Link-bandwidth is encoded into extended community, not ipv6 extended community.
Thus it's not needed here at all.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This is needed to implement and use larger bandwidths rather than limiting only
to theoretical 34Gbps max bandwidth.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In zebra_interface_nhg_reinstall zebra is checking that the
nhg is a singleton and not a blackhole nhg. This was originally
done with checking that the nexthop is a NEXTHOP_TYPE_IFINDEX,
NEXTHOP_TYPE_IPV4_IFINDEX and NEXTHOP_TYPE_IPV6_IFINDEX. This
was excluding NEXTHOP_TYPE_IPV4 and NEXTHOP_TYPE_IPV6. These
were both possible to be received and maintained from the upper
level protocol for when a route is being recursively resolved.
If we have gotten to this point in zebra_interface_nhg_reinstall
the nexthop group has already been installed at least once
and we *know* that it is actually a valid nexthop. What the
test is really trying to do is ensure that we are not reinstalling
a blackhole nexthop group( Which is not possible to even be
here by the way, but safety first! ). So let's change
to test for that instead.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The define has inheritated from a wrong naming in sr-mpls.
Fix this by renaming ISIS_SRV6_LAN_BACKUP to ISIS_SRV6_ADJ_BACKUP.
Fixes: 2566656a6f ("isisd: Add data structure for SRv6 Adjacency SIDs")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
This was caught by the grpc_basic test which was receiving an invalid error
result, which was returned b/c inside zebra the libyang code was flagging the
value as invalid for a derived zebra interface type.
Signed-off-by: Christian Hopps <chopps@labn.net>
- by using symlinks in the rundir (/tmp) into the source/build directory
we avoid needing to copy the *.gcda stat files into the source/build dir.
Signed-off-by: Christian Hopps <chopps@labn.net>
When a BFD down notification is received and the C-bit is set in both
directions, any ongoing graceful restart should be aborted and stale
routes removed from the RIB.
This commit updates the `bfd_bgp_cbit_topo3` topotest accordingly to
fix the expected outcomes in the `test_bfd_loss_intermediate` test.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commit adds the capabiity to filter OSPF neighbors using a
prefix-list with rules matching the neighbor's IP source address.
Configuration, filtering, immediate neighbor pruning, topo-tests,
and documentation are included. The command is:
ip ospf neighbor-filter <prefix-list> [A.B.C.D]
Signed-off-by: Acee Lindem <acee@lindem.com>
RFC5492 says:
This document defines a new Error Subcode, Unsupported Capability.
The value of this Subcode is 7. The Data field in the NOTIFICATION
message MUST list the set of capabilities that causes the speaker to
send the message. Each such capability is encoded in the same way as
it would be encoded in the OPEN message.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When the ISIS instance does not exist, this check causes the default value of the ISIS instance's metric to become narrow.
The following two scenarios present issues:
1) When the ISIS metric configuration under the interface exceeds 63, we are unable to delete the ISIS instance.
2) When the ISIS instance is not created, we are unable to modify an ISIS metric that exceeds 63.
Signed-off-by: zhou-run <166502045+zhou-run@users.noreply.github.com>
Today, with the following bgp instance configured, the
local VRF label is allocated even if it is not used.
> router bgp 65500 vrf vrf1
> address-family ipv4 unicast
> label vpn export allocation-mode per-nexthop
> label vpn export auto
> rd vpn export 444:1
> rt vpn both 52:100
> export vpn
> import vpn
The 'show mpls table' indicates that the 16 label value
is allocated, but never used in the exported prefixes.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP vrf1 -
> 17 BGP 192.168.255.13 -
> 18 BGP 192.0.2.12 -
> 19 BGP 192.0.2.11 -
Fix this by only allocating new label values when really
used. Consequently, only 3 labels will be allocated instead
of previously 4.
> r1# show mpls table
> Inbound Label Type Nexthop Outbound Label
> -----------------------------------------------------
> 16 BGP 192.168.255.13 -
> 17 BGP 192.0.2.11 -
> 18 BGP 192.0.2.12 -
Fixes: 577be36a41 ("bgpd: add support for l3vpn per-nexthop label")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
SRTE_COLOR is not defined at all as an attribute, it was a mistake from the
beginning.
SRTE_COLOR is extended community, can't see the reason having it as a community,
and a separate attribute.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
