ConnectivityRestaurant StatusesThere are a several different statuses available to help us diagnose the health of a customer’s ERB system. You can find the status of a particular system by looking it up in CHARM:

Status DefinitionsActive - Restaurant is ready to take online reservations and is on the OpenTable website. Just because a restaurant is active doesn't mean they are Reserve Now. They could be back soon because of internet connectivity problems.

Awaiting Install - This is a new customer, the process of implementation has begun

Inactive - Restaurant is no longer a customer with OpenTable - could be because they have closed, they quit OpenTable, etc.

Closed Temporarily - Site is closed for a short period of time for reasons like renovations - they will not appear on the website. A site may sometimes be in hibernation during this period.

Seasonal - Depending on the location of the restaurant, they may only be open during the high tourist season - open only for winter months (Ski season in Denver, Colorado) or only open during summer months. A restaurant is also to be considered to be in Hibernation

Temporarily Inactive - Listener password does not match between the server ERB and the website. When this occurs, you will need to verify the password on the ERB and what is in CHARM (only visible to tier 2). This status can also occur if two (or more) restaurants are sharing the same public IP. In this case you will need to get the restaurants on unique IP addresses.

Initiating Uninstall - Site is in the process of terminating their OpenTable service - they are not on the website. Also, if a customer is Locked Out due to a billing issue.

Client Grace Period - Restaurant has been installed, they SHOULD have connectivity, but they are not ready to go live on OpenTable.com site. At time of install, this status should only be in place for up to two weeks and after that they need to be set to Active/Reserve Now or Waiting for Connectivity. You can confirm connectivity is in place by checking the "Last Contact" field on the ROMS -> Hardware page.

Decline Online w/ Conn. - Restaurant has OpenTable, but they do not want to take online reservation. They only use OpenTable to manage their phone / internal reservations. The restaurant is charged a monthly Non-Connectivity Surcharge (USD $75) for not accepting reservations online.

Waiting for Connectivity - Restaurant did not have connectivity at the time they were installed - restaurant usually is actively looking to get connectivity

Updating Book - When the restaurant is making configuration changes in their ERB, this will cause them to temporarily go into this state. They will return to their previous status once they are done with their configuration changes

No Connectivity Available - Site does not have connectivity - they have more than likely exhausted all options for getting connectivity for the OpenTable ERB

Decline Online w/o Conn. - Site has exhausted all options on finding connectivity for the ERB OR simply chooses to not be connected. The restaurant is charged two monthly fees for this:Non-Connectivity Surcharge (USD $75) for not accepting reservations onlineNon-connectivity Support Fee (USD $25) as it is typically more complex / time consuming to support these customers.

False Reserve Now (FRN) - ERB has connectivity to the internet, but port forwarding is not set correctly.

Restaurant Status History

The Restaurant Status History keeps track of any connectivity changes a restaurant may experience. You can find this information for a specific restaurant under Profile -> Connectivity Settings in CHARM.

Status History DefinitionsReserve Now - This has the same meaning for both Website and Cache Server. It means that that the Webserver or a Cache Server has received recent contact (a reply to a request, a heartbeat message, or some other message), within the past 10 minutes, indicating that they system is online and is accepting online reservations.

The origin of the name "Reserve Now" comes from early versions of the OpenTable.com website - a diner would click on a "Reserve Now" button next to the restaurant name to search for reservation availability.

Back Soon - No recent contact has been received from the restaurant, most likely because of network issues.

The origin of the "Back Soon" label comes from older versions of the OpenTable.com website - when a restaurant was offline, the website would show an icon saying that the restaurant would be back soon for online reservations.

Updating Book - The restaurant is currently editing some aspect of their system (modifying shift times/dates, modifying slot allocations, etc.). Once the editing is complete and the new schedule information has been uploaded to the Cache Server, the restaurant should normally transition back into the "Reserve Now" state.

False Reserve Now (FRN) - The ERB is telling the web servers that it has connectivity, but when the web servers ask it a question, there is no reply back. This might be caused by networking misconfigurations (i.e. port forward not set correctly). The restaurant is falsely proclaiming that it is "Reserve Now" - this is a "False Reserve Now" because it will not accept reservation requests even though it may be sending us heartbeats.

Troubleshooting Back SoonsA Back Soon status occurs when our website cannot communicate to an ERB, and the ERB cannot call out at all. This means that the restaurant’s system is offline and cannot accept reservations, nor can it be backed up to the OpenTable servers.

In an effort to resurrect “Reserve Now” status on our Website, proceed with the below steps.  This guide is designed to be worked through from start to finish in a stepwise fashion.  

Note that if you find yourself at an escalation point, you want to have ready the most thorough information possible.  As you move through the below steps, place a check mark next to what you’ve done.  That way, when passing on the information, you can repeat the exact steps that were taken.  

If you find yourself at a point in this guide where a call to the restaurant is needed have ready a standard response.  For example, “I noticed that you are listed as Offline on our Website.  Do you have some time to troubleshoot with me - I need your help to check a few items on your end.” If Back Soon status is non-urgent to the restaurant, avoid troubleshooting calls to a restaurant during meal hours. Be aware of the restaurant’s needs and priorities.

Step 1 - Check the RouterTo check the router, follow these steps:

1. Ping the gateway address (Server IP minus 1).  a. If you receive a solid string of replies, the router is connected to the

DSL line. Move on to check the Listener.b. If you receive a response that is ~50% timed out with variable replies,

the router may have a faulty circuit.  [Internal escalation - possible trouble ticket needed]

c. If your request is solidly timed out, proceed with point 2 - calling the restaurant

2. Call the restaurant. Ask the customer to check for power to the router; are there lights on?  What color are the lights?

a. If red lights are on, check the connection of the router to the DSL line in the wall.  Make sure the DSL cabling is firmly “clicked” into router as well as snug in the wall jack.

If the cabling is secure but red lights persist, possible regional DSL outage. Check the status of other establishments in the area on the website. If other establishments are not offline, its possible that the restaurant is experiencing a site specific outage. [Internal escalation - trouble ticket needed]

b. If green lights are on and the cable connection to the DSL line looks secure but Back Soon status persists, have the restaurant “power cycle” the router by turning it on and off and unplugging it for a few seconds.

Step 2 - Check the ListenerIf you’ve received a solid string of replies from the gateway address, your next step is to check the Listener.

If you can connect using a virtual network connection (VNC), check the Listener on the server node (the Listener should be disabled on every client). On the server, start the Listener if it is stopped or try stopping and re-starting it.  

If you are unable to connect using a VNC, move on to Step 3 - Check the ERB.

Step 3 - Check the ERBFollow these steps to check the ERB:

1. Ping the server ERB (IP address)a. If your request is timed out, place a call to the restaurant to determine

if the server ERB is turned off.  It will take a few minutes for the restaurant to be removed from Back Soon status once the ERB is

restarted.  

b. If the ERB was not turned off, but your request was timed out move on to Step 4 - Check the Hardware Connections from Router to ERB

Step 4 - Check the Hardware Connections from the Router to the ERBFollow these steps to check the hardware connections from the router to the ERB:

1. Call the restaurant**a. Ask the customer to trace the thinnest gray/ blue/ white/ black cable

from the server.  For restaurants with drilled host stands, they may have to tilt the base to see and check the cable and, in turn, open a host-stand cabinet to follow the cable to the modem or router. The thin cable should feel secure from the base of the server ERB.

b. Check the cabling from the server to the hub (if applicable) and to the router. Check for a secure, “clicked” connection from the server to the hub and from the hub to the router, noting if the light is on.

2. If Back Soon still persists, power cycle the router and/or the hub by turning them on and off and unplugging for a few seconds.

Escalating Back Soons to Tier IIIf you need to escalate a Back Soon case to Tier II, ensure that the following information is included for the support rep.

Port Test Results: IPConfig: IP: SM: DG: Ping OT.com IP: Ping OT.com:

The above MUST be included with EVERY Back Soon call!1. RUN A PORT TEST IN RAT!-If your port scan FAILS FOR ALL PORTS, MOVE ON TO STEP 2.-If your port scan PASSES FOR ALL PORTS, then check the rogue status of the ERB. This is listed under the hardware process and there is a wiki page with complete instructions on how to correct a rogue.-If you receive mixed results with your port scans, then flapping is a possibility. See if you are able to VNC in and investigate the ERB’s connectivity.-If your port scan indicates ONLY LISTENER FAILING, then try restarting OTL service or SQL. Often times if this isn’t resolved by the service restart, then there is a

possible issue with SQL. You can confirm a SQL issue, if the software fails to open completely.

2. Have the customer pull up the command prompt and run and IPCONFIG. The results of the IPCONFIG determine the next course of action.

-If returned with Media State Media Disconnected, have customer check cables between the ERB and first device and ensure that the first device is powered on properly.

-If returned with relevant IP information, move on to step 3.

3. Ping the DG  -If the ping to the DG times out, then P/C the DG. If this still does not resolve the issue, then try setting the ERB to DHCP, to see if a new DG will be pulled automatically. -If you successfully get replies from the DG, then move on to step 4.

4. Ping 66.151.130.32 -If this ping fails, then the site is unable to reach out to the internet. Have them check the cabling for the modem and ask if other devices at the restaurant are experiencing issues, as this will tell you if we need to get the ISP involved.-If you get replies from 66.151.130.32 when pinging, then move on to step 5.

5. Ping Opentable.com-If this fails, but you were able to ping 66.151.130.32 in the previous step, this often indicates a DNS issue. Check the ERB’s DNS settings and if need be, run an “nslookup” to see if the DNS servers are being resolved.-If this passes, then you have internet connection and move on the FRN troubleshooting.

Troubleshooting False Reserve Nows (FRN)False Reserve Now (FRN) occurs when an ERB can send data to our website, but the website cannot send data back to the ERB.

Troubleshooting Steps

1. Check the Public IP Address-The first step with any FRN should be to check the PFIP. Often times this switches up rendering sites FRN. If our auto-update feature is enabled in CHARM “Connection Settings”, then the site should theoretically go back Reserve Now after several minutes, but many sites have this feature disabled and need to update this information with us manually.

2. Check the Port Forwarding-More often than not, the cause of a FRN will be port forwarding related. We will need to pull and ipconfig, access the DG and attempt to setup port forwarding. In some cases the ports will still not pass after setting up the first device and you will need to check for a possible double, or sometimes even triple NAT. Most routers and modems have a page that is likely titled “Status” or a close variant. If you see the PFIP being displayed on this page, then you are currently in the last device, however if an additional DG and IP address is displayed, you will need to drop Host Intrusion and attempt to access to next device.

3. Static vs DHCP-95% of the time, our ERB’s are required to be set to a static IP. The only exception being some 2wire devices that route to either the MAC address or netbios of the machine, rather than the IP.  If an ERB gets left in DHCP and reboot, we run the risk of it pulling a different IP address, resulting in an FRN.

4. Check Windows Firewall-In rare cases, Windows Firewall will be enabled on the ERB and will cause an FRN. Where this is rather rare, A LOT of reps do not think to check this before escalating, leaving T2 shaking their heads…A MUST CHECK before escalating.

Single NATs (NAT = Network Address Translation)Double NATs

Quick way to see if it is a double NAT

1. Once connected into 1st device (router), if you see a public facing IP it is NOT a Double Nat. You can find the public facing IP on the router’s status page.

2. If you connect to 1st device (router) and see a different IP address and default gateway, it IS a double NAT. Connect to the 2nd device using the default gateway that is shown on the router.

Note: to get to the 2nd device you will need to log into the server machine under the admin account and drop into the firewall. McAfee HipScore & McAfee Host Intrusion. You will not be able to get to the 2nd device without dropping firewall)

Once you see the public facing IP address you are done. Hit “search” again in RAT and test the ports. They should pass. Then, restart the firewall and log back into the server as the user’s account.

Triple NATsIf double/ triple NAt, you need to drop the firewall in order to get into the 2nd and 3rd device. McAfee HipScore & McAfee Host Intrusion. You must be logged in as an admin on the server.

Once you see the public facing IP address (www.opentable.com/ip) you are done

Hit “search” in RAT and check the ports. They should now pass. If so, reenable the firewall and log back into the server as the user.

FlappingA "flapping" restaurant is a site that changes from Reserve Now to a different status at least 3 changes per day for more than 2 days in a row.

FirewallWindows FirewallOpenTable’s FirewallMcAfee Host IntrusionMcAfee Hip Score