Kevin Dorrell, CCIE #20765

07 Mar 2008

Frame-Relay multipoint or physical interfaces

Filed under: Bridging on routers, EIGRP, Frame Relay, IP Multicast, OSPF, RIP — dorreke @ 11:38

 If you want to skip the blah-blah, you may want to go directly to the table below.  You will then want to read the blah blah to see what it is about. 🙂

 I’m not sure how much sense I made in yesterday’s posting.  The point was that we had a Frame Relay multipoint interface with a bridge-group on it.  Spanning Tree assumes that all devices on a segment can see each other’s broadcasts.  But this is not so with FR-MP or physical.

It got me thinking.   Frame Relay multipoint and physical interfaces are great for CCIE scenario writers.  They have so many issues.  That is because they are NBMA.  Many many protocols assume a multi-access segment is a broadcast segment.  NBMA breaks this rule because as often as not there is no visibility from spoke to spoke.  Most of the literature says “Here is a technology X.  This is how you configure it.  BTW, there is a special requirement for NBMA networks, and you have to do this … “.

I want to look at it from a different angle.  I want to make a list the things that NBMA cannot do, and how you can get round it for each technology.  I want to be able to say “OK, we have a FR multipoint.  They have obviously specified that in order to mess something up.  Which technologies are likely to be impacted?

So here is the list:

Technology Gotcha Solution
RIP RIP will not normally advertise out an interface it received the route on.  Not a problem in Frame Relay because split-horizon is disabled by default, but is a problem in other NBMA technologies such as X.25. 1. no ip split-horizon on interface (by default in FR)
2. Static neighbor spoke to spoke (TTL=2)
EIGRP EIGRP will not advertise out an interface it received the route on 1. no ip split-horizon eigrp nn on interface
2. Static neighbor spoke to spoke (TTL=2)
OSPF network No LSAs seen spoke-to-spoke 1. ip ospf priority 0 on spokes to force DR on hub
2. ip ospf network point-to-multipoint throughout
OSPF NSSA If one spoke is an ASBR and talks OSPF to the hub, but another spoke does not talk OSPF but has a route to the the prefix, what can happen to the forward address.  Might be unreachable? Still thinking about this !
bridge-group No visibility spoke-to-spoke There will usually be some alternate route between the STP root and the spoke.  Contrive Spanning Tree to block all but one of the circuits on the multipoint and therefore use alternate route.
PIM dense-mode If multicast source is behind the hub, then a prune from one spoke will prune all of them.  If multicast source is on a spoke, then it will not be routed out the same interface to another spoke. Find an alternate route for all but one of the spokes, or even for all of them.  Usually, this can be done with a tunnel, or by leveraging some alternate path to the source.  Use static ip mroute
PIM sparse-mode If multicast source is on a spoke, then it will not be routed out the same interface to another spoke. ip pim nbma-mode.  Or treat in same way as dense mode above.

Can anyone suggest anything to add to the list?

These issues are not limited to Frame Relay multipoint.  I have seen NMC labs where they contrive to turn an Ethernet segment into a NBMA segment, typically by creating unicast peering between routers on the Ethernet, and therefore not allowing them full-mesh.

06 Mar 2008

NMC Lab 10 – Layer 2 challenge

Filed under: Bridging on routers, LAN Switching — dorreke @ 23:16

Today I did NMC Lab 10.  This lab is a layer-2 blockbuster.  The most difficult part consists of two Spanning Trees comprising a mix of switches and IRB bridges.

I am seeing patterns in the style of the NMC labs.  Very often the problem will consist using a feature for something it was never intended for in the first place, and then using the configuration tools to get round the problems.  In this case it constructed two Spanning-Tree networks, each consisting of four routers acting as bridges, and VLANs on the four switches.  In this case, the biggest issue was that some of the bridges were multipoint Frame Relay subinterfaces in a hub-and-spoke arrangement.  Of course, the issue is that you cannot broadcast from spoke to spoke, and Spanning Tree assumes that you can.  You therefore have to fiddle the Spanning Tree so that only one spoke is in forwarding, and the others are in blocking state.

They then specify multiple constraints about which switch or bridge is root, and the paths that the traffic should take.  What you are left with is a sort of Sudoku puzzle where you have to work out the link costs on the links you are allowed to touch by deriving them from the links you are not allowed to touch.  You have to consider five sections of the lab, 10.1, 10.2, 10.3, 10.4 and 10.10 simultaneously.

At one point, they ask you to minimise the convergence timers.  I did so, and one of the Spanning Trees became unstable.  Strange … I used the same timers as in the SHOWiT.  May be something to do with the fact that I use 2950s for CAT3 and CAT4 instead of 3560s.  Wrote a note on the DISCUSSiT about it.

I think I would have failed this one.  It took me the best part of four hours to get the layer-2 working and the full inter-network connectivity, and a further hour and a bit to get the full IP connectivity.  The BGP took some time too.  Not so much of a challenge, but just big.

I like Ethan’s comments on this lab.

Create a free website or blog at