Redistribute +include-connected

Kevin Dorrell · ‎11-22-2007

Has anyone had any trouble with the include-connected keyword?

12.4(2)T on 2611XM. I was redistributing RIPng into OSPFv3. I tried:

<b>

ipv6 router ospf 100

Â redistribute rip RIPng metric 1 include-connected

</b>

That redistributed the router's remote RIP routes, but for some reason it did not redistribute its connected RIPng interfaces. So instead, I did:

<b>

ipv6 router ospf 100

Â redistribute rip RIPng metric 1

Â redistribute connected metric 1

</b>

That worked fine. I am sure that RIPng was running on those connected interfaces, otherwise the rest of my RIP domain would not have had any updates. So why did the include-connected keyword not redistribute them into RIP?

Does anyone know of a bug or limitation in include-connected? I didn't find anything on the bug database.

Kevin Dorrell

Luxembourg

royalblues · ‎11-22-2007

Kevin,

I just tested it and it works fine. have a look

R2

interface Loopback2

no ip address

ipv6 address 4001::1/64

ipv6 rip test enable

interface Loopback1

no ip address

ipv6 address 3001::1/64

ipv6 ospf 100 area 0

interface Serial2/1

no ip address

ipv6 address 2004::1/64

ipv6 ospf 100 area 0

serial restart-delay 0

clock rate 64000

ipv6 router ospf 100

router-id 10.10.10.1

log-adjacency-changes

redistribute rip test metric 1 include-connected

R3

interface Serial2/0

no ip address

ipv6 address 2004::2/64

ipv6 ospf 100 area 0

serial restart-delay 0

ipv6 router ospf 100

router-id 10.10.10.2

log-adjacency-changes

R3#sh ipv6 route

IPv6 Routing Table - 8 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

U - Per-user Static route, M - MIPv6

I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2

ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

D - EIGRP, EX - EIGRP external

C 2004::/64 [0/0]

via ::, Serial2/0

L 2004::2/128 [0/0]

via ::, Serial2/0

O 3001::1/128 [110/64]

via FE80::C001:16FF:FE3C:0, Serial2/0

OE2 4001::/64 [110/1]

via FE80::C001:16FF:FE3C:0, Serial2/0

L FF00::/8 [0/0]

I can see the loopback being redistributed beacuse of the include connected keyword. Removing it does not redistribute it into ospf

Did the test on 3725 Adavnce IP services image.

HTH

Narayan

Kevin Dorrell · ‎11-22-2007

Thank you Narayan, that's really helpful. I wonder what is going on in my setup then. I shall have to do some more testing. There are one or two differences, but none that should make any difference to the end result. What do you think?

1. I was redistributing both ways, each IGP with its own include-connected. (There was no overlap between the two domains, and all the interfaces were in one or the other IGP.) I don't think the connected were being redistributed in either direction.

2. I had initially tried a metric of 0 each way, which is allowed but was not in my answer book. Puzzled! However, changing to 1 seemed to make no difference.

3. On the OSPF side I was redistributing into an NSSA.

4. The RIPng connected networks that did not get redistributed into OSPF were an Ethernet and a FR point-to-point. I shall try loopbacks on both sides when I get home this evening and see how they behave.

The really strange thing is that I could swear I had full connectivity when I originally configured it on Sunday. I gotta do some more testing until I understand it.

Thanks again.

Kevin Dorrell

Luxembourg

Kevin Dorrell · ‎11-23-2007

Narayan,

I investigated the problem yesterday evening and found I could not reproduce it. However, I did identify another problem, and I wonder if I got confused.

The problem I identified was concerned with the redistribution metric 0, which seems to be an undocumented feature. From OSPF to RIP, if you specify the metric as zero, then the redistribution metric is the OSPF path cost. That is not so useful because most OSPF path costs come out as more than 15. That is why I was getting some routes redistributed and not others. What puzzles me is how I thought it was the connected routes that were not being redistributed, whereas it was actually the more remote routes that were missing.

Thanks again for trying the include-connected. It gave me the impetus to try it again and investigate what was really going on.

Kevin Dorrell

Luxembourg

royalblues · ‎11-23-2007

Kevin,

Now you have got me confused. I thought RIP does not understand a metric of 0 (and no seed metric) and hence it becomes mandatory to specify the metric while redistributing into RIP.

If Zero is specified, RIP should have treated them anyway as infinite metric (>15)

I think i need to lab it up again to confirm the behavior :-)

Narayan