Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Multicasting through 2424M 1
- Thread starter g6udx
- Start date
-
1
- #2
Hello g6udx -
You do not need a router if:
1. The server and workstations are on the same subnet; or
2. The servers and workstations are capable of ARPing
for remote subnets. The ability to do this and the
configuration (of servers and workstations) required
to do this vary from OS to OS.
Regards,
Ralph
You do not need a router if:
1. The server and workstations are on the same subnet; or
2. The servers and workstations are capable of ARPing
for remote subnets. The ability to do this and the
configuration (of servers and workstations) required
to do this vary from OS to OS.
Regards,
Ralph
- Thread starter
- #3
Hi ralpheb
The server and workstations are all on the same sub-net. Yet I have no trouble when using a 2650 or 4108 yet the 2424M will not co-operate. Is it something to do with IGMP in the multi-cast and the fact 2424M is layer 2 only according to hp.com?
Regards
g6udx
The server and workstations are all on the same sub-net. Yet I have no trouble when using a 2650 or 4108 yet the 2424M will not co-operate. Is it something to do with IGMP in the multi-cast and the fact 2424M is layer 2 only according to hp.com?
Regards
g6udx
Hi g6udx -
I don't think it has anything to do with layer 2 vs layer 3 because the three devices you mentioned all switch (as opposed to route) IP Multicast packets.
Note that the 2650's throughput and backplane performance is about 2-3 times that of the 2424M, according to the data sheet, and the 4108 has a considerably faster backplane than the 2650. Perhaps it is a horsepower issue, although I am only guessing since I have such limited information.
Have you looked through the 2525M's event log and counters for diagnostic symptoms?
Regards,
Ralph
I don't think it has anything to do with layer 2 vs layer 3 because the three devices you mentioned all switch (as opposed to route) IP Multicast packets.
Note that the 2650's throughput and backplane performance is about 2-3 times that of the 2424M, according to the data sheet, and the 4108 has a considerably faster backplane than the 2650. Perhaps it is a horsepower issue, although I am only guessing since I have such limited information.
Have you looked through the 2525M's event log and counters for diagnostic symptoms?
Regards,
Ralph
- Thread starter
- #5
Hi ralpheb
Agreed the 2650 has much more grunt than a 2424M, however, Ghost (multicast) under the scenario above takes many many times longer with the 2424M. Sometime the application just falls over completely due to timeout issues.
Perhaps you can explain the mechanics of multicast in laymans terms so I can understand it better. All the stuff I've found in seems real heavy to understand.
No-one is as smart as they would like to be. But with a little help from these forums we can make some small progress.
Agreed the 2650 has much more grunt than a 2424M, however, Ghost (multicast) under the scenario above takes many many times longer with the 2424M. Sometime the application just falls over completely due to timeout issues.
Perhaps you can explain the mechanics of multicast in laymans terms so I can understand it better. All the stuff I've found in seems real heavy to understand.
No-one is as smart as they would like to be. But with a little help from these forums we can make some small progress.
- Thread starter
- #7
Hi g6udx -
'IP Multicast' sounds like layer 3, which usually means routing. IP Multicast packets aren't routed by software, however. IP Multicast packets are also MAC multicast, and so are generally switched (forwarded) at hardware speed by layer 2 (switches) or layer 3 (routers and routing switches) devices.
IP Multicast packets are the data packets used for applications such as streaming video. IGMP packets are the control packets that manage where the IP Multicast packets are forwarded.
Did that make sense? I hope I didn't use too much jargon.
Anyhow, that's IP Multicast in a nutshell.
You can find IP Multicast/IGMP introductory and intermediate reading, although in more depth than what I have written above, in these ProCurve Tech Notes:
So, back to your problem. I still recommend that you follow basic troubleshooting techniques, starting with a careful inspection of the Switch Event Log (look for anything other than "I" in the left-hand column), counters (look for drops or a 'suspicious' number of errors).
I hope that helps.
Regards,
Ralph
'IP Multicast' sounds like layer 3, which usually means routing. IP Multicast packets aren't routed by software, however. IP Multicast packets are also MAC multicast, and so are generally switched (forwarded) at hardware speed by layer 2 (switches) or layer 3 (routers and routing switches) devices.
IP Multicast packets are the data packets used for applications such as streaming video. IGMP packets are the control packets that manage where the IP Multicast packets are forwarded.
Did that make sense? I hope I didn't use too much jargon.
Anyhow, that's IP Multicast in a nutshell.
You can find IP Multicast/IGMP introductory and intermediate reading, although in more depth than what I have written above, in these ProCurve Tech Notes:
So, back to your problem. I still recommend that you follow basic troubleshooting techniques, starting with a careful inspection of the Switch Event Log (look for anything other than "I" in the left-hand column), counters (look for drops or a 'suspicious' number of errors).
I hope that helps.
Regards,
Ralph
Sorry to disagree Ralph
IP Multicasting is LAYER 3, however, a layer 2 device treats them as a broadcast. You do need a router for multicast if you want the switch to direct the IGMP to a specific port.
You can deal with Multicast in several ways.
I layer 2, you do IGMP Snooping, this is bad, which is probably why the 2424 is suffering. this is because the switch actually has to lift the layer 3 lid and see where the destination address is (DA). This takes CPU power, the faster the switch the better.
Sorry to say this Ralph, but Cisco have a brilliant way of dealing with it. CGMP.
go to the Cisco site and search for CGMP and you will understand completely, hopefully.
PIM is also another good search mode.
IP Multicasting is LAYER 3, however, a layer 2 device treats them as a broadcast. You do need a router for multicast if you want the switch to direct the IGMP to a specific port.
You can deal with Multicast in several ways.
I layer 2, you do IGMP Snooping, this is bad, which is probably why the 2424 is suffering. this is because the switch actually has to lift the layer 3 lid and see where the destination address is (DA). This takes CPU power, the faster the switch the better.
Sorry to say this Ralph, but Cisco have a brilliant way of dealing with it. CGMP.
go to the Cisco site and search for CGMP and you will understand completely, hopefully.
PIM is also another good search mode.
ProCurve Switches direct IP Multicast packets to specific ports based on snooping Joins and Leaves. These Switches do this (directing IP Multicast packets to specific ports) without routing.
In my opinion, g6udx's performance issue is unlikely to be due to the processing overhead of snooping.
ProCurve Switches do not have to "lift the Layer 3" lid of IP Multicast packets in order to make forwarding decisions for individual packets. It relies on the MAC multicast address to do this.
Regards,
Ralph
In my opinion, g6udx's performance issue is unlikely to be due to the processing overhead of snooping.
ProCurve Switches do not have to "lift the Layer 3" lid of IP Multicast packets in order to make forwarding decisions for individual packets. It relies on the MAC multicast address to do this.
Regards,
Ralph
Hi Ralph
Sorry to disagree, again
But exactly how does an l2 switch deal with an l3 protocol, which, without doubt a multicast packet is l3. It has an IP address, starts with 224.0.0.0 with reserved addressing, eg EIGRPO, RIPv2 etc
So, snooping means you need power, lots of it! Every packet needs to be snooped, that is, lift the lid, look at the MAC destination and deliver.
I love HP switches, but you have to agree CGMP is the answer.
Sorry to disagree, again
But exactly how does an l2 switch deal with an l3 protocol, which, without doubt a multicast packet is l3. It has an IP address, starts with 224.0.0.0 with reserved addressing, eg EIGRPO, RIPv2 etc
So, snooping means you need power, lots of it! Every packet needs to be snooped, that is, lift the lid, look at the MAC destination and deliver.
I love HP switches, but you have to agree CGMP is the answer.
Hello BAsh12 -
Do not apologize for disagreeing! I can tell that you are a curious and sceptical individual, which I respect!
First of all, we need to carefully distinguish between IGMP packets and IP Multicast packets. From reading your postings it is not clear to me whether you are making this distinction, although I will assume that you are since you seem familiar with the technology. So, please don't feel patronized if what I write here is already obvious to you. It is primarily for the benefit of the original poster.
ProCurve Switches snoop IGMP packets but do not snoop IP Multicast packets. The Tech Note at contains the comment, "The 4108gl ... looks at destination Ethernet addresses in order to recognize IP Multicast traffic..." While the Tech Note does not explicitly state that the 4108gl (and other ProCurve Switch models) need not and does not look at the Layer 3 information in order to make a forwarding/filtering decision, I can assure you that this is the case. In fact, it is precisely the carefully designed IP multicast adress - to - MAC multicast address mapping, the subject of this Tech Note, which allows Layer 2 devices to make forwarding/filtering decisions about THIS ONE TYPE of Layer 3 traffic, IP Multicast.
If you don't believe this, I can suggest an experiment that will conclusively prove my point.
Set up a ProCurve Switch and turn on IGMP. Generate IGMP Join for an IP Multicast group. Then generate a high level IP Multicast traffic corresponding to that Join. You will see that the Switch's IP Multicast forwarding performance is similar to the Switch's layer 2 switching performance, rather than the much degraded performance that one would expect if the Switch were processing each IP Multicast packet in software.
Regards,
Ralph
Do not apologize for disagreeing! I can tell that you are a curious and sceptical individual, which I respect!
First of all, we need to carefully distinguish between IGMP packets and IP Multicast packets. From reading your postings it is not clear to me whether you are making this distinction, although I will assume that you are since you seem familiar with the technology. So, please don't feel patronized if what I write here is already obvious to you. It is primarily for the benefit of the original poster.
ProCurve Switches snoop IGMP packets but do not snoop IP Multicast packets. The Tech Note at contains the comment, "The 4108gl ... looks at destination Ethernet addresses in order to recognize IP Multicast traffic..." While the Tech Note does not explicitly state that the 4108gl (and other ProCurve Switch models) need not and does not look at the Layer 3 information in order to make a forwarding/filtering decision, I can assure you that this is the case. In fact, it is precisely the carefully designed IP multicast adress - to - MAC multicast address mapping, the subject of this Tech Note, which allows Layer 2 devices to make forwarding/filtering decisions about THIS ONE TYPE of Layer 3 traffic, IP Multicast.
If you don't believe this, I can suggest an experiment that will conclusively prove my point.
Set up a ProCurve Switch and turn on IGMP. Generate IGMP Join for an IP Multicast group. Then generate a high level IP Multicast traffic corresponding to that Join. You will see that the Switch's IP Multicast forwarding performance is similar to the Switch's layer 2 switching performance, rather than the much degraded performance that one would expect if the Switch were processing each IP Multicast packet in software.
Regards,
Ralph
Hi Ralph
1. The client sends an IGMP join message to its designated multicast router. The destination MAC address maps to the Class D address of group being joined, rather being the MAC address of the router. The body of the IGMP datagram also includes the Class D group address.
2. The router logs the join message and uses PIM or another multicast routing protocol to add this segment to the multicast distribution tree.
3. IP multicast traffic transmitted from the server is now distributed via the designated router to the client's subnet. The destination MAC address corresponds to the Class D address of group
4. The switch receives the multicast packet and examines its forwarding table. If no entry exists for the MAC address, the packet will be flooded to all ports within the broadcast domain. If a entry does exist in the switch table, the packet will be forwarded only to the designated ports.
5. With IGMP V2, the client can cease group membership by sending an IGMP leave to the router. With IGMP V1, the client remains a member of the group until it fails to send a join message in response to a query from the router. Multicast routers also periodically send an IGMP query to the "all multicast hosts" group or to a specific multicast group on the subnet to determine which groups are still active within the subnet. Each host delays its response to a query by a small random period and will then respond only if no other host in the group has already reported. This mechanism prevents many hosts from congesting the network with simultaneous reports.
AND
VLANs can de defined to correspond to the boundaries of the multicast group. This is a simple approach, however, it doesn't support dynamic changes to group membership and adds to the administrative burden of unicast VLANs.
Layer 2 switches can snoop IGMP queries and reports to learn the port mappings of multicast group members. This allows the switch to dynamically track group membership. But snooping every multicast data and control packet consumes a lot of switch processing capacity and therefore can degrade forwarding performance and increase latency.
Taking advantage of the Generic Attribute Registration Protocol (IEEE 802.1p) will allow the end system to communicate directly with the switch to a join a 802.1p group corresponding to a multicast group. This shifts much of the responsibility for multicast group configuration from Layer 3 to Layer 2, which may be most appropriate in large flat switched networks.
The traditional role of the router as a control point in the network can be maintained by defining a multicast router-to-switch protocol, such as the Cisco Group Multicast Protocol (CGMP), that allows the router to configure the switch's multicast forwarding table to correspond to the current group membership.
Taken directly from Cisco's web page.
In other words, if the switch is snooping, large overhead.
Hope this clears up any missunderstanding.
1. The client sends an IGMP join message to its designated multicast router. The destination MAC address maps to the Class D address of group being joined, rather being the MAC address of the router. The body of the IGMP datagram also includes the Class D group address.
2. The router logs the join message and uses PIM or another multicast routing protocol to add this segment to the multicast distribution tree.
3. IP multicast traffic transmitted from the server is now distributed via the designated router to the client's subnet. The destination MAC address corresponds to the Class D address of group
4. The switch receives the multicast packet and examines its forwarding table. If no entry exists for the MAC address, the packet will be flooded to all ports within the broadcast domain. If a entry does exist in the switch table, the packet will be forwarded only to the designated ports.
5. With IGMP V2, the client can cease group membership by sending an IGMP leave to the router. With IGMP V1, the client remains a member of the group until it fails to send a join message in response to a query from the router. Multicast routers also periodically send an IGMP query to the "all multicast hosts" group or to a specific multicast group on the subnet to determine which groups are still active within the subnet. Each host delays its response to a query by a small random period and will then respond only if no other host in the group has already reported. This mechanism prevents many hosts from congesting the network with simultaneous reports.
AND
VLANs can de defined to correspond to the boundaries of the multicast group. This is a simple approach, however, it doesn't support dynamic changes to group membership and adds to the administrative burden of unicast VLANs.
Layer 2 switches can snoop IGMP queries and reports to learn the port mappings of multicast group members. This allows the switch to dynamically track group membership. But snooping every multicast data and control packet consumes a lot of switch processing capacity and therefore can degrade forwarding performance and increase latency.
Taking advantage of the Generic Attribute Registration Protocol (IEEE 802.1p) will allow the end system to communicate directly with the switch to a join a 802.1p group corresponding to a multicast group. This shifts much of the responsibility for multicast group configuration from Layer 3 to Layer 2, which may be most appropriate in large flat switched networks.
The traditional role of the router as a control point in the network can be maintained by defining a multicast router-to-switch protocol, such as the Cisco Group Multicast Protocol (CGMP), that allows the router to configure the switch's multicast forwarding table to correspond to the current group membership.
Taken directly from Cisco's web page.
In other words, if the switch is snooping, large overhead.
Hope this clears up any missunderstanding.
BAsh -
Apparently we will have to agree to disagree as to whether ProCurve switches snoop, in software, L3 information in IP Multicast packets, as opposed to IGMP packets which ProCurve switches *DO* snoop.
Anyone who truly needs to know the answer can run the experiment that I suggested earlier.
Regards,
Ralph
Apparently we will have to agree to disagree as to whether ProCurve switches snoop, in software, L3 information in IP Multicast packets, as opposed to IGMP packets which ProCurve switches *DO* snoop.
Anyone who truly needs to know the answer can run the experiment that I suggested earlier.
Regards,
Ralph
- Status
Similar threads
- Locked
- Question