EVPN_VXLAN_HLD: update to allow recording for p2mp remote vteps #1897
Conversation
Complimentary ticket to sonic-net/sonic-swss#3480 in order to allow p2mp vteps to be tracked. This will mostly aid in debugging. The HLD specifically states this when talking about P2P vs P2MP: "For an external user, there will be no changes from usability perspective since the schema is unchanged." However this is not entirely true since the state table wasn't recording p2mp remote vteps and therefore `show vxlan remotevtep` would return no results making a user believe the vxlan tunnel was not properly established. This as well as the aforementioned PR corrects this oversight. Signed-off-by: Brad House (@bradh352)
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
@dgsudharsan mind reviewing this change? You seem to have been the one to contribute the P2MP vs P2P information. |
|
@bradh352 Unlike P2P scenario where we have individual tunnel objects, P2MP implies there is only one tunnel in the local device. Since there is only one tunnel object, state_db was intentionally not populated and mentioned so in the HLD as well |
Sure, but that's more of an internal design aspect, right? The HLD specifically states that there are no usability changes, but there is infact a difference ... even though the user has no knowledge of if the underlying implementation is p2p vs p2mp. You can't expect a user to know that when they log into their Dell S5248F switch they will see As far as I know, there's no way to simply show the remote vteps on P2MP without this patch (you can get it via vtysh obviously). What users see should be the same from silicon to silicon for common features. Are you completely against this change, or would you rather it done a different way? |
Complimentary ticket to sonic-net/sonic-swss#3480 in order to allow p2mp vteps to be tracked. This will mostly aid in debugging. The HLD specifically states this when talking about P2P vs P2MP:
"For an external user, there will be no changes from usability perspective since the schema is unchanged."
However this is not entirely true since the state table wasn't recording p2mp remote vteps and therefore
show vxlan remotevtepwould return no results making a user believe the vxlan tunnel was not properly established. This as well as the aforementioned PR corrects this oversight.Signed-off-by: Brad House (@bradh352)