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.
