Jan
15

Hi Brians,

Just a quick question about the “include-connected” command when redistributing IPv6 protocols (especially RIPng and OSPFv3). From the DocCD it says that it allows the quote “target protocol to redistribute routes learned by the source protocol and connected prefixes on those interfaces over which the source protocol is running”. Is there any reason why this is now necessary to do with IPv6 routing protocols, whereas IPv4 routing protocols would automatically advertise the networks of the connected interfaces if the source protocol is running on them. By the way, this blog is a fantastic idea/revison tool. Keep up the excellent work.

Kind Regards,

Colin

Hi Colin,

In current IOS versions for IPv4 redistribution is a two step process. Let’s suppose that we are trying to redistribute RIPv2 into OSPFv2 by issuing the “redistribute rip subnets” command under the OSPF process. The first thing the router does is to look at the “show ip route rip” output. All of these prefixes are candidate to be redistributed into OSPF. Next the router looks at the “show ip route connected” output. The routes for any connected interfaces from this output running RIPv2 are also candidate to be redistributed into OSPF. In other words, we don’t have to issue the “redistribute connected subnets” to get connected interfaces that run RIP to be sent into the OSPF process.

In previous IOS versions this was not always the case however. In many network designs, especially in service provider environments, transit links themselves are not advertised into the routing domain. Based on this design traffic cannot be sent *to* the network itself, only *through* the network. Over the course of IOS releases however this behavior was mostly updated, and now we see that IPv4 protocols, with the exception of IS-IS, do automatically redistribute their connected interfaces.

For IPv6 whether or not connected links are included in redistribution is up to you at the time of configuration. If we take the previous case for IPv4 and translate it to IPv6 we’ll see that the behavior is not the same. By this I mean that if we issue the “redistribute rip 1” command under the OSPFv3 process, the router will only look at the output of the routes from the “show ipv6 route rip” command, and not the output from the “show ipv6 route connected”. To get connected interfaces to be included in this redistribution we can either issue a separate “redistribute connected” command under OSPFv3, which will take all connected IPv6 interfaces by default, not those just running RIPng, or we can issue the “redistribute rip 1 include-connected” command. This is the preferred design as it gives us more flexibility as to which particular networks we choose to advertise.

About Brian McGahan, CCIE #8593, CCDE #2013::13:

Brian McGahan was one of the youngest engineers in the world to obtain the CCIE, having achieved his first CCIE in Routing & Switching at the age of 20 in 2002. Brian has been teaching and developing CCIE training courses for over 10 years, and has assisted thousands of engineers in obtaining their CCIE certification. When not teaching or developing new products Brian consults with large ISPs and enterprise customers in the midwest region of the United States.

Find all posts by Brian McGahan, CCIE #8593, CCDE #2013::13 | Visit Website


You can leave a response, or trackback from your own site.

5 Responses to “Understanding How Route Redistribution Works in IPv6”

 
  1. daghighi says:

    Again, a short and interesting article.
    Thanks.

  2. wael says:

    Thanks Brian, but my question is how include-connected differs from redistribute connected or are they just the same. I mean, does include-connected redistribute all connected interfaces like (redistribute connected) or just those who have the redistributed protocol enabled on.

  3. Edward W W says:

    Hi,

    “include-connected” doesn’t work as expected in BGP IPv6.

 

Leave a Reply

Categories

CCIE Bloggers