BGP update-source loopback 0 doesn't work

[StefanStefanR]

Hello, I have this network where D1, D2 and D3 routers are configured as iBGP. 

Network works just fine until I do the command:

neighbor x.x.x.x update-source loopback 0

on each router.

Once this is done, routers begin to shutdown their neighbors after 180 seconds have passed, removing the topology table. This is the error that I'm getting:

D1;

router bgp 64530
bgp router-id 1.1.1.1
bgp log-neighbor-changes
network 1.2.3.4 mask 255.255.255.255
network 10.10.11.0 mask 255.255.255.252
network 10.10.12.0 mask 255.255.255.252
network 150.224.224.196 mask 255.255.255.252
network 180.200.200.0 mask 255.255.255.252
neighbor 10.10.11.2 remote-as 64530
neighbor 10.10.12.1 remote-as 64530
!

D2;

router bgp 64530
bgp log-neighbor-changes
network 10.10.12.0 mask 255.255.255.252
network 10.10.13.0 mask 255.255.255.252
network 10.10.100.0 mask 255.255.255.252
network 10.16.0.0 mask 255.240.0.0
network 180.110.100.100 mask 255.255.255.255
redistribute ospf 1 route-map OSPF_FILTER
neighbor 10.10.12.2 remote-as 64530
neighbor 10.10.13.1 remote-as 64530
!

D3;

router bgp 64530
bgp log-neighbor-changes
network 10.10.11.0 mask 255.255.255.252
network 10.10.13.0 mask 255.255.255.252
network 10.10.14.0 mask 255.255.255.252
network 10.10.154.208 mask 255.255.255.240
network 10.10.189.0 mask 255.255.255.240
network 10.10.198.0 mask 255.255.255.0
network 180.100.100.100 mask 255.255.255.255
redistribute static
neighbor 10.10.11.1 remote-as 64530
neighbor 10.10.13.2 remote-as 64530
!

Router D2 has OSPF process but only with the router OfficeA-1 which is down next to him.

The issue persists once I start configuring the

update-source

command. Let's say I go to D2 and put:

neighbor 10.10.12.2 update-source loopback 0

neighbor 10.10.13.1 update-source loopback 0

and then I do the same for the rest of them. They will still maintain the bgp peering until hold timer ends and then they start shutting themselves down and routers also go to a full freeze mode with no respond, so I have to stop routers and force a restart of an IOS system.

Any clue to why this happens? Do I need to have IGP configured with iBGP maybe?

[David Ruess]

You need to make sure that the D1-D3 routers Loopbacks are reachable from each other. If you only have OSPF configure on one router then I assume you don't have any routing protocol to help inform the routers about each others loopbacks.

When a BGP neighbor statement is configure with the

update-source

command then it sends BGP messages to its configured neighbor with that address. When the neighbor BGP router receives it it will see it needs to connect to the

update source

IP (which in your case is the Lo0). It will look into its routing table and if you don't have routing/static route configured then it wont establish an adjacency. Before you enter the neighbor command 

update-source 

the router will use the exit interface as the

update-source

This is reachable by the neighbor since they ar eon the same link and in the same network, therefor it does not need any additional neighbor statements to connect.

Once you include the 

update-source 

command the router will time out in the 3 minutes as you have mentioned because it has not way to route to the Loopback you specified in the BGP message.

You can configure static routes, OSPF, EIGRP, etc between routers and advertise the

Loopback 0

into them to provide the reachability you need.

-David

[Harold Ritter]

Hi @StefanStefanR ,

In addition to what @David Ruess mentioned about making sure the lo0 IP address is propagated via the IGP, the

update-source

would normally be used if you use the loopback interface IP addresses to peer.

I notice that you are rather using the physical interfaces to peer

(10.10.11.1, 10.10.11.2, 10.10.12.1, 10.10.12.2, 10.10.13.1, 10.10.13.2)

which is counterintuitive and will lead to unexpected results.

You should definitely use the loopback interface IP address of each router

(1.2.3.4/32, 180.110.100.100/32 and 180.100.100.100/32)

in the neighbor statement if you are going to use

update-source lo0

Regards,

[StefanStefanR]

@David Ruess @Harold Ritter 

Thank you very much for your detailed explanation. Here is the current image so you get the idea of what is happening.

On routers D1, D2 and D3, I removed all

neighbor

commands. Then I added the

neighbor

commands again but this time not using their physical interfaces but loopbacks.

For an example:

D1(config-router)#neighbor 180.110.100.100 remote-as 64530

D1(config-router)#neighbor 180.110.100.100 update-source loopback 0

I did this for each one of them. BGP sessions are not established since as you mentioned, an IGP is needed to advertise these routes. D2 and OfficeA-1 are working with

OSPF process 100

and they are in

AREA 1

(for making OfficeA-1 as a stub router). Afterwards, I made on D2 another

OSPF process 1

but here he is using

AREA 0

(the backbone).

I advertised the networks on D2 like this:

network 10.10.0.0 0.0.255.255 area 0

network 180.110.100.100 0.0.0.0 area 0

I am using

10.10.0.0 0.0.255.255

network because it will catch all his directly connected links and I don't have the need to type every single one of them (at least I think so).

I did these commands on all other routers D1 and D3. All

area 0

backbone. After I advertised these networks via OSPF, all routers have made OSPF process 1 adjacency with each other. Afterwards, BGP sessions have been established as well. Everything is going fine right now.

Then on D2 router I redistributed OSPF 100 process routes into BGP (I was in a dilemma if I should redistribute this into

ospf 1 or bgp 64530

but I went with bgp anyways). With command:

redistribute ospf 100 route-map OSPF_FILTER

. This filter just makes sure that only

192.168.100.0

and

192.168.150.0 (Vlan 100 / 150)

are advertised into bpg and not

.99.0 (Vlan 99)

network.

I did the pings from PC's, routers and whole network is connected successfully.

But, I still need some deep throughout explanation on a few things that have been occurring here. 

1) Why are routers D1 and D3 connected with D2 via

10.16.0.1

Loopback 1 network for OSPF? Why not pick Loopback 0?

Nevermind, I actually figured this question out. The issue is that OSPF process 100 is already using Loopback 0 as his router-ID. But OSPF process 1 is using Loopback 1 router-id because Loopback 0 is already used for another process. My bad, I'm sorry. I understand this question now. I actually checked show ip protocols and it shows right there.

2) Doing the command:

show ip protocols

on each router, shows that BGP sessions are connected via Loopback 0 but then it also shows that their Gateways for neighbors are containing their

next-hop

addresses as well. Even though I disabled

neighbor

command for these and reset the bgp session. Here look at the image below;

D3 shows 1.2.3.4 which is okay,

180.110.100.100

correct, but then it also shows his

10.10.13.2 and 10.10.11.1 neighbor's next-hop

addresses of

Gigabit0/0 - 0/1

interface. I assume this is the "correct" behavior or I have done something wrong?

3) When I do

show ip bgp

, let's say on D3. He implies that some routes have

rib-failures

(which is fine since they are using OSPF). Message is "Higher administrative distance''. All 3 routers are experiencing this.

I assumed that because of OSPF, it should state "Lower administrative distance" failure but not higher. I'm wondering if I should just do 

bgp suppress-inactive 

command or this would make a mess in the network when other routers are configured?

Here below are configurations of D1, D2, D3;

D1:

!
router ospf 1
network 1.2.3.4 0.0.0.0 area 0
network 10.10.0.0 0.0.255.255 area 0
!
router bgp 64530
bgp router-id 1.1.1.1
bgp log-neighbor-changes
network 1.2.3.4 mask 255.255.255.255
network 10.10.11.0 mask 255.255.255.252
network 10.10.12.0 mask 255.255.255.252
network 150.224.224.196 mask 255.255.255.252
network 180.200.200.0 mask 255.255.255.252
neighbor 180.100.100.100 remote-as 64530
neighbor 180.100.100.100 update-source Loopback0
neighbor 180.110.100.100 remote-as 64530
neighbor 180.110.100.100 update-source Loopback0
!

D2:

router ospf 100
network 10.10.100.0 0.0.0.3 area 1
!
router ospf 1
network 10.10.0.0 0.0.255.255 area 0
network 180.110.100.100 0.0.0.0 area 0
!
router bgp 64530
bgp log-neighbor-changes
network 10.10.12.0 mask 255.255.255.252
network 10.10.13.0 mask 255.255.255.252
network 10.10.100.0 mask 255.255.255.252
network 10.16.0.0 mask 255.240.0.0
network 180.110.100.100 mask 255.255.255.255
redistribute ospf 100 route-map OSPF_FILTER
neighbor 1.2.3.4 remote-as 64530
neighbor 1.2.3.4 update-source Loopback0
neighbor 180.100.100.100 remote-as 64530
neighbor 180.100.100.100 update-source Loopback0
!

D3:

!
router ospf 1
network 10.10.0.0 0.0.255.255 area 0
network 180.100.100.100 0.0.0.0 area 0
!
router bgp 64530
bgp log-neighbor-changes
network 10.10.11.0 mask 255.255.255.252
network 10.10.13.0 mask 255.255.255.252
network 10.10.14.0 mask 255.255.255.252
network 10.10.154.208 mask 255.255.255.240
network 10.10.189.0 mask 255.255.255.240
network 10.10.198.0 mask 255.255.255.0
network 180.100.100.100 mask 255.255.255.255
redistribute static
neighbor 1.2.3.4 remote-as 64530
neighbor 1.2.3.4 update-source Loopback0
neighbor 180.110.100.100 remote-as 64530
neighbor 180.110.100.100 update-source Loopback0
!

[David Ruess]

What are the static routes o D3? You have those being redistributed into BGP as well.

[StefanStefanR]

There's only one single static route of

10.255.255.0

from D3. That one is redistributed yes. That route goes up to the

10.10.14.0

network because there is a router there. D3 uses a static route to reach his LAN network. Router on that other side is using a simple default route of

0.0.0.0

to communicate with the rest of the network. There's no issue there only that route has "?" mark next to it but that's because it's redistributed.

I mean, everything is working fine right now. I managed to fix the whole network thanks to your help. I only have those two questions about BGP behavior. 

The command

show ip protocols

states that neighbors are loopbacks 0 but it also contains the physical addresses of the directly connected interface. I can only assume that this is the correct behavior because it is an intriguing find. Maybe this is just how it works?

As for BGP showing

rib-failures

that one is totally acceptable. Those are bound to happen no matter what. I was only double minded if it should say: ''Higher admin distance'' or "Lower admin distance''. But to my surprise, "Lower admin distance" message doesn't even exist (at least from searching over the internet), so my guess is that ''Higher admin distance'' is the correct thing to pop-up.

Why I think that this is correct? Because

180.110.100.100, 10.10.12.0 and 1.2.3.4 on D3 show rib-failure

as those routes are also learned via OSPF process. So normally even though BGP is also advertising them, D3 prefers the OSPF ones. This behavior happens on all routers which is acceptable and I think there's no way to fix this.

Doing the

bgp supress-inactive

might not be the case here since there are no different next-hops. 

As I stated, the network is fine right now. I only had these two questions brought up because they are interesting ones, at least for me.

[Giuseppe Larosa · Accepted solution]

Hello @StefanStefanR ,

>>

2) Doing the command:

show ip protocols

 on each router, shows that BGP sessions are connected via

Loopback 0

but then it also shows that their Gateways for neighbors are containing their

next-hop

addresses as well. Even though I disabled

neighbor

command for these and reset the bgp session. Here look at the image below;

D3 shows 1.2.3.4 which is okay

180.110.100.100

correct, but then it also shows his

10.10.13.2 and 10.10.11.1 neighbor's next-hop addresses of Gigabit0/0 - 0/1 interface

I assume this is the "correct" behavior or I have done something wrong?

My guess is that the

show ip

protocols is reporting also the old neighbors configured if you see the last update is more then one hour ago on the two addresses on LAN interfaces.

3)   Your understanding is correct iBGP AD is

200 > OSPF AD 110

so all routes advertised in OSPF are RIB failure in BGP. This is normal

You need an IGP to build iBGP sessions terminated on loopbacks this is the most important take away of your tests.

Hope to help

Giuseppe