UDP Broadcast traffic?

I have a Cisco 2500 sitting between two Ethernet subnets. A device on one subnet is generating a high level of UDP broadcast traffic to the address This traffic is appearing on both subnets. My understanding is that the Cisco router does not normally forward these broadcasts without an IP helper address. I have not configured the helper address, and I have run the command 'no ip forward-protocol udp' with no change in behavior.

I've included a portion of the Ethereal trace below. Can anyone tell me how to block this traffic from coming through the router?

Thanks, Joe

No. Time Source Destination Protocol Info

1 2007-08-13 10:52:58.186418 ENIP Connection: ID=Frame 1 (66 bytes on wire, 66 bytes captured)

Arrival Time: Aug 13, 2007 10:52:58.186418000

Time delta from previous packet: 0.000000000 seconds

Time since reference or first frame: 0.000000000 seconds

Frame Number: 1

Packet Length: 66 bytes

Capture Length: 66 bytes

Protocols in frame: eth:ip:udp:enip

Coloring Rule Name: Low TTL

Coloring Rule String: ip.ttl < 5

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

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

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

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

.... ...1 .... .... .... .... = Multicast: This is a MULTICAST frame

.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address

Source: Allen-Br_2b:0d:9a (00:00:bc:2b:0d:9a)

Address: Allen-Br_2b:0d:9a (00:00:bc:2b:0d:9a)

.... ...0 .... .... .... .... = Multicast: This is a UNICAST frame

.... ..0. .... .... .... .... = Locally Administrated Address: This is a FACTORY DEFAULT address

Type: IP (0x0800)

Internet Protocol, Src: (, Dst: (

Version: 4

Header length: 20 bytes

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)

0000 00.. = Differentiated Services Codepoint: Default (0x00)

.... ..0. = ECN-Capable Transport (ECT): 0

.... ...0 = ECN-CE: 0

Total Length: 52

Identification: 0xfb83 (64387)

Flags: 0x00

0... = Reserved bit: Not set

.0.. = Don't fragment: Not set

..0. = More fragments: Not set

Fragment offset: 0

Time to live: 1

Protocol: UDP (0x11)

Header checksum: 0x0082 [correct]

Good: True

Bad : False

Source: (

Destination: (

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

Source port: 2222 (2222)

Destination port: 2222 (2222)

Length: 32

Checksum: 0x1b4a [correct]

EtherNet/IP (Industrial Protocol)

Item Count: 2

Type ID: Sequenced Address Item (0x8002)

Length: 8

Connection ID: 0x003a7e82

Sequence Number: 24378242

Type ID: Connected Data Item (0x00b1)

Length: 6

Data: 72242D330000

Reply to
Loading thread data ...

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

Do you have ip multicast routing enabled ?

Do you have PIM configured?

Reply to

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

Reply to

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 ?

Reply to

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

Do you have PLC controllers connected to this network ?

Reply to


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.

Reply to

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

Reply to

I'm confused.

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

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

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


Reply to

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- ip access-list extended BLOCK- deny udp host host eq 2222 permit ip any any end

config t int ip access-group BLOCK- in end

Reply to

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.

Reply to

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

Reply to

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

Reply to

Were there any hits against the access-list

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

Reply to

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.

Reply to

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- 10 deny udp host host eq 2222 20 permit ip any any (1281497 matches) Extended IP access list BLOCK- Router#

Reply to

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: (, Dst: (

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

EtherNet/IP (Industrial Protocol)

Reply to

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 At layer 2, the IP address is folded into an Ethernet multicast address.

Check out RFC 1112 for details

Start with 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.

Reply to

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

Reply to

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 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.

Reply to

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

Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.