The lab in question is one of the current crop of Cisco ASET labs. My answer: access-list 120 deny ip any host 255.255.255.255 access-list 120 permit ip any host 224.0.0.9 access-list 120 permit ip any any
The book answer: access-list 120 deny ip any host 255.255.255.255 access-list 120 permit ip any any Yes the ISDN link is practically permantently up. Depending on the flow of hellos, it may drop for an instant, but it pops right back up. In answer to someone else's point, no, snapshot routing is not an option with either ospf or eigrp. I am assuming that it is possible for bgp. not that I want to get off on a tangent right bow. :-O -- TANSTAAFL "there ain't no such thing as a free lunch" ""Nigel Taylor"" wrote in message news:[EMAIL PROTECTED] > 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=66033&t=66016 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
