Overview
One of my customers needed to quickly convert his core 6500 switches over to Nexus 7700 switches at two main sites connected by a Comcast ENS service as primary link. The sites are also connected with an MPLS service as a backup path.
In the first project phase, the plan was to try to just move what was currently configured on the old cores over to the new core devices. Since this was mainly a switched environment, this seemed like a reasonable plan. He was planning to move one site at a time.
The old core routing configuration had been grown organically over several years. There was definitely some outdated configuration that could be cleaned up, but optimizing the routing was deferred to Phase 2. I did discuss with the customer that they appeared to have too many static routes, and were redistributing them on all four cores without any route-maps or distribute-lists to control them — not a recommended practice.
One function the customer wanted to migrate was supporting the voice gateway loopbacks. At each location, the customer had loopbacks on two voice gateway routers that he wanted to use to establish tie-lines with the other location. He wanted the traffic to the voice gateway (VG) loopbacks to go across the MPLS ‘backup’ path. On the old 6500s, he had been using static routes at each site to point to the remote voice gateway loopbacks via the local managed MPLS customer edge (CE) router. These routes were redistributed into the EIGRP routing process.
The old running configuration at each site included the following key elements:
After the migration of one side, the MPLS backup path was just performing as a backup path. The SP managed CE router was running EIGRP with his Core2 routers, and BGP across the MPLS. The appropriate tagging and route-maps appeared to be in place on the CE for the redistribution of the EIGRP routes into BGP at one site, and then back into EIGRP at the other site. The MPLS routers were announcing the remote voice gateway loopbacks as routes with an administrative distance of 170.
We discussed what his VG goal was — he wanted to use his MPLS links for the traffic to the VG loopbacks most of the time, and as a backup link when needed.
The customer had been using the distance command in the EIGRP routing process to increase the administrative distance of the remote loopbacks to 171. This technique was successful in allowing him to send just the voice gateway traffic across the backup MPLS links.
We talked about difference between NX-OS and EIGRP: NX-OS does not support redistribution of static routes without a route map, and it does not support the distance command in the EIGRP routing process. Typically, the routing process is configured on an interface, and not with a network statement.
Initial Table-Map Solution
I initially thought we could replace/recreate the 6500’s EIGRP distance command using prefix-lists, route-maps, and table-maps. We decided that he did not need static routes on all his core routers pointing to the remote gateways.
To follow his previous EIGRP distance configuration, I came up with the following configuration using NX-OS table-maps:
A Simpler Solution
After writing up the table-map solution, I realized that a much simpler solution could be implemented. Instead of trying to do the ‘NX-OS’ way of implementing distances in the EIGRP routing process, we could instead recreate the intent.
We could use an EIGRP summary address with a higher distance for the two voice gateway IPs on the ENS interface of the Core1-7Ks. The command will announce a summary route for the two local VG loopbacks to each Core1-7K’s peers. We could then accomplish the customer’s intent with a simplified configuration.
The remote EIGRP peer will learn a higher distance, less specific route, and so it will prefer the MPLS path for traffic.
Summary
In the end, we did not use table-maps on the Cisco Nexus. We agreed that the simple solution is best in this scenario.
I felt it was an interesting exercise looking at EIGRP distance manipulation in NX-OS vs. IOS routing processes.