SONiC IGMP Snooping HLD #426
Conversation
|
|
ashok-krishnegowda
changed the title
…MP Snooping feature in SONiC
ashok-krishnegowda
force-pushed
the
igmp-snooping
branch
from
73fbb8c to
448174c
Compare
| 5. Support static and dynamic multicast router list. | ||
| 6. Aging of dynamic mrouter ports will be supported. Static mrouter ports will not timed out, they have to be un-configured explicitly. | ||
| 7. Support static multicast group configuration. Static l2mc entries will not timed out, they have to be un-configured explicitly. | ||
| 8. Support trapping IGMP and PIM Hello control packets to CPU. |
There was a problem hiding this comment.
is this typo wrt hello packets? why do we need PIM hello packets for IGMP snooping?
There was a problem hiding this comment.
When device running with IGMP Snooping, it maintains the router ports based on the received PIM hello messages that PIM routers send.
| IGMP control packets flooding happens in kernel, kernel flooding behaviour is per bridge, there is no per VLAN flooding control in Kernel. Until the dynamic multicast-router(mrouter) port learns in the VLAN, IGMP reports will be flooded to all members of the VLAN. | ||
| In presence of multicast-router, IGMP reports received on a host interface are forwarded to multicast-router interfaces alone, but not to the other host interfaces in the VLAN. | ||
|
|
||
| ### 1.2.4 SAI Overview |
There was a problem hiding this comment.
Could you please provide more details on how the SAI apis are going to be invoked? Does the sync layer maintain seperate database of L2MC entries and their port member lists? How does it going to differentiate new L2MC entry creation versus adding a port member to existing group? It would be good to put an example how the sync layer interacts with SAI layer wrt programming of the entries?
There was a problem hiding this comment.
Yes, L2mcorch in Orchagent maitains database of L2MC entries and their port member information. L2MC (Source,Group,Vlan) entry will be created in L2mcorch when it recieves first member addition, subsequent member add will bring in source group and the vlan information, based on that update to an already existing entry will be decided. L2mcorch will call sairedis API's to program L2mc entry, L2mc group and L2mc group members.
Example:
APP_L2MC_MEMBER_TABLE:Vlan10:0.0.0.0:225.0.0.1:Port1
L2mcorch processes and creates db entry when L2MC entry add comes to APPDB for the first time on the port1, key for db lookup here will be Source, Group and the Vlan.
L2mcorch will call sairedis API to create L2MC group first, then it calls API to create L2MC entry in the hardware and later L2MC group member add API will be called to update new port list.
When there is new receiver joins on Port1 on the same Vlan10 as mentioned below, lookup will find an already existing L2MC entry, this will update new port2 to the mc_id by calling sairedis API to add new group member.
APP_L2MC_MEMBER_TABLE:Vlan10:0.0.0.0:225.0.0.1:Port2
I will put these details.
|
|
||
|
|
||
|  | ||
|
|
There was a problem hiding this comment.
Diagrams are not accessible.. can you please check?
There was a problem hiding this comment.
I will check and update.
| key = APP_L2MC_VLAN_TABLE:"Vlan"vlanid | ||
| ;field = value | ||
|
|
||
| #### APP_L2MC_MEMBER_TABLE |
There was a problem hiding this comment.
Lets say for a given group 225.0.0.1, if there are two interested ports port 1(VLAN 10) and port 2(VLAN20), are we going to maintain two entries in the table? If this is the case, how are we going to check manage the SAI interactions where i guess we need to create mc_id for all the outgoing ports? does sync layer going maintain some data structure for entry and port list?
There was a problem hiding this comment.
As snooping works on Vlan, for the given scenario we will have db entry for both the Vlans like below,
APP_L2MC_MEMBER_TABLE:Vlan10:0.0.0.0:225.0.0.1:Port1
APP_L2MC_MEMBER_TABLE:Vlan20:0.0.0.0:225.0.0.1:Port2
Orchagent maintains data structure which holds (S, G, Vlan) entry and the interested ports for the multicast group on that Vlan.
For each entry there will be mc_id associated, this mc_id will be updated with port when there is IGMP join/leave for multicast group.
| ;field = value | ||
| type = "static"/"dynamic" ; Static or Dynamic mrouter entry | ||
|
|
||
| ### 3.2.4 ASIC DB |
There was a problem hiding this comment.
No details here? We dont maintain anything ASIC db?
There was a problem hiding this comment.
We have defined APP_DB schema, L2mcorch in Orchagent processes snooping table updates from the APP_DB and calls the sairedis APIs to put these routes in ASIC_DB.
| No changes | ||
|
|
||
| ## 3.3 Switch State Service Design | ||
| ### 3.3.1 L2mcOrch changes |
There was a problem hiding this comment.
Does this layer maintain infomation if this a new group entry or existing entry?
yxieca
force-pushed
the
master
branch
2 times, most recently
from
8498931 to
8837dc2
Compare
This document describes the functionality and high level design of IGMP Snooping feature in SONiC