Problems reported that if multiple peers have "remove-private-AS
replace-AS" with each other and all are using private asns, the as-path
gets hosed and continues to grow when a prefix is removed. This fix
disallows removing and replacing the private asn if it matches the
peer's ASN so that normal as-path loop prevention will operate correctly.
Ticket: CM-25489
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Issue1: When a vni in-filter eg:"neighbor X.X.X.X route-map RM-VNI-FILTER in"
is configured under evpn address-family, all the received routes are dropped
regardless of whether the route has a matching vni or not.
(Where RM-VNI-FILTER contains "match evpn vni 100")
Issue2: Routes with 2 labels are not filtered correctly
Issue3: This filter should not get applied for MPLS routes. For MPLS routes,
we need route-map to handle a 3rd state besides match/nomatch called: noop.
Fix1: The handler bgp_update() that services the received route ignored the
route's label while deciding whether to filter it or not.
As part of the fix, the handler now uses the label info to make the
decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route
Fix3: route_match_vni() should return noop when it encounters an mpls based
route. For this, route_map library should handle this 3rd state: RMAP_NOOP.
Related fix : Extract tunnel type
This fix relies on PR 4314 #4314 to extract the tunnel type from bgp extended
communities. The information about the route's tunnel type (vxlan or mpls)
is needed to apply "match evpn vni xx" rule. This rule is applicable to
vxlan routes, and should exit safely for mpls based evpn routes.
Signed-off-by: Lakshman Krishnamoorthy lkrishnamoor@vmware.com
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
BMP uses this to get notified about any changes to prefixes, at which
point it schedules its own processing to happen later.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These counters are accessible through BMP and may be useful to monitor
bgpd. A CLI to show them could also be added if people are interested.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
not getting displayed.
Neighbour prefix-count is not getting displayed with IPV6 neighbours
and displays the o/p “ % No such neighbor or address family ”.
However, I observed it is working fine for IPV4 neighbour.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
EVPN route's extended community include
important informations like Mobility sequence,
router mac, and RT values, include the ecomm
in evpn brief output.
Ticket:CM-25353
Testing Done:
Validated in evpn deployment with routes.
TOR#show bgp l2vpn evpn route
...
Network Next Hop Metric LocPrf Weight Path
Extended Community
Route Distinguisher: 27.0.0.11:3
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:04]:[128]:[fe80::202:ff:fe00:4]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8 ND:Router Flag
* [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
*> [2]:[0]:[0]:[48]:[00:02:00:00:00:36]
36.0.0.11 0 4435 5546 i
RT:5546:1008 RT:5546:4003 ET:8 MM:0, sticky MAC Rmac:44:38:39:ff:ff:01
* [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
*> [3]:[0]:[32]:[36.0.0.11]
36.0.0.11 0 4435 5546 i
RT:5546:1008 ET:8
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
FRR has a provision to give exact-match in match clause for
standard community, but this option is missing for lcommunity.
Part 3 : show related changes for match clause
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
FRR has no option for the as-set for aggregate route
under IPV6 address family. Added the command to
configure the as-set option for IPV6.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
This is mostly relevant for Solaris, where config.h sets up some #define
that affect overall header behaviour, so it needs to be before anything
else.
Signed-off-by: David Lamparter <equinox@diac24.net>
Issue:
ip route 15.1.1.0/24 10.112.158.15
ip route 15.1.1.0/32 10.112.158.15
Brought up ebgp session between two FRR routers and
redistributed static routes via BGP and verfied the advertising
routes in the peer.
Verify the command "show ip bgp neighbors <neighbor address>
advertised-routes json". It only shows 15.1.1.0/32 route details.
Root casue:
For both the routes "15.1.1.0/24" and "15.1.1.0/32" the advertised
routes key is the prefix i.e. "15.1.1.0".
Fix:
Modify the key to prefix/prefix-length.
Signed-off-by: Sarita Patra <saritap@vmware.com>
* When the bgp is being deleted and routes are in clear workqueue
and new aggregate address being allocated
* Added flag BGP_FLAG_DELETE_IN_PROGRESS in bgp structure to
bgp instance is being deleted
* When adding aggregate route check this flag and peer_self is valid
Signed-off-by: Soman K S <somanks@vmware.com>
The BGP_OPT_CONFIG_CISCO command could no longer be set
as such remove it from the system as a viable option to
be used.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue1: When "neighbor X.X.X.X route-map RM-VNI-FILTER in" is configured under evpn address-family,
all the received routes are dropped regardless of whether the route has a matching vni or not.
Issue2: Routes with 2 labels are not filtered correctly
Issue3: Interpreting the label based on tunnel type, vxlan was not done correctly.
Vxlan label has 24 bits, whereas, MPLS label is 20 bits long
Fix1: The handler bgp_update() that services the received route ignored the route's label while deciding whether to filter it or not. As part of the fix, the handler now uses the label info to make the decision about whether to filter the route or not.
Fix2: route_match_vni() now tries to match both the labels within the route, not just the one.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
We already show this information in `show [ip] bgp <prefix`, thus why don't
show it in global output. It's very handy when using at scale and to see
the whole picture instead of resolving neighbor manually.
It will show FQDN only if `bgp default show-hostname` is toggled.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
As part of detailed bgp route detail, include the
reason why a route was selected as best path.
robot# show bgp ipv4 uni 223.255.254.0
BGP routing table entry for 223.255.254.0/24
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
annie(192.168.201.136)
64539 15096 6939 7473 3758 55415
192.168.201.136 from annie(192.168.201.136) (192.168.201.136)
Origin IGP, valid, external, bestpath-from-AS 64539, best (First path received)
Last update: Wed May 15 21:15:48 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Store in bgp_node the reason why we choose a particular
best path over another. At this point we do not do
anything other than just store this data when we make
the decision. Future commits will display it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Instead of just passing in the prefix, pass in the particular
bgp_node we are using.
This is setup for a future commit to use this data.
The long term goal is to collect data about why
a particular bgp_path_info was selected as best and
to display that reason.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Display a debug message while sending a BGP route if the route is filtered by a
route-map.
Debug for incoming filtered route is already present.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
Prevent the ebgp sender from changing the nexthop( which is same as the ebgp neighbour ipv6 address),
while sending updates to its ipv6 neighbor.So,if the nexthop of the ipv6 route is same as the ipv6
neighbour address do not change the next hop to your own ip.
Signed-off-by: Biswajit Sadhu <sadhub@vmware.com>
Prevent IPv6 routes received via a ibgp session with one of its own interface
ip as nexthop from getting installed in the BGP table.
Implemented IPV6 HASH table, where we need to add any ipv6 address as they
gets configured and delete them from the HASH table as the ipv6 addresses
get unconfigured. The above hash table is used to verify if any route learned
via BGP has nexthop which is equal to one of its its connected ipv6 interface.
Signed-off-by: Biswajit Sadhu sadhub@vmware.com
EVPN routes (type-2/type-5) are imported from
default bgp instance (where they are learnt) to
non-default vrf instance.
When a bgp instance (default) is deleted,
unimport evpn routes from vrfs.
In absence of unimport, the imported routes in vrf
has parent path info points to default instance's path
info which is no longer valid (if instance is deleted).
When accessing parent path info leads to a crash
in non-default vrf instance.
The bgp instance is not cleaned up when
'no router bgp ASN' is performed, the instance's
reference count remains for evpn imported routes.
Ticket:CM-24484
Reviewed By:
Testing Done:
Validated via learning EVPN type-2/type-5 routes in symmetric
routing scenario.
The routes are imported to VRFs based on corresponding
L3VNI. When the default instance is removed, the evpn routes
are cleaned up from the VRF instance.
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
Network Next Hop Metric LocPrf Weight Path
*> 70.1.0.0/16 0.0.0.0 32768 i
s 70.1.1.24/32 110.0.0.2 0 65100 65002 i
s> 110.0.0.2 0 65100 65002 i
s 70.1.1.43/32 110.0.0.4 0 65100 65004 i
s> 110.0.0.4 0 65100 65004 i
TURTLE(config)# no router bgp 65050
TURTLE(config)# do show bgp vrf vrf3 ipv4 unicast
No BGP prefixes displayed, 0 exist
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
