From: Narbik Kocharians (narbikk@gmail.com)
Date: Sat Jun 28 2008 - 18:02:07 ART
Ha ha ha ha
Tarun and others,
Please, let's understand that the RFCs and what you and your mate/s stated
in your posts is read by every one and I mean at all levels, CCNP, CCIP etc.
and i find them to be very basic. Please understand what you read sometimes
does NOT jive with the real world implementation and I think that is what is
lacking here, "practical experience". Fortunately or unfortunately I HAVE
and I still do bunch of work (Teaching and/or consulting) for few major
providers, let me explain things a little more clearer may be every one of
you guys will see it:
RRs will ONLY advertise the best route, and thank god for that, I think
knowledge 101 tells me that this provides redundancy.
There are few forms of RR clustering and they are as follows:
- 2 or more RRs operating in the same cluster, in this case the clients
are members of a single cluster.
- A client is a member of multiple clusters, in this case if the RR
fails, the client/s can get their update through another cluster.
Now let's look at the following 2 scenarios, and I am sure there are others
but I like to bring only two of them to your attention:
Let's say there are 2 route-reflectors, RR-1 and RR-2, RR-1 has a peer
session with RR-2 and there are two RR clients, C1 and C2.
C1 has two peer sessions one to RR-1 and another to RR-2
C2 also has two peer sessions, one to RR-1 and another to RR-2
Let's say the links are all working fine and the route-reflectors are in the
same cluster:
C1 gets an update from another source, it will advertise that update to RR-1
and RR-2, and *both route reflectors will advertise the update to C2*, the
route reflectors will also send the same update to each other, BUT because
the cluster-id in the update received by one route reflector is identical to
its own, it will discard the update.
Let's say that the following links or BGP sessions are down, may be they are
connected to the same switch or the same provider device or what ever the
reason:
C1's link/BGP session to RR-2 and C2's link/BGP session to RR-1 are down.
C1 gets the same update and it advertises that route to RR-1, C1 can NOT
advertise that route to RR-2 because the session/link is down and when RR-1
advertises that update to RR-2, RR-2 rejects the route because they have the
same cluster-id.
As a result of this, half of the routers in the same cluster are NOT going
to have the update.
Now let's configure the RR-1 and RR-2 in different clusters or NOT configure
cluster-ids on the route reflectors, which means the cluster-ids will be
different because the router-ids are different:
When RR-1 advertises that update to RR-2, RR-2 will accept the update and it
will process it, because the cluster-ids DO NOT match.
*I think this provides a better redundancy.*
Let me give you another scenario why sometimes you need to see the real
networks and NOT what your CCIE lab asked you to do:
C1 has a peer session with RR-1 and another with RR-2, RR-1 has a peer
session with RR-2. C2 also has two peer sessions, one with RR-1 and
another with RR-2, in the following topology:
C1
RR-1 RR-2
C2
C1 has two BGP paths to the destinations advertised by C2, one through RR-1
and another through RR-2.
Let's say that C1 load shares the packets using both IGP paths.
The IBGP session between RR-2 and C2 goes down.
In this case RR-1 continues to forward traffic whereas, the traffic through
RR-2 is discarded, even though the link between RR-2 and C2 is still UP.
I know that RFC or other documentations do not mention every possible
scenario, but logic and basic knowledge tells me that 50% of the packets
will be dropped.
Now let's configure the 2 route reflectors in different clusters or NOT
configure cluster-ids at all, which means that the 2 Route reflectors will
be in 2 different clusters:
RR-2 will still continue to forward traffic because the update is also
learned through RR-1.
*Now without mentioning RFCs and copying and pasting an old link, DON'T YOU
THINK THAT THIS WILL PROVIDE A LOGICAL AND PHYSICAL
REDUNDANCY????????????????????????????????????*
But YEH man, we have more memory consumption. As far as I know as a CCIE and
an architecture designer/consultant and more importantly as an instructor my
responsibility is to teach the theory plus what's real. Have a chat with the
architecture designers of some of the providers and you will see what its
all about.
On Sat, Jun 28, 2008 at 1:18 PM, Luan Nguyen <luan.m.nguyen@gmail.com>
wrote:
> Good blogging materials :) I'll blog this RR thingy.
> I can say that the way on of the biggest ISP does thing is using RRs within
> a cluster with same Cluster ID...peering using loopbacks ofcourse.
> Each cluster is a subAS-confederation and fully meshed with others in
> different clusters. They themselves are just iBGP peers within the
> cluster.
> Don't quote me on this though :)
>
> -Luan
>
>
> On Sat, Jun 28, 2008 at 6:40 AM, Tarun Pahuja <pahujat@gmail.com> wrote:
>
> > There are Plenty of RFC revolving around route reflectors. Lets Just
> > summarize the concept for ease of understanding. If one method is
> preferred
> > over the other in the industry their must be a reason for it ;-)
> >
> > *Router Reflectors with in a cluster with same Cluster-ID*
> > 1) Loop prevention using Cluster-list and Originator-ID concept.
> > 2) One Path from each Route Reflector client.
> > 3) 100% redundancy difficult to accomplish. ( using loopbacks you can get
> > close to 100%).
> > 4) comparatively less memory and cpu Utilization.
> >
> > *Router Reflector with in a Cluster with different Cluster-ID*
> > 1) One Path from Router Reflector Client and one path from Route
> Reflector
> > (
> > you just doubled the size of your bgp table!, Hence more memory
> > consumption).
> > 2) You can achive 100% redundancy.
> > 3) BGP has to do more work as it has 2 paths for each prefix, hence more
> > CPU
> > Utilization.
> >
> > As you can see it all depends on the design and what the customer
> > expectations are:
> > 1) Does he want 100% redundant RR design or close to 100% using loopbacks
> > would be fine?
> > 2) Do his routers have enough power(memory and CPU) to accommodate 2 next
> > hops for the same prefix?
> > 3) Budget limitations.
> >
> > Since today's ISPs are running Voice,Video and Data majority of the ISP's
> > do
> > not want to take any chances with a RR design which is less than 100%
> > redundant. Moreover, Routers have become much more faster which are
> capable
> > of accommodating much more routes and processing them faster than their
> > predecessor.
> >
> > HTH,
> > Tarun
> >
> >
> >
> > On 6/28/08, Narbik Kocharians <narbikk@gmail.com> wrote:
> > >
> > > I agree, but if you look at the design within most if not all ISPs you
> > will
> > > NEVER see redundant RRs configured, you will see that a client is a
> > client
> > > in couple of clusters (Different ones). The identical cluster-id is no
> > > longer in practise. Without getting into word games no one practises
> that
> > > RFC.
> > >
> > > On Fri, Jun 27, 2008 at 11:07 PM, Anthony Faria <tfaria72@gmail.com>
> > > wrote:
> > >
> > > > Be afraid very afraid. Petr Is an endless wealth of knowledge.
> > > >
> > > > Tony
> > > >
> > > > On Fri, Jun 27, 2008 at 9:41 PM, Joseph Brunner <
> > joe@affirmedsystems.com
> > > >
> > > > wrote:
> > > >
> > > > > Petr,
> > > > >
> > > > > Are the proctor's afraid of you yet?
> > > > >
> > > > > LOL
> > > > >
> > > > > -Joe
> > > > > (up soon in SJ)
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
> Behalf
> > > Of
> > > > > Petr
> > > > > Lapukhov
> > > > > Sent: Saturday, June 28, 2008 12:38 AM
> > > > > To: Marc La Porte; Brian McGahan; netplusca@rogers.com; Cisco
> > > > > certification
> > > > > Subject: Re: the relation between the route-reflector servers
> within
> > > the
> > > > > same bgp cluster id?
> > > > >
> > > > > Just to make it more clear,
> > > > >
> > > > > per RFC 4456:
> > > > >
> > > > > <rfc>
> > > > >
> > > > > Usually, a cluster of clients will have a single RR. In that
> case,
> > > > >
> > > > > the cluster will be identified by the BGP Identifier of the RR.
> > > > >
> > > > > However, this represents a single point of failure so to make it
> > > > >
> > > > > possible to have multiple RRs in the same cluster, all RRs in the
> > > > >
> > > > > same cluster can be configured with a 4-byte CLUSTER_ID so that
> an
> > RR
> > > > >
> > > > > can discard routes from other RRs in the same cluster.
> > > > >
> > > > > </rfc>
> > > > >
> > > > > OK, so let's hold here for a second. What is an RR cluster? A group
> > of
> > > > > fully
> > > > > meshed RRs with the *same* cluster ID. That is, if they are on the
> > same
> > > > > cluster, they should have the same Cluster ID, otherwise the
> > definition
> > > > > makes no sense. Of course, we usually think of clusters from the
> > > > "peering"
> > > > > perspective, but the ID is what makes the definition strict. To
> > > > summarize:
> > > > > strictly speaking, configuring RRs with different cluster-IDs puts
> > them
> > > > > into
> > > > > *separate* RR clusters.
> > > > >
> > > > > As for BGP route distribution redundancy. It's kind of a tricky,
> > > > > "CCDE-level" question ;). Should RRC (RR Clients) peer with RRs in
> > the
> > > > same
> > > > > cluster (same cluster-ID) or with RRs in different clusters? Narbik
> > > > > demostrated a classic example of what happens when you have RRC
> > peering
> > > > > with
> > > > > redundant RRs in the same cluster. However, even in this case, the
> > > > > situation
> > > > > is not so serious if you deal with a real-life scenario. This is
> due
> > to
> > > > the
> > > > > fact that iBGP peerings are usually sourced off Loopbacks, and
> > > therefore
> > > > > massive peering failures should not happen often. On the contrary
> > side,
> > > a
> > > > > drawback of "redundant peering with RRC in different clusters"
> > > approach,
> > > > > one
> > > > > can point out excessive routing information stored on RRs, due to
> the
> > > > fact
> > > > > that they don't discard it based on CLUSTER_ID.
> > > > >
> > > > > Here is a nice Cisco presentation being held on RIPE session back
> in
> > > > days,
> > > > > which discusses the questions mentioned above:
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/sld02
> > > > > 0.html<
> > > >
> > >
> >
> http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-eof-bgp/sld020.html
> > > > >
> > > > >
> > > > > HTH
> > > > > --
> > > > > Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice)
> > > > > petr@internetworkexpert.com
> > > > >
> > > > > Internetwork Expert, Inc.
> > > > > http://www.InternetworkExpert.com
> > http://www.internetworkexpert.com/>
> > > > > 2008/6/28 Narbik Kocharians <narbikk@gmail.com>:
> > > > >
> > > > > > If anyone needs the topology i will attach it so you will see
> what
> > i
> > > am
> > > > > > talking about. Marc, Look at the attached topology that i just
> sent
> > > > you:
> > > > > > When C2 receives an update, it sends the update to RR-1 and RR-2.
> > > RR-2
> > > > > will
> > > > > > set the cluster-id in the update and send the update to RR-1, RR1
> > > will
> > > > > > reject the update because it sees that the cluster-ids in the
> > update
> > > > > match
> > > > > > its own.
> > > > > > Now Let's say the link between C2 and RR-1 and C1 and RR-2 goes
> > down,
> > > > > now,
> > > > > > C2 gets the update and it sends it to RR-1 and RR-2, RR-2 sets
> the
> > > > > > cluster-id and sends it to RR-1, and RR-1 will reject the update
> > > > because
> > > > > it
> > > > > > will see its own cluster-id in the update.
> > > > > > Note half of the cluster has no idea about the update.
> > > > > >
> > > > > > But if they had different cluster-ids RR-1 will process the
> update
> > > and
> > > > > send
> > > > > > it to C1.
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 27, 2008 at 11:29 AM, Marc La Porte <
> > > > > marc.a.laporte@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Narbik,
> > > > > > >
> > > > > > > Why's that?
> > > > > > >
> > > > > > > Marc
> > > > > > >
> > > > > > > On Fri, Jun 27, 2008 at 7:49 PM, Narbik Kocharians <
> > > > narbikk@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Basically the cluster-ids should NOT match when you have
> > redundant
> > > > > > >> route-reflectors, for the CCIE lab, you should make sure that
> > they
> > > > do,
> > > > > > but
> > > > > > >> NOT in the real world scenario.
> > > > > > >>
> > > > > > >> On Fri, Jun 27, 2008 at 10:30 AM, Brian McGahan <
> > > > > > >> bmcgahan@internetworkexpert.com> wrote:
> > > > > > >>
> > > > > > >> > Hi Mohamed,
> > > > > > >> >
> > > > > > >> > The BGP router-id comes from the highest loopback
> address,
> > or
> > > > if
> > > > > > >> > there is no loopback, your highest interface IP address.
> The
> > > > > > cluster-id
> > > > > > >> > comes from the router-id. In a real design you would always
> > > want
> > > > to
> > > > > > >> > hard code at least the BGP router-id, and possibly the
> > > cluster-id
> > > > > > >> > depending on the design. There are certain designs that if
> > your
> > > > BGP
> > > > > > >> > router-id overlaps with someone else's there could be a
> > problem,
> > > > > such
> > > > > > as
> > > > > > >> > if you're doing Anycast RP for multicast. As a general rule
> > > OSPF,
> > > > > > >> > EIGRP, and BGP router-id's should always be hardcoded. In
> the
> > > lab
> > > > > > exam
> > > > > > >> > if there isn't a requirement *not* to hardcode them, you
> > should
> > > > set
> > > > > it
> > > > > > >> > to a unique IP address configured on the router.
> > > > > > >> >
> > > > > > >> > HTH,
> > > > > > >> >
> > > > > > >> > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > > > > >> > bmcgahan@internetworkexpert.com <mailto:
> > > > > > bmcgahan@internetworkexpert.com
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > Internetwork Expert, Inc.
> > > > > > >> > http://www.InternetworkExpert.com
> <
> > > http://www.internetworkexpert.com/><
> > > > > http://www.internetworkexpert.com/
> > > > > > >
> > > > > > >>
> > > > > > >> > Toll Free: 877-224-8987 x 705
> > > > > > >> > Outside US: 775-826-4344 x 705
> > > > > > >> > 24/7 Support: http://forum.internetworkexpert.com
> > > > > > >> > Live Chat: http://www.internetworkexpert.com/chat/
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > Net Plus wrote:
> > > > > > >> > > Hi Brian,
> > > > > > >> > >
> > > > > > >> > > It means;
> > > > > > >> > >
> > > > > > >> > > Once you set the bgp Router-id, You don't need any
> > Cluster-id,
> > > > As
> > > > > > per
> > > > > > >> > your
> > > > > > >> > > statement, bgp cluster-id is derived from Router-id.
> > > > > > >> > >
> > > > > > >> > > Regards,
> > > > > > >> > >
> > > > > > >> > > Mohamed.
> > > > > > >> > > -----Original Message-----
> > > > > > >> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com
> > ]On
> > > > > Behalf
> > > > > > >> Of
> > > > > > >> > > Brian McGahan
> > > > > > >> > > Sent: Friday, June 27, 2008 9:55 AM
> > > > > > >> > > To: cciestruggle; Cisco certification
> > > > > > >> > > Subject: Re: the relation between the route-reflector
> > servers
> > > > > within
> > > > > > >> the
> > > > > > >> > > same bgp cluster id?
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > You should statically set the BGP router ID to a globally
> > > > > > significant
> > > > > > >> > > address on the router. The cluster-ID is inherited from
> > > > router-id
> > > > > > >> > > regardless if you hardcode it or the router-id though.
> > > > > > >> > >
> > > > > > >> > > Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > > > > >> > > bmcgahan@internetworkexpert.com <mailto:
> > > > > > >> bmcgahan@internetworkexpert.com>
> > > > > > >> > >
> > > > > > >> > > Internetwork Expert, Inc.
> > > > > > >> > > http://www.InternetworkExpert.com
> <
> > > http://www.internetworkexpert.com/><
> > > > > > http://www.internetworkexpert.com/
> > > > > > >> >
> > > > > > >>
> > > > > > >> > > Toll Free: 877-224-8987 x 705
> > > > > > >> > > Outside US: 775-826-4344 x 705
> > > > > > >> > > 24/7 Support: http://forum.internetworkexpert.com
> > > > > > >> > > Live Chat: http://www.internetworkexpert.com/chat/
> > > > > > >> > >
> > > > > > >> > > cciestruggle wrote:
> > > > > > >> > >
> > > > > > >> > >> Hello Brain,
> > > > > > >> > >>
> > > > > > >> > >> We do need to have the cluster id on the router
> reflectors
> > to
> > > > > avoid
> > > > > > >> > >> loops ? right?
> > > > > > >> > >>
> > > > > > >> > >> And further more do we need to explicitly specify the
> > cluster
> > > > id?
> > > > > > the
> > > > > > >> > >> command reference says that it is automatically set to
> the
> > > > local
> > > > > > >> > >> router id (of which reflector ?)
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp1.html#
> > > > > > >> > > wp1012377
> > > > > > >> > >
> > > > > > >> > >> Zealot
> > > > > > >> > >>
> > > > > > >> > >> On Fri, Jun 27, 2008 at 3:52 PM, Brian McGahan
> > > > > > >> > >> <bmcgahan@internetworkexpert.com
> > > > > > >> > >> <mailto:bmcgahan@internetworkexpert.com>> wrote:
> > > > > > >> > >>
> > > > > > >> > >> You can, but you don't necessarily have to. Most
> large
> > > > scale
> > > > > > >> route
> > > > > > >> > >> reflection designs include a full mesh of peerings
> > > between
> > > > > > >> > >> clusters via
> > > > > > >> > >> the route reflectors, but the route reflectors are
> not
> > > > > clients
> > > > > > of
> > > > > > >> > each
> > > > > > >> > >> other. This means that if reflector A peers with
> > > reflector
> > > > > B,
> > > > > > >> and
> > > > > > >> > >> reflector B peers with reflector C, reflector C
> cannot
> > > > learn
> > > > > a
> > > > > > >> route
> > > > > > >> > >> from reflector A's cluster through B's cluster,
> because
> > > if
> > > > A
> > > > > is
> > > > > > a
> > > > > > >> > >> non-client of B, B cannot advertise an iBGP route
> from
> > A
> > > to
> > > > > C.
> > > > > > >> > >> However
> > > > > > >> > >> if these is a full mesh of non-client iBGP peerings
> > > between
> > > > > A,
> > > > > > B,
> > > > > > >> > >> and C,
> > > > > > >> > >> reflector C wouldn't need to use B to get to A, since
> > it
> > > > has
> > > > > a
> > > > > > >> > direct
> > > > > > >> > >> peering.
> > > > > > >> > >>
> > > > > > >> > >> Ultimately for production it depends on your
> redundancy
> > > > > design.
> > > > > > >> > >> Technically you can have every single router be a
> > router
> > > > > > >> reflector
> > > > > > >> > >> with
> > > > > > >> > >> everyone else beings its clients. You won't cause
> any
> > > > > routing
> > > > > > >> > loops,
> > > > > > >> > >> since the cluster list prevents this, but instead
> > you'll
> > > > just
> > > > > > >> have
> > > > > > >> > >> a lot
> > > > > > >> > >> of unnecessary route replication. However when we
> are
> > > > > talking
> > > > > > >> about
> > > > > > >> > >> update messages in the order of 300,000 routes for
> the
> > > full
> > > > > BGP
> > > > > > >> > table,
> > > > > > >> > >> scalability from a resource management perspective is
> > > > highly
> > > > > > >> > >> affected by
> > > > > > >> > >> route reflection design.
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >> HTH,
> > > > > > >> > >>
> > > > > > >> > >> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > > > > > >> > >> bmcgahan@internetworkexpert.com
> > > > > > >> > >> <mailto:bmcgahan@internetworkexpert.com>
> > > > > > >> > >> <mailto:bmcgahan@internetworkexpert.com
> > > > > > >> > >> <mailto:bmcgahan@internetworkexpert.com>>
> > > > > > >> > >>
> > > > > > >> > >> Internetwork Expert, Inc.
> > > > > > >> > >> http://www.InternetworkExpert.com
> <
> > > http://www.internetworkexpert.com/>
> > > > <
> > > > > > >> http://www.internetworkexpert.com/>
> > > > > > >>
> > > > > > >> > >> Toll Free: 877-224-8987 x 705
> > > > > > >> > >> Outside US: 775-826-4344 x 705
> > > > > > >> > >> 24/7 Support: http://forum.internetworkexpert.com
> > > > > > >> > >> Live Chat: http://www.internetworkexpert.com/chat/
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >> ccie wrote:
> > > > > > >> > >> > Hi experts,
> > > > > > >> > >> >
> > > > > > >> > >> > Assume I have 5 router within the same AS, and two
> of
> > > > them
> > > > > > will
> > > > > > >> > >> have IBGP
> > > > > > >> > >> > peer with the rest, So I configure these two with
> the
> > > > same
> > > > > > bgp
> > > > > > >> > >> cluster-id,
> > > > > > >> > >> > and configure the rest to be their
> > > > route-reflector-clients.
> > > > > > >> Should
> > > > > > >> > I
> > > > > > >> > >> > configure these two to be route-reflector-clients
> to
> > > each
> > > > > > >> > others!!!
> > > > > > >> > >> >
> > > > > > >> > >> > Thanks in advance
> > > > > > >> > >> >
> > > > > > >> > >> > Amin
> > > > > > >> > >> >
> > > > > > >> > >> >
> > > > > > >> > >> >
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >>
> > > > >
> > _______________________________________________________________________
> > > > > > >> > >
> > > > > > >> > >> > 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
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > > --
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >>
> > > > >
> > _______________________________________________________________________
> > > > > > >> > > Subscription information may be found at:
> > > > > > >> > > http://www.groupstudy.com/list/CCIELab.html
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > __________ NOD32 3223 (20080627) Information __________
> > > > > > >> > >
> > > > > > >> > > This message was checked by NOD32 antivirus system.
> > > > > > >> > > http://www.eset.com
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > >
> > > _______________________________________________________________________
> > > > > > >> > Subscription information may be found at:
> > > > > > >> > http://www.groupstudy.com/list/CCIELab.html
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Narbik Kocharians
> > > > > > >> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> > > > > > >> www.Net-Workbooks.com <http://www.net-workbooks.com/> <
> http://www.net-workbooks.com/>
> > > > > > >> Sr. Technical Instructor
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > >
> > _______________________________________________________________________
> > > > > > >> Subscription information may be found at:
> > > > > > >> http://www.groupstudy.com/list/CCIELab.html
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Narbik Kocharians
> > > > > > CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> > > > > > www.Net-Workbooks.com <http://www.net-workbooks.com/> <
> http://www.net-workbooks.com/>
> > > > > > Sr. Technical Instructor
> > > > > >
> > > > > >
> > > > > >
> > > _______________________________________________________________________
> > > > > > 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
> > > > >
> > > > >
> > > > >
> > _______________________________________________________________________
> > > > > 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
> > > CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> > > www.Net-Workbooks.com <http://www.net-workbooks.com/>
> > > Sr. Technical Instructor
> > >
> > >
> > > _______________________________________________________________________
> > > 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
>
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
-- Narbik Kocharians CCSI#30832, CCIE# 12410 (R&S, SP, Security) www.Net-Workbooks.com Sr. Technical Instructor
This archive was generated by hypermail 2.1.4 : Tue Jul 01 2008 - 06:23:23 ART