We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is Why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 580 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

 

295 New Members signed up the last 30 days!

satisfaction-guaranteed

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags:


Forum Replies

  1. >show ip route
    Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
           I - ISIS, B - BGP, > - selected route, * - FIB route
    
    B>* 10.1.1.0/24 [200/0] via 10.2.2.2, eth1, 00:00:11
    C>* 10.2.2.0/24 is directly connected, eth1
    ...
    
    >show bgp
    BGP table version is 0, local router ID is 10.5.5.5
    Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
                  r RIB-failure, S Stale, R Removed
    Origin codes: i - IGP, e - EGP, ? - incomplete
    
       Network          Next Hop            Metric LocPrf Weight Path
    *>i10.1.1.0/24      10.2.2.2                 0    100      0 i
    * i10.2.2.0/24      10.2.2.2                 0    100      0 i
    *>                  0.0.0.0                  0         32768 i
    * i10.16.16.0/24    10.1.1.1                 0    100      0 i

    As you see we have a route to 10.16.16.0/24 in bgp table but not in routing table.
    Next hop is 10.1.1.1 and is not in directly connected network. But we have also a route to that network 10.1.1.0/24 learned via BGP. But the router doesn't make recursive lookup and just doesn't use this route.

    If i have static (or learned with ospf) route to 10.1.1.0/24 - all works great and route to 10.16.16.0/24 is insatlled in routing table.

    Please explain why this happens and how can i get route to 10.16.16.0/24 vith bgp only?

  2. Rene,

    If this has been answered by other members I apologize but following your example, the RR works as configured as R3 does learn about the 1.1.1.1/32 prefix but its not being installed in the routing table because it can not reach the next hop address of 192.168.12.1. To resolve this I added the next-hop-self command on R1 and reset the BGP peerings. That still did not resolve this.

    My question is once a RR is configured should all the clients update their next hop to the RR or should the originator of the prefix have the next-hop-self configuration?

    R3#sh ip bgp 1.1.1.1
    BGP routing table entry for 1.1.1.1/32, version 0
    Paths: (1 available, no best path)
      Not advertised to any peer
      Refresh Epoch 2
      Local
        192.168.12.1 (inaccessible) from 192.168.23.2 (192.168.23.2)
          Origin IGP, metric 0, localpref 100, valid, internal
          Originator: 1.1.1.1, Cluster list: 192.168.23.2
          rx pathid: 0, tx pathid: 0

    -

    R1#sh running-config | section router bgp
    router bgp 123
     bgp log-neighbor-changes
     network 1.1.1.1 mask 255.255.255.255
     neighbor 192.168.12.2 remote-as 123
     neighbor 192.168.12.2 next-hop-self
  3. Using the "neighbor x.x.x.x next-hop-self all" command on RR will solve the iBGP next-hop problems when using RRs.

    Below is the config i Labed and it just worked:

    Leaf1#sh run | sec bgp
    router bgp 1234
     bgp log-neighbor-changes
     network 10.1.1.0 mask 255.255.255.0
     neighbor 11.11.11.2 remote-as 1234
     neighbor 21.21.21.2 remote-as 1234
     maximum-paths ibgp 64

    Leaf2#sh run | sec bgp
    router bgp 1234
     bgp log-neighbor-changes
     neighbor 12.12.12.2 remote-as 1234
     neighbor 22.22.22.2 remote-as 1234
     maximum-paths ibgp 64

    Leaf3#sh run | sec bgp
    router bgp 1234
     bgp log-neighbor-changes
     network 10.2.2.0 mask 255.255.255.0
     neighbor 13.13.13.2 remote-as 1234
     neighbor 23.23.23.2 remote-as 1234
     maximum-paths ibgp 64 #ECMP

    Spine1#sh run | sec bgp
    router bgp 1234
     bgp log-neighbor-changes
     neighbor S1_L1_L2_L3 peer-group
     neighbor S1_L1_L2_L3 remote-as 1234
     neighbor S1_L1_L2_L3 route-reflector-client
     neighbor S1_L1_L2_L3 next-hop-self all
     neighbor 11.11.11.1 peer-group S1_L1_L2_L3
     neighbor 12.12.12.1 peer-group S1_L1_L2_L3
     neighbor 13.13.13.1 peer-group S1_L1_L2_L3

    Spine2#sh run | sec bgp
    router bgp 1234
     bgp log-neighbor-changes
     neighbor S2_L1_L2_L3 peer-group
     neighbor S2_L1_L2_L3 remote-as 1234
     neighbor S2_L1_L2_L3 route-reflector-client
     neighbor S2_L1_L2_L3 next-hop-self all
     neighbor 21.21.21.1 peer-group S2_L1_L2_L3
     neighbor 22.22.22.1 peer-group S2_L1_L2_L3
     neighbor 23.23.23.1 peer-group S2_L1_L2_L3

    Leaf1 : BGP and route table:

         Network          Next Hop            Metric LocPrf Weight Path
     *>  10.1.1.0/24      0.0.0.0                  0         32768 i
     *mi 10.2.2.0/24      21.21.21.2               0    100      0 i
     *>i                  11.11.11.2               0    100      0 i
    
          10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
    B        10.2.2.0/24 [200/0] via 21.21.21.2, 00:31:39
                         [200/0] via 11.11.11.2, 00:31:39
  4. andrew says:

    Udaya,
    In the case of a router's being a route reflector client of multiple route reflectors, the client will accept routes from all reflectors. In other words, all learned routes will be present in the BGP topology table. As far as which routes are selected as best routes, and installed in the routing table, the client will use the standard (and complex!) BGP best path selection algorithm.

  5. andrew says:

    Hey Ryan,
    The issue you are having is that while R1 knows about the BGP route to R3, it is not installing it into the routing table. You can verify this by going on to R1 and issuing a "show ip bgp" and look for the 192.168.0.0 route (it will be missing the ">" symbol).

    The reason R1 is not installing the route is due to BGP behaving differently than other routing protocols. BGP really isn't a true routing protocol in the way that OSPF or EIGRP are. BGP is more of an application that tells you WHERE to go to get to a network, but it does not tell HOW to get there. So, for example, BGP is telling R1 to get to 192.168.0.0/24, go to 2.2.2.2. It is up to R1 to figure out HOW to get to 2.2.2.2. In this case, R1 doesn't know how to get to 2.2.2.2.

    I suspect you know all of this, which is why you are trying to configure R2 to be a next-hop-self for R1. The problem with this solution is that, by default, BGP only modifies this attribute on routes it learns from external neighbors--not internal neighbors.

    So to solve this problem, you have four options:
    1) Configure R3 in a different BGP ASN than R2
    2) Configure R2 to advertise the 1.1.1.0/24 and 2.2.2.0/24 networks in BGP
    3) Configure either static routes or an IGP so that R1, R2, and R3 know about all the links connecting them
    4) If you have a late enough version of the IOS, R2 will have a new option of "neighbor 1.1.1.1 next-hop-self all" where this option allows the modification of either internally or externally learned BGP routes.

43 more replies! Ask a question or join the discussion by visiting our Community Forum