Kevin Dorrell, CCIE #20765

01 Apr 2008

NMC Lab 14

Filed under: IPv6, LAN Switching, NAT, RIP, Security — dorreke @ 22:10

Busy busy busy, so I only have time for a few notes which I hope I shall expand later.¬† Just to punish myself for my mistakes … ūüôā

  • 14.4.1 : RIP : I read too much into the requirements.¬† I read 14.4.1 as¬†meaning that I should set up neighbor relations R2<–>R6<–>R4, but not R2<–>R4.¬† Then I wondered why¬†there was nothing in the requirements about the route from R2 to 172.16.104.1 and from R4 to 172.16.102.1.¬† (Of course, the answer would have been no ip split-horizon on R6-F0/0.)¬†¬†But it seems I “spotted an issue” that wasn’t there in the first place!¬†
  • 14.8.1 : Security : I’m just going to have to sit down and read the Command Reference for all those itty-bitty security commands.¬† Boring or what!
  • 14.9 : IPv6 : Don’t mess about thinking “can I get away without specifying link-local addresses”.¬† In a frame-relay configuration, they are absolutely essential so that you can set frame-maps to them.¬† Do them as a matter of course.¬† Oh, and¬†the pseudo-broadcast should only go to the link-local at the other end of the DLCI, not to any of the others.¬† I wasted an hour on the IPv6 section that should have taken me half that time.
  • 14.10.2 : Layer-3 access list on Catalyst layer-2 port.¬† This can be done; I know because I do it all the time on my 4500 switches at work.¬† What I am a bit puzzled at here is that the access-lists don’t seem to be counting packets.¬† My first attempt didn’t include return traffic for telnet, so I know the access-list is working.¬† So why doesn’t it count packets?
  • 14.11.2 : NAT : ip nat source list 11 pool IG overload will not do instead of ip nat inside source list 11 pool IG overload. I’m not sure what it does without the “inside” keyword, but it does accept the command, and it doesn’t do the job I wanted it to.¬† Careful!
Advertisements

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.

20 Feb 2008

NMC Lab 8

Filed under: BGP, Frame Relay, IP Routing Protocols, PPP, Redistribution, RIP, WAN — dorreke @ 14:31

Took a day out of work today to see what I could get out of Lab 8.  Once again, the lab caught me unawares in several places.  Here are some of the lessons:

8.1.4. PPP over Frame Relay

I had not done a PPP over Frame Relay before.  It is an interesting technique involving configuring a Virtual-Template interface that then spawns a Virtual-Access interface when it connects.  Here for the Cisco Configuration guide.

One configuration “gotcha”¬†caught me out.¬† I have tripped over so many “gotchas” in the past that I have decided to make a list of them (top right, under “pages”) and write a small posting on each.

It is interesting that the example in the Cisco doument has three levels of interface: a physical interface, a point-to-point subinterface that defines the DLCI, and the PPP Virtual-Template.  The NMC answer key has only two: they go straight from the physical interface to the Virtual-Template.  Pros and Cons of each approach? 

One thing I did not manage to do: to get R3 and R4 to ping their own addresses on the PPP link.¬† They could each ping their partner’s address, but not their own.¬† I spent a long time trying to get this to work before giving up and looking at the AK.¬† Then I find that their solution doesn’t reach those addresses either.¬† They might have said so!¬† I have asked the question on the DISCUSSiT forum, but there seems to be less and less activity there.

Redistribution into RIP

Beware any border router that has two interfaces in the RIP domain; there could be an internal¬†loop within the RIP domain.¬† In particular, beware of injecting any external route that has an AD more than 120.¬† The injected route will go round the loop, and appear at the other interface with a greater hop count, but an AD of 120, where it will overwrite the original injected route.¬† The route can thrash.¬† Or not … if you are lucky, the updates will go both ways round the loop and meet on some other non-border router, where they are safe.¬† There is a similar lesson in Lab 23, but with a rather simpler loop.

8.7. BGP

I have already had a good rant about the apalling contradictory requirements of this section.  Now I must concentrate of what I can learn from this section:

  • A BGP speaker, even if a route reflector, will not send a prefix to a neighbor that is in that same cluster as the one he learned it from.¬† The scenario leverages this behavior in an unusual way by deliberately using the feature to break reachability.
  • A¬†route reflector will not touch next-hop information.¬† Eeven if it has next-hop-self configured, that does not apply to reflected routes.¬† (The scenario was not intended to teach that but a screw-up in my topology led me down that path.)
  • Interestingly, because next-hop is not touched as the route propagates along the AS 100 chain, the traffic itself takes a shortcut CAT1-R3-R4-CAT2.

I implemented the solution proposed in the AK, and it seemed to work OK.¬† Then, just to be perverse, I looked around for other solutions that ignored¬†various bits of the requirements.¬† (Well, their solution ignores requirement 8.7.4., so I felt at liberty to keep 8.7.4 and to ignore something else instead.)¬† BTW, this section won’t make much sense unless you have the scenario in front of you.

I thought I would try peering R3-CAT2 and R4-CAT1.  That should inject the routes into AS 100 by two different ways, and is not expressly forbidden by the scenario.  My problem was which addresses to peer.  I had no luck peering the loopback addresses, because those have multiple paths, some going back the way you came.  I tried peering with the addresses on the 172.16.34.0/24 link, but had not luck with that either.  For some reason it does not like peering from a Virtual-Template address:

R3# 
Feb 20 15:57:15.760: BGP: 172.16.46.20 active open failed - update-source Virtual-Template1 
is not available, open active delayed 25730ms (35000ms max, 28% jitter)

So, I settled on these peerings:

  • CAT1 (172.16.38.10) <–> R4 (172.16.46.4)
  • CAT2 (172.16.46.20) <–> R3 (172.16.38.3)

Really perverse, I know.¬† It almost worked as well.¬† The only thing that didn’t work was that if I take down the peering R5<–>R3, then R5 can no longer reach 100.100.100.1.¬† Conversely, if I take down the peering R2<–>R4, then R2 can no longer reach 200.200.200.1.¬† R2 is rejecting the route to 200.200.200.0/24 because it has the same cluster-id.¬† Or maybe FRS is not sending it, I’m not sure.

I’ve had enough of this BGP scenario for now.¬† If I get time I shall try some other techniques.¬† I thought of making AS100 a confederation with a different AS on each router in the chain, and give R2 and R5 the same AS number.¬† That should do the 8.7.7. trick.¬† Another possiblity is to mark the route with a community that would make R2 / R5 drop it.¬† But that’s enough for now.

8.8. VPN

Got this bit OK, but 20 minutes was a little longer than I should have taken over it.  I must be geting tired.  The issue was to keep the infrastructure RIP routes seperate form the VPN RIP routes in R3.  (I thought they were going to implement virtual routers at some point?)  They defined the infrastructure routes as everything except the sepcific VPN routes.  I defined the infrastructure as 172.16.0.0/16 and the VPN as 10.10.0.0/16.  Six of one and half-a dozen of the other I suppose.

 

 

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.

Create a free website or blog at WordPress.com.