BGP does not advertise iBGP-learned routes to eBGP peers?

Theoretically, BGP does not advertise iBGP-learned routes to eBGP peers. Hence, I did not filter iBGP learned routes to my eBGP peers. I didn't realise my eBGP router did advertise these iBGP routes (not meant for transit) until our partner informed me and I did a "show ip bgp vpnv4 VRF-name neighbors 1.1.1.1 advertised-routes" to verify. So, is this theory wrong?

Well, it comes with a caveat. This theory is true only if BGP synchronisation is enabled. The rule of synchronization states that routes learned via BGP must be validated by the interior routing table before they can be advertised to remote peers. So, what does this mean? Click here for explanation.

In older Cisco IOS versions, Synchronization is enabled by default. However, it is disabled by default in Cisco IOS Software Release 12.2(8)T and later. If you do not intend for the iBGP learnt routes to be on transit among different AS, it is probably safer to enable BGP synchronization.

Use BGP maximum-paths eibgp with Caution

Under the BGP command process, "maximum-paths" enables BGP to perform load-sharing among multiple paths. There are 3 options:

1. maximum-paths: only allow equal-cost path load-sharing
2. maximum-paths ibgp: enable both equal-cost and unequal-cost path load-sharing for internal BGP
3. maximum-paths eibgp: enable both equal-cost and unequal-cost path load-sharing for both internal and external BGP

If you have 2 or more edge BGP routers on same AS and is using both iBGP and eBGP, use the "maximum-paths eibgp" with caution. The Cisco routers would assign iBGP routes with same administrative distance (i.e. 20) as eBGP. You could end up with a routing loop if you design eBGP to be preferred over iBGP paths.

Load Sharing in MPLS VPN with Route Reflector

No matter what I did according to this Cisco article, I simply can't do load-sharing among the PE routers within our enterprise MPLS VPN. The central Route Reflector (RR) simply refuses to send more than 1 identical route, even though I have multiple PE routers attached to that route.

Subsequently, I come across this excellent MPLS VPN blog. It explains that there is no way to change the route reflector behavior.  The workaround is to simply assign different Route Distinguisher (RD) values for the same VRF on different routers. To enable route propagation, ensure that you export and import common Route Target (RT) across the PE routes. Finally, enable "maximum-paths eibgp " on each vpnv4 address family under the router bgp process, so as to inject more than one bgp route into the routing table.

And it works magic!

Example configuration according to above diagram

On Router PE A

ip vrf VRF_A

  rd 65001:101

 route-target both 65001:100

  .....

router bgp 65001

  address-family ipv4 vrf VRF_A

  maximum-paths eibgp 4

On Router PE B

ip vrf VRF_A

  rd 65001:102

 route-target both 65001:100

.....

router bgp 65001

  address-family ipv4 vrf VRF_A

  maximum-paths eibgp 4

On Router PE C

ip vrf VRF_A

  rd 65001:101

 route-target both 65001:100

  .....

router bgp 65001

  address-family ipv4 vrf VRF_A

  maximum-paths eibgp 4

On Router PE D

ip vrf VRF_A

  rd 65001:102

 route-target both 65001:100

.....

router bgp 65001

  address-family ipv4 vrf VRF_A

  maximum-paths eibgp 4

Route filtering using route tags

In enterprise routing, route-filtering is often used to prevent routing loops and sometimes for security reasons. Instead of solely relying on ip access-list and addresses, route filtering can also be performed by route tagging. In fact, this method is more scable for a larger network when managing access-lists can be a challenge over a large number of routers. Consider this corporate network (see below pic). The corporate has 3 remote sites with IP subnets of 1.1.1.0, 2.2.2.0 and 3.3.3.0 respectively. You have a corporate policy that states Network A should link to all 3 remote sites via ISP X. Network B should link to the first 2 remote sites via leased lines and the last remote site via ISP X only. Network A is peered with ISP X on eBGP. IGP between internal networks is OSPF and remote sites via leased line is RIP. To implement such routing policy using route-tag:

1. Router A


2. access-list 1 permit 1.1.1.0 255.255.255.0


3. access-list 1 permit 2.2.2.0 255.255.255.0


4. access-list 2 permit 3.3.3.0 255.255.255.0


5. !


6. route-map route-tag permit 10 ‌


7. match ip address 1 ‌


8. set tag 111 --tag the 1st two remote sites with 111


9. !


10. route-map route-tag permit 20 ‌


11. match ip address 2 ‌


12. set tag 222 -- tag the 3rd remote site with 222


13. !


14. route-map route-tag permit 30 -- without this, all other routes will be dropped


15. !


16. router ospf 1 ‌


17. redistribute bgp 65001 subnets route-map route-tag -- redistribute ISP routes into IGP


18. ...


19. ...


20. Router B


21. route-map tag-filter deny 10 ‌


22. match tag 111 -- filter off sites with tag 111


23. !


24. route-map tag-filter permit 20 ‌


25. match tag 222 --permit only sites with tag 222


26. !


27. router ospf 2 ‌


28. distribute-list route-map tag-filter in

To verify, perform the necessary "show ip route" commands on both router A and B to ensure the route entries are in order. Do note that tagging does not work with BGP. The alternative in BGP is to use community string in AA:NN format (e.g. 100:300). For the adverting routers (typically on customer edge), use "set community" in place of "set tag" in the route-map statement. For the recieving routers (typically on provider edge), use "ip community-list" to describe the community string and "match community". For further example on using BGP community, see this Cisco example.

Internet Load Balancing for Dual WAN Links to ISP

Recently, the WAN upgrade to our ISP is complete with dual redundant paths. We were asked if we could allow our Internet surfing users utilizing both links as much as possible instead of leaving one link to be idle most of the time. At the same time, it must not break the existing path redundancy. Since BGP rules Internet routing, we are using it to our advantage.

Below is the simplified network diagram to keep this discussion simple. (Click to enlarge)


Our 2 routers and the provider's routers are peered in full mesh eBGP. We advertised our public IP subnet (say 160.1.1.0/29) to the world via the 2 ISP routers (i.e. ISP R1 and ISP R2). By default in BGP, only 1 best route (i.e. default route) from either ISP R1 or ISP R2 is chosen as the path to the Internet. To influence the routing behavior, AS path prepend is used to influence inbound traffic and local preference to outbound traffic. As for load-balancing, whatever traffic that entered via R1 will route through ISP R1 and the similar applies to R2. This is our strategy for ISP link load-balancing:

1. We further break our public IP subnet into 2 halves i.e. 160.1.1.0/30 and 160.1.1.4/30 and advertise them via both R1 and R2.
2. On R1, we prepend AS path on advertised route 160.1.1.4/30 to make it less desirable for inbound traffic to use this route via R1. On R2, we prepend AS path on route 160.1.1.0/30.
3. On R1, higher local preference is set for default route (0.0.0.0/32) advertised from ISP R1. Hence, ISP R1 will be the preferred next-hop for all outbound Internet traffic entered via R1. As for R2, the next preferred next-hop will be ISP R2.
4. In summary, the path will become R1 <-> ISP R1 and R2 <-> ISP R2. We influence inbound traffic by making the other route less attractive and outbound traffic by making the route more attractive. If either R1 or R2 link were down, the remaining active link will take over all the traffic.

As for load-balancing between our routers (R1 & R2), it is more straightforward. Have both routers to advertise default route (on same metric) into the IGP (e.g. OSPF or RIP) by using "default information-orginate" router command. Alternatively, you may prefer GLBP (Gateway Load Balancing Protocol) for multiple clients.

The diagram (courtesy from my colleague MT) below illustrates the BGP load-balancing concept described above. (Click to enlarge)


Any sample configuration? Here you are:

On R1:
router bgp 65001
bgp router-id 172.16.1.1
bgp log-neighbor-changes
no auto-summary
neighbor 172.16.1.3 remote-as 65002
neighbor 172.16.1.3 route-map R1-ISPR1-MAP out # apply AS path prepend
neighbor 172.16.1.3 activate
neighbor 172.16.1.4 remote-as 65002
neighbor 172.16.1.4 route-map ISPR1-R1-MAP in # set higher local preference
neighbor 172.16.1.4 activate
no synchronization
network 160.1.1.0 mask 255.255.255.252 # route advertisement
network 160.1.1.4 mask 255.255.255.252
!
# exact routes must exist before they can be advertised in eBGP!
# since we are using NAT, just create some "phantom" routes
ip route 160.1.1.0 255.255.255.252 null0
ip route 160.1.1.4 255.255.255.252 null0
!
!
# Use NAT overload for internal users accessing Internet
ip nat pool INET_POOL 160.1.1.1 160.1.1.1 netmask 255.255.255.252
ip nat inside source list INSIDE_VLAN pool INET_POOL overload
!
ip access-list standard INSIDE_VLAN
permit 192.168.2.0 0.0.0.63
!
access-list 11 permit 160.1.1.0 0.0.0.3
access-list 12 permit 160.1.1.4 0.0.0.3
!
#make certain route advertised by this router less desirable
#to influence inbound traffic
route-map R1-ISPR1-MAP permit 10
match ip address 12
set as-path prepend 65001 65001 65001
!
route-map R1-ISP1-MAP permit 20
match ip address 11
!
#prefer default route from specific ISP router to influence outbound traffic
route-map ISPR1-R1-MAP permit 10
set local-preference 200

On R2:
router bgp 65001
bgp router-id 172.16.1.2
bgp log-neighbor-changes
no auto-summary
neighbor 172.16.1.3 remote-as 65002
neighbor 172.16.1.3 route-map ISPR2-R2-MAP in
neighbor 172.16.1.3 activate
neighbor 172.16.1.4 remote-as 65002
neighbor 172.16.1.4 route-map R2-ISPR2-MAP out
neighbor 172.16.1.4 activate
no synchronization
network 160.1.1.0 mask 255.255.255.252
network 160.1.1.4 mask 255.255.255.252
!
ip route 160.1.1.0 255.255.255.252 null0
ip route 160.1.1.4 255.255.255.252 null0
!
!
ip nat pool INET_POOL 160.1.1.5 160.1.1.5 netmask 255.255.255.252
ip nat inside source list INSIDE_VLAN pool INET_POOL overload
!
ip access-list standard INSIDE_VLAN
permit 192.168.2.0 0.0.0.63
!
access-list 11 permit 160.1.1.0 0.0.0.3
access-list 12 permit 160.1.1.4 0.0.0.3
!
route-map R2-ISPR2-MAP permit 10
match ip address 11
set as-path prepend 65001 65001 65001
!
route-map R2-ISP2-MAP permit 20
match ip address 12
!
route-map ISPR2-R2-MAP permit 10
set local-preference 200