cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1827
Views
26
Helpful
18
Replies

NX-OS (n7k) EIGRP outbound distribute-list with route-map tag setting

hrtendrup
Level 1
Level 1

Hello,

I'm having a seemingly basic problem that is frustrating me. I'm certain this worked on classic IOS, but I'm missing whether this is just unsupported on NX-OS, or if this is a bug, or something else.

I want to use an outbound distribute-list with a

route map

to set a tag on selected routes before advertising to its peer.

hrtendrup_0-1661956945954.png

NX01 - 
kickstart: version 8.4(2)
system: version 8.4(2)

NX02-
kickstart: version 8.3(2)
system: version 8.3(2)

There is an Inbound distro-list on NX01:eth1/2 to tag routes learned from VPN endpoint. This seems to work:

 

interface Ethernet1/2

medium p2p
ip address 192.168.255.53/31
ip router eigrp PROC1
ip distribute-list eigrp PROC1 route-map TAG-VPN-ROUTES in
no ip passive-interface eigrp PROC1
no shutdown
!
route-map
TAG-VPN-ROUTES permit 10
set tag 350


!
NX01# show ip route 100.100.100.100

IP Route Table for VRF "default"

100.100.100.0/24, ubest/mbest: 1/0 time
*via 192.168.255.52, Eth1/2, [90/3072], 10:40:46, eigrp-PROC1, internal, tag 350

 

Then, I'm trying to deny routes with tag 350 and further tag anything else with 340 with a outbound

route-map

on NX01:eth1/3:


interface Ethernet1/3
mtu 9150
udld aggressive
ip address 192.168.255.57/31
ipv6 address use-link-local-only
ipv6 router eigrp PROC1
ip router eigrp PROC1
ip authentication mode eigrp PROC1 md5
ip authentication key-chain eigrp PROC1 KEY-EIGRP
ip distribute-list eigrp PROC1 route-map RMAP-DCI-DIST out
no ipv6 passive-interface eigrp PROC1
no ip passive-interface eigrp PROC1
ip pim sparse-mode
no shutdown
!

route-map RMAP-DCI-DIST deny 10
description deny routes from VPN endpoints
match tag 350
route-map RMAP-DCI-DIST permit 20
description permit and tag all other routes
set tag 340
!



When I check the routes on NX02, I do NOT see the routes tagged with 350, BUT the other routes are NOT tagged with 340 either:

 

NX02# show ip route 100.100.100.0
IP Route Table for VRF "default"

0.0.0.0/0, ubest/mbest: 1/0 time
*via 192.168.250.2, Eth5/1, [170/25920], 16w1d, eigrp-PROC1, external, tag 210
!
NX02# show ip route 10.0.10.0
IP Route Table for VRF "default"

10.0.10.0/24, ubest/mbest: 1/0 time
*via 192.168.255.57, Eth5/8, [90/3328], 10:50:53, eigrp-PROC1, internal
!
NX02# show ip eigrp topology 10.0.10.0/24

IP-EIGRP (AS 2020): Topology entry for 10.0.10.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3328
Routing Descriptor Blocks:
192.168.255.57 (Ethernet1/3), from 192.168.255.57, Send flag is 0x0
Composite metric is (3328/3072), Route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 30 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Internal tag is 0
!



The config, is pretty simple, right? This seems like something that should be just working...

 

Edit: I updated the masked route in the

show

outputs that I had forgotten about and probably caused confusion. I'm not sure why I masked an RFC1918 route to begin with, it's not particularly special. Furthermore, I chose not to mask/change the transit networks/IPs which would be arguably more important than the advertised route in question. ¯\_( ͡° ͜ʖ ͡°)_/¯ 

Edit: Updated with NX## running versions

18 Replies 18

Hello


@hrtendrup wrote:

Then, I'm trying to deny routes with tag 350 and further tag anything else with 340 with a outbound

route-map

on NX01:eth1/3:

Try to mark for egress, match/remark ingress


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

hrtendrup
Level 1
Level 1

So, this turns out to be a problem of my own making (as so many are).

I had forgotten about the fact that INTERNAL EIGRP routes can only carry a tag of up to 255 by default. The EIGRP RFC 7868 indicate that there is an extended metric that can carry larger administrator tags which would be valid for internal routes. You can also view the classic internal and external EIGRP packet formats and see that the Internal admin tag field is only 8bits long while the external is 32.

This doc Cisco Nexus 9000 Series NX-OS Unicast Routing Configuration Guide, Release 6.x - Configuring Route Policy Manager [Cisco Nexus 9000 Series Switches] - Cisco mentions this limitation, but I'm unclear how to specifically configure EIGRP to use the wide metric TLVs.

After reconfiguring the outbound

route-map

to set something less than 255, the tag is set and received by the peer EIGRP speaker.


Lastly, as a matter of curiosity, I set the tagging in my classic IOS lab, running 15.5, and the nodes also successfully set and transmitted the maximum tag of 4294967295. It seems that this version automatically uses the wide metric TLVs and can attach admin tags larger than 255. I believe this wasn't the case in earlier versions of IOS, but I would have to confirm.

but I see in your original post route with tag 340 !!
it bug but we need some search to find it.

by the way, I try done lab and same not success with

route-map

IN, 
and I try your suggest and it work. 
so I may need some more study this behavior. 
I will update you If I get something. 

Review Cisco Networking for a $25 gift card