Tunneling over ANW2 Networks

I’ve already posted a couple of times on using ANW2 with Harris 117G radios.  This time I would like to talk about tunneling with ANW2.  In the most simple employment, you hang a single computer off of each radio.  This allows all of the computers to talk to each other.  By adding the RedLAN connection, you can allow those computers to integrate into your LAN.  Instead of using computers, you could hang a router off of your radio and use the ANW2 cloud as a transport network to extent your LAN.  Because the radios do not support EIGRP, we will need to establish tunnels between the routers to advertise our backside networks.  I setup a small lab environment for my Marines to test out this employment.  It looked something like this:

A couple of notes:  The diagram above does not show a tunnel between each of the routers and the router attached to the RedLAN radio.  There is a tunnel there, but I did not depict it in the diagram because it would have cluttered things up too much.  Each of the tunnel sources correspond to the physical connection to the radios (.6, .10, .14).  The tunnel destination would be these same interfaces.  An example would be for the bottom right router tunneling to the middle right router, tunnel source would be .14 and tunnel destination would be .10.  Another configuration note:  These routers need a route to get to their tunnel destinations (the directly connected networks would be the only thing in your routing table).  To cover the entire cloud, I had all of the Marines set a static route to the 172.16.1.0/24 network with a next-hop IP address of their radio.

Each of the routers on the right hand have a single computer and a single IP phone hanging off of them.  They also have a voice and data VLAN for those assets.  The router off of the RedLAN radio has a phone and computer, but it is also running CallManager Express and all phones register to it.

For this exercise, I had all of the Marines start things off by configuring a voice and data VLAN, assigning their computer and IP phone an IP address and made sure they could all ping across.  After that was complete, I had them connect their routers to their radios and assign the appropriate IP addresses.  When we verified they could ping their radio, I had them configure the static route to the 172.16.1.0/24 network.  This allowed them to ping every radio from their router.  As they were working this, I hopped on the router connected to the RedLAN radio and started configuring tunnels to each of the routers.  I setup EIGRP and waited for the Marines to finish their configuration.

I told the Marines to configure their tunnels to route ONLY their tunnel network, their voice VLAN, and their data VLAN.  I had given a class the previous week on recursive routing (going through a tunnel to get to the end of a tunnel, spoiler: doesn’t work well).  Ironically, every single tunnel came up and then was automatically brought down by my router (router attached to RedLAN radio) because of recursive routing.  I went over to the first Marine and reminded him that he was not supposed to advertise the network used to connect to the radio.  He assured me he absolutely did not do so.  Knowing full well that network was advertised, I asked the Marine what he typed in.  His answer was “net 172.16.23.0”.  This is one of the times where knowing the exact syntax of the commands is absolutely crucial.  In the case of EIGRP, the syntax is “network <NET ID> <Wildcard Mask>”.  In the event you should choose to leave off the wildcard mask, the router will fix that for you by placing the default class-full mask there.  In this case, 172.16.23.0 became 172.16.0.0/16.  You can confirm this by typing “show ip protocols”.

I know this post is primarily about tunneling over ANW2, but it is important to go a bit deeper into why the tunnels were disabled for recursive routing.  Each router has the static route of 172.16.1.0/24, which initially got the routers to the tunnel destination.  As soon as the router corrected the network statement (172.16.23.0 -> 172.16.0.0/16), the /30 that is connected to the radio is advertised through the tunnel.  Let’s pretend we are the bottom right router.  In the routing table, we will see 172.16.1.0/24 (admin distance of 1 for static route) and 172.16.1.8/30 (admin distance of 90 for EIGRP).  Even though the static route has a lower administrative distance, the more specific route wins out.  Because the .8/30 network was learned about through the tunnel, the distant end of the tunnel will be the next-hop IP for that network.  Now the tunnel destination is reached through the tunnel.  If you are not lucky enough to have a router that will warn you this is happening, you will notice your neighbor relationships going up and down (flapping).  After the neighbor relationship goes down, the /30 will come out of the routing table and the static route will be used to reach the end of the tunnel.  The tunnel will come back up, the neighbor relationship will re-establish and the /30 will be routed back through the tunnel (causing it to go down again).

The question is, how do we break the cycle?  Like about anything else with routers, there are several answers.  You can correct the initial subnet mask (not advertise the network connected to the radio).  I would consider this the CCNA level answer.  It would correct the problem, but would come at a cost.  By not advertising that subnet, anything 1 hop away would not have a route to that subnet.  Network monitoring stations, for instance, would not be able to tell you if radios are up or not.  The other option, the CCNP level option, would be to configure a prefix list that filters out the tunnel destination from being received through the tunnel.  If you need to monitor the radios, this is the most compelling option.  Prefix lists can be tricky if you don’t have experience with them, and there are few better ways to ruin your network than incorrectly applying one.  An easier, but less attractive option, would be to static route a /32 that includes only the tunnel destination.  I’m sure there are a half dozen other options I am not thinking of right now, but the point is you really need to look at what you need to route and how well trained your people are.

Sorry for the tangent, back to ANW2.  After we fixed the recursive routing (by fixing the subnet mask), the phones all registered and before you knew it, phones were ringing.  To recap, the ANW2 cloud does not support EIGRP, so we needed to tunnel so that we could form EIGRP neighbor relationships and dynamically route our backside networks.  Carefully avoiding recursive routing, we brought the tunnels up and registered phones to our CallManager.  I found this to be an excellent beginner/intermediate training opportunity that was able to re-enforce previously learned topics and get both the data and radio Marines involved and training together.