Louis Scalbert [Mon, 17 Oct 2022 15:35:12 +0000 (17:35 +0200)]
isisd: fix sending remote interface ip address after enabling MPLS TE
If MPLS TE is enabled, the router encodes the local and remote interface
IP address in the "Extended Reachability" TLV.
> east-vm(config)# do show isis database detail east-vm.00-00
> Extended Reachability: 0007.e901.3333.00 (Metric: 10)
> Local Interface IP Address(es): 10.126.0.2
> Remote Interface IP Address(es): 10.126.0.3
> Maximum Bandwidth: 1.76258e+08 (Bytes/sec)
The remote interface is added when the circuit adjacency comes up after
setting MPLS TE. However, if MPLS TE is enabled after, the remote
address is not added. It happens after disabling and re-enabling the
MPLS TE.
> east-vm(config)# router isis 1
> east-vm(config-router)# no mpls on
> east-vm(config-router)# mpls on
> east-vm(config)# do show isis database detail east-vm.00-00
> Extended Reachability: 0007.e901.3333.00 (Metric: 10)
> Local Interface IP Address(es): 10.126.0.2
> Maximum Bandwidth: 1.76258e+08 (Bytes/sec)
Update the remote IPv4 and IPv6 of all adjacencies after enabling MPLS
TE.
Fixes: 1b3f47d04c ("isisd: Update TLVs processing for TE, RI & SR") Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Stephen Worley [Fri, 21 Oct 2022 15:18:12 +0000 (11:18 -0400)]
bgpd: fix vni_str NULL check in evpn rt show run
Fix the vni_str NULL check for wildcard route-targets
in evpn show run. This will never be NULL if we add 1
here. Though it should also never be NULL since ":" should
always exist. Better to be safe than sorry.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
Donald Sharp [Wed, 19 Oct 2022 16:57:28 +0000 (12:57 -0400)]
lib: Remove unnecessary comparison, for linked list
In the comparison function for a linked list code was
always checking against passed in NULL's. The comparison
function will never receive a NULL value for data from
the linklist.c code.
Donald Sharp [Wed, 19 Oct 2022 16:44:55 +0000 (12:44 -0400)]
zebra: Fix debug of filtering out prefix due to routemap
The debug for notification about a filtered prefix was
just printing the nexthop ifindex and vrf id. Not all
nexthops have this data. Just print out the actual nexthop
Sarita Patra [Tue, 11 Oct 2022 01:38:14 +0000 (18:38 -0700)]
pimd, pim6d: Don't configure link-local, Multicast, Unspecified address as RP
Problem:
=======
frr(config)# do show ipv6 pim interface
Interface State Address PIM Nbrs PIM DR FHR IfChannels
ens192 up fe80::250:56ff:feb7:3619 0 local 0 1
Configure ens192 interface link-local address as RP.
frr(config)# ipv6 pim rp fe80::250:56ff:feb7:3619
No Path to RP address specified: fe80::250:56ff:feb7:3619
frr(config)# do show ipv6 pim rp-info
RP address group/prefix-list OIF I am RP Source Group-Type
fe80::250:56ff:feb7:3619 ff00::/8 Unknown yes Static ASM
Fix:
===
RP should not be link-local, multicast and unspecified address.
Introduced common api pim_process_unicast_bsm_cmd,
pim_process_no_unicast_bsm_cmd which will process
both "[no] ip pim unicast-bsm" command and "[no] ipv6 pim
unicast-bsm" command.
Donald Sharp [Wed, 12 Oct 2022 20:05:23 +0000 (16:05 -0400)]
ospfd: Allow unnumbered and numbered addresses to co-exist better
When forming a neighbor relationship on an interface, ospf is
currently evaluating unnumbered as highest priority, without
any consideration for if you have /32's and non /32's on the
interface. Effectively if I have something like this:
int foo0
ip address 192.168.119.1/24
!
router ospf
network 0.0.0.0/0 area 0
!
ospf will form a neighbor on foo0 if it exists. Now
suppose someone does this:
int foo0
ip address 192.168.120.1/32
This will create the unnumbered interface on foo0 and
the peering will come down immediately.
The problem here is that the original designers of the unnumbered
code for ospf didn't envision end operators mixing and matching
addresses on an interface like this ( for perfectly legitimate
reasons I might add ).
So if ospf has both numbered and unnumbered let's match against
the numbered first and then unnumbered. This solves the problem
Fixes: #6823 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Wed, 12 Oct 2022 18:53:21 +0000 (14:53 -0400)]
bgpd: Allow `network XXX` to work with bgp suppress-fib-pending
When bgp is using `bgp suppress-fib-pending` and the end
operator is using network statements, bgp was not sending
the network'ed prefix'es to it's peers. Fix this.
Also update the test cases for bgp_suppress_fib to test
this new corner case( I am sure that there are going to
be others that will need to be added ).
Fixes: #12112 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Tue, 11 Oct 2022 17:21:03 +0000 (13:21 -0400)]
lib: Free some memory in scripting subsystem at shutdown
Pre:
staticd: showing active allocations in memory group libfrr
staticd: memstats: Scripting : 16 * (variably sized)
staticd: memstats: Hash : 2 * (variably sized)
staticd: memstats: Hash Bucket : 8 * 32
staticd: memstats: Hash Index : 1 * (variably sized)
staticd: memstats: Link List : 1 * 40
staticd: memstats: Link Node : 1 * 24
staticd: showing active allocations in memory group logging subsystem
staticd: memstats: log file target : 1 * 88
staticd: showing active allocations in memory group staticd
Post:
staticd: showing active allocations in memory group libfrr
staticd: showing active allocations in memory group logging subsystem
staticd: memstats: log file target : 1 * 88
staticd: showing active allocations in memory group staticd
Donatas Abraitis [Tue, 11 Oct 2022 19:36:26 +0000 (22:36 +0300)]
tools: Handle sequence numbers for BGP community (large/ext) in frr-reload.py
If we add/modify community/large/ext lists without sequence numbers, and
doing frr-reload.py, then rules with sequence numbers (show running-config
always adds sequence numbers) will be deleted and new ones will be re-added.
bgpd: Don't check for NULL when removing SRv6 SIDs
When an SRv6 locator is unset, all the SRv6 SIDs allocated from the
locator are removed. Before freeing the memory allocated for an SRv6
SID, we check if the pointer to the SID is `NULL`.
However, checking for `NULL` before freeing memory is useless.
This PR aims to improve the code's readability by removing the
useless `NULL` checks.
Currently, if `bgp max-med on-startup` is configured, after BGP session
is established for the first time, a timer for the specified time is
started. When the timer is expired, an UPDATE message should be sent to
reflect changes in the routes' MED value. The problem is that the routes
are being suppressed because based on the attributes they look like they
have not changed. However, in the case of max-med, the value is copied
to the packet directly from `bgp->maxmed_value`, not from the
attributes. Thus, changes in this case cannot be detected by comparing
attributes.
With this fix, avoid route suppressing when the `max-med on-startup`
timer expires and initiates an UPDATE.
Signed-off-by: Alexander Chernavin <achernavin@netgate.com>
projects / matthieu / frr.git / log