This commit adds a new topotest to verify the functionality of SRv6
locators with custom bits length parameters.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds a new topotest which tests SRv6 L3VPN for IPv4 and
IPv6 address families using a single SID.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds a new test case to the
test_zebra_seg6local_route topotest. The new test case performs two
operations:
* try to install a seg6local route with an End.DT46 action
* verify that the route is created correctly
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
In the current implementation of bgpd, SRv6 SIDs can be configured only
under the address-family. This enables bgpd to leak IPv6 routes using
an SRv6 End.DT6 behavior and IPv4 routes using an SRv6 End.DT4
behavior. It is not possible to leak both IPv6 and IPv4 routes using a
single SRv6 SID.
This commit adds a new CLI command
"sid vpn per-vrf export <sid_idx|auto>" that enables bgpd to leak both
IPv6 and IPv4 routes using a single SRv6 SID (End.DT46 behavior).
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds the SRv6 locator's block length, node length and
argument length to the output of the command
"show segment-routing srv6 locator json"
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds SRv6 locator's block length, node length and argument
length to the output of the command
"show segment-routing srv6 locator NAME detail [json]".
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
This commit adds the SRv6 locator's block length, node length and
argument length to the SRv6 configuration.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
The seg6_local.h header has changed in the kernel. We need a recent
version of the header to support SRv6 End.DT46 behavior.
This commit pulls seg6_local.h header from the Linux kernel.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
In the current implementation, an SRv6 locator only supports the
following structure:
* node-len = 24
* block-len = prefix-len - 24
* function-len = <configurable>
* argument-len = 0
This commit adds two optional arguments to the locator_prefix CLI
command: "node-len" and "block-len". These arguments allows an user to
configure the block length and node length of a SRv6 locator according
to the following logic:
* the node-len + block-len = prefix-len constraint must always be
satisfied;
* if node-len and block-len are both omitted, they are calculated as in
the current implementation (for backward compatibility reasons)
* if node-len is omitted, its value is computed as
prefix-len - block-len
* if block-len is omitted, its value is computed as
prefix-len - node-len
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
Description:
Active GR count field is missing in json o/p
of 'show ipv6 ospf gr helper' command.
Issue: #12100
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
In the current code, if_lookup_by_index()
is called for un-initialized ifindex value.
This issue is introduced after 11098 PR.
Signed-off-by: Sarita Patra <saritap@vmware.com>
If the timer is not explicitly configured for a peer, the default timer
is not taken into account and SendHoldTimer mechanism does not work at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Daemons like isisd continue to use the previous link-params after they
are removed from zebra.
For example,
>r0# sh run zebra
> (...)
> interface eth-rt1
> link-params
> enable
> metric 100
> exit-link-params
> r0# conf
> r0(config)# interface eth-rt1
> r0(config-if)# link-params
> r0(config-link-params)# no enable
After "no enable", "sh run zebra" displays no more link-params context.
The "no enable" causes the release of the "link_params" pointer within
the "interface" structure. The zebra function to update daemons with
a ZEBRA_INTERFACE_LINK_PARAMS zapi message is called but the function
returns without doing anything because the "link_params" pointer is
NULL. Therefore, the "link_params" pointers are kept in daemons.
When the zebra "link_params" pointer is NULL:
- Send a zapi link param message that contains no link parameters
instead of sending no message.
- At reception in daemons, the absence of link parameters causes the
release of the "link_params" pointer.
Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
A given interface has no enabled link-params context. If a link-params
configuration command fails, the link-params is wrongly enabled:
> r4(config-link-params)# no enable
> r4(config-link-params)# delay
> (0-16777215) Average delay in micro-second as decimal (0...16777215)
> r4(config-link-params)# delay 50 min 300 max 500
> Average delay should be comprise between Min (300) and Max (500) delay
> r4(config-link-params)# do sh run zebra
> (...)
> interface eth-rt1
> link-params
> enable
> exit-link-params
link-params are enabled if and only if the interface structure has a
valid link_params pointer. Before checking the command validity,
if_link_params_get() is called to retrieve the link-params pointer.
However, this function initializes the pointer if it is NULL.
Only use if_link_params_get() to retrieve the pointer to avoid
confusion. In command setting functions, initialize the link_params
pointer if needed only after the validation of the command.
Fixes: 16f1b9e ("Update Traffic Engineering Support for OSPFD")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
touch + chown can have a gap between the commands (or the second failed).
This could lead to unexpected permissions (root, instead of frr) for some
.conf files or directories.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
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>
