BGP Additional-paths vs. Multipath
In the following post we're going to take a look at these two features: what are their purpose and in which situations can they be useful. BGP Multipath provides load balancing. Additional-paths provide high availability primarily, and it is used to avoid sub-optimal routing in a Route Reflector (RR) environment. Optionally we can also install a backup path into the forwarding table to reduce convergence time in case the primary path fails.
BGP Additional-paths
What's the problem with the topology below? We have a Route Reflector (R1) which has five clients (R3, R5, R7, R8 and R9). So we have five BGP sessions between the edge routers and the RR, the edge routers don't have BGP neighborship with each other, they only receive/send prefixes to/from the RR. R10 advertises a single prefix 10.10.10.10/32 from AS 65002 in this topology.
So the RR receives the prefix from R3 (10.3.3.3) R5 (10.5.5.5) and R7 (10.7.7.7):
R1#show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path * i 10.10.10.10/32 10.7.7.7 0 100 0 65002 i * i 10.5.5.5 0 100 0 65002 i *>i 10.3.3.3 0 100 0 65002 i
The RR, just like any other BGP router selects his best path to reach the destination. R1 chooses R3 as the exit point to reach AS 65002. Why did R1 choose R3? Basically all of the path attributes are the same, the IGP metric to reach the next-hop is the tiebreaker here:
R1#show bgp ipv4 unicast 10.10.10.10/32BGP routing table entry for 10.10.10.10/32, version 2Paths: (3 available, best #3, table default) Advertised to update-groups: 1 2 Refresh Epoch 1 65002, (Received from a RR-client) 10.7.7.7 (metric 5) from 10.7.7.7 (10.7.7.7) Origin IGP, metric 0, localpref 100, valid, internal rx pathid: 0, tx pathid: 0 Refresh Epoch 1 65002, (Received from a RR-client) 10.5.5.5 (metric 4) from 10.5.5.5 (10.5.5.5) Origin IGP, metric 0, localpref 100, valid, internal rx pathid: 0, tx pathid: 0 Refresh Epoch 1 65002, (Received from a RR-client) 10.3.3.3 (metric 3) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
The lowest IGP metric (OSPF cost in this case) is preferred to reach the next-hop. R3 has the lowest metric (cost of 3), so R1 chooses 10.3.3.3 as the next-hop for his best path. What does R1 reflect to his RR-client? Only his best path with 10.3.3.3 as the next-hop:
R9#show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 100 0 65002 iR8#show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 100 0 65002 i
R8 and R9 have no idea about that they could also use R5 and R7 as an exit point to reach AS 65002. So this results in sub-optimal routing: for example if R9 wanted to reach AS 65002, we would use the following path R9 -> R4 -> R2 -> R3. (In my case R4 and R2 don't have route to 10.10.10.10/32 because they don't run BGP, so they would simply drop the packet in this case. That's not the point here. Let's assume that we run MPLS in the core, and we provide an L3VPN service for AS 65002, in that case we would switch labels in the core, so the 'P' routers don't need to have the customer routes and run BGP at all.) The point is that the RR only reflects the best path from HIS perspective to the edge routers. So the RR sends only ONE path, the other edge routers, R8 and R9 have no visibility of the other exit points such as R5 and R7.
With the Additional-paths capability the RR can send not just his best path, but also the other paths which he has in his BGP table. The additional-paths capability must be enabled both on the RR and on the edge routers as well. First let's enable it on the RR:
R1(config)#router bgp 65001R1(config-router)#address-family ipv4 unicast R1(config-router-af)#neighbor 10.8.8.8 additional-paths ? disable Disable additional paths for this neighbor receive Receive additional paths from neighbors send Send additional paths to this neighborR1(config-router-af)#neighbor 10.8.8.8 additional-paths send ? receive Receive additional paths from this neighbor <cr> <cr>R1(config-router-af)#neighbor 10.8.8.8 additional-paths sendR1(config-router-af)#neighbor 10.9.9.9 additional-paths send
On the RR we need the send capability, while on the edge routers we're going to activate the receive capability. We can also enable both if we want, but that's not needed in this case. On the edge routers we need the receive capability:
R8(config)#router bgp 65001R8(config-router)#address-family ipv4 unicast R8(config-router-af)#neighbor 10.1.1.1 additional-paths receiveR9(config)#router bgp 65001R9(config-router)#address-family ipv4 unicast R9(config-router-af)#neighbor 10.1.1.1 additional-paths receive
Now I do this for the IPv4 unicast address family, but we can also enable this feature for other address families as well if we want (VPNv4 for example). Here I enabled the feature for a single neighbor, but we can also enable it globally for the whole address family with the bgp additional-paths send|receive command. Also notice that these capabilities will be negotiated in the BGP OPEN messages, which results in a session flap:
BGP-5-ADJCHANGE: neighbor 10.8.8.8 Down Capability changedBGP_SESSION-5-ADJCHANGE: neighbor 10.8.8.8 IPv4 Unicast topology base removed from session Capability changedBGP-5-ADJCHANGE: neighbor 10.8.8.8 Up BGP-5-ADJCHANGE: neighbor 10.9.9.9 Down Capability changedBGP_SESSION-5-ADJCHANGE: neighbor 10.9.9.9 IPv4 Unicast topology base removed from session Capability changedBGP-5-ADJCHANGE: neighbor 10.9.9.9 Up
We can also verify the additional-paths capabilities with the following command:
R1#show ip bgp neighbors 10.8.8.8 | include Additional Additional Paths send capability: advertised Additional Paths receive capability: received
Now we need to select which paths we want to advertise on the RR:
R1(config-router-af)#bgp additional-paths select ? all Select all available paths backup Select backup path best Select best N paths best-external Select best-external path group-best Select group-best pathR1(config-router-af)#bgp additional-paths select allR1(config-router-af)#neighbor 10.8.8.8 advertise additional-paths ? all Select all available paths best Select best N paths group-best Select group-best pathsR1(config-router-af)#neighbor 10.8.8.8 advertise additional-paths all
With the all option we simply select all paths which are available (and valid) in the BGP table, even if they have different next-hops. Alternatively with the best option we could select the second or the second and third best paths as well. So we can send two or three more paths in addition to the best path. The group-best option selects the best path from each AS. The backup option is mainly used with PIC, and we'll take a closer look at the best-external later. Now if we take a look at the BGP table of the RR:
R1(config-router-af)#do show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path * ia 10.10.10.10/32 10.7.7.7 0 100 0 65002 i * ia 10.5.5.5 0 100 0 65002 i *>i 10.3.3.3 0 100 0 65002 i
R1(config-router-af)#do show bgp ipv4 unicast 10.10.10.10BGP routing table entry for 10.10.10.10/32, version 6Paths: (3 available, best #3, table default) Path advertised to update-groups: 4 Refresh Epoch 1 65002, (Received from a RR-client) 10.7.7.7 (metric 5) from 10.7.7.7 (10.7.7.7) Origin IGP, metric 0, localpref 100, valid, internal, all rx pathid: 0, tx pathid: 0x1 Path advertised to update-groups: 4 Refresh Epoch 1 65002, (Received from a RR-client) 10.5.5.5 (metric 4) from 10.5.5.5 (10.5.5.5) Origin IGP, metric 0, localpref 100, valid, internal, all rx pathid: 0, tx pathid: 0x2 Path advertised to update-groups: 1 2 4 Refresh Epoch 1 65002, (Received from a RR-client) 10.3.3.3 (metric 3) from 10.3.3.3 (10.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal, best rx pathid: 0, tx pathid: 0x0
We have an 'a' in front of every row, meaning these routes can be sent as additional-paths. This doesn't necessarily mean that the router sends all three paths for all of his neighbors. Notice the different path IDs: this is what differentiates the paths and makes them unique. Now let's take a look at the routes we send to R8 (Adj-RIB-Out):
R1#show ip bgp neighbors 10.8.8.8 advertised-routes | begin Netw Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 100 0 65002 i * ia 10.10.10.10/32 10.7.7.7 0 100 0 65002 i * ia 10.10.10.10/32 10.5.5.5 0 100 0 65002 iTotal number of prefixes 3
As we've expected the RR now advertises all three paths to R8. This is because we've issued the neighbor 10.8.8.8 advertise additional-paths allcommand. This is how the BGP Update looks like, notice the different path IDs, this indicates that we use additional-paths.
If we take a look at the advertised routes to R9:
R1#show ip bgp neighbors 10.9.9.9 advertised-routes | begin Netw Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 100 0 65002 iTotal number of prefixes 1
We can see that the RR only advertises a single path for R9. This is because we didn't issue the previous command for R9, so let's do that:
R1(config-router-af)#neighbor 10.9.9.9 advertise additional-paths all
Now R1 sends all three paths to both R8 and R9, and they can select the best path from THEIR perspective. R8 and R9 select the path with the next-hop 10.5.5.5 instead of the path through 10.3.3.3, because their IGP metric to R5 is lower than the IGP metric to R3 (3 vs. 4).
PIC Edge
But this doesn't necessarily mean that R8 and R9 can use these path as backup paths for example. If we check the BGP table of R8, we can see that now R8 receives all three paths:
R8#show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path * i 10.10.10.10/32 10.7.7.7 0 100 0 65002 i *>i 10.5.5.5 0 100 0 65002 i * i 10.3.3.3 0 100 0 65002 i
That looks good, R8 has now full visibility, and instead of R3, now he chooses R5 as his exit-point because of the lower IGP metric. But we can also go one step further. At this point only a single route is installed into the FIB with a next-hop of 10.5.5.5. We can also install a backup path into the FIB so that if R5 fails, the backup path can be used right away:
R8(config-router)#address-family ipv4 unicast R8(config-router-af)#bgp additional-paths select allR8(config-router-af)#bgp additional-paths install
Now if we take a look at the BGP table we can see the 'a's and also a 'b' meaning that this path can be used as the backup path:
R8(config-router-af)#do show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path *bia 10.10.10.10/32 10.7.7.7 0 100 0 65002 i *>i 10.5.5.5 0 100 0 65002 i * ia 10.3.3.3 0 100 0 65002 iR8(config-router-af)#do show bgp ipv4 unicast 10.10.10.10/32BGP routing table entry for 10.10.10.10/32, version 6Paths: (3 available, best #2, table default) Additional-path-install Path not advertised to any peer Refresh Epoch 4 65002 10.7.7.7 (metric 3) from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, backup/repair, all Originator: 10.7.7.7, Cluster list: 10.1.1.1 rx pathid: 0x1, tx pathid: 0x1 Path advertised to update-groups: 6 Refresh Epoch 4 65002 10.5.5.5 (metric 3) from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best Originator: 10.5.5.5, Cluster list: 10.1.1.1 rx pathid: 0x2, tx pathid: 0x0 Path not advertised to any peer Refresh Epoch 4 65002 10.3.3.3 (metric 4) from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, all Originator: 10.3.3.3, Cluster list: 10.1.1.1 rx pathid: 0x0, tx pathid: 0x2
This feature is called PIC (Prefix Independent Convergence), and it helps reduce the data plane convergence time. In addition to 10.5.5.5, also 10.7.7.7 is installed into the FIB and can be used instantly in case R5 fails. Notice that we don't use load-balancing or Multipath at this point, 10.7.7.7 can only be used as the backup path.
BGP best external
Let's say that we want to use an outbound policy: we want to use R3 as our primary exit-point within the whole AS. So on R3 I increase the Local Preference attribute (100 is the default, we need a higher value) for the prefix 10.10.10.10/32:
R3(config)#ip prefix-list R10LOOP permit 10.10.10.10/32R3(config)#route-map SET_LP permit 10R3(config-route-map)#match ip address prefix-list R10LOOPR3(config-route-map)#set local-preference 101R3(config-route-map)#exitR3(config)#route-map SET_LP permit 20R3(config-route-map)#exitR3(config)#router bgp 65001R3(config-router)#neighbor 172.3.10.10 route-map SET_LP inR3(config-router)#do clear ip bgp * inR3(config-router)#do clear ip bgp * out
But this change affects the whole AS, not just R3. Now R5 and R7 also prefer R3 (10.3.3.3) to their eBGP neighbors:
R5#show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 101 0 65002 i * 172.5.10.10 0 0 65002 iR7#show bgp ipv4 unicast | begin Net Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 101 0 65002 i * 172.7.10.10 0 0 65002 i
By default they can only advertise their best path, since their best path is an iBGP path, they don't advertise the path which they got from their eBGP neighbors (175.5.10.10 and 172.7.10.10). So the RR only has a single path though R3 to reach 10.10.10.10/32:
R1#show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path *>i 10.10.10.10/32 10.3.3.3 0 101 0 65002 i
The RR has no idea that he could also use R5 and R7 as next-hops to reach 10.10.10.10/32. With the advertise-best-external feature we can make R5 advertise his eBGP path for the RR, even if R5 doesn't use his eBGP peer to reach the prefix. It's a single command which can be configured under the address family:
R5(config)#router bgp 65001R5(config-router)#address-family ipv4 unicast R5(config-router-af)#bgp advertise-best-external
Now R5 advertises his eBGP path, even though R5 uses an iBGP path to reach the prefix:
R5#show ip bgp neighbors 10.1.1.1 advertised-routes BGP table version is 4, local router ID is 10.5.5.5Status 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, t secondary path, Origin codes: i - IGP, e - EGP, ? - incompleteRPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *b x 10.10.10.10/32 172.5.10.10 0 0 65002 iTotal number of prefixes 1
The 'x' in front of the prefix indicates R5 uses the best-external feature. Now the RR receives the path from R5 and with the additional-paths feature it can also send it to R8, who can use the path as the backup path:
R1#show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path * ia 10.10.10.10/32 10.5.5.5 0 100 0 65002 i *>i 10.3.3.3 0 101 0 65002 iR8#show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path *bia 10.10.10.10/32 10.5.5.5 0 100 0 65002 i *>i 10.3.3.3 0 101 0 65002 i
Notice that R8 will also use R3 as the next-hop because of the higher Local Preference. This time the IGP metric isn't compared, the LP has way more priority than IGP metric (it's the second most influential path attribute after Weight).
BGP Multipath
eBGP Multipath
To demonstrate the BGP Multipath feature we're going to use a new topology, where R13 advertises a single prefix 13.13.13.13/32 in AS 65004:
BGP Multipath works the same way just as OSPF for example: it can install multiple routes into the RIB also into the FIB and provide load-balancing. But the BGP Multipath feature is disabled by default, we have to manually enable it. Unlike OSPF, BGP can actually support unequal-cost load balancing (UCMP - Unequal-Cost Multiple Path), not just ECMP (Equal-Cost Multiple Path), but this time we're only focusing on ECMP.
So when can we use ECMP? The following attributes must match: Weight, Local Preference, AS-Path sequence (not just the length of the AS-Path!), Origin code, MED, and also the IGP metric in case of iBGP routes. Let's take a look at the BGP table of R3:
R3#show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path * 13.13.13.13/32 172.3.12.12 0 65003 65004 i * 172.3.11.11 0 65002 65004 i *> 172.3.10.10 0 65002 65004 i
R3 chooses R10 as the next-hop. We have no tiebreaker here, every attribute is the same, probably R3 received the NLRI from R10 first, and picked R10 because it's the oldest route. Now let's enable ECMP, similarly to OSPF and other IGPs we do this with the maximum-paths command:
R3(config)#router bgp 65001R3(config-router)#address-family ipv4 unicastR3(config-router-af)#maximum-paths ? <1-32> Number of paths eibgp Both eBGP and iBGP paths as multipath ibgp iBGP-multipathR3(config-router-af)#maximum-paths 4
With the maximum-paths 4 command we can install up to four eBGP routes into the RIB. If we want to provide ECMP among iBGP paths we have to use the ibgp keyword, with the eibgp option we can do load balancing among different iBGP and eBGP paths. After issuing the command above, R3 now selects the path via R11 as a multipath route, and installs the next-hop of R11 into the routing table:
R3(config-router-af)#do show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path * 13.13.13.13/32 172.3.12.12 0 65003 65004 i *m 172.3.11.11 0 65002 65004 i *> 172.3.10.10 0 65002 65004 iR3(config-router-af)#do show ip bgp 13.13.13.13/32BGP routing table entry for 13.13.13.13/32, version 3Paths: (3 available, best #3, table default)Multipath: eBGP Advertised to update-groups: 1 2 Refresh Epoch 1 65003 65004 172.3.12.12 from 172.3.12.12 (172.12.13.12) Origin IGP, localpref 100, valid, external rx pathid: 0, tx pathid: 0 Refresh Epoch 1 65002 65004 172.3.11.11 from 172.3.11.11 (10.11.11.11) Origin IGP, localpref 100, valid, external, multipath(oldest) rx pathid: 0, tx pathid: 0 Refresh Epoch 1 65002 65004 172.3.10.10 from 172.3.10.10 (10.10.10.10) Origin IGP, localpref 100, valid, external, multipath, best rx pathid: 0, tx pathid: 0x0R3(config-router-af)#do show ip route bgp | begin GateGateway of last resort is not set 13.0.0.0/32 is subnetted, 1 subnetsB 13.13.13.13 [20/0] via 172.3.11.11, 00:02:10 [20/0] via 172.3.10.10, 00:02:10
Why can't R3 use R12 for multipath? Take a look at the AS-Path: although the length is the same the AS-Path itself is different, and we need the same AS Sequence. The same thing we have with the MED attribute: we can only compare the MED values, if the NLRIs came from the same AS, MED values cannot be compared if the AS-Path is different. Actually there's a hidden command to disable this feature, it won't be displayed if we use '?' for context-sensitive help:
R3(config-router)#bgp bestpath ? aigp if both paths doesn't have aigp ignore on bestpath comparision compare-routerid Compare router-id for identical EBGP paths cost-community cost community med MED attributeR3(config-router)#bgp bestpath as-path multipath-relax
It's not recommended to use this feature, but now R3 can also use R12 for multipath, and install a third route into the forwarding table for load-balancing:
R3(config-router)#do show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path *m 13.13.13.13/32 172.3.12.12 0 65003 65004 i *m 172.3.11.11 0 65002 65004 i *> 172.3.10.10 0 65002 65004 iR3(config-router)#do show ip route bgp | begin GateGateway of last resort is not set 13.0.0.0/32 is subnetted, 1 subnetsB 13.13.13.13 [20/0] via 172.3.12.12, 00:01:25 [20/0] via 172.3.11.11, 00:01:25 [20/0] via 172.3.10.10, 00:01:25
iBGP Multipath
The BGP table of R8 looks like this at the moment:
R8#show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path *bia 13.13.13.13/32 10.7.7.7 0 100 0 65002 65004 i *>i 10.5.5.5 0 100 0 65002 65004 i * ia 10.3.3.3 0 100 0 65002 65004 i
Although R8 received additional paths from the Route Reflector, because we configured it previously, R8 can select only a single route. Notice that the 'b' only means backup route, although it has been installed into the forwarding table in addition to the next-hop of 10.5.5.5, R8 cannot actively use it and do load-balancing. The backup path only helps to reduce the convergence time in case 10.5.5.5 fails. If we want to configure multipath for iBGP routes we have to use the ibgp keyword with the maximum-paths command:
R8(config)#router bgp 65001R8(config-router)#address-family ipv4 unicast R8(config-router-af)#maximum-paths ? <1-32> Number of paths eibgp Both eBGP and iBGP paths as multipath ibgp iBGP-multipathR8(config-router-af)#maximum-paths ibgp ? <1-32> Number of pathsR8(config-router-af)#maximum-paths ibgp 4
Remember for iBGP routes besides the Weight, Local Preference, AS-Path, Origin code and MED, also the IGP metric must match. R8 has the OSPF cost of 3 to reach 10.5.5.5 and also the cost of 3 to reach 10.7.7.7, so R8 can use these two iBGP paths for load-balancing. R8 cannot use R3 for iBGP multipath, because it has a higher IGP metric (cost of 4).
R8(config-router-af)#do show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path *mia 13.13.13.13/32 10.7.7.7 0 100 0 65002 65004 i *>i 10.5.5.5 0 100 0 65002 65004 i * ia 10.3.3.3 0 100 0 65002 65004 iR8(config-router-af)#do show ip bgp 13.13.13.13/32BGP routing table entry for 13.13.13.13/32, version 5Paths: (3 available, best #2, table default)Multipath: iBGP Additional-path-install Path not advertised to any peer Refresh Epoch 1 65002 65004 10.7.7.7 (metric 3) from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, multipath(oldest), all Originator: 10.7.7.7, Cluster list: 10.1.1.1 rx pathid: 0x2, tx pathid: 0x2 Path not advertised to any peer Refresh Epoch 1 65002 65004 10.5.5.5 (metric 3) from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, multipath, best Originator: 10.5.5.5, Cluster list: 10.1.1.1 rx pathid: 0x1, tx pathid: 0x0 Path not advertised to any peer Refresh Epoch 1 65002 65004 10.3.3.3 (metric 4) from 10.1.1.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, all Originator: 10.3.3.3, Cluster list: 10.1.1.1 rx pathid: 0x0, tx pathid: 0x1R8(config-router-af)#do show ip route bgp | begin GateGateway of last resort is not set 13.0.0.0/32 is subnetted, 1 subnetsB 13.13.13.13 [200/0] via 10.7.7.7, 00:02:33 [200/0] via 10.5.5.5, 00:02:33
eiBGP Multipath
It's also possible to do load-balancing among different eBGP and iBGP paths as well, in this case we have to use the eibgp keyword with the maximum-paths command. R5 has currently five paths to reach the prefix 13.13.13.13/32:
R5(config-router-af)#do show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path * ia 13.13.13.13/32 10.7.7.7 0 100 0 65002 65004 i * ia 10.3.3.3 0 100 0 65002 65004 i * a 172.5.12.12 0 65003 65004 i *b a 172.5.11.11 0 65002 65004 i *> 172.5.10.10 0 65002 65004 i
R5 has both eBGP and iBGP paths because we configured additional paths on the Route Reflector. The IGP metrics for the iBGP routes are the same. Although it's not displayed, the Local Preference is also 100 and the MED is 0 by default for the eBGP routes, so we can use load-balancing. Notice that the route with the next-hop 172.5.12.12 has a different AS-Path, so we cannot select R12 for multipath.
R5(config-router-af)#maximum-paths ? <1-32> Number of paths eibgp Both eBGP and iBGP paths as multipath ibgp iBGP-multipathR5(config-router-af)#maximum-paths eibgp ? <1-32> Number of pathsR5(config-router-af)#maximum-paths eibgp 4%BGP: This may cause traffic loop if not used properly (command accepted)%BGP-4-MULTIPATH_LOOP: This may cause traffic loop if not used properly (command accepted).R5(config-router-af)#do show ip bgp | begin Net Network Next Hop Metric LocPrf Weight Path *mia 13.13.13.13/32 10.7.7.7 0 100 0 65002 65004 i *mia 10.3.3.3 0 100 0 65002 65004 i * a 172.5.12.12 0 65003 65004 i *m a 172.5.11.11 0 65002 65004 i *> 172.5.10.10 0 65002 65004 iR5(config-router-af)#do show ip route bgp | begin GateGateway of last resort is not set 13.0.0.0/32 is subnetted, 1 subnetsB 13.13.13.13 [20/0] via 172.5.11.11, 00:01:31 [20/0] via 172.5.10.10, 00:01:31 [20/0] via 10.7.7.7, 00:01:31 [20/0] via 10.3.3.3, 00:01:31
Notice that the AD for the iBGP paths has been reduced to 20, so that also the iBGP paths can be installed into the RIB. Remember that the usual BGP path selection rules still prevail: eBGP routes will be selected first (if they have the same attributes), if there aren't any eBGP routes left, or the remaining eBGP paths cannot be selected for multipath (because of different path attributes), only then will the router pick the iBGP routes.