SG108E Multicast Report Forwarding Errors

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

SG108E Multicast Report Forwarding Errors

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
SG108E Multicast Report Forwarding Errors
SG108E Multicast Report Forwarding Errors
2019-05-24 17:58:24
Model: TL-SG108E  
Hardware Version: V3
Firmware Version: 1.0.0 Build 20171214 Rel.70905

I am having a lot of trouble with multicast on these switches. After a lot of testing and analysis I've found that they do not appear to forward group reports at all, specifically not back through the query port. There is also some unexpected behavior with initial flooding and membership timeout. Here's what I've found:

 

I'll first describe the flooding and timeout behavior. This is 'ok' but I'd like confirmation that this is expected, it isn't mention in the documentation. This description is performed without a querier in the network. Let's say we have this configuration:

Host1 (send and join) - Switch1 - Switch2 - Host2 (join)

Without snooping enabled everything goes through, as expected. With snooping enabled, when Host1 joints a group (239.0.1.0) and the first report message is received you see that group and port show up in the membership table on Switch1, the switch immediately connected to the host. After a while you'll find that this entry in the membership table is removed, and this turns out to be 260 seconds, which I've found is a typical default timeout, if the switch never receives another group report. This isn't documented, but I can understand it. Here's where it gets odd. Let's say that Host2 joins the group, you will see its entry in the Switch2 table. Then, Host1 will both join the group and start sending on that group. For the first ~10 milliseconds the traffic will flood out and you'll see the packets on Host2. This is not expected. Since snooping is enabled I'd expect no traffic to go through at all. The entry for Switch1 (from Host1) is created, but it basically seems that even with snooping on it initially doesn't have anything in the table for that group and lets it flood, and then after a short time the table entry is created and it's filtered. It makes sense that it is filtered in this case, because it only knows that Host1 has joined the group, so it doesn't send the traffic onto Switch2/Host2. Then, once the membership timeout occurs (260s) on Switch1 the entry is removed from Switch1, and the traffic floods without a filter, and then it goes through Switch2 (without or without a matching entry in the list), and then onto Host2. So, you effectively see a quick burst, then nothing, and then you get all the traffic from the timeout period on. Since snooping is on, this behavior seems undesirable, but from a user standpoint and a simple switch, at least this allows for traffic to flow in a misconfigured network (so I can get it, it's ok).

 

We do want the usual snooping behavior, for efficient multicast traffic flow, and I was trying to figure out why we didn't get traffic or membership entries between the two switches. I understand that you need a querier in the network, and assumed that because I didn't have one in the test above, that's why the group reports were not forwarded outside the switches to each other, and that's why the traffic wasn't sent through (until the timeout and subsequent flooding). So, next I'll setup a querier on Host2:

Host1 (join) - Switch1 - Switch2 - Host2 (query)

When Host1 joins you see the intial group reports on Switch1, i.e. the entry is added to the membership table on Switch1, and the report is not delivered beyond that switch. When Host2 is setup to query (this is a linux machine with a bridge setup as a querier), you can see the query igmp messages on Host2, and on Host1, and you can see the group reports in response on Host1, and I can confirm those are hitting Switch1 (because the membership entry in the table is being kept alive, i.e. the entry is never cleared via the membership timeout, described above). However, these membership reports are never seen on Host2, and Switch2 never has an entry in the table from Host1/Switch1, so this implies that the group report is never forwarded back out of Switch1. My understanding is that they are supposed to be forwared back to the port where the query came in, but they are not. I've looked up and tried everything I know, and I can never get multicast traffic to flow through multiple switches when snooping is enabled and there is an entry in the table. The only thing that works is not having a querier and allowing the table to timeout, or simply turning off snooping, which is effectively equivalent, and then there are no gains from multicast. Can you help explain what is going on, and if there is specifically something else that is required? (I'll add that the querier is igmp v2, in case that matters. Without the querier the Hosts are using igmp v3, but all the behavior appears to be the same, with respect to these switches.) So, in the event that you have this configuration:

Host1 (join) - Switch1 - Switch2 - Host2 (query)

                                                   - Host3 (join)

                                                   - Host4 (send)

You will never see traffic on Host1 from Host4 because there is a table entry in Switch2 from Host3, so Switch2 is filtering, and Host4's traffic is never sent from Switch2 to Switch1/Host1, because Switch2 never learns that Switch1 is in the group. This is not good.

 

There is another detail that I find odd. I've noticed that reports for the multicast group 224.0.0.0-255 go through the entire network, all switches, in response to a query. Without a query, the intial reports are not fowarded (same as the other groups). This led me to think that perhaps my choice of group was an issue, but I found that of all the possible multicast address spaces, the only one that is forwarded is that one, 224.0.0.0-255. I was thinking that perhaps this was just the only group that would work correctly in this switch, however I found that this group is never added into the membership table at all (all the other addresses are, as expected), AND that any traffic in this group is always forwarded to all switches and ports, so nothing is actually filtered at all, with snooping on (as it should be). I know the 224.0.0.0-255 range is special and reserved, so this being a special case could be ok, but it's the only one that works with report forwarding, however it doesn't actually filter, so this isn't useful either.

 

I really need to figure this out and get the traffic to propogate as expected, so I'd very much appreciate any help. Thanks, Michael.

  0      
  0      
#1
Options
2 Reply
Re:SG108E Multicast Report Forwarding Errors
2019-05-28 02:00:07

Hi JamesMMatthews

 

You have done really much research. I just say something I know, maybe have some help.

1. The IGMP report/leave message will be only forwarded to route port. Route port is the port that receive the IGMP query message.

2. The IGMP query message will be forwarded to all ports.

3. When there is not multicast entry on the multicast table, the multicast data will flood to all ports. You also mentioned this point. When there are multicast entries, the multicast data will be forwarded according to the multicast table.

 

So in the following topology, Host1 can get the multicast data from switch2. Host1 will send the IGMP join, switch 1 will generate the multicast entry. Host2 send the IGMP query, switch1 will receive the query and generate the route port. Route port will be added to the multicast entry. Then the IGMP join from Host1 will be forwarded to the route port and switch2 will receive this IGMP join. So switch2 will generate the multicast entry and the multicast data can be forwarded to switch1.

Host1 (join) - Switch1 - Switch2 - Host2 (query)

                                                   - Host3 (join)

                                                   - Host4 (send)

  0  
  0  
#2
Options
Re:Re:SG108E Multicast Report Forwarding Errors
2019-05-28 13:38:35

Thanks for those points. I completely agree, and that's my understanding and expectation. Unfortunately, that is specifically what is not occuring.

  0  
  0  
#3
Options

Information

Helpful: 0

Views: 1046

Replies: 2