Cisco – Update-source loopback and next-hop-self

bgpciscojuniperrouting

I've a question related to BGP configuration. If I'm using the update-source loopback or next-hop-self commands, will they modify the source IP address in the packet?

Assume R1 has an eBGP session with R2 and iBGP session with R3 and R4. R1 uses the command update-source loopback and sends the packet to R3. Now, the source IP address of the packet has been changed. R3 forwards the packet to its destination through some other peer. Now, when the packet comes from destination, it wont be having the correct source address from where packet came because of the command update-source loopback. So, does BGP handle this case?

Same for the next-hop-self command. R2 can use this command while sending the packets to R3 or R4, and further they can send to their peers.

Can someone please clarify my doubts?

Best Answer

The two commands are for completely different reasons, and they do not modify addresses on packets. The update-source command will try to form a neighbor relationship using an address different than the directly connected address, while the next-hop-self command tells a neighbor where to send packets when the neighbor doesn't know how to reach the advertising router.

If you are using eBGP, and the update-source command, you must understand a few things. The eBGP peer must have a route to the interface in the update-source command in order to form a neighbor. That would involve using a different routing protocol or static routing for the eBGP neighbor to be able to reach the interface in the update-source command. That is why it is normally only used for iBGP. Also, with eBGP, you muse use the ebgp multihop command, otherwise it will not work. This command is for forming the BGP neighbor connection.

The next-hop-self command has nothing to do with the addresses on packets. That command simply tells the neighbor that it should send packets toward the destination to the router with that command. It is used in cases where the neighbor router doesn't know how to reach the advertising router, but the router with the next-hop-self command does. This command is for advertising route direction.

Related Solutions

BGP Neighborship Basics – Understanding BGP Fundamentals

OK - so there are a few things going on here and I'll try to address them in some approximate order.

There are two sub-variants of BGP - internal (iBGP) and external (eBGP). In the case of iBGP the ASN's of the two peers are identical. In the case of eBGP the two ASN's are different. In your example you're using eBGP. I mention this because a number of rules are different between eBGP and iBGP.
Most typically eBGP sessions occur between directly connected interfaces. In your example this would mean that R1 and R2 would peer to one another as 1.1.1.1 and 1.1.1.2 respectively (i.e. R1 has a neighbor statement to 1.1.1.2, R2 has its statement to 1.1.1.1). This works because each router can reach the other via a directly connected route. If you deleted the update-source and static route and simply peered the routers on their directly connected interfaces the peer would come up without any further configuration. Also - as an aside, if you have a point-to-point link use a /30 or /31 prefix rather than a /8.
It's possible to configure what's called multihop eBGP. This means peering two router interfaces that aren't directly connected. This requires that another route needs to be in place for the interfaces to be able to pass packets. When you changed the source of the sessions to loopbacks you needed the static routes in place to allow the session to come up. Typically the peering session will require an additional statement specifying the maximum number of IP hops for the session but since in this instance they're only a single hop apart it may not have been necessary (..although it used to be). This is also known as a recursive route - so a route received with a next-hop of the remote router's loopback will actually use the static route as a way of resolving the interface that a given packet will take (in this case 1.1.1.x).
By default for eBGP routes will be advertised with a next-hop of the peering address (unless specifically altered via a knob or route-map). This is one of the differences with iBGP where the next-hop address will be normally unchanged across peers unless configured to behave otherwise.

VRF Route with Global IP as the Next Hop

I got it working(with guidance of my colleague), please have a look at the configs, note that there is a minor change in the ip(replace 192 with 172), replace 1.0.1.1 with 100.0.0.1; and f0/1 is replaced with subinterfaces. Below are the working configs of my lab in GNS3.

On R1:

R1#ter len 0
R1#
R1#
R1#
R1#
R1#sho run
Building configuration...

Current configuration : 1076 bytes
!
! Last configuration change at 16:46:26 UTC Thu May 25 2017
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
!
!
!
!
!
!
no ip domain lookup
ip domain name lab.local
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 100.0.0.1 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex full
!
interface FastEthernet1/0
 ip address 172.16.1.14 255.255.255.252
 ip ospf 1 area 0
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 shutdown
 speed auto
 duplex auto
!
router ospf 1
 network 100.0.0.1 0.0.0.0 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 0.0.0.0 0.0.0.0 172.16.1.13
!
!
!
!
control-plane
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line vty 0 4
 login
!
!
end

R1#

On R2:

R2#sho run
Building configuration...

Current configuration : 1697 bytes
!
! Last configuration change at 16:48:08 UTC Thu May 25 2017
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
vrf definition TEST
 rd 2:1
 !
 address-family ipv4
 exit-address-family
!
!
no aaa new-model
!
!
!
!
!
!
no ip domain lookup
ip domain name lab.local
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex full
!
interface FastEthernet1/0
 ip address 172.16.2.9 255.255.255.252
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 speed auto
 duplex auto
!
interface FastEthernet1/1.2000
 encapsulation dot1Q 2000
 vrf forwarding TEST
 ip address 172.16.1.9 255.255.255.252
!
interface FastEthernet2/0
 ip address 172.16.1.13 255.255.255.252
 ip ospf 1 area 0
 speed auto
 duplex auto
!
interface FastEthernet2/1
 no ip address
 shutdown
 speed auto
 duplex auto
!
router ospf 1
!
router bgp 65002
 bgp log-neighbor-changes
 neighbor 172.16.2.10 remote-as 65003
 !
 address-family ipv4
  redistribute ospf 1
  neighbor 172.16.2.10 activate
 exit-address-family
 !
 address-family ipv4 vrf TEST
  neighbor 172.16.1.10 remote-as 65003
  neighbor 172.16.1.10 activate
  neighbor 172.16.1.10 allowas-in
 exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 172.16.1.8 255.255.255.252 FastEthernet1/1.2000
!
!
!
!
control-plane
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line vty 0 4
 login
!
!
end

R2#

On R3:

R3#ter len 0
R3#sho run
Building configuration...

Current configuration : 1567 bytes
!
! Last configuration change at 16:23:00 UTC Thu May 25 2017
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
vrf definition TEST
 rd 3:1
 !
 address-family ipv4
  import ipv4 unicast map GLOBAL_TO_VRF
 exit-address-family
!
!
no aaa new-model
!
!
!
!
!
!
no ip domain lookup
ip domain name lab.local
ip cef
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex full
!
interface FastEthernet1/0
 ip address 172.16.2.10 255.255.255.252
 speed auto
 duplex auto
!
interface FastEthernet1/1
 no ip address
 speed auto
 duplex auto
!
interface FastEthernet1/1.2000
 encapsulation dot1Q 2000
 vrf forwarding TEST
 ip address 172.16.1.10 255.255.255.252
!
router bgp 65003
 bgp log-neighbor-changes
 neighbor 172.16.2.9 remote-as 65002
 !
 address-family ipv4
  neighbor 172.16.2.9 activate
 exit-address-family
 !
 address-family ipv4 vrf TEST
  neighbor 172.16.1.9 remote-as 65002
  neighbor 172.16.1.9 activate
 exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route vrf TEST 172.16.2.8 255.255.255.252 172.16.2.9 global
!
access-list 10 permit any log
!
route-map GLOBAL_TO_VRF permit 10
 match ip address 10
!
!
!
control-plane
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line aux 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 stopbits 1
line vty 0 4
 login
!
!
end

R3#

Verification:

R2#ping vrf TEST 100.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/60/68 ms
R2#

Best Answer

Related Solutions

BGP Neighborship Basics – Understanding BGP Fundamentals

VRF Route with Global IP as the Next Hop

Related Topic