Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

does ibgp run on vrf does a next hop modification?

Hi all,

As i understand when we run nomral bgp with 3 routers R1, R2 and R3 where R1 and R2 are running ebgp and R2 and R3 is running ibgp and a network advertized N1 by R1. N1 is R3 must see the advertized network with a next hop of R1's interface which basically signifies that ibgp does not do a next hop modification. This works absolutely fine when there are no vrf's configured. But if the same setup is configured as VRF ie R1 and R2 run ebgp in vrf outside and R2 and R3 run ibgp on outside vrf. We advertize N1 from R1. If we look at the bgp table on R3 we see the next hop to be R2 (which is strange because as per the standards ibgp does not do the next hop modification). i have attached the diagram and the configurations below. Can you please let me know what makes vrf ibgp neighbor to change the nexthop to self?

The configurations are as below

R1:

interface Ethernet0/0

ip vrf forwarding outside

ip address 155.1.0.1 255.255.255.0

router bgp 1

no synchronization

bgp log-neighbor-changes

network 0.0.0.0

no auto-summary

!

address-family ipv4 vrf outside

  neighbor 155.1.0.2 remote-as 65501

  neighbor 155.1.0.2 activate

  no synchronization

  network 0.0.0.0

exit-address-family

R2:

interface Ethernet0/0

ip vrf forwarding outside

ip address 155.1.0.2 255.255.255.0

!

interface Ethernet0/1

ip vrf forwarding outside

ip address 155.1.1.2 255.255.255.0

!

router bgp 65501

address-family ipv4 vrf outside

  neighbor 155.1.0.1 remote-as 1

  neighbor 155.1.0.1 activate

  neighbor 155.1.1.3 remote-as 65501

  neighbor 155.1.1.3 activate

  no synchronization

exit-address-family

R3:

interface Ethernet0/0

ip vrf forwarding outside

ip address 155.1.1.3 255.255.255.0

router bgp 65501

!

address-family ipv4 vrf outside

  neighbor 155.1.1.2 remote-as 65501

  neighbor 155.1.1.2 activate

  no synchronization

  network 3.3.3.0 mask 255.255.255.0

exit-address-family

BGP routes on R3

---------------------------

R3#sh ip bgp vpnv4 vrf outside neighbors 155.1.1.2 routes

BGP table version is 4, local router ID is 155.1.1.3

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: 65501:23 (default for vrf outside)

*>i0.0.0.0          155.1.1.2                0    100      0 1 i

                        (R2)

Total number of prefixes 1

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

does ibgp run on vrf does a next hop modification?

Hello there,

what you see is the expected behavior for iBGP implementations with VRF.

These types of sessions have an inherent next-hop-self (like eBGP sessions) unlike standard iBGP sessions in global table.

The idea is to make sure that connectivity from router receiving the prefix (the one after the CE, in your case R3) and the VPNV4 routes behind the PE (R1 for you) is preserved without the need of an IGP protocol between R2 and R3.

Don't forget that the eBGP session between PE and CE is a session which is traditionally run by an ISP which is normally a different administration entity from the one managing the routing from CEs and routers beyond this point. iBGP was not even considered as the right protocol to advertise the prefixes downstream. That is why the behavior is slightly different.

The only way to change the behavior and get the 'standard' one is by the use of a route map with set next-hop-unchanged.

hope it clarifies

please rate and close question if helpful

regards,

Riccardo

1 REPLY
Cisco Employee

does ibgp run on vrf does a next hop modification?

Hello there,

what you see is the expected behavior for iBGP implementations with VRF.

These types of sessions have an inherent next-hop-self (like eBGP sessions) unlike standard iBGP sessions in global table.

The idea is to make sure that connectivity from router receiving the prefix (the one after the CE, in your case R3) and the VPNV4 routes behind the PE (R1 for you) is preserved without the need of an IGP protocol between R2 and R3.

Don't forget that the eBGP session between PE and CE is a session which is traditionally run by an ISP which is normally a different administration entity from the one managing the routing from CEs and routers beyond this point. iBGP was not even considered as the right protocol to advertise the prefixes downstream. That is why the behavior is slightly different.

The only way to change the behavior and get the 'standard' one is by the use of a route map with set next-hop-unchanged.

hope it clarifies

please rate and close question if helpful

regards,

Riccardo

1350
Views
0
Helpful
1
Replies
CreatePlease login to create content