Mac for kernel static neigh programmed for voq neighs in VOQ chassis with port type inband interface in VS platforms #1724
Conversation
Signed-off-by: vedganes <vedavinayagam.ganesan@nokia.com>
This patch is to make VOQ chassis with port type inband interface work
in VS platform based setups such as setups with KVMs
Currently with port type inband interface, kernel static neighbors for voq
neighbors are programmed with mac = local asic's mac. Because of this,
packets generated by host destined to voq neighbors will have both src and
dst mac same. This is fine for forwarding by hardwareiwhere recycle port is
used for inband interface. However, for VS platforms, since src mac = dst
mac, host's ip stack drops the packet. To fix this problem, for VS
platforms, if the inband interface is port type, staic neibhbors for voq
neighbors are programmed with mac = neighbors's owner asic's mac. With
this change, since src mac and dst mac are different and since we also
programm neighbor for all the remote asics, the packet will be sent out
correctly.
NOTE:
Since in local asic, the remote neigh's owner asic mac is not available
it is derived from the switch id and lower 5 bytes of local asic mac.
Therefore, to have VOQ chassis with port type inband interface work in VS
platforms, it is required that asic macs are programmed in the following
format:
<higher 5 bytes same for all asics>:<6th byte = switch id of the asic>
|
@abdosi - could you please take a look, thanks. |
|
@abdosi - could you please review |
|
Hi @ysmanman- could you please review and approve, thanks. |
1 similar comment
|
Hi @ysmanman- could you please review and approve, thanks. |
|
if the issue is w.r.t to VS can this change be done in SAI VS Layer ? |
We need to program the owner asic's MAC (for the remote neighbor) in the kernel records not in the SAI/hardware. Also the SAI/hardware record requires the neighbor's own MAC for all platfroms. There is no change in the record sent to SAI. |
If it is kernel record only why it is VS specific then ? |
For VS platforms for CPU originated packets destined to remote neighbors, the dst mac resolution happens in software. If we do not have this fix, i.e, if we program the kenel neighbors with local asic's mac, the src and dst mac will be same and packet will not be sent out. |
[flex-counters] Delay flex counters stats init for faster boot time (sonic-net/sonic-swss#1803) [mirror] Detach session dst ip from route orch LPM calculation regardless of session status at session CONFIG DB removal (sonic-net/sonic-swss#1800) [Dynamic Buffer Calc] Support dynamic buffer calculation on top of port auto negotiation (sonic-net/sonic-swss#1762) [neighorch] VOQ encap index change handling (sonic-net/sonic-swss#1729) [neighorch] Mac for voq neighbors in VS platforms (sonic-net/sonic-swss#1724) [acl mirror action] Mirror session ref count fix at acl rule attachment (sonic-net/sonic-swss#1761)
[flex-counters] Delay flex counters stats init for faster boot time (sonic-net/sonic-swss#1803) [mirror] Detach session dst ip from route orch LPM calculation regardless of session status at session CONFIG DB removal (sonic-net/sonic-swss#1800) [Dynamic Buffer Calc] Support dynamic buffer calculation on top of port auto negotiation (sonic-net/sonic-swss#1762) [neighorch] VOQ encap index change handling (sonic-net/sonic-swss#1729) [neighorch] Mac for voq neighbors in VS platforms (sonic-net/sonic-swss#1724) [acl mirror action] Mirror session ref count fix at acl rule attachment (sonic-net/sonic-swss#1761)
[flex-counters] Delay flex counters stats init for faster boot time (sonic-net/sonic-swss#1803) [mirror] Detach session dst ip from route orch LPM calculation regardless of session status at session CONFIG DB removal (sonic-net/sonic-swss#1800) [Dynamic Buffer Calc] Support dynamic buffer calculation on top of port auto negotiation (sonic-net/sonic-swss#1762) [neighorch] VOQ encap index change handling (sonic-net/sonic-swss#1729) [neighorch] Mac for voq neighbors in VS platforms (sonic-net/sonic-swss#1724) [acl mirror action] Mirror session ref count fix at acl rule attachment (sonic-net/sonic-swss#1761)
… patch (sonic-net#1724) Signed-off-by: Jing Kan jika@microsoft.com
What I did
This patch is to make VOQ chassis with port type inband interface work
in VS platform based setups such as setups with KVMs
Currently with port type inband interface, kernel static neighbors for voq
neighbors are programmed with mac = local asic's mac. Because of this,
packets generated by host destined to voq neighbors will have both src and
dst mac same. This is fine for forwarding by hardware where recycle port is
used for inband interface. However, for VS platforms, since src mac = dst
mac, host's ip stack drops the packet. To fix this problem, for VS
platforms, if the inband interface is port type, staic neibhbors for voq
neighbors are programmed with mac = neighbors's owner asic's mac. With
this change, since src mac and dst mac are different and since we also
program neighbors for all the remote asics, the packet will be sent out
correctly.
NOTE:
Since in local asic, the remote neigh's owner asic mac is not available
it is derived from the switch id and lower 5 bytes of local asic mac.
Therefore, to have VOQ chassis with port type inband interface work in VS
platforms, it is required that asic macs are programmed in the following
format:
<higher 5 bytes same for all asics>:<6th byte = switch id of the asic>
Why I did it
To fix problem related to packet forwarding by linux ip stack for the packets generated by host destined to remote voq neighbors via port type inband interfaces in VOQ chassis systems in KVM based testbed using VS platforms. i.e., this patch is to fix the issue sonic-net/sonic-buildimage#7434
How I verified it
Executed the T2 topology test scripts made for testing VOQ chassis in KVM based test setups and verified that iBGP connections among inband interfaces of all the asics are established successfully.