This commit is to correct the order in which the fields are
accessed while verifying it. First the fields should be
verified, and if it is valid then access it.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Allow the join-prune interval to be as small as 5 seconds instead
of limiting the value to 60.
This can and will come at a price of being able to converge less
mroutes.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
IGMPv3 packets with invalid TOS should be dropped.
Test Case ID: 4.10
TEST_DESCRIPTION
Every IGMP message described in this document is sent with
IP Precedence of Internetwork Control (e.g., Type of Service
0xc0)
(Tests that IGMPv3 Membership Query Message conforms to
above statement)
TEST_REFERENCE
NEGATIVE: RFC 3376, IGMP Version 3, s4 p7 Message Formats
Issue: #9071
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
IGMPv3 packets with invalid TTL should be dropped.
Test Case ID: 4.10
TEST_DESCRIPTION
Every IGMP message described in this document is sent with an IP
Time-to-Live of 1 (Tests that IGMPv3 Membership Report Message
conforms to above statement)
TEST_REFERENCE
NEGATIVE: RFC 3376, IGMP Version 3, s4 p7 Message Formats
Issue: #9070
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Making the interface holdtime range to 3.5 times the hello-time
As per 7761, Section 4.11:
The Holdtime in a Hello message should be set to
(3.5 * Hello_Period), giving a default value of 105 seconds.
Therefore providing the user also to configure max upto 3.5 times
the hello timer interval.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
When we have a "192.0.2.1 peer 192.0.2.2/32" address on an interface, we
need to (a) recognize the local address as being on the link for our own
packets, and (b) do the IGMP socket lookup with the proper local address
rather than the peer prefix.
Fixes: efe6f18 ("pimd: fix IGMP receive handling")
Cc: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1. Add the querierIP object to igmp_sock datastruct to save the IP address of the querier.
Management of the querierIP object is added.
2. To show the querier IP address in the CLI "show ip igmp interface".
3. To add the json object querierIP for querier IP address in the json CLI "show ip igmp interface json".
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
... the PIM code is kinda misusing prefix lists to match addresses.
Considering the weird semantics of access-lists, I can't fault it.
However, prefix lists aren't great at matching addresses by default,
since they try to match the prefix length too. So, here's an "address
match mode" for prefix lists to get that to work more reasonably.
Fixes: #8492
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
There's an IGMP socket per interface, so they should be bound to that
interface. Which also makes IGMP work in VRFs.
Fixes: #7889
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Rename functions (`pim_msdp_peer_new` => `pim_msdp_peer_add` and
`pim_msdp_peer_do_del` => `pim_msdp_peer_del`) to keep consistency and
update the `pim_msdp_peer_add` documentation to tell users that this is
also used for non meshed group peers.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Fully utilize the northbound to hold pointers to our private data
instead of searching for data structures every time we need to change a
configuration.
Highlights:
* Support multiple mesh groups per PIM instance (instead of one)
* Use DEFPY instead of DEFUN to reduce code complexity
* Use northbound private pointers to store data structures
* Reduce callback names size
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When running pim on an interface and that interface has
state and we move that interface into a different vrf
there exists a call path where we have not created the pimreg
device yet. Prevent a crash in this rare situation.
Ticket: #2552763
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Compile with v2.0.0 tag of `libyang2` branch of:
https://github.com/CESNET/libyang
staticd init load time of 10k routes now 6s vs ly1 time of 150s
Signed-off-by: Christian Hopps <chopps@labn.net>
VRF creation can happen from either cli or from
knowledged about the vrf learned from zebra.
In the case where we learn about the vrf from
the cli, the vrf id is UNKNOWN. Upon actual
creation of the vrf, lib/vrf.c touches up the vrf_id
and calls pim_vrf_enable to turn it on properly.
At this point in time we have a pim->vrf_id of
UNKNOWN and the vrf->vrf_id of the right value.
There is no point in duplicating this data. So just
remove all pim->vrf_id and use the vrf->vrf_id instead
since we keep a copy of the pim->vrf pointer.
This will remove some crashes where we expect the
pim->vrf_id to be usable and it's not.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When creating configuration for a vrf *Before* the vrf has been
created, pim will not properly create the pimreg device and
we will promptly crash when we try to pass data.
Put some code checks in place to ensure that the pimreg is
created for vrf's.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The router->register_suppress_time is used to derive the
rp_keep_alive_time, but when the suppress time was changed, pim was
not recalculating the rp_keep_alive_time and left it at the old value.
This fix applies the changes when a new suppress_time is entered
(or removed.)
Signed-off-by: Don Slice <dslice@nvidia.com>
Problem reported that when certain pim commands were entered, they
showed up duplicated in the configuration both under default instance
and every vrf (whether pim was used there or not.) This was because
these particular parameters are global only and the function doing
the display would repeat for each vrf. This fix only displays those
in the default case (and removes them from the help for entering
under a vrf.)
Signed-off-by: Don Slice <dslice@nvidia.com>
Just some cleanup before I touch this code; switching to typesafe list
macros & putting the data directly inline.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
... yes we may need it later, but if and when that happens we can put it
back there. No point carrying around unused things.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Display the MSDP peer configuration in `show running-config` so it can
be saved on configuration write.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
