[Orchagent]: FdbOrch changes for EVPN VXLAN #1275

jainp1979 · 2020-04-28T21:31:42Z

This Change set is to support EVPN MAC routes addition/deletion in ASIC.

HLD Location : https://github.com/Azure/SONiC/pull/437/commits

Signed-off-by: Pankaj Jain [email protected]

What I did
Support for EVPN advertised mac routes

Why I did it
Part of overall EVPN-VXLAN Implementation

How I verified it
compiled and Unit tested

Details if related
Depends on the following PRs:
#1264

msftclas · 2020-04-28T21:31:56Z

All CLA requirements met.

lgtm-com · 2020-04-28T21:44:13Z

This pull request introduces 7 alerts when merging acb5c7e into 3829053 - view on LGTM.com

new alerts:

5 for Unused import
1 for Unused local variable
1 for Variable defined multiple times

jainp1979 · 2020-04-29T05:43:37Z

Dependent on the following PRs:
#1264

gord1306 · 2020-05-19T03:23:00Z

orchagent/fdborch.cpp

        return false;
    }

-    if (!m_portsOrch->getPortByBridgePortId(attr.value.oid, port))
+    if (!m_portsOrch->getPortByBridgePortId(bridge_port_id, port))
    {
        SWSS_LOG_ERROR("Failed to get port by bridge port ID 0x%" PRIx64, attr.value.oid);


attr.value.oid should change to bridge_port_id ?

Yes definitely; I will correct it.
Thanks for spotting the error.

Rectified in latest commit.

gord1306 · 2020-05-19T03:30:32Z

orchagent/fdborch.cpp

    }

-    sai_status_t status = sai_fdb_api->create_fdb_entry(&fdb_entry, (uint32_t)attrs.size(), attrs.data());
-    if (status != SAI_STATUS_SUCCESS)
+    string key = "Vlan" + to_string(vlan.m_vlan_info.vlan_id) + ":" + entry.mac.to_string();


this string is unused variable ?

Yes; I will remove that.

Rectified in latest commit

gord1306 · 2020-05-21T06:02:54Z

orchagent/fdborch.cpp

-    attr.value.s32 = (type == "dynamic") ? SAI_FDB_ENTRY_TYPE_DYNAMIC : SAI_FDB_ENTRY_TYPE_STATIC;
+    if (origin == FDB_ORIGIN_VXLAN_ADVERTIZED)
+    {
+        attr.value.s32 = (type == "dynamic") ? SAI_FDB_ENTRY_TYPE_STATIC_MACMOVE : SAI_FDB_ENTRY_TYPE_STATIC;


Which PR contains this define SAI_FDB_ENTRY_TYPE_STATIC_MACMOVE. The SAI PR1024 doesn't include this constant

This is how it was proposed initially;
later as part of PR filing it was changed; Once the PR1024 gets merged; I will update the code;

Code is updated as per SAI PR1024

Signed-off-by: Pankaj Jain <[email protected]>

1. Review comments incorporated 2. Dependency for PR sonic-net#885 is resolved 3. Added test_evpn_fdb.py pytest script to verify EVPN-VXLAN-FDB 4. compiled and verified the FDB functionality with EVPN 5. Changes to handle the static mac and aging from CLI

vasant17 · 2020-10-08T16:47:40Z

orchagent/fdborch.cpp

-                        entry.mac.to_string().c_str(), entry.bv_id);
-
-        if (!inserted.second)
+        bool mac_move = false;


Why do we have to interlace add and move? Can we seperate them out as the caller anyways know if its a move or add?

You are right, Caller knows it; but since storeFdbEntryState takes FdbUpdate as a parameter which only has add/del indication;
Kept the function signature same and added the logic;
Also only CRM-Counter is handled differently in MOVE case so it did not seem complicated either.

vasant17 · 2020-10-08T17:08:35Z

orchagent/fdborch.cpp


-    case SAI_FDB_EVENT_FLUSHED:
+        if (!m_portsOrch->getPortByBridgePortId(bridge_port_id, update.port))


How do we know bridge_port_id is valid? If it is, we do NOT need to call this function as update.port is already populated at the start of the function.

Yes; you are right
It will be removed in next update.

vasant17 · 2020-10-08T17:12:29Z

orchagent/fdborch.cpp

-                       bridge port ID: 0x%" PRIx64 ".",
-                       update.entry.mac.to_string().c_str(), entry->bv_id,
-                       bridge_port_id);
+        if (existing_entry->second.bridge_port_id != bridge_port_id)


Assuming existing_entry->second.bridge_port_id is always valid, I think we should do this comparison only if bridge_port_id is also valid, if it is NOT, I think we should go ahead and delete it. Of course we still need to get the port by using the existing_entry->bridge_port_id

validity of bridge-port is already checked in the beginning.
As you indicated in previous comment, that check is not required.
This comparison is fine and fdb entry is deleted irrespective of the comparison result.

vasant17 · 2020-10-08T17:13:54Z

orchagent/fdborch.cpp

+            {
+                SWSS_LOG_NOTICE("FdbOrch AGE notification: Failed to get port by bridge port ID 0x%lx", existing_entry->second.bridge_port_id);
+            }
+            // dont return, let it delete just to bring SONiC and SAI in sync


Delete this commented out code? I wont mind keeping it as it helps the reader!

Lets keep it;

vasant17 · 2020-10-08T17:21:13Z

orchagent/fdborch.cpp

+    {
+        port_attr[1].id = SAI_FDB_FLUSH_ATTR_ENTRY_TYPE;
+        port_attr[1].value.s32 = SAI_FDB_FLUSH_ENTRY_TYPE_DYNAMIC;
+        status = sai_fdb_api->flush_fdb_entries(gSwitchId, 2, port_attr);


can we call this only once and use attr_count variable?

Same comment applies to below two functions.

vasant17 · 2020-10-08T17:28:30Z

orchagent/fdborch.h

 struct SavedFdbEntry
 {
-    FdbEntry entry;
+    MacAddress mac;


Why did we remove FdbEntry and added mac and vlanID explicitly. Can we keep FdbEntry and use its overloaded comparision operator to compare savedFdbEntry?

SaveFdbEntry is used for storing an FDB which has valid vlan (vlan is created) but is waiting for the port to become the associated vlan's member.
now if vlan gets deleted, this entry is stuck in the saveFdbEntry;
later when user deletes the FDB, there is no way to compare it with bv_id (because that is no more there) hence changed to vlan-id so that delete request can be compared against FDBs in savedFdbEntry.

vasant17 · 2020-10-08T17:29:36Z

orchagent/fdborch.h

 struct SavedFdbEntry
 {
-    FdbEntry entry;
+    MacAddress mac;
+    unsigned short vlanId;
    string type;


Can we remove all the variable below this variable and add fdbData as a variable?

vasant17 · 2020-10-08T17:30:56Z

orchagent/fdborch.h

    bool add;
 };

+struct FdbData


This structure will contain all the information related to an FDB entry, so, it would be neat keep VxLAN related info in a separate structure and add it here as a variable, but I will leave it up to you!

keeping it the same for now.

vasant17 · 2020-10-08T17:36:03Z

orchagent/fdborch.h

-    bool removeFdbEntry(const FdbEntry&);
-    void flushFDBEntries(sai_object_id_t bridge_port_oid,
-                         sai_object_id_t vlan_oid);
+    bool addFdbEntry(const FdbEntry&, const string&, const string&, FdbOrigin origin, const string& remote_ip="", unsigned int vni=0, const string& esi="");


Why not use FDBData structure here, instead of passing 6 extra arguments?

Review comments incorporated.

removed commented code.

prsunny · 2020-11-13T01:33:41Z

cfgmgr/vlanmgr.cpp

-    std::string res;
-    EXEC_WITH_ERROR_THROW(cmds.str(), res);
+    if (isVlanMemberStateOk(key)) {
+        ostringstream cmds, inner;


You could define this outside to avoid duplicate declaration

prsunny · 2020-11-13T01:34:12Z

cfgmgr/vlanmgr.cpp

-      BRIDGE_CMD " vlan add vid " + std::to_string(vlan_id) + " dev " << shellquote(port_alias) << " " + tagging_cmd;
-    cmds << BASH_CMD " -c " << shellquote(inner.str());
+
+    const std::string key = std::string("") + "Vlan1|" + port_alias;


This has been included in #885, will remove from here.

prsunny · 2020-11-13T01:44:35Z

cfgmgr/vlanmgr.cpp

@@ -241,6 +264,137 @@ bool VlanMgr::isVlanMacOk()
    return !!gMacAddress;
 }

+void VlanMgr::doSwitchTask(Consumer &consumer)


Not sure a CLI/config is introduced for this. Lets discuss this in WG call to understand more

This has been included in #885, will remove from here.

prsunny · 2020-11-13T01:50:52Z

cfgmgr/vlanmgr.cpp

@@ -103,7 +111,7 @@ bool VlanMgr::addHostVlan(int vlan_id)
      + BASH_CMD + " -c \""
      + BRIDGE_CMD + " vlan add vid " + std::to_string(vlan_id) + " dev " + DOT1Q_BRIDGE_NAME + " self && "
      + IP_CMD + " link add link " + DOT1Q_BRIDGE_NAME
-               + " up"
+               + " down"


This is a behavior change.

This has been included in #885, will remove from here.

prsunny · 2020-11-13T01:51:59Z

cfgmgr/vlanmgr.cpp

-                    fvVector.push_back(i);
-                }
-                /* Set vlan mtu */
+                {	


Looks like tabspaces got added. Please fix

prsunny · 2020-11-13T02:50:50Z

orchagent/portsorch.cpp

@@ -3709,8 +3831,10 @@ bool PortsOrch::removeLag(Port lag)
        return false;
    }

+


Remove extra line

prsunny · 2020-11-13T02:51:54Z

orchagent/portsorch.cpp

+        {
+        	updateDbVlanOperStatus(Vlan, "up");
+        }
+        SWSS_LOG_NOTICE("Vlan %s Port %s state %s m_up_member_count %d",


Please change to INFO

prsunny · 2020-11-13T02:52:10Z

orchagent/portsorch.cpp

+    {
+        return ;
+    }
+    SWSS_LOG_NOTICE("Port %s oper state set from %s to %s",


Change to INFO

prsunny · 2020-11-13T02:52:34Z

orchagent/portsorch.cpp

+        {
+        	updateDbVlanOperStatus(Vlan, "up");
+        }
+        SWSS_LOG_NOTICE("Vlan %s Port %s state %s m_up_member_count %d",


Change to INFO

prsunny · 2020-11-13T02:55:07Z

orchagent/port.h

@@ -24,6 +24,7 @@ namespace swss {

 struct VlanMemberEntry
 {
+    std::string                alias;


is this the Vlan name?

gord1306 · 2020-11-25T09:25:04Z

orchagent/portsorch.cpp

@@ -3411,13 +3475,14 @@ bool PortsOrch::removeBridgePort(Port &port)
    SWSS_LOG_INFO("Flush FDB entries for port %s", port.m_alias.c_str());


Should this flushFDBEntries operation be called before if (port.m_fdb_count != 0)

Str1ker17 · 2020-12-07T13:55:33Z

orchagent/fdborch.cpp

-        // try to insert an FDB entry. If the FDB entry is not ready to be inserted yet,
-        // it would be added back to the saved_fdb_entries structure by addFDBEntry()
-        (void)addFdbEntry(fdb.entry, fdb.type);
+        for (const auto& fdb: fdb_list)


The additional inner loop looks like a mistake. Has it ever compiled? I got an error on gcc 8.3. Probably you want a single-level loop.

yes; it should be single loop;

@jainp1979 Do you plan to maintain this pull request further to integrate it into master branch? There are some changes requested and some new merges introduced conflicts with your code.

lgtm-com · 2020-12-24T02:07:12Z

This pull request fixes 1 alert when merging 41a4a18 into c39a4b1 - view on LGTM.com

fixed alerts:

1 for FIXME comment

srj102 · 2020-12-24T07:25:57Z

orchagent/fdborch.cpp

@@ -1448,8 +1247,7 @@ void FdbOrch::notifyTunnelOrch(Port& port)
 {
    VxlanTunnelOrch* tunnel_orch = gDirectory.get<VxlanTunnelOrch*>();

-    if((port.m_type != Port::TUNNEL) ||
-       (port.m_fdb_count != 0))
+    if(port.m_type != Port::TUNNEL)


With this change, Tunnel Bridge port will now be deleted even though the number of EVPN MACs over a Tunnel is non zero. This will fail and hence the m_fdb_count variable needs to be updated and deleteTunnelPort should be called only when the number goes down to 0.

@srj102 @prsunny The m_fdb_count logic is part of generic L2 enhancements and it is used to check for fdb count before deleting a bridgeport, which in turn prevents deleting lag or vlan when fdb entries are present. This change is already part of #885. We can bring in that change back just for tunnel, but this issue exists for all the non tunnel cases as well. let me know if you want the change to be done here only for tunnel or in general.
BTW, if the m_fdb_count is not 0, is there a trigger to delete all the pending tunnel bridgeports when the m_fdb_count becomes 0? How is it handled if the tunnel bridgeport is created again before fdb count becomes 0?

The change in notifyTunnelOrch to check for fdb count could be left as was earlier. PR 885 will not have the changes pertaining to notifyTunnelOrch.
If it is clear that PR 885 will not be merged for Dec release then we should bring back the changes for all types of Port objects - Phy port, LAG, Vlan, Tunnel.

notifyTunnelOrch is called from different places in fdborch whenever the fdb count becomes zero.
on becoming zero the deleteTunnelPort is called which checks for the presence of IMR/IP routes over the tunnel. If there are IMR/IP routes then the tunnel bridge port and tunnel is not deleted.
Similarly when the IMR/IP route count becomes zero the m_fdb_count is checked in vxlanorch before deleting the tunnel port/bridgeport.

added the reference count logic for tunnels

lgtm-com · 2020-12-28T01:24:32Z

This pull request fixes 1 alert when merging f17b20e into 6eb36d9 - view on LGTM.com

fixed alerts:

1 for FIXME comment

prsunny · 2020-12-29T18:41:43Z

orchagent/portsorch.h

@@ -169,7 +171,7 @@ class PortsOrch : public Orch, public Subject
    Port m_cpuPort;
    // TODO: Add Bridge/Vlan class
    sai_object_id_t m_default1QBridge;
-    sai_object_id_t m_defaultVlan;
+    sai_object_id_t   m_defaultVlan;


Please remove this extra space

prsunny · 2020-12-29T18:41:56Z

orchagent/portsorch.h

@@ -198,6 +200,7 @@ class PortsOrch : public Orch, public Subject
    map<set<int>, tuple<string, uint32_t, int, string, int>> m_lanesAliasSpeedMap;
    map<string, Port> m_portList;
    unordered_map<sai_object_id_t, int> m_portOidToIndex;
+


Why this extra line?

prsunny · 2020-12-29T18:42:23Z

orchagent/portsorch.h

@@ -9,6 +9,7 @@
 #include "observer.h"
 #include "macaddress.h"
 #include "producertable.h"
+#include "notificationproducer.h"


Looks like not relevant in this PR. Please remove

prsunny · 2020-12-29T18:42:41Z

orchagent/portsorch.cpp

                m_portOidToIndex[id] = index;
+                m_port_ref_count[alias] = 0;   


Why this change?

prsunny · 2020-12-29T18:48:58Z

orchagent/fdborch.cpp

+         * but we should not delete this mac here since now
+         * mac in orchagent represents locally learnt
+         */
+        SWSS_LOG_NOTICE("FdbOrch RemoveFDBEntry: mac=%s fdb origin is different; found_origin:%d delete_origin:%d",


Please change to INFO

prsunny · 2020-12-29T18:49:09Z

orchagent/fdborch.cpp

                       entry.mac.to_string().c_str(), entry.bv_id);
        return true; //FIXME: it should be based on status. Some could be retried. some not
    }

+    SWSS_LOG_NOTICE("Removed mac=%s bv_id=0x%lx port:%s",


Please change to INFO

prsunny · 2020-12-29T18:49:44Z

orchagent/fdborch.cpp

+                {
+                    if (iter->fdbData.origin == origin)
+                    {
+                        SWSS_LOG_NOTICE("FDB entry found in saved fdb. deleting..."


Please change the NOTICE logs to INFO in the regular flow of FDB add/remove

updated as per latest review comments

anilkpan · 2020-12-29T21:25:29Z

Updated as per latest review comments.

…

On Tue, Dec 29, 2020 at 10:50 AM Prince Sunny ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In orchagent/portsorch.h <#1275 (comment)>: > @@ -169,7 +171,7 @@ class PortsOrch : public Orch, public Subject Port m_cpuPort; // TODO: Add Bridge/Vlan class sai_object_id_t m_default1QBridge; - sai_object_id_t m_defaultVlan; + sai_object_id_t m_defaultVlan; Please remove this extra space ------------------------------ In orchagent/portsorch.h <#1275 (comment)>: > @@ -198,6 +200,7 @@ class PortsOrch : public Orch, public Subject map<set<int>, tuple<string, uint32_t, int, string, int>> m_lanesAliasSpeedMap; map<string, Port> m_portList; unordered_map<sai_object_id_t, int> m_portOidToIndex; + Why this extra line? ------------------------------ In orchagent/portsorch.h <#1275 (comment)>: > @@ -9,6 +9,7 @@ #include "observer.h" #include "macaddress.h" #include "producertable.h" +#include "notificationproducer.h" Looks like not relevant in this PR. Please remove ------------------------------ In orchagent/portsorch.cpp <#1275 (comment)>: > m_portOidToIndex[id] = index; + m_port_ref_count[alias] = 0; Why this change? ------------------------------ In orchagent/fdborch.cpp <#1275 (comment)>: > { - SWSS_LOG_ERROR("FDB entry isn't found. mac=%s bv_id=0x%" PRIx64 ".", - entry.mac.to_string().c_str(), entry.bv_id); + /* When mac is moved from remote to local + * BGP will delete the mac from vxlan_fdb_table + * but we should not delete this mac here since now + * mac in orchagent represents locally learnt + */ + SWSS_LOG_NOTICE("FdbOrch RemoveFDBEntry: mac=%s fdb origin is different; found_origin:%d delete_origin:%d", Please change to INFO ------------------------------ In orchagent/fdborch.cpp <#1275 (comment)>: > entry.mac.to_string().c_str(), entry.bv_id); return true; //FIXME: it should be based on status. Some could be retried. some not } + SWSS_LOG_NOTICE("Removed mac=%s bv_id=0x%lx port:%s", Please change to INFO ------------------------------ In orchagent/fdborch.cpp <#1275 (comment)>: > { - observer->update(SUBJECT_TYPE_FDB_CHANGE, &update); + if (portName.empty() || (portName == itr.first)) + { + auto iter = saved_fdb_entries[itr.first].begin(); + while(iter != saved_fdb_entries[itr.first].end()) + { + if (*iter == entry) + { + if (iter->fdbData.origin == origin) + { + SWSS_LOG_NOTICE("FDB entry found in saved fdb. deleting..." Please change the NOTICE logs to INFO in the regular flow of FDB add/remove — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1275 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APJR3CQEAHYXDYSEDSCWHU3SXIQGXANCNFSM4MTGETBQ> .

-- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.

lgtm-com · 2020-12-29T22:15:32Z

This pull request fixes 1 alert when merging 3ceb819 into e32b9d0 - view on LGTM.com

fixed alerts:

1 for FIXME comment

prsunny · 2020-12-29T22:18:10Z

orchagent/portsorch.cpp

@@ -1882,7 +1881,6 @@ bool PortsOrch::initPort(const string &alias, const int index, const set<int> &l

                /* Add port to port list */
                m_portList[alias] = p;
-                m_port_ref_count[alias] = 0;


i think you accidently remove this line. Can you put it back?

this line was somehow showing as a new addition as seen in your pervious comment. I just re-added this line.

lgtm-com · 2020-12-29T23:23:39Z

This pull request fixes 1 alert when merging df6b9e7 into e32b9d0 - view on LGTM.com

fixed alerts:

1 for FIXME comment

prsunny · 2020-12-30T17:22:17Z

retest this please

prsunny · 2020-12-30T22:35:30Z

retest this please

prsunny · 2020-12-31T05:26:16Z

retest this please

lgtm-com · 2020-12-31T20:39:26Z

This pull request fixes 1 alert when merging 798d5fe into 7ba4e43 - view on LGTM.com

fixed alerts:

1 for FIXME comment

prsunny · 2021-01-04T17:21:11Z

retest this please

prsunny · 2021-01-08T00:46:01Z

retest this please

liushilongbuaa · 2021-01-08T03:18:16Z

retest vs please

* [Orchagent]: FdbOrch changes for EVPN VXLAN * Support for EVPN advertised mac routes

…ic-net#1275) * [config/console][consutil] Support enable/disable console switch * Changed the key to aligned with feature table style Signed-off-by: Jing Kan [email protected]

gord1306 reviewed May 19, 2020

View reviewed changes

gord1306 reviewed May 21, 2020

View reviewed changes

jainp1979 force-pushed the evpn_fdb_orchagent branch from 102b8ca to f9050e2 Compare June 23, 2020 17:29

jainp1979 marked this pull request as ready for review June 24, 2020 08:44

jainp1979 added 3 commits September 27, 2020 10:24

[Orchagent]: FdbOrch changes for EVPN VXLAN

6d3d2b5

Signed-off-by: Pankaj Jain <[email protected]>

This commit contains:

84642fc

1. Review comments incorporated 2. Dependency for PR sonic-net#885 is resolved 3. Added test_evpn_fdb.py pytest script to verify EVPN-VXLAN-FDB 4. compiled and verified the FDB functionality with EVPN 5. Changes to handle the static mac and aging from CLI

Fixed LGTM Warnings

4d9bd0a

jainp1979 force-pushed the evpn_fdb_orchagent branch from a18d035 to 4d9bd0a Compare September 27, 2020 18:19

vasant17 reviewed Oct 8, 2020

View reviewed changes

srj102 mentioned this pull request Oct 23, 2020

[Orchagent] Vxlanorch and Portsorch changes for EVPN VXLAN #1264

Merged

jainp1979 added 3 commits October 28, 2020 11:29

[Orchagent]: FdbOrch changes for EVPN VXLAN

187388e

Review comments incorporated.

[Orchagent]: FdbOrch changes for EVPN VXLAN

fb85618

removed commented code.

Merge branch 'master' into evpn_fdb_orchagent

304234e

prsunny requested changes Nov 13, 2020

View reviewed changes

gord1306 reviewed Nov 25, 2020

View reviewed changes

Str1ker17 mentioned this pull request Dec 7, 2020

Flush ARP/neighbor entry on FDB flush when port L2-L3 #1506

Merged

Str1ker17 suggested changes Dec 7, 2020

View reviewed changes

reverted vlanmgr changes

073da4a

srj102 reviewed Dec 24, 2020

View reviewed changes

Update fdborch.cpp

f17b20e

prsunny reviewed Dec 29, 2020

View reviewed changes

updated as per latest review comments

3ceb819

updated as per latest review comments

prsunny reviewed Dec 29, 2020

View reviewed changes

anilkpandey added 2 commits December 29, 2020 14:27

Merge remote-tracking branch 'upstream/master' into evpn_fdb_orchagent

9021773

Update portsorch.cpp

df6b9e7

prsunny previously approved these changes Dec 31, 2020

View reviewed changes

anilkpandey added 2 commits December 31, 2020 11:53

Merge remote-tracking branch 'upstream/master' into evpn_fdb_orchagent

1665c71

fix vs test

798d5fe

anilkpandey dismissed prsunny’s stale review via 798d5fe December 31, 2020 19:54

prsunny approved these changes Jan 8, 2021

View reviewed changes

prsunny merged commit a960e2e into sonic-net:master Jan 8, 2021

lguohan mentioned this pull request Jan 11, 2021

[build]: fix armhf build issue #1591

Closed

prsunny mentioned this pull request Jan 11, 2021

[Fdborch] Fix for arm compilation #1592

Merged

DavidZagury pushed a commit to DavidZagury/sonic-swss that referenced this pull request Mar 4, 2021

[Orchagent]: FdbOrch changes for EVPN VXLAN (sonic-net#1275)

76de991

* [Orchagent]: FdbOrch changes for EVPN VXLAN * Support for EVPN advertised mac routes

wendani mentioned this pull request Jul 20, 2021

[fdb & vstest/mirror] Populate FdbEntry port_name in APPL_DB SET path #1827

Open


		case SAI_FDB_EVENT_FLUSHED:
		if (!m_portsOrch->getPortByBridgePortId(bridge_port_id, update.port))

		@@ -3709,8 +3831,10 @@ bool PortsOrch::removeLag(Port lag)
		return false;
		}

		@@ -3411,13 +3475,14 @@ bool PortsOrch::removeBridgePort(Port &port)
		SWSS_LOG_INFO("Flush FDB entries for port %s", port.m_alias.c_str());

[Orchagent]: FdbOrch changes for EVPN VXLAN #1275

[Orchagent]: FdbOrch changes for EVPN VXLAN #1275

Conversation

jainp1979 commented Apr 28, 2020 • edited Loading

msftclas commented Apr 28, 2020 • edited Loading

lgtm-com bot commented Apr 28, 2020

jainp1979 commented Apr 29, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gord1306 May 21, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vasant17 Oct 8, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jainp1979 Oct 15, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vasant17 Oct 8, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lgtm-com bot commented Dec 24, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

srj102 Dec 24, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lgtm-com bot commented Dec 28, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

anilkpan commented Dec 29, 2020 via email

lgtm-com bot commented Dec 29, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lgtm-com bot commented Dec 29, 2020

prsunny commented Dec 30, 2020

prsunny commented Dec 30, 2020

prsunny commented Dec 31, 2020

lgtm-com bot commented Dec 31, 2020

prsunny commented Jan 4, 2021

jainp1979 commented Apr 28, 2020 •

edited

Loading

msftclas commented Apr 28, 2020 •

edited

Loading

jainp1979 commented Apr 29, 2020 •

edited

Loading

gord1306 May 21, 2020 •

edited

Loading

vasant17 Oct 8, 2020 •

edited

Loading

jainp1979 Oct 15, 2020 •

edited

Loading

vasant17 Oct 8, 2020 •

edited

Loading

srj102 Dec 24, 2020 •

edited

Loading