[FDBSYNCD] Added support for FDBSYNCD for EVPN as described in the PR Azure/SONiC#437#1276
Conversation
|
need vs test to cover this feature. |
fdbsyncd/fdbsync.cpp
Outdated
|
|
||
| FdbSync::FdbSync(RedisPipeline *pipelineAppDB, DBConnector *stateDb) : | ||
| m_fdbTable(pipelineAppDB, APP_VXLAN_FDB_TABLE_NAME), | ||
| m_imetTable(pipelineAppDB, APP_EVPN_REMOTE_VNI_TABLE_NAME), |
There was a problem hiding this comment.
According to sonic-swss-common PR339, should this constant be renamed to APP_VXLAN_REMOTE_VNI_TABLE_NAME
There was a problem hiding this comment.
Thanks for review. Updated the same
fdbsyncd/fdbsync.cpp
Outdated
| if (m_AppRestartAssist) | ||
| { | ||
| m_AppRestartAssist->registerAppTable(APP_VXLAN_FDB_TABLE_NAME, &m_fdbTable); | ||
| m_AppRestartAssist->registerAppTable(APP_EVPN_REMOTE_VNI_TABLE_NAME, &m_imetTable); |
There was a problem hiding this comment.
According to sonic-swss-common PR339, should this constant be renamed to APP_VXLAN_REMOTE_VNI_TABLE_NAME
There was a problem hiding this comment.
Thanks for review. Updated the same
fdbsyncd/fdbsync.cpp
Outdated
| // If warmstart is in progress, we take all netlink changes into the cache map | ||
| if (m_AppRestartAssist->isWarmStartInProgress()) | ||
| { | ||
| m_AppRestartAssist->insertToMap(APP_EVPN_REMOTE_VNI_TABLE_NAME, key, fvVector, false); |
There was a problem hiding this comment.
According to sonic-swss-common PR339, should this constant be renamed to APP_VXLAN_REMOTE_VNI_TABLE_NAME
There was a problem hiding this comment.
Thanks for review. Updated the same
fdbsyncd/fdbsync.cpp
Outdated
| // If warmstart is in progress, we take all netlink changes into the cache map | ||
| if (m_AppRestartAssist->isWarmStartInProgress()) | ||
| { | ||
| m_AppRestartAssist->insertToMap(APP_EVPN_REMOTE_VNI_TABLE_NAME, key, fvVector, true); |
There was a problem hiding this comment.
According to sonic-swss-common PR339, should this constant be renamed to APP_VXLAN_REMOTE_VNI_TABLE_NAME
There was a problem hiding this comment.
Thanks for review. Updated the same
| fdbmac.erase(key); | ||
| } | ||
|
|
||
| if (fdb_type == FDB_TYPE_DYNAMIC) |
There was a problem hiding this comment.
There is a question about the bridge fdb command, whether the remote MAC need to have extern_learn field
There was a problem hiding this comment.
Thanks for review, Yes extern_learn flag need to be set but currently exec command doesn't has extern_learn support, Hence it is not set.
This API is delete from common library, so delete the call as well
Address the review comments
Updated based on review comments
Updated based on the comment
comment from Qi.
78717d2 to
877ec26
Compare
kishorekunal01
left a comment
There was a problem hiding this comment.
All review comment address. WIll raise 2 more PR for the sonic-buildimage to start fdbsyncd process, and adding a table for warm reboot store in swss-common
fdbsyncd/fdbsync.cpp
Outdated
|
|
||
| if (info->op_type == FDB_OPER_ADD) | ||
| { | ||
| macAddSrcDB(info); |
There was a problem hiding this comment.
We can't move this to caller since we use the DB data to send del to the kernel and we want to keep add/del from DB at one place.
| } | ||
| else | ||
| { | ||
| /* If this is for vnet bridge vxlan interface, then return */ |
There was a problem hiding this comment.
@prsunny If the interface is Vxlan and is Vnet interface then return from here. Am I missing something
| return; | ||
| } | ||
| SWSS_LOG_INFO("Op:%d VxLAN dev %s index:%d vni:%d", nlmsg_type, ifname? ifname: nil, ifindex, vni); | ||
| if (nlmsg_type == RTM_NEWLINK) |
There was a problem hiding this comment.
We are only creating interface for vxlan interface so that we can extract VNI information for MAC installation, When interface is delete, each MAC del will be received in the kernel. Hence we don't need to handle interface delete here.
|
retest this please |
…NiC#437 (sonic-net#1276) * [FPMSYNCD] EVPN Type5 prefix handling in FPMSYNCD. This Change set is to support EVPN MAC/IMET routes from Kernel to DB and DB to Kernel: New demon is added to sync MAC from Kernel to DB and vise versa. Add remote IMET route learned via EVPN to EVPN_REMOTE_VNI_TABLE in APP_DB. Add remote MAC route learned via EVPN to VXLAN_FDB_TABLE. Add State DB FDB_TABLE for local learned MAC to Kernel Signed-off-by: Kishore Kunal [email protected] Signed-off-by: Arvindsrinivasan Lakshmi Narasimhan <[email protected]>
…onic-net#1276) **- What I did** Fix that it cannot add loopback interface by CLI, like the following: ``` root@as7816-64x:~# config loopback add Loopback1 Usage: config [OPTIONS] COMMAND [ARGS]... Try "config --help" for help. Error: No such command "L". ``` **- How I did it** Remove `@config.group()` before the function `is_loopback_name_valid(loopback_name)`, which will be called by add/del command Signed-off-by: MuLin <[email protected]>
…NiC#437 (sonic-net#1276) * [FPMSYNCD] EVPN Type5 prefix handling in FPMSYNCD. This Change set is to support EVPN MAC/IMET routes from Kernel to DB and DB to Kernel: New demon is added to sync MAC from Kernel to DB and vise versa. Add remote IMET route learned via EVPN to EVPN_REMOTE_VNI_TABLE in APP_DB. Add remote MAC route learned via EVPN to VXLAN_FDB_TABLE. Add State DB FDB_TABLE for local learned MAC to Kernel Signed-off-by: Kishore Kunal [email protected]
[FDBSYNCD] Added support for FDBSYNCD for EVPN as described in the PR sonic-net/SONiC#437
This Change set is to support EVPN MAC/IMET routes from Kernel to DB and DB to Kernel.
What I did
Why I did it
Part of overall EVPN-VXLAN Implementation
How I verified it
Not yet compiled or verified
Details if related
HLD Location : https://github.com/Azure/SONiC/pull/437/commits
Signed-off-by: Kishore Kunal [email protected]