Re: OSPF Duplicate Router-id - problem areas

From: Christian Hunter <stasis416_at_gmail.com>
Date: Thu, 22 Dec 2011 13:55:37 -0500

I think any router that establishes a neighborship with another device via
OSPF within the same area needs to have a unique OSPF router-id as this is
whats used in the database and route exchange etc.. So all OSPF packets
have a standard 24-octet header and the router ID is in this header of the
route originating the OSPF packet. Also LSA exchange containts an
"Advertising Router" field that is the RID. So all ASBRs and all OSPF
enabled RTRs in a single area needs unique RIDs. Sound about right?

I think this is something that is highly testable on the TS section.

On Thu, Dec 22, 2011 at 11:39 AM, Tom Kacprzynski <tom.kac_at_gmail.com> wrote:

> In terms of the lab, I was thinking more in a scenario where you are asked
> to fix the configuration with minimal number of changes, and changing every
> router to correct Router-ID would be excessive.
>
> But in general I'm more interested in the inner workings of OSPF as it
> relates to Router ID, that's all.
>
> Thanks
>
> Tom
>
>
> On Thu, Dec 22, 2011 at 10:06 AM, marc abel <marcabel_at_gmail.com> wrote:
>
> > We always hear that the CCIE isn't a best practice test, but I can't
> > see the proctors/lab writers forcing you to utilize something that is
> > just as bad of an idea as having hosts with the same router ID.
> >
> > On Thu, Dec 22, 2011 at 6:18 AM, Paul Cosgrove
> > <paul.cosgrove.groupstudy_at_gmail.com> wrote:
> > > Generally people define a loop back as rid, using the same interface
> for
> > > device management. Using duplicate rids is taking a risk without any
> > > benefit. The rid does not need to exist as an ip, so using duplicates
> > > wouldn't even save addresses. Even if you were to have a topology where
> > > duplicate rids were not causing problems, they may do so when that
> > network
> > > is later modified.
> > > On Dec 22, 2011 5:41 AM, "Tom Kacprzynski" <tom.kac_at_gmail.com> wrote:
> > >
> > >> Hello,
> > >> I have a quick question regarding OSPF Router-id uniqueness. I know
> that
> > >> router-id needs to be unique in OSPF. So I did some testing.
> > >>
> > >> Looks like in the same area you'll run into problem.
> > >>
> > >> I'm thinking that if you have virtual-links, then yeah that would give
> > your
> > >> problems.
> > >>
> > >> You can't have any ABR or ASBR with router-id that are duplicate, that
> > is a
> > >> problem for sure.
> > >>
> > >> In you have member routers in different areas with duplicate
> router-id,
> > >> you'll run into problems if one of the routers sharing the same
> > router-id
> > >> is originating an external route (FLOOD_WAR).
> > >>
> > >> But outside of that, everyone else would see the advertising router as
> > ABR
> > >> and not the router with duplicate router-id so that should be ok.
> > >>
> > >> Are there any other scenarios? Seems to me saying that the whole AS
> > needs
> > >> to have unique router-id might be too general and there are few cases
> > where
> > >> you won't need that. I'm not saying to start configure them duplicate,
> > but
> > >> just exploring the concept further.
> > >>
> > >>
> > >> Thank you very much in advance for any input.
> > >>
> > >> Tom Kacprzynski
> > >>
> > >>
> > >> Blogs and organic groups at http://www.ccie.net
> > >>
> > >>
> _______________________________________________________________________
> > >> Subscription information may be found at:
> > >> http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Thu Dec 22 2011 - 13:55:37 ART

This archive was generated by hypermail 2.2.0 : Sun Jan 01 2012 - 08:27:00 ART