Not signed in (Sign In)

Categories




{ Etherwire is an open forum related to Industrial Ethernet }

Ethernet/IP: Multicast and Ethernet/IP

Bottom of Page

1 to 12 of 12

  1.  
    •  
      CommentAuthorAllen Lee
    • CommentTimeJan 7th 2010
     
    I heard the Rockwell Automation (Allen Bradley) PLC use multicasting when using Ethernet/IP. My IT guys didn't look too enthusiastic when I mentioned multicast (not sure what that really is but will research more on that). Is there any extra setup I would need to do or good setup pointers from the switch perspective?
  2.  
    An Ethernet packet has information within it which identifies it as a broadcast packet (goes to everyone), unicast packet (goes to one device), or Multicast packet (goes to devices that have joined the multicast group to which it is addressed). These groups are configured and managed by Internet Group Management Protocol, or IGMP. IGMP requires a querier, which is usually a Layer 3 device in the IT world. It queries the LAN to determine which group(s) a device would like to join. In the absence of a querier, multicast traffic behaves like broadcast traffic and goes to every device. Imagine yourself at a large gathering and having to listen to every conversation. It would make participating in the conversation you really want to be part of very difficult. So how do you implement IGMP snooping in your Industrial Ethernet Network? It will require a MANAGED switch with IGMP Snooping AND querying capability. With most Managed Industrial Ethernet switches you will need to configure the IGMP parameters of the switch, set up groups, indicate which groups each switch will be a part of etc. This is somewhat time consuming and tedious, and requires a good measure of network expertise. This also leaves the door open for the dreaded 2am network failure and the accompanying trip to the plant to reconfigure IGMP groups. There is also another alternative. Choose a switch with automatic IGMP snooping that allows plug and play IGMP configuration. I only know of one manufacturer that has this feature, and that's N-Tron. Full disclosure, I am a marketing analyst at N-Tron, and I know this forum is not for promotion of brands or products, however if I refrained from advising you of the existence of this product I'd be doing you a disservice. Having said that, if another manufacturer offered this feature I would certainly mention them as well, and invite anyone I've overlooked to add to the conversation. Here is an interesting white paper on IGMP snooping in a Rockwell Automation environment.

    http://www.n-tron.com/pdf/rockwellautomationappnotev8.pdf

    Good luck, and if you need further assistance I'd be happy to be of service.
    •  
      CommentAuthorDan Booth
    • CommentTimeJan 7th 2010
     
    Tony, will there be any adverse effect on the network if you enable IGMP (and there aren't any multicast traffic present)?
  4.  
    Dan,

    There will be the tiny amount of additional traffic generated by the switch doing the querying, but we are talking about such a tiny amount that it would make no difference. So the answer to your question is, in practice no, becuase this tiny bit of additional traffic will cause no adverse effect.
    •  
      CommentAuthorAfan
    • CommentTimeJan 8th 2010
     
    Tony Oberkirch's explanation is solid. However, there are other manufacturers out there with IGMP snooping out of the box as well. Rockwell and Phoenix Contact are two that I know of. That being said, my company standardizes on N-Tron and has had great success using them.
    •  
      CommentAuthorjtjohnson
    • CommentTimeJan 8th 2010
     
    @Tony
    I haven't heard of "automatic IGMP snooping" and "plug and play IGMP configuration" -- care to explain that further? Not to state the obvious, I take it that if it sees multicast packets, it will automatically switch on but what I am really asking is does it trigger on the first time is sees a multicast packet, or after a certain threshold level. Does it disable if it doesn't see multicast packets after a certain time? Can you switch the setting off?

    @Afan
    Most of the managed switches have IGMP snooping out of the box but "automatic IGMP snooping" I am not too sure. Does Rockwell-Cisco collaboration Stratix range have it too (I guess that is the switch you are referring to)? Didn't know Phoenix Contact makes switches, showing a little naivety on my part.

    I am wondering whether Cisco's IE3000 range as it is more or less the same switch Stratix is (without the logix functionality)
    •  
      CommentAuthormarbera
    • CommentTimeJan 10th 2010
     
    multicast traffic make unmanaged (e non igmp-enabled swith) to beahve like an old hub.
    this means that multicast traffic is like broadcast and can easily flood the network.
    managed mc traffic requieres two step
    1) a device (named querier) has to ask all others igmp enabled devicec "who is interested in this traffic"?
    2) each switch sees the questions (coming from the querier) and listens (igmp snooping) the answer coming from the connected devices.
    in this way, each switch takes notes on who is interested on a specific mc and send it only to the relevant ports

    all for saying, that supporting igmp snooping is not enough to avoid the issue
    same managed switch managed igmp snooping but not igmp querying.
    it's important to notice that in an industrial network, at least one querier must be present

    all the discussion, is relevant with ethernet/ip cause rockwell use multicast traffice to "optmize" the communication

    I haven't heard about "automatic igmp ", but I'll stay away of any automatic engine
    after all, igmp configuration is quite easy. and if you do by yourself, you will always know what is doing :-)
    Marco
  8.  
    @jtJohnson - I'm not going to go into the nuts and bolts of the automatic IGMP snooping, but it requires a layer 2 device to be a querier as well as have IGMP snooping enabled. And yes, you can configure the switch to turn off IGMP snooping if you really want to. I'm not trying to be uncooperative by not answering your question in detail, but it's kind of like the recipe for Coca Cola, and you know how tight lipped Coke is with that!! I'll say this: N-Tron's automatic IGMP snooping is 100% effective, adheres 100% to the IEEE standard, and has no adverse effects on network performance beyond what a switch that is configured manually would impose. If you have doubts, try one. I'll take it back if it doesn't work as i've described.

    It's true that several manufacturers have IGMP snooping enabled out of the box. And it's also true that a querier has to start querying to get the process going. Usually it's a layer 3 device that querys, but not always. Several manufacturers of layer 2 switches also have IGMP querying capability. Still, it takes a bit more than having both IGMP querying and snooping capability to make it all happen in a layer 2 switch automatically. And that's probably why Afan's company has standardized on N-Tron. Thanks Afan.

    I'm 99.9% sure that you won't find another switch with out of the box automatic IGMP snooping. To clairfy, what I'm referring to is this: take the switch out of the box, plug in the fiber and RJ45 connectors, apply power, and it works without further configuration. As of today, I'm sure Cisco's IE3000 and Rockwell's Stratix 8000 do not have this functionality.

    Marco: I wouldn't call N-Tron's Automatic IGMP Snooping an "automatic engine", it's more of a bit of intelligent software making plain IEEE Ethernet standards much more user friendly.

    IGMP configuration is easy? Easy is a VERY relative word. I'm sure Marco is very capabie and knowledgeable and has no trouble configuring IGMP, but can the same be said for the night shift maintenance crew in a typical plant? This is probably not the case in most plants. Is it easy to wake up at 2am and go configure a replacement switch after a forklift operator ran into a cabinet and destroyed switch that was previously configured? And is is easy to explain to the boss why the line was down for 6 hours instead of 2 or 3 hours at a cost of $100,000 per hour lost production? Those are the kind of questions asked in the Industrial Ethernet world that are not usually asked in the IT Ethernet world.
  9.  
    Good discussion.

    I am curious about the querier thing. I've used the N-Tron 500 series switches stacking them up to 3 levels deep which is the maximum allowed according to the N-Tron documentation. My question now is, "How does the N-Tron handle the querier functionality if there should only be one in the network?" Do the N-Tron switches auto negotiate this?

    Tony Oberkirch, thanks for your contributions. However, I must let you know about a difficulty we ran into using these switches. We found that if you change connections it can take quite some time before the switches figure out how to re-route the traffic... I'm thinking it could take something like 30 minutes.... The work around was to cycle power to the switches if we changed the patching and everything would work within a minute or so. Since we were in checkout we could do this, however cycling the power is not usually desirable. Are you aware of this "problem"? If so, any suggestions?
  10.  
    There is aso a discussion on LinkedIn in the "Automaton & Controls" group about this topic.
  11.  
    Harold: First, thanks for using N-Tron. To answer your questions, I consulted with Gordon Stevens, Technical support specialist here at N-Tron. Here are answers to your questions:

    Regarding querier functionality: N-Tron managed switches will dynamically negotiate down to one querier. In the event a query message with a lower source IP is received by the switch, it will suppress its own query function dynamically. In the event the lowest source IP query message is no longer seen on the LAN, the other switches will renegotiate a new querier.


    Regarding changing connections, it's related to the Address Resolution Logic table. An Ethernet switch routes unicast frames based on the Address Resolution Logic (ARL) table. The ARL table is basically a MAC address list associated with the switch port the device is seen through. If the physical path to devices is changed, the switch will continue to route these frames until one of the following occurs: 1) the ARL entry is updated due to the switch seeing frames from the device that is now seen via a new path. 2) the ARL entry has aged out of the dynamic table. Typically N-Tron switches with two or more FX ports default to 20 second ARL aging time. Otherwise, the aging time is defaulted to 300 seconds. The aging times are configurable on N-Tron managed switches, including the 500-A series switches you have (assuming that they have the -A option) . With that being said, the longest time the switch should take would be 5-10 minutes. The 10 minutes comes from 2X the aging time as a maximum and is based on timing of the last frame with the source MAC seen by the switch. Could the time frame have been 10 minutes or are you sure about the 30 minutes time frame you mentioned above? I know 10 minutes can seem like forever when the network is down.

    Cycling the power of the switch will flush the table and force it to relearn the new path. This of course is not a desirable solution as you indicated. You may want to look into adjusting the aging time to better suit your needs. Or use switches that fully support Rapid Spanning Tree Protocol (RSTP) or a propriatiary ring protocol. When RSTP is fully supported by the switch fabric, each switch will respond to physical path changes such as broken cable segments or power outages at a particular switch location based on the RSTP protocol/scheme. With a propriatiary ring protocol millisecond heal times are possible.

    If changing the aging time on the ARL table is not an option or does not resolve the problem call me or Gordon at 251-342-2164 and we'll investigate further and find an answer for you.
  12.  
    Great answer Tony. The querier auto negotiation thing is way cool! Actually having a true plug and play switch out of the box for Ethernet/IP is way cool. It's nice to finally know how it's done.

    As for the 10 minute max delay in switching ports. I'm not really sure about the time. However there might be some time added by the Allen Bradley RSLinx software reestablishing the connection between the I/O and the PLC as well that adds additional minutes to the time. I mainly remember changing the connections and wondering why it wasn't working within a few minutes. While we were trying to figure it out and doing other things suddenly.... "hey, it's working!".... and we moved on... That happened a couple of times before we figured out the cycling power trick.

    You fully addressed my concerns. Thanks so much.

1 to 12 of 12

  1.  
Add your comments
    Username Password
  • Format comments as
 
Back to Discussions Top of Page
Site usage is subject to the Forum Terms and the Privacy Policy. This forum is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.
© 2010 Etherwire c/o Kazio Networks, 5 South Centre Ave. Suite 101, PO Box 194, Leesport, Pennsylvania 19533 | 484.334.2757