Leaked route from the l3VRF are installed with the loopback as the
nexthop interface instead of the real interface.
> B>* 10.0.0.0/30 [20/0] is directly connected, lo (vrf default), weight 1, 00:21:01
Routing of packet from a L3VRF to the default L3VRF destined to a leak
prefix fails because of the default routing rules on Linux.
> 0: from all lookup local
> 1000: from all lookup [l3mdev-table]
> 32766: from all lookup main
> 32767: from all lookup default
When the packet is received in the loopback interface, the local rules
are checked without match, then the l3mdev-table says to route to the
loopback. A routing loop occurs (TTL is decreasing).
> 12:26:27.928748 ens37 In IP (tos 0x0, ttl 64, id 26402, offset 0, flags [DF], proto ICMP (1), length 84)
> 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64
> 12:26:27.928784 red Out IP (tos 0x0, ttl 63, id 26402, offset 0, flags [DF], proto ICMP (1), length 84)
> 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64
> 12:26:27.928797 ens38 Out IP (tos 0x0, ttl 63, id 26402, offset 0, flags [DF], proto ICMP (1), length 84)
> 10.0.0.2 > 10.0.1.2: ICMP echo request, id 47463, seq 1, length 64
Do not set the lo interface as a nexthop interface. Keep the real
interface where possible.
Fixes: db7cf73a33 ("bgpd: fix interface on leaks from redistribute connected")
Fixes: 067fbab4e4 ("bgpd: fix interface on leaks from network statement")
Fixes: 8a02d9fe1e ("bgpd: Set nh ifindex to VRF's interface, not the real")
Fixes: https://github.com/FRRouting/frr/issues/15909
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
1. When both Router A and Router B are configured with "is-type level-1," the area->is_type will be assigned the value IS_LEVEL_1, and circuit->is_type will also be assigned the value IS_LEVEL_1.
2. Configuring the circuit type "isis circuit-type level-1-2" for the interface of Router A will inadvertently call lib_interface_isis_circuit_type_modify to assign circuit->is_type the value IS_LEVEL_1_AND_2. This causes the hello packets reception and transmission, as well as the reception of LSP/SNP packets, to check circuit->is_type, allowing the level-2 hello packets to be sent and received normally, and level-2 LSP/SNP packets to be received normally.
3. When Router B modifies the configuration to "is-type level-2," and Router A and Router B establish a level-2 neighbor relationship, Router B sends level-2 LSP packets to Router A. Upon receiving these, Router A calls isis_spf_schedule to calculate the level-2 SPT, which results in accessing a null pointer.
When defining the behavior of the ISIS router, the call to isis_area_is_type_set will check that area->is_type is not IS_LEVEL_1_AND_2, and it disallows circuit->is_type_config from overriding circuit->is_type. Therefore, when configuring the circuit type for the interface of Router A, it should also check that area->is_type is not IS_LEVEL_1_AND_2 and disallow circuit->is_type_config from overriding circuit->is_type.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
In case when bgp_evpn_free or bgp_delete is called and the announce_list
has few items where vpn/bgp does not match, we add the item back to the
list. Because of this the list count is always > 0 thereby hogging CPU or
infinite loop.
Ticket: #3905624
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
As part of backpressure changes, there is a bug where immediate withdraw
is to be sent for evpn imported type-5 prefix to clear the nh neigh and
RMAC entry.
Fixing this by sending withdraw immediately to keep it inline with the
code today
Ticket: #3905571
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
`make check` should run w/o installing FRR first. Thus we need to embed
the yang modules otherwise mgmtd unit-test fails.
Signed-off-by: Christian Hopps <chopps@labn.net>
Without this patch we MUST follow this sequence:
```
no match peer 10.0.0.1
match peer 2a01::1
```
Otherwise, both IPv4/IPv6 values are set/compiled, thus when printing the
configuration in show running, we see the first one (IPv4).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
add some match in route map rules
add some set unset bgp access path list
add another prefix for better tests discrimination
update expected results
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
whith the following config
router bgp 65001
no bgp ebgp-requires-policy
neighbor 192.168.1.2 remote-as external
neighbor 192.168.1.2 timers 3 10
!
address-family ipv4 unicast
neighbor 192.168.1.2 route-map r2 in
exit-address-family
exit
!
bgp as-path access-list FIRST seq 5 permit ^65
bgp as-path access-list SECOND seq 5 permit 2$
!
route-map r2 permit 6
match ip address prefix-list p2
set as-path exclude as-path-access-list SECOND
exit
!
route-map r2 permit 10
match ip address prefix-list p1
set as-path exclude 65003
exit
!
route-map r2 permit 20
match ip address prefix-list p3
set as-path exclude all
exit
making some
no bgp as-path access-list SECOND permit 2$
bgp as-path access-list SECOND permit 3$
clear bgp *
no bgp as-path access-list SECOND permit 3$
bgp as-path access-list SECOND permit 2$
clear bgp *
will induce some crashes
thus we rework the links between aslists and aspath_exclude
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Configured with "mpls label bind 1.1.1.1/32 explicit-null", the running
configuration is:
```
!
mpls label bind 1.1.1.1/32 IPv4 Explicit Null
!
```
After this commit, the running configuration is:
```
!
mpls label bind 1.1.1.1/32 explicit-null
!
```
And add the support for the "no" form:
```
anlan(config)# mpls label bind 1.1.1.1/32 explicit-null
anlan(config)# no mpls label bind 1.1.1.1/32 explicit-null
```
Signed-off-by: anlan_cs <anlan_cs@tom.com>
bgp_llgr topotest sometimes fails at step 8:
> topo: STEP 8: 'Check if we can see 172.16.1.2/32 after R4 (dynamic peer) was killed'
R4 neighbor is deleted on R2 because it fails to re-connect:
> 14:33:40.128048 BGP: [HKWM3-ZC5QP] 192.168.3.1 fd -1 went from Established to Clearing
> 14:33:40.128154 BGP: [MJ1TJ-HEE3V] 192.168.3.1(r4) graceful restart timer expired
> 14:33:40.128158 BGP: [ZTA2J-YRKGY] 192.168.3.1(r4) graceful restart stalepath timer stopped
> 14:33:40.128162 BGP: [H917J-25EWN] 192.168.3.1(r4) Long-lived stale timer (IPv4 Unicast) started for 20 sec
> 14:33:40.128168 BGP: [H5X66-NXP9S] 192.168.3.1(r4) Long-lived set stale community (LLGR_STALE) for: 172.16.1.2/32
> 14:33:40.128220 BGP: [H5X66-NXP9S] 192.168.3.1(r4) Long-lived set stale community (LLGR_STALE) for: 192.168.3.0/24
> [...]
> 14:33:41.138869 BGP: [RGGAC-RJ6WG] 192.168.3.1 [Event] Connect failed 111(Connection refused)
> 14:33:41.138906 BGP: [ZWCSR-M7FG9] 192.168.3.1 [FSM] TCP_connection_open_failed (Connect->Active), fd 23
> 14:33:41.138912 BGP: [JA9RP-HSD1K] 192.168.3.1 (dynamic neighbor) deleted (bgp_connect_fail)
> 14:33:41.139126 BGP: [P98A2-2RDFE] 192.168.3.1(r4) graceful restart stalepath timer stopped
af8496af08 ("bgpd: Do not delete BGP dynamic peers if graceful restart
kicks in") forgot to modify bgp_connect_fail()
Do not delete the peer in bgp_connect_fail() if Non-Stop-Forwarding is
in progress.
Fixes: af8496af08 ("bgpd: Do not delete BGP dynamic peers if graceful restart kicks in")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
* Starting from version DPDK 22.11 we have API changes:
The rte_driver and rte_device objects are now opaque and must be manipulated through added accessors.
We need to update Zebra DPDK sources to DPDK version >=22.11
* Fix clang-format
Signed-off-by: EasyNet <devel@easynet.dev>
The SR-TE color of nexthop should be displayed in all situations.
Fixes: 553c804846 ("zebra: fix JSON fields for 'show ip/ipv6 nht'")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The zebra_nexthop_vty_helper() and zebra_nexthop_json_helper()
functions could be very helpful to display nexthop information
from whatever daemon.
Move the core function in the nexthop_vty_helper() and the
nexthop_json_helper() function. The zebra API call remains
unchanged.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
- Add separate get, get-config, get-state operations to query command, as
well as switching default output to JSON.
- Add an `--xml` to change the output format.
- move printss to logging.debug so output is a machine parseable result.
Signed-off-by: Christian Hopps <chopps@labn.net>
Include the prefix source address when set by a route-map in
show output for routes, in various formats.
Add some debugs when encoding netlink route messages with
a source address.
Signed-off-by: Mark Stapp <mjs@cisco.com>
Unconfiguring the send-experimental stats in BMP has no effect
on the current behavior.
Fixes this by swapping the configuration boolean.
Fixes: 7ba991cf96 ("bgpd: add 'bmp stat send-experimental' command")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
On a multihomed setup with colored bgp updates, when the primary
PE goes offline, only a small subset of colored bgp routes are
not switching to the secondary pe.
When a switchover happens, due to a remote IP becoming unreachable,
some nexthop tracking down notifications are sent, but those messages
are completely ignored for colored bgp updates.
The original code has been thought for mounting up the SR-TE service,
when IP reachability is ok, but not when services goes offline.
Fix this by extending the down notification mechanism for colored routes
too.
Fixes: 545aeef1d1 ("bgpd: extend the NHT code to understand SR-TE colors")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Similarly to recently fixed 'show ip[v6] prefix-list ...' - PR#15750,
json output is not valid for 'show ip[v6] access-list ... json' commands,
as it goes through all the running daemons and for each one it calls
'filter_show' creating a new json object. To aggreagate the output
and create a valid json that can later be parsed, the commands were
moved to vtysh and formatted accordingly
Signed-off-by: Piotr Suchy <piotrsuchy@proton.me>
When the SR-TE service is off, colored BGP routes are not
selected if it is recursively resolved over routes that are
colored only.
Actually, a BGP nexthop context includes the color attribute;
when an update from ZEBRA is received, there is no color, and
the colored BGP nexthop contexts are parsed, only if there
is a non colored BGP nexthop context. The actual setup shows
this may not be the case every time.
Fix this by parsing all the colored BGP nexthop contexts.
Fixes: b8210849b8 ("bgpd: Make bgp ready to remove distinction between 2 nh tracking types")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If you had a situation where an operator turned on
ospfd with snmp but not ospf6d and agentx was configured
then you get into a situation where ospf6d would complain
that the config for agentx did not exist. Let's modify
the code to allow this situation to happen.
Fixes: #15896
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
In route-map: `match tag untagged`.
E.g. Cisco/Juniper allows that, but they use `match tag 0` instead.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
