""Priscilla Oppenheimer"" wrote in message news:[EMAIL PROTECTED] > 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.
You know, Cil, that's a great idea. In the real world that would be one solution. This practice lab is bizarre - running EIGRP over ISDN as the only link to half the network is something that could only happen in the owrld of CCIE studies. :-> Well, I was gonna show how changing the hello and hold timers to outrageous lengths would solve this problem, but the link insistas on statying up Another time. > > 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=66051&t=66016 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
