topic BGP Network statement - IGP Equal path cost in Routing and SD-WAN

BGP Network statement - IGP Equal path cost

Americo Massotti — Sat, 23 Feb 2019 11:14:37 GMT

Hello guys.

I've a question about network stamente in bgp in the case the underlay IGP has two equal path cost to the same destination.

I created this topology.

Three bgp AS. R5 is in AS1, R6 in AS2

The other router (R1,R2,R3, R4) are in As100.

I created some Loopback on R1 (10.10.10.10 etc), R2 (40.40.40.40 etc) and the same on R5 and R6.

In AS 100 there is Eigrp As 1 as IGP protocol.

I've created on R3 and R4 under bgp process the network statement for the loopback of R1 and R2.

R4 for example, reach Loopbacks of R1 through two path of equal cost:

R4# show ip route

D 10.10.10.10 [90/435200] via 192.168.34.3, 00:26:04, Ethernet0/0
[90/435200] via 192.168.24.2, 00:26:04, Ethernet0/1
20.0.0.0/32 is subnetted, 1 subnets
D 20.20.20.20 [90/435200] via 192.168.34.3, 00:26:04, Ethernet0/0
[90/435200] via 192.168.24.2, 00:26:04, Ethernet0/1
30.0.0.0/32 is subnetted, 1 subnets
D 30.30.30.30 [90/435200] via 192.168.34.3, 00:26:04, Ethernet0/0
[90/435200] via 192.168.24.2, 00:26:04, Ethernet0/1

R4, that has a network statement for these loopback ( You know, I could hit the network stamente on each router where the loopback reside, but to try different things)

R4#show run | sec router bgp
router bgp 100
bgp log-neighbor-changes
network 10.10.10.10 mask 255.255.255.255
network 20.20.20.20 mask 255.255.255.255
network 30.30.30.30 mask 255.255.255.255

.....

Why R4 select always in BGP the same path even the equal cost? Which is the discriminant?

Why never 192.168.34.3 as path?

Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.10/32 192.168.24.2 435200 32768 i
* i 192.168.13.1 409600 100 0 i
*> 20.20.20.20/32 192.168.24.2 435200 32768 i
* i 192.168.13.1 409600 100 0 i
*> 30.30.30.30/32 192.168.24.2 435200 32768 i
* i 192.168.13.1 409600 100 0 i

In attachment if you would help me you could find the show run-show ip bgp and show ip route of AS100 Router.

Thanks a lot and have a nice day!

Re: BGP Network statement - IGP Equal path cost

Sergey Lisitsin — Sat, 23 Feb 2019 11:54:12 GMT

Americo Massotti,

By default BGP doesn't do load sharing. It only selects one best path to the destination. The fact that you have multiple paths to reach your BGP neighbour's address doesn't play a role in the selection process. Which makes sense, because routes coming from different AS'es won't have comparable metrics and you don't want to load share across paths that might have a very uneven bandwidth and delay characteristics.

Re: BGP Network statement - IGP Equal path cost

Americo Massotti — Sat, 23 Feb 2019 12:14:35 GMT

Hello Sergey.

Thanks a lot for your explanation.

However, why R4 choose always the same path as best path respect to other?

D 10.10.10.10 [90/435200] via 192.168.34.3, 00:26:04, Ethernet0/0
[90/435200] via 192.168.24.2, 00:26:04, Ethernet0/1

The metric is the same but R4 for the network statement: network 10.10.10.10 mask 255.255.255.255

choose 192.168.24.2

Why not the other neighbor 192.168.34.3?

The same thing about the 20.20.20.20 and 30.30.30.30 network.

I understand that it only select one best path, but when we have two equal metric path (IGP) to the same destination such in this case, the network statment which choose?

In my case choose always the same. Why?

Thanks a lot.

Re: BGP Network statement - IGP Equal path cost

Sergey Lisitsin — Sat, 23 Feb 2019 13:15:34 GMT

Check your EIGRP topology table for prefix 10.10.10.10/32. That will give you an idea of why you only choose one EIGRP path.

Re: BGP Network statement - IGP Equal path cost

Americo Massotti — Sat, 23 Feb 2019 13:29:18 GMT

Ho Sergey

R4# show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(4.4.4.4)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status

P 10.10.10.10/32, 2 successors, FD is 435200
via 192.168.24.2 (435200/409600), Ethernet0/1
via 192.168.34.3 (435200/409600), Ethernet0/0

R4#show ip route

D 10.10.10.10 [90/435200] via 192.168.34.3, 02:46:50, Ethernet0/0
[90/435200] via 192.168.24.2, 02:46:50, Ethernet0/1

R4#show ip route 10.10.10.10
Routing entry for 10.10.10.10/32
Known via "eigrp 1", distance 90, metric 435200, type internal
Redistributing via eigrp 1
Advertised by bgp 100
Last update from 192.168.24.2 on Ethernet0/1, 02:47:15 ago
Routing Descriptor Blocks:
* 192.168.34.3, from 192.168.34.3, 02:47:15 ago, via Ethernet0/0
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
192.168.24.2, from 192.168.24.2, 02:47:15 ago, via Ethernet0/1
Route metric is 435200, traffic share count is 1
Total delay is 7000 microseconds, minimum bandwidth is 10000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

R4#traceroute
Protocol [ip]:
Target IP address: 10.10.10.10
Source address:
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 10.10.10.10
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.24.2 5 msec
192.168.34.3 1 msec
192.168.24.2 1 msec
2 192.168.13.1 1 msec
192.168.12.1 5 msec
192.168.13.1 4 msec

R4#show ip bgp 10.10.10.10
BGP routing table entry for 10.10.10.10/32, version 38
Paths: (2 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 1
Local
192.168.24.2 from 0.0.0.0 (4.4.4.4)
Origin IGP, metric 435200, localpref 100, weight 32768, valid, sourced, local, best
rx pathid: 0, tx pathid: 0x0

I see that through eigrp I have two equal path in load balance.

But when hit the network statement under bgp process, rightly it choose only on path through 192.168.24.2 next hop.

But the same destination have an other next hop 192.168.34.3 with the same metric (It is in eigrp topology as successor).

Re: BGP Network statement - IGP Equal path cost

Deepak Kumar — Sat, 23 Feb 2019 13:51:40 GMT

Hi,

For BGP routes only one of the interfaces/IP will be used as the best next hop. Once that interface is down it will pick the other interface but does not load balance between the interfaces. This is the default behavior of the BGP.

And Why 10.10.10.10 is advertised on R3 again?

Regards,

Deepak Kumar

Re: BGP Network statement - IGP Equal path cost

Americo Massotti — Sat, 23 Feb 2019 14:17:00 GMT

Hello Deepak.

thanks for your support.

Yes, I understand that choose only one, but my question is why 192.168.24.2 over 192.168.34.3? the metric is the same as you can see on routing table and eigrp topology table. Maybe it choose the lowest address?

And Why 10.10.10.10 is advertised on R3 again?

It's a topology that I see on INE video. We have multihomed AS. Maybe In the case R4 goes down, we advertise our network to outside anyway.

Re: BGP Network statement - IGP Equal path cost

Sergey Lisitsin — Sat, 23 Feb 2019 14:35:34 GMT

Well, you can clearly see, that you get load sharing for 10.10.10.10/32 prefix over EIGRP.

Re: BGP Network statement - IGP Equal path cost

Deepak Kumar — Sat, 23 Feb 2019 14:44:31 GMT

Hi,

There is something issue with your GNS3 or IOS. Because I have configured the same topology in my lab and I am getting correct result as

R4#traceroute 10.10.10.10
Type escape sequence to abort.
Tracing the route to 10.10.10.10
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.24.2 24 msec
    192.168.34.3 24 msec
    192.168.24.2 32 msec
  2 192.168.13.1 56 msec
    192.168.12.1 72 msec
    192.168.13.1 24 msec
R4#

R4#sho ip rou
R4#sho ip route

      10.0.0.0/32 is subnetted, 1 subnets
D        10.10.10.10 [90/158720] via 192.168.34.3, 00:02:21, FastEthernet0/0
                     [90/158720] via 192.168.24.2, 00:02:21, FastEthernet1/0

Restart your topology and check again.

Regards,

Deepak Kumar

Re: BGP Network statement - IGP Equal path cost

andresfr — Sun, 24 Feb 2019 07:02:35 GMT

Hi Americo,

I got your point:

R4# show ip bgp
BGP table version is 43, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network    Next Hop Metric    LocPrf    Weight Path
*> 10.10.10.10/32 192.168.24.2 435200 32768 i <--- Because of network command in R4
* i 192.168.13.1 409600    100    0 i
*> 20.20.20.20/32 192.168.24.2 435200 32768 i <--- Because of network command in R4
* i 192.168.13.1 409600    100    0 i
*> 30.30.30.30/32 192.168.24.2 435200 32768 i <--- Because of network command in R4
* i 192.168.13.1 409600    100    0 i

There are several things to notice to understand this scenario:

R1,R2,R3,R4 are in the same AS, so they are iBGP peers
You're having equal path (from IGP perspective) to Lo1,Lo2 and Lo3 on R1
An iBGP router will not advertise a route learned from an iBGP peer to another iBGP peer unless you use the route reflector feature, or in this case, since that same router are already being learned through and IGP (EIGRP) then you can use the BGP network command and it will work because BGP will find a valid EIGRP route in the routing table.
In this particular scenario you're using the network command under BGP on routers R1, R3, and R4 but not on R2. I would be interesting if you could check what happens when using the network command on routers R1, R2, and R3 but not on R4.
On R4, the path that is not selected as the best path by BGP is the one that you actually learn this router from R3 with next hop 192.168.13.1 after using the network command on R3 for 10.10.10.10/32 and the other prefixes. The path that is selected as the best path by BGP is the one through 192.168.24.2 and is as a result of the network commands on R4 that is causing this path to have a higher Weight attribute (32768) as if it were a locally originated network (but with next hop different from 0.0.0.0 since we've valid routes learned through EIGRP).

So the right question would be, why is R4 always selecting 192.168.24.2 as the next hop for those networks in R1 after using the network command for the same on R4 under BGP?

The answer seems to be that after issuing the network command under BGP router mode on R4 for those networks, BGP will always select as the next hop (between the posible paths) the lowest IP address. I did change segment between R3 and R4 to be 192.168.14.0/24 so it would be lower when compared to 192.168.24.0/24 and this is what I got (I did clear BGP):

R4#sh ip bgp
BGP table version is 4, local router ID is 4.4.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop    Metric LocPrf Weight Path
*> 10.10.10.10/32 192.168.14.3 131072 32768 i <----- Next hop is R3
* i    192.168.13.1 130816 100 0 i
*> 20.20.20.20/32 192.168.14.3 131072 32768 i <----- Next hop is R3
* i    192.168.13.1 130816 100 0 i
*> 30.30.30.30/32 192.168.14.3 131072 32768 i <----- Next hop is R3
* i    192.168.13.1 130816 100 0 i
R4#

I then changed the network segment between R2 and R4 to be 192.168.11.0/24 and R4 did choose R2 again (192.168.11.2 in my test) as the next hop.

I hope this helps.

Re: BGP Network statement - IGP Equal path cost

Americo Massotti — Sun, 24 Feb 2019 07:49:34 GMT

Hi Andres.

Thanks for your explanation. Cisco bgp implementantion seem to choose always the lowest ip address.

I tried to find some tech note about this behavior but I dont find it.

I was wondering if this behavior its only on Cisco devices but I think that other vendor implemented the same thing.

BGP must choose by default only one best path after analalyzing the ip routing table and in the case (as our case) we have multiple IGP equal path cost, maybe the next hop ip address is the only tie breaker (Cisco like as other vendor).

Thanks once again!

Edit: I tried to change the link R3-R4 on the subnet 192.168.23.0/24 (lowest against R2-R4 192.168.24.0/24) and the choose of R4 about the best path to install in bgp table about R1 loopback changed.

* i 10.10.10.10/32 192.168.13.1 409600 100 0 i
*> 192.168.23.3 435200 32768 i

Re: BGP Network statement - IGP Equal path cost

Deepak Kumar — Sun, 24 Feb 2019 09:14:29 GMT

Hi,

Sorry, I missed your statement "

But when hit the network statement under bgp process, rightly it choose only on path through 192.168.24.2 next hop.
But the same destination have an other next hop 192.168.34.3 with the same metric (It is in eigrp topology as successor)."

If you will check BGP best path selection process then the last decision point will be "Prefer The route with the lowest neighbor IP"

Here is the guide:

"https://www.ciscozine.com/bgp-best-path-selection/"

Regards,

Deepak Kumar

Re: BGP Network statement - IGP Equal path cost

Americo Massotti — Sun, 24 Feb 2019 10:26:15 GMT

Hello Deepak.

Thanks for your link.

But I thought that the best bgp path selection algorithm applies on the NLRI in the bgp table and after that choose the best path (*>) but the other IGP equal path cost never enter in the bgp table (Otherwise I have to see it as valid * but no best).

It's correct?

I think that in our case the only tiebreaker it's the lowest address, and the decision its out of the scope of the best BGP path selection algorithm.

Re: BGP Network statement - IGP Equal path cost

Deepak Kumar — Sun, 24 Feb 2019 11:13:52 GMT

Hi,

What is your mean by "other IGP equal path cost never enter in the bgp table (Otherwise I have to see it as valid * but no best)?"

Kindly explain bit more.

Regards,

Deepak Kumar

Re: BGP Network statement - IGP Equal path cost

andresfr — Sun, 24 Feb 2019 16:18:12 GMT

I'm glad we figure it out.

I didn't find any documentation regarding this behavior and I've not tested with other vendors, but it seems to be consistent with Cisco devices running IOS.
Regards,