[c-nsp] MAN providers in Shenzen,China-HK region

Hi, Sorry for going OT, but I was hoping somebody in the know could recommend MAN providers in the Shenzen Area. This can be MPLS or plain Metro-E connectivity to the hub site. We are looking at connecting around 7 sites in the area at a minimum of 10 Mbps. Thanks, -Andrew.

[c-nsp] IPv6 static NAT (PAT)

Hi, I'm trying to figure out the (NAT/PAT) mechanics of assigning a customer ipv6 only. I know I don't have to worry about this today, but I tend to jump to the worst case scenario first and work backwards. (FYI - I am talking about datacenter / dedicated access only - i.e. no residential

Re: [c-nsp] IPv6 static NAT (PAT)

Hi Brandon, Brandon Applegate wrote: Hi, I'm trying to figure out the (NAT/PAT) mechanics of assigning a customer ipv6 only. I know I don't have to worry about this today, but I tend to jump to the worst case scenario first and work backwards. (FYI - I am talking about datacenter /

Re: [c-nsp] ouch 7204vxr reloaded

Mike, This is a PMPE and as such, the tracebacks et al are invalid and so too the decodes. There is _no_ software fix to prevent PMPEs. Most PMPEs are caused by cosmic radiation and sometimes (albeit rarely) from built up ESD due to improper personnel handling of components. Since

Re: [c-nsp] ouch 7204vxr reloaded

In many cases (at least for us), it often makes much more sense to have a cold/warm/hot spare than to maintain a support contract. I've also had more than one case when TAC really couldn't help unless I had a reproducible, live problem for them to troubleshoot. Not trying to steer you away from

[c-nsp] Nexus 5xxx VPC peer keepalives

Anyone, Coming up on a design issue with our upcoming first deployment of Nexus 5010s and 5020s in a new datacenter. It's recommended in the following doc to use the mgmt0 interface for peer keepalive messages:

Re: [c-nsp] Nexus 5xxx VPC peer keepalives

Charles, -Original Message- Sent: Wednesday, April 28, 2010 1:36 PM To: nsp-cisco Subject: [c-nsp] Nexus 5xxx VPC peer keepalives Anyone, Coming up on a design issue with our upcoming first deployment of Nexus 5010s and 5020s in a new datacenter. It's recommended in the

[c-nsp] Access-list not working on eth sub if

This is on a 2811 running c2800nm-spservicesk9-mz.124-21a. I have an access list applied as such: ! interface GigabitEthernet0/0/0 description QMOE service no ip address ip flow ingress negotiation auto ! interface GigabitEthernet0/0/0.1 description PtP VLAN to xxx encapsulation dot1Q xxx

Re: [c-nsp] Access-list not working on eth sub if

I failed to mention that Gi0/0/0.1 is the only up interface on the router, so I am sure of the path a ping to 4.2.2.2 takes. -- James H. Edwards Senior Network Systems Administrator Judicial Information Division jedwa...@nmcourts.gov ___ cisco-nsp

Re: [c-nsp] Access-list not working on eth sub if

On 29/04/2010, at 8:15 AM, james edwards wrote: The access-lists seem to not work when configed out but works fine configured in ACLs don't match locally-originated traffic from the router. cheers, lincoln. ___ cisco-nsp mailing list

Re: [c-nsp] ouch 7204vxr reloaded

What's really strange is that we had a sup720 failover to the redundant Sup in a 7609 recently. I opened a TAC case and the reason I got for it from Cisco was: = the device experienced a CPU parity error ... These occur when an energy level within the chip (for example, a one or a zero)