Solved: Frame Relay Questions

gojericho0 · ‎04-22-2008

Hi NetPros, I'm trying to understand frame-relay and the way it works a little bit more in depth. I'm kind of confused with the Layer2-to-Layer3 mapping.

With point-to-point subinterfaces is the DLCI used to send frames implied because the receiving router will see the DLCI and realize it can only come from one possible host?

When 2 or more PVCs terminate on a router is it necessary to have this mapping in order to avoid DLCI confusion?

If so, what examples would you prefer frame-relay map configuration opposed to inverse ARP and vice versa!

Thanks

Kevin Dorrell · ‎04-23-2008

For a hub-and-spoke system, you can have a multipont (or physical) interface at the hub, and p2p subinterfaces at the spokes. At the hub, configure a frame map for each spoke, or allow it to learn the address of each spoke by inverse-arp.

From the p.o.v. of spoke-to-spoke communication, there shoud be no problem. Each spoke will forward all traffic for the subnet up to the hub, because the P2P inteface will have a mask that covers all the spokes as well as the hub.

As far as the routing protocols are concerned, you would need to switch off split-horizon for RIP or EIGRP. If you don't do that, the spokes will still be able to get to each other on the FR subnet, but the hub would not pass any branch-office LAN prefixes from spoke to spoke.

OSPF is a little more complicated. You should make sure that the hub is the DR, and in that way it will reflect any prefix advertised by a spoke to each other spoke. The best way to do that is to configure ip ospf priority 0 on the spokes.

Alternatively, define the OSPF network type as point-to-multipoint. That way there would no longer be any DR, but the hub would treat each link like a seperate P2P network as far as LSAs are concerned.

Does that make sense?

Kevin Dorrell

Luxembourg

View solution in original post

paolo bevilacqua · ‎04-22-2008

Hi, basically it's like you say, point-to-point eliminates the need for mapping and is preferred for most installations. Exception, when an hub has many many spokes (like, hundreds) and you don't want to reconfigure it each time a branch is addeded or changed, then a multipoint configuration is advantageous.

gojericho0 · ‎04-22-2008

Thanks for the quick reply

gojericho0 · ‎04-22-2008

Another frame question. I can understand how implementing multipoint connection for a large hub and spoke would make maintenance easier every time a new spoke was added/removed, but what happens if each of those spokes LANs need to communicate to one another? With a multipoint (sub)interface would split horizon stop the LANs networks from advertising to each other since it would try to both enter and exit from the same sub(interface) on the hub?

Kevin Dorrell · ‎04-23-2008

For a hub-and-spoke system, you can have a multipont (or physical) interface at the hub, and p2p subinterfaces at the spokes. At the hub, configure a frame map for each spoke, or allow it to learn the address of each spoke by inverse-arp.

From the p.o.v. of spoke-to-spoke communication, there shoud be no problem. Each spoke will forward all traffic for the subnet up to the hub, because the P2P inteface will have a mask that covers all the spokes as well as the hub.

As far as the routing protocols are concerned, you would need to switch off split-horizon for RIP or EIGRP. If you don't do that, the spokes will still be able to get to each other on the FR subnet, but the hub would not pass any branch-office LAN prefixes from spoke to spoke.

OSPF is a little more complicated. You should make sure that the hub is the DR, and in that way it will reflect any prefix advertised by a spoke to each other spoke. The best way to do that is to configure ip ospf priority 0 on the spokes.

Alternatively, define the OSPF network type as point-to-multipoint. That way there would no longer be any DR, but the hub would treat each link like a seperate P2P network as far as LSAs are concerned.

Does that make sense?

Kevin Dorrell

Luxembourg

gojericho0 · ‎04-23-2008

Yes, that makes sense as well. Thanks

mohammedmahmoud · ‎04-23-2008

Hi Kevin,

Nice explanation indeed, i just wanted to elaborate on the OSPF case, as you have stated one of the recommended ways to configure OSPF in a hub and spokes scienarios, is using point-to-point network type on the spokes, and point-to-multipoint on the hub (or even more point-to-point subinterfaces on the hub), and since point-to-point and point-to-multipoint are compatiple network types (both doesn't use DR) thus it will work fine, but don't forget to edit the timers on any of the sides to match the other (since by default point-to-point hello is 10, while point-to-multipoint is 30, thus it is more logical to change it on the hub).

The thing that i wanted to highlight is how this overcomes the spoke to spoke reachability issue (layer 3 to 2 resolution), multiaccess network types (Broadcast and NBMA) don't change the next-hop of a route, which is very logical, but point-to-point and point-to-multipoint do change it, and thus in the hub and spoke model if they are used as proposed, the hub will always be the next-hop of the routes, and thus no spoke to spoke rechability is required.

BR,

Mohammed Mahmoud.

mohammedmahmoud · ‎04-23-2008

Hi,

After rereading the post, i think i might have not made my point clear. The main problem with OSPF is that with multiaccess networks, for a spoke route on another spoke router, OSPF installs the route into the routing table of a spoke using the other spoke as its next-hop (regardless of being its neighbor), and since the spokes have no layer 3 to layer 2 mapping for each other, the routes are not reachable, and thus you have three solutions: 1) OSPF Solution: Use point-to-point and point-to-multipoint network types to force the spokes to use the hub as the next-hop of the routes (The hub will always be the next-hop of the routes, and thus no spoke to spoke reachability is required). 2) Layer 2 Solution: Make sure that the spokes have layer 3 to layer 2 mapping on the spokes (all the other spokes IPs resolves to the hub DLCI). 3) Layer 3 Solution: Make sure that the spokes have layer 3 reachability of each other through the hub (Static routes for the spokes IPs on each spoke pointing to the hub).

I believe that all these stuff are nice, for understanding OSPF behavior and also for CCIE exam :), for real life, i think that simple point-to-point subinterfaces are the best option.

BR,

Mohammed Mahmoud.