zebra: trigger remove all access vlans for access port
When port was removed from last access vlan, the linux kernel
won't send any vlan info in the netlink message, it might affact
the evpn mh not withdraw EAD-EVI routes.
David Lamparter [Wed, 21 Jul 2021 09:04:23 +0000 (11:04 +0200)]
build: fix `AM_LDFLAGS` usage (and gcov)
like the other automake variables, setting `xyz_LDFLAGS` causes
`AM_LDFLAGS` to be ignored for `xyz`. For some reason I had in my mind
that automake doesn't do this for LDFLAGS, but... it does. (Which is
consistent with `_CFLAGS` and co.)
So, all the libraries and modules have been ignoring `AM_LDFLAGS` (which
includes `SAN_FLAGS` too). Set up new `LIB_LDFLAGS` and
`MODULE_LDFLAGS` to handle all of this correctly (and move these bits to
a central location.)
Fixes: #9034 Fixes: 0c4285d77eb ("build: properly split CFLAGS from AC_CFLAGS") Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 63116a7008706988136785ffa011cefee0355193)
Igor Ryzhov [Wed, 21 Jul 2021 14:22:14 +0000 (17:22 +0300)]
vtysh: fix exit from zebra-only nodes
When exiting from link-params and pseudowire nodes, we were sending exit
command to all VTYSH_INTERFACE daemons. This led to a desynchronized
state in vtysh and daemons other then zebra. We must send exit command
only to zebra.
Rafael Zalamena [Tue, 20 Jul 2021 12:43:03 +0000 (09:43 -0300)]
ospf6d: always generate default route for stubs
In RFC 2328 OSPF Version 2, Section 12.4.3.1 "Originating summary-LSAs
into stub areas" mentions that the stub areas should not import external
routes and instead should generate a 'default summary-LSA' set to
default destination.
> In a stub area, instead of importing external routes
> each area border router originates a "default summary-
> LSA" into the area. The Link State ID for the default
> summary-LSA is set to DefaultDestination, and the metric
> set to the (per-area) configurable parameter
> StubDefaultCost. Note that StubDefaultCost need not be
> configured identically in all of the stub area's area
> border routers.
ospfd: ospfd crash while giving 'clear ip ospf neighbor'
Description:
Ospf process crashes upon giving 'clear ip ospf neighbor' with
self routerId. It is asserting if it is a self neighbor in ospf
neighbour kill event processing.
Added a check to validate the provided router-id is self
router-id.
With fix:
```
exit1-debian-9# sh ip bgp dampening flap-statistics
BGP table version is 22, local router ID is 10.10.10.200, vrf id 0
Default local pref 100, local AS 65001
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
RPKI validation codes: V valid, I invalid, N Not found
```
5 0x00007fccab6fac39 in json_object_boolean_true_add (obj=<optimized out>, key=<optimized out>) at lib/json.c:70
No locals.
6 0x000055c7b8c08ae5 in route_vty_short_status_out (vty=<optimized out>, path=0x55c7bb37dcf0, p=<optimized out>, json_path=0x55c7bb3735a0)
at bgpd/bgp_route.c:8566
rpki_state = RPKI_NOT_BEING_USED
7 0x000055c7b8c22d1b in flap_route_vty_out (afi=AFI_IP, json=0x55c7bb3735a0, use_json=true, safi=SAFI_UNICAST, display=0, path=0x55c7bb37dcf0,
p=0x55c7bb37dea0, vty=0x55c7bb39e4c0) at bgpd/bgp_route.c:9600
attr = <optimized out>
bdi = 0x55c7bb377950
timebuf = '\000' <repeats 24 times>
len = <optimized out>
8 bgp_show_table (vty=0x55c7bb39e4c0, bgp=0x55c7bb316300, safi=safi@entry=SAFI_UNICAST, table=0x55c7bb314d90, type=bgp_show_type_flap_statistics,
output_arg=0x0, rd=0x0, is_last=1, output_cum=0x0, total_cum=0x0, json_header_depth=0x7ffeefd649f8, show_flags=1, rpki_target_state=RPKI_NOT_BEING_USED)
at bgpd/bgp_route.c:11110
```
With fix:
```
exit1-debian-9# sh ip bgp dampening dampened-paths
BGP table version is 16, local router ID is 10.10.10.200, vrf id 0
Default local pref 100, local AS 65001
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
RPKI validation codes: V valid, I invalid, N Not found
Igor Ryzhov [Mon, 12 Jul 2021 20:56:04 +0000 (23:56 +0300)]
isisd: fix processing of the attached bit
There are two problems with the current code for processing the attached
bit:
- we should process it when acting both a level-1-only and level-1-2
- we should add the default route when we don't have L2 adjacensies, not
when we don't have other routers configured on the device
Igor Ryzhov [Mon, 12 Jul 2021 20:51:27 +0000 (23:51 +0300)]
isisd: fix setting of the attached bit
Current code related to setting of the attached bit checks for existence
of L2 adjacencies in other routers configured on the device. This makes
no sense. We should check for L2 adjacencies in the same router where we
have L1 adjacencies.
Philippe Guibert [Mon, 12 Jul 2021 07:22:41 +0000 (09:22 +0200)]
bgpd: associate correct nexthop when using peer link-local
When setting bgp configuration using peers referencing link local
ipv6 addresses, the bgp should be able to handle incoming bgp
connections, and find out the appropriate interface where the
connection comes from.
ipv6 link local sessions work by using bgp unnumbered interfaces
config, but it does not work if we have a shared media with
multiple potential link local ipv6 addresses on the network.
The fix consists in finding out the appropriate interface, when
the local configuration references a link local ipv6 addresses,
and the source address used references an interface. below
configuration illustrates what can be done then:
note: this change does not solve the ability for such config to
create an outgoing connection to remote peer (as the link local
ipv6 address config does not indicate which interface to use).
zyxwvu Shi [Wed, 26 May 2021 02:33:55 +0000 (10:33 +0800)]
bgpd: Do not delete peer_af when deactivating peer-group.
There is no peer_af allocated in `peer_activate`. Trying to delete
the structure just results in an no-op and a error return value.
The error message "couldn't delete af structure for peer" is
unexpected.
staticd: fix late initialization of blackhole type
If a static route is added to a not-yet-existing VRF, the blackhole type
is not initialized. Initialization must be done before the VRF existence
check.
Philippe Guibert [Wed, 30 Jun 2021 12:07:52 +0000 (14:07 +0200)]
bgpd: nht unresolved with global address next-hop
When bgp peers with ipv6 link local addresses, it may receive a
BGP update with next-hop containing both LL and GA information.
By default, nexthop tracking applies to GA, and ignores presence
of LL, when both addresses are present. This is a problem for
resolving GA as next-hop as the next-hop information can be solved
by using the LL address only.
The solution consists in defaulting the nexthop ipv6 choice to LL
when available, and moving back to GA if a route-map is locally
configured at inbound.
Donald Sharp [Wed, 30 Jun 2021 14:25:43 +0000 (10:25 -0400)]
bgpd: Ensure v6 LL address is available before establishing peering
There are startup situations where we will attempt to connect to a remote
peer before bgp has received the v6 LL address. If we do not have this address
we must not allow the connection to come up until we have one available to use
in those situations where we must have a v6 LL address.
Donald Sharp [Tue, 23 Mar 2021 12:48:54 +0000 (08:48 -0400)]
tools: limit bgp route-maps to direct changes only
When using frr-reload.py to modify a bgp neighbors route-map
the code was doing this:
a) deleting the previous route-map: `no neighbor XX route-map YY (in|out)`
b) Adding the new route-map back in `neighbor XX route-may ZZ (in|out)`
Now imagine that we have an outgoing route-map that we are changing
and the reload is large because of a large number of lines in frr.conf
Item (a) will happen. BGP will immediately start sending all local
routes. At some point in time in the future (b) will be applied.
This of course causes a withdraw but for a short amount of time we
are leaking unintended routes. This is bad for several reasons
not 1) route churn upstream, 2) we might influence traffic to go the
wrong way. 3) if upstream has a maximum-prefix command the routes
being sent might trip its circuitry and shutdown the peer entirely
not even allowing you to get to (b).
ospfd: External lsa handling in opaque capabilities enable/disable
Description:
When opaque capability disabled/enabled , all the self-originated lsa will be
flushed and it will make the neighbours to renegotiate.
But here, external lsas are not being re-originated after negotiation
Fix:
Refresh/re-originate external lsas(Type-5 and Type-7) explicitly after
re-negotiation.
Yash Ranjan [Tue, 16 Mar 2021 07:45:23 +0000 (00:45 -0700)]
ospf6d: Release last dbdesc packet after router dead interval
During the database description exchange process, the slave
releases the last dbdesc packet after router_dead_interval.
This was not implemented in the code.
I have written the function ospf6_neighbor_last_dbdesc_release,
which releases the last dbdesc packet after router_dead_interval.
This change was required as per the conformance test 13.11:
In state Full reception of a Database Description packet from
the master after this interval (RouterDeadInterval) will
generate a SeqNumberMismatch neighbor event.
Associated Parameters
ICMPv6 Packet Listen Time
ICMPv6 Packet Tolerance Factor
ICMPv6 Packet Tolerance Time
OSPFV3 DUT Interface Transmit Delay
OSPF Reset Adjacencies Timeout
Test Actions
1.
2. 3.
ANVL: Establish full adjacency with DUT for neighbor Rtr-0-A on DIface-0, with DUT as slave.
ANVL: Wait (for <RouterDeadInterval> seconds).
ANVL: Send <OSPF-DD> packet from neighbor Rtr-0-A to DIface-0 con- taining:
• •
I-bit field not set M-bit field not set
MS-bit field set
DD sequence number same as the one last sent by ANVL.
. ANVL: Listen (for upto 2 * <RxmtInterval> seconds) on DIface-0.
5. DUT: Trigger the event SeqNumberMismatch and set the neighbor state for neighbor Rtr-0-A to ExStart.
6. DUT: Send <OSPF-DD> packet.
7. ANVL: Verify that the received <OSPF-DD> packet contains:
• I-bit field set
• M-bit field set
• MS-bit field set.
Don Slice [Wed, 9 Jun 2021 21:17:21 +0000 (14:17 -0700)]
tools: add mac access-list context to frr-reload.py
Problem reported that frr-reload.py didn't handle the mac access-list
command correctly, causing reloads to fail. This fix adds the
support for the command as a single line context.
Currently 'show evpn rmac vni .. mac .. json' includes fields for
localSequence and remoteSequence, which are misleading since they
aren't applicable to a macs in the IP-VRF mac table (RMAC).
This removes the localSequence + remoteSequence fields from the output.
Christian Hopps [Fri, 9 Jul 2021 07:58:02 +0000 (03:58 -0400)]
ospf6d: fix backlink check
This code has been wrong ~ever (according to git history). There are 3
conditional blocks with the added assertion that both the LSA and the
vertex being checked can't both be network LSAs.
The third block is clearly assuming both LSA and vertex are router
LSAs b/c it is accessing the backlink and lsdesc as router lsdesc's also
making sure both are p2p links (which they would have to be to point at
each other).
The programming error here is that (A && B) == False does NOT imply !A,
but the code is written that way.
So we end up in the third block one of LSA or vertex being network LSAs
rather easily (whenever that is the case and the desc isn't the backlink
being sought).
This was caught by ASAN b/c the lsdesc and backlinks are being accessed
(> 4 byte field offsets) as if they were router lsdesc's in the third
block, when in fact one of them is a network lsdesc which is only 4
bytes long -- so ASAN flags the access beyond bounds.
Yash Ranjan [Wed, 2 Jun 2021 12:45:18 +0000 (05:45 -0700)]
ospf6d: Set metric from default values when route-map metric not present
For redistribute commands if route map is set, then route takes it's metric
values from the route map. But in the case that routemap is set but the
metric for the route map is not, then the route metric is set to type-1.
Check if the metric is set for the routemap. If not then set it as per
redistributed default values (type 2)
Yash Ranjan [Mon, 24 May 2021 10:44:12 +0000 (03:44 -0700)]
ospf6d: Change the default metric parameter for redistribute
The default values will be set at the time of ospf6_redist_add
similar to ospfv2. Hence the default values will change as well.
Default metric type = E2
Default metic value = 20
lynne [Fri, 11 Jun 2021 14:38:42 +0000 (10:38 -0400)]
ospf6: Drop LSA with bad seqnumber
In RFC 2328 seqnumber 0x80000000 is reserved and not used. If an LSA
is received with seqnumber the LSA is now dropped and a debug error log
is printed.
Igor Ryzhov [Mon, 21 Jun 2021 15:04:46 +0000 (18:04 +0300)]
lib: remove vrf-interface config when removing the VRF
If we have the following configuration:
```
vrf red
smth
exit-vrf
!
interface red vrf red
smth
```
And we delete the VRF using "no vrf red" command, we end up with:
```
interface red
smth
```
Interface config is preserved but moved to the default VRF.
This is not an expected behavior. We should remove the interface config
when the VRF is deleted.
ospf6d: route-map config changed, not getting applied on all types of routes
Problem Statement:
==================
when route-map config is changed from permit to deny, it is not getting
applied to both connected and static and vice versa
RCA:
==================
When route-map changes from permit to deny or vice versa, a notification is
sent to ospf6 daemon via ospf6_asbr_routemap_update. In this function, a thread
is scheduled after 5 seconds to apply the route-map changes. In this thread
(ospf6_asbr_routemap_update_timer), only the first type is passed as argument
and only the first type i.e "connected" is passed and hence in callback only
on this type of route route-map gets applied.
Fix:
====
Need to loop through all the route-types in the call back and process
the route-map changes. Added a flag to mark which all route-types needs
to be processed.
Test Executed:
===============
1. Change route-map from permit to deny.
2. Change route-map from deny to permit.
3. Add new route and checked.
4. Verified summarised routes.
ospf6d: Max aged LSAs are not getting deleted from DB
Problem Statement:
==================
Max aged LSAs are not getting deleted from DB when there are multiple
neighbors in a LAN.
Root Cause Analysis:
====================
When the LSA is added to the neighbor's retransmit list, the LSA retrans count
is incremented but it is not checked if the LSA is already present in the
retransmit list leading to the count being incremented multiple times
untill the ack is not received and when the ack is received the count is
decremented once and hence the count never becomes 0 and
it remains in the DB forever.
Fix:
====================
Do not increment the retrans count multiple times if the LSA is already
present in the retransmit list of the neighbor. Also do not add the LSA
in the retransmit List if already present.
Martin Winter [Wed, 21 Jul 2021 13:06:19 +0000 (15:06 +0200)]
FRR Release 8.0
Major changes:
* A new daemon, `pathd`, has been added. This daemon implements support
for segment routing.
* EVPN Multihoming is now fully supported
* OSPFv3 now supports VRFs
* TI-LFA has been implemented in IS-IS and OSPF
* Zebra now has the ability to dump netlink messages in a human-friendly format
* LDP gained SNMP support
* Minimum libyang version is now 2.0
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Problem: Sometimes the configured Local GR state is not reflected in
show command and peer node. This is causing failures in few of the
BGP-GR topotests.
RCA: This problem is seen when the configuration of local GR state
happens when the BGP session is in OpenSent state and moves to
Established after the configuration is complete.
When the session gets established, we move the GR state value from stub peer
to the config peer. This will result in overriding the GR state to
previous value.
Fix: The local GR state is modified only through CLI configuration and
does not change during BGP FSM transition. In this case it is not necessary
to transfer the GR state value from stub peer to config peer. This way we
can ensure that always the most recent config value is present in peer
datastructure.
Igor Ryzhov [Mon, 12 Jul 2021 19:51:49 +0000 (22:51 +0300)]
ospf6d: fix freebsd mcast group issues
There's a delay in FreeBSD between issuing a command to leave a
multicast group and an actual leave. If we execute "no router ospf6" and
"router ospf6" fast enough, we can end up in a situation when OS
performs the leave later than it performs the join and the interface
remains without a multicast group.
Instead of counting on a one second delay, we must wait until the
interface actually leaves the group.
projects / matthieu / frr.git / log