Re: Router-ID & BGP address-family questions

From: Brian McGahan <bmcgahan_at_ine.com>
Date: Tue, 1 Feb 2011 14:14:01 -0600

The real question should be, why don't OSPFv3 and EIGRPv6 just use RIDs in 128 bit IPv6 format instead of 32 bit IPv4 format :) Probably this has to do with control plane overhead, where you save 12 bytes by using a 4 byte RID field instead of a 16 byte RID field.

Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
http://www.INE.com

On Feb 1, 2011, at 2:09 PM, "Scott M Vermillion" <scott_ccie_list_at_it-ag.com<mailto:scott_ccie_list_at_it-ag.com>> wrote:

OK, thanks for the clarification Brian. It would make sense that Cisco would have corrected this, if ever it was a limitation. Why would EIGRPv6 not pull from an interface configured with an IPv4 address like all of the other protocols? Never made sense to me but it's definitely in my notes. Also, the 4th edition of the Cert Guide has the following to say (page 918):

"IPv6 EIGRP requires a routing process to be defined and enabled (no shutdown) and a router ID (in 32-bit IPv4 address format) to be manually assigned using the router-id command, both of which must be done in IPv6 router configuration mode before the IPv6 EIGRP routing process can start. These are two of the differences between EIGRP for IPv4 and IPv6."

Then on the next page it goes on to say the following:

"Router ID - EIGRP for IPv6 requires a 32-bit router ID (a dotted-decimal IPv4 address) to be configured before it starts. A router does not complain about the lack of an EIGRP RID, however, so remember to configure one statically when doing a no shutdown in the routing process."

Perhaps I read too much into statements such as these. Nowhere does the above text explicitly state that an IPv4 address absolutely will not be inherited if configured on an interface. However, it could easily be interpreted to suggest as much. And come to think of it, I'm not sure EIGRPv6 (which is apparently now referred to as "IPv6 EIGRP!") was even within the scope of the lab when I was preparing for it, so it may be the case that I've never labbed it to see for myself one way or the other...

____________________________________________
There are only 10 types of people in the world:
Those who understand binary and those who do not...

On Feb 1, 2011, at 12:48 , Brian McGahan wrote:

No, it's not needed in new versions. It's possible it was needed when the feature was first released. The IPv6 protocols should normally pull their RIDs from an IPv4 interface just like their v4 counterparts. Like you said though, if you're not running dual-stack then you need to configure it manually.

Brian McGahan, CCIE #8593 (R&S/SP/Security)
<mailto:bmcgahan_at_INE.com>bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
<http://www.INE.com>http://www.INE.com

On Feb 1, 2011, at 1:44 PM, "Scott M Vermillion" <<mailto:scott_ccie_list_at_it-ag.com>scott_ccie_list_at_it-ag.com<mailto:scott_ccie_list_at_it-ag.com>> wrote:

Well, I certainly haven't encountered EIGRPv6 in the real world and the code I'm running in my current lab setup doesn't support it, so perhaps I am mistaken. My old notes from R&S lab prep state that the 'router-id' command is required under the EIGRPv6 process, regardless of whether or not any interfaces have been assigned IPv4 addresses. It wouldn't be the first time one of my notes was either just flat out incorrect or had become OBE over the past few years...

____________________________________________
There are only 10 types of people in the world:
Those who understand binary and those who do not...

On Feb 1, 2011, at 12:25 , Brian McGahan wrote:

In IPv6 as well. All designs can be solved without the need for the use of the router-I'd command, both in IPv4 and IPv6. The only issue is that within the scope of the lab, they may say don't do X or dint use command Y, in which case you may be limited as to your viable solutions.

Brian McGahan, CCIE #8593 (R&S/SP/Security)
<mailto:bmcgahan_at_INE.com>bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com><<mailto:bmcgahan_at_INE.com><mailto:bmcgahan_at_INE.com>mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
<http://www.INE.com><http://www.INE.com>http://www.INE.com

On Feb 1, 2011, at 12:58 PM, "Scott M Vermillion" <<mailto:scott_ccie_list_at_it-ag.com>scott_ccie_list_at_it-ag.com<mailto:scott_ccie_list_at_it-ag.com><<mailto:scott_ccie_list_at_it-ag.com>mailto:scott_ccie_list_at_it-ag.com>> wrote:

Likewise there is never a case where you *have* to define the router-I'd manually.

In the case of IPv4, anyway, no?

____________________________________________
There are only 10 types of people in the world:
Those who understand binary and those who do not...

On Feb 1, 2011, at 10:47 , Brian McGahan wrote:

Likewise there is never a case where you *have* to define the router-I'd manually. Whether a routing process is in the global table or a vrf table, the highest loopback that is up/up when the process starts will be the RID. If no loopback exists then the highest address on any other link will be used.

Setting the RID is good design practice, and can make troubleshooting easier. If different routers have the same RID, like in an anycast design, different protocols can have different problems.

So now the question should be, what are these problems? If you know this then it will tell you when it's a good idea to set the RID manually.

Brian McGahan, CCIE #8593 (R&S/SP/Security)
<<mailto:bmcgahan_at_INE.com>mailto:bmcgahan_at_INE.com><mailto:bmcgahan_at_INE.com>bmcgahan_at_INE.com<mailto:bmcgahan_at_INE.com><<mailto:bmcgahan_at_INE.com>mailto:bmcgahan_at_INE.com>

Internetwork Expert, Inc.
<http://www.INE.com>http://www.INE.com

On Feb 1, 2011, at 10:40 AM, "Hussam EL Kebbi" <<mailto:hussamkibbi_at_hotmail.com>hussamkibbi_at_hotmail.com<mailto:hussamkibbi_at_hotmail.com>> wrote:

<mailto:ccielab_at_groupstudy.com>ccielab_at_groupstudy.com<mailto:ccielab_at_groupstudy.com>

Blogs and organic groups at <http://www.ccie.net> http://www.ccie.net
Received on Tue Feb 01 2011 - 14:14:01 ART

This archive was generated by hypermail 2.2.0 : Tue Mar 01 2011 - 07:01:49 ART