BGP wont establish with peer using update-source Loopback0

[bret]

I hope someone can steer me in the right direction. I am working on a BGP lab, trying to figure out a production problem. In this lab I have 4 routers, where 2 CE routers each peer with a PE router. I have established a neighbor relationship with the PE, but cant establish a peer relationship with the CE's, when update-source loopback 0 is used on 1 of the CE routers. When I take update-source loopback off, the peer establishes. The loopback is routed and can be pinged from the far side CE router.

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.0.82    4  1803      52      50       15    0    0 00:43:43        6
192.168.107.3   4 65185       0       0        0    0    0 never    Active
 

CE1: 192.168.107.2

router bgp 65185
no synchronization
bgp log-neighbor-changes
network 7.255.1.6 mask 255.255.255.255
network 192.168.8.6 mask 255.255.255.255
network 192.168.107.0 mask 255.255.255.192
network 192.168.107.64 mask 255.255.255.192
network 192.168.107.128 mask 255.255.255.192
network 192.168.107.192 mask 255.255.255.192
network 192.168.151.0 mask 255.255.255.128
neighbor 192.168.0.82 remote-as 1803
neighbor 192.168.0.82 description Sprint-MPLS-BGP
neighbor 192.168.0.82 version 4
neighbor 192.168.0.82 soft-reconfiguration inbound
neighbor 192.168.0.82 weight 100
neighbor 192.168.0.82 prefix-list Default-Route-Only in
neighbor 192.168.107.3 remote-as 65185
neighbor 192.168.107.3 description IBGP Link to Backup Router
neighbor 192.168.107.3 update-source Loopback0
neighbor 192.168.107.3 next-hop-self
no auto-summary

CE2 = 192.168.107.3

router bgp 65185
 no synchronization
 bgp log-neighbor-changes
 network 10.251.3.0 mask 255.255.255.0
 network 192.168.8.6 mask 255.255.255.255
 network 192.168.107.0 mask 255.255.255.192
 network 192.168.107.64 mask 255.255.255.192
 network 192.168.107.128 mask 255.255.255.192
 network 192.168.107.192 mask 255.255.255.192
 redistribute static
 neighbor 192.168.3.49 remote-as 65185
 neighbor 192.168.3.49 version 4
 neighbor 192.168.3.49 next-hop-self
 neighbor 192.168.3.49 soft-reconfiguration inbound
 neighbor 192.168.3.49 prefix-list Default-Route-Only in
 neighbor 192.168.3.49 route-map AS-Prepend out
 neighbor 192.168.107.2 remote-as 65185
 neighbor 192.168.107.2 description IBGP Link to Primary Rtr
 neighbor 192.168.107.2 next-hop-self

HSRP is configured using 192.168.107.1

Here is the debug output:

CE where the update-source loopback0 is used.

*Mar  1 02:58:10.363: BGP: 192.168.107.3 passive open to 192.168.107.2
*Mar  1 02:58:10.367: BGP: 192.168.107.3 passive open failed - 192.168.107.2 is not update-source Loopback0's address (192.168.8.6)
*Mar  1 02:58:10.367: BGP: 192.168.107.3 remote connection attempt failed, local address 192.168.107.2

The other CE router:

*Mar  1 02:37:21.867: BGP: 192.168.107.2 open active, local address 192.168.107.3
*Mar  1 02:37:21.919: BGP: 192.168.107.2 went from Active to OpenSent
*Mar  1 02:37:21.923: BGP: 192.168.107.2 sending OPEN, version 4, my as: 65185, holdtime 24 seconds
*Mar  1 02:37:21.927: BGP: 192.168.107.2 send message type 1, length (incl. header) 45
*Mar  1 02:37:21.991: BGP: 192.168.107.2 remote close, state CLOSED
*Mar  1 02:37:21.991: BGP: 192.168.107.2 -reset the session
*Mar  1 02:37:21.991: BGPNSF state: 192.168.107.2 went from nsf_not_active to nsf_not_active
*Mar  1 02:37:21.995: BGP: 192.168.107.2 went from OpenSent to Idle
*Mar  1 02:37:21.995: BGP: 192.168.107.2 closing
*Mar  1 02:37:22.995: BGP: 192.168.107.2 went from Idle to Active
*Mar  1 02:37:23.003: BGP: 192.168.107.2 open active delayed 28796ms (35000ms max, 28% jitter)
 

[Bilal Nawaz]

On CE2 aren't you missing this:

neighbor 192.168.107.2 update-source loopback 0

should be set on both sides I would have thought? so you are trying to peer together two CE's via iBGP over eBGP (PE)?

[bret]

Good eye. I added the update-source loopback 0 to CE 2, not included in the post, but it didn't work. I clear ip bgp after adding it and still the peer did not establish.

[Bilal Nawaz]

How can HSRP be configured between loopback addresses? I didn't think you could.... Maybe you can?

Anyway, could you tell us if this works on CE2:

ping 192.168.107.2 source loopback 0

On CE1 - ping 192.168.107.3 source loopback 0

[bret]

CE1#ping 192.168.107.3 source l0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.107.3, timeout is 2 seconds:
Packet sent with a source address of 192.168.8.6
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/37/52 ms

Not sure what you meant by "how can HSRP be configured between loopback address."

AZTEM-CWR1#sh stand bri
                     P indicates configured to preempt.
                     |
Interface   Grp Prio P State    Active          Standby         Virtual IP
Fa0/3       5   110  P Active   local           192.168.107.3   192.168.107.1
 

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
192.168.0.82    4  1803     154     152       15    0    0 02:25:54        6
192.168.107.3   4 65185       0       0        0    0    0 never    Active
 

[Bilal Nawaz]

Right, so your loopback address was 192.168.8.6 - you need to peer to this IP, and not the IP on Fa0/3.

Step no 1 for you is to remove non working config

Step no 2 - determine the loopback addresses on both CE's

Step no 3 - create neighborship on respective CE's to the Loopback address (not the 192.168.107.x)

Step no 4 - source your bgp from loopback (with update-source)

Step no 5 - which should really be done first, is make sure from on of the CE's you can source the ping from loopback to the other CE loopback

Remember, BGP peering needs to match the outgoing interface IP address and the respective neighbor statement on the other side.

Here in your case you have BGP trying to peer to 192.168.107 addresses with the source of the loopback address 192.168.8.6 address which will not work. You could do it without sourcing from the loopback - sure enough it will work, but if you want to achieve this via loopback then we need to change the config a little.

EDIT: I noticed you advertise out 192.168.8.6 on both CE's - is this some sort of ANYCAST address? Please dont do the above just yet! Need to understand what you are trying to do before I can assist further. Perhaps show me config of both loopbacks.

If they have the same IP address, the i'd suggest that you need loopback addresses that are different.

[bret]

Thanks Bilal! So what your saying is if I am not peering with the loopback, the update-source is not needed? If the update-source is used with a non-peering loopback, it causes problems, because its not the actual source.

The loopback is being advertised because we use it for the source of logging and mgmt. of the device.

[Bilal Nawaz]

Yes, exactly. If you arent peering with the loopback, the update-source wouldn't be needed "Only if the outgoing interface IP was the one being used for peering" and in your case it is true.

If you wanted to peer with the loopbacks you could, maybe try it out in your lab, with the update-source command.

Hope it helps

Bilal

[bret]

So, I guess the update-source, isn't like a logging source-interface l0? As a test I did change the update-source to the interface of the peering-ip and the neighbor came up. Looks like I need re-engineer these sites with IBGP, changing them to peer with loopbacks, instead of physical interfaces.

[Bilal Nawaz · Accepted solution]

Yes it's not like logging in that logging isn't connection based, it's only firing off longs from a particular IP. I think of it as connection based since it uses TCP, IPs have to be correct for TCP session to be established if we peer to an IP we have to return back with the same IP being used for peering.

[milan.kulik]

Hi,

you might also need to use

ebgp-multihop

or

neighbor disable-connected-check

command to peer through Looppback addresses, as discussed here:

https://supportforums.cisco.com/discussion/11603211/ebgp-multihop-command-only-applies-loopbacks

Best regards,

Milan

[Bilal Nawaz]

Milan - this question is for ibgp not ebgp.