[vxlan]add L2-vxlan [#376] #867
Conversation
[vxlanorch] * Adding the following logic: - When creating vxlan tunnel, create its bridge port. If VXLAN tunnel without bridge port, FDB MAC can not be learnt from or set to VXLAN tunnel in ASIC. - Add the tunnel name map to counter table, so that the ‘show mac’ command can display the FDB learnt from VXLAN tunnel. - Send command to Linux kernel to create L2 VXLAN tunnel interface. [fdborch] * FDB MAC can be learnt from or set to VXLAN tunnel in ASIC Signed-off-by: jianjun.dong <jianjun.dong@nephosinc.com>
| sai_fdb_entry_t fdb_entry; | ||
|
|
||
| fdb_entry.switch_id = gSwitchId; | ||
| memcpy(fdb_entry.mac_address, entry.mac.getMac(), sizeof(sai_mac_t)); | ||
| fdb_entry.bv_id = entry.bv_id; | ||
|
|
||
| Port port; | ||
| /* Retry until port is created */ | ||
| if (!m_portsOrch->getPort(port_name, port)) | ||
| sai_object_id_t bridge_port_id = SAI_NULL_OBJECT_ID; |
There was a problem hiding this comment.
The Sonic VxLAN HLD refers to a separate VXLAN_FDB_TABLE for MACs pointing to remote VTEP. addFdbEntry is to handle entry additions in APP_FDB_TABLE. The current code changes seem to indicate that the VxLAN MACs are populated in the APP_FDB_TABLE. Is there a change in the design ?
Either way It is better to handle VxLAN FDB entry add/remove in a different function to keep it clean instead of checking for port_name against VTT in multiple places.
There was a problem hiding this comment.
Yes, vxlan tunnel MAC is set in APP_FDB_TABLE currently. Packet forwarding is correctly in lab test.
In Sonic VxLAN HLD, I don't see any description about VXLAN_FDB_TABLE, only 'Add VxlanOrch as a member of FDBOrch. For FDB entries learnt on remote VTEP, app-fdb-table shall be updated and programmed to SAI by getting the BridgeIf/RemoteVTEP mapping from VxlanOrch. (TBD)'.
There was a problem hiding this comment.
https://github.com/Azure/SONiC/blob/master/doc/vxlan/Vxlan_hld.md#22-app-db
VXLAN_FDB_TABLE is defined here.
There was a problem hiding this comment.
Thanks. I think that VXLAN_FDB_TABLE is used for L3 vxlan scenario, such as EVPN, entries in the table are exchanged by MBGP. The modification here is only for L2 vxlan scenario, entries are learned by ASIC.
There was a problem hiding this comment.
The existing fdborch can't listen to VXLAN_FDB_TABLE. We can refine the code after fdbOrch support listening to vxlan_fdb_table event.
Signed-off-by: leo.li <leo.li@nephosinc.com>
Signed-off-by: shine.chen <shine.chen@nephosinc.com>
Signed-off-by: shine.chen <shine.chen@nephosinc.com>
|
retest this please |
- Fix Python warnings flagged by "LGTM" plugin. - Also make all 'except' statements Python3-compliant
What I did
Add L2 vxlan feature
Why I did it
Current vxlan implementation only support VNET scenario. We add vxlan support on L2 scenario.
How I verified it
Tested it in nephos lab
Details if related
[vxlanorch]
without bridge port, FDB MAC can not be learnt from or set to VXLAN
tunnel in ASIC.
command can display the FDB learnt from VXLAN tunnel.
[fdborch]