Folks,
I'm sure this a pretty straight forward but as this ISDN
connection relates to the lab requirements as a complete scenario should
dictate how the requirements are interpreted.
It seems strange that the ISDN link should stay up indefinitely.
Another question here would be what "broadcast packets" are they referring
to that could bring up the line.
Nigel
Dazed and confused :->
----- Original Message -----
From: "David j"
To:
Sent: Sunday, March 23, 2003 2:50 AM
Subject: RE: Sanity Check - ISDN and EIGRP [7:66016]
> See below:
>
> The Long and Winding Road wrote:
> >
> > I'm working on a practice lab problem.
> >
> > there are two domains - OSPF and EIGRP
> >
> > The two domains can only communicate via ISDN
> >
> > OSPF---R1-------ISDN------R2----EIGRP
> >
> > R1 is where redistribution takes place. The ISDN link is in the
> > EIGRP
> > domain.
> >
> > Pretty much I've concluded that the only way this works is that
> > here have to
> > be static default routes on R1 and R2 pointing to eachother.
> > The only other
> > way I can see this working is for the ISDN link to be
> > permanently up.
> >
> > Unfortunately, the lab instructions are not very clear on this
> > point. The
> > only relevant instructions are:
> >
> > 1) no broadcast packets should initiate a DDR session.
> > Multicast packets
> > should be able to traverse the ISDN link.
> >
> > 2) use an access-list 120 for any filters you may need for DDR
> >
> > 3) only IP traffic will need to traverse the link
> >
> > That multicast instruction is interesting. Am I on the right
> > track thinking
> > the test here is to let the link stay up forever by defining
> > the EIGRP
> > hellos as "interesting" ?? thoughts?
>
> I think so, in fact if the link were used as backup of a serial link it
> would be logical that eigrp multicast packets bring it up when the serial
> link is down. We have our backups defined more or less in that way ( on a
> eigrp - eigrp domain, but this is not so important here). We have defined
as
> interesting traffic any ip packet, but I think you could fulfill all
> requirements of this lab doing some "acl engineering", perhaps denying
> explicitly broadcast packets at the beginning of the acl.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=66023&t=66016
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
