BGP Next-hop command

FrankGuthrieFrankGuthrie Member Posts: 245
Ok, I'm currently studying BGP, and I'm using the IPExpert CCNP Route on demand videos.

The instructor is explaining about the next-hop-self command, but I was wondering If I understood correct. So if you use the #neighbor x.x.x.x nex-hop-self command under the BGP process, and the BGP update is send to router in the network, also the ones not running BGP, they will alter the packet when it passes the IGP routes, and they will point to themselves as the next hop to reach a eBGP route. This will be done up until the route reach the other iBGP peer. And when this iBGP peer send the route out to another AS again to an eBGP peer, it will also alter the next-hop to itself as this is the default behaviors for eBGP.

So does this command act like some sort of flag in the BGP packet?

Please find enclose an attachment of the diagram I'm talking about:



In this network diagram he only tells to configure the next-hop-self command on R1. I would think this also need to be done on R2 or R4, depending in which path you prefer, because they need to tell R3 to use them (R2 or R4) as the next hop. Or am I missing something here?

Comments

  • bermovickbermovick Member Posts: 1,135 ■■■■□□□□□□
    Well, from your diagram it doesn't look like R2 or R4 are running IBGP - the peering is strictly between R1 and R3. Internally, OSPF is going to be used to tell each router how to get from R1 to R3. Even if they were, with IBGP's high AD, OSPF would still be used.

    [edit] For more specifics, let's look at a packet from R6 destined out R5.

    R6 will have an EBGP route to send it to R3
    R3 will have an IBGP route to send it to R1 <-- due to next-hop-self**
    . R3 will have an OSPF route to send packets to R1 through R2 or R4
    R1 will have an EBGP route to send to R5

    ** without the next-hop-self argument, OSPF would need to have a route to R5.
    Latest Completed: CISSP

    Current goal: Dunno
  • mattaumattau Member Posts: 218
    The next hop self command would only benefit R1 in this case as R2 and R4 dont run ibgp.
    This is the classic blackhole setup and the "bgp sync" was there to prevent
    BGP runs over an existing infrastructure via tcp. R2 and R4 wont do anything with the next hop, they just see it as a stream of tcp packets and forward accordingly based on the destination IP address. Thats how an ibgp peering is built. The IGP provides the paths to get to the peering addresses and bgp just runs over the top of that to establish a client server relationship.

    from example it looks like that pic has AS500 with 5.5.5.0/24

    since R1 put itself has next hop for AS100 via the next hop self command.
    R3 will have
    B 5.5.5.0 via 1.1.1.1 (R1's loopback for example advertised in ospf)
    O 1.1.1.1 via 150.1.23.2
    O 1.1.1.1 via 150.1.34.4
    C 150.1.23.0 is directly connected fa0/1
    C 150.1.34.0 is directly connected fa0/0

    then R3 will do a recursive lookup on how to get to 1.1.1.1 and it will be R2 or R4 depending on ospf.
    R2 or R4 will receive packet and lookup destination to 5.5.5.0/24 but will drop it seems its not a full mesh of peerings.

    The only way R2 and R4 would know how to get to 5.5.5.0/24 is if it has an ibgp peering with R1 or R1 redistributes bgp into ospf
    _____________________________________
    CCNP ROUTE - passed 20/3/12
    CCNP SWITCH - passed 25/10/12
    CCNP TSHOOT - passed 11/12/12




  • FrankGuthrieFrankGuthrie Member Posts: 245
    Hi Guys, you replies were excellent. This made is clear for me. Thank you.
Sign In or Register to comment.