Sarita Patra <saritap@vmware.com>: Author Summary

Builds triggered by Sarita Patra <saritap@vmware.com>

Builds triggered by an author are those builds which contains changes committed by the author.
48
28 (58%)
20 (42%)

Breakages and fixes

Broken means the build has failed but the previous build was successful.
Fixed means that the build was successful but the previous build has failed.
11 (23% of all builds triggered)
3 (6% of all builds triggered)
-8
Build Completed Code commits Tests
FRR › FRR › #2342 3 months ago
bgpd : add prefix-length in show ip bgp neighbor advertised routes key
Issue:
ip route 15.1.1.0/24 10.112.158.15
ip route 15.1.1.0/32 10.112.158.15
Brought up ebgp session between two FRR routers and
redistributed static routes via BGP and verfied the advertising
routes in the peer.

Verify the command "show ip  bgp neighbors <neighbor address>
advertised-routes json". It only shows 15.1.1.0/32 route details.

Root casue:
For both the routes "15.1.1.0/24" and "15.1.1.0/32" the advertised
routes key is the prefix i.e. "15.1.1.0".

Fix:
Modify the key to prefix/prefix-length.

Signed-off-by: Sarita Patra <saritap@vmware.com>
8194 passed
FRR › FRR › #2258 3 months ago
pimd: new cli to configure last-member-query-count & last-member-query-interval
Introduce new cli commands ip igmp last-member-query-count <1-7>
ip igmp last-member-query-interval <1-255> deciseconds.

Display the config in show running config and show ip igmp interface

Signed-off-by: Sarita Patra <saritap@vmware.com>
1 of 8236 failed
FRR › FRRPULLREQ › #7881 3 months ago
pimd: new cli command show ip mroute summary
Introduced a new command "show ip mroute summary"
to display total number of (*, G) and (S, G) mroutes
created and number of mroutes installed in the kernel.

Signed-off-by: Sarita Patra <saritap@vmware.com>
1 of 6822 failed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › FRR › #2258 3 months ago
pimd: new cli to configure last-member-query-count & last-member-query-interval
Introduce new cli commands ip igmp last-member-query-count <1-7>
ip igmp last-member-query-interval <1-255> deciseconds.

Display the config in show running config and show ip igmp interface

Signed-off-by: Sarita Patra <saritap@vmware.com>
1 of 8236 failed
FRR › FRR › #2222 4 months ago
pimd: fix (s,g) expiry.
Fix: When RP receives a (*, G) join and corresponding (s,g)
is present, then check for OIL is not-empty, then only switch
upstream (s, g) state to JOINED.

Signed-off-by: Sarita Patra <saritap@vmware.com>
1 of 7725 failed
FRR › FRRPULLREQ › #7185 5 months ago
pimd: Introduce mroute_creation in channel oil data structure
Issue: (*,G) mroute uptime is not updated in mroute table,
after deleting and adding the RP

Root cause: When RP gets deleted or becomes not reachable, then
we un-install the entry from the kernel, but still maintains the
entry in the stack. When  RP gets re-configured or becomes reachable,
"show ip mroute" shows the uptime, when the channel_oil gets created.

Fix: Introduce a new time mroute_creation in the channel_oil, gets
updated when mroute gets installed in the kernel.

Signed-off-by: Sarita Patra <saritap@vmware.com>
2 of 4861 failed
FRR › FRRPULLREQ › #6663 7 months ago
pimd: reject inconsistent address/mask "ip pim rp command"
Issue: Configure "ip pim rp x.x.x.x 225.0.0.0/4".
Show running config shows "ip pim rp x.x.x.x 224.0.0.0/4"
This is mis-leading.

Root-cause: Internally 225.0.0.0/4 is getting converted to
224.0.0.0/4 group mask, since the prefix length is 4.

Fix: Restrict the user to configure inconsistent group address
mask by throughing a cli error "Inconsistent address and mask".

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: Don't refersh the oif_creation timer if S,G already present
Issue: Shut the RP interface in the router RP. LHR will get to know
RP becomes not-reachable, so it send a prune towards the RP. On
receiving the prune, RP clear the (*, G) entry, but (S, G) should
not get removed if present.
Now no-shut the RP interface in the router RP. LHR will send a (*, G)
join towards the RP. On receiving join FRR create the (*, G) entry.
Along with this, it also add the interface(join received) in the OIL
of (S, G) and also refresh the (S, G) timer.

Fix: Dont refresh the timer for S, G or (*, G), if the flag for the
channel OIL is PIM_OIF_FLAG_PROTO_ANY.

Signed-off-by: Sarita Patra <saritap@vmware.com>
4434 passed
FRR › FRR › #1604 11 months ago
bgpd: remove ip prefix from as-path, <large,ext>community-list
The existing commands "ip as-path", "ip community list", "ip extcommunity
list" & "ip largecommunity list" is used to configure both for ipv4 and
ipv6. So the prefix "ip" is removed from these commands.
All the configuration, show related configuration, show running config
& boot up with write memory is also verified with the provided fix.

Signed-off-by: Sarita Patra <saritap@vmware.com>
6852 passed
FRR › TOPOPR › #359 1 year ago
pimd: fix indentation warnings
Signed-off-by: Sarita Patra <saritap@vmware.com>
12 of 1080 failed
FRR › TOPOPR › #337 1 year ago
pimd: Fix memory leak pim nexthop creation
While terminating pim instance, the memory allocated for pim nexthop
should be released before deallocating the memory of pim nexthop cache(pnc).
This resolves the memory leak detected in pnc->nexthop creation.

Signed-off-by: Sarita Patra <saritap@vmware.com>
28 of 918 failed
FRR › TOPOPR › #333 1 year ago
pimd: Fix memory leak pim nexthop creation
While terminating pim instance, the memory allocated for pim nexthop
should be released before deallocating the memory of pim nexthop cache(pnc).
This resolves the memory leak detected in pnc->nexthop creation.

Signed-off-by: Sarita Patra <saritap@vmware.com>
2 of 927 failed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › FRR › #2016 6 months ago
pimd: Addressing the review comments
Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: update pim upstream structure when RP gets configured
When a new RP is configured, find all the (*, G) upstream whose
group belongs to the new RP and then update the upstream structure
with the below fields.
1. De-register for the old RP.
2. Set the upstream address as new RP
3. Register for the new RP.
4. Update the upstream rpf information and kernel multicast forwarding
cache(MFC), if the new RP is reachable.

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: clear rp_info source_nexthop when RP becomes not reachable
When route to RP gets modified, FRR receives a notification from
zebra, and call the function pim_update_rp_nh() to compute the
new nexthop and will update the source_nexthop information of
rp_info. This is not working for the case when RP becomes not
reachable.

Fix: When FRR receives a notification from zebra saying RP becomes
not reachable, then delete the source_nexthop informatio of rp_info.

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: clear upstream rpf information when RP becomes not reachable
When route to RP gets modified, FRR receives a notification from
zebra, and call the function pim_resolve_upstream_nh() to compute the
nexthop and update upstream->rpf structure.
Issue: In case when RP becomes not reachable, FRR only uninstall
the mroute from the kernal, but not update the upstream->rpf structure.

Fix: When FRR receives a notification from zebra saying RP becomes
not reachable, then update the following fields.
1. update channel_oil incoming interface as MAXVIFS
2. Un-install the mroute from the kernel.
3. Switch upstream state from JOINED to NOTJOINED.
4. Clear the nexthop information of the upstream.

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: update pim upstream structure when RP gets deleted
When a RP gets deleted, find all the (*, G) upstream whose
group belongs to the deleted RP.

case 1: if the group belongs to any other rp, then call
pim_upstream_update() to update the upstream addr and rpf
information.

case 2: If no RP found for the group, then clear the pim
upstream address and rpf information.

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: Handling Null incoming interface of dummy upstream
When FRR receives IGMP/PIM (*, G) join and RP is not configured or not
reachable, then we are creating a dummy upstream with incoming interface
as NULL and upstream address as INADDR_ANY.

Added upstream address and incoming interface validation where it is necessary,
before doing any operation on the upstream.

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: Handling delete nexthop track for PIM upstream address
When RP gets deleted, find all the (*, G) upstream whose group belongs to
the deleted RP, release the upstream from pnc->upstream_hash in the function
pim_delete_tracked_nexthop().

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: Don't install dummy channel oil entry into Kernel
If the channel oil is dummy(channel_oil->is_valid != True),
then don't install entry into the kernel.

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: Handling dummy upstream in "show ip pim upstream"
When FRR receives IGMP/PIM (*, G) join and RP is not configured or
not reachable, then we are creating a dummy upstream with incoming
interface as NULL.
Added some null checks for the incoming interface, while displaying
the pim upstream information in the cli command "show ip pim upstream".

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: create dummy (*,G) upstream when RP not configured/reachable
In this commit, we are creating a dummy upstream & dummy channel_oil
for (*, G) when RP is not configured or not reachable.
Dummy upstream: <upstream_addr = INADDR_ANY, rpf = Unknown>
Dummy channel oil: <iif = MAXVIFS>

Signed-off-by: Sarita Patra <saritap@vmware.com>
pimd: added comments for upstream and channel_oil new values
Added comments which explains the new values for existing fields
and new fields in the upstream and channel_oil data structure.

Following are the summary of the behaviour change in PIM code.

Scenario 1 : RP doesn’t exist/RP not reachable
Event: Join received
Current behaviour:
        No upstream gets created
Changed behaviour:
        Upstream data structure created with below info
        upstream_addr: INADDR_ANY
        channel_oil iif:  MAXVIF
        channel_oil is_valid: FALSE (flag introduced to indicate if this entry is valid to get installed in hardware)
        RPF details: Not valid
        Join state: NOT_JOINED
        Kernal installed: FALSE

Scenario 2: Dummy upstream exists
Event: RP configured
Current Behaviour:
        upstream address updated for the dummy upstream created.
Changed Behaviour:
        upstream_addr: RP address
        channel_oil iif:  MAXVIF
        channel_oil is_valid: FALSE
        RPF details: only RP address updated
        Join state: NOT_JOINED
        Kernel installed: FALSE

Scenario 3: Dummy upstream exists
Event: RP becomes reachable
Current Behaviour:
        Update channel oil, rpf details in the upstream and install in hardware
Changed Behaviour:
        upstream_addr: RP Adress
        channel_oil iif:  MAXVIF
        channel_oil is_valid: FALSE
        RPF details: RPF details updated via NHT callback
        Join state: JOINED
        Kernel installed: TRUE

Scenario 4: MRoute exists
Event: RP gets deleted
Current behaviour:
        Nothing got updated in him upstream and channel oil,
        join timer still runs. Mroute still exists in kernel.
Changed behaviour:
        upstream_addr: INADDR_ANY
        channel_oil iif:  MAXVIF
        channel_oil is_valid: FALSE
        RPF details: Not valid
        Join state: NOT_JOINED (also sent prune towards deleted RPF nbr)
        Kernel installed: FALSE

Scenario 5: MRoute Exists
Event: RP unreachable
Current behaviour:
        Nothing got updated in him upstream and channel oil,
        join timer still runs. Mroute sdeleted from  kernel.
Changed behaviour:
        upstream_addr: RP address
        channel_oil iif:  MAXVIF
        channel_oil is_valid: FALSE
        RPF details: only RP address updated
        Join state: NOT_JOINED (also sent prune towards deleted RPF nbr)
        Kernel installed: FALSE

Scenario 6: Mroute exists
Event: Better RP configured with precise group range & reachable.
Current behaviour:
        No effect on existing route.
Changed behaviour:
        Upstream address: Better RP
        RPF interface: towards the better RP
        Join state: JOINED (Send a prune towards the old RP and send a join
                towards the better RP)

Scenario 7: Mroute exists
Event: RP deleted and another RP with broad group range fits this group & reachable
Current behaviour:
        No effect on current behaviour
Changed behaviour:
        Upstream address: next available RP
        RPF interface: towards the next available RP
        Join state: JOINED (Send a prune towards the old RP and send a join
                towards the better RP)
Signed-off-by: Sarita Patra <saritap@vmware.com>
6996 passed
FRR › FRR › #1921 7 months ago
pimd: Don't refersh the oif_creation timer if S,G already present
Issue: Shut the RP interface in the router RP. LHR will get to know
RP becomes not-reachable, so it send a prune towards the RP. On
receiving the prune, RP clear the (*, G) entry, but (S, G) should
not get removed if present.
Now no-shut the RP interface in the router RP. LHR will send a (*, G)
join towards the RP. On receiving join FRR create the (*, G) entry.
Along with this, it also add the interface(join received) in the OIL
of (S, G) and also refresh the (S, G) timer.

Fix: Dont refresh the timer for S, G or (*, G), if the flag for the
channel OIL is PIM_OIF_FLAG_PROTO_ANY.

Signed-off-by: Sarita Patra <saritap@vmware.com>
6577 passed
FRR › FRR › #1583 11 months ago
ospfd: handling of OSPF_AREA_RANGE_ADVERTISE flag
Issue: # https://github.com/FRRouting/frr/issues/1836

Issue 1: if the router ospf current configuration is "area 0.0.0.2
range 1.0.0.0/24 cost 23" and user try to configure "area 0.0.0.2
range 1.0.0.0/24 not-advertise", the existing o/p is "area 0.0.0.2
range 1.0.0.0/24 cost 23 not-advertise". The keywords "not-advertise"
& "cost" are multually exclusive, so they should not come together.
The vice versa way configuration is working fine.

Fix: When ospf area range "not-advertise", the cost should be initialized
to OSPF_AREA_RANGE_COST_UNSPEC.

Issue 2: if the router ospf current configuration "area 0.0.0.2 range
1.0.0.0/24 substitute 2.0.0.0/24" and user try to configure "area 0.0.0.2
range 1.0.0.0/24 not-advertise" the existing o/p is "area 0.0.0.2 range
1.0.0.0/24 not-advertise substitute 2.0.0.0/24". The keywords
"not-advertise" & "substiture" are multually exclusive, so they should
not come together. The vice versa way configuration is working fine.

Fix: When ospf area range "not-advertise" is configured,
ospf_area_range_substitute_unset() should be get called.

Issue 3: if the router ospf6 current configuration is "area 0.0.0.2
range 2001::/64 cost 23" and user try to configure "area 0.0.0.2 range
2001::/64 advertise", the existing o/p is area 0.0.0.2 range 2001::/64.
The keyword "cost 23" disappears.

Fix: When ospf area range "advertise" is configured and the range is not
NULL, the cost should not be modified.

Signed-off-by: Sarita Patra <saritap@vmware.com>
7335 passed