Routes learned from iBGP are not maintaining Metrics when advertised to eBGP peers
Doing some testing on FRR here, and hoping for some assistance. Hopefully this is the right place to go. If not, please let me know! I've got 3 remote iBGP peers that are configured as standard iBGP peers. These two iBGP peers learn some routes locally and then re-advertise these prefixes over a full-mesh iBGP network to each other, with FRR being one of the four routers in the mesh. The other three iBGP peers are Cisco. FRR has one eBGP peer, to replicate re-advertising these routes out to iBGP. In our other three iBGP peers, we leverage route-maps to increment the received MED value of the route, so that we can prefer locally received eBGP routes - all else being equal - as opposed to those learned from our iBGP speakers in other locations. We also do this so locally originated prefixes from our AS have a higher metric when going out to eBGP speakers so they don't inadvertently get preferenced when there's a better path for the route to take. I am receiving the routes from our iBGP speakers fine, and see the incremented MED on receipt of the routes from the aforementioned speaker. When I configure a local (to FRR) iBGP speaker as a route-reflector-client within the same AS, these pre-incremented MED's are correctly advertised to the local iBGP speaker and work just fine. When advertising these same prefixes to an eBGP speaker with a different AS, the metric's are not readvertised, and only a locally originated prefix maintains any sort of metric at all. Route's received from one of our remote iBGP speakers: routert# sh bgp ipv4 unicast neighbors 1.1.1.1 received-routes BGP table version is 0, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 1.1.1.1 100 100 0 i *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678 i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i Total number of prefixes 6 Route's being correctly re-advertised and maintaining metric on re-advertisement to our local iBGP speaker (route-reflector-client): router# sh bgp ipv4 unicast neighbors 3.3.3.3 advertised-routes BGP table version is 4560509, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 1.2.7.0/23 2.2.2.2 0 100 32768 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i Total number of prefixes 6 Route's not maintaining their metric on re-advertisement to our local (to FRR) eBGP speaker: router# sh bgp ipv4 unicast neighbors 8.8.8.8 advertised-routes BGP table version is 4562244, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 0.0.0.0 100 0 i *> 1.2.7.0/23 0.0.0.0 0 32768 i *> 2.3.4.0/21 0.0.0.0 100 0 5678i *> 3.4.5.0/24 0.0.0.0 100 0 5678 i *> 5.6.7.0/22 0.0.0.0 100 0 5678 i *> 7.8.9.0/24 0.0.0.0 100 0 5678 i Total number of prefixes 6 Am I doing something wrong here? Otherwise a pretty straight forward BGP setup with some basic route-maps in and out, nothing too crazy. Is this expected behavior in FRR? Running latest available stable release, FRRouting 7.1RPKI. Thanks for any help.
My memory is we don't send the med to eBGP peers... See https://tools.ietf.org/html/rfc4451#section-3.1 Lou ---------- On October 23, 2019 8:31:52 AM Lee Clements <lclements0@gmail.com> wrote:
Doing some testing on FRR here, and hoping for some assistance. Hopefully this is the right place to go. If not, please let me know!
I've got 3 remote iBGP peers that are configured as standard iBGP peers. These two iBGP peers learn some routes locally and then re-advertise these prefixes over a full-mesh iBGP network to each other, with FRR being one of the four routers in the mesh. The other three iBGP peers are Cisco.
FRR has one eBGP peer, to replicate re-advertising these routes out to iBGP. In our other three iBGP peers, we leverage route-maps to increment the received MED value of the route, so that we can prefer locally received eBGP routes - all else being equal - as opposed to those learned from our iBGP speakers in other locations. We also do this so locally originated prefixes from our AS have a higher metric when going out to eBGP speakers so they don't inadvertently get preferenced when there's a better path for the route to take.
I am receiving the routes from our iBGP speakers fine, and see the incremented MED on receipt of the routes from the aforementioned speaker. When I configure a local (to FRR) iBGP speaker as a route-reflector-client within the same AS, these pre-incremented MED's are correctly advertised to the local iBGP speaker and work just fine.
When advertising these same prefixes to an eBGP speaker with a different AS, the metric's are not readvertised, and only a locally originated prefix maintains any sort of metric at all.
Route's received from one of our remote iBGP speakers:
routert# sh bgp ipv4 unicast neighbors 1.1.1.1 received-routes BGP table version is 0, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0/0 1.1.1.1 100 100 0 i *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678 i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i
Total number of prefixes 6
Route's being correctly re-advertised and maintaining metric on re-advertisement to our local iBGP speaker (route-reflector-client):
router# sh bgp ipv4 unicast neighbors 3.3.3.3 advertised-routes BGP table version is 4560509, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 1.1.1.1 100 100 0 i *> 1.2.7.0/23 2.2.2.2 0 100 32768 i *> 2.3.4.0/21 1.1.1.1 100 100 0 5678i *> 3.4.5.0/24 1.1.1.1 100 100 0 5678 i *> 5.6.7.0/22 1.1.1.1 102 100 0 5678 i *> 7.8.9.0/24 1.1.1.1 102 100 0 5678 i
Total number of prefixes 6
Route's not maintaining their metric on re-advertisement to our local (to FRR) eBGP speaker:
router# sh bgp ipv4 unicast neighbors 8.8.8.8 advertised-routes BGP table version is 4562244, local router ID is 2.2.2.2, vrf id 0 Default local pref 100, local AS 1234 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path *> 1.2.3.0/20 0.0.0.0 100 0 i *> 1.2.7.0/23 0.0.0.0 0 32768 i *> 2.3.4.0/21 0.0.0.0 100 0 5678i *> 3.4.5.0/24 0.0.0.0 100 0 5678 i *> 5.6.7.0/22 0.0.0.0 100 0 5678 i *> 7.8.9.0/24 0.0.0.0 100 0 5678 i
Total number of prefixes 6
Am I doing something wrong here? Otherwise a pretty straight forward BGP setup with some basic route-maps in and out, nothing too crazy. Is this expected behavior in FRR?
Running latest available stable release, FRRouting 7.1RPKI.
Thanks for any help.
---------- _______________________________________________ frog mailing list frog@lists.frrouting.org https://lists.frrouting.org/listinfo/frog
participants (2)
-
Lee Clements -
Lou Berger