ISIS redistribution

[ziutek]

Simple scenario, difficult problem.

Three routers connected to each other via serial connections.

R1 <-------------> R2 <------------> R3

ISIS <--------------> OSPF

All interfaces pingable from the central router, R2. Redistribution is taking place in both directions on R2. R2 has formed a L1 adjacency with R1. R2 and R3 are OSPF neighbors. There are also loopbacks configured on R1 and R3.

Here is the problem:

The network between R1 and R2 does not get redistributed to R3, even though the loopback on R1 does. This means that you can ping from R3 to R1, but cannot ping from R1 to R3. R1 sees the route to R3, but R3 does not have a route back to the serial interface on R1. An extended ping using the loopback ip address as the source works no problem. This also happens if I change OSPF to EIGRP.

There are several possible solutions. Solving this is not a problem. The quesiton is, WHY does this happen.

Hope someone can answer this.

Regards to all,

Joe

[msdonahue]

When Redistributing with ISIS into any IGP, all of the connected networks for that router runing ISIS are not redistributed. You also need to Redistribute connected.

IE

Router 1

interface Serial1/0.516 point-to-point

ip address 192.168.254.37 255.255.255.252

ip router isis

frame-relay interface-dlci 516

interface Serial1/0.517 point-to-point

ip address 192.168.254.21 255.255.255.252

ip router isis

frame-relay interface-dlci 517

interface Serial1/0.519 point-to-point

ip address 192.168.254.41 255.255.255.252

frame-relay interface-dlci 519

!

interface Serial1/0.521 point-to-point

ip address 192.168.254.49 255.255.255.252

frame-relay interface-dlci 521

router ospf 50

redistribute isis level-1 subnets

network 192.168.254.40 0.0.0.3 area 0

network 192.168.254.48 0.0.0.3 area 0

router isis

net 01.0000.0001.0005.00

redistribute ospf 50

redistribute connected route-map connected

access-list 1 permit 192.168.20.0 0.0.0.3

access-list 1 permit 192.168.36.0 0.0.0.3

route-map connected permit 10

match ip address 1

[ziutek]

Thanks for the reply.

In your example I see redistribution into ISIS from OSPF. My problem is just the opposite. I cannot get connected routes into OSPF from ISIS.

Can you tell me why connected networks are not redistributed into IGP from ISIS?

Thanks,

Joe

[msdonahue]

Sorry I was backwards in my config.

router ospf 50

redistribute isis level-1 subnets

redistribute connected route-map connected

network 192.168.254.40 0.0.0.3 area 0

network 192.168.254.48 0.0.0.3 area 0

router isis

net 01.0000.0001.0005.00

redistribute ospf 50

[ziutek]

OK, but why. No other IGPs behave in this manner?

Joe

[ruwhite]

Whether or not to redistribute routes that are both connected and part of a protocol has been a point of major contention between the protocol teams within cisco for a number of years. EIGRP has traditionally "picked up" conencted routes within other protocols when you redistribute from that protocol, while OSPF and IS-IS do not. It's really something of a distance vector vs link state issue.

So, the bahviour isn't consistent, and isn't likely to be consistent any time in the future.

:-)

Russ.W

[ziutek]

Thanks for the reply Russ.

I also set this up running EIGRP between R2 and R3 with the same results. The connected route does not get "picked up" as you suggest.

Additional comments welcome.

Joe

[ruwhite]

From which protocol into EIGRP, or from EIGRP into which protocol? I've not tested every possible combination in the lab, but let me explain why this happens:

For every route in the routing table, there is a flag that says which protocol "owns" a given route. For instance, every network configured on an interface has the "connected" flag set. If you configure an EIGRP process, and configure a network statement so EIGRP runs on that interface, the "EIGRP" flag will also be set. Now, if some routing protocol is redistributing from EIGRP, say OSPF, IS-IS, or RIP, then it can look at these flags and see if EIGRP "owns" the route.

From here, what you need to know is which protocols use this flag, and which ones check the connected flag when they are redistributing from some other protocol. IS-IS doesn't set these flags for the routes associated with connected interfaces, because IS-IS doesn't use network statements. This means that no other routing protocol can "pick up" the networks for interfaces IS-IS is running on--the information isn't in the routing table. I know that OSPF checks to see if the connected flag is set, and won't treat a route as coming from another protocol if this flag is set. I know that RIP and EIGRP only check for the flag being set for the protocol they are coming from, and never the connected flag.

Again, I've not tested it in the lab, but this is what you should see:

EIGRP-->IS-IS, NO

EIGRP-->OSPF, NO

EIGRP-->RIP, YES

IS-IS-->OSPF, NO

IS-IS-->EIGRP, NO

IS-IS-->RIP, NO

OSPF-->IS-IS, NO

OSPF-->EIGRP, YES

OSPF-->RIP, YES

RIP-->EIGRP, YES

RIP-->IS-IS, NO

RIP-->OSPF, NO

If you are redistributing from IS-IS into EIGRP, EIGRP won't pick up the interfaces IS-IS is running on. If you are redistributing from OSPF into EIGRP, EIGRP should, as far as I know, pick these interfaces up. EIGRP to OSPF, and OSPF won't pick up the connected interfaces. Etc.

So, if I try this on one instance, say OSPF to EIGRP. I configure this:

!

interface Serial0/1

bandwidth 100

ip address 208.0.16.10 255.255.255.0

....

router eigrp 100

redistribute ospf 100

network 208.0.3.0

default-metric 10000 1 255 1 1500

....

router ospf 100

log-adjacency-changes

network 0.0.0.0 255.255.255.255 area 0

!

I get this, on the same router:

2651A#sho ip route

....

C 208.0.7.0/24 is directly connected, Serial0/0

C 208.0.16.0/24 is directly connected, Serial0/1

....

2651A#sho ip eigrp topo

IP-EIGRP Topology Table for AS(100)/ID(208.0.16.10)

....

P 208.0.16.0/24, 1 successors, FD is 256256

via Redistributed (256256/0)

....

EIGRP isn't redistributing connected, nor is it running on the serial interface with the address 208.0.16.0/24--in fact, this network shows up as redistributed. It's getting that network from OSPF, since it's redistributing OSPF, and OSPF is running on that interface. It's a little more complex than it appears at first, it all depends on the routing protocol implementation, the way some bits are used in the routing table, and a bunch of other stuff.

:-)

Russ.W

[ziutek]

Thank you very much Russ for your response and knowledge. I have set up every redistribution scenario that you mentioned above, and here are my results using the simple three router scenario described in my first post:

ISIS-->OSPF no connected

OSPF-->ISIS connected

ISIS-->EIGRP no connected

EIGRP-->ISIS connected

ISIS-->RIP no connected

RIP-->ISIS connected

EIGRP-->RIP connected

RIP-->EIGRP connected

EIGRP-->OSPF connected

OSPF-->EIGRP connected

RIP-->OSPF connected

OSPF-->RIP connected

So it seems that the only protocol that causes connected routes no to be pick up by the protocol into which you are redistributing is ISIS. I had no problems pinging accross the network in either direction using any protocol other than ISIS. I wonder if this is a protocol design issue, or if this is a result of Cisco's implementation of ISIS.

I wrote Dr. Radia Perlman a quick e-mail about this. We'll see if she replies.

Once again thanks for your time, and the interesting discussion.

Regards,

Joe

[ruwhite]

Actually, I'm surprised by OSPF. :-) It's the way Cisco implemented IS-IS, not anything to do with the protocol itself.

:-)

Russ.W