“Still to do” list

Someone asked me recently what I was going to do now I have my digits … would I go for a second one?  Well, not just yet.  I may have got my digits, but there are still too many things in R&S that take me by surprise.  I have found out that you can be a CCIE and still not know everything yet. :-). So expect about a year of consolidation and blogging before I move to pastures new.

Knowing what
Thou knowest not
Is in a sense
Omniscience

Piet Hein, “Grooks”

Some of the stuff that Keith Tokash has been logging recently on the “CCIE Candidate” blog has pointed the way to some interesting investigations.  Furthermore, there have been a few questions on NetPro that have made me think.  It might even be the case to go to one of Narbik’s boot camps when he is in London.  (Or maybe I’m just looking for an excuse to go back to my home city.   So this page will be a working list of things to do.  Pian piano.

EIGRP 

1. EIGRP uses the metrics at which end of each link: the transmit end or the receive end.  Is it possible to provoke asymmetric routing by configuring different metrics at either end of a link?  Can this result in any unstable topologies?  See NetPro context.
2. Someone on the NetPro forum tells me that EIGRP uneven load balancing is always process switched.  I thought it was handled by CEF using a weighted hash algorithm.  I have to lab this.  Here is a document I based my belief on.

OSPF

1. OSPF uses the cost at which end of each link?  Actually, I already know the answer to this one: each router advertises an LSA for each network it is attached to, along with the outgoing metric of the link.  So, looking at the path of a packet from source to destination, the cost is the sum of the transmit costs on the path.
2. There are two ways of putting a link into are area: with ip ospf 100 area 0 on the interface, and with network x.x.x.x area 0 in the router section.  In the event of a conflict, which takes precedence?
3. Ask the same question of ip unnumbered interfaces.

HSRP and Routing protocols

1. I still need to understand fully the interaction between HSRP and routing protocols.  Hereis a situation where HSRP appears to cause unexpected results from a routing protocol.

LAN Control Protocols

1. When you have a dot1q trunk, which of the control protocols are send on VLAN 1 and which are sent on the native VLAN (assuming these are different).  I answered a question on NetPro about this and apparently got it wrong.  I need to lab it.

Spanning Tree

1. Spanning-Tree.  I guess I should ask the same question for Spanning-Tree, which after all is a sort of Distance-Vector algorithm.  Which end of each link is significant.

VTP

1. I keep telling people to beware that a VTP client can update a domain, and so it can.  But it is not as easy as I had once thought.  I need to write up the experiment properly.  I wonder whether the behavior is version dependant.
2. Furthermore, I really want to investigate VTP transparent.  How transparent is VTP transparent?  Can a transparent switch pass through VTP information, and if so, does the domain name need to match?  How does VTP pruning react to encountering a VTP transparent switch?

There is a load of lab work to do on this.

EIGRP timers – solution

A couple of days ago I posted a blog entry about EIGRP timers, but I didn’t have time to explain it properly.  So I just dumped the console logs of the experiment, and left it as a “guess what” challenge.  Now is the time to reveal all.

What I am trying to do is to look at a common misconception about EIGRP hello timers.  By default, the EIGRP hello-interval on most networks is 5 seconds, and the hold-time is 3 times that: 15 seconds.  These values are configurable, but how should they be configured?

The story you read in the books is that the hold-timer must be more than the hello-timer, and preferably 3 times as much.  What the books generally don’t tell you is that:

• The hello mechanism works independently in each direction.  Hellos from router R1 to router R2 do not necessarily have to use the same parameters as hellos from R2 to R1.
• The hold time is transmitted to the neighbor in the hello packet.  R2 does not use its locally configured hold-time, but uses the value that R1 tells it to use.  This has profound implications if you really want to understand the EIGRP Hello timers.

Let us illustrate this with an experiment:

Now, observe the EIGRP timers.  R1 has a hello-interval of 3 seconds, and a configured hold-time of 10 seconds.  R2 has a hello-time of 30 seconds, and a hold-time of 100 seconds.  At first sight, this looks as though it should be unstable; it looks as if the adjacency should stay up for 10 seconds, then go down, stay down for 20 seconds, come up for 10, etc.  But it doesn’t.  Why not?

Let us look at R1’s view of this relationship:

R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.2             Fa0/0.12          74 00:00:25   12   200  0  6

See the hold time?  The neighbor relationship has been up for 25 seconds, and the hold time is 74 seconds, not something less than 10 as we would expect.  What has happened is that R2 has sent a Hello with 100 seconds of hold time.  “Hello, I am R1, if you don’t hear from me in the next 100 seconds, assume I am dead”.

And at R2:

R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.1             Fa0/0              8 00:00:35    8   200  0  9

Here we see the hold timer that was configured in R1.

Conclusions: The EIGRP Hello mechanism works independently in each direction.  Each router does not use its locally configured hold time, but the hold time determined by its neighbor.

The really cool thing about this is that if I want to change the interval at which I send out hellos, I don’t need to touch the hold time of any of my neighbors; I just need to configure it locally.

EIGRP timers

Well, anyone can see that this blog entry is incomplete.  I am just dumping the console logs here so I can format them up and explain them later.  Anyone care to hazard a guess as to what I am trying to show? 

R1:

R1#show run int f0/0.12
Building configuration...

Current configuration : 197 bytes
!
interface FastEthernet0/0.12
 encapsulation isl 12
 ip address 172.16.12.1 255.255.255.0
 no ip redirects
 ip hello-interval eigrp 200 3
 ip hold-time eigrp 200 10
 no snmp trap link-status
end

R1#show ip eigrp neighbor f0/0.12
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.2             Fa0/0.12          74 00:00:25   12   200  0  6

And R2:

R2#show run int f0/0
Building configuration...

Current configuration : 156 bytes
!
interface FastEthernet0/0
 ip address 172.16.12.2 255.255.255.0
 ip hello-interval eigrp 200 30
 ip hold-time eigrp 200 100
 duplex auto
 speed auto
end

R2#show ip eigrp neighbor f0/0
IP-EIGRP neighbors for process 200
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.16.12.1             Fa0/0              8 00:00:35    8   200  0  9

So there you have it …

 

NMC DOiT 16.5 EIGRP

I did have a momentary panic in the EIGRP section over “16.5.2 Send a summary for the entire Class B range from R2 to CAT2 only.”

For a start, I misinterpreted it as meaning 160.60.0.0/16, the major network of the pod.  So I did an ip summary-address eigrp 1 160.60.0.0 255.255.0.0 on R2-F0/0.  Of course, the summary turned up not only in CAT2, but in R1 and everywhere else as well.  I could have filtered it toward R1, but that seemed like too much work.  What I wanted to do was to get rid of the discard route on R2.  Could I remember how to do it?  No!  So it took some research to remind myself of ip summary-address eigrp 1 160.60.0.0 255.255.0.0 255.  Setting the AD to 255 stops the discard route getting into the routing table, and so stops it getting redistributed into OSPF.

All well.  But futile.  On reconsideration, what they wanted was a range that covered all the Class-B addresses.  In other words, ip summary-address eigrp 1 128.0.0.0 192.0.0.0 255.  Later, I checked it against the SHOWiT, and found they did not put in the AD=255.  So, doesn’t that make the /2 summary route turn up in R1?  Instead of putting AD=255, they take the precaution  of filtering it during the redistribution from EIGRP to OSPF.  The difference my AD=255 makes is whether the discard route gets installed in R2.

 

NMC Lab 12.7.5 : EIGRP uneven load-balancing

This section is a study in unequal load balancing in EIGRP using the variance command.  We have R5 that is being fed identical routes from R2 and R3.  It is load-sharing 1:1.  We have to change that ratio 6:1 in favour of R2.  The way they do it in the AK is to increase the delay on the interface towards R3 until it gets only 1/6 share of the traffic.  We end up with something like this on R5:

R5#show ip route 151.10.104.0
Routing entry for 151.10.104.0/24
  Known via "eigrp 100", distance 170, metric 20537600, type external
  Redistributing via eigrp 100
  Last update from 151.10.25.2 on Serial1/0, 00:14:14 ago
  Routing Descriptor Blocks:
  * 151.10.35.3, from 151.10.35.3, 00:14:14 ago, via Serial1/1
      Route metric is 123225600, traffic share count is 1
      Total delay is 4032250 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
    151.10.25.2, from 151.10.25.2, 00:14:14 ago, via Serial1/0
      Route metric is 20537600, traffic share count is 6
      Total delay is 21000 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

R5#show ip eigrp topology 151.10.104.0/24
IP-EIGRP (AS 100): Topology entry for 151.10.104.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20537600
  Routing Descriptor Blocks:
  151.10.25.2 (Serial1/0), from 151.10.25.2, Send flag is 0x0
      Composite metric is (20537600/1732096), Route is External
      Vector metric:
        Minimum bandwidth is 128 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 151.10.102.1
        AS number of route is 12
        External protocol is OSPF, external metric is 66
        Administrator tag is 0 (0x00000000)
  151.10.35.3 (Serial1/1), from 151.10.35.3, Send flag is 0x0
      Composite metric is (123225600/1732096), Route is External
      Vector metric:
        Minimum bandwidth is 128 Kbit
        Total delay is 4032250 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 151.10.103.1
        AS number of route is 12
        External protocol is OSPF, external metric is 65
        Administrator tag is 0 (0x00000000)
R5# 

The original metric was 20537600 on both of these routes, but by adding to the delay on the interface, we have loaded the route via 151.10.35.3 until it is 6 times that through 151.10.25.2.

I thought I would be clever and try and do it another way, using an offset list.  So I removed the loading on the interface, and added offset-list 1 input 102688000, where access-list 1 defines the OSPF routes we want to re-balance.  That should bring the metric to 123225600.  Trouble is, it doesn’t work.  The route disappears altogether.  Why?

Well, when we add delay to our local interface, we add to the metric sure, but the “advertised distance” to the downstream router, R2, remains unaffected.  In this case it is 1732096.  OTOH, if we use an offset-list, it adds not only to the metric, but also to the “advertised distance”.  In this case, it becomes 104420096.  This is greater than the total metric of the route via R2, so we fail the “feasible successor” test.

Key point: Adding to the interface delay increases the local metric but leaves the neighbor’s apparent advertised distance unchanged.  An offset-list, OTOH, adds to the apparent advertised distance of the neighbor.

NMC Lab12 : Redistribution OSPF–>EIGRP

While I was doing this lab, I came across some strange behavior.  If you redistribute from OSPF to EIGRP through a route-map, and that map specifies the route-type, (local, internal, external, etc.) then there seems to be no way to include the connected interfaces.

For example, using NMC Lab 12 as a test-bed, I removed the redistribution on R2 and concentrated on R3.  R3 is connected to 151.10.43.0/24, which is in OSPF.  We are redistributing OSPF into EIGRP, and watching the routes turn up through EIGRP on R5:

R3#
:
router eigrp 100
 redistribute ospf 12 metric 1500 100 255 1 1500
:

On R5, we can see a route to 151.10.43.0/24:

R5#show ip route 151.10.43.0
Routing entry for 151.10.43.0/24
  Known via "eigrp 100", distance 170, metric 123225600, type external
  Redistributing via eigrp 100
  Last update from 151.10.35.3 on Serial1/1, 00:00:45 ago
  Routing Descriptor Blocks:
  * 151.10.35.3, from 151.10.35.3, 00:00:45 ago, via Serial1/1
      Route metric is 123225600, traffic share count is 1
      Total delay is 4032250 microseconds, minimum bandwidth is 128 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

I have prepared a route-map on R3 to distribute through.  Let us include locally generated routes and internal routes:

R3#show run
:
route-map OSPF-->EIGRP permit 10
 match route-type local
!
route-map OSPF-->EIGRP permit 20
 match route-type internal
!

Now let us apply the route map:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R3(config)#router eigrp 100
R3(config-router)#redistribute ospf 12 metric 1500 100 255 1 1500 route-map OSPF-->EIGRP
R3(config-router)#^Z
R3#

Look what happens on R5.  We lose the route to 151.10.43.0/24.  It does not seem to be getting past the route-map.

R5#
*Mar  1 19:29:31.788: RT: delete route to 151.10.43.0 via 151.10.35.3, eigrp metric [170/123225600]
*Mar  1 19:29:31.792: RT: SET_LAST_RDB for 151.10.43.0/24
  OLD rdb: via 151.10.35.3, Serial1/1 *Mar  1 19:29:31.792: RT: no routes to 151.10.43.0
*Mar  1 19:29:31.792: RT: NET-RED 151.10.43.0/24
*Mar  1 19:29:31.792: RT: delete subnet route to 151.10.43.0/24
*Mar  1 19:29:31.796: RT: NET-RED 151.10.43.0/24
R5#

I would have thought the connected interface would at least be counted as a locally generated route.  How do I write a route-map to include the connected interfaces?  (Assuming that, as in this case, the scenario forbids you to redistribute the connecteds directly.)  Well, the only way I can think of is to make an access-list listing the connected prefixes of the source protocol, and add a clause to the route-map that matches the access list.  Normally I am reluctant to use access lists to filter redistributions because it is not scaleable.  However, in this case it is not so bad because it is only the locally connected prefixes you are listing.  It is still scaleable.

Key Point: If you redistribute from OSPF through a route-map, and that route-map filters by route-type, the connected networks are no longer included.

If anyone else has observed this, or can repeat the experiment, could you please leave a comment?  Thanks.
 

NMC Lab 11 : Redistribution

Here is my redistribution diagram:

 It looks complicated, but in fact it isn’t.  It looks complicated ‘cos I added a lot of information to the diagram as I want along.

Since this lab contains multiple loops and no less than four active redistribution points, we have to be careful with filtering and Administrative Distances.   I look at the filtering first, which prefixes get passed from which domain to which other, then I look at the Administrative Distance to control which routes are preferred at the border routers.  I prefer not to rely on AD to control redistribution; I find the filtering tools such as route maps are better for that.  AD is only relevant at border routers, and I use it to control forwarding preferences.

Controlling redistribution with tags 

Everything gets tagged as it is redistributed, to say where it originally came from.  Once a prefix is tagged, it usually keeps its tag, even through subsequent redistributions.  That way, I can base my filters on the tags.  Any prefix that is not yet tagged must be internal to the domain we are in.  (I use that property later to distinguish RIP native prefixes, rather than have to list them explicitly.)  Here are the tags I have used in this lab:

• Tag 12 = EIGRP 12 native prefixes
• Tag 34 = EIGRP 34 native prefixes
• Tag 110 = OSPF native prefixes
• Tag 120 = RIP native prefixes

Routing domains

Looking at the diagram, we have two transit domains (RIP and OSPF) and two edge domains (EIGRP 10 and EIGRP 34). 

The edge domains only have to send out their native prefixes into the RIP and OSPF.  At first, they will only receive prefixes that are not their own natives.  (Later, I shall look at the possibility of them receiving their own fed-back prefixes to repair them if they are broken.)

Traffic between the edge domains will pass through either RIP or OSPF.  RIP and OSPF will have to pass prefixes through from one edge domain to the other.  One thing I shall not attempt to do (at least for now) is to get the transit domains to repair each other if they are broken.  That would really make it complicated.

Redistribution rules

R1 has no less than six redistribution route-maps.  Only the listed prefixes get redistributed, everything else is implicitly denied.

• RIP–>EIGRP : RIP natives get tagged 120, EIGRP 34 natives keep thier tag.
• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 34 natives keep their tag.
• EIGRP–>RIP : EIGRP internals get tagged 12
• OSPF–>RIP : OSPF internals get tagged 110
• EIGRP–>OSPF : EIGRP internals get tagged 12
• RIP–>OSPF : RIP internals get tagged 120

Everything gets tagged, or gets to keep its existing tag. 

I prefer to set redistribution metrics inside the route-map rather than as a default or in the redistribute command.  It is more granular and controllable. 

OSPF and EIGRP have tools to distinguish internal prefixes: match route-type internal.  RIP does not.  How can we distinguish the RIP native prefixes from its externals?  Most NMC answers do this with an access list or prefix list.  I prefer to do it by match tag 0.  They must be RIP natives because they have not been tagged yet.

Since this router touches all three domains (EIGRP 12, RIP, OSPF) there is no point in any of these domains redistributing each others’ prefixes.  The only external prefixes taht need to be redistributed are EIGRP 34 prefixes from the transit domains (RIP and OSPF) to EIGRP 12.

There is an important point to make about “EIGRP 34 natives keep their tag”.  In this particular case, I could get away with:

match tag 34
  set metric 1500 50 255 1 1500

That is, the tag is automatically preserved as you redistribute.  But here is a “gotcha”: that does not apply to prefixes redistributed into RIP.  They lose the tag on the way, so the route-map has to regenerate it.  I make a habit of regenerating the tag in all cases anyway:

match tag 34
  set tag 34
  set metric 1500 50 255 1 1500

The situation at R3 is exactly the converse of R1:

• RIP–>EIGRP : RIP natives get tagged 120, EIGRP 12 natives keep thier tag.
• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 12 natives keep their tag.
• EIGRP–>RIP : EIGRP internals get tagged 34
• OSPF–>RIP : OSPF internals get tagged 110
• EIGRP–>OSPF : EIGRP internals get tagged 34
• RIP–>OSPF : RIP internals get tagged 120

I have treated R2 and R4 as warm-standby redistribution points.  Each has only two redistributions.  R4 is the converse of R2, which looks like this:

• OSPF–>EIGRP : OSPF internals get tagged 110, EIGRP 34 natives keep their tag.
• EIGRP–>OSPF : EIGRP internals get tagged 12

Note that the diagram does not show “EIGRP 34 natives keep their tag”, except as “OSPF ext ?”.  This is because I added it as a refinement during testing.

Administrative Distances at Border Routers

Once I have decided what to redistribute at the active border routers, I then have to look at the routes on the border routers themselves.  This includes both the active border routers (i.e. ones that are doing redistribution) and passive border routers (i.e. ones where two or more routing protocols meet, but that are not doing any redistribution).  The routes at the border routers can be optimised using the Administrative Distances.

Let us look first at the ADs on R1.  I have:

• 90 = EIGRP 12 internal prefixes (default)
• 110 = OSPF internal prefixes (default)
• 120 = RIP prefixes, and EIGRP 34 prefixes via RIP (default)
• 130 = OSPF external prefixes (EIGRP 34 prefixes via OSPF)
• 170 = EIGRP external prefixes (from R2 via EIGRP)

The last of these is the only one that needs to be configured explicitly: distance ospf external 130.  This ensures that R1 uses RIP to get to the EIGRP prefixes rather than going through OSPF, and also ensures that the RIP prefixes do not get dispaced out of R1’s routing table by the same prefix as an OSPF external.  The rest are defaults.  None of the AD=170 prefixes will find their way into the forwarding table unless somethong is broken, because there will always be a better route.

On R3, we have exactly the converse:

• 90 = EIGRP 34 internal prefixes
• 110 = OSPF internal prefixes
• 120 = RIP prefixes, and EIGRP 12 prefixes via RIP
• 130 = OSPF external prefixes (EIGRP 12 prefixes via OSPF)
• 170 = EIGRP external prefixes (from R4 via EIGRP)

Now to look at R2.  As I have already said, R4 is just the converse of R2.  These are the ADs that I chose on R2:

• 90 = EIGRP 12 internal prefixes
• 110 = OSPF internal prefixes
• 170 = EIGRP external prefixes (EIGRP 12 and RIP prefixes via R1) 
• 180 = OSPF external prefixes (EIGRP 12 and RIP prefixes via OSPF)

By putting the OSPF external prefixes down at 180, R2 will prefer to go through EIGRP over the same external prefixes over OSPF.

So, that’s my design for the redistribution scenario.

Additional Challenges

The scenario AK throws out some additional challenges.  The first is “How would it complicate matters if the loopbacks on R6, CAT1 and CAT2 were redistributed into EIGRP as connected routes?”  So let’s try.  Instead of reconfiguring Lo106, I am going to add Lo116 141.11.116.1/24.

As I have been careful about what I redistribute, I am going to have to add it to the route maps EIGRP–>OSPF and EIGRP–>RIP on R1 and R2.  So I shall tag it with 116 as I inject it into EIGRP in the first place, and then use the tag to insert it into the route-maps.  When passing it into RIP and OSPF, I shall re-tag it as 12 because it is effectively part of EIGRP by proxy.

First, let me predict what will happen.  I think the route will get redistributed into OSPF on R1 and end up at AD=180 on R2.  That is fine, because it will have an AD of 170 within EIGRP.  It will also get redistributed into OSPF on R2, and end up on R1 with an AD=130.  That is not so fine, because it means that R1 will prefer to go though OSPF and R2 to get to it.  That is exactly what happened:

R1#show ip route 141.11.116.0
Routing entry for 141.11.116.0/24
  Known via "ospf 11", distance 130, metric 20
  Tag 12, type extern 2, forward metric 64
  Redistributing via eigrp 12, rip
  Last update from 141.11.10.2 on Serial0/0.10, 00:01:38 ago
  Routing Descriptor Blocks:
  * 141.11.10.2, from 141.11.102.1, 00:01:38 ago, via Serial0/0.10
      Route metric is 20, traffic share count is 1
      Route tag 12

The problem is that we have redundant border routers between EIGRP and OSPF.  They should be told not to use each others’ redistrubuted routes.  What I would like to do is this:

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#router ospf 11
R1(config-router)#distance 180 141.11.102.1 0.0.0.0
R1(config-router)#exit
R1(config)#exit

That would tell R1 to treat any route that originated on R2 as AD=180.  The trouble is that it would also affect 141.11.102.1/24.  That means we would have to solve it by listing the prefix.  Ugh!

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#access-list 16 permit 141.11.116.0 0.0.0.255
R1(config)#router ospf 11
R1(config-router)#distance 180 141.11.102.1 0.0.0.0 16
R1(config-router)#^Z
R1#

R1#show ip route 141.11.116.0
Routing entry for 141.11.116.0/24
  Known via "eigrp 12", distance 170, metric 537602560
  Tag 116, type external
  Redistributing via ospf 11, eigrp 12, rip
  Advertised by ospf 11 subnets route-map EIGRP-->OSPF
  Last update from 141.11.16.6 on FastEthernet0/0.60, 00:00:19 ago
  Routing Descriptor Blocks:
  * 141.11.16.6, from 141.11.16.6, 00:00:19 ago, via FastEthernet0/0.60
      Route metric is 537602560, traffic share count is 1
      Total delay is 1000100 microseconds, minimum bandwidth is 5 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
      Route tag 116 R1#show ip route 141.11.102.0
Routing entry for 141.11.102.0/24
  Known via "ospf 11", distance 110, metric 65, type inter area
  Redistributing via eigrp 12, rip
  Advertised by eigrp 12 route-map OSPF-->EIGRP
                rip route-map OSPF-->RIP
  Last update from 141.11.10.2 on Serial0/0.10, 00:00:26 ago
  Routing Descriptor Blocks:
  * 141.11.10.2, from 141.11.102.1, 00:00:26 ago, via Serial0/0.10
      Route metric is 65, traffic share count is 1

But yuk!  An access-list!  Now, I have always said that what I would really like to do is to determine the AD of a route according to its tag.  This is an example where it would have been useful.  I should be able to tell R1 “If OSPF tells you about external routes with a tag of 12 (or perhaps 116), then mark them down to AD=180 because you should already have a better route to them via EIGRP.”

Frame-Relay multipoint or physical interfaces

 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.

Static neighbors

I’ve just realised I didn’t publish yesterday’s posting.  I’m still getting used to this blogging lark, and I must have clicked “Save” instead of “Publish”.  Anyways, it’s there now.

I’ve got a 3 a.m. bout of insomnia, so I’ve just done some experiments with the routing protocols and static neighbors.  Each protocol behaves differently.  I am too tired to write up the experiment fully, but here are the conclusions:

RIP: When you configure a static neighbor, RIP continues to multicast on the network as well as sending unicasts to the neighbor.  If you configure passive-interface, the unicasts can penetrate the wall, but the multicasts are blocked.

 EIGRP: When you configure a static neighbor, EIGRP stops sending multicasts on the network, replacing them with the unicast.  If you configure passive-interface, it blocks the unicast as well.  Moreover, you cannot mix static and multicast between two neighbors; that is, you cannot configure a static neighbor on one side and the neighbor still sending multicast. They just don’t form the adjacency.

OSPF does not allow static neighbors except in non-broadcast networks, i.e. NBMA or P2MP-NB.  In that case, the multicasts are switched off anyway.  passive-interface will block the unicasts as well.  If you have a broadcast network, the only thing you can use the neighbor command for is to modify the cost for that neighbor.

Now I’m going back to bed.