I have to admit, I’m pretty frustrated right now. It’s 11:30 at night…here I sit. I’ve spent the last 2 nights working on IPexpert Volume 1 Lab 11: BGP. I knew it was coming, dreaded it, feared it, and decided to just jump in, the water was warm!

I was in for the beating I expected. Still, after a rough first night, and spending most of today pondering a particular problem I just was not grasping, I finally understood it. I was about halfway through the lab and pretty much understood everything — Until tonight.

Is it just me, or is anybody else out there having occasional “issues” with the startup-configurations provided to you from IPexpert? I’ve noticed this before, but didn’t say anything because frankly hey it is a lot of information and there are bound to be tiny mistakes. But tonight seemed to present some fairly large issues. I mean here I am plowing through this material, I have enough things to worry about without having to worry about my configurations that I’m supposed to be learning from all jacked up. I’ll try to explain this.

grrrrrrrr…. a network diagram is necessary. Let me go make one quick…

So here is the deal… first off I should mention all routers have a loopback that is advertised into BGP of 200.0.0.x where x is the router number. simple enough. Also, R2,R5,R6 are a frame-relay cloud, whereby R2 is the Hub. Also, the diagram above shows BGP links, not physical links necessarily.

So I am about halfway through this lab, and I start pinging around for reachability to all my loopbacks. I am on R1 trying to ping (R9’s loopback). It doesn’t work. I do a traceroute, and discover I have a routing loop. The packet goes from R1 to R2 to R5 to R2 to R5 to R2 …..OK what’s going on here?

The neighbor on R5 to R2 is set for next-hop-self. This was part of the lab solution, because without it we had no reachability to R7,R8, and anything injected via BB2. So, R9 advertises via eBGP to R6. The neighbor relationship between R6 and R5 is also set for next-hop-self. So, now R6 sends the route to R5. R5 gets the route to, next hop R6. No problems. R5 advertises to R2 with next-hop-self. Now R2 has a route to next hop R5. Great.

So lets take this from the perspective of pinging from R2 to R9. On R2 you ping…OK it is in my routing table, next hop R5, send to R5. R5 gets the packet, looks at the destination IP address of…see’s that is in it’s routing table, next hop R6. Here is the problem — R5 now does a recursive route lookup for the next hop address of R6. R5 and R6 are both spokes in a frame-relay cloud and R2 is the hub. For R5 to send to R6 is HAS to go to R2 (No spoke/spoke PVCs here boys!) R5 sends to R2, and boom we have a loop.

I beat my head into the wall for a good part of today going over the proctor guide, trying to see had I missed something? Have I gone insane?! Finally, I loaded the “final configurations” given by IPexpert and reloaded.

To my horror, after loading the “final configurations”, upon reboot I had a serious issue between R5 and R6. They were both complaining of “BGP identifier wrong” coming from the other side…as a 32 bit number (weird!) So I checked the ASNs configured on both ends, as well as the neighbor commands…all looked good. So the problem was that there was a task somewhere in this lab that told you to configure the same loopback addresses on both routers and advertise them into BGP (They were all /24 loopbacks). When the routers reboot, these loopbacks were the highest ones on the routers, and thus became the BGP RID. Both routers therefore had the same RID. None of this was mentioned in the lab solutions at all.

So after all that hoo-ha , the moment of truth… I am on R2 and attempt to ping R9 after loading the final configurations given to me…nothing. Same exact problem (routing loop). So, I had not missed something, it was just flat out wrong (if they expected full reachability). At this point I was pretty much too frustrated to continue for the night.

I did however play around a little more just for shits and giggles. So I did a little playing around on R5 just to see if I could make it work

access-list 101 permit host
access-list 101 permit host

route-map wtf 10
match ip address 101
set ip next-hop

router bgp 64513
neighbor route-map wtf in

clear ip bgp

Poof…reachability to R9 from R1 : )

*UPDATE* ….so how could I make this work for ANY networks advertised to R5 with a next hop of R6 ? The newest solution, quite a bit more scalable below! So this as-path access-list matches anything learned from subAS 64514. the \ characters are used in the regular expression to escape the parens…not sure if it is technically required or not, but this does work! So, now anything that R6 sends to R5 with next hop of R6 will be changed to a next hop of R7. So basically anything learned from R6 at R5 will now go back to R6 via the ethernet link to R7 instead of over the frame, thus defeating the evil loop issue.

ip as-path access-list 19 permit ^\(64514\)_

route-map wtf 10
match as-path 19
set ip next-hop

Wow, kind of a long post tonight. So what’s the point? I guess I just wanted to bitch a little about something 🙂 This lesson has just been a bit frustrating so far. I knew BGP was going to be a struggle for me, because I have really only read about it before, but I was not expecting major problems from the study material out of the box. The other day during OSPF I had a similar issue with the startup configurations…as in major issues that I had to go in and dick with to get the practice scenarios given to work properly. For instance, sometimes there have been things missing in the startup configurations that are needed, yet those commands are not given in the solutions guide…but then are magically in the final configurations given.

Well, if nothing else, it is now 12:15 AM, I’ve plowed heavily into BGP for 2 nights now…although much of this fooling around has been due to what I perceive here as errors in the study material, at least it has been time spent on a router, and at least I have learned something and understand WHY it is broken, and was even able to make it work.


Joe A