BGP Next-Hop Processing - Manual Modification (V5)

Hi all,

this could be stupid question but i really want to ask.

in the lab " BGP next-hop Processing - Manual Modification"  why i am able to ping the prefix learned from the AS 54 from ibgp internal loop back address.  why packets are being dropped when pinging from other interface.

i really need to know the trick before i move on.

Comments

  • So the thing you must realize is that Ping is testing both sides of the path. Obviously you have a route to the destination because it works when you source it from Lo0. The  question is do you have a route from the destination back to the source when it is using an interface other than Lo0? 

  • even if you have IGP route but if it's still same route is not being advertised in bgp is not going to work ?

    yes, i only have "

    R#7

    router bgp 100
     bgp log-neighbor-changes
     network 150.1.7.7 mask 255.255.255.255
     neighbor 155.1.79.9 remote-as 54
     neighbor 155.1.146.1 remote-as 100
     neighbor 155.1.146.1 route-map NHS out
    ===========

    R9#sh run | s bgp
    router bgp 54
     bgp log-neighbor-changes
     network 150.1.9.9 mask 255.255.255.255
     network 160.1.9.9 mask 255.255.255.255
     neighbor 155.1.79.7 remote-as 100

     

    so i was able to ping from loopback"150 .

  • What does your routing table look like? All hops along the path (in both directions if asymmetric ) needs to have a route for the destination (source on the return path)

  • Hi Ahmed and All,

    "even if you have IGP route but if it's still same route is not being advertised in bgp is not going to work ?"

    Does IGP extend end-to-end from R7 to both AS54 routers?  If not, then routing is dependent on BGP protocol between AS 100 and AS 54; then only BGP advertised networks see return traffic. This is common between two bgp domains.  Never advertise your infrastructure!

    for example:  R7.AS100 -- R6.AS100 -- BB1.AS54 -- BB2.AS54

    BB2 only sees bgp networks advertised by R7 (for example an http server).  The nexthop for these prefixes is R6's address on link R6 -- BB1. BB2 doesn't need to know any infrastructure addresses within AS 100; only needs to know how to get to R6 -- BB1 link.

    how about this for troubleshooting: 

    1) If ping from R7 lo0 to AS54 works; and if

    2) ping from R7 Et interface to AS54 doesn't work; then

    3) traceroute from R7 Lo0 to AS54; if successful, then

    4) traceroute from R7 Et to AS54; should break; where it stops is last router with return path

    Please advise if above looks ok or not//RandyB

  • I am using sINE "BGP Next-Hop Processing - Manual Modification" example.

    so config is same as it is asked to make sure "ensure full IPv4 reachability to Loopback0 prefixes from all internal
    devices, and to all prefixes learned from AS 54 from R1 - R8 when
    sourcing traffic from Loopback0 interfaces."

    so from the loop back is OK. but if you know the config you can have idea .

    from the example i am able to achieve what was asked. just trying to get more expertise on it .WHY?

  • NHS is the route map to configure to set next hop ip. instead on using neighbor x.x.x.x next-hop-self.

  • Here is my best attempt at trying to convey why. I loaded up this lab with the provided solution. In the example I will be pinging from R1 towards one of the interfaces of R9.

     

     

     

    R1#ping 114.0.0.1 so lo0

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 114.0.0.1, timeout is 2 seconds:

    Packet sent with a source address of 150.1.1.1 

    !!!!!

    Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/8 ms

     

    R1#ping 114.0.0.1       

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 114.0.0.1, timeout is 2 seconds:

    .....

    Success rate is 0 percent (0/5)

     

     

     

    So same behavior that you are describing.

     

     

     

    Lets look at why.

     

     R1#traceroute 114.0.0.1 source lo0

    Type escape sequence to abort.

    Tracing the route to 114.0.0.1

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

     1 155.1.146.6 2 msec 2 msec 2 msec

     2 155.1.67.7 3 msec 3 msec 4 msec

     3 155.1.79.9 4 msec *  3 msec

     

     

     

    R1#traceroute 114.0.0.1           

    Type escape sequence to abort.

    Tracing the route to 114.0.0.1

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

     1 155.1.146.6 1 msec 2 msec 2 msec

     2 155.1.67.7 3 msec 2 msec 2 msec     <--- Here we can see that R7 is the last router that has a route back to R1 g1.146 interface

     3  *  *  * 

      4  *  *  * 

     

     

     

    So lets take a look there.

     

    R7#sh ip route 155.1.146.1       

    Routing entry for 155.1.146.0/24 <—— Here we can see R7 has an IGP route to R1’s interface

     Known via "eigrp 100", distance 90, metric 3072, type internal

     Redistributing via eigrp 100

     Last update from 155.1.67.6 on GigabitEthernet0/1.67, 00:13:27 ago

     Routing Descriptor Blocks:

      * 155.1.67.6, from 155.1.67.6, 00:13:27 ago, via GigabitEthernet0/1.67

       Route metric is 3072, traffic share count is 1

       Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit

       Reliability 255/255, minimum MTU 1500 bytes

        Loading 1/255, Hops 1

     

     

    R9#sh ip route 155.1.146.1

    % Subnet not in table      <—— Here is the reason why R9 will not respond to traffic when sourced from an interface other the Lo0 of R1

     

     

    To fix this, we have a couple of options. 

    1. Advertise from R1 155.1.146.0/24 into BGP

    2. Advertise an aggregate from R7 suck as 155.1.0.0/16

    3. Advertise a default from R7

    4. Set a static on R9.

     

    Ultimately the issue is that because the prefix is not advertised into BGP combined with the fact that R9 is not participating in the IGP domain, R9 does not know where to route the echo reply and is why the pings fail when sourced from an ethernet interface. 

     

     

    Hope this helps

     

     

     

  • Hi Ahmed and All,

    After looking at my previous post, I can see why it is a poor explanation.  Please consider the following.  First step is to evaluate interior connectivity; then consider the interaction between AS 54 and AS 100.

    " why i am able to ping the prefix learned from the AS 54 from ibgp internal loop back address.  why packets are being dropped when pinging from other interface."

    First note that eigrp is not advertising the 150.1.0.0/16 network, only advertising the 155.1.0.0/16 network.

    R9 , R10 (AS54) <---eBGP---> AS  100

    1)  Loopback to Loopback connectivity within AS100:

    Eigrp 100 is providing full connectivity within AS 100 for network 155.1.0.0/16 (with the exception of demarcation links between AS 54 and AS 100).

    BGP 100 is advertising 150.1.0.0/16

    iBGP using a single route reflection cluster; R1 is the route reflector

    R2 through R8 will advertise their 150.1.x.x address to R1.  R1 is a route reflector, and reflects these updates to all others.  The nexthop attribute is set to a physical interface address.   That is, iBGP session endpoint addresses of R2 through R8.  show tcp brief  on R2 through R8

    These nexthops are being advertised by eigrp.  We get full connectivity within AS100 for its iBGP advertised 150.1.0.0/16 routes.

    2)  AS 100 150.1.0.0/16 advertisement to AS 54:

    R7 to R9 have an eBGP session across link.  At every eBGP session, the nexthop is always reset to the peering address.  That way the adjacent AS knows how to reach the received routes.  Just send to the router that I am peering with.

    R7 sets the BGP nexthop to its peering address 155.1.79.9.

    R9 knows how to reach all AS 100's 150.1.x.x addresses; send to R7.

    Example:  R9  Route table:   150.1.7.7 255.255.255.255    G1.79 155.1.79.7

    3)  AS 54 networks to AS 100:

    R9 advertises 112.0.0.0/8 to R7 and sets NextHop to its peering address with R7; 155.1.79.9

    R7 knows how to reach 112.0.0.0/8; send to R9

    But wait!  Requirements state that R7 must change this NextHop address to an EIGRP routed address.

    By coin toss, R7 chooses eigrp network 155.1.67.0/24.  NextHop is then set to 155.1.67.7 using a route map.

    This is sent in BGP update to R1, which reflects to all others.  Now all AS 100 routers know how to reach 112.0.0.0/8; go to R7 via eigrp path.

    All AS 100 routers now have a two way BGP path to R9 between their loopback address and R9's 112.0.0.0/8.  If one knows R9's host address, then ping should work.

    Reason why only loopback addresses work is that AS 100 is not advertising 155.1.0.0/16 to AS 54.

    I'm not an expert.  But the above is my understanding.

    //RandyB

     

     

  • Thanks for quick replying and improving my skills. I spent last night and in troubleshooting unable clear the things . Once again i appreciate both of you guys helping me.

    Yea i am not advertising 155 network to outside could be the reason of icmp failure.

    Sent from my iPhone

    On Aug 29, 2015, at 8:05 PM, "Randy" <[email protected]> wrote:

    Hi Ahmed and All,

    After looking at my previous post, I can see why it is a poor explanation.  Please consider the following.  First step is to evaluate interior connectivity; then consider the interaction between AS 54 and AS 100.

    " why i am able to ping the prefix learned from the AS 54 from ibgp internal loop back address.  why packets are being dropped when pinging from other interface."

    First note that eigrp is not advertising the 150.1.0.0/16 network, only advertising the 155.1.0.0/16 network.

    R9 , R10 (AS54) <---eBGP---> AS  100

    1)  Loopback to Loopback connectivity within AS100:

    Eigrp 100 is providing full connectivity within AS 100 for network 155.1.0.0/16 (with the exception of demarcation links between AS 54 and AS 100).

    BGP 100 is advertising 150.1.0.0/16

    iBGP using a single route reflection cluster; R1 is the route reflector

    R2 through R8 will advertise their 150.1.x.x address to R1.  R1 is a route reflector, and reflects these updates to all others.  The nexthop attribute is set to a physical interface address.   That is, iBGP session endpoint addresses of R2 through R8.  show tcp brief  on R2 through R8

    These nexthops are being advertised by eigrp.  We get full connectivity within AS100 for its iBGP advertised 150.1.0.0/16 routes.

    2)  AS 100 150.1.0.0/16 advertisement to AS 54:

    R7 to R9 have an eBGP session across link.  At every eBGP session, the nexthop is always reset to the peering address.  That way the adjacent AS knows how to reach the received routes.  Just send to the router that I am peering with.

    R7 sets the BGP nexthop to its peering address 155.1.79.9.

    R9 knows how to reach all AS 100's 150.1.x.x addresses; send to R7.

    Example:  R9  Route table:   150.1.7.7 255.255.255.255    G1.79 155.1.79.7

    3)  AS 54 networks to AS 100:

    R9 advertises 112.0.0.0/8 to R7 and sets NextHop to its peering address with R7; 155.1.79.9

    R7 knows how to reach 112.0.0.0/8; send to R9

    But wait!  Requirements state that R7 must change this NextHop address to an EIGRP routed address.

    By coin toss, R7 chooses eigrp network 155.1.67.0/24.  NextHop is then set to 155.1.67.7 using a route map.

    This is sent in BGP update to R1, which reflects to all others.  Now all AS 100 routers know how to reach 112.0.0.0/8; go to R7 via eigrp path.

    All AS 100 routers now have a two way BGP path to R9 between their loopback address and R9's 112.0.0.0/8.  If one knows R9's host address, then ping should work.

    Reason why only loopback addresses work is that AS 100 is not advertising 155.1.0.0/16 to AS 54.

    I'm not an expert.  But the above is my understanding.

    //RandyB

     

     




    INE - The Industry Leader in CCIE Preparation

    http://www.INE.com



    Subscription information may be found at:

    http://www.ieoc.com/forums/ForumSubscriptions.aspx
Sign In or Register to comment.