Re: [c-nsp] PIX questions

2008-05-13 Thread [EMAIL PROTECTED]
Dear ALL,
I don't understand why do you wonna do something like that..., maybe I 
misunderstood but I don't recognize your needs

What I mean is:

If you need to make some comunication between internal addresses, than you need 
to use real IP

If you need to make comunication between different interfaces you can (if 
needed) use nated IP

Now I'm thinking about, and I think that you should need it, due to DNS 
resolutions issue.


In other words, a internal address nated on the outside that is resolved with a 
public (nat) address that need to be reached from the internal  server/client,
than you need to use the alias command to define DNS doctoring inspection.

take a look to the manual for DNS doctoring (alias command).

Hope this help you guys out 

Cheers

 
Paolo Riviello

Home: http://www.paoloriviello.com 
Msn: [EMAIL PROTECTED] Skype: pao_rivi 
--
I'm a rebel, soul rebel I'm a capturer, soul adventurer
See the morning sun, On the hillside if not living good, travel wide. B.M.



 From: [EMAIL PROTECTED]
 To: cisco-nsp@puck.nether.net
 Date: Tue, 13 May 2008 09:14:03 +0300
 Subject: Re: [c-nsp] PIX questions
 
 
 You must understand that the NAT is being performed on a from--to basis, 
 that is why the command is static (inside,outside) so if the NAT is between 
 inside and outside you can't hit it when coming from the dmz, for this to be 
 achieved you should use a static (inside,dmz) command, but then, you won't 
 have the needed translation towards the outside, I think you can't enjoy both 
 worlds... Besides, what's the problem having the outside hosts use the public 
 IP address and the dmz hosts use the inside IP address for accessing the 
 severs?
 
 Ziv
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gregori Parker
 Sent: Monday, May 12, 2008 8:35 PM
 To: cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] PIX questions
 
 I was hoping to see an answer to this, as I ran into what I believe to
 be a similar situation a while back.
 
 We had an ASA at an edge, with several static identity NATs, e.g.:
 
 static (inside,outside) x.x.x.78 172.16.8.44 netmask
 255.255.255.255
 static (inside,outside) x.x.x.79 172.16.8.45 netmask
 255.255.255.255
 ...
 
 Where x.x.x.* are public addresses, and an access-list allows specific
 services from anywhere to each public NAT.  All outgoing traffic is
 PATed to the interface address, say x.x.x.80, and I'm not clear on how
 to enable a host on the inside to communicate with an identity NAT on
 the outside...essentially the ASA would be doubling up on translations,
 one outgoing, to one inbound...looping back to itself so-to-speak.  It
 doesn't work, and I understand why, but I've wondered if there's a way
 to enable this (other than having the hosts communicate directly).  I've
 looked at things like permitting same-security-traffic
 inter/intra-interface to no avail.
 
 Thanks in advance (and sorry if I woke a dead thread)
 
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Rudy Setiawan
 Sent: Friday, May 09, 2008 12:05 AM
 To: cisco-nsp@puck.nether.net
 Subject: [c-nsp] PIX questions
 
 Hi all,
 
 I have a question about PIX translation
 
 An outside interface has IP address:
 192.168.1.2 255.255.255.0
 
 An DMZ interface has IP address:
 10.1.1.2 255.255.255.0
 
 
 Current translation:
 10.1.1.3 - 192.168.1.3
 10.1.1.4 - 192.168.1.4
 
 
 How can I make it so that 10.1.1.3 is able to ping the IP 192.168.1.4?
 How can I make it so that anyone behind 10.1.1.0/24 network is able to
 ping the IP 192.168.1.4?
 
 Consider the ICMP is allowed any any.
 
 I tried to configure it but the ASDM log say
 Deny IP Spoof From 192.168.1.2 to 192.168.1.4 on interface outside
 
 Thank you for your help in advance.
 
 Regards,
 Rudy
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/
 
 
 
 
 
 
 This footnote confirms that this email message has been scanned by
 PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
 viruses.
 
 
 
 
 
 
  
  
 
 This footnote confirms that this email message has been scanned by
 PineApp Mail-SeCure for the presence of malicious code, vandals  computer 
 viruses.
 
 
 
 ___
 cisco

Re: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN

2008-02-01 Thread [EMAIL PROTECTED]
Hi Jeff,

I still did not have opportunity to test it over L3. However, I tested
it over L2 VPNs. The result was pretty good, specially when using the
more complex algorithm available in the command ip multicast
multipath
Each IPTV program took a different interface when using the following:

-Different sources and multicast group
-Same source and different multicast group

I believe the limitation advised in Cisco page were removed, or I am not
using exactly the same PFC described in the restriction.

Br,
Alaerte 

-Original Message-
From: ext Jeff Tantsura [mailto:[EMAIL PROTECTED] 
Sent: Thursday, January 31, 2008 11:25 AM
To: Vidali Alaerte (NSN - BR/Rio de Janeiro)
Subject: RE: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN

Hi Alaerte,

Would be interested in your test results.

Thanks,
Jeff

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cisco-nsp- 
 [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
 Sent: woensdag 23 januari 2008 12:29
 To: [EMAIL PROTECTED]; cisco-nsp@puck.nether.net
 Subject: Re: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN
 
 Thanks Oli.
 
 I will test today on PFC3xx with SRB2 and post the result.
 
 Br,
 Alaerte
 
 -Original Message-
 From: ext Oliver Boehmer (oboehmer) [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, January 22, 2008 8:01 PM
 To: Vidali Alaerte (NSN - BR/Rio de Janeiro); 
 cisco-nsp@puck.nether.net
 Subject: RE: [c-nsp] PIM Split Rules and Multicast over L3 MPLS VPN
 
 [EMAIL PROTECTED]  wrote on Tuesday, January 22, 2008 6:09 PM:
 
  Hi,
 
  PIM considers source of multicast to perform load splitting when the

  command ip multicast multipath is entered. When using multicast 
  over
  L3 MPLS VPN, the source IP is the IP of PEx for any customer group 
  connected to PEx.
  Any way to overcome this limitation and achieve load splitting of 
  multicast over L3 MPLS VPN?
 
  For example, consider this scenario:
 
   Sender for group G1 and
  G2---CE1-PE1--P1-PE2CE2receiver of G1 and G2
 |   |
 |___P2__|
 
  The goal is having one G1 taking path PE1--P1--PE2 and G2 taking 
  path PE1--P2--PE2.
  (but without using GRE encapsulation to have multicast encapsulated 
  into unicast)
 
 12.2SRB for the 7600 introduced ip multicast multipath s-g-hash
basic
 which allows you to do the hash on source+group.. Platform support for

 this is still limited, not sure about your environment.
 
   oli
 ___
 cisco-nsp mailing list  cisco-nsp@puck.nether.net 
 https://puck.nether.net/mailman/listinfo/cisco-nsp
 archive at http://puck.nether.net/pipermail/cisco-nsp/

___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] EoMPLS and VPLS Load Balancing

2008-01-18 Thread [EMAIL PROTECTED]
 Hi,

Considering the scenario, do you see a way to load balancing Layer 2 VPN
over MPLS (VPWS or old AtoM and VPLS?
(that is, one xconnect takes PE1-P1-PE2 and other takes PE1-P2-PE2)

CE-PE1-P1-PE2CE2
|   |  |
|__P2__|


Tks,
Alaerte
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] 7507 IOS ver. recommendation: 12.0S or 12.2S or whatever?

2007-09-21 Thread [EMAIL PROTECTED]
Hi folks,

 

Please, I need your advice. Which IOS ver. is mostly recommended for
7507 running mostly as an ethernet customer access router?

 

Our hardware configs are: 7507, dual RSP4 256D/32+F, VIP2-50s w/
PA-FE-TXs, old serials (FSIPs).

 

Our feature config is a standard provider package: lots ISL/dot1q
customer subintefaces, dCEF, BGP4, netflow ver. 5 , ACLs.

And a little bit of some service stuff that we can switch off if needed
for moving to the right image: NAT, GRE, NBAR, rate-limit,
traffic-shaper. So, we are IPv4 only, no IPv6, no MPLS, no non-IP stuff.

 

 

Today I noticed our cybuses are upto ~100mbps load, so dCEF is
definitely not working for us, that's the reason why we should switch
IOS version. Also, it turned out today our dCEF really suffer from
named-ACLs bug. Oh, yes.

 

 

Please, advise.

 

 

Thank you, indeed.

 

 

 

--

Ilia Zubkov,

CIO, Educational Network Ltd.

Phone: +7 (495) 988-8990

Cell: +7 (985) 139-7739

Web: http://www.edunet.ru/

 

 



___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] Error Msgs - SYS-4-CHUNKMALLOCFAIL - arp throttle

2007-09-10 Thread Jairaj [EMAIL PROTECTED]@DCIN-BOM
 

 

HI,

 

Pls help me on the below error.

 

*Sep  8 07:24:00.475: %SYS-4-CHUNKMALLOCFAIL: Could not allocate 
 chunks for CEF:
   arp throt
 Total free: 0, Total inuse: 500, Cause : Not a dynamic chunk
   -Process= interrupt level, ipl= 1 -Traceback= 0x41102C3C 
 0x400AB2F0 0x400AB
 354 0x413B99FC 0x40056A28 0x425D505C 0x425D2B90 0x40041FF8 
 0x400101E8 0x40011668
 *Sep  8 07:25:00.655: %SYS-4-CHUNKMALLOCFAIL: Could not allocate 
 chunks for CEF:
   arp throt
 Total free: 0, Total inuse: 500, Cause : Not a dynamic chunk
   -Process= interrupt level, ipl= 1 -Traceback= 0x41102C3C 
 0x400AB2F0 0x400AB
 354 0x413B99FC 0x40056A28 0x425D505C 0x425D2B90 0x40041FF8 
 0x400101E8 0x40011668
 *Sep  8 08:13:40.767: %SYS-4-CHUNKMALLOCFAIL: Could not allocate 
 chunks for CEF:
   arp throt
 Total free: 0, Total inuse: 500, Cause : Not a dynamic chunk
   -Process= interrupt level, ipl= 1 -Traceback= 0x41102C3C 
 0x400AB2F0 0x400AB
 354 0x413B99FC 0x40056A28 0x425D505C 0x425D2B90 0x40041FF8 
 0x400101E8 0x40011668
 *Sep  8 08:27:32.059: %BGP-3-NOTIFICATION: sent to neighbor 
 125.99.127.102 4/0 (
 hold time expired) 0 bytes
 *Sep  8 08:37:43.531: %SYS-4-CHUNKMALLOCFAIL: Could not allocate 
 chunks for CEF:
   arp throt




This email and all contents are subject to the following disclaimer:

http://www.datacraft-asia.com/disclaimer


___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


Re: [c-nsp] BGP Cpu

2007-06-22 Thread [EMAIL PROTECTED]
It's a GSR 12012/PRP working as PE with 4 full feed from RR, some transit 
client and some mpls vpn customer.
However TAC engineer didn't explain me why cpu can goes down and  in a couple 
of days goes up, but he said i can have reach platform limit so i'm going to 
migrate some customer on another PE.

Regards,
Gianluca
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/


[c-nsp] BGP Cpu

2007-06-21 Thread [EMAIL PROTECTED]
Hi, someone have idea on how a clear ip bgp * soft in and clear ip bgp soft 
out can smooth out CPU use ?
Before the clear:
CPU utilization for five seconds: 99%/0%; one minute: 69%; five minutes: 66%
 PID Runtime(ms)   Invoked  uSecs   5Sec   1Min   5Min TTY Process 
 174 97860441440825344  6 47.56% 53.47% 52.70%   0 BGP Router 
After the clear:
CPU utilization for five seconds: 18%/0%; one minute: 37%; five minutes: 37%
 PID Runtime(ms)   Invoked  uSecs   5Sec   1Min   5Min TTY Process 
 174101175361440872287  7 16.15% 22.41% 23.23%   0 BGP Router

Regards,
Gianluca
___
cisco-nsp mailing list  cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/