Re: OSPF- Area dummy area message

From: marc edwards <renorider_at_gmail.com>
Date: Tue, 27 Nov 2012 19:17:19 -0800

Thanks for addressing this. That was great question and explanation. Good
enough where I am sure I will reference again.

Regards,
Marc
On Nov 27, 2012 7:09 PM, "HEMANTH RAJ" <hemanthrj_at_gmail.com> wrote:

> Hi Rajesh
>
> OSPF area dummy area specifies that a LSA origination was prevented by a
> conflicit with an existing LSA with the same LSID but a different mask.
> OSPF resolve conflicts when multiple LSAs with the same prefix and
> differing masks are advertised. When using this algorithm and host routes
> are advertised there are situations where conflict resolution is impossible
> and either the host route or the conflicting prefix is not advertised.
>
> When an LSA is received for the same prefix twice with two different subnet
> masks and the LSA ID is same , w will see this error, in ur case, it is a
> PPP Link and ur a using a different subnet masks, both the configured
> subnet mask and PPP Host route will be added and the there comes a LSA ID
> for the same prefix with two different Subnet masks.
>
> What you can do is that you can locate the prefix that is not advertised
> and the conflicting prefix by entering the show ip route and show ip ospf
> database commands and decide which route or prefix is more important to
> advertise and take steps to prevent advertising the conflicting route or
> prefix.
>
> So the only fix proposed is to remove the unnecessary duplicate prefix, in
> our case it should be the ppp peer route /32 .
>
> Can you give no peer neighbor route under ppp and get rid of /32
>
> And let me know the results.
>
> Thanks
> Hemanth Raj
>
>
> On Tue, Nov 27, 2012 at 11:29 AM, Rajesh Prasad
> <prasadrajesh1979_at_gmail.com>wrote:
>
> > Did any one receive this message?
> >
> > On Mon, Nov 26, 2012 at 5:09 PM, Rajesh Prasad
> > <prasadrajesh1979_at_gmail.com>wrote:
> >
> > > Hi,
> > >
> > > I am having a strange OSPF behavior, may be this is the way to prevent
> > > loop in OSPF.
> > >
> > > This is the lab scenario.
> > >
> > > R5 is acting as a Hub and it is connected to R2 and R4 via
> > > point-to-multipoint link and to R1 via point-to-point link. R1 and R2
> > are
> > > connected to R6 via EIGRP and redistributing EIGRP routes into R1 and
> R2.
> > >
> > > Now, as per my understanding on R1 and R2 the external LSA must be
> > present
> > > in database both on R1 (must be from R2 and its own) and on R2 ( From
> R1
> > > and it own.)
> > > But on both routers the database showing their own external LSA and
> does
> > > not showing external LSA from others.
> > >
> > > After doing the debugging, i found that the routes are removed from the
> > > database due to OSPF set the routes to Area dummy area and increased
> the
> > > metric to 167772 learned from other borders routers
> > >
> > > Debuggin done on R1
> > >
> > > These routes are from R1
> > >
> > > OSPF process partial spfQ LSA id 54.1.3.0: mask 255.255.255.0, type 5
> > > adv_rtr 150.1.1.1, age 3600, seq 0x80000002 (Area dummy area)
> > > OSPF: Start partial processing Type 5 External LSA 54.1.3.0, mask
> > > 255.255.255.0, adv 150.1.1.1, age 3600, seq 0x80000002, metric 167772
> > >
> > > Rack1R2#show ip ospf database external 204.12.1.0
> > >
> > > OSPF Router with ID (150.1.2.2) (Process ID 1)
> > >
> > > Type-5 AS External Link States
> > >
> > > LS age: 968
> > > Options: (No TOS-capability, DC)
> > > LS Type: AS External Link
> > > Link State ID: 204.12.1.0 (External Network Number )
> > > Advertising Router: 150.1.2.2
> > > LS Seq Number: 80000009
> > > Checksum: 0x1165
> > > Length: 36
> > > Network Mask: /24
> > > Metric Type: 1 (Comparable directly to link state metric)
> > > TOS: 0
> > > Metric: 20
> > > Forward Address: 0.0.0.0
> > > External Route Tag: 300
> > >
> > >
> > > Thanks in advance.
> > >
> > > Rgds,
> > >
> > > Rajesh
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Problems arise because we talk,problems are not solved because we don't
> talk So good or bad talk to your affectionate one's freely.
>
> Yours Friendly,
> H P HEMANTH RAJ
> CCIE#28593 (R&S)
>
>
> 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 Tue Nov 27 2012 - 19:17:19 ART

This archive was generated by hypermail 2.2.0 : Sat Dec 01 2012 - 07:27:51 ART