cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2175
Views
0
Helpful
2
Replies

EIGRP route redustribution into ospf - wrong tag

Nathan Spitzer
Level 1
Level 1

OK, so I have a problem I am pulling my hair out and trying to explain it to TAC might take a while so Im going to see if anyone here has a simple answer.

Scenerio: I am using route tagging to control route distribution in an extermely complicated network with almost indescribably complex requirements!. In the little section of the network in question I have 2 3750's running IP Services 12.2(52)SE. On the Enterprise side they have a full mesh setup with EIGRP. On the LAN side they each have a single connection to the LAN core routers (Extreme Network) using OSPF. The Enterprise side (EIGRP) advertises a default roue with a tag of 65013 and I have a route-map attached to the EIGRP-OSPF reditribute command which matches tag 65013 and sets the tag to 65013. In OSPF both 3750's have a distribute-list which uses a route-map to block learning tag 65013 (among others).

Problem: Both 3750's are advertising the default route with a tag of "1" in OSPF.  This means that one of them marks its EIGRP route as Inaccessible since it learns the route via OSPF with a lower admin distance, hence it does not redistribute the route hence traffic is not load-balanced between them. Clearing ip routes on the active switch causes it to flip to inactive and vice-versa, which is both expected and confirms both are doing the same thing. Alternatively, what commands can I show to figure out why a route gets taged as it does?

Validation steps performed already:

  • Verified via "show ip eigrp topo" that both routers are learning 0.0.0.0 0.0.0.0 with a tag of 65013 
  • Verified via "show ip ospf database" that there are no other default routes being learned
  • Went through the configs with a fine-tooth comb looking for "stupid sh@t" I might have missed

Some verification output, a partial 3750 config (they are both identical) is below and a diagram (a VERY VERY SCARY diagram)of the tags in use is attached. Can anyone see whats happening? I could just block routes tagged with "1" but this is complex enough without me putting band-aides on it. I would very much like to know what is going on and fix it right.

Verification:As shown below, both routers are learning the route via EIGRP with a tag of 65013 and one is redistributing it into OSPF with a tag of "1"

****************************************************************************************************************************

ISGS-10-BLD-10#sh ip eigrp topo | be 0.0.0.0
P 0.0.0.0/0, 0 successors, FD is Inaccessible, tag is 65013
        via 158.186.254.9 (104960/102400), GigabitEthernet1/0/21
        via 166.17.254.117 (104960/102400), GigabitEthernet1/0/24

ISGS-10-BLD-10#sh ip ospf database

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         166.17.254.189  1354        0x80000001 0x00C991 1

******************************************************************************************************************************

ISGS-A#sh ip eigrp topol | be 0.0.0.0
P 0.0.0.0/0, 2 successors, FD is 104960, tag is 65013
        via 158.186.254.5 (104960/102400), GigabitEthernet1/0/23
        via 166.17.254.113 (104960/102400), GigabitEthernet1/0/24

ISGS-A#sh ip ospf database
                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
0.0.0.0         166.17.254.189  1455        0x80000001 0x00C991 1

**********************************************************************************************************************************

router eigrp 6075
distribute-list route-map rm_EIGRP-in in GigabitEthernet1/0/24
distribute-list route-map rm_EIGRP-out out GigabitEthernet1/0/24
distribute-list route-map rm_EIGRP-in in GigabitEthernet1/0/21
distribute-list route-map rm_EIGRP-out out GigabitEthernet1/0/21
network AAA.186.0.0
network CCC.17.0.0
redistribute ospf 1 metric 100000 100 255 1 1500 route-map rm_OSPFtoEIGRP
passive-interface default
no passive-interface GigabitEthernet1/0/1
no passive-interface GigabitEthernet1/0/21
no passive-interface GigabitEthernet1/0/24
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 10000
redistribute eigrp 6075 metric 100 metric-type 1 subnets route-map rm_EIGRPtoOSPF
passive-interface default
no passive-interface GigabitEthernet1/0/22
no passive-interface GigabitEthernet1/0/23
no passive-interface GigabitEthernet1/0/26
network CCC.17.24.83 0.0.0.0 area CCC.17.89.0
network CCC.17.24.98 0.0.0.0 area CCC.17.89.0
network CCC.17.24.108 0.0.0.0 area CCC.17.89.0
default-information originate metric 100 metric-type 1
distribute-list route-map rm_OSPF-in in
!

route-map rm_OSPFtoEIGRP permit 10
description Hanover intranet routes
match tag 7200
!
route-map rm_OSPFtoEIGRP permit 20
description VF intranet routes
match tag 751
!
route-map rm_OSPFtoEIGRP permit 30
description GBG/RCK Intranet routes
match tag 100 105
!
route-map rm_OSPFtoEIGRP permit 40
description VF untagged intranet routes
match tag 0
set tag 751
!
route-map rm_OSPFtoEIGRP deny 50
!
route-map rm_EIGRPtoOSPF permit 10
description MPLS routes
match tag 1803 13979
!
route-map rm_EIGRPtoOSPF permit 20
description Enterprise Default Route
match tag 65013
set tag 65013
!
route-map rm_EIGRPtoOSPF permit 30
description VF DF-routable nets
match ip address prefix-list rf-vf-B10-ISN rf-vfdc rf-vpc
set tag 6075
!
route-map rm_EIGRPtoOSPF permit 40
set tag 666
!
route-map rm_EIGRP-in deny 10
match tag 100 105 7200 751
!
route-map rm_EIGRP-in permit 20
!
route-map rm_EIGRP-out permit 10
match ip address prefix-list pl-isgs-summary
set tag 751
!
route-map rm_EIGRP-out permit 20
!
route-map rm_OSPF-in deny 10
match tag 666 1803 6075 13979 65013
!
route-map rm_OSPF-in permit 20
!
!

1 Accepted Solution

Accepted Solutions

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Nspitzter5,

the OSPF default route is NOT the result of EIGRP redistribution into OSPF as this is not supported but it is generated by the following command:

default-information originate metric 100 metric-type 1

as a result of this route tag of OSPF default route is set = OSPF process id.

if you need OSPF default routes to be tagged with a different value you need to use a route-map

like

route-map settag

set tag 65013

set metric 100

and you need to use

default-information originate metric-type 1 route-map settag

be also aware that using distribute lists with OSPF is not a very nice game as they cannot change LS database contents but just if the OSPF route is installed in local router IP routing table. You should rather tune the route-maps used for redistribution

logic:

deny route-tags set on the other direction

accept routes and tag them with other route tags

you need to review all of your route-maps taking in account the notes above

Final note:

you may not need to use mutual redistribution as default route in OSPF is not generated by it but by default originate command as explained above.

This may be feasible or not depending if you just need a default route from WAN block. if you just need the default route there you can remove mutual redistribution with great complexity reduction.

In the long term migrating to an OSPF only routing domain is probably the best solution.

I used the approach that I'm suggesting between OSPF and BGP with good results.

Hope to help

Giuseppe

View solution in original post

2 Replies 2

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Nspitzter5,

the OSPF default route is NOT the result of EIGRP redistribution into OSPF as this is not supported but it is generated by the following command:

default-information originate metric 100 metric-type 1

as a result of this route tag of OSPF default route is set = OSPF process id.

if you need OSPF default routes to be tagged with a different value you need to use a route-map

like

route-map settag

set tag 65013

set metric 100

and you need to use

default-information originate metric-type 1 route-map settag

be also aware that using distribute lists with OSPF is not a very nice game as they cannot change LS database contents but just if the OSPF route is installed in local router IP routing table. You should rather tune the route-maps used for redistribution

logic:

deny route-tags set on the other direction

accept routes and tag them with other route tags

you need to review all of your route-maps taking in account the notes above

Final note:

you may not need to use mutual redistribution as default route in OSPF is not generated by it but by default originate command as explained above.

This may be feasible or not depending if you just need a default route from WAN block. if you just need the default route there you can remove mutual redistribution with great complexity reduction.

In the long term migrating to an OSPF only routing domain is probably the best solution.

I used the approach that I'm suggesting between OSPF and BGP with good results.

Hope to help

Giuseppe

First, thanks for the definative answer. I was kinda sorta thinking along those lines but this whole setup is convoluted enough I need to understand the "why" now so when I look at it later I at least remember there was a definative "why", even if I can't remember what it was!

   "be also aware that using distribute lists with OSPF is not a very nice game as they cannot change LS database contents but just if the OSPF route is installed in local router IP routing table. You should rather tune the route-maps used for redistribution"

True, but you missed two crucial pieces of information that shows why that would be a VBT (Very Bad Thing) in this case.First, lets say I did that: each router would have those routes being redistributed that are currently blocked by the distribution list in their routing tables from both EIGRP and OSPF. For the EIGRP routes going into OSPF the routes learned via OSPF (even though they originated in EIGRP) wins on admin distance, routing loop is the result. Second, those redistribution rules are EXTREMELY finely tuned. Every route being redistributed MUST be redistributed as it is currently setup to meet the requirements. It would take me an hour to even begin to explain the reasons and requirements behind it all and truth be told I HATE this level of complexity (and I created this monstrosity)  but this is actually 1000 times simpler then the old way of static (and unsummerized) access lists used to do the same thing that were impossible to keep syncronized and a royal pain to troubleshoot.

Just to begin to get a glimmer, the EIGRP 100 and OSPF domains are each connected to an enterprise MPLS/BGP network as two separate sites. However, there is a "backdoor" dark-fiber 10GB connection (300 miles or so long) between them. Should the CE routers at either site learn the other sites routes from the LAN side all hell would break loose. In addition, just on the other side of the 3750's in question is a co-located enterprise (EIGRP 6075) data center with lots of resources people in EIGRP 100 want access to.Of the EIGRP 6075 routes there is a subset that can take the backdoor and another subset that cannot for reasons I've never comprehended. And to make things even more interesting, there is a second (smaller) EIGRP100 site with a DIFFERENT backdoor connection that does not do redistribution.

To give you a sense of scale, EIGRP 100 and OSPF has at least 10,000  ports each, each site has several hundred local routes and on the MPLS network there is 3000+ routes

"if you just need the default route there you can remove mutual redistribution with great complexity reduction."

Nope,  the default route is the thing in here I care least about.

In the long term migrating to an OSPF only routing domain is probably the best solution.

Actually, would not make much of a difference. Most of the exact same requirements would still apply. I would just have to break it into two areas and apply almost identical filters at the ABR. The requirements for this are just that complex. I would actually prefer if the group running Extreme networks got with the corporate standard and went with Cisco/EIGRP. I have thought about migrating everthing to OSPF but the reality is I am currently the only one at either of the sites (EIGRP 100 and OSPF) that actually understands OSPF and there is neither the time nor budget to bring all the other network engineers up to speed. In fact, I know much more about OSPF then the guys runing OSPF!

Thanks again for the answer and I hope I've given you some insight into the obvious question of "Was all that REALLY neccessary?" Believe me, it was!

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: