From: tycampbell@comcast.net
Date: Thu Sep 09 2004 - 11:39:43 GMT-3
John,
I apologize for mis-understanding your post. You have cleared this up for me.
Thnak you,
Ty
-------------- Original message -------------- 
> Hello Ty, 
> I just wanted to let people know that I did create a forum specifically 
> for the New Cisco press book, and the purpose of my statement to post 
> questions in my forum, and errors that you find, is to have a central 
> place, to have discussion, and to possibly check my forum to see if the 
> same issue has already been discussed previously. As always you are free 
> to post the question in Groupstudy as well, and I recommend that you put 
> which lab and source you are discussing the problem with. Again, I agree 
> with Howard, in that if you do post a question from a lab study vendor 
> on Groupstudy that you include the question in your email, so those of 
> us that have the workbook or scenario can reference it. Also you can 
> read the posts in my forum without being a member. I hope that helps 
> clarify for you. 
> 
> Sincerely, 
> 
> John Matijevic, CCIE #13254, MCSE, CNE, CCEA 
> CEO 
> IgorTek Inc. 
> 151 Crandon Blvd. #402 
> Key Biscayne, FL 33149 
> Hablo Espanol 
> 305-321-6232 
> http://home.bellsouth.net/p/PWP-CCIE 
> 
> 
> -----Original Message----- 
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of 
> tycampbell@comcast.net 
> Sent: Thursday, September 09, 2004 7:31 AM 
> To: john matijevic; 'john matijevic'; 'Richard Dumoulin'; 'James' 
> Cc: 'Kenneth Wygand'; ccielab@groupstudy.com 
> Subject: RE: RE : RE : RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> 
> John, 
> Just curious as to why the questions should be posted on your forum and 
> not on this board for all of us to see ? Or do you mean in addition to 
> this board ? 
> No offense, but I find this board extremely helpful, and I don't want to 
> join another forum at this time. 
> Ty 
> 
> 
> -------------- Original message -------------- 
> 
> > Hello Team, 
> > Here is the scenario, there are no restrictions as far as the backup 
> > method to use. As far as the first task in isdn it is telling you that 
> 
> > they should be able to ping each other, so you have to make sure you 
> > define the interesting traffic, and based on previous lab has the same 
> 
> > task so they permitted the ip and clns in dialer-list statements. Now 
> as 
> > far as the backup method, in this case and in Lab 5, the answer key 
> left 
> > it out, but if you read the ask the proctor guide, it looks like they 
> > are leading to backup interface. I was able to use the backup 
> interface 
> > method in this case. Again, please post questions in my forum and 
> errors 
> > that you find. 
> > 
> > R2#sh ip route 
> > Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - 
> BGP 
> > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
> > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 
> > E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP 
> > i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS 
> > inter area 
> > * - candidate default, U - per-user static route, o - ODR 
> > P - periodic downloaded static route 
> > 
> > Gateway of last resort is not set 
> > 
> > O E2 196.1.8.0/24 [110/56] via 160.10.38.4, 00:10:13, Serial1.2 
> > B 198.18.10.0/24 [200/0] via 160.10.6.6, 00:10:06 
> > B 200.20.4.0/24 [200/0] via 160.10.6.6, 00:10:06 
> > 50.0.0.0/24 is subnetted, 1 subnets 
> > D 50.5.5.0 [90/409600] via 130.200.10.200, 00:29:46, Ethernet0 
> > B 200.20.5.0/24 [200/0] via 160.10.6.6, 00:10:06 
> > O E2 196.1.9.0/24 [110/56] via 160.10.38.4, 00:10:13, Serial1.2 
> > O E2 196.1.10.0/24 [110/56] via 160.10.38.4, 00:10:13, Serial1.2 
> > B 198.18.8.0/24 [200/0] via 160.10.6.6, 00:10:07 
> > B 200.20.6.0/24 [200/0] via 160.10.6.6, 00:10:07 
> > B 198.18.9.0/24 [200/0] via 160.10.6.6, 00:10:07 
> > B 200.20.7.0/24 [200/0] via 160.10.6.6, 00:10:07 
> > D 193.118.9.0/24 [90/409600] via 130.200.10.200, 00:29:47, Ethernet0 
> > O E2 20.0.0.0/8 [110/128] via 160.10.38.4, 00:10:16, Serial1.2 
> > B 200.20.1.0/24 [200/0] via 160.10.6.6, 00:10:09 
> > D 193.118.8.0/24 [90/409600] via 130.200.10.200, 00:29:49, Ethernet0 
> > B 200.20.2.0/24 [200/0] via 160.10.6.6, 00:10:09 
> > B 200.20.3.0/24 [200/0] via 160.10.6.6, 00:10:09 
> > D 193.118.10.0/24 [90/409600] via 130.200.10.200, 00:29:49, Ethernet0 
> > D 193.118.5.0/24 [90/409600] via 130.200.10.200, 00:29:49, Ethernet0 
> > B 198.18.2.0/24 [200/0] via 160.10.6.6, 00:10:09 
> > D 193.118.4.0/24 [90/409600] via 130.200.10.200, 00:29:49, Ethernet0 
> > B 198.18.3.0/24 [200/0] via 160.10.6.6, 00:10:09 
> > O E2 196.1.1.0/24 [110/56] via 160.10.38.4, 00:10:16, Serial1.2 
> > 160.10.0.0/16 is variably subnetted, 16 subnets, 3 masks 
> > O 160.10.37.5/32 [110/64] via 160.10.37.5, 00:10:16, Serial1.1 
> > C 160.10.32.0/30 is directly connected, Serial0 
> > O E2 160.10.33.0/24 [110/100] via 160.10.37.5, 00:00:11, Serial1.1 
> > C 160.10.38.0/24 is directly connected, Serial1.2 
> > O 160.10.37.1/32 [110/64] via 160.10.37.1, 00:10:17, Serial1.1 
> > C 160.10.37.0/24 is directly connected, Serial1.1 
> > O IA 160.10.11.1/32 [110/65] via 160.10.37.1, 00:10:17, Serial1.1 
> > C 160.10.15.0/24 is directly connected, BRI0 
> > C 160.10.2.0/24 is directly connected, Loopback0 
> > O 160.10.3.0/24 [110/65] via 160.10.32.1, 00:25:52, Serial0 
> > O 160.10.1.0/24 [110/65] via 160.10.37.1, 00:10:17, Serial1.1 
> > O E2 160.10.6.0/24 [110/100] via 160.10.37.5, 00:10:17, Serial1.1 
> > O 160.10.4.0/24 [110/65] via 160.10.38.4, 00:10:17, Serial1.2 
> > O 160.10.5.0/24 [110/65] via 160.10.37.5, 00:10:17, Serial1.1 
> > O IA 160.10.25.0/24 [110/65] via 160.10.37.5, 00:10:17, Serial1.1 
> > O E2 160.10.22.0/24 [110/100] via 160.10.37.5, 00:10:17, Serial1.1 
> > D 193.118.7.0/24 [90/409600] via 130.200.10.200, 00:29:50, Ethernet0 
> > O E2 196.1.2.0/24 [110/56] via 160.10.38.4, 00:10:17, Serial1.2 
> > 40.0.0.0/24 is subnetted, 1 subnets 
> > D 40.4.4.0 [90/409600] via 130.200.10.200, 00:29:50, Ethernet0 
> > 130.200.0.0/24 is subnetted, 1 subnets 
> > C 130.200.10.0 is directly connected, Ethernet0 
> > D 193.118.6.0/24 [90/409600] via 130.200.10.200, 00:29:51, Ethernet0 
> > B 198.18.1.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > O E2 196.1.3.0/24 [110/56] via 160.10.38.4, 00:10:18, Serial1.2 
> > O E2 196.1.4.0/24 [110/56] via 160.10.38.4, 00:10:18, Serial1.2 
> > B 198.18.6.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > B 200.20.8.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > D 193.118.1.0/24 [90/409600] via 130.200.10.200, 00:29:51, Ethernet0 
> > B 198.18.7.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > B 200.20.9.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > O E2 196.1.5.0/24 [110/56] via 160.10.38.4, 00:10:19, Serial1.2 
> > O E2 196.1.6.0/24 [110/56] via 160.10.38.4, 00:10:19, Serial1.2 
> > B 198.18.4.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > B 200.20.10.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > D 193.118.3.0/24 [90/409600] via 130.200.10.200, 00:29:51, Ethernet0 
> > B 198.18.5.0/24 [200/0] via 160.10.6.6, 00:10:11 
> > O E2 196.1.7.0/24 [110/56] via 160.10.38.4, 00:10:19, Serial1.2 
> > D 193.118.2.0/24 [90/409600] via 130.200.10.200, 00:29:51, Ethernet0 
> > O E2 30.0.0.0/8 [110/128] via 160.10.38.4, 00:10:19, Serial1.2 
> > R2# 
> > 
> > Sw2(config)#int fa0/3 
> > Sw2(config-if)#shut 
> > Sw2(config-if)# 
> > 01:34:26: %LINK-5-CHANGED: Interface FastEthernet0/3, changed state to 
> 
> > administ 
> > atively down 
> > 01:34:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
> > FastEthernet0/3, chan 
> > ed state to down 
> > Sw2(config-if)# 
> > 
> > 
> > Ethernet0 160.10.22.3 YES manual up 
> > down 
> > 
> > R2#sh ip route isis 
> > 160.10.0.0/16 is variably subnetted, 17 subnets, 3 masks 
> > i L1 160.10.33.0/24 [115/20] via 160.10.15.5, BRI0 
> > R2# 
> > 
> > 
> > As you can now see that with the interface shut, R2 learns the route 
> > through IS-IS going over the isdn link. 
> > 
> > R2#ping 49.0004.0000.0000.0003.00 
> > 
> > Type escape sequence to abort. 
> > Sending 5, 100-byte CLNS Echos with timeout 2 seconds 
> > !!!!! 
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/44 
> ms 
> > R2# 
> > comm-server#3 
> > [Resuming connection 3 to r3 ... ] 
> > 
> > 01: 
> > R3#ping 49.0004.0000.0000.0002.00 
> > 
> > Type escape sequence to abort. 
> > Sending 5, 100-byte CLNS Echos with timeout 2 seconds 
> > !!!!! 
> > Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/44 
> ms 
> > R3# 
> > 
> > And I R2 and R3 can ping each other across the isdn link. 
> > 
> > 
> > Sincerely, 
> > 
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA 
> > CEO 
> > IgorTek Inc. 
> > 151 Crandon Blvd. #402 
> > Key Biscayne, FL 33149 
> > Hablo Espanol 
> > 305-321-6232 
> > http://home.bellsouth.net/p/PWP-CCIE 
> > 
> > 
> > -----Original Message----- 
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf 
> Of 
> > john matijevic 
> > Sent: Wednesday, September 08, 2004 5:50 PM 
> > To: 'Richard Dumoulin'; 'James' 
> > Cc: 'Kenneth Wygand'; ccielab@groupstudy.com 
> > Subject: RE: RE : RE : RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> 
> > 
> > Hello Richard, 
> > I really believe this could be solved with backup interface on R5, 
> that 
> > is how I solved the lab I dont have the debugs right now, but later I 
> 
> > will relab it up and demonstrate that it will meet the requirements. 
> > 
> > Sincerely, 
> > 
> > 
> > 
> > John Matijevic, CCIE #13254, MCSE, CNE, CCEA 
> > CEO 
> > IgorTek Inc. 
> > 151 Crandon Blvd. #402 
> > Key Biscayne, FL 33149 
> > Hablo Espanol 
> > 305-321-6232 
> > http://home.bellsouth.net/p/PWP-CCIE 
> > 
> > -----Original Message----- 
> > From: Richard Dumoulin [mailto:Richard.Dumoulin@vanco.fr] 
> > Sent: Wednesday, September 08, 2004 3:31 PM 
> > To: James 
> > Cc: Kenneth Wygand; john matijevic; ccielab@groupstudy.com 
> > Subject: RE : RE : RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> > 
> > James, R5's Fast0/0 could be down but R3's Fast 0/0 not. How could R3 
> > know if R5's Ethernet is down ? 
> > We have ISIS already. A pity that ISIS on demand does not exists :) 
> > --Richard 
> > -----Message d'origine----- 
> > De : James [mailto:james@towardex.com] 
> > Envoyi : Wednesday, September 08, 2004 9:08 PM 
> > @ : Richard Dumoulin 
> > Cc : Kenneth Wygand; john matijevic; ccielab@groupstudy.com 
> > Objet : Re: RE : RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> > On Wed, Sep 08, 2004 at 08:01:14PM +0100, Richard Dumoulin wrote: 
> > > The requirement is "...when R5 fast0/0 goes down...". 
> > > R3 is connected to the same Ethernet segment as R5 so R3 won't be 
> able 
> > to 
> > > know if R5 Fast is down because it can learn R5's routes via another 
> 
> > frame 
> > > relay interface. 
> > The fa0/0 of R5 is also fa0/0 of R3, both sitting on the same ethernet 
> 
> > network 
> > with ISDN circuit suppose to be "backup." 
> > > 
> > > I still don't like watching a connected interface but I don't see 
> any 
> > reason 
> > > to not use it ! Is there any one ? If not then we only need the 
> > equivalent 
> > > commands of backup delay to fulfill the same requirements as the 
> > backup 
> > > command and even more !!! 
> > I think this question is just a little bit messy in the wording :P 
> > But, since we like challenges however.. 
> > The dialer-watch idea I think is shot down upon realization that both 
> > routers 
> > share the same connected network. 
> > How about running OSPF w/ demand circuit in between, in a totally 
> > seperate 
> > process and its own area 0 accross the ISDN, so that topology changes 
> on 
> > the 
> > primary ospf network in R3 won't trigger the ISDN activation. But 
> FA0/0 
> > outage on R5 would, which would then cause CLNS to establish 
> > adjacency..? 
> > Thanks again! 
> > -J 
> > > 
> > > --Richard 
> > > 
> > > -----Message d'origine----- 
> > > De : Kenneth Wygand [mailto:KWygand@customonline.com] 
> > > Envoy? : Wednesday, September 08, 2004 8:54 PM 
> > > ? : Richard Dumoulin; James 
> > > Cc : john matijevic; ccielab@groupstudy.com 
> > > Objet : RE: RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> > > 
> > > Since I don't have the lab in front of me (but I did buy the book 
> and 
> > > studied from it and liked it), does it say which side has to do the 
> > dialing? 
> > > Otherwise, you could have the other side watch the network so you 
> > don't have 
> > > to watch a directly-connected network. 
> > > 
> > > Kenneth E. Wygand 
> > > Systems Engineer, Project Services 
> > > CCIE #13720, CISSP #37102, CCNP/DP, ACSP, 
> > > Cisco IPT Design Specialist, MCP, CNA, Network+, A+ 
> > > Custom Computer Specialists, Inc. 
> > > "Failure only occurs at the point in which one stops trying." 
> > > -Anonymous 
> > > 
> > > Custom Computer Specialists, Inc. 
> > > "Celebrating 25 Years of Excellence" 
> > > 
> > > -----Original Message----- 
> > > From: Richard Dumoulin [mailto:Richard.Dumoulin@vanco.fr] 
> > > Sent: Wednesday, September 08, 2004 2:51 PM 
> > > To: Kenneth Wygand; James 
> > > Cc: john matijevic; ccielab@groupstudy.com 
> > > Subject: RE : RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> > > 
> > > Kenneth, you passed before the book was edited I think :) 
> > > "CCIE Routing and Switching Practice Labs". 
> > > James, 
> > > it does not say "must" but "should only pass a routing protocol if 
> > fast0/0 
> > > is down". 
> > > But yes, I think you are right and dialer watch should do the job. 
> > Although 
> > > I find it weird to watch a directly connected interface. Is this 
> good 
> > > practice ? 
> > > --Richard 
> > > -----Message d'origine----- 
> > > De : Kenneth Wygand [mailto:KWygand@customonline.com 
> > > ] 
> > > Envoy? : Wednesday, September 08, 2004 8:44 PM 
> > > ? : James; Richard Dumoulin 
> > > Cc : john matijevic; ccielab@groupstudy.com 
> > > Objet : RE: RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> > > James, 
> > > Which practice lab workbook is this from? I've purchased almost all 
> > of 
> > > them so I should be able to reference the diagram to answer your 
> > > question. 
> > > Thanks! :) 
> > > Kenneth E. Wygand 
> > > Systems Engineer, Project Services 
> > > CCIE #13720, CISSP #37102, CCNP/DP, ACSP, 
> > > Cisco IPT Design Specialist, MCP, CNA, Network+, A+ 
> > > Custom Computer Specialists, Inc. 
> > > "Failure only occurs at the point in which one stops trying." 
> > > -Anonymous 
> > > Custom Computer Specialists, Inc. 
> > > "Celebrating 25 Years of Excellence" 
> > > 
> > > -----Original Message----- 
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com 
> > > ] On Behalf Of 
> > > James 
> > > Sent: Wednesday, September 08, 2004 2:38 PM 
> > > To: Richard Dumoulin 
> > > Cc: john matijevic; ccielab@groupstudy.com 
> > > Subject: Re: RE : Lab6 Cisco r&s Prac Labs ISDN wording 
> > > On Wed, Sep 08, 2004 at 07:32:17PM +0100, Richard Dumoulin wrote: 
> > > > Hi John, the problem with using the backup command is you are 
> > breaking 
> > > the 
> > > > requirement "...R3 and R5 should be able to ping each other..." 
> > > > 
> > > > After reading his explanation I have come to the conclusion that 
> it 
> > is 
> > > not 
> > > > really a backup solution the author is asking for, nor is there a 
> > > > requirement for it. We can see in the breakdown solution that ISIS 
> 
> > > only goes 
> > > > through the isdn line once he pings through the bri interfaces so 
> he 
> > 
> > > is 
> > > > effectively fulfilling all his requirements. 
> > > But ISIS must activate when fa0/0 goes down? :P 
> > > I am pretty new in the ISDN field as my experience never used it in 
> > the 
> > > past. So I ask -- would using dialer-watch also prevent pinging 
> > accross 
> > > the 
> > > ISDN circuit when fa0/0 is up and running, like backup command does? 
> 
> > > Thanks for all the good replies! 
> > > -J 
> > > > 
> > > > --Richard 
> > > > 
> > > > -----Message d'origine----- 
> > > > De : john matijevic [mailto:matijevi@bellsouth.net 
> > > ] 
> > > > Envoyi : Wednesday, September 08, 2004 6:00 PM 
> > > > @ : 'James'; ccielab@groupstudy.com 
> > > > Objet : RE: Lab6 Cisco r&s Prac Labs ISDN wording 
> > > > 
> > > > Hello James, 
> > > > Yes this is an error in the book, please visit my forum, as there 
> > are 
> > > > many errors already pointed out there, already. Backup interface 
> is 
> > > the 
> > > > solution I used as well. 
> > > > 
> > > > Sincerely, 
> > > > 
> > > > John Matijevic, CCIE #13254, MCSE, CNE, CCEA 
> > > > CEO 
> > > > IgorTek Inc. 
> > > > 151 Crandon Blvd. #402 
> > > > Key Biscayne, FL 33149 
> > > > Hablo Espanol 
> > > > 305-321-6232 
> > > > http://home.bellsouth.net/p/PWP-CCIE 
> > > 
> > > > 
> > > > 
> > > > -----Original Message----- 
> > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com 
> > > ] On Behalf 
> > > Of 
> > > > James 
> > > > Sent: Wednesday, September 08, 2004 3:23 AM 
> > > > To: ccielab@groupstudy.com 
> > > > Subject: Lab6 Cisco r&s Prac Labs ISDN wording 
> > > > 
> > > > In Lab 6 on practice labs , under ISDN, we see the following: 
> > > > 
> > > > "Make sure that yourrouting proto is passed accross the isdn link 
> > only 
> > > > when 
> > > > the connectivity is established" 
> > > > 
> > > > In order to accomplish the above, we simply make sure 'dialer-list 
> 1 
> > 
> > > > proto 
> > > > clns permit', and ensure that "clns_is" is not included -- thereby 
> 
> > > > making 
> > > > ISIS establish adjacency only when ISDN circuit is already up and 
> > > > running. 
> > > > So far so good. (well also ensuring dialer map clns yadda yadda..) 
> 
> > > > 
> > > > "The ISDN link should only pass a routing protocol if R5-fa0/0 is 
> > > down." 
> > > > 
> > > > Now.. it says ISDN should pass routing protocol when fa0/0 on R5 
> is 
> > > > down. 
> > > > That is good and all when FA0/0 sudden goes down while ISDN is 
> > already 
> > > > dialed 
> > > > and running. But what happens when ISDN is NOT dialed and turned 
> off 
> > 
> > > > (due to 
> > > > idle traffic)?? The previous requirement says that isdn must only 
> > > > establish 
> > > > ISIS protocol when the circuit is already dialed and running. 
> > > > 
> > > > So the thought process here in my head is to use 'backup 
> interface' 
> > on 
> > > > fa0/0 
> > > > or another mechanism that will trigger ISDN to dial itself during 
> > > fa0/0 
> > > > outage. 
> > > > This will ensure ISIS will establish adjacency then, after fa0/0 
> > > outage, 
> > > > since backup interface brought up the ISDN circuit physically. 
> > > > 
> > > > But the solution in the book made no configuration changes for 
> this 
> > > > requirement. 
> > > > 
> > > > Well, not making any config changes for this requirement works 
> well 
> > > when 
> > > > the 
> > > > isdn is already dialed and up and running, but guarantees nothing 
> > when 
> > > > proctor 
> > > > reboots your routers and isdn is shut down at boot time :( 
> > > > 
> > > > Any ideas, clues? 
> > > > 
> > > > Thanks, 
> > > > -J 
> > > > -- 
> > > > James Jun TowardEX 
> > > > Technologies, Inc. 
> > > > Technical Lead Network Design, Consulting, IT 
> > 
> > > > Outsourcing 
> > > > james@towardex.com Boston-based Colocation & 
> > > Bandwidth 
> > > > Services 
> > > > cell: 1(978)-394-2867 web: http://www.towardex.com 
> > > , noc: 
> > > > www.twdx.net 
> > > > 
> > > > 
> > > 
> > 
> _______________________________________________________________________ 
> > > > Please help support GroupStudy by purchasing your study materials 
> > > from: 
> > > > http://shop.groupstudy.com 
> > > > 
> > > > Subscription information may be found at: 
> > > > http://www.groupstudy.com/list/CCIELab.html 
> > > 
> > > > 
> > > > 
> > > 
> > 
> _______________________________________________________________________ 
> > > > Please help support GroupStudy by purchasing your study materials 
> > > from: 
> > > > http://shop.groupstudy.com 
> > > > 
> > > > Subscription information may be found at: 
> > > > http://www.groupstudy.com/list/CCIELab.html 
> > > 
> > > > 
> > > > 
> > > > 
> > ********************************************************************** 
> 
> > > > Any opinions expressed in the email are those of the individual 
> and 
> > > not 
> > > > necessarily the company. This email and any files transmitted with 
> 
> > it 
> > > are 
> > > > confidential and solely for the use of the intended recipient. If 
> > you 
> > > are not 
> > > > the intended recipient or the person responsible for delivering it 
> 
> > to 
> > > the 
> > > > intended recipient, be advised that you have received this email 
> in 
> > > error and 
> > > > that any dissemination, distribution, copying or use is strictly 
> > > prohibited. 
> > > > 
> > > > If you have received this email in error, or if you are concerned 
> > with 
> > > the 
> > > > content of this email please e-mail to: 
> > e-security.support@vanco.info 
> > > > 
> > > > The contents of an attachment to this e-mail may contain software 
> > > viruses 
> > > > which could damage your own computer system. While the sender has 
> > > taken every 
> > > > reasonable precaution to minimise this risk, we cannot accept 
> > > liability for 
> > > > any damage which you sustain as a result of software viruses. You 
> > > should carry 
> > > > out your own virus checks before opening any attachments to this 
> > > e-mail. 
> > > > 
> > ********************************************************************** 
> 
> > > > 
> > > > 
> > > 
> > 
> _______________________________________________________________________ 
> > > > Please help support GroupStudy by purchasing your study materials 
> > > from: 
> > > > http://shop.groupstudy.com 
> > > > 
> > > > Subscription information may be found at: 
> > > > http://www.groupstudy.com/list/CCIELab.html 
> > > 
> > > -- 
> > > James Jun TowardEX 
> > > Technologies, Inc. 
> > > Technical Lead Network Design, Consulting, IT 
> > > Outsourcing 
> > > james@towardex.com Boston-based Colocation & 
> > Bandwidth 
> > > Services 
> > > cell: 1(978)-394-2867 web: http://www.towardex.com 
> > > , noc: 
> > > www.twdx.net 
> > > 
> > 
> _______________________________________________________________________ 
> > > Please help support GroupStudy by purchasing your study materials 
> > from: 
> > > http://shop.groupstudy.com 
> > > Subscription information may be found at: 
> > > http://www.groupstudy.com/list/CCIELab.html 
> > > 
> > 
> > -- 
> > James Jun TowardEX 
> > Technologies, Inc. 
> > Technical Lead Network Design, Consulting, IT 
> > Outsourcing 
> > james@towardex.com Boston-based Colocation & Bandwidth 
> > Services 
> > cell: 1(978)-394-2867 web: http://www.towardex.com , noc: 
> > www.twdx.net 
> > 
> > 
> _______________________________________________________________________ 
> > Please help support GroupStudy by purchasing your study materials 
> from: 
> > http://shop.groupstudy.com 
> > 
> > Subscription information may be found at: 
> > http://www.groupstudy.com/list/CCIELab.html 
> > 
> > 
> _______________________________________________________________________ 
> > Please help support GroupStudy by purchasing your study materials 
> from: 
> > http://shop.groupstudy.com 
> > 
> > Subscription information may be found at: 
> > http://www.groupstudy.com/list/CCIELab.html 
> 
> _______________________________________________________________________ 
> Please help support GroupStudy by purchasing your study materials from: 
> http://shop.groupstudy.com 
> 
> Subscription information may be found at: 
> http://www.groupstudy.com/list/CCIELab.html 
> 
> _______________________________________________________________________ 
> Please help support GroupStudy by purchasing your study materials from: 
> http://shop.groupstudy.com 
> 
> Subscription information may be found at: 
> http://www.groupstudy.com/list/CCIELab.html 
This archive was generated by hypermail 2.1.4 : Fri Oct 01 2004 - 15:00:40 GMT-3