Kevin Dorrell, CCIE #20765

27 May 2008

“Still to do” list

Filed under: EIGRP, General, HSRP, IP Routing Protocols, OSPF, Spanning-Tree Protocol, VTP — dorreke @ 10:00

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.

16 Mar 2008

NMC Lab12 : Redistribution OSPF–>EIGRP

Filed under: EIGRP, IP Routing Protocols, OSPF, Redistribution — dorreke @ 17:44

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.
 

14 Mar 2008

NMC Lab 11 : Redistribution

Filed under: EIGRP, IP Routing Protocols, OSPF, Redistribution, RIP — dorreke @ 05:23

Here is my redistribution diagram:

NMC Lab 11 Redistribution

 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.”

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.

25 Feb 2008

NMC Lab 09 – The Golden Moment

Filed under: IP Addressing Services, OSPF, Redistribution — dorreke @ 23:48

It’s week 9, so I’m doing NMC Lab 09.  This time I think I have reach the full reachability as fast as I can: 2 hours and 20 minutes.  I was cautious – maybe over cautious – about the redistribution, only redistributing internal routes of each protocol.  (Except for RIP, which is out on a limb and therefore can be redistributed blindly.)  Of course, that left me with a lot of redistributing connected, but that was allowed by the scenario.

R4-Lo104 was the joker in the pack, because there were no instructions.  I redistributed it into both OSPF and EIGRP just for good measure.  I then looked at R3 and decided the 104 subnet would be better handled by EIGRP than OSPF.  In fact, if the R3 chooses the OSPF route to Lo104, then R6 never sees it.  So I punished every OSPF LSA coming from R4 with distance 180 172.16.104.1 0.0.0.0 at R3.  (The 172.16.104.1 being the router ID of R4 … it is only coincidence that it is also the subnet we are trying to manipulate.)  Probably would have been easier if I had just sent it into EIGRP and not to OSPF.

I suspect they wanted me to put the R2-R5 link into OSPF area 12, and use the R2-S1/0 address for the unnumbered reference on the Tunnel.  So just to be perverse, I didn’t do it that way.  Insead, I based my tunnel on R1-L101 and R2-L102, and I activated the OSPF on it with the interface command ip ospf 9 area 12.  That left me free to use whatever area I chose for the R2-R5 link.  I chose area 25, and made a string of virtual links across area 25 and area 51.

 There is something that makes me want to put a virtual link between R1 and R2 across area 12 to leverage that nice fast Ethernet segment rather than going through the Frame Relay.  I’ll bear that in mind if there is any RPF issue in the multicast.

More tomorrow.  The IPv6 and Cat 3560 sections look a bit heavy.  But it’s late now, the rest of the family are in bed already (one with ‘flu) and I need my sleep.

11 Feb 2008

Static neighbors

Filed under: EIGRP, IP Routing Protocols, OSPF, RIP — dorreke @ 03:52

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.

Blog at WordPress.com.