Anuradha Karuppiah <anuradhak@cumulusnetworks.com>: Author Summary

Builds triggered by Anuradha Karuppiah <anuradhak@cumulusnetworks.com>

Builds triggered by an author are those builds which contains changes committed by the author.
30
16 (53%)
14 (47%)

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.
13 (43% of all builds triggered)
2 (7% of all builds triggered)
-11
Build Completed Code commits Tests
FRR › TOPOPR › #384 1 month ago
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 1240 failed
FRR › FRRPULLREQ › #5960 1 month ago
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
5920 passed
FRR › TOPOPR › #383 2 months ago
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
5 of 1240 failed
FRR › TOPOPR › #382 2 months ago
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 1240 failed
FRR › RPKI › #630 2 months ago
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Testless build
FRR › FRR › #1675 2 months ago
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6890 passed
FRR › RPKI › #504 3 months ago
zebra: resolve link dependencies post nldump
Netdevices are not sorted in any fashion by the kernel during the initial
interface nldump. So you can get an upper device (such as an SVI) before
its corresponding lower device (bridge).

To fix this problem we skip resolving link dependencies during handling of
nldump notifications. Resolving instead at the end (when all the devices
are present)

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>

Ticket: CM-22388, CM-21796
Reviewed By: CCR-7845
Testing Done:
1. verified on a setup with missing linkages
2. automation - evpn-min
Testless build
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › TOPOPR › #384 1 month ago
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 1240 failed
FRR › TOPOPR › #383 2 months ago
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
5 of 1240 failed
FRR › TOPOPR › #382 2 months ago
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 1240 failed
FRR › TOPOPR › #343 4 months ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
5 of 972 failed
FRR › TOPOPR › #342 4 months ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 972 failed
FRR › TOPOPR › #339 4 months ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
689 passed
FRR › TOPOPR › #338 4 months ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
10 of 824 failed
FRR › TOPOPR › #284 5 months ago
zebra: install EVPN gateway MAC as static/sticky
SVI interface ip/hw address is advertised by the GW VTEP (say TORC11) with
the default-GW community. And the rxing VTEP (say TORC21) installs the GW
MAC as a dynamic FDB entry. The problem with this is a rogue packet from a
server with the GW MAC as source can cause a station move resulting in
TORC21 hijacking the GW MAC address and blackholing all inter rack traffic.

Fix is to make the GW MAC "sticky" pinning it to the GW VTEP (TORC11). This
commit does it by installing the FDB entry as static if the MACIP route is
received with the default-GW community (mimics handling of
mac-mobility-with-sticky community)

Sample output with from TORC12 with TORC11 setup as gateway -
root@TORC21:~# net show evpn mac vni 1004 mac 00:00:5e:00:01:01
MAC: 00:00:5e:00:01:01
 Remote VTEP: 36.0.0.11 Remote-gateway Mac
 Neighbors:
    45.0.4.1
    fe80::200:5eff:fe00:101
    2001:fee1:0:4::1

root@TORC21:~# bridge fdb show |grep 00:00:5e:00:01:01|grep 1004
00:00:5e:00:01:01 dev vx-1004 vlan 1004 master bridge static
00:00:5e:00:01:01 dev vx-1004 dst 36.0.0.11 self static
root@TORC21:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Ticket: CM-21508
Testless build
FRR › TOPOPR › #283 5 months ago
zebra: install EVPN gateway MAC as static/sticky
SVI interface ip/hw address is advertised by the GW VTEP (say TORC11) with
the default-GW community. And the rxing VTEP (say TORC21) installs the GW
MAC as a dynamic FDB entry. The problem with this is a rogue packet from a
server with the GW MAC as source can cause a station move resulting in
TORC21 hijacking the GW MAC address and blackholing all inter rack traffic.

Fix is to make the GW MAC "sticky" pinning it to the GW VTEP (TORC11). This
commit does it by installing the FDB entry as static if the MACIP route is
received with the default-GW community (mimics handling of
mac-mobility-with-sticky community)

Sample output with from TORC12 with TORC11 setup as gateway -
root@TORC21:~# net show evpn mac vni 1004 mac 00:00:5e:00:01:01
MAC: 00:00:5e:00:01:01
 Remote VTEP: 36.0.0.11 Remote-gateway Mac
 Neighbors:
    45.0.4.1
    fe80::200:5eff:fe00:101
    2001:fee1:0:4::1

root@TORC21:~# bridge fdb show |grep 00:00:5e:00:01:01|grep 1004
00:00:5e:00:01:01 dev vx-1004 vlan 1004 master bridge static
00:00:5e:00:01:01 dev vx-1004 dst 36.0.0.11 self static
root@TORC21:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Ticket: CM-21508
Testless build
FRR › TOPOPR › #282 5 months ago
zebra: install EVPN gateway MAC as static/sticky
SVI interface ip/hw address is advertised by the GW VTEP (say TORC11) with
the default-GW community. And the rxing VTEP (say TORC21) installs the GW
MAC as a dynamic FDB entry. The problem with this is a rogue packet from a
server with the GW MAC as source can cause a station move resulting in
TORC21 hijacking the GW MAC address and blackholing all inter rack traffic.

Fix is to make the GW MAC "sticky" pinning it to the GW VTEP (TORC11). This
commit does it by installing the FDB entry as static if the MACIP route is
received with the default-GW community (mimics handling of
mac-mobility-with-sticky community)

Sample output with from TORC12 with TORC11 setup as gateway -
root@TORC21:~# net show evpn mac vni 1004 mac 00:00:5e:00:01:01
MAC: 00:00:5e:00:01:01
 Remote VTEP: 36.0.0.11 Remote-gateway Mac
 Neighbors:
    45.0.4.1
    fe80::200:5eff:fe00:101
    2001:fee1:0:4::1

root@TORC21:~# bridge fdb show |grep 00:00:5e:00:01:01|grep 1004
00:00:5e:00:01:01 dev vx-1004 vlan 1004 master bridge static
00:00:5e:00:01:01 dev vx-1004 dst 36.0.0.11 self static
root@TORC21:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Ticket: CM-21508
Testless build
Build Completed Code commits Tests
FRR › RPKI › #630 2 months ago
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Testless build
FRR › FRR › #1675 2 months ago
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-22700
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6890 passed