Re: RIP Timers

You have it black on wight from Cisco debug ip rip output, you can try it .

But Don't wast your time you may change your mind by mistake:-).

On Mon, Mar 22, 2010 at 4:05 PM, Cristian Matei
<cristian.matei_at_datanets.ro>wrote:

> Hi Shiran/mate,
>
>
>
> Youre wrong again (HOLDDOWN timer is NOT used when direct
> failures happen; so in your case when the link between R1 and R3 goes down,
> without any switch between, the network will converge instantly and R3 will
> accept the new path with higher metric through R2).
>
> When the link between R1 and R3 is down, since RIP is
> enabled over that link, both R1 and R3 will remove all prefixes known from
> RIP through those interfaces; basically as soon as R3 receives the regular
> update from R2 it will add 10.1.150.0/24 in its RT through R2; youre
> doing something wrong there.
>
>
>
> I can test it and prove that, but its a loss of time to
> me.
>
>
>
> Regards,
> Cristian.
>
>
>
>
>
> *From:* shiran guez [mailto:shiranp3_at_gmail.com]
> *Sent:* Monday, March 22, 2010 1:19 PM
>
> *To:* cristian.matei_at_datanets.ro
> *Cc:* Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> tosara_at_gmail.com
> *Subject:* Re: RIP Timers
>
>
>
> Mate, don't give up :-)
>
>
>
> Topology realy simple
>
>
>
> 3 Routers each with 2 FastEthernet full mash no switchs
>
>
>
> The Advertising router R1 have a loopback interface with network *
> 10.0.150.0/24 (see diagram)*
>
>
>
> illustration diagram
>
> R1
>
> / \
>
> / \
>
> R2----R3
>
>
>
> once you shut the interface from R1 to R3
>
> R3 will get the *10.0.150.0/24 from R2 with higher metric*
>
> *As it has already a lower metric and he didn't receive an update from R1
> he will start count the holddown timer.*
>
>
>
> *at the end of the timer he will update the table with the higher metric.
> if he would received an update from R1 directly during that time the
counter
> would be terminated.*
>
>
>
>
>
> *The invalidate Timer is different (but you can try now in your own
> setup), instead of shutting down the interface between R1 to R3 just remove
> the loopback interface what R1 will do he will multicast a poison route to
> 10.0.150.0/24 by sending the network with metric 16.... come on do the lab
> and see the rest yourself*
>
>
>
> On Mon, Mar 22, 2010 at 12:27 PM, Cristian Matei <
> cristian.matei_at_datanets.ro> wrote:
>
> Hi Shiran,
>
>
>
> I can guarantee youre wrong here; if you could just let me
> know the exact topology youre using here.
>
> One thing: if routers are directly connected than how is Fa0/0 still up, if
> you terminated the interface on the other end; or by terminating you mean
> you removed it from the RIP process with passive?
>
>
>
>
>
> Of course, if u dont want to continue you can live on with this assumption
> J
>
> 10.0.0.0/24 is subnetted, 4 subnets
>
> R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:03, FastEthernet1/0
>
> C 10.0.0.0 is directly connected, FastEthernet0/0
>
> C 10.0.1.0 is directly connected, FastEthernet1/0
>
> *R 10.0.150.0 [120/2] via 10.0.1.2, 00:00:03, FastEthernet1/0*
>
>
>
> Regards,
>
> Cristian.
>
>
>
> *From:* shiran guez [mailto:shiranp3_at_gmail.com]
> *Sent:* Monday, March 22, 2010 11:57 AM
>
>
> *To:* cristian.matei_at_datanets.ro
> *Cc:* Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> tosara_at_gmail.com
> *Subject:* Re: RIP Timers
>
>
>
> no cristian it is not due to Invalidate timer, that is the holddown and
> they are not connected through a switch they are directly connected.
>
>
>
> I think this ping pong is going on too long, you can keep on argue on that
> but I choose now to back off as I do not see any benefit from
> this discussion.
>
>
>
> Have a good day :-)
>
> On Mon, Mar 22, 2010 at 11:11 AM, Cristian Matei <
> cristian.matei_at_datanets.ro> wrote:
>
> Hi Shiran,
>
>
>
> I believe routers are NOT directly connected but through a
> switch, correct?
>
>
>
> What youre seeing below happening is due to the INVALID timer and NOT the
> holddown timer.
>
>
>
> *Mar 1 00:11:29.471: RIP: build flash update entries
>
>
> *Mar 1 00:11:29.471: 10.0.150.0/24 via 0.0.0.0, metric 16, tag 0 *<<
> holddown timer ended ~180 sec*
>
> *Mar 1 00:11:33.819: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:11:33.823: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:11:33.827: 10.0.150.0/24 via 0.0.0.0 in 2 hops
> * << updating Table*
>
>
>
>
>
> Regards,
>
> Cristian.
>
>
>
> *From:* shiran guez [mailto:shiranp3_at_gmail.com]
> *Sent:* Monday, March 22, 2010 10:29 AM
>
>
> *To:* cristian.matei_at_datanets.ro
> *Cc:* Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> tosara_at_gmail.com
> *Subject:* Re: RIP Timers
>
>
>
> and just to add to that:
>
>
>
> ########### BEFORE notice to route *10.0.150.0/24 installed with metric 1*
>
> *Gateway of last resort is not set*
>
> * *
>
> * 10.0.0.0/24 is subnetted, 4 subnets*
>
> *R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:12, FastEthernet1/0*
>
> * [120/1] via 10.0.0.2, 00:00:14, FastEthernet0/0*
>
> *C 10.0.0.0 is directly connected, FastEthernet0/0 *
>
> *C 10.0.1.0 is directly connected, FastEthernet1/0 *
>
> *R 10.0.150.0 [120/1] via 10.0.0.2, 00:00:02, FastEthernet0/0*
>
> * *
>
> *Mar 1 00:07:53.527: RIP: received v2 update from 10.0.0.2 on
> FastEthernet0/0
>
> *Mar 1 00:07:53.531: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> **Mar 1 00:07:53.535: 10.0.150.0/24 via 0.0.0.0 in 1 hops *
>
>
> *Mar 1 00:07:54.267: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:07:54.271: RIP: build update entries
>
>
> *Mar 1 00:07:54.271: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> ########### "Suddenly" I terminated interface one of the interfaces on
> router
>
> *10.0.0.2 making him advertise the network trough a diffrent interface and
> causing a "suddent" increase in metric to 10.0.150.0/24 now lets count
> together*
>
> *Mar 1 00:07:54.523: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:07:54.527: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:07:54.531: 10.0.150.0/24 via 0.0.0.0 in *2 hops*
>
>
> *Mar 1 00:07:55.175: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:07:55.179: RIP: build update entries
>
>
> *Mar 1 00:07:55.179: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> *Mar 1 00:07:55.183: 10.0.150.0/24 via 0.0.0.0, metric 2, tag 0
>
>
> *Mar 1 00:08:19.039: RIP: received v2 update from 10.0.0.2 on
> FastEthernet0/0
>
> *Mar 1 00:08:19.043: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:08:19.047: 10.0.150.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:08:21.531: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:08:21.531: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:08:21.531: 10.0.150.0/24 via 0.0.0.0 in 2 hops
>
>
> *Mar 1 00:08:21.783: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:08:21.787: RIP: build update entries
>
>
> *Mar 1 00:08:21.787: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> *Mar 1 00:08:21.791: 10.0.150.0/24 via 0.0.0.0, metric 2, tag 0
>
>
> *Mar 1 00:08:24.107: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:08:24.111: RIP: build update entries
>
>
> *Mar 1 00:08:24.111: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> R0#
>
>
> R0#
>
>
> R0#sh ip rou
>
>
> Codes: C - connected, S - static, 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
>
>
> i - IS-IS, su - IS-IS summary, 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
>
>
>
> 10.0.0.0/24 is subnetted, 4 subnets
>
> R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:18, FastEthernet1/0
>
> [120/1] via 10.0.0.2, 00:00:21, FastEthernet0/0
>
> C 10.0.0.0 is directly connected, FastEthernet0/0
>
> C 10.0.1.0 is directly connected, FastEthernet1/0
>
> R 10.0.150.0 [120/1] via 10.0.0.2, 00:00:21, FastEthernet0/0 *<<<
> notice that we do not change the route during the holddown timer*
>
> ....
>
> ....
>
> *Mar 1 00:11:29.471: RIP: build flash update entries
>
>
> *Mar 1 00:11:29.471: 10.0.150.0/24 via 0.0.0.0, metric 16, tag 0 *<<
> holddown timer ended ~180 sec*
>
> *Mar 1 00:11:33.819: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/0
>
> *Mar 1 00:11:33.823: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
>
> *Mar 1 00:11:33.827: 10.0.150.0/24 via 0.0.0.0 in 2 hops
> * << updating Table*
>
> *Mar 1 00:11:33.931: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:11:33.935: RIP: build update entries
>
>
> *Mar 1 00:11:33.935: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
>
> *Mar 1 00:11:35.831: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:11:35.835: RIP: build flash update entries
>
>
> *Mar 1 00:11:35.835: 10.0.150.0/24 via 0.0.0.0, metric 3, tag 0
>
>
> *Mar 1 00:11:35.839: RIP: sending v2 flash update to 224.0.0.9 via
> FastEthernet1/0 (10.0.1.1)
>
>
> *Mar 1 00:11:35.843: RIP: build flash update entries - suppressing null
> update
>
> *Mar 1 00:11:40.403: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet0/0 (10.0.0.1)
>
>
> *Mar 1 00:11:40.407: RIP: build update entries
>
> *Mar 1 00:11:40.407: 10.0.1.0/24 via 0.0.0.0, metric 1, tag 0
>
> *Mar 1 00:11:40.411: 10.0.2.0/24 via 0.0.0.0, metric 2, tag 0
>
> *Mar 1 00:11:40.411: 10.0.150.0/24 via 0.0.0.0, metric 3, tag 0
>
> *Mar 1 00:12:01.123: RIP: sending v2 update to 224.0.0.9 via
> FastEthernet1/00.0.1.1)
>
> *Mar 1 00:12:01.127: RIP: build update entries
>
> *Mar 1 00:12:01.127: 10.0.0.0/24 via 0.0.0.0, metric 1, tag 0
>
> *Mar 1 00:12:02.447: RIP: received v2 update from 10.0.1.2 on
> FastEthernet1/
>
> *Mar 1 00:12:02.451: 10.0.2.0/24 via 0.0.0.0 in 1 hops
>
> *Mar 1 00:12:02.451: 10.0.150.0/24 via 0.0.0.0 in 2 hopssh ip rip
> databou
>
> Codes: C - connected, S - static, 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
>
> i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
> level-2
>
> ia - IS-IS inter area, * - candidate default, U - per-user static
> rout
>
> o - ODR, P - periodic downloaded static route
>
>
>
> Gateway of last resort is not set
>
>
>
> 10.0.0.0/24 is subnetted, 4 subnets
>
> R 10.0.2.0 [120/1] via 10.0.1.2, 00:00:03, FastEthernet1/0
>
> C 10.0.0.0 is directly connected, FastEthernet0/0
>
> C 10.0.1.0 is directly connected, FastEthernet1/0
>
> *R 10.0.150.0 [120/2] via 10.0.1.2, 00:00:03, FastEthernet1/0*
>
> R0#
>
>
>
>
>
> On Mon, Mar 22, 2010 at 9:57 AM, shiran guez <shiranp3_at_gmail.com> wrote:
>
> Simplify, here is quate from a nice book i recommend
>
> *CCIE Professional Development Routing TCP/IP, Volume I, Second Edition
> By Jeff Doyle - CCIE No. 1919, Jennifer Carroll - CCIE No. 1402*
>
> "The third timer is the holddown timer, although RFC 1058 does not call for
> the use of holddowns. The Cisco implementation of RIP does use them. An
> update with a hop count higher than the metric recorded in the route table
> will cause the route to go into holddown for 180 seconds (again, six update
> periods)."
>
>
>
>
>
> On Mon, Mar 22, 2010 at 9:46 AM, Cristian Matei <
> cristian.matei_at_datanets.ro> wrote:
> > Hi Shiran,
> >
> > If you read my *book* you'll understand. Holddown timer NEVER
> kicks
> > in just when the metric for a prefix increases; maximum hop count of 15
> is
> > the protection for it.
> >
> > Regards,
> > Cristian.
> >
> > -----Original Message-----
> > From: shiran guez [mailto:shiranp3_at_gmail.com]
> > Sent: Monday, March 22, 2010 9:34 AM
> > To: cristian.matei_at_datanets.ro
> > Cc: Erwin van Harrewijn; kebramccie_at_gmail.com; ccielab_at_groupstudy.com;
> > tosara_at_gmail.com
> > Subject: Re: RIP Timers
> >
> > Hi Cristian
> >
> > Sorry I do not have the time to read your book bellow, but I think you
> > missed my point the basic rule is that when an update shows the metric
> > for an existing route to have increased sufficiently, there is a loop.
> > The route should be removed and put into holddown.
> >
> > Dont think there is a real need to get into the full story, and you
> > are correct as I said what is happening in Sarad scenario perfectly
> > normal.
> >
> >
> > On Sun, Mar 21, 2010 at 9:39 PM, Cristian Matei
> > <cristian.matei_at_datanets.ro> wrote:
> >> Hi Shiran,
> >>
> >> HOLDDOWN timer is NOT when you suddenly get a higher metric for
> an
> >> already installed route. See below my initial post on this thread. To
> >> quickly answer the question still, the problem you're seeing here is a
> >> normal behavior: basically RIP is NOT using holddown timer to converge
> in
> >> the case of direct "neighbor" failures. Read my post below, and if
> things
> >> are still unclear let me know where exactly.
> >>
> >> ####################################################
> >> Hi Sarad,
> >>
> >>
> >> First of all you're confusing the invalid timer with the hold down
> timer.
> >> Secondly , I believe we're speaking about RIPv1/v2 for IPv4 as RIPnG for
> >> IPv6 behaves a little bit differently. Now, each routing protocol needs
> to
> >> know how to converge in any of the 2 failure cases:
> >>
> >>
> >> 1. direct failures, meaning a prefix advertised inside the
> >> routing domain is down; here the router owning the prefix will start
> >> advertising this(depends on the routing protocol what exactly and how
> it's
> >> advertised) and all routers inside the routing domain need to converge
> > asap.
> >> 2. indirect failures, meaning a interconnect link between
> >> routers inside the routing domain is down (routing protocol runs over
> that
> >> interconnect), thus invalidating some prefixes; here each router needs a
> > way
> >> to determine that a "neighbor"/routing protocol speaker is not reachable
> > any
> >> longer, thus making some prefixes no longer reachable.
> >>
> >>
> >> RIP makes no difference and needs ways to converge in both cases.
> >>
> >> For the first case, the convergence is based on a combination of flash
> >> routing updates (known incorrectly as triggered updates) and
> > split-horizon,
> >> poison-reverse with split-horizon rules. Basically in this case the
> >> convergence is almost instant. So to detail a bit, in RIP when a prefix
> is
> >> down, the owner will advertise it as unreachable with metric 16; all the
> > RIP
> >> speakers receiving this will instantly remove the prefix from RT, send
> > flash
> >> updates on all RIP enabled interfaces for that prefix with a metric of
> 16;
> >> the prefix is no longer used for packet forwarding (as is no longer
> > present
> >> in the RT); RIP speakers (except the router that owned the prefix) will
> >> still keep the prefix in their databases and the prefix will be included
> > in
> >> the following regular updates (at each 30 second by default) for the
> >> FLUSH-INVALID amount of seconds (by default for 240-180=60 seconds which
> >> means 2 regular updates). Since the hold down timer is not used, any
> >> following update for that prefix, with any metric (lower or higher than
> > the
> >> initial one) is accepted by the RIP speakers. So here no timers are
> needed
> >> for RIP speakers to remove the unreachable prefix from RT; invalid and
> > flush
> >> timers are important for how long the prefix is kept in the RIP database
> > but
> >> NOT for RT convergence.
> >>
> >> For the second case, the convergence is based on INVALID timer, HOLD
> DOWN
> >> timer and FLUSH timer. When an update about a prefix is no longer
> received
> >> by a RIP speaker from the next-hop it has in its RT (so actually the RIP
> >> speaker that advertised the prefix) for as long as the INVALID timer
> this
> > is
> >> the point where the things start to happen; so first of all a router
> will
> >> still forward packets towards that destination, although unreachable for
> > 180
> >> seconds (the default INVALID timer); after the invalid timer reaches 0
> >> seconds, the prefix enters in the hold-down state (this means all
> updates
> >> about that prefix, regardless of having a lower or higher metric are
> >> ignored); the router will KEEP this time the prefix in the RT but in the
> >> "possibly down state" and in the RIP database as well in the same state
> >> (this means the router still uses that path for packet forwarding). Also
> > it
> >> will start advertising the prefix as unreachable on all enabled RIP
> >> interfaces by a flash update and following regular updates. The prefix
> > will
> >> remain in the hold down state for the minimum (HOLD DOWN timer, FLUSH
> > timer
> >> - INVALID timer); by default this means minimum (180,240-180)= minimum
> >> (180,60) means 60 seconds. After 60 seconds the router will remove the
> >> prefix from both RT and RIP database, stop advertising the prefix as
> >> unreachable and stop ignoring updates about that prefix (meaning at this
> >> point any updates about that prefix will be subject for the RT).
> >>
> >>
> >> Just for fun, another RIP topic which is unclear is the split-horizon.
> Lot
> >> of people "know" that if RIP receives an update about prefix
10.0.0.0/8on
> >> its Fa0/0 interface, the router will not send regular updates about
> >> 10.0.0.0/8 out that interface; this is somehow true but not entirely;
> the
> >> router will NOT send updates about 10.0.0.0/8 out on Fa0/0 ONLY and
> ONLY
> > if
> >> it prefers(puts in the RT) that route in order to reach
10.0.0.0/8prefix.
> >> For example if you have R1 that receives updates about 10.0.0.0/8 on
> Fa0/0
> >> with metric of 3 and about 10.0.0.0/8 on Fa0/1 with metric of 4, it
> will
> > put
> >> in the RT the one with metric 3. This means it will send regular RIP
> > updates
> >> about 10.0.0.0/8 out on Fa0/1 but NOT out on Fa0/0 which is its best
> path.
> >>
> >>
> >> I hope the post was not too long, but clear enough.
> >>
> >>
> >> ##################################################
> >>
> >> Regards,
> >> Cristian.
> >>
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> >> shiran guez
> >> Sent: Sunday, March 21, 2010 8:45 PM
> >> To: Erwin van Harrewijn
> >> Cc: kebramccie_at_gmail.com; ccielab_at_groupstudy.com; tosara_at_gmail.com
> >> Subject: Re: RIP Timers
> >>
> >> I think you are a little bit confused with the timers
> >>
> >> invalidate timer is when you didn't get a route update on a route that
> >> is in your table for ~180 sec (that is the status you are in)
> >> holdown timer is when suddenly you get a higher metric for an already
> >> installed route (lets say you have 1.1.1.0/24 with metric of 2 and
> >> suddenly you get that route with a metric of 3 then your router will
> >> start to count the hold down timer)
> >>
> >> between the invalidate and the flash timer if you receive an update
> >> for your route with a better metric your router immediately update the
> >> routing table and that is exactly what happened in your scenario
> >>
> >> hope that sort your mind a Little
> >>
> >>
> >> On Sun, Mar 21, 2010 at 8:30 PM, Erwin van Harrewijn <erwin_at_f1x0r.nl>
> > wrote:
> >>> Hi Shiran,
> >>>
> >>> I would have expected that the hold-down timer would have prevented
> >>> the newly learned route to the 1.1.1.0/24 network to be installed in
> >>> the routing table "already"
> >>> Since there is only 16 seconds between the moment the route was
> >>> invalidated and the newly learned route was received. The hold-down
> >>> timer could not have been expired yet.
> >>>
> >>> So why is that route installed in the routing-table?
> >>>
> >>> Thanks,
> >>> Erwin
> >>>
> >>
> >>
> >>
> >> --
> >> Shiran Guez
> >> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> >> http://cciep3.blogspot.com
> >> http://www.linkedin.com/in/cciep3
> >> http://twitter.com/cciep3
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Shiran Guez
> > MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> > http://cciep3.blogspot.com
> > http://www.linkedin.com/in/cciep3
> > http://twitter.com/cciep3
> >
> >
>
> --
>
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>
>
>
>
> --
> Shiran Guez
> MCSE CCNP NCE1 JNCIA-ER CCIE #20572
> http://cciep3.blogspot.com
> http://www.linkedin.com/in/cciep3
> http://twitter.com/cciep3
>

--
Shiran Guez
MCSE CCNP NCE1 JNCIA-ER CCIE #20572
http://cciep3.blogspot.com
http://www.linkedin.com/in/cciep3
http://twitter.com/cciep3
Blogs and organic groups at http://www.ccie.net