224.0.0.0/24 cannot be used by igmp since this is reserved
for routing protocols and other low-level topology discovery or
maintenance protocols.
Fixes: #10614
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Two minor changes:
1) Change `zebra_evpn_mac_gw_macip_add()` 's return type to `void`.
2) Since `zebra_evpn_mac_gw_macip_add()` has already `assert` the returned
`mac`, the check of its return value makes no sense. And keep setting
`mac->flags` inside `zebra_evpn_mac_gw_macip_add()` is more reasonable. So
just move the setting `mac->flags` inside `zebra_evpn_mac_gw_macip_add()`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Restrict the number of nexthops for a route to the compiled-in
limit. Be careful with the zapi route struct's array of nexthops
too.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
The pim_upstream data structure has a ref count that is
not properly being incremented/decremented and when an
instance is removed this is causing crashes because timers
are still popping afterwords on data structures that are
now freed.
Since getting the ref count code is extremely hard and
we know that this crash is happening, add a bit of code
to prevent the timers from popping at all when we go
through and free up other data structures that we
are pointing at.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
noticed that pylint was complaining about some easily
fixable stuff in test_route_map_topo1.py so let's clean
it up some.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This creates `pim6_stubs.c`, which is intended to temporarily provide
stubbed-out definitions of some functions we don't have yet for IPv6.
This makes pim6d compile without the `PIM_V6_TEMP_BREAK` hack, and is
very important as an intermediate step to get a working environment for
further work.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is just hitting the pim_mroute code with a hammer until it doesn't
print warnings anymore. This is NOT quite tested or working yet, it
just compiles.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Just fixing a bunch of compiler errors, this will NOT actually configure
IPv6 PIM properly.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The entirety of this file is heavily indented. Work some coding
structure to make it easier to read and understand and not be
so heavily indented.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When rip is configured to work on secondary addresses
on an interface, rip was not properly sending out
the packets on secondary addresses because the source of the
packet was never properly being setup and rip would
send the packet out multiple times for the primary address
not once for each address on the interface that is setup to work.
tcpdump + rip debugs output with fix:
2022/02/15 19:59:50 RIP: [ZG173-BHW0K] turn on virbr0
2022/02/15 19:59:51 RIP: [PYB7S-80D89] multicast join at virbr0
2022/02/15 19:59:51 RIP: [GZR24-FCQGG] multicast request on virbr0
2022/02/15 19:59:51 RIP: [JTNCV-XD8S1] rip_send_packet 192.168.122.1 > 224.0.0.9 (virbr0)
2022/02/15 19:59:51 RIP: [VEJY5-67P5X] SEND to 224.0.0.9520
2022/02/15 19:59:51 RIP: [JTNCV-XD8S1] rip_send_packet 73.3.3.8 > 224.0.0.9 (virbr0)
2022/02/15 19:59:51 RIP: [VEJY5-67P5X] SEND to 224.0.0.9520
19:59:51.831128 IP 192.168.122.1.route > rip2-routers.mcast.net.route: RIPv2, Request, length: 24
19:59:51.831161 IP c-73-3-3-8.hsd1.mo.comcast.net.route > rip2-routers.mcast.net.route: RIPv2, Request, length: 24
Fixes: #10588
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Conversion of bgp error codes returned for cli input into
an enum and then properly handling all the error cases
in bgp_vty_return.
Because not all error codes returned were properly handled
in this function there existed configuration examples that
were accepted on the cli without an error message but not
saved.
Fixes: #10589
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
BGP_ERR_PEER_GROUP_MEMBER and BGP_ERR_PEER_GROUP_PEER_TYPE_DIFFERENT
both are not handled by bgp_vty_return, but both can be handled by
this function as that there is nothing special going on here.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
confederations are checking to see that the bgp pointer
is non-null. But it's impossible to have a null pointer
in the cli and in all paths we have already deref'ed the bgp
pointer. Let's remove that error code as that it is impossible
to happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
