On Tue, 13 Jul 2010, Benjamin Lovell wrote:
7200 NPE-G2 - may not handle traffic rate(high rate of small packets is
a problem)
Afaik there is no STM-4 POS interface for 7200, which was a requirement.
I'd also bet on the ASR1k with that requirement, or look at used 12000
equipment if
On Wed, 14 Jul 2010, Mark Tinka wrote:
On Wednesday 14 July 2010 02:37:09 pm Mikael Abrahamsson
wrote:
Afaik there is no STM-4 POS interface for 7200, which was
a requirement.
Not anymore, no.
Anymore? As far as I know there never has been one, only OC12 SRP (which
only allowed for ~120
We have the default service-policy applied so we have the default sip
inspection enabled.
We have enabled debug sip and all the types of logging and we didn't see
absolutely nothing.
I'm trying to get the output you mentioned.
Thanks.
Regards,
Antonio Soares, CCIE #18473 (RS/SP)
Hi Group,
We are having trouble with unicast flooding on a particular VLAN and
associated ports and as a result brief spikes in CPU usage on one of our
6509 core switches.
ARP and MAC timeouts are set to default and we haven't had problems with
this in the past. The problem is I believe
On 14/07/10 11:30, Aaron Riemer wrote:
Hi Group,
We are having trouble with unicast flooding on a particular VLAN and
associated ports and as a result brief spikes in CPU usage on one of our
6509 core switches.
ARP and MAC timeouts are set to default and we haven't had problems with
this
Hi,
Would anybody have any comments on doing port-mode EoMPLS xconnects on
port-channels on Sup720 running SXI?
We're contemplating delivering EoMPLS PtP this way. In or normal setup
we connect a switchport trunk from the downlink device to a port-mode
EoMPLS-port, plain and simple.
My guess is
Hi Phil,
I had a problem like this last year on 6500's.
It was related to bug: CSCsk23521
Basically a server in our datacenter used multicast addresses in the range
allocated for BPDU's, and this just killed the SP (100% CPU...).
If you do a remote command switch sh proc cpu on the 6500 you can
On Wed, Jul 14, 2010 at 12:14:01AM +0100, Antonio Soares wrote:
I have a customer running 8.3.1 that is facing a very strange issue. Some SIP
packets are silenty dropped. This seems to be random.
The SIP packets are of type request:options. The source and destination
ports are the same:
On 14/07/10 13:03, JC Cockburn wrote:
Hi Phil,
I had a problem like this last year on 6500's.
It was related to bug: CSCsk23521
Basically a server in our datacenter used multicast addresses in the range
allocated for BPDU's, and this just killed the SP (100% CPU...).
Ugh. Nasty bug!
If you
Correct. OC12 is as high as we went but the email said GE/FE uplinks so I took
622 as an effective traffic rate not interface type.
-Ben
On Jul 14, 2010, at 4:28 AM, Mikael Abrahamsson wrote:
On Wed, 14 Jul 2010, Mark Tinka wrote:
On Wednesday 14 July 2010 02:37:09 pm Mikael Abrahamsson
I would test this for load-sharing with your traffic profile. It's been a while
since I looked at this but I think the port channel hashing criteria is limited
when xconnect terminates to a port-channel.
If I remember correctly we cannot do port channel hash on IP header when coming
off an
Hi Phil,
Answers below:
1) IOS - s72033-advipservicesk9_wan-mz.122-18.SXF17a.bin
2) HSRP configured between two core 6509's. SVI is VLAN1 (I know don't ask)
trunked between the cores via 10G. Only ports in VLAN1 on one core switch
are impacted and seeing the flooding.
3) Building floor switches
Most of the time we see problems like this it is caused by asymmetric routing.
The ECPM return path leads to the standby switch which does not know the DMAC
as all traffic was processed by the active switch. This is usually fixed by
increasing the MAC table timers to match the ARP timers so
Since you are running HSRP,I'm willing to bet it's a asymmetrical routing with
aging timeout causing a unicast flooding.
If you make the arging timeout = to the arp timeout it might fix your problem:
mac-address-table aging-time 14400
http://www.ciscopress.com/articles/article.asp?p=336872
On 14/07/10 15:40, Matthew Huff wrote:
Since you are running HSRP,I'm willing to bet it's a asymmetrical routing with
aging timeout causing a unicast flooding.
This is a very good bet.
If you make the arging timeout= to the arp timeout it might fix your problem:
mac-address-table
Great.
I was researching about commands to monitor the TCAM and ACL statistics, but I
could not figure out how is the association between port asics and interfaces.
There is the command 'show platform pm if-numbers', but in the column port, is
the first number the port asic number and second one
Yes i have read all about unicast flooding:
Can occur by:
1) Asymmetric routing
2) Spanning Tree TCN
3) MAC aging out
I cannot see any TCN's or Asymmetric routing so i think we may have to
adjust the mac aging as you suggested.
I am just trying to work out why the hell this has only just
I see 5 SIP bugs in that list but they don't seem to match this issue.
The link for those interested:
http://www.cisco.com/web/software/280775065/33079/ASA-831-Interim-Release-Notes.html
I forgot to mention but the SIP packets being dropped are UDP based. It's like
a keepalive mechanism
On Wednesday 14 July 2010 02:37:09 pm Mikael Abrahamsson
wrote:
Afaik there is no STM-4 POS interface for 7200, which was
a requirement.
Not anymore, no.
If the OP really needs 622Mbps, and Ethernet is not an
option, the ASR1002 is the way forward, at least.
Cheers,
Mark.
signature.asc
Forgive my ignorance. What is ECPM??
Shouldn't all routed traffic be handled by the active HSRP node?
-Original Message-
From: Benjamin Lovell [mailto:belov...@cisco.com]
Sent: Wednesday, 14 July 2010 10:38 PM
To: Aaron Riemer
Cc: 'JC Cockburn'; 'Phil Mayers'; cisco-nsp@puck.nether.net
typo. Should have been ECMP(equal cost multi-path) i.e. equal cost routes.
-Ben
On Jul 14, 2010, at 10:59 AM, Aaron Riemer wrote:
Forgive my ignorance. What is ECPM??
Shouldn't all routed traffic be handled by the active HSRP node?
-Original Message-
From: Benjamin Lovell
On 14/07/10 15:59, Aaron Riemer wrote:
Forgive my ignorance. What is ECPM??
ECMP = Equal-cost multipath
Shouldn't all routed traffic be handled by the active HSRP node?
Outbound yes. Inbound no; both HSRP active standby have connected
routes for the subnet.
On 14/07/10 15:51, Aaron Riemer wrote:
Yes i have read all about unicast flooding:
Can occur by:
1) Asymmetric routing
2) Spanning Tree TCN
3) MAC aging out
I cannot see any TCN's or Asymmetric routing so i think we may have to
adjust the mac aging as you suggested.
If you're running HSRP,
On 7/14/10 7:41 AM, TCIS List Acct wrote:
We are using a boatload of aging 3550-EMI switches (-48s and -12Ts
mostly) as our distribution layer in our Co-lo facilities. The switches
talk a little bit of OSPF and iBGP back to the core (uplinked over the 2
Gig-E ports). All customers have their
HSRP is an inbound next hop routing protocol. It creates a virtual Ip that
tracks with a virtual MAC. It has no bearing on outbound traffic, only inbound.
With HSRP it is very easy to create asymmetrical routing.
For example, consider a firewall connected to a VLAN with two 6500 switches
Shouldn't all routed traffic be handled by the active HSRP node?
Yes, but the problem is the return path...
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
On Wed, 2010-07-14 at 09:49 -0400, Benjamin Lovell wrote:
I would test this for load-sharing with your traffic profile. It's
been a while since I looked at this but I think the port channel
hashing criteria is limited when xconnect terminates to a
port-channel.
If I remember correctly we
Depending on the number of connected IP addresses this can be an issue. This is
why in most cases it will be better to bring up the MAC table timers as opposed
to bring down the ARP timers.
-Ben
On Jul 14, 2010, at 11:16 AM, Jon Lewis wrote:
On Wed, 14 Jul 2010, Phil Mayers wrote:
From a load sharing point of view this is likely to work out better as then
the CEs have all the load-sharing options available to them. LACP, STP, UDLP,
et al pass transparently over port mode xconnect.
-Ben
On Jul 14, 2010, at 12:13 PM, Peter Rathlev wrote:
On Wed, 2010-07-14 at 09:49
Hi,
On Wed, 14 Jul 2010 11:16:45 -0400 (EDT)
The vlan in question had an arp timeout of 60s and had a couple of KVM
servers with 100 or so virtual machines. Especially when a large number
of VMs started up, we'd see periods of packet loss. My assumption is that
the sup720-3bxl can only
On Wed, 14 Jul 2010, Rich Sena wrote:
Looking for some advice on ISO to support a 6513 that is currently running
s72033-jk9sv-mz.122-18.SXD6.bin - we are going to add a 10G card
(WS-X6708-10GE CEF720 8 port 10GE with DFC)
The switch is a data center core and has a twin that it works HA via
Check for SXI latest later this week...
Sent from my iThing
On Jul 14, 2010, at 4:30 PM, Gert Doering g...@greenie.muc.de wrote:
Hi,
On Wed, Jul 14, 2010 at 01:36:34PM -0400, Rich Sena wrote:
Looking for some advice on ISO to support a 6513 that is currently running
Hi all,
I've got a client that has ~15 sites on the fibre side of my network.
Most of these sites have redundant links via SDSL. All of the sites
(even the single-homed ones) do BGP to me (private AS, I announce
default and a small subset of specifics).
Most of the sites are small, and I usually
Guys,
Can ASIC oversubscription cause the switch to unicast out all ports for that
ASIC?
I am still seeing some unicast traffic hitting ports where it shouldn't be.
Cheers,
Aaron.
On Thu 15/07/10 12:27 AM , Benjamin Lovell belov...@cisco.com wrote:
Depending on the number of connected IP
Are you relying on QoS in the 3550? If so, you'll be disappointed with
the 3560/3750.
Nope, no QoS.
--Mike
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
35 matches
Mail list logo
