NX-OS Route redistribution EIGRP -> OSPF

[rtjensen4]

Maybe I'm misunderstanding somthing:

I use EIGRP as my LAN routing protocol with my pair of Nexus5500 switches in vPC. This works fine.

I want to fire up routing between the Nexus boxes and a Checkpoing firewall cluster. I fire up OSPF for this. Nexus boxes peer with the Checkpoints just fine.

I want the Checkpoints to have EIGRP routing table from box Nexuses.... So I do the following to both Nexus boxes:

ip prefix-list redis-eigrp-to-ospf permit 0.0.0.0/0 le 32
route-map redis-eigrp-to-ospf-rmap deny 10
match tag 9927
route-map redis-eigrp-to-ospf-rmap permit 20
match ip address prefix-list redis-eigrp-to-ospf
set tag 9927
router ospf GFFCU
redistribute eigrp 10 route-map redis-eigrp-to-ospf-rmap

My thought pattern was to send the EIGRP routes to OSPF and Tag them, then filter the tagged routes on the Nexus boxes so they dont see each other's routes.

To my surprise, this is what I see after executing the above commands:

From Nexus 1, OSPF Peer IP 192.168.101.2:

HQ-N5k-1(config-router)# show ip route ospf
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
10.0.240.0/24, ubest/mbest: 1/0
    *via 192.168.101.3, Vlan101, [110/20], 00:00:01, ospf-GFFCU, type-2, tag 9927
     via 192.168.100.6, Eth1/9, [170/5274112], 4d10h, eigrp-10, external
10.1.1.32/32, ubest/mbest: 1/0
    *via 192.168.101.3, Vlan101, [110/20], 00:00:02, ospf-GFFCU, type-2, tag 9927
     via 192.168.90.6, Vlan90, [170/28416], 1d12h, eigrp-10, external
10.1.4.0/24, ubest/mbest: 1/0
    *via 192.168.101.3, Vlan101, [110/20], 00:00:02, ospf-GFFCU, type-2, tag 9927
     via 192.168.90.6, Vlan90, [170/28416], 4d01h, eigrp-10, external

From Nexus 2, OSPF Peer IP 192.168.101.3:

HQ-N5k-2(config-router)# show ip route ospf
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
10.0.240.0/24, ubest/mbest: 1/0
    *via 192.168.101.2, Vlan101, [110/20], 00:00:01, ospf-GFFCU, type-2, tag 9927
     via 192.168.100.10, Eth1/9, [170/5274112], 4d11h, eigrp-10, external
10.1.1.19/32, ubest/mbest: 1/0
    *via 192.168.101.2, Vlan101, [110/20], 00:00:06, ospf-GFFCU, type-2, tag 9927
     via 192.168.90.6, Vlan90, [170/28416], 4d01h, eigrp-10, external

My Nexus boxes are pointing to each other.

What am I missing? I would have thought these tagged routes would be filtered before being installed?? Thoughts?

[dslice]

You're applying the route-maps on redistribution from EIGRP to OSPF and both testing and setting the tags at that point. In other words denying routes from being redistributed from EIGRP into OSPF if they have the tag set. This has no impact on routes that are already in OSPF.

Sent from Cisco Technical Support iPad App

[brandon.cummings]

Since it's a type-2 route it's most likely coming from the other EIGRP router.  Basically a route loop.  You could put a route-map on EIGRP and deny those tagged routes from being redistributed back into OSPF, or you can use a route-map and a distribute-list in on your Nexus OSPF process to deny routes with tag 9927 from being put into the routing table.

[paul driver]

Hello

Looks like you are eigrp is reintroducing the route.

try amending your route-map statements to tag eigrp routes also.

route-map redis-eigrp-to-ospf-rmap deny 10
match tag 110

route-map redis-eigrp-to-ospf-rmap permit 90

set tag 90

route-map redis-ospf-to-eigrp-rmap deny 10
match tag 90

route-map redis-ospf-to-eigrp-rmap permit 90

match ip address prefix-list redis-eigrp-to-ospf
set tag 110

router eigrp x

redistribute ospf x route-map  redis-eigrp-to-ospf-rmap metric 1 1 1 1 1

router ospf x

redistribute eigrp x route-map redis-ospf-to-eigrp-rmap (I beleive "subnets" keyword isnt applicable in Nexus)

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[dslice]

Paul,

This most likely won't work because your solution filters routes in OSPF from being advertised back into EIGRP.  While stopping these routes from being redistributed in a loop is a "good thing", it won't solve the problem shown above.  The reported problem is that a route learned on one ASBR via EIGRP is advertised into OSPF with a tag added.  This route is then received on the other ASBR with the tag, but there is nothing to stop it from installing this prefix into the RIB (which appears to be the problem.)  You've applied a filter for routes with the tag learned in OSPF from going back into EIGRP, but we want to stop them from being installed in the RIB in the first place on the OSPF side. 

As Brandon mentioned, filtering before installing in the RIB should be the real answer. I'm an EIGRP guy by trade, but I believe OSPF also supports a Distribute-list command that can refer to a route-map that tests the tag and blocks the route from RIB installation.