Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>: Author Summary

Builds triggered by Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>

Builds triggered by an author are those builds which contains changes committed by the author.
33
18 (55%)
15 (45%)

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.
6 (18% of all builds triggered)
1 (3% of all builds triggered)
-5
Build Completed Code commits Tests
FRR › FRR › #2419 1 month ago
lib: Introducing a 3rd state for route-map match cmd: RMAP_NOOP
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP

Traditionally route map MATCH rule apis  were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:

State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away

State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH

We require a 3rd state because of the following situation:

The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.

Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"

With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.

As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.

Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
bgpd: Route-map VNI in-filter filters out all the routes for EVPN
Issue1: When a vni in-filter eg:"neighbor X.X.X.X route-map RM-VNI-FILTER in"
is configured under evpn address-family, all the received routes are dropped
regardless of whether the route has a matching vni or not.
(Where RM-VNI-FILTER contains "match evpn vni 100")

Issue2: Routes with 2 labels are not filtered correctly

Issue3: This filter should not get applied for MPLS routes. For MPLS routes,
we need route-map to handle a 3rd state besides match/nomatch called: noop.

Fix1: The handler bgp_update() that services the received route ignored the
route's label while deciding whether to filter it or not.
As part of the fix, the handler now uses the label info to make the
decision about whether to filter the route or not.

Fix2: route_match_vni() now tries to match both the labels within the route

Fix3: route_match_vni() should return noop when it encounters an mpls based
route. For this, route_map library should handle this 3rd state: RMAP_NOOP.

Related fix : Extract tunnel type
This fix relies on PR 4314 #4314 to extract the tunnel type from bgp extended
communities. The information about the route's tunnel type (vxlan or mpls)
is needed to apply "match evpn vni xx" rule.  This rule is applicable to
vxlan routes, and should exit safely for mpls based evpn routes.

Signed-off-by: Lakshman Krishnamoorthy lkrishnamoor@vmware.com
8763 passed
FRR › FRR › #2273 3 months ago
Revert of PR 4078 and PR 4315
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
8186 passed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › FRR › #2203 4 months ago
bgpd: Extract tunnel type from extended communities
This diff contains 2 parts:
1. Extract the tunnel type info from bgp extended communities.
2. Make rfapi use this common tunnel type ap

Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
1 of 7697 failed
FRR › FRR › #2201 4 months ago
bgpd: evpn json cli bug fix
Bug: If there are 2 different prefixes under an rd, the
output of "show bgp l2vpn evpn json" would print only one of the
prefixes.

RCA: prefix info was added to the json_object once per rd. Hence,
prefix and rd were added just once, as the loop iterated over all
the prefixes and paths.

This is related to my earlier commit that went in via PR 4283:
https://github.com/FRRouting/frr/pull/4283

Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
6641 passed
FRR › TOPOPR › #365 10 months ago
bgpd: Route Server support for evpn address-family Signed-off-by: Lakshman Krishnamoorthy lkrishnamoor@vmware.com
9 of 1116 failed
FRR › TOPOPR › #364 10 months ago
bgpd: Route Server support for evpn address-family Signed-off-by: Lakshman Krishnamoorthy lkrishnamoor@vmware.com
10 of 992 failed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
You have insufficient permissions to see all of the builds.