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 200.0.0.9 (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 200.0.0.9 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 200.0.0.9, next hop R6. No problems. R5 advertises 200.0.0.9 to R2 with next-hop-self. Now R2 has a route to 200.0.0.9 next hop R5. Great.

So lets take this from the perspective of pinging from R2 to R9. On R2 you ping 200.0.0.9…OK it is in my routing table, next hop R5, send to R5. R5 gets the packet, looks at the destination IP address of 200.0.0.9…see’s that 200.0.0.9 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

R5
——
access-list 101 permit host 200.0.0.6
access-list 101 permit host 200.0.0.9

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

router bgp 64513
neighbor 150.100.100.6 route-map wtf in

clear ip bgp 150.100.100.6

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 200.0.0.7

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.

Regards,

Joe A

Comments

4 Responses to “BGP, Frame-Relay, Confederations, And Loops — OH MY!!!”

  1. Caue Wailemann on November 7th, 2008 6:17 am

    Hey buddy! Long time I dont speak to you! How is everything?! Fine I hope!!!! :)

    Hmmm… I just did a few labs, and the ones I did I just got some diagram issues, not the configs, but if you had, when I finally get to lab 10, 11 I will have the same issue…

    One question, have you downloaded the Updated version of Vol. 1 workbook from IPExpert site?!

    One other thing we could do is to post the problem at OnlineStudyList, normally Tyson or Jared solves all the problems quickly… at least when I needed they answered me! :)

    Anyway, congrats for your patience and hard working! You will be ready to face the “beast” very soon buddy!

    Cheers man!

    Caue Wailemann

  2. CCIETalk.com on November 7th, 2008 9:59 am

    OK. I read briefly but couldn’t make much sense out of it and would like to see your configs. BGP confederations are not that bad but make sure you take it one step at a time.

    I am not working with IPexpert WBs so I can’t reference anything here but if you want to discuss this with me shoot me an email and I will be more than happy to work with you :) Even though I suck at BGP and got 40s on my Mock Labs :(

  3. Joe A on November 7th, 2008 10:32 am

    Hey Caue! Nice to hear from you. Yeah, I have the latest configurations released in October.

    What I do when I am ready to do a lab is take the startup configurations provided, and I go in and tweak down each one for my own home lab interface numbers. I also remove lines like “speed” and “duplex” if it is just a plain Ethernet interface and not FastEthernet. Then I save all those to a new folder I call “custom” and upload them to my tftp server. Then I write erase all my devices, and pull the configs down and I am ready to go!

  4. Joe A on November 11th, 2008 3:43 am

    I’d like to update this by saying if you use the direct serial interface links between R2/R5 instead of the frame-relay, which in retrospect I guess should be sort of assumed since they tell you to add the direct serial link to BGP and not the frame, that this entire loop problem goes away :)

    Doh!

Leave a Reply