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:

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.

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.