BGP issue has me stumped

Testing some different configuration options I decided to test an eBGP peering between R8 and R10, from CCIE v5 INE topology. On both routers, R8 BGP AS 200 and R10 BGP AS 54 per the workbook topology. Using OSPF on Routers 1-8.

 

R10:

 neighbor 150.1.8.8 remote-as 200

 neighbor 150.1.8.8 disable-connected-check

 neighbor 150.1.8.8 update-source Loopback0

R8:

 neighbor 150.1.10.10 remote-as 54

 neighbor 150.1.10.10 disable-connected-check

 neighbor 150.1.10.10 update-source Loopback0

Straightforward and simple, added a static route /32 on each router pointing to the peers loopback.

ip route 150.1.10.10 255.255.255.255 155.1.108.10

ip route 150.1.8.8 255.255.255.255 155.1.108.8 

I now have static routes in the IP routing table and the peering comes up as expected. All seemed well until I started the Route Relector section, following Brian's video, RR in the dataplane, R5 as the RR and out of the data plane on R2 as the RR. From R10 I couldn't trace to the 155.1.37.0/24 network, it died at R8. Ok Let's try the reverse path, traced to 150.1.10.10 from R3, dies at R8. Common denominator, R8 right? After some thought I advertised the connected 155.1.108.0/24 into BGP on R8 and now I can successfully trace to R3's .37 network from R10. Now for the reverse path, this is where I can't seem to figure out. I trace from R3 to R10 and die at R8, I then, just to see if it would work, advertised the .108 network into BGP. No dice, still die at R8. Mind you, after every modification I do a full clear of bgp both soft in/out and hard just see the differences (clear ip bgp * out/in). No dice, I checked the routing table,

I have a static host route on R8:S        150.1.10.10 [1/0] via 155.1.108.10,

also checked the CEF table: 150.1.10.10/32   nexthop 155.1.108.10 GigabitEthernet1.108 

Still nothing, R3's info: Sho ip bgp *>i 150.1.10.10/32   155.1.108.10             0    100      0 ?

The CEF table on R3 150.1.10.10/32   nexthop 169.254.100.5 GigabitEthernet1.100

Trace output:

R3#traceroute 150.1.10.10

Type escape sequence to abort.

Tracing the route to 150.1.10.10

VRF info: (vrf in name/id, vrf out name/id)

  1 169.254.100.5 4 msec 1 msec 1 msec

  2 155.1.58.8 2 msec 1 msec 1 msec

  3  *  *  *

R3#sh ip bgp 150.1.10.10

BGP routing table entry for 150.1.10.10/32, version 48

Paths: (1 available, best #1, table default)

  Advertised to update-groups:

     9

  Refresh Epoch 2

  Local

    155.1.108.10 (metric 3) from 150.1.2.2 (150.1.2.2)

      Origin incomplete, metric 0, localpref 100, valid, internal, best

      Originator: 150.1.8.8, Cluster list: 150.1.2.2

      rx pathid: 0, tx pathid: 0x0

Is this some stupid issue with CSR and diable connected check? Haven't found much on documentation on it.  Any ideas as to what I am missing? I'll be happy to add any info you request. I commonly test weird stuff like this and I have always been able to get it to work with minimal effort, this time I don't get it. I have also rebooted the CSR for R8 2 times, I had an issue previously and a reboot fixed the traces. 

Comments

  • Sometimes I wonder why I don't think of this stuff sooner, considering I have BGP and EIGRP running in my network now. I never redistributed BGP to OSPF and vice versa. I haven't gotten to the NLRI section yet of the ATC, I was stuck on the RR setup. Now I am able to successfully trace from R10 to R3 and vice versa. I've been beating myself up on this for over an hour. I also noticed that next to my info on the forums my points earned has granted me Expert status, so I guess I should have thought of all possible solutions rather than running up here for help. I now bid you all a good night of studying!

    Rob

  • Rob, sometimes beating your head against the wall on a problem is the only way to knock the solution loose.

  • That's funny. The really funny part of it is when I went back and did more digging, I then realized my error and corrected it worked. Like most of us studying for CCIE, you test weird configs so you don't get caught up in the lab.


    On Thursday, September 11, 2014 9:23 AM, dmowery <[email protected]> wrote:


    Rob, sometimes beating your head against the wall on a problem is the only way to knock the solution loose.



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx


  • Sometimes I wonder why I don't think of this stuff sooner, considering I have BGP and EIGRP running in my network now. I never redistributed BGP to OSPF and vice versa. I haven't gotten to the NLRI section yet of the ATC, I was stuck on the RR setup. Now I am able to successfully trace from R10 to R3 and vice versa. I've been beating myself up on this for over an hour. I also noticed that next to my info on the forums my points earned has granted me Expert status, so I guess I should have thought of all possible solutions rather than running up here for help. I now bid you all a good night of studying!

    Years ago, I read a book, perhaps it was "Practical C Programming". In it under the troubleshooting section, the author told the tale of perhaps himself going to a colleague and saying "Hey, I've got this program where I'm doing X, which results in Z, but I was expecting Y...oh wait, I got it, thanks!" - he referred to it as "confessional debugging", and let's just say I'm a HUGE fan of confessional debugging.

    So, when in doubt, run to the restroom and confess your challenges, since you probably shouldn't talk in the lab room. ;)

  • Really good advice. The funny part of that is I did go to the restroom, tucked my kids and wife into bed then took a 20 minute break to watch some TV. The entire time I'm crunching the issue in my head, what am I missing. As I was adding info to the forum to help you all help me out, it never hit me to check OSPF reachability to an eBGP peering. Then like a smack to the back of the head I remember hearing Brian mention the OSPF Database, do you see an entry for the route you're trying to reach and then it hit me. I did a debug ip routing on R3 and then did mutual redistribution on R8 and checked R3 had a ton of debugs with the routes I was missing. I redid the trace and bam I had reachability and the OSPF database had entries for the missing routes. I was like "hot dog I figured it
    out!" But I like the confessional debugging to figure out the problem. I guess you could say to some extent that I am an expert, I just need to think about the protocol operations before I go cry wolf.


    On Thursday, September 11, 2014 11:33 AM, peety <[email protected]> wrote:


    image rriker:

    Sometimes I wonder why I don't think of this stuff sooner, considering I have BGP and EIGRP running in my network now. I never redistributed BGP to OSPF and vice versa. I haven't gotten to the NLRI section yet of the ATC, I was stuck on the RR setup. Now I am able to successfully trace from R10 to R3 and vice versa. I've been beating myself up on this for over an hour. I also noticed that next to my info on the forums my points earned has granted me Expert status, so I guess I should have thought of all possible solutions rather than running up here for help. I now bid you all a good night of studying!

    Years ago, I read a book, perhaps it was "Practical C Programming". In it under the troubleshooting section, the author told the tale of perhaps himself going to a colleague and saying "Hey, I've got this program where I'm doing X, which results in Z, but I was expecting Y...oh wait, I got it, thanks!" - he referred to it as "confessional debugging", and let's just say I'm a HUGE fan of confessional debugging.

    So, when in doubt, run to the restroom and confess your challenges, since you probably shouldn't talk in the lab room. ;)



    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx


  • Getting up and walking away for 5 min is almost always good practice IMO/IME.  I started using a "pomodoro" timer app a while ago to try to force myself to work for 25 min and get up and wal around for a few min.  It has the added (huge) benefit of getting you out of your chair.

  • "confessional debugging"

    And you didn't have to visit a priest :-)

Sign In or Register to comment.