Inter-AS option A , How BGP Next-HOP is changed?

[xZamalek]

Dears,

I'm trying to practice Inter-AS , i configured option A as per the below picture and the pings goes successfully from HSBC-1 to HSBC-2 , my question is when the BGP update for the loopback of HSBC-1 received by R5 , how R5 set him self as the next hop for this subnet?

1-an IPV4 BGP update goes from HSBC1 to R2

2-R2 will impose a transport and vpn label to this route and forward it to R3-RR

3-R3 will pop the label and send the update to R4 with the vpn label only.

4-R4 will send normal ipv4 EBGP update to r5 as they formed BGP neighbor under the same VRF.

6-R5 will receive the update and will impose a VPN+Transport label and send it to R6-RR as it has an MB-IBGP session.

My question is , when R5 receive the update and send it to R6-RR , the next hop on RR should be R4 because it's an EBGP update and R5 shouldn't modify the next hop when sending an update via MB-IBGP , could anyone explain to me how?

R6#show ip bgp vpnv4 all
BGP table version is 3, local router ID is 6.6.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 2:100
*>i1.1.1.0/24 5.5.5.5 0 100 0 1 65001 i
*>i8.8.8.0/24 7.7.7.7 0 100 0 65002 i
R6#

1.1.1.1=loopback of HSBC-1

is the normal behavior for MB-IBGP updates that the router will announce it self as the next hop ??

[Giuseppe Larosa · Accepted solution]

Hello @xZamalek ,

inter AS option A is simply back to back VRFs with the other provider PE seen as a CE node.

My question is , when R5 receive the update and send it to R6-RR , the next hop on RR should be R4 because it's an EBGP update and R5 shouldn't modify the next hop when sending an update via MB-IBGP , could anyone explain to me how?

In i MP BGP address family VPNv4 the eBGP next-hop of the CE node is not preserved but is changed to the source PE loopback address otherwise the VPN forwarding plane would fail ( the external label is provided by the LSP with destination the source PE).

What you see is normal and happens even in a single provider context, the rule of eBGP next-hop unchanged is not honored in address family VPNv4 or you want to see it in another way it is like if each VPNv4 neighbor had next-hop self configured automatically.

Hope to help

Giuseppe

[xZamalek]

Thank you Giuseppe , i have learned something new today , so shall we confirm the below process if it's correct?

1-when an IPV4 EBGP update is sent to the service provider under a vrf which will need to be forwarded as an MP-IBGP VPNV4 , the Next-Hop Address will be the loopback of the PE which already contained in the VPNV4 BGP neighbor command.

I have another question , in Option B , we will run an EBGP VPNV4 between ASRBS (R4 & R5) , this will lead to me ask the below question.

1-an MP-IBGP update will be send from R2 to RR then from RR to R4 with the next-hop of R2's Loopback.

2-an MB-EBGP will be sent from R4 to R5 and R5 will see the loopback of R4 as the next-hop.

3-R5 will send MP-IBGP update to R6 RR , but R5 will not modify the next hop to itself that's why i read in the book we will either use the next hop self on the PE or we can redistribute connected subnets leading to R4 , is that true that from MP-EBGP to MB-IBGP the next hop of R4 will be reserved ??

[Giuseppe Larosa]

Hello @xZamalek ,

your understanding is correct in the case of MP eBGP for AF VPNv4 you need to configure next-hop self  explicitly towards the i MP BGP neighbors (internal neighbors)

In the case of a IPv4 eBGP session in VRF the creation of the VPNv4 prefix starting from an IPv4 prefix allows for the automatic next-hop change to the source PE loopback.

Hope to help

Giuseppe