We will speak here about some basics about Forwarding UDP broadcast traffic. If you were wondering what Forwarding UDP broadcast traffic actually is I will try to explain it here in few words.
If you have more that one broadcast domains in your local network, let’s say that you have three VLANs. In normal networking theory it’s normal that broadcast initiated on host inside one VLAN will get to all host inside that VLAN but it will not get across to other VLAN. Typically the broadcast domain border is router or a Layer’s 3 switch VLAN interface. Although this is normal for most of broadcast traffic there needs to be a way to forward some kinds of broadcast traffic across that border. Why? Here’s a simple example. If you use DHCP, and you are, you will probably have hosts in different VLANs and all of them need to get the IP address from DHCP. If Forwarding UDP broadcast traffic didn’t exist it will be needed to have one DHCP server on every VLAN. Remember that DHCP works using broadcast traffic in some of the steps.
Simple DHCP address leasing:
Host that connects on the network will in the first step send broadcast DHCP discover message in order to find where the server is or if the server actually exist. After the HDCP replies with unicast DHCP offer host will one again use broadcast to send DHCP request to server. Server will then acknowledge the IP address leasing with unicast ACK message and that’s it.
Forwarding UDP broadcast traffic
If the DHCP server is on one VLAN and host is on other, the DHCP server will not get the first message from the host because that message is broadcast and it will be stopped on broadcast domain border (router, VLAN interface). By implementing Forwarding UDP broadcast traffic it will be possible for DHCP discover and DHCP request to get to the server. Normally that implementation is done on the broadcast border, on the interfaces that are connecting two VLANs (two broadcast domains).
Implementation
Cisco IOS provides two ways to implement Forwarding UDP broadcast traffic:
- IP helper addressing
- UDP flooding
The first method, IP helper addressing, is used in production networks much more frequently than the second. Usually to convert broadcast traffic into unicast. Such as forwarding DHCP requests from all segments to a centralized DHCP server.
I can point you on the fast that using IP helper addressing is only possible if you have the unicast destination on the other segment (IP address of the DHCP server). Basically IP helper addressing needs to know to which unicast address to send the received broadcast. And the config is more than simple, please note that int fa 0/0 is connecting to VLAN with IP addressing 192.168.0.0/24 and that DHCP server is on other VLAN and it has IP address 172.16.1.55
Rack1R5#conf t R5(config)#int fa 0/0 R R5(config-if)#ip add 192.168.1.1 255.255.255.0 R5(config-if)#no sh R5(config-if)#ip helper-address 172.16.1.55
Let’s go further, the other method is UDP flooding and it will be used when you cannot convert the broadcast traffic into unicast traffic simply because you do not know the unicast address. Sometimes is not about you not knowing unicast IP address on other side but it’s about the need to keep the traffic pointed to broadcast address even when forwarded on the other side. If you must make sure that it remains broadcast traffic when forwarded along the specified path your solution is UDP flooding.
Cisco IOS normally possesses a technique for forwarding UDP broadcasts. This feature enables flooding of UDP broadcast packets from one network segment (VLAN) to other. When the feature is enabled each router forwards (rebroadcasts) UDP broadcast packets to the next segment. The packets are not actually routed, layer 2-type forwarding is used. You will use ip forward-protocol spanning-tree command to turn this on.
Although the forwarding is very similar to spanning-tree flooding it does happen on Layer 3. Routers use spanning-tree topology only for loop control and UDP broadcast packets are forwarded out of nonblocking spanning-tree interfaces. The spanning tree must be enabled on all interfaces participating in the flooding tree.
Configuration of spanning tree requires that you configure a bridge-group command on all participating interfaces and that you assure that spanning-tree BPDUs are forwarded along the specified path. When you configure the ip forward-protocol spanning-tree command with the bridge-group command you do not need to enable concurrent routing and bridging (CRB) or integrated routing and bridging (IRB). This configuration will not bridge all IP traffic but only UDP broadcast traffic specified with the ip forward protocol command. This configuration will however bridge all nonrouted (non-IP) traffic if you have that kid of traffic filtering techniques to avoid the bridging of non-IP packets will be needed.
Only UDP packets are forwarded in this fashion and the following conditions must be met for a Packet to be considered for flooding:
- The packet must be MAC-level broadcast
- The packet must be IP-level broadcast
- The packet must be a UDP packet with a port matching what is specified by ip forward-protocol command.
- TTL of those packets must be at least 2
A flooded UDP datagram is given the destination address that is specified by the ip broadcast-address interface configuration command on the output interface. The destination address can be set to any desired address. Therefore the destination address can change as the datagram propagates through the network. The source address is never changed. The TTL value decreases. After a decision has been made to send the datagram out on an interface (and the destination address has possibly changed) the datagram is handed to the normal IP output routines, and is therefore subject to access lists if they are present on the output interface.
The spanning-tree based flooding mechanism forwards packets whose contents are 255.255.255.255 and 0.0.0.0 and also if subnet local broadcast packets (with host part of 255.255.255.255 or 0.0.0.0) when ip forward-protocol spanning-tree any-local-broadcast is configured.
Example on Cisco device
This one enables spanning-tree forwarding:
R5(config)#ip forward-protocol spanning-tree
Here we configure a bridge-group and assign interfaces to it:
R5(config)#interface FastEthernet0/1 R5(config-if)#bridge-group 1 R5(config)#interface Virtual-Temolate1 R5(config-if)#bridge-group 1 R5(config)#bridge 1 protocol vlan-bridge
In this example I configured vlan-bridge spanning-tree protocol in the bridge protocol command. You can use IEEE STP which is most commonly used for fallback bridging but in my case the example is on Catalyst 3550 Series Switch that does not support IEEE STP. If you have 3560 go for IEEE STP. There is no actual bridging that will happen in this example, you just need to build STP topology to provide for loop-free flooding of UDP datagrams.
I need to mention that there must be ip forward-protocol udp global command configured. This applies to both broadcast forwarding methods, IP helper addressing and UDP flooding to. In other words, before Cisco IOS Software can use IP helper or UDP flooding for broadcast it needs to be told what to forward.
Look at what ports you need to forward: Cisco IOS Software has a number of ports enabled for forwarding by default:
- TFTP port 69
- DNS port 53
- Time service port 37
- NetBI0S name server port 137
- NetBIOS datagram server port 138
- BOOTP client and server packets ports 67 and 68
- TACACS service port 49
- IEN-116 name service port 42
Note that on some Cisco IOS versions defaults differ from those just listed even when documentation does not indicate that. The best thing to do is to manually configure all UDP ports that you need to be forwarded. It is done like this:
R5(config)#ip forward-protocol udp tftp R5(config)#ip forward-protocol udp domain R5(config)#ip forward-protocol udp bootps R5(config)#ip forward-protocol udp time R5(config)#ip forward-protocol udp bootpc