Re: Sanity Check - ISDN and EIGRP [7:66016]
""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--R2EIGRP > > > > > > > > > > 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]
Re: Sanity Check - ISDN and EIGRP [7:66016]
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--R2EIGRP > > > > > > > > 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]
RE: Sanity Check - ISDN and EIGRP [7:66016]
Dosnt sound like they want the ISDN up all the time, if they did why mention not allowing broadcasts to bring the link up? Definitly sounds like an ACL is what they are looking for. Chuck when are you sitting the lab again? Don K. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66031&t=66016 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Sanity Check - ISDN and EIGRP [7:66016]
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--R2EIGRP > > > > > > 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]
Re: Sanity Check - ISDN and EIGRP [7:66016]
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--R2EIGRP > > > > 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]
Re: Sanity Check - ISDN and EIGRP [7:66016]
Hi Chuck >From the look of the problem the best solution to the problem would be to move the redistribution from R1 to R2 and run OSPF over the link. Which then allows you to use an OSPF Demand Circuit reducing the time the link is up. But if the problem specifically mentions that EIGRP must be redistributed on R1 then from the look of the instructions all you need is an Access list that allows no broadcast IP traffic to initiate the link and allows Multicast packets to initiates the link so EIGRP is able to form a neighbour relationship. From memory there is no version of Snapshot for EIGRP, but I could be wrong. If there was that would be the answer. Hope I haven't confused you more Chuck :) Vince - Original Message - From: "The Long and Winding Road" To: Sent: Sunday, March 23, 2003 4:26 PM Subject: Sanity Check - ISDN and EIGRP [7:66016] > 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--R2EIGRP > > 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? > > Chuck > -- > TANSTAAFL > "there ain't no such thing as a free lunch" Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=66020&t=66016 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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--R2EIGRP > > 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=66019&t=66016 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
