We had an interesting problem in one of our spokes in our DMVPN network.
The spoke is 2811, its process had been 98% with the process IP input taking 98%.
From netflow I saw a lot of directed broadcasts going through tun4 which is a dmvpn tunnel.
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/0 169.254.29.148 Tu4 169.254.255.255 11 0089 0089 9136
Fa0/0 169.254.220.230 Tu4 169.254.255.255 11 0089 0089 1935
Fa0/0 169.254.153.196 Tu4 169.254.255.255 11 0089 0089 14K
the 169.254.X.X address is the self configured windows address when a pc cannot get IP.
the tunnel configuration is like this and I am wondering if because of the "ip nhrp multicast" forwards all multicast and broadcast traffic over the tunnel.
Is this the case?
ip address X.X.X.X 255.255.252.0
no ip redirects
ip mtu 1400
ip flow ingress
ip nhrp authentication xxxxx
ip nhrp map A.A.A.A. B.B.B.B
ip nhrp map multicast B.B.B.B
ip nhrp network-id 100003
ip nhrp holdtime 600
ip nhrp nhs Y.Y.Y.Y
ip nhrp registration no-unique
ip nhrp shortcut
ip nhrp redirect
tunnel source Loopback4
tunnel mode gre multipoint
tunnel key 100003
tunnel protection ipsec profile backup
Solved! Go to Solution.
The 'ip nhrp multicast' shouldn't cause the issue. Do you have a default route point to the tunnel?
Yes I receive a default route from the tunnel, but routing of directed broadcasts is by default disabled.
I am using IOS 124-22.T5. That's why I am asking about the multicast mapping.
169.254.0.0/16 is not directly connected to any interface, so 169.254.255.255 will not be considered as direct broadcast. You can configure a static route for 169.254.0.0/16 point to null0 to drop the packets.
If you dont have interface configure in 10/8, or 10.255/16 or 10.255.255/24 subnets, then it will follow the default route.
Still confusing? Let's use an example
R1 sends out packets to 10.255.255.255; R1 has default route points to R2; R1 will follow the default route send the packet to R2, just like forward an unicast packet.
Now, when R2 receive the packet, it will decide wether broadcast the packet to 10.255/16 subnet. That decision is made based on 'ip direct-broadcast' command. If 'ip direct-broadcast' is configured on R2 LAN interface, then R2 will send out the broadcast. If ' no ip direct-broadcast' is configured, which is default or newer IOS, then R2 will drop the packet.
First of all, I don't understand why the router R1 will forward the packet since it doesn't have "ip directed broadcast" enabled.
The reason it forwards it in my opinion is because of the
ip nhrp map multicast dynamic|[StaticIP] command
this command is used in order to send multicast/broadcast packets across an NBMA network (in order routing protocol updates to work)
Are you saying that if I have two routers R1-R2 connected by a leased line (no tunnel int), R1 will forward directed broadcasts to R2 just because it received a default route from R2?
Having 'ip directed-broadcast' or not changes the behavior when router receives broadcast traffic destinat to the subnet where this interface belongs to.
What will be the behavior if you remove 'ip nhrp map multicast dynamic|[StaticIP]'?
I think the tunnel will stop forwarding broadcast and mcast, because the mgre tunnel doesn't know how to encapsulate the traffic. However, it will still forward the traffic towards 169.254.255.255. It will consider it as a unicast traffic.
Do you think a router will forward a traffic destinat to 10.10.10.127? I think you will say yes, right? Because 10.10.10.127 is a valid unicast address, but it is also a broadcast address for 10.10.10.0/25 subnet. If you think router should forward 10.10.10.127 why do you think it shouldn't forward 10.10.10.255?
I will take a slightly different approach in answering than the very good information provided by Lei Tian. Perhaps in combining our answers you may understand better what is going on. The command of ip directed-broadcast only has effect on the router where the destination is.
This is partly because no router at the source and no router along the path toward the destination can know for sure whether a packet to be forwarded is a unicast or is a directed broadcast. In today's environment of CIDR addressing only the router that has the subnet mask on the interface can know for sure whether it is unicast or is broadcast. I like the example given by Lei Tian about 10.10.10.127 which is a good example of this point.
Hi Lei and Richard and thanks
Now I understood the thing about directed broadcasts.
What about the multicast and broadcast (all 1s) traffic?
if the router forwards multicast/broadcast traffic (except for the routing updates) over the tunnel then I have a waste of bandwidth.
I tried a ping from R1 to 255.255.255.255 and I got a reply from R2 (and of course the hosts on the local lan)
R1----dmvnp tunnel---------R2 (dmvpn hub)
What you are describing is the normal behavior of IOS routers. If you are concerned about wasted bandwidth you could apply an access list to the tunnel and filter out traffic that you believe is wasting bandwidth. Be aware that an access list can not filter out traffic generated by the router itself (so if you ping 255.255.255.255 then the ping will go over the tunnel no matter what access list). But you can certainly filter out 169.254.255.255 or things like that.