Has anyone had any trouble with the include-connected keyword?
12.4(2)T on 2611XM. I was redistributing RIPng into OSPFv3. I tried:
ipv6 router ospf 100
Â redistribute rip RIPng metric 1 include-connected
That redistributed the router's remote RIP routes, but for some reason it did not redistribute its connected RIPng interfaces. So instead, I did:
ipv6 router ospf 100
Â redistribute rip RIPng metric 1
Â redistribute connected metric 1
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.
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.
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.
We have 3 identical switches configured by someone else and would like to claim some of the Gigabit ports(G1/G2/G3/G4) for use on servers. When we try to change the wiring and configuration, we run in to connectivity issues. Attached is a des...
This is actually a pretty cool feature, i didn't even know it existed until I was looking for a solution to advertise a subnet (prefix in BGP talk), only if a certain condition existed. This is exactly what conditional advertisements does
j ai une question j ai achete un routeur cisco 887VA-k9 , je le configuré avec la configuration ci- dessous
si je le lier avec mon pc portable sur l un de ses ports directement ça marche toute est bien ( la connexion internet + m...