This will be a quicky I hope, pretty straight forward topic, but I always say that so lets get started.
The IP helper-address is a command issued at the interface level, on the interface of incoming broadcasts, and its purpose is to forward UDP broadcasts on (as routers DO NOT forward broadcasts) to other routers in Unicast format.
The command itself is fairly simple:
R1(config-if)#ip helper-address ?
A.B.C.D IP destination address
global Helper-address is global
vrf VRF name for helper-address (if different from interface VRF)
R1(config-if)#ip helper-address 18.104.22.168 ?
redundancy defines VRG group name
R1(config-if)#ip helper-address 22.214.171.124
In red is what we are focusing on, configuring an IP address, though it is worth noting that you can assign VRF instances for it as well as a global command.
Now the global command was not covered in my materials thus far, but from what I researched (fairly quickly), it works in conjunction with VRF to allow ip helper-address to work with VRF – For the CCNP ROUTE these very well could be unnecessary to know but I wanted to point them out.
Now, back to business.
This command will primarily be used to forward BOOTP (DHCP) requests from host machines onto Domain Controllers running a DHCP server, but it is also VERY important for Cisco Voice as VOIP phones sometimes need a helper-address to reach their TFTP server to pull down their settings. Wanted to drop that little bit of real world knowledge.
By default, the “ip helper-address x.x.x.x” command only forward 8 UDP port #’s:
- TIME (TimeServer) = 37 *** Note this is not NTP and has nothing to do with NTP ***
- TACACS = 49
- DNS = 53
- BOOTP (DHCP SERVER) = 67
- BOOTP (DHCP CLIENT) = 68
- TFTP (Trivial File Transfer Protocol) = 69
- NETBIOS Name Service = 137
- NETBIOS Datagram Service = 138
So we get kind of a win with memorizing these with 67-69 being in sequential order, but the others if you don’t work with them will be good to commit to memory. This command is obviously very oriented on reaching server types, and is mainly used for DHCP / TFTP / DNS so I would really burn those port numbers into your mind.
Remember, it is configured on the interface of the incoming broadcasts, and can be verified with “sh IP int s0/0” and it is becoming so clearly important to remember that “sh ip int” and “sh int” give completely different output so I would recommend really committing the output to memory (as with everything else… of course):
R1#sh ip int s0/0
Serial0/0 is up, line protocol is up
Internet address is 126.96.36.199/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is 188.8.131.52
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is disabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is enabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF Fast switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
WCCP Redirect outbound is disabled
WCCP Redirect inbound is disabled
WCCP Redirect exclude is disabled
I was going to stop at the helper address, but I wanted to exemplify all the different information you can get from “sh ip int x/x” vs “sh int x/x” so really know the differences for exam day!
So we are unable to add protocols to be forwarded via “ip helper-address” (also note the hyphen is between helper-address), so we will need another command:
“ip forward-protocol” comes to save the day, and I want to walk through the output modifiers for clarity on maybe a couple things:
R1(config)#ip forward-protocol ?
nd Sun’s Network Disk protocol
sdns Network Security Protocol
spanning-tree Use transparent bridging to flood UDP broadcasts
turbo-flood Fast flooding of UDP broadcasts
udp Packets to a specific UDP port
R1(config)#ip forward-protocol udp ?
<0-65535> Port number
biff Biff (mail notification, comsat, 512)
bootpc Bootstrap Protocol (BOOTP) client (68)
bootps Bootstrap Protocol (BOOTP) server (67)
discard Discard (9)
dnsix DNSIX security protocol auditing (195)
domain Domain Name Service (DNS, 53)
echo Echo (7)
isakmp Internet Security Association and Key Management Protocol
mobile-ip Mobile IP registration (434)
nameserver IEN116 name service (obsolete, 42)
netbios-dgm NetBios datagram service (138)
netbios-ns NetBios name service (137)
netbios-ss NetBios session service (139)
non500-isakmp Internet Security Association and Key Management Protocol
ntp Network Time Protocol (123)
pim-auto-rp PIM Auto-RP (496)
rip Routing Information Protocol (router, in.routed, 520)
snmp Simple Network Management Protocol (161)
snmptrap SNMP Traps (162)
R1(config)#ip forward-protocol udp ntp ?
R1(config)#ip forward-protocol udp ntp
A few things to note with “ip forward-protocol …” command:
- It is configured on the global configuration level, not the interface
- It also defines in the first ? that there is no TCP options available
- It does not require an IP address to send it to, however it will forward it
Really the main difference that I have found between the two protocols is in terms of vlans, that “ip helper-address” will forward broadcasts onto its same vlan that the interface is part of that it’s configured on, while “ip forward-protocol” will forward to all attached vlans.
So the helper-address is a more focused command, while the forward-protocol is a bit more general in allowing traffic to flow around.
That is actually it for this, I have one more lab on quieting down “sh ip packet” so you can run it on a router without pegging the CPU, but I think it would take voodoo for that to work and then it is on to the massive topic of BGP!
So, I will wrap up the security stuff with that, and then it is going to be some epic labbing from what I understand of BGP – It’s going to be like catching King Kong in a net 🙂 Can’t wait!