UDP Broadcast traffic?

This is IPv4 multicast traffic. It is NOT IP broadcast traffic.

Do you have ip multicast routing enabled ?

Do you have PIM configured?

Merv, Thanks for the reply. I do not have ip multicast routing enabled, but to make sure I ran the command 'no ip multicast-routing'. No change. I am still getting the same high level of UDP traffic from the other subnet. Can you tell me what I'm missing?

Thanks, Joe

Do you have devices on BOTH subnets that are generating this multicast traffic ??

How do you know that this multicast traffic is passing thru the router ?

TW UDP port 2222 is an unregistered Allen-Bradley UDP port.

Do you have PLC controllers connected to this network ?

Merv,

I guess you noticed: Ethernet II, Src: Allen-Br_2b:0d:9a ?

Also note Time to live: 1

I agree that there seems a decent chance that the traffic is not actually passing thru' the router.

Merv, Answers to your questions:

Negative. The only multicast traffic that Ethereal is picking up is coming from a single device behind the router.

Because the source address (per Ethereal) is from a known IP address behind the router.

Correct. The traffic is coming from an IP address assigned to an Allen-Bradley PLC. The production engineers are using the multicast traffic for diagnostics between some PLCs. I want to block it from coming through the router on to the rest of the network.

Hope these answers help.

Thanks, Joe

I'm confused.

The source address of the traffic is 192.168.11.10 (on one side of the router.)

The protocol analyzer is sitting on 172.24.16.37 (on the other side of the router.)

How is it possible that the traffic is not passing through the router? Am I missing something?

Joe

Given the above, teh multicast traffic should not be forwarded by the router and it sure sounds like it is.

You should be able to block it with an access-list something like

config t no ip access-list extended BLOCK-239.192.2.65 ip access-list extended BLOCK-239.192.2.65 deny udp host 192.168.11.10 host 239.192.2.65 eq 2222 permit ip any any end

config t int ip access-group BLOCK-239.192.2.65 in end

Well, you seem to have it all sorted out,

Follow Merv's advice and use an access-list to block this specific traffic.

Report back.

Good luck - you may need it.

Merv, No luck. Ran the commands you recommended, saved the running-config to the startup-config, and restarted the router. Ran Ethereal and still see the same UDP traffic.

I will send a copy of my config to you directly, if you don't mind. Don't know what the heck I'm missing, since my config is as basic as can be.

Thanks, Joe

Well, I ran Merv's commands with no change in behavior. My only other thought is that there may be another connection between the two networks. But without a router, not sure how the traffic would bridge the two subnets. Any thoughts on this?

Thanks, Joe

Were there any hits against the access-list

post the output of show access-list as it should show match counters

Look at the source MAC address on the Ethereal trace taken on the destination side of the router.

If it's the router's MAC address then the traffic is coming from the router.

If it's somebody else's MAC address then the traffic is coming from somewhere else.

If the two networks have a layer 2 connection between them in addition to the layer 3 routed path then this would be consistent with your symptoms.

Merv, Looks like some were denied. Post is below. I will also look into Brigg's suggestion about the MAC addresses. Thanks, Joe

Router#show access-list Extended IP access list BLOCK-239.192.2.64 10 deny udp host 192.168.11.10 host 239.192.2.65 eq 2222 20 permit ip any any (1281497 matches) Extended IP access list BLOCK-239.192.2.65 Router#

There are two MAC addresses listed in the trace, shown below. The source is the address of the Allen-Bradley PLC. The second I don't recognize and don't know how to track down. Joe

Frame 2 (202 bytes on wire, 202 bytes captured)

Ethernet II, Src: Allen-Br_2b:0d:9a (00:00:bc:2b:0d:9a), Dst:

01:00:5e:40:02:40 (01:00:5e:40:02:40)

Internet Protocol, Src: 192.168.11.10 (192.168.11.10), Dst: 239.192.2.64 (239.192.2.64)

User Datagram Protocol, Src Port: 2222 (2222), Dst Port: 2222 (2222)

EtherNet/IP (Industrial Protocol)

As predicted, the source MAC is from the source device, not from the intermediate router. This demonstrates that the router is not involved. The packet is being forwarded at layer 2.

At layer 3, the IP multicast is addressed to 239.192.2.64 At layer 2, the IP address is folded into an Ethernet multicast address.

Check out RFC 1112 for details

Start with 239.192.2.64 Drop the 239. Mask out the high bit of the 192 leaving 64.2.64 In hex, that's 40:02:40

Take the prefix 01:00:5e and tack on 40:02:40

*voila* -- 01:00:5e:40:02:40

You do recognize that an Ethernet address with the low order bit of the first octet set is an Ethernet multicast, right?

I wrote previously:

Now that we've proved that there is indeed a layer 2 connection, the next step is to trace that connection.

If you have a Cisco switch infrastructure, one way to proceed is to start at the switch adjacent to the host receiving these multicasts, log onto it and:

Switch# show mac-addr addr 0000:bc2b:0d9a

The display should show an interface such as FastEthernet0/18. Make note of it.

Switch# show cdp neighbor Fa0/18 detail

The display should show you the adjacent switch (if any) and its IP address. Make note of that. Note also the interface on the adjacent switch that faces back at you. Note that.

Log onto the switch you just found and repeat the process. Continue until you hit a port that has no CDP neighbor but which is, instead, directly adjacent to your Allen-Bradley PLC.

You may get stuck at a switch port facing a piece of non-Cisco gear or a port where CDP has been disabled at one end or the other. In that case, you're on your own.

If you make it all the say to the Allen-Bradley PLC, then you will have traced the layer 2 forwarding path between the two endpoints.

Look at your notes. You will have a list of every switch and every involved interface on that path.

Briggs, Brilliant. Thanks for the detailed answer. There must be a background connection between the two subnets at the switch level. I will begin this phase of investigation.

(On the other note, I did not realize that " recognize that an Ethernet address with the low order bit of the first octet set is an Ethernet multicast" Never had to play in the multicast playground before.)

Thanks much, Joe

Introduction to Ethernet...

Ethernet addresses are transmitted on the cable little-endian. So the low order bit of the first octet in an Ethernet address goes first on the wire. Us software types don't usually need to worry about this endian-ness detail. It's just an interesting bit of hardware trivia that helps explain why it's not the high order bit that's important.

That first bit controls whether the specified address is a unicast or a broadcast/multicast.

FF:FF:FF:FF:FF:FF is, of course, the broadcast address :xx:xx:xx:xx:xx are multicast addresses :xx:xx:xx:xx:xx are unicast addresses

In classical Ethernet, every NIC on the wire gets every packet. The NIC is then expected to filter out received traffic so that what goes up the stack to the attached station is only:

1. Broadcasts
2. Unicasts addressed to [one of] the NIC's address[es]
3. Multicast addresses that the host has expressed interest in

A host that wishes to receive IP multicast group 239.192.2.64 will tell its NIC to look for Ethernet multicast group 01:00:5E:40:02:40

Sniffer software that wishes to receive everything on the wire will tell the NIC to go "promiscuous" and relay everything.

[Implementation details will vary, but this is the naive model. In particular, your operating system software is in the business of giving each application the illusion of a virtual NIC that they can use to access the Ethernet. WireShark/Ethereal can be using the NIC in promiscuous mode at the same time your IP stack is using it in normal mode]

In switched Ethernet, one goal is that the switches preserve the illusion of a classical Ethernet without the overhead of actually forwarding every packet to every station.

Switches do this by keeping track of which unicast addresses are where. They route unicast packets accordingly. Broadcast and multicast packets are flooded to all switch ports on all switches. Unicast packets where no destination location is known are also flooded on all switch ports.

[Implementation details may vary slightly. In particular, switches that implement "IGMP snooping" may be selective in their forwarding of the Ethernet multicast packets that carry IP multicasts. (IGMP is an IP protocol that stations can use to tell routers about IP multicast groups that they do or do not have an interest in)]

A key part of this implementation is that each switch will have a table of which Ethernet addresses are reachable through which switch ports. Managed switches allow you to query this table to see which switch port a particular Ethernet address is connected to/through.

That's the table that the Cisco "show mac-addr addr xxxx.xxxx.xxxx" command queries.

On a single segment, IP multicast and Ethernet multicast merge into one another cleanly. The IP multicast is encapsulated in an Ethernet multicast and the interested stations pick it up off the wire.

If one needs to route IP multicasts on a WAN (you have no need to do this, of course, since you were actually trying to stop it), one generally needs to explicitly enable multicast routing and configure a multicast routing protocol such as PIM.

Brigss, Wow. Great summary. Thanks. I'm a networking guy from way back, but haven't had to delve that deeply into the bottom layers in years. I'll be saving your message for future reference.

Again, thanks for all your help. Joe