Is it possible to get a traffic from a multicast address with specific destination port using IGMP? For example, I have some multicast flows like 239.192.7.1:5000, 239.192.7.1:5001 to 239.192.7.1:5009. Is there any way that I can request only the traffic from a specific port - for example only from 239.192.7.1:5000 ?
-
1What platform and software? You should be able to use IGMP access-group or equivalent.– Daniel DibFeb 5, 2014 at 5:10
-
IGMP works at the IP layer. Ports work at the transport protocol layer (i.e. UDP, DCCP...). What did you expect ?– BatchyXFeb 6, 2014 at 9:37
-
Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.– Ron Maupin ♦Aug 8, 2017 at 15:55
1 Answer
Is it possible to get a traffic from a multicast address with specific destination port using IGMP?
Short Answer:
You have three decent choices:
- Ask some senders / listeners to change their group
- Deploy IGMPv3 with PIM-SSM
- Deny certain UDP ports with an extended ACL (example: the Catalyst 4500 calls this a Port ACL... since it requires manual intervention for each host, this is not very scalable, and switch port ACLs are only supported on certain switching platforms)
Details:
Strictly speaking, no an IGMPv2 or IGMPv3 listener cannot specify a port to listen for. Let's assume you have the following situation:
- Source at 172.16.1.50 sends to 239.192.7.1:5000
- Source at 172.16.1.51 sends to 239.192.7.1:5001
- Source at 172.16.1.59 sends to 239.192.7.1:5009
PIM SSM / IGMPv3 include the ability to EXCLUDE certain source IP addresses. This means an IGMPv3 listener can exclude one or more of the source IPs; for instance, a IGMPv3 listener can exclude listening for 172.16.1.59.
Speaking practically, this is a design problem. When someone allocated 239.192.7.1 for multicast (presumably using IGMPv2 and PIM-SPARSE or PIM-DENSE) in your network, they should not have given that same group address to multiple applications. The simplest way around this problem is to change the group for one application and continue using IGMPv2.
If you don't have someone coordinating multicast addresses, then consider this a good reason to start doing so. There are ways to control who sends what multicast between subnets (at least in Cisco IOS). As organizations expand their use of multicast, controlling who sends what is pretty important.