What is a possible solution to this issue?

Customer X has a hub-and-spoke Frame Relay network, with a central office and two branch offices (RemoteA and RemoteB). Each location has only one physical link to the Frame Relay cloud and RemoteB has a router that is not a Cisco router. Since the installation, there is no connectivity between RemoteB and the central office. What is a possible solution to this issue?

Customer X has a hub-and-spoke Frame Relay network, with a central office and two branch offices (RemoteA and RemoteB). Each location has only one physical link to the Frame Relay cloud and RemoteB has a router that is not a Cisco router. Since the installation, there is no connectivity between RemoteB and the central office. What is a possible solution to this issue?

A.
Because Frame Relay IETF encapsulation is only configurable at interface level, you must use IETF encapsulation on all routers.

B.
This is not a possible scenario. A dedicated Frame Relay link to RemoteB is mandatory at the central office.

C.
The router at RemoteB must be replaced by a Cisco router.

D.
Use Frame Relay IETF encapsulation on a per-VC basis on the central office router.

E.
There is a problem in the Frame Relay cloud, because Cisco routers are compatible with IETF Frame Relay.

Explanation:
Cisco supports two different Frame Relay encapsulation types. The default Frame Relay encapsulation enabled on supported interfaces is the Cisco encapsulation. Cisco also supports the IETF Frame Relay encapsulation type, which is in conformance with RFC 1490 and RFC 2427. RFC 2427 supercedes RFC 1490. Both RFC specifications define standards allowing multiple routed protocols to be carried over Frame Relay. Readers can refer to http://www.faqs.org/rfcs/rfc2427.html and http://www.faqs.org/rfcs/rfc1490.html for references on both RFCs.



Leave a Reply 0

Your email address will not be published. Required fields are marked *