Routing ANW2 Networks Safely
The procurement of IP-based radios and the proliferation throughout the Marine Corps have changed and will continue to change the way we employ both radios and IP endpoints. This post is not going to cover how they work, or recommendations for employing them because I honestly have a lot still to learn and think through before I am willing to go into that. What I am willing to do is cover what I believe is the safest way to route the networks that will use ANW2 (Adaptive Networking Wideband Waveform) based radios into your domain.
The radios within an ANW2 network will route between each other automatically as part of the mission plan you configure with the CPA (Communications Programming Application). On the radio side of things, if you would like your radios to route outside of the ANW2 network you will need to configure a REDLAN connection. Simply put, this is a radio that routes between ANW2 and non-ANW2 networks. You could use this radio to push only the networks in your domain to your ANW2 radios, but it just makes much more sense to use this radio to push out a default route to your ANW2 radios. The REDLAN radio would be the single exit point, so a default route also makes sense from a routing perspective.
Where the routing can become dangerous is how you push the ANW2 networks to your routing domain. Again, because it is a single point of entry to the network, static routing is the best bet for the router you connect the REDLAN radio to. Simply static route your entire ANW2 IP allocation to the REDLAN radio’s IP address and you are all set … FOR THAT ROUTER. How will you get those networks to all the other routers (and Layer 3 switches) in your domain? All of the Data Marines have been through CCNA Modules 1-3, so the concept of static routing should be pretty clear. In those modules, you are taught very briefly the concept of redistribution. When you are taught about EIGRP and how to propagate a default route, you are taught about the “redistribute static” command. When you learn this in CCNA your instructor will casually mention this CAN be very dangerous and that you need to be careful. When I used to teach it I would come up with a couple of hypothetical scenarios of just how it could be dangerous, but I was teaching CCNA students so I could not get into how to mitigate the danger. Thankfully now I can.
To help mitigate the potential danger of unwanted static routes making their way through your domain you can use the combination of prefix-lists and route-maps. I have a standard topology I use to quickly test configs. It looks like this:
Each of the routers has a connected network in the 192.168.1.0 range and those networks are routed using EIGRP. Each router also has a loopback corresponding to its router number (ie 1.1.1.1, 2.2.2.2, 3.3.3.3). I am going to do all the configuration on R1 using R3’s loopback as my fictional ANW2 network. All verification will be done on R2 because that network is directly connected to R3 and a static network on R1 (will not show up as an EIGRP route on either).
Before I go into how to mitigate a possible dangerous config, here is an example of what the potentially dangerous config would look like. This is pretty basic stuff, but in the above graphic you can see a static route (I’m notionally using 3.3.3.3/32 to represent my ANW2 networks) and I am redistributing that static route into my EIGRP routing domain.
In the modified configuration that can help mitigate this dangerous config, the first thing we are going to do is to create a prefix-list to define the ANW2 networks, and only the ANW2 networks. You could just as easily use an ACL to do this, but I like the more exact nature of prefix-lists compared to ACLs. Next, we create a route-map to reference the prefix-list. Route-maps consist of a match and a set statement. In this case, we did not use a set statement. Another important thing to note is that because we are going to use this for a redistribution, there is in effect a second route-map statement denying all other networks (much like the implicit deny at the end of an ACL). I included two static routes, one that should match the prefix-list and one that should not. Finally, went into EIGRP and added the redistribution command with the attached route-map. If this worked right, we should have 1 EIGRP external route on R2. If it didn’t we should either have 0 or 2.
As you can tell from the picture, the protected redistribution worked. The quad-zero static route was not redistributed because it was not matched by the prefix-list and referenced in the permitted route-map. Just for the sake of arguement, let’s see what happens when we just try the old “redistribute static”. I will nullify the current redistribution with the route-map, and then redistribute static.
As you can see from the above graphic, without the route-map on the redistribution you will have possibly unwanted networks added to your routing domain. I would highly recommend you do this every time that you route and redistribute an ANW2 network as nearly every time I have helped a Marine trouble-shoot routing problems there have always been statements in the router that they either “Don’t know why that is there” or “were told to do this”.