The Long and Winding Road wrote: > > 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.
The book answer does seem a little brain-damaged. ;-) Generally you wouldn't want IDSN to stay up just for a routing protocol, from what I understand. Could you change the hello interval? The default on ISDN BRI is 5 seconds. You could make it a lot longer. But then EIGRP would take a long time to converge. You could fix this with a shorter hold-time. Well, you're probably on to bigger and better things by now anyway! Priscilla > > 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=66046&t=66016 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
