mirror of
https://git.proxmox.com/git/mirror_frr
synced 2026-02-01 18:37:27 +00:00
bgpd: Allow bgp static routes to use /32's
If you are including a network statement of a /32
then the current bgp martian checks will match the /32
together.
Problem:
!
router bgp 3235
neighbor 192.168.161.2 remote-as external
neighbor 192.168.161.131 remote-as external
!
address-family ipv4 unicast
network 10.10.3.11/32
network 192.168.161.0/24
no neighbor 192.168.161.2 activate
neighbor 192.168.161.2 route-map BLUE in
exit-address-family
!
eva# show bgp ipv4 uni
BGP table version is 1, local router ID is 10.10.3.11, vrf id 0
Default local pref 100, local AS 3235
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
10.10.3.11/32 0.0.0.0(eva) 0 32768 i
*> 192.168.161.0/24 0.0.0.0(eva) 0 32768 i
Displayed 2 routes and 2 total paths
eva# show bgp import-check-table
Current BGP import check cache:
192.168.161.0 valid [IGP metric 0], #paths 1
if enp39s0
Last update: Fri Sep 25 08:00:42 2020
10.10.3.11 valid [IGP metric 0], #paths 1
if lo
Last update: Fri Sep 25 08:00:42 2020
eva# show bgp ipv4 uni summ
BGP router identifier 10.10.3.11, local AS number 3235 vrf-id 0
BGP table version 1
RIB entries 3, using 576 bytes of memory
Peers 1, using 21 KiB of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd PfxSnt
janelle(192.168.161.131) 4 60000 69 70 0 0 0 00:03:21 0 1
Total number of neighbors 1
When we are deciding that a nexthop is valid there is not much point in checking
that a static route has a martian nexthop or not, since we self derived it already.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This commit is contained in:
parent
b1f476731a
commit
e8442016a8
@ -3340,14 +3340,20 @@ bool bgp_update_martian_nexthop(struct bgp *bgp, afi_t afi, safi_t safi,
|
||||
(type == ZEBRA_ROUTE_BGP && stype == BGP_ROUTE_STATIC) ? true
|
||||
: false;
|
||||
|
||||
/* Only validated for unicast and multicast currently. */
|
||||
/* Also valid for EVPN where the nexthop is an IP address. */
|
||||
if (safi != SAFI_UNICAST && safi != SAFI_MULTICAST && safi != SAFI_EVPN)
|
||||
/*
|
||||
* Only validated for unicast and multicast currently.
|
||||
* Also valid for EVPN where the nexthop is an IP address.
|
||||
* If we are a bgp static route being checked then there is
|
||||
* no need to check to see if the nexthop is martian as
|
||||
* that it should be ok.
|
||||
*/
|
||||
if (is_bgp_static_route ||
|
||||
(safi != SAFI_UNICAST && safi != SAFI_MULTICAST && safi != SAFI_EVPN))
|
||||
return false;
|
||||
|
||||
/* If NEXT_HOP is present, validate it. */
|
||||
if (attr->flag & ATTR_FLAG_BIT(BGP_ATTR_NEXT_HOP)) {
|
||||
if ((attr->nexthop.s_addr == INADDR_ANY && !is_bgp_static_route)
|
||||
if (attr->nexthop.s_addr == INADDR_ANY
|
||||
|| IPV4_CLASS_DE(ntohl(attr->nexthop.s_addr))
|
||||
|| bgp_nexthop_self(bgp, afi, type, stype, attr, dest))
|
||||
return true;
|
||||
@ -3366,8 +3372,7 @@ bool bgp_update_martian_nexthop(struct bgp *bgp, afi_t afi, safi_t safi,
|
||||
switch (attr->mp_nexthop_len) {
|
||||
case BGP_ATTR_NHLEN_IPV4:
|
||||
case BGP_ATTR_NHLEN_VPNV4:
|
||||
ret = ((attr->mp_nexthop_global_in.s_addr == INADDR_ANY
|
||||
&& !is_bgp_static_route)
|
||||
ret = (attr->mp_nexthop_global_in.s_addr == INADDR_ANY
|
||||
|| IPV4_CLASS_DE(
|
||||
ntohl(attr->mp_nexthop_global_in.s_addr))
|
||||
|| bgp_nexthop_self(bgp, afi, type, stype, attr,
|
||||
@ -3376,9 +3381,8 @@ bool bgp_update_martian_nexthop(struct bgp *bgp, afi_t afi, safi_t safi,
|
||||
|
||||
case BGP_ATTR_NHLEN_IPV6_GLOBAL:
|
||||
case BGP_ATTR_NHLEN_VPNV6_GLOBAL:
|
||||
ret = ((IN6_IS_ADDR_UNSPECIFIED(
|
||||
ret = (IN6_IS_ADDR_UNSPECIFIED(
|
||||
&attr->mp_nexthop_global)
|
||||
&& !is_bgp_static_route)
|
||||
|| IN6_IS_ADDR_LOOPBACK(&attr->mp_nexthop_global)
|
||||
|| IN6_IS_ADDR_MULTICAST(
|
||||
&attr->mp_nexthop_global)
|
||||
|
||||
Loading…
Reference in New Issue
Block a user