From: Narbik Kocharians (narbikk@gmail.com)
Date: Tue Sep 04 2007 - 16:31:01 ART
Scott you used the wrong AS number (666)
On 9/4/07, Scott Morris <smorris@ipexpert.com> wrote:
>
> Should work....
>
> Configure a pretend BB router:
>
> R2(config)#router bgp 666
> R2(config-router)#network 140.101.2.0 mask 255.255.255.0
> R2(config-router)#neighbor 140.101.36.1 remote-as 100
> R2(config-router)#
>
>
> Configure your router:
>
> R1(config)#router bgp 100
> R1(config-router)#network 140.101.1.0 mask 255.255.255.0
> R1(config-router)#neighbor 140.101.36.2 remote-as 200
> R1(config-router)#
>
> You don't know the peer's AS, so pick any number (200)
>
> *Sep 4 19:30:37.719: %BGP-3-NOTIFICATION: sent to neighbor 140.101.36.22/2
> (peer in wrong AS) 2 bytes 029A
> R1(config-router)# FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 029A
> 00B4 8C65 0202 1002 0601 0400 0100 0102 0280 0002 0202 00
> R1(config-router)#
>
> Now, look at "029A" in hex... You'll find it's '666' which is what we
> configured the BB router as.
> If you were looking at the message on the BB router, it would show its own
> ASN.
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI-M/JNCI-J
> VP - Technical Training - IPexpert, Inc.
> IPexpert Sr. Technical Instructor
>
> A Cisco Learning Partner - We Accept Learning Credits!
>
> smorris@ipexpert.com
>
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> http://www.ipexpert.com
>
>
> -----Original Message-----
> From: Cecil Wilson [mailto:Cecil.Wilson@flextronics.com]
> Sent: Tuesday, September 04, 2007 2:46 PM
> To: smorris@ipexpert.com; Greg Wendel
> Cc: Joseph Brunner; NET HE; bit.gossip@chello.nl; ccielab@groupstudy.com
> Subject: RE: EBGP AS mispatch
>
> Scott
> when I tried this, the hex number converted to the AS number on my side
> of the peer. Am I reading it wrong, maybe missing one part?
>
> Thanks, Cecil
>
>
>
> Cecil G. Wilson
> IT Network Services
> Office: (901) 215-2710
> Cell: (901) 601-6201
> cecil.wilson@flextronics.com
>
>
> -----Original Message-----
> From: Scott Morris [mailto:smorris@ipexpert.com]
> Sent: Tuesday, September 04, 2007 1:12 PM
> To: 'Greg Wendel'; Cecil Wilson
> Cc: 'Joseph Brunner'; 'NET HE'; bit.gossip@chello.nl;
> ccielab@groupstudy.com
> Subject: RE: EBGP AS mispatch
>
> In the message that you get when you setup a peer (pick an AS you want),
> it
> will tell you peer in wrong AS:
>
> R2(config-router)#
> *Jul 28 13:28:25.977: %BGP-3-NOTIFICATION: sent to neighbor
> 140.101.68.13
> 2/2 (peer in wrong AS) 2 bytes 2864
>
> That last part there (2864) is a hex number. Convert that with Windows
> calculator and you'll find that the remote AS (in this instance) is
> AS10340.
>
> So it gives it to you automagically!
>
> HTH,
>
>
> Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
> #153, CISSP, et al.
> CCSI/JNCI-M/JNCI-J
> VP - Technical Training - IPexpert, Inc.
> IPexpert Sr. Technical Instructor
>
> A Cisco Learning Partner - We Accept Learning Credits!
>
> smorris@ipexpert.com
>
> Telephone: +1.810.326.1444
> Fax: +1.810.454.0130
> http://www.ipexpert.com
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Greg
> Wendel
> Sent: Tuesday, September 04, 2007 1:23 PM
> To: Cecil Wilson
> Cc: Joseph Brunner; NET HE; bit.gossip@chello.nl; ccielab@groupstudy.com
> Subject: Re: EBGP AS mispatch
>
> There are interesting discussions on this in the archives, but I am pretty
> sure the general consensus is that there is no way to get this
> information.
>
> On 9/4/07, Cecil Wilson <Cecil.Wilson@flextronics.com> wrote:
> >
> > Hi GS
> >
> >
> >
> > - is the EBGP AS peers are mismatch you wil get a message that
> >
> > includes a hex code, this code is the AS on the near side
> >
> > What can I use to tell me what the AS is on the far side(peer) if
>
> > I
> >
> > don't know.
> >
> > Are there anyway to tell?
> >
> >
> >
> > Cecil G. Wilson
> >
> > IT Network Services
> >
> > Office: (901) 215-2710
> >
> > Cell: (901) 601-6201
> >
> > cecil.wilson@flextronics.com
> >
> >
> >
> >
> >
> > -----Original Message-----
> >
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> >
> > Joseph Brunner
> >
> > Sent: Thursday, August 30, 2007 10:22 PM
> >
> > To: 'NET HE'; bit.gossip@chello.nl; ccielab@groupstudy.com
> >
> > Subject: RE: nasty redistribution
> >
> >
> >
> > Xin He;
> >
> >
> >
> > I use tagging to prevent route feedback. This will happen when you are
> >
> > re-distributing one protocol into another in at least two places and
> > the
> >
> > RECEIVING protocol (like OSPF/RIP) doesn't have a build in mechanism
> > to
> >
> > detect inferior redistributed routes (EIGRP does this pretty well by
> >
> > default, with EX = 170).
> >
> >
> >
> > I use "distance xxx source ACL" when a single path must be preferred
> >
> > which supersedes what the redistribution decided was the best path on
> >
> > its own, and the task wont let us touch cost, bandwidth, etc.
> >
> >
> >
> > Also you will find yourself touch distance often when preferring two
> >
> > routes (and two sources) from the same protocol (i.e. two ospf paths
> > to
> >
> > 123.0.1.0/24, etc.)
> >
> >
> >
> > If you find you are stuck on redistribution, DRAW it OUT. THINK like
> >
> > each router at EACH hop. Consider all information available at each
> > hop,
> >
> > prefix length, AD, Metric, and as you pointed out, order of learning
> > the
> >
> > route (what will be in the routing table when the redistribution
> > command
> >
> > looks for the routes to redistribute)
> >
> >
> >
> > -Joe
> >
> >
> >
> > -----Original Message-----
> >
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> >
> > NET HE
> >
> > Sent: Thursday, August 30, 2007 10:24 PM
> >
> > To: bit.gossip@chello.nl; ccielab@groupstudy.com
> >
> > Subject: RE: nasty redistribution
> >
> >
> >
> > Hi,
> >
> >
> >
> > I was under the same inpression as well. I was always using tagging to
> >
> > prevent routing loop it there were multiple redistrition points
> > between
> >
> > 2 routing domains. Recently I found a solution, but inputs from group
> >
> > are very
> >
> >
> >
> > appreciated.
> >
> >
> >
> > Since CCIE lab is small, it's very easy to know th biggest metric in a
> >
> > routing domain, for example, maximum hops in a rip domain, minimum
> >
> > bandwidth
> >
> >
> >
> > and biggest acummulated delay in eigrp domain, and biggest acummulated
> >
> > cost in ospf domain. I would put that biggest metric as default-metric
> >
> > under the routing protocol. When routes are redistributed from another
> >
> > routing domain,
> >
> >
> >
> > all those routes will have the biggest metric at that redistribution
> >
> > point.
> >
> > This would simply prevent any routing loop without any tagging.
> >
> >
> >
> >
> >
> > Best Regards,
> >
> > Net (Xin) He
> >
> >
> >
> > >
> >
> > >Group,
> >
> > >so far I was under the impression that I could tackle every scenario
> > >of
> >
> >
> >
> > >simple and mutual redistribution by tagging and filtering at
> >
> > >redistribution points.
> >
> > >So I focused and practiced a lot to become proficient and familiar
> > >with
> >
> >
> >
> > >this technique.
> >
> > >Until the simple scenario that I describe below shattered all my
> >
> > >confidence and pushed me back to square 0 :-( Tagging and filtering
> > >is
> >
> > >not enough: in some cases it doesn't work; in some cases admin
> >
> > >disctance must be manipulated.
> >
> > >
> >
> > >The problem with this simple network is the redistribution of R7 lo0
> >
> > >170.1.7.7
> >
> > >from RIP to OSPF via 2 distribution points: R5 and R6. In normal
> >
> > >condition the network is stable in the following status:
> >
> > >- either R5 or R6, whoever is faster, redistributes 170.1.7.7 from
> > >RIP
> >
> > >to OSPF; let's assume R6 is faster
> >
> > >- R6 will redistribute 150.1.7.7 into OSPF and keep the original RIP
> >
> > >route in its routing table R6#show ip route | i 170.1.7.7
> >
> > >R 170.1.7.7/32 [120/1] via 170.1.200.7, 00:00:23,
> FastEthernet0/0
> >
> > >
> >
> > >- R5 instead learns 170.1.7.7 via OSPF so that the OSPF route
> >
> > >overwrites the RIP route due to better admin distance R5#show ip
> > >route
> >
> > >| i 170.1.7.7
> >
> > >O E2 170.1.7.7/32 [110/20] via 170.1.100.9, 00:17:30, Serial1/0.1
> >
> > >
> >
> > >- the tagging that I put in place prevents the route from
> >
> > ricirculating:
> >
> > >the
> >
> > >network is perfectly stable, even if maybe routing is not optimal but
> >
> > >who cares now.....
> >
> > >
> >
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > >
> >
> > >The fun starts if I shutdown the OSPF session between R5 and R2, for
> >
> > >instance putting passive one interface long enogh for R5 to re-learn
> >
> > >the route via RIP from R7. At this point, if we reestablish OSPF,
> > >both
> >
> > >R5 and R6 try to redistribute the route from RIP to OSPF and
> > >170.1.7.7
> >
> > >ping-pongs for ever between R5 and R6.
> >
> > >
> >
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > >
> >
> > >The first nasty thing here is that I would have not spotted this
> >
> > >condition at the real lab because in normal condition the network is
> >
> > >stable and even after a reload the network comes up stable. Only what
>
> > >I
> >
> >
> >
> > >described above can trigger the instability.
> >
> > >The second nasty thing is that now I am back to the original
> question:
> >
> > >when should I use tagging? When admin-distance? When both?
> >
> > >In this case I guess both are needed!
> >
> > >
> >
> > >The reason why I tried to avoid manipulating admin distance so far is
> >
> > >the
> >
> > >following:
> >
> > >
> >
> > >Let's say that to solve the instability here I increase the admin
> >
> > >distance of OSPF external to 121: the problem of 170.1.7.7 is solved
> >
> > >because both R5 and
> >
> > >R6 will prefer the RIP route and only R2 will see the O E2 But while
> > >I
> >
> > >solved the problem in the direction RIP -> OPSF, now I have create
> > >the
> >
> > >same potential problem in the opposite direction; so, if R2 were to
> >
> > >redistribute its loopback as connected, I am exactly in the same
> >
> > >situation as I was at the beginning but in a mirrored form. I have
> > >not
> >
> > >solved the problem but just thrown in over the fence !
> >
> > >
> >
> > >I think that the only way out here is to increase the admin distance
> >
> > >only of specific selected routes when redistributed; in this case
> > >only
> >
> > >170.1.7.7 shold be changed from O E2 [110/20] to O E2 [121/20]
> >
> > >
> >
> > >Am I completely out of track?
> >
> > >PS: sorry for the long post!
> >
> > >
> >
> > >
> >
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > >
> >
> > > _____ R5 _|
> >
> > > / | rip
> >
> > > / |
> >
> > > / |
> >
> > >R2(ospf) |--- R7 - lo0 170.1.7.7
> >
> > > \ |
> >
> > > \ |
> >
> > > \_____ R6 _ |
> >
> > >
> >
> > >
> >
> > >~~~~~~~~
> >
> > >
> >
> > >hostname R2
> >
> > >!
> >
> > >interface Serial1/0
> >
> > > no ip address
> >
> > > encapsulation frame-relay
> >
> > > serial restart-delay 0
> >
> > > no frame-relay inverse-arp
> >
> > >!
> >
> > >interface Serial1/0.5 point-to-point
> >
> > > ip address 170.1.100.9 255.255.255.252
> >
> > > frame-relay interface-dlci 205
> >
> > >!
> >
> > >interface Serial1/0.6 point-to-point
> >
> > > ip address 170.1.100.13 255.255.255.252
> >
> > > frame-relay interface-dlci 206
> >
> > >!
> >
> > >router ospf 1
> >
> > > log-adjacency-changes
> >
> > > network 170.1.100.0 0.0.0.255 area 0
> >
> > >
> >
> > >~~~~~~~~
> >
> > >
> >
> > >hostname R5
> >
> > >!
> >
> > >interface FastEthernet0/0
> >
> > > ip address 170.1.200.5 255.255.255.224
> >
> > > duplex full
> >
> > >!
> >
> > >interface Serial1/0
> >
> > > no ip address
> >
> > > encapsulation frame-relay
> >
> > > serial restart-delay 0
> >
> > > no frame-relay inverse-arp
> >
> > >!
> >
> > >interface Serial1/0.1 point-to-point
> >
> > > ip address 170.1.100.10 255.255.255.252
> >
> > > frame-relay interface-dlci 502
> >
> > >!
> >
> > >router ospf 1
> >
> > > log-adjacency-changes
> >
> > > redistribute rip subnets route-map RO
> >
> > > network 170.1.100.0 0.0.0.255 area 0
> >
> > >!
> >
> > >router rip
> >
> > > version 2
> >
> > > redistribute ospf 1 metric 2 route-map OR
> >
> > > passive-interface default
> >
> > > no passive-interface FastEthernet0/0
> >
> > > network 170.1.0.0
> >
> > > no auto-summary
> >
> > >!
> >
> > >route-map RO deny 10
> >
> > > match tag 96 115 116 125 126
> >
> > >!
> >
> > >route-map RO permit 20
> >
> > > set tag 125
> >
> > >!
> >
> > >route-map OR deny 10
> >
> > > match tag 96 115 116 125 126
> >
> > >!
> >
> > >route-map OR permit 20
> >
> > > set tag 115
> >
> > >
> >
> > >~~~~~~~~~~
> >
> > >
> >
> > >hostname R6
> >
> > >!
> >
> > >interface FastEthernet0/0
> >
> > > ip address 170.1.200.6 255.255.255.224
> >
> > > duplex full
> >
> > >!
> >
> > >interface Serial1/0
> >
> > > no ip address
> >
> > > encapsulation frame-relay
> >
> > > serial restart-delay 0
> >
> > > no frame-relay inverse-arp
> >
> > >!
> >
> > >interface Serial1/0.1 point-to-point
> >
> > > ip address 170.1.100.14 255.255.255.252
> >
> > > frame-relay interface-dlci 602
> >
> > >!
> >
> > >router ospf 1
> >
> > > log-adjacency-changes
> >
> > > redistribute rip subnets route-map FROM-RIP
> >
> > > network 170.1.100.0 0.0.0.255 area 0
> >
> > >!
> >
> > >router rip
> >
> > > version 2
> >
> > > redistribute ospf 1 metric 2 route-map FROM-OSPF
> >
> > > passive-interface default
> >
> > > no passive-interface FastEthernet0/0
> >
> > > network 170.1.0.0
> >
> > > no auto-summary
> >
> > >!
> >
> > >no ip http server
> >
> > >no ip http secure-server
> >
> > >!
> >
> > >!
> >
> > >!
> >
> > >logging alarm informational
> >
> > >!
> >
> > >!
> >
> > >!
> >
> > >route-map FROM-OSPF deny 10
> >
> > > match tag 96 115 116 125 126
> >
> > >!
> >
> > >route-map FROM-OSPF permit 20
> >
> > > set tag 116
> >
> > >!
> >
> > >route-map FROM-RIP deny 10
> >
> > > match tag 96 115 116 125 126
> >
> > >!
> >
> > >route-map FROM-RIP permit 20
> >
> > > set tag 126
> >
> > >!
> >
> > >~~~~~~~~~
> >
> > >
> >
> > >hostname R7
> >
> > >!
> >
> > >interface Loopback0
> >
> > > ip address 170.1.7.7 255.255.255.255
> >
> > >!
> >
> > >interface FastEthernet0/0
> >
> > > ip address 170.1.200.7 255.255.255.224
> >
> > > duplex full
> >
> > >!
> >
> > >router rip
> >
> > > version 2
> >
> > > network 170.1.0.0
> >
> > > no auto-summary
> >
> > >!
> >
> > >~~~~~~~~~~~
> >
> > >R5#debug ip routing
> >
> > >IP routing debugging is on
> >
> > >R5(config-router)#passive-interface s1/0.1 R5(config-router)# *Aug 30
> >
> > >21:07:49.147: %OSPF-5-ADJCHG: Process 1, Nbr 170.1.100.13 on
> >
> > >Serial1/0.1 from FULL to DOWN, Neighbor Down: Interface down or
> >
> > >detached *Aug 30 21:07:54.651: RT: del 170.1.100.12/30 via
> > >170.1.100.9,
> >
> >
> >
> > >ospf metric [110/128] *Aug 30 21:07:54.655: RT: delete subnet route
> > >to
> >
> > >170.1.100.12/30 *Aug 30 21:07:54.659: RT: NET-RED 170.1.100.12/30
> > >*Aug
> >
> > >30 21:07:54.667: RT: del 170.1.7.7/32 via 170.1.100.9, ospf metric
> >
> > >[110/20] *Aug 30 21:07:54.671: RT: delete subnet route to
> > >170.1.7.7/32
> >
> > >*Aug 30 21:07:54.675: RT: NET-RED 170.1.7.7/32 R5(config-router)#
> >
> > >R5(config-router)# *Aug 30 21:08:07.395: RT: add 170.1.100.12/30 via
> >
> > >170.1.200.6, rip metric [120/1] *Aug 30 21:08:07.399: RT: NET-RED
> >
> > >170.1.100.12/30
> >
> > >R5(config-router)#no passive-interface s1/0.1 <<<<<<<<<<< let's
> the
> >
> > show
> >
> > >begin !
> >
> > >R5(config-router)#
> >
> > >*Aug 30 21:08:18.071: %OSPF-5-ADJCHG: Process 1, Nbr 170.1.100.13 on
> >
> > >Serial1/0.1 from LOADING to FULL, Loading Done *Aug 30 21:08:18.363:
> >
> > >RT: add 170.1.7.7/32 via 170.1.200.7, rip metric [120/1] *Aug 30
> >
> > >21:08:18.367: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.111: RT:
> > >closer
> >
> >
> >
> > >admin distance for 170.1.100.12, flushing
> >
> > >1
> >
> > >routes
> >
> > >*Aug 30 21:08:33.115: RT: NET-RED 170.1.100.12/30 *Aug 30
> 21:08:33.119:
> >
> >
> >
> > >RT: add 170.1.100.12/30 via 170.1.100.9, ospf metric [110/128] *Aug
> > >30
> >
> > >21:08:33.123: RT: NET-RED 170.1.100.12/30 *Aug 30 21:08:33.127: RT:
> >
> > >closer admin distance for 170.1.7.7, flushing 1 routes *Aug 30
> >
> > >21:08:33.127: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.127: RT: add
> >
> > >170.1.7.7/32 via 170.1.100.9, ospf metric [110/20] *Aug 30
> >
> > >21:08:33.127: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:33.279: RT: del
> >
> > >170.1.7.7/32 via 170.1.100.9, ospf metric [110/20] *Aug 30
> >
> > >21:08:33.279: RT: delete subnet route to 170.1.7.7/32 *Aug 30
> >
> > >21:08:33.279: RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:45.515: RT: add
> >
> > >170.1.7.7/32 via 170.1.200.7, rip metric [120/1] *Aug 30
> 21:08:45.519:
> >
> > >RT: NET-RED 170.1.7.7/32 *Aug 30 21:08:45.615: RT: closer admin
> >
> > >distance for 170.1.7.7, flushing 1 routes *Aug 30 21:08:45.615: RT:
> >
> > >NET-RED 170.1.7.7/32 *Aug 30 21:08:45.615: RT: add 170.1.7.7/32 via
> >
> > >170.1.100.9, ospf metric [110/20] *Aug 30 21:08:45.619: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:08:50.751: RT: del 170.1.7.7/32 via
> >
> > >170.1.100.9, ospf metric [110/20] *Aug 30 21:08:50.751: RT: delete
> >
> > >subnet route to 170.1.7.7/32 *Aug 30 21:08:50.751: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:14.455: RT: add 170.1.7.7/32 via
> >
> > >170.1.200.7, rip metric [120/1] *Aug 30 21:09:14.459: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:14.599: RT: closer admin distance for
> >
> > >170.1.7.7, flushing 1 routes *Aug 30 21:09:14.603: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:14.607: RT: add 170.1.7.7/32 via
> >
> > >170.1.100.9, ospf metric [110/20] *Aug 30 21:09:14.611: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:19.699: RT: del 170.1.7.7/32 via
> >
> > >170.1.100.9, ospf metric [110/20] *Aug 30 21:09:19.699: RT: delete
> >
> > >subnet route to 170.1.7.7/32 *Aug 30 21:09:19.699: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:43.395: RT: add 170.1.7.7/32 via
> >
> > >170.1.200.7, rip metric [120/1] *Aug 30 21:09:43.399: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:43.527: RT: closer admin distance for
> >
> > >170.1.7.7, flushing 1 routes *Aug 30 21:09:43.531: RT: NET-RED
> >
> > >170.1.7.7/32 *Aug 30 21:09:43.535: RT: add 170.1.7.7/32 via
> >
> > >170.1.100.9, ospf metric [110/20] *Aug 30 21:09:43.539: RT: NET-RED
> >
> > >170.1.7.7/32
> >
> > >
> >
> > >_____________________________________________________________________
> > >__
> >
> > >Subscription information may be found at:
> >
> > >http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> > _________________________________________________________________
> >
> > Get Cultured With Arts & Culture Festivals On Live Maps
> >
> > http://local.live.com/?mkt=en-ca&v=2&cid=A6D6BDB4586E357F!2010&encType
> > =1
> >
> > &sty
> >
> > le=h&FORM=SERNEP
> >
> >
> >
> > ______________________________________________________________________
> > _
> >
> > Subscription information may be found at:
> >
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> > ______________________________________________________________________
> > _
> >
> > Subscription information may be found at:
> >
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> > Legal Disclaimer:
> >
> > The information contained in this message may be privileged and
> > confidential. It is intended to be read only by the individual or
> > entity to whom it is addressed or by their designee. If the reader of
> > this message is not the intended recipient, you are on notice that any
>
> > distribution of this message, in any form, is strictly prohibited. If
> > you have received this message in error, please immediately notify the
>
> > sender and delete or destroy any copy of this message
> >
> > ______________________________________________________________________
> > _ Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
>
>
> --
> Gregory Wendel
> Springfield VA, 22153
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Narbik Kocharians CCIE# 12410 (R&S, SP, Security) CCSI# 30832 www.Net-WorkBooks.com
This archive was generated by hypermail 2.1.4 : Sat Oct 06 2007 - 12:01:09 ART