This was found while doing libyang2 work (causes assert); however, it is
also incorrect for libyang1 (empty canonical value for incorrectly
referenced interface vs interface-name node).
While here, fix 2 other incorrect uses of "." on a container node.
Signed-off-by: Christian Hopps <chopps@labn.net>
We can proactively check whether this mroute will be nacked by loopfree
MFC checks so let's do it in the apply phase and emit a useful error
message.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
When the control plane protocol is created, the vrf structure is
allocated, and its address is stored in the northbound node.
The vrf structure may later be deleted by the user, which will lead to
a stale pointer stored in this node.
Instead of this, allow daemons that use the vrf pointer to register the
dependency between the control plane protocol and vrf nodes. This will
guarantee that the nodes will always be created and deleted together, and
there won't be any stale pointers.
Add such registration to staticd and pimd.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Neither tabs nor newlines are acceptable in syslog messages. They also
break line-based parsing of file logs.
Signed-off-by: David Lamparter <equinox@diac24.net>
Modify code to add JSON format output in show command.
"show ip igmp [vrf NAME] join" and "show ip igmp vrf all join" with proper formatting
Signed-off-by: Sai Gomathi <nsaigomathi@vmware.com>
Valgrind reports:
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A090D: bgp_bfd_dest_update (bgp_bfd.c:416)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
469901-==469901==
469901-==469901== Conditional jump or move depends on uninitialised value(s)
469901:==469901== at 0x3A093C: bgp_bfd_dest_update (bgp_bfd.c:421)
469901-==469901== by 0x497469E: zclient_read (zclient.c:3701)
469901-==469901== by 0x4955AEC: thread_call (thread.c:1684)
469901-==469901== by 0x48FF64E: frr_run (libfrr.c:1126)
469901-==469901== by 0x213AB3: main (bgp_main.c:540)
469901-==469901== Uninitialised value was created by a stack allocation
469901:==469901== at 0x3A0725: bgp_bfd_dest_update (bgp_bfd.c:376)
On looking at bgp_bfd_dest_update the function call into bfd_get_peer_info
when it fails to lookup the ifindex ifp pointer just returns leaving
the dest and src prefix pointers pointing to whatever was passed in.
Let's do two things:
a) The src pointer was sometimes assumed to be passed in and sometimes not.
Forget that. Make it always be passed in
b) memset the src and dst pointers to be all zeros. Then when we look
at either of the pointers we are not making decisions based upon random
data in the pointers.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
RCA: There were 2 problems.
1. SGRpt prune expiry didn't create S,G entry with none oil when no other
interfaces were part of the oil.
2. When restarting the timer with new hold value, comparision was missing and
old timer was not stopping.
Fix:
SGRpt Prune pending expiry will put SG entry with none oil if no other
Signed-off-by: Saravanan K <saravanank@vmware.com>
interfaces present. If present we will be deleting the inherited oif from oil.
Deleting the oif in that scenario will take care of changing mroute.
When alone interface expires in SGRpt prune pending state, we shall detect by
checking installed flag. if not installed, install mroute.
Valgrind is reporting this:
==22220== Invalid read of size 4
==22220== at 0x11DC2B: pim_if_delete (pim_iface.c:215)
==22220== by 0x11DD71: pim_if_terminate (pim_iface.c:76)
==22220== by 0x128E03: pim_instance_terminate (pim_instance.c:66)
==22220== by 0x128E03: pim_vrf_delete (pim_instance.c:159)
==22220== by 0x48E0010: vrf_delete (vrf.c:251)
==22220== by 0x48E0010: vrf_delete (vrf.c:225)
==22220== by 0x48E02FE: vrf_terminate (vrf.c:551)
==22220== by 0x149495: pim_terminate (pimd.c:142)
==22220== by 0x13C61B: pim_sigint (pim_signals.c:44)
==22220== by 0x48CF862: quagga_sigevent_process (sigevent.c:103)
==22220== by 0x48DD324: thread_fetch (thread.c:1404)
==22220== by 0x48A926A: frr_run (libfrr.c:1122)
==22220== by 0x11B85E: main (pim_main.c:167)
==22220== Address 0x5912160 is 1,200 bytes inside a block of size 1,624 free'd
==22220== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==22220== by 0x128E52: pim_instance_terminate (pim_instance.c:74)
==22220== by 0x128E52: pim_vrf_delete (pim_instance.c:159)
==22220== by 0x48E0010: vrf_delete (vrf.c:251)
==22220== by 0x48E0010: vrf_delete (vrf.c:225)
==22220== by 0x48F1353: zclient_vrf_delete (zclient.c:1896)
==22220== by 0x48F1353: zclient_read (zclient.c:3511)
==22220== by 0x48DD826: thread_call (thread.c:1585)
==22220== by 0x48A925F: frr_run (libfrr.c:1123)
==22220== by 0x11B85E: main (pim_main.c:167)
==22220== Block was alloc'd at
==22220== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==22220== by 0x48ADA4F: qcalloc (memory.c:110)
==22220== by 0x128B9B: pim_instance_init (pim_instance.c:82)
==22220== by 0x128B9B: pim_vrf_new (pim_instance.c:142)
==22220== by 0x48E0C5A: vrf_get (vrf.c:217)
==22220== by 0x48F13C9: zclient_vrf_add (zclient.c:1863)
==22220== by 0x48F13C9: zclient_read (zclient.c:3508)
==22220== by 0x48DD826: thread_call (thread.c:1585)
==22220== by 0x48A925F: frr_run (libfrr.c:1123)
==22220== by 0x11B85E: main (pim_main.c:167)
On pim vrf deletion, ensure that the vrf->info pointers are NULL as well
as the free'd pim pointer for ->vrf is NULL as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Issue: #7892 has a startup config where only igmp
interfaces are created and a igmp report comes in.
Effectively we are not creating the regiface device unless
we do a `ip pim`. This is incorrect we should always create
the regiface.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. As per RFC 4601 Sec 4.5.7:
* JoinDesired(S,G) -> False, set SPTbit to false.
2. Change the debug type.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This command has been added in the context of
PIM BSM functionality. This command will clear the
data structs having bsr information.
Co-authored-by: Sarita Patra <saritap@vmware.com>
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
Test case 5.10 sends leave message to unicast address, the leave
packet is accepted and a query message is sent in response to this.
No validation for address is present in the function
Add check for addresses as per RFC. Leave messages are allowed only
sent to either ALL-ROUTERS (224.0.0.2) or group address.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
1. When a node changes from non-DR to DR in the given topology,
the node was receiving both PIM Join as well as IGMP join.
Since it was already receiving PIM Join previously, ifchannel was
already present. Hence when it becomes DR, the IGMP source flag is not
set due to issue in the code. Hence it never creates S,G entry thinking
that it is not DR.
2. When pim join expires, the pim flag is not reset when ifchannel is not
deleted.
Issue: #7752
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The flag "R" in below display description denotes the
SGRpt Pruned but the description shows something else
hence correcting the definition.
R2(config)# do show ip mroute
IP Multicast Routing Table
Flags: S- Sparse, C - Connected, P - Pruned
R - RP-bit set, F - Register flag
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Issue:
Configure msdp mesh mg1 for 2 groups.
ip msdp mesh-group mg1 member 1.1.1.1
ip msdp mesh-group mg1 member 1.1.1.2
Remove mg1 for 1.1.1.1
no ip msdp mesh-group mg1 member 1.1.1.1
mg1 for 1.1.1.1 still present. This is fixed.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue:
Configure RP.
ip pim rp 20.0.0.1 239.1.1.1/32
ip pim rp 20.0.0.1 239.1.1.2/32
Remove RP.
no ip pim rp 20.0.0.1 239.1.1.1/32
Rp is not removed. This is fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
The pim_version.[c|h] files are never used and we are getting
warnings about PIM_VERSION changing pointer sizes from
newer versions of the compiler. I see no reason to keep this
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
pim is enabled internally/implicitly on the vxlan termination device
and displaying that can confuse the admin and tools (such as
frr-reload).
Ticket: CM-30180
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
If we screw up and don't have the right flags we'll print
out garbage. At the very least just print out nothing.
Signed-off-by: Donald Sharp <sharp@nvidia.com>
Issue: When an IGMPv2 leave packet is received, it did not validate
the checksum and hence the packet is accepted and group specific
query is sent out in response to this.
Due to this IGMP conformance test case 6.1 failed.
https://github.com/FRRouting/frr/issues/6868
Fix: Validate the checksum for all IGMP packets
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
The `enum zclient_send_status` enum needs to be extended
throughout the code base to use the new states and
to fix up places where we tested against the return
value being non zero.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
problem :
=========
When (*,G) prune received where we have SGRpt state,
ifchannel goes to NO_INFO state and doesn't get removed.
Root cause :
============
During the processing of (*,G) prune, we are not removing the
ifchannel on PruneTmp or PrunePendingTmp state.
Fix :
=====
In that scenario, stop joinExpiry timer and delete the ifchannel.
issue #7347
Co-authored-by: Saravanan K <saravanank@vmware.com>
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
Replace all lib/thread cancel macros, use thread_cancel()
everywhere. Only the THREAD_OFF macro and thread_cancel() api are
supported. Also adjust thread_cancel_async() to NULL caller's pointer (if
present).
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Create appropriate accessor functions for the rn->lock
data. We should be accessing this data through accessor
functions since it is private data to the data structure.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We have this pattern in the code base:
if (thread)
THREAD_OFF(thread);
If we look at THREAD_OFF we check to see if thread
is non-null too. So we have a double check.
This is unnecessary. Convert to just using THREAD_OFF
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* If the MSDP peer receives the SA from a non-RPF peer towards the
originating RP, it will drop the message.
* SA messages are forwarded away from the RP address only.
* SA messages are not forwarded within the mesh group.
* Preventing the MSDP connection from being dropped due to RPF check
failure (RFC3618, section 13 "MSDP Error Handling")
Signed-off-by: Adriano Marto Reis <adrianomarto@gmail.com>
Signed-off-by: Adriano Reis <areis@barrukka.local>
This should never happen; no need to debug guard it and it's not a
warning, if this isn't working then NHT is not working at all.
Signed-off-by: Quentin Young <qlyoung@nvidia.com>
Clean up the rare situation when bind fails to not
close the fd that was just opened and have the socket
leaked.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
We use the pim mroute socket for kernel notifications of events.
Currently this is limited to 8 bits of data. There are patches
coming down the pike in kernel land to allow this to expand.
Rather than fix this and all the other places we assume MAXVIFS < 256
in the pim code right now. Leave a land mine for the developer
doing this work to point them in the right direction.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Match by exact address rather than by prefix match to
determine if we generated the IGMPP query. Othwerwise
we will be ignoring IGMP queries coming from other
hosts on the same subnet.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Reviewed-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
IGMP queries should contain the source address of the IGMP socket
they are being sent from.
Added binding the IGMP sockets to their specific source, otherwise
interfaces with multiple addresses will send multiple queries using
the same source, which is determined by the kernel.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Reviewed-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
IGMP packets received from a source that does not match the subnet
of any configured addresses on the receive interface should be
ignored.
Also, find and use the correct IGMP socket object for the received
IGMP packet.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Suppose you have more than 2 addresses on a pim interface:
lo up default 10.255.0.1/32
10.255.0.101/32
10.255.0.254/32
A `show ip pim int lo` gives us this:
eva# show ip pim interface lo
Interface : lo
State : up
Address : 10.255.0.1 (primary)
10.255.0.101/32
When we go look at the code that pulls secondary addresses in
we are using a prefix_cmp to know if we know about a secondary already
but were expecting true values instead of -1/0/1 being returned.
Modify code so that pim sees all secondary addresses
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd crash at pim_msg_build_jp_groups (
grp=grp@entry=0x7ffca55b5d1e, sgs=sgs@entry=0x17821a0, size=20)
at pimd/pim_msg.c:198
Fix for https://github.com/FRRouting/frr/issues/6849
Root Cause:
===========
pimd has crashed because pim_upstream_rpf_clear function sets the
up->rpf.source_nexthop.interface pointer to NULL and has not removed
the upstream source node from the neighbor. When the upstream gets
deleted the source is not removed from neighbor
neigh->upstream_jp_agg->groups->sources list. This source node has
pointer to upstream freed memory. Hence when on_neighbor_jp_timer expires,
it tries to access the upstream pointer and crashed.
Fix:
====
Before setting the interface pointer to NULL, remove the node from
neigh->upstream_jp_agg->groups->sources list. Also the upstream state
has to be changed to Not joined.
Removed extra line changes.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Move pim and igmp yang files registery to appropriate makefiles.
In yang directory makefile move under `PIMD`
Remove pimd yang files from library makefile instead move them
to pimd makefile.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
There are couple spots where group may be NULL and
when we output strings associated with it we should
ensure we are not doing something stupid.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When creating a pim instance, we were allocating table information
but never freeing it. Do so.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Remove mid-string line breaks, cf. workflow doc:
.. [#tool_style_conflicts] For example, lines over 80 characters are allowed
for text strings to make it possible to search the code for them: please
see `Linux kernel style (breaking long lines and strings)
<https://www.kernel.org/doc/html/v4.10/process/coding-style.html#breaking-long-lines-and-strings>`_
and `Issue #1794 <https://github.com/FRRouting/frr/issues/1794>`_.
Scripted commit, idempotent to running:
```
python3 tools/stringmangle.py --unwrap `git ls-files | egrep '\.[ch]$'`
```
Signed-off-by: David Lamparter <equinox@diac24.net>
BFD profiles can now be used on the interface level like this:
interface eth1
ip router isis 1
isis bfd
isis bfd profile default
Here the 'default' profile needs to be specified as usual in the
bfdd configuration.
Signed-off-by: GalaxyGorilla <sascha@netdef.org>
This section of code was ported incorrectly and is causing
issues when running against some tests. Fix the missed
code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Don't crash when trying to `show running-config` because of missing
filter northbound integration.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Issue: After SPT switchover, do shut and no-shut the received connected
interface, traffic stops.
R2
| |
+ +
Client-----R1--------R3----Source
R2 is RP.
Root cause:
Client is sending join for G and Source is sending traffic for G.
Before SPT switchover, traffic flows R3-R2-R1, after SPT switchover,
traffic flows R3-R1. Now Check in R2, there will be 2 ifchannel gets
created. first is (*, G) ifchannel which gets created because of (*, G)
join received from R1, second is (S, G) ifchannel which gets created
because of (s,g,rpt) prune received from R1
Shut the receiver connected interface on R1, R1 will send a (*, G) prune
towards RP (R2). On receiving (*, G) prune, R2 deletes the (*, G) ifchannel.
(s,g) ifchannel with flag (s,g,rpt) set will be timeout after the prune timer
expires. Before this timer expires, do noshut the received connected inrterface
on R1. R1 will send a (*,G) join to R2(RP), So oil will be updated in (*, G),
but wont get updated in (s,g) since the flag (s,g,rpt) is set. So traffic flow
stops.
Fix: When (*, G) ifchannel is getting deleted because of (*, G) prune
received, as (*,G) prune indicates that the router no longer wishes
to receive shared tree traffic, so clear (S,G,RPT) flag on all the child (S,G)
ifchannel, which was created because of (S,G,RPT) prune received
Signed-off-by: Sarita Patra <saritap@vmware.com>
Found some more missing code that got dropped during the
upstreaming process causing issues with things actually
working.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When the mlag code was ported upstream the structure
of the calls in igmp_source_forward_start had been
reset and as a result we missed the call to check
that creating an ifchannel when we are DualActive
is allowed.
Ticket: CM-29941
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Description:
"show ip mroute" displays only installed(kernel) mroutes, where
as "show ip mroute json" diplays both installed and not installed
mroutes in the o/p.To make this consistant, diplaying only valid
routes in json o/p.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
Description:
Added json support for the following PIM commands.
1. show ip mroute [vrf NAME] count [json]
2. show ip mroute vrf all count [json]
3. show ip mroute [vrf NAME] summary [json]
4. show ip mroute vrf all summary [json]
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
We were using thread_cancel() directly instead of
THREAD_OFF which correctly ensures the pointer is not NULL.
Ticket:CM-29866
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Added a new show command "show ip multicast", display the multicast data
packet in and out on interface level.
Signed-off-by: Sarita Patra <saritap@vmware.com>
These are easy to get subtly wrong, and doing so can cause
nondeterministic failures when racing in parallel builds.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace sprintf with snprintf where straightforward to do so.
- sprintf's into local scope buffers of known size are replaced with the
equivalent snprintf call
- snprintf's into local scope buffers of known size that use the buffer
size expression now use sizeof(buffer)
- sprintf(buf + strlen(buf), ...) replaced with snprintf() into temp
buffer followed by strlcat
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Replace all `random()` calls with a function called `frr_weak_random()`
and make it clear that it is only supposed to be used for weak random
applications.
Use the annotation described by the Coverity Scan documentation to
ignore `random()` call warnings.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
It is possible that a if_lookup_by_index can return NULL
ensure that we handle this appropriately.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
And again for the name. Why on earth would we centralize this, just so
people can forget to update it?
Signed-off-by: David Lamparter <equinox@diac24.net>
Same as before, instead of shoving this into a big central list we can
just put the parent node in cmd_node.
Signed-off-by: David Lamparter <equinox@diac24.net>
There is really no reason to not put this in the cmd_node.
And while we're add it, rename from pointless ".func" to ".config_write".
[v2: fix forgotten ldpd config_write]
Signed-off-by: David Lamparter <equinox@diac24.net>
The only nodes that have this as 0 don't have a "->func" anyway, so the
entire thing is really just pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
Issue: no ip msdp mesh-group <word> source command
deleting the mesh group, which might be used by the member.
Solution: no ip msdp mesh-group <word> source command, deletes
the mesh-group source.
Add a new cli command "no ip msdp mesh-group <word>" to delete
the mesh group.
Signed-off-by: Sarita Patra <saritap@vmware.com>
JSON output for igmp group display is modified as follows for better python handling.
1. Under each interface make array of group as an object
2. Include source and group inside each group object
These improvements are required for the set of topotest cases which will be upstreamed shortly.
Signed-off-by: Saravanan K <saravanank@vmware.com>
This CLI will allow user to configure a igmp group limit which will generate
a watermark warning when reached.
Though watermark may not make sense without setting a limit, this
implementation shall serve as a base to implementing limit in future and helps
tracking a particular scale currently.
Testing:
=======
ip igmp watermark-warn <10-60000>
on reaching the configured number of group, pim will issue warning
2019/09/18 18:30:55 PIM: SCALE ALERT: igmp group count reached watermak limit: 210(vrf: default)
Also added group count and watermark limit configured on cli - show ip igmp groups [json]
<snip>
Sw3# sh ip igmp groups json
{
"Total Groups":221, <=====
"Watermark limit":210, <=========
"ens224":{
"name":"ens224",
"state":"up",
"address":"40.0.0.1",
"index":6,
"flagMulticast":true,
"flagBroadcast":true,
"lanDelayEnabled":true,
"groups":[
{
"source":"40.0.0.1",
"group":"225.1.1.122",
"timer":"00:03:56",
"sourcesCount":1,
"version":2,
"uptime":"00:00:24"
<\snip>
<snip>
Sw3(config)# do sh ip igmp group
Total IGMP groups: 221
Watermark warn limit(Set) : 210
Interface Address Group Mode Timer Srcs V Uptime
ens224 40.0.0.1 225.1.1.122 ---- 00:04:06 1 2 00:13:22
ens224 40.0.0.1 225.1.1.144 ---- 00:04:02 1 2 00:13:22
ens224 40.0.0.1 225.1.1.57 ---- 00:04:01 1 2 00:13:22
ens224 40.0.0.1 225.1.1.210 ---- 00:04:06 1 2 00:13:22
<\snip>
Signed-off-by: Saravanan K <saravanank@vmware.com>
Valid range for hashmasklen is 0-32 under IPv4; failure to validate this
results in a negative bitshift later
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This is a full rewrite of the "back end" logging code. It now uses a
lock-free list to iterate over logging targets, and the targets
themselves are as lock-free as possible. (syslog() may have a hidden
internal mutex in the C library; the file/fd targets use a single
write() call which should ensure atomicity kernel-side.)
Note that some functionality is lost in this patch:
- Solaris printstack() backtraces are ditched (unlikely to come back)
- the `log-filter` machinery is gone (re-added in followup commit)
- `terminal monitor` is temporarily stubbed out. The old code had a
race condition with VTYs going away. It'll likely come back rewritten
and with vtysh support.
- The `zebra_ext_log` hook is gone. Instead, it's now much easier to
add a "proper" logging target.
v2: TLS buffer to get some actual performance
Signed-off-by: David Lamparter <equinox@diac24.net>
Line break at the end of the message is implicit for zlog_* and flog_*,
don't put it in the string. Mid-message line breaks are currently
unsupported. (LF is "end of message" in syslog.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem: This happened in once in a while during testing the scenario multiple
times. When regstop timer expire and at that point if rpf interface doesn't
exist, the register state for the upstream gets struck in reg-prune state indefinitely.
This will not recover even when rpf comes back and traffic resumed because
register state is struck on prune.
RCA: Reg suppression expiry is keeping reg state unchanged when iif is absent.
Fix: When iif is absent during reg suppression expiry, treat it as couldreg
becoming false and move it NO_INFO state.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Problem: output is cut short when prefix string all octets are 3 digit.
RCA: Buffer was allocated only to hold ip addr str.
Fix: Added 3 bytes more to hold prefix length and a /.
Modified buffer in 'show ip pim bsrp-info' and 'show ip pim bsm database'
Signed-off-by: Saravanan K <saravanank@vmware.com>
Zebra is currently sending messages on interface add/delete/update,
VRF add/delete, and interface address change - regardless of whether
its clients had requested them. This is problematic for lde and isis,
which only listens to label chunk messages, and only when it is
waiting for one (synchronous client). The effect is the that messages
accumulate on the lde synchronous message queue.
With this change:
- Zebra does not send unsolicited messages to synchronous clients.
- Synchronous clients send a ZEBRA_HELLO to zebra.
The ZEBRA_HELLO contains a new boolean field: sychronous.
- LDP and PIM have been updated to send a ZEBRA_HELLO for their
synchronous clients.
Signed-off-by: Karen Schoener <karen@voltanet.io>
This is as per RFC. This is identified when conformance suite catched join.
RCA:
Packets were processed without checking allowed dest IP for that packet.
Fix:
Added check for dest IP
Converted this check to a function
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: preferred bsr routine, compare address in network byte order
Fix: changed to host format before comparision.
Testing:
Verified between 1.1.2.7 and 10.2.1.1, 10.2.1.1 is chosen as bsr
Initially:
R11# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 1.1.2.7
Priority Fragment-Tag State UpTime
0 2862 ACCEPT_PREFERRED 00:00:30
Last BSM seen: 00:00:30
After next bsr started:
R11# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 10.2.1.1
Priority Fragment-Tag State UpTime
0 3578 ACCEPT_PREFERRED 00:00:01
Last BSM seen: 00:00:01
R11# sh ip pim bsr
PIMv2 Bootstrap information
Current preferred BSR address: 10.2.1.1
Priority Fragment-Tag State UpTime
0 3578 ACCEPT_PREFERRED 00:00:04
Last BSM seen: 00:00:04
Signed-off-by: Saravanan K <saravanank@vmware.com>
Problem:
When the ifchannel is in SGRpt prune, if we receive a join, we go into no info
state but mroute still present with none oil
Join Prune Expiry timer on the ifchannel was still running when
Prune pending expired. This causes ifchannel not to be deleted and hence mroute.
Fix:
Stop expiry timer when we move into NOINFO state and delete the ifchannel.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: Upstreams which are in register state other than noinfo, doesnt remove
register tunnel from oif after it becomes nonDR
Fix: scan upstreams with iif as the old dr and check if couldReg becomes false.
If couldreg becomes false from true, remove regiface and stop reg timer.
Do not disturb the entry. Later the entry shall be removed by kat expiry.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA:
Either JP timer is used to send join or join timer.
We are not removing the group from jp aggregate during suppression.
So even if join timer is restarted, jp aggregate expiry during suppression
is sending join for the group.
Fix:
Remove the group from jp aggregate on the neighbor during jp suppression.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: This was todo item in current code base
Fix: Hello sent with 0 hold time before we update the pim ifp primary address
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: starg join fell in to SGRpt join check and was treated as SGRpt join
so ifchannel state machine moved from prunepending to noinfo.
Fix: Check if it is starg join and process
Signed-off-by: Saravanan K <sarav511@vmware.com>
RCA:
Trying to get primary address for the interface.
Unnumbered interface pick address from vrf device for non default.
While doing so it ends up in recursion without exit condition if vrf dev doesnt have any address.
Solution:
Break the recursion by checking if it is vrf device.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA:
It has asserted because during neighbor delete on a interface,
pim_number_of_nonlandelay_neighbors count has become less less than 0.
This was due to not updating the count when hello option changed.
Fix:
During hello option update, check and increment or decrement when this option changes.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA:
1. Prune processing during join state was putting of join expiry timer
2. Join received during prune pending state was not comparing hold time with remaining expiry timer.
Fix:
Fixed as per RFC 4601/7761
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: We are ignoring (*,G) prune when the RP in packet is not RP(G)
Fix:
According to RFC 4601 Section 4.5.2:
Received Prune(*,G) messages are processed even if the RP in the message does not match RP(G).
We have allowed starg prune to be processed in the scenario.
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: Periodic join is mostly sent by nbr jp timer except for few scenarios by upstream join timer
Fix: If join timer not running, we have to use nbr jp timer to calculate
remaining time for next join.
Signed-off-by: Saravanan K <saravanank@vmware.com>
Issue: Client1------LHR-----(int-1)RP(int-2)------client2
Client2 send IGMP join for group G.
Client1 send IGMP join for group G.
verify show ip mroute in RP, will have 2 OIL.
Client2 send IGMP leave.
Verify show ip mroute in RP, will still have 2.
Root cause: When RP receives IGMP join from client2, it creates
a (s,g) channel oil and add the interface int-2 into oil list and
set the flag PIM_OIF_FLAG_PROTO_IGMP to int-2
Client1 send IGMP join, LHR will send a (*,G) join to RP. RP will
add the interface int-1 into the oil list of (s,g) channel_oil and
will set the flag PIM_OIF_FLAG_PROTO_IGMP and PIM_OIF_FLAG_PROTO_PIM
to the int-1 and set PIM_OIF_FLAG_PROTO_PIM to int-2 as well. It is
happening because of the pim_upstream_inherited_olist_decide() and
forward_on() get all the oil and update the flag wrongly.
So now when client 2 sends IGMP prune, RP will not remove the int-2
from oil list since both PIM_OIF_FLAG_PROTO_PIM & PIM_OIF_FLAG_PROTO_IGMP
are set, it just unset the flag PIM_OIF_FLAG_PROTO_IGMP.
Fix: Introduced new flags in if_channel, PIM_IF_FLAG_MASK_PROTO_PIM
& PIM_IF_FLAG_MASK_PROTO_IGMP. If a if_channel is created because of
pim join or pim (s,g,rpt) prune received, then set the flag
PIM_IF_FLAG_MASK_PROTO_PIM. If a if_channel is created becuase of IGMP
join received, then set the flag PIM_IF_FLAG_MASK_PROTO_IGMP.
When an interface needs to be added into the oil list check if
PIM_IF_FLAG_MASK_PROTO_PIM or PIM_IF_FLAG_MASK_PROTO_IGMP is set, then
update oil flag accordingly.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Issue 1: "show ip pim interface traffic" not show prune TX/RX
Rootcause : not added the variable in the json
Fix : add prune TX/RX in show ip pim interface traffic json
Issue 2: "show ip pim rp-info" not shows the key iAmRp when it is false
Rootcause: Only display the key when the value is true.
Fix: add iAmRp as false in show ip pim rp-info json
Issue 3: "show ip pim rp-info" not showing outbound interface if it is empty
Rootcause: Only display when there is any OIL
Fix: When RP is not reachable then, the outbound interface is Unknown
The command "show ip pim rp-info json" not displaying the outbound
interafce if it is unknown
Signed-off-by: Sarita Patra <saritap@vmware.com>
S - Sparse Mode
C - indicates there is a member of the group directly connected to the router.
R -set on an (S, G) by the receipt of an (S, G) RP bit prune message.
F -This indicates that this router is a FHR and send register messages to RP to inform RP of this active source
P - OIL list is NULL. That means the router will send a prune.
T - At least one packet received via SPT.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem:
We are receiving PIM BSR packet over the pim interface which has no nbrs
According to RFC 5059 Sec 3.4
When a Bootstrap message is forwarded, it is forwarded out of every
multicast-capable interface that has PIM neighbors (including the one
over which the message was received).
RCA:
We are sending to all pim neighbors.
Fix:
We will avoid the interfaces which has no neighbors.
Verification: Manually verified that Pim router doesn't forward to intf with no nbrs
Signed-off-by: Saravanan K <saravanank@vmware.com>
RCA: When configured more than 32(MAXVIS), the inerfaces that are configured
after 32nd interfaces have the value of MAXVIF.
This is used as index to access the free vif tracker of array size 32(MAXVIFS).
So the channel oil list pointer which is present as the next field in pim structure get corrupt, when updating free vif.
This gets accessed during rpf update resulting in crash.
Fix: Refrain from allocating mcast interface structure and throw config error when more than MAXVIFS are attempted to configure.
Max vif checks are exempted for vrf device and pimreg as vrf device will be the first interface and not expected to fail and pimreg has reserved vif.
vxlan tunnel termination device creation has this check and throw warning on max vif.
All other creation are through CLI.
Signed-off-by: Saravanan K <saravanank@vmware.com>
