When pim is creating an upstream for a S,G that it has received
*but* it has not received a route to the S, the oil is not
scanned to see if it should inherit anything from the *,G
that may be present when it cannot find the correct iif to
use. When the nexthop tracking actually
resolves the route, the oil is never rescanned and the
S,G stream will be missing a correct oil list leading
to absolute mayhem in the network.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When a pim vxlan S,G is created, the code attempts to send out a NULL
register. This is used to build the S,G tree from the RP to the
FHR. Upon initial startup it is not unusual for the pim vxlan state
be fully ready to go but the RP is still not reachable. Let's add
a bit of a pump prime that allows the vxlan code to re-attempt to
send the null register for vxlan S,G's that the RP's outgoing
interface changed from unknown to an actual interface.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Upon startup the pim vxlan code initiates a pim null register
send for the S,G and sends a *,G join towards the RP at the same
time. Since a S,G upstream is created in the vxlan code with
the appropriate flags, the *,G join has the embedded S,G RPT
Prune. When an intermediate route receives this *,G RPT Prune
it creates a blackhole S,G route since this particular intermediate
router has not received a join from the RP yet( say the packet is
lost, or that part of the network is slower coming up ).
Let's try to intelligently decide that the S,G RPT Prune
should not be sent as part of the *,G join until the actual
S,G join from the RP reaches this box. Then we can make
intelligent decisions about whether or not to send it
out.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The tests were originally tor --- spine
lets add a tor -- leaf -- spine. At this
point this change was to allow me to test
some funkiness I am seeing in pim vxlan setups
when the leaf is acting as the intermediate routers.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There is no test that checks for the mpls interface
configuration.
The new test checks that mpls configuration per
interface works when value is enabled or disabled.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The yang NB API does not handle the mpls configuration
on its leaf.
Add an mpls leaf to stick to the mpls configuration.
- true or false to mean if config
- not defined, means no config.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
The 'no mpls' command wrongly assumes the user wants to disable
the mpls handling on the interface whereas this is just a config
knob that should mean 'I don't care with mpls'.
Fix this by adding a 'disable' option to the mpls command.
Fixes: 39ffa8e8e8 ("zebra: Add a `mpls enable` interface node command")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Even if some of the attributes in bgp_path_info_extra are
not used, their memory is still allocated every time. It
cause a waste of memory.
This commit code deletes all unnecessary attributes and
changes the optional attributes to pointer storage. Memory
will only be allocated when they are actually used. After
optimization, extra info related memory is reduced by about
half(~400B -> ~200B).
Signed-off-by: Valerian_He <1826906282@qq.com>
Coverity is complaining that listnode can return a NULL
value and thus FRR could derefence the returned value.
Since this is not crashing we know that this is not happening
in the wild. Let's make this an assert or check that it is
legal to use the value.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The usage of bgp_vrf does not need to be tested
at this point since it's already been derefed in all
paths to this point.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
A route-map applied on incoming BGP updates is not able
to replace an unwanted as segments by another one.
unwanted as segment are based on an AS path access-list.
The below configuration illustrates the case:
router bgp 65001
address-family ipv4 unicast
neighbor 192.168.1.2 route-map rule_2 in
exit-address-family
bgp as-path access-list RULE permit ^65
route-map rule_2 permit 10
set as-path replace as-path-access-list RULE 6000
```
BGP routing table entry for 10.10.10.10/32, version 13
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.10.65
65000 1 2 3 123
192.168.10.65 from 192.168.10.65 (10.10.10.11)
Origin IGP, metric 0, valid, external, best (First path received)
```
After:
```
do show ip bgp 10.10.10.10/32
BGP routing table entry for 10.10.10.10/32, version 15
Paths: (1 available, best #1, table default)
Advertised to non peer-group peers:
192.168.10.65
6000 1 2 3 123
192.168.10.65 from 192.168.10.65 (10.10.10.11)
Origin IGP, metric 0, valid, external, best (First path
received)
```
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
Add this logic inside bgp_capability_send() instead of repeating the whole
logic before calling bgp_capability_send().
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When setting local-role for the neighbor, force sending ROLE capability via
dynamic capability if it's enabled.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
vtysh is not supposed to show empty interface node in running config,
however the corresponding check is broken and empty nodes are shown.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
isis_snmp.test_isis_snmp/r1/ldpd.log:2023/08/04 12:49:54 LDP: [SHWNK-NWT5S][EC 100663304] No such command on config line 8: agentx
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
babel_topo1.test_babel_topo1/r3/babeld.log:2023/08/04 12:46:55 BABELD: [SHWNK-NWT5S][EC 100663304] No such command on config line 17: redistirbute ipv6 connected
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
./config_timing.test_config_timing/r1/zebra.log:2023/08/04 12:34:29 ZEBRA: [SHWNK-NWT5S][EC 100663304] No such command on config line 7: exit-route-map
./config_timing.test_config_timing/r1/zebra.log:2023/08/04 12:34:29 ZEBRA: [SHWNK-NWT5S][EC 100663304] No such command on config line 10: exit-route-map
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
./bfd_ospf_topo1.test_bfd_ospf_topo1/rt3/ospfd.log:2023/08/04 12:46:58 OSPF: [SHWNK-NWT5S][EC 100663304] No such command on config line 28: passive interface lo
./bfd_ospf_topo1.test_bfd_ospf_topo1/rt5/ospfd.log:2023/08/04 12:46:59 OSPF: [SHWNK-NWT5S][EC 100663304] No such command on config line 27: passive interface lo
./bfd_ospf_topo1.test_bfd_ospf_topo1/rt1/ospfd.log:2023/08/04 12:46:56 OSPF: [SHWNK-NWT5S][EC 100663304] No such command on config line 30: passive interface lo
./bfd_ospf_topo1.test_bfd_ospf_topo1/rt4/ospfd.log:2023/08/04 12:47:00 OSPF: [SHWNK-NWT5S][EC 100663304] No such command on config line 27: passive interface lo
./bfd_ospf_topo1.test_bfd_ospf_topo1/rt2/ospfd.log:2023/08/04 12:46:57 OSPF: [SHWNK-NWT5S][EC 100663304] No such command on config line 28: passive interface lo
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
