Re: dynamic vs static nat

Hi,
route-map with reversable command let the remote side access R1 once nat
translation was in the table:

ip nat pool POOL 192.168.200.1 192.168.200.254 prefix-length 24
ip nat inside source route-map NAT interface Serial0/0.12 overload
ip nat inside source route-map POLICY pool POOL reversible

think this allows the nat translationt stay in place longer / infinit
ip nat translation routemap-entry-timeout never/1000

On Tue, Jul 31, 2012 at 2:05 PM, ccie99999 <ccie99999_at_googlemail.com> wrote:

> Cool Peter and Carlos. Thanks a lot .
> I go back home and lab it up.
> For the traffic from R3 to R1 I guess I need an outside nat (traffic
> initiated from outside).
> Isn't?
> Il giorno 31/lug/2012 14:56, "peter dervan" <petesccie_at_gmail.com> ha
> scritto:
>
> > I edited the nat statements to include route-maps instead of list, as
> seen
> > below. Worked perfectly - pings to R2 loop are seen from overload nat
> > source, whereas pings to R3 loop are showing as coming from statically
> > natted source (192.168.200.0/24). Only one issue - I can't initiate the
> > traffec from R3 loop 0 towards the 192.168.200.0/24 network, so this
> will
> > only work as static nat one way from R1 towards R3. perhaps another NAT
> > setup on R3 towards to R1 would finish this policy off... It will respond
> > fine, but if i kick the traffic off ftom R3 instead - no joy. I have a
> > feeling this is working correctly - just a lack of understanding on my
> part
> > to the exact behaviour of this NAT...
> >
> > R1 - ping 192.168.2.2 rep 1 so lo 0
> >
> > R2 :
> > ICMP: echo reply sent, src 192.168.2.2, dst 10.1.12.1
> >
> > R1 - ping 192.168.3.3 rep 1 so lo 0
> >
> > R3
> > ICMP: echo reply sent, src 192.168.3.3, dst 192.168.200.1
> >
> >
> > same pings provided same results over and over.
> >
> > traffic initiated from R3 - reverse of above - gave following error:
> >
> > 000087: ICMP: echo reply sent, src 192.168.3.3, dst 192.168.200.1
> (//reply
> > from previous successful test)
> > R3#ping 192.168.200.1 source 192.168.3.3
> >
> > Type escape sequence to abort.
> > Sending 5, 100-byte ICMP Echos to 192.168.200.1, timeout is 2 seconds:
> > Packet sent with a source address of 192.168.3.3
> >
> > 000088: ICMP: time exceeded rcvd from 10.1.12.2.
> >
> >
> >
> >
> > On Tue, Jul 31, 2012 at 1:22 PM, ccie99999 <ccie99999_at_googlemail.com
> >wrote:
> >
> >> Peter,
> >>
> >> you're absolutely right!
> >>
> >> I've seen the behaviour at step 3 me too! (forgot to mention it)
> >>
> >> Carlos.. I ll lab your suggestion.
> >>
> >> I'll get back soon
> >>
> >> On Tue, Jul 31, 2012 at 11:58 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> >> >wrote:
> >>
> >> > Can you try putting a route-map to both nat statements ?
> >> > I.e. instead of just an ACL, a route-map that uses the ACL.
> >> > -Carlos
> >> >
> >> > peter dervan @ 31/07/2012 08:52 -0300 dixit:
> >> >
> >> > Hi,
> >> >> I labbed this up, and thought i had this working - but got some
> >> unexpected
> >> >> results. Maybe someone could shed some light on the following
> results?
> >> >> sorry if this is a little long!
> >> >>
> >> >> with the config below,
> >> >>
> >> >> 1) when i pinged R2 loop using R1 loop (this should be using overload
> >> nat)
> >> >> - this worked correctly. debugs (attached below) showed source as the
> >> >> overload interface - ALL GOOD
> >> >>
> >> >> 2) when i pinged the loop of R3 using R1 loop (should engage static
> >> policy
> >> >> nat using pool etc) - this worked correctly - source was showing from
> >> >> 192.168.200.1 instead of 192.168.1.1
> >> >>
> >> >> 3) when i repeated Step 1 - ping R2 loop from R1 loop (overload nat)
> -
> >> >> THIS
> >> >> NOW ENGAGED THE WRONG NAT POLICY - this showed source of
> 192.168.200.1,
> >> >> instead of previous source of serial0/0.12 (10.1.12.1)
> >> >>
> >> >> I'm fairly sure the nat translation below - which was not there
> before
> >> >> step
> >> >> 1, but was there after step 2, is the reason for this behaviour. Does
> >> the
> >> >> nat translation table not allow/account for the destination once
> there
> >> is
> >> >> a
> >> >> translation stored?? Any advice would be much appreciated!! (ps: ASA
> >> >> option of using a route-map to make it policy based is so mcuh
> easier!)
> >> >>
> >> >> Does anyone know if perhaps ip nat enable should be used??
> >> >>
> >> >>
> >> >> I set up the lab topoogy as:
> >> >> R1 ------------------------------**--> R2
> >> >> ------------------------------**-->
> >> >> R3
> >> >> (10.1.12.1) (10.1.12.2) (10.1.23.2)
> >> (10.1.23.3)
> >> >> Lo0: 192.168.1.1 Lo0: 192.168.2.2 Lo0:
> >> >> 192.168.3.3
> >> >>
> >> >> RIP running between all devices, a default route was put on R1 and R3
> >> >> pointing to R2, and R2 had static route to 192.168.200.0/24 to
> >> 10.1.12.1
> >> >> (going to be static natted address). This is all fine...
> >> >>
> >> >> The config of R1 (where the NAT is being performed) is as follows:
> >> >>
> >> >> access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
> >> >> //this is for the policy static nat - going to translate
> >> 192.168.1.0/24to
> >> >> 192.168.200/24
> >> >>
> >> >> access-list 150 deny ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255
> >> >> access-list 150 permit ip 192.168.1.0 0.0.0.255 any
> >> >> //access-list for nat overload,called within route-map for nat
> >> >>
> >> >> route-map NAT permit 10
> >> >> match ip address 150
> >> >> // route-map used in nat statement
> >> >>
> >> >> ip nat pool POOL 192.168.200.1 192.168.200.254 prefix-length 24
> >> >> ip nat inside source list 120 pool POOL
> >> >> ip nat inside source route-map NAT interface Serial0/0.12 overload
> >> >>
> >> >> interface Loopback0
> >> >> ip address 192.168.1.1 255.255.255.255
> >> >> ip nat inside
> >> >>
> >> >> interface Serial0/0.12 point-to-point
> >> >> ip address 10.1.12.1 255.255.255.0
> >> >> ip nat outside
> >> >> ip virtual-reassembly
> >> >> snmp trap link-status
> >> >> frame-relay interface-dlci 102
> >> >>
> >> >>
> >> >>
> >> >> DEBUGS AS FOLLOWS:
> >> >>
> >> >> #INITIAL PING FROM R1 LOOP TO R2 LOOP (OVERLOAD nat) - SUCCESSFUL
> >> >> R1#ping 192.168.2.2 rep 1 so lo 0
> >> >>
> >> >> Type escape sequence to abort.
> >> >> Sending 1, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
> >> >> Packet sent with a source address of 192.168.1.1
> >> >> !
> >> >> Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32
> ms
> >> >> R1#
> >> >> NAT: map match NAT
> >> >> NAT: [0] Allocated Port for 192.168.1.1 -> 10.1.12.1: wanted 16 got
> 16
> >> >> NAT: i: icmp (192.168.1.1, 16) -> (192.168.2.2, 16) [55]
> >> >> NAT: s=192.168.1.1->10.1.12.1, d=192.168.2.2 [55]
> >> >> NAT*: o: icmp (192.168.2.2, 16) -> (10.1.12.1, 16) [55]
> >> >> NAT*: s=192.168.2.2, d=10.1.12.1->192.168.1.1 [55]
> >> >> R1#
> >> >> R1#sh ip nat trans
> >> >> Pro Inside global Inside local Outside local Outside
> >> >> global
> >> >> icmp 10.1.12.1:16 192.168.1.1:16 192.168.2.2:16
> >> >> 192.168.2.2:16
> >> >>
> >> >>
> >> ==============================**==============================**========
> >> >> #INITIAL PING FROM R1 LOOP TO R3 LOOP (POLICY STATIC nat) -
> SUCCESSFUL
> >> >>
> >> >>
> >> >> R1#ping 192.168.3.3 rep 1 so lo 0
> >> >>
> >> >> Type escape sequence to abort.
> >> >> Sending 1, 100-byte ICMP Echos to 192.168.3.3, timeout is 2 seconds:
> >> >> Packet sent with a source address of 192.168.1.1
> >> >> !
> >> >> Success rate is 100 percent (1/1), round-trip min/avg/max = 52/52/52
> ms
> >> >> R1#
> >> >> NAT: i: icmp (192.168.1.1, 18) -> (192.168.3.3, 18) [57]
> >> >> NAT: s=192.168.1.1->192.168.200.1, d=192.168.3.3 [57]
> >> >> NAT*: o: icmp (192.168.3.3, 18) -> (192.168.200.1, 18) [57]
> >> >> NAT*: s=192.168.3.3, d=192.168.200.1->192.168.1.1 [57]
> >> >> R1#
> >> >> R1#sh ip nat tran
> >> >> R1#sh ip nat translations
> >> >> Pro Inside global Inside local Outside local Outside
> >> >> global
> >> >> icmp 10.1.12.1:17 192.168.1.1:17 192.168.2.2:17
> >> >> 192.168.2.2:17
> >> >> icmp 192.168.200.1:18 192.168.1.1:18 192.168.3.3:18
> >> >> 192.168.3.3:18
> >> >> --- 192.168.200.1 192.168.1.1 --- ---
> >> >>
> >> >>
> >> >>
> >> ==============================**==============================**========
> >> >>
> >> >> #SECOND PING FROM R1 LOOP TO R2 LOOP (OVERLOAD nat) - UNSUCCESSFUL
> >> >>
> >> >>
> >> >> R1#ping 192.168.2.2 rep 1 so lo 0
> >> >>
> >> >> Type escape sequence to abort.
> >> >> Sending 1, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
> >> >> Packet sent with a source address of 192.168.1.1
> >> >> !
> >> >> Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36
> ms
> >> >> R1#
> >> >> NAT: i: icmp (192.168.1.1, 19) -> (192.168.2.2, 19) [58]
> >> >> NAT: s=192.168.1.1->192.168.200.1, d=192.168.2.2 [58]
> >> >> NAT*: o: icmp (192.168.2.2, 19) -> (192.168.200.1, 19) [58]
> >> >> NAT*: s=192.168.2.2, d=192.168.200.1->192.168.1.1 [58]
> >> >> R1#
> >> >> R1#sh ip nat tra
> >> >> R1#sh ip nat translations
> >> >> Pro Inside global Inside local Outside local Outside
> >> >> global
> >> >> icmp 10.1.12.1:17 192.168.1.1:17 192.168.2.2:17
> >> >> 192.168.2.2:17
> >> >> icmp 192.168.200.1:18 192.168.1.1:18 192.168.3.3:18
> >> >> 192.168.3.3:18
> >> >> icmp 192.168.200.1:19 192.168.1.1:19 192.168.2.2:19
> >> >> 192.168.2.2:19
> >> >> --- 192.168.200.1 192.168.1.1 --- ---
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Jul 31, 2012 at 1:08 AM, ccie99999 <ccie99999_at_googlemail.com
> >
> >> >> wrote:
> >> >>
> >> >> thanks guys for your reply but still I don't get it..
> >> >>>
> >> >>> I'm here, this is the same situation I've:
> >> >>> https://supportforums.cisco.**com/thread/2043483<
> >> https://supportforums.cisco.com/thread/2043483>
> >> >>>
> >> >>> but after setting the static and the dynamic with the route-map I
> >> still
> >> >>> don't have a working solution.
> >> >>>
> >> >>> and googling this it looks like it's a common issue..
> >> >>>
> >> >>> checking some previous lab I did for my ccie I don't see this
> >> scenario.
> >> >>>
> >> >>> thanks again for your help
> >> >>>
> >> >>> On Mon, Jul 30, 2012 at 5:16 PM, Dan Shechter G <danshtr_at_gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>> Its a bit mess on IOS, but in general static route has precedence
> >> over
> >> >>>> dynamic NAT.
> >> >>>>
> >> >>>> you can use route map, but notice that route-maps in nat are
> >> evaluated
> >> >>>> be
> >> >>>> lexical order, which means that route-map 'rmA' will be evaluated
> >> before
> >> >>>> 'rmB'
> >> >>>>
> >> >>>> On 30 Jul 2012, at 17:19, ccie99999 wrote:
> >> >>>>
> >> >>>> yeah, nothing..
> >> >>>>>
> >> >>>>> overload works but not static nat..
> >> >>>>> even after a clear ip nat tran * , a ping to the remote net + a
> >> show ip
> >> >>>>>
> >> >>>> nat
> >> >>>>
> >> >>>>> translat and I don't see the static nat..
> >> >>>>>
> >> >>>>> :(
> >> >>>>>
> >> >>>>> On Mon, Jul 30, 2012 at 2:04 PM, peter dervan <
> petesccie_at_gmail.com>
> >> >>>>>
> >> >>>> wrote:
> >> >>>>
> >> >>>>>
> >> >>>>> Hi,
> >> >>>>>> Try something like this, been a while since i labbed this so
> can't
> >> >>>>>> remember if it will do proper 1 to 1 static network nat or
> not...
> >> >>>>>>
> >> >>>>>> ==============================**=======================
> >> >>>>>>
> >> >>>>>> access-list 120 permit ip 192.168.1.0 0.0.0.255 10.10.0.0
> >> 0.1.255.255
> >> >>>>>>
> >> >>>>>> ip nat pool OVERLAPPING 192.168.200.1 192.168.200.254
> >> prefix-length 24
> >> >>>>>>
> >> >>>>>> ip nat inside source list 120 pool OVERLAPPING
> >> >>>>>>
> >> >>>>>> ==============================**=======================
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> On Mon, Jul 30, 2012 at 2:41 PM, ccie99999 <
> >> ccie99999_at_googlemail.com
> >> >>>>>>
> >> >>>>> wrote:
> >> >>>>>
> >> >>>>>>
> >> >>>>>> Hi Peter,
> >> >>>>>>>
> >> >>>>>>> thanks for your help.
> >> >>>>>>>
> >> >>>>>>> I've tried what you've suggested and it looks it's working (the
> >> >>>>>>>
> >> >>>>>> static
> >> >>>
> >> >>>> is
> >> >>>>
> >> >>>>> not taking the precedence on the dynamic one)
> >> >>>>>>>
> >> >>>>>>> unluckily the static nat is not working..
> >> >>>>>>>
> >> >>>>>>> this is my basic nat stuff:
> >> >>>>>>>
> >> >>>>>>> (note: net 192.168.1.x must become 192.168.200.x with the static
> >> nat
> >> >>>>>>>
> >> >>>>>> and
> >> >>>>
> >> >>>>> talk to 10.10.0.0)
> >> >>>>>>>
> >> >>>>>>> route-map NAT permit 10
> >> >>>>>>> match ip address 101
> >> >>>>>>>
> >> >>>>>>> access-list 101 permit ip 192.168.200.0 0.0.0.255 10.10.0.0
> >> >>>>>>>
> >> >>>>>> 0.1.255.255
> >> >>>
> >> >>>> access-list 101 permit ip 192.168.1.0 0.0.0.255 10.10.0.0
> 0.1.255.255
> >> >>>>>>>
> >> >>>>>>> ip nat pool OVERLAPPING 192.168.200.1 192.168.200.254 pref 24
> >> >>>>>>>
> >> >>>>>>> ip nat inside source route-map NAT pool OVERLAPPING
> >> >>>>>>>
> >> >>>>>>> ######
> >> >>>>>>>
> >> >>>>>>> ip nat inside source list 100 interface Dialer0 overload
> >> >>>>>>>
> >> >>>>>>> access-list 100 deny ip 192.168.1.0 0.0.0.255 10.10.0.0
> >> 0.1.255.255
> >> >>>>>>> access-list 100 deny ip 192.168.200.0 0.0.0.255 10.10.0.0
> >> >>>>>>>
> >> >>>>>> 0.1.255.255
> >> >>>
> >> >>>> access-list 100 permit ip 192.168.1.0 0.0.0.255 any
> >> >>>>>>>
> >> >>>>>>> thaaaanks again.
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> On Mon, Jul 30, 2012 at 12:29 PM, Peter Dervan <
> >> petesccie_at_gmail.com>
> >> >>>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>> Try making the static nat policy based, using a nat pool and
> >> route
> >> >>>>>>>>
> >> >>>>>>> map.
> >> >>>>
> >> >>>>> Policy would allow static nat to kick in only when traffic is
> >> >>>>>>>>
> >> >>>>>>> destined
> >> >>>
> >> >>>> to a
> >> >>>>>>>
> >> >>>>>>>> particular destination - should fix your issue.
> >> >>>>>>>>
> >> >>>>>>>> Sent from my iPhone
> >> >>>>>>>>
> >> >>>>>>>> On 30 Jul 2012, at 13:14, ccie99999 <ccie99999_at_googlemail.com>
> >> >>>>>>>>
> >> >>>>>>> wrote:
> >> >>>
> >> >>>>
> >> >>>>>>>> Hi guys,
> >> >>>>>>>>>
> >> >>>>>>>>> I feel a bit frustrated because of this simple issue:
> >> >>>>>>>>>
> >> >>>>>>>>> I've got to do a static nat and a dynamic one with the
> overload.
> >> >>>>>>>>>
> >> >>>>>>>>> the static one is for translating my entire lan to a specific
> >> net
> >> >>>>>>>>>
> >> >>>>>>>> (because
> >> >>>>>>>>
> >> >>>>>>>>> of overlapping over ipsec).
> >> >>>>>>>>>
> >> >>>>>>>>> the dynamic one with overload is for surfing the web.
> >> >>>>>>>>>
> >> >>>>>>>>> As soon as I set up the static nat the customer looses the
> >> access
> >> >>>>>>>>>
> >> >>>>>>>> to
> >> >>>
> >> >>>> internet (the dynamic one stop to work).
> >> >>>>>>>>>
> >> >>>>>>>>> I know that a static route has precedence over a dynamic but
> >> I've
> >> >>>>>>>>>
> >> >>>>>>>> set
> >> >>>
> >> >>>> up
> >> >>>>>>>
> >> >>>>>>>> a
> >> >>>>>>>>
> >> >>>>>>>>> specific acl:
> >> >>>>>>>>>
> >> >>>>>>>>> this is my conf:
> >> >>>>>>>>>
> >> >>>>>>>>> NAT:
> >> >>>>>>>>> ip nat inside source list 100 interface Dialer0 overload
> >> >>>>>>>>> ip nat inside source static network 192.168.1.0 192.168.200.0
> >> /24
> >> >>>>>>>>>
> >> >>>>>>>>> ACL:
> >> >>>>>>>>> access-list 100 deny ip 192.168.1.0 0.0.0.255 10.10.0.0
> >> >>>>>>>>>
> >> >>>>>>>> 0.1.255.255
> >> >>>
> >> >>>> access-list 100 deny ip 192.168.200.0 0.0.0.255 10.10.0.0
> >> >>>>>>>>>
> >> >>>>>>>> 0.1.255.255
> >> >>>>>>>
> >> >>>>>>>> access-list 100 permit ip 192.168.1.0 0.0.0.255 any
> >> >>>>>>>>>
> >> >>>>>>>>> I've even tried to use a route-map within the dynamic nat but
> >> still
> >> >>>>>>>>>
> >> >>>>>>>> doesn't
> >> >>>>>>>>
> >> >>>>>>>>> work..
> >> >>>>>>>>>
> >> >>>>>>>>> where am I wrong?
> >> >>>>>>>>>
> >> >>>>>>>>> thanks in advance
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> --
> >> >>>>>>>>> ccie99999
> >> >>>>>>>>> twitter: @ccie99999
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>> Blogs and organic groups at http://www.ccie.net
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>
> ______________________________**______________________________**
> >> >>> ___________
> >> >>>
> >> >>>> Subscription information may be found at:
> >> >>>>>>>>> http://www.groupstudy.com/**list/CCIELab.html<
> >> http://www.groupstudy.com/list/CCIELab.html>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>>
> >> >>>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> --
> >> >>>>>>> ccie99999
> >> >>>>>>> twitter: @ccie99999
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> Blogs and organic groups at http://www.ccie.net
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> ______________________________**______________________________**
> >> >>> ___________
> >> >>>
> >> >>>> Subscription information may be found at:
> >> >>>>>>> http://www.groupstudy.com/**list/CCIELab.html<
> >> http://www.groupstudy.com/list/CCIELab.html>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>>> --
> >> >>>>> ccie99999
> >> >>>>> twitter: @ccie99999
> >> >>>>>
> >> >>>>>
> >> >>>>> Blogs and organic groups at http://www.ccie.net
> >> >>>>>
> >> >>>>> ______________________________**______________________________**
> >> >>>>> ___________
> >> >>>>> Subscription information may be found at:
> >> >>>>> http://www.groupstudy.com/**list/CCIELab.html<
> >> http://www.groupstudy.com/list/CCIELab.html>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >> >>> --
> >> >>> ccie99999
> >> >>> twitter: @ccie99999
> >> >>>
> >> >>>
> >> >>> Blogs and organic groups at http://www.ccie.net
> >> >>>
> >> >>> ______________________________**______________________________**
> >> >>> ___________
> >> >>> Subscription information may be found at:
> >> >>> http://www.groupstudy.com/**list/CCIELab.html<
> >> http://www.groupstudy.com/list/CCIELab.html>
> >> >>>
> >> >>
> >> >>
> >> >> Blogs and organic groups at http://www.ccie.net
> >> >>
> >> >> ______________________________**______________________________**
> >> >> ___________
> >> >> Subscription information may be found at:
> >> >> http://www.groupstudy.com/**list/CCIELab.html<
> >> http://www.groupstudy.com/list/CCIELab.html>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> > --
> >> > Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
> >> >
> >>
> >>
> >>
> >> --
> >> ccie99999
> >> twitter: @ccie99999
> >>
> >>
> >> Blogs and organic groups at http://www.ccie.net
> >>
> >> _______________________________________________________________________
> >> Subscription information may be found at:
> >> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Jul 31 2012 - 14:07:25 ART