On 27-Mar-13 23:16 PM, Lukasz Bromirski wrote:
>
> On Mar 27, 2013, at 9:27 AM, Gert Doering wrote:
>
>>> I have opened tickets for silly bugs like "igmp snooping breaks ospf" or
>>> "show ip route command chrashed with SIGSEGV". (XR 4.3.0)
>>
>> That's a bit surprising - I had assumed that "it'
On Mar 27, 2013, at 9:27 AM, Gert Doering wrote:
>> I have opened tickets for silly bugs like "igmp snooping breaks ospf" or
>> "show ip route command chrashed with SIGSEGV". (XR 4.3.0)
>
> That's a bit surprising - I had assumed that "it's running the same IOS
> XR as are the bigger ASR9ks".
+1
On 27/03/13 16:18, Nick Hilliard wrote:
As this latest widely reported 300G spoof+amplification DDoS is causing
actual service harm to third party networks, could someone from Cisco give
some idea on when we can see uRPF on the ME3600/ME3800 product line up?
I really like these as PE boxes,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Internet Key Exchange Vulnerability
Advisory ID: cisco-sa-20130327-ike
Revision 1.0
For Public Release 2013 March 27 16:00 UTC (GMT)
+-
Summary
===
The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Resource Reservation Protocol Denial of Service
Vulnerability
Advisory ID: cisco-sa-20130327-rsvp
Revision 1.0
For Public Release 2013 March 27 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Zone-Based Policy Firewall Session Initiation
Protocol Inspection Denial of Service Vulnerability
Advisory ID: cisco-sa-20130327-cce
Revision 1.0
For Public Release 2013 March 27 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Smart Install Denial of Service Vulnerability
Advisory ID: cisco-sa-20130327-smartinstall
Revision 1.0
For Public Release 2013 March 27 16:00 UTC (GMT
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Network Address Translation Vulnerability
Advisory ID: cisco-sa-20130327-nat
Revision 1.0
For Public Release 2013 March 27 10:00 UTC (GMT)
+-
Summary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software IP Service Level Agreement Vulnerability
Advisory ID: cisco-sa-20130327-ipsla
Revision 1.0
For Public Release 2013 March 27 16:00 UTC (GMT)
+-
Summary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Cisco IOS Software Protocol Translation Vulnerability
Advisory ID: cisco-sa-20130327-pt
Revision 1.0
For Public Release 2013 March 27 16:00 UTC (GMT)
+-
Summary
===
The
As this latest widely reported 300G spoof+amplification DDoS is causing
actual service harm to third party networks, could someone from Cisco give
some idea on when we can see uRPF on the ME3600/ME3800 product line up?
I really like these as PE boxes, but lack of uRPF on them is hurting badly.
Ni
netdr capture could lend some clues. I don't think that's been
suggested yet. I've only used it on SUP720s, but I would think it will
still work for SUP-2Ts.
-dan
On 3/27/2013 10:03 AM, Pete Lumbis wrote:
I'd second this. My guess is there is a large amount of punted traffic and
the problem
I'd second this. My guess is there is a large amount of punted traffic and
the problem is just being made worse by netflow export. I'd suggest
engaging TAC to help you identify what's going on.
On Wed, Mar 27, 2013 at 2:15 PM, Dobbins, Roland wrote:
>
> On Mar 27, 2013, at 7:50 PM, Mikael Abrah
On Mar 27, 2013, at 7:50 PM, Mikael Abrahamsson wrote:
> For "Internet peering router at 10GE with typical eyeball traffic" my
> opinion is that 6500/7600 doesn't have working netflow.
Sup2T/DFC4 fixes these issues, as well as the uRPF mode limitation and weird
ACL threshold limitation.
The
Dne 27.3.2013 14:12, Dobbins, Roland napsal(a):
On Mar 27, 2013, at 6:42 PM, Jiri Prochazka wrote:
As soon as I limit usage to 70% (both Sup and linecards), no flows are
dropped, but the box is still dying.
Are your linecards all either DFC4 or CFC?
One is DFC4XL, one CFC.
Mod Sub-Modu
On Mar 27, 2013, at 6:42 PM, Jiri Prochazka wrote:
> As soon as I limit usage to 70% (both Sup and linecards), no flows are
> dropped, but the box is still dying.
Are your linecards all either DFC4 or CFC?
---
Roland Dobbins
Hej allihop
Vi kommer inte deplya några nya DS switchar, dessa kommer i framtiden vara
AS switchar.
De befinliga kommer endast döpas om om de samtidigt märks om på plats.
--
*Med Vänliga Hälsningar - Best Regards*
*Mattias Gyllenvarg*
*Nätutveckling*
Bredband2
Tel: +46 406219712
_
Hi,
On Wed, Mar 27, 2013 at 12:50:39PM +0100, Jiri Prochazka wrote:
> I'll try this today and will let you know the result. I thought the
> majority of CPU usage is consumed by 'match' statements, so I have
> already tried just 'match source ip' and 'match destination ip', which
> had no effect
On Wed, 27 Mar 2013, Phil Mayers wrote:
Obviously lots of people won't have this need, but it's the reason we would
avoid sampling. Maybe it's an unreasonable thing to want - but we do want it
;o)
The important thing is to realise the limitations of the 6500/7600 when it
comes to netflow. Fo
On 27/03/13 12:08, Sam wrote:
On Wed, March 27, 2013 12:49 pm, Phil Mayers wrote:
If it wasn't so irritating/tragic, this would be hilarious. People have
repeatedly said "sup2T has operationally useful netflow" and yet it
turns out to be *less* capable than sup720.
I agree on this, however I
On Wed, March 27, 2013 12:49 pm, Phil Mayers wrote:
> If it wasn't so irritating/tragic, this would be hilarious. People have
> repeatedly said "sup2T has operationally useful netflow" and yet it
> turns out to be *less* capable than sup720.
I agree on this, however I don't really see a problem i
Andras, Gert,
I'll try this today and will let you know the result. I thought the
majority of CPU usage is consumed by 'match' statements, so I have
already tried just 'match source ip' and 'match destination ip', which
had no effect.
Jiri
Dne 26.3.2013 22:33, Tóth András napsal(a):
Hi
On 27/03/13 11:42, Jiri Prochazka wrote:
Sam,
NDE yielding is not something I would like to use at this stage, because
I'm not able to get atleast to the same exporting capabilities as with
the old Sup720.
I tried to limit CPU usage for NDE to 20%, which had an effect of
droping majority of flo
Sam,
NDE yielding is not something I would like to use at this stage, because
I'm not able to get atleast to the same exporting capabilities as with
the old Sup720.
I tried to limit CPU usage for NDE to 20%, which had an effect of
droping majority of flows.
As soon as I limit usage to 70%
The two devices are from the same vendor and are connected via a 2gig trunck.
Rgds
Harry
Harry Hambi BEng(Hons) MIET Rsgb
-Original Message-
From: Rati , Berikaant Jokhadze [mailto:iinf...@gmail.com]
Sent: 27 March 2013 09:32
To: Harry Hambi
Cc: 'cisco-nsp@puck.nether.net'
Subject: R
On 26/03/13 23:56, Jared Mauch wrote:
On Mar 26, 2013, at 7:46 PM, Tammy A Wisdom
wrote:
Yea I don't recall if we did that or not. We changed to juniper
afterwards :)
I've tried for years to get Cisco to run RANCID against their
equipment in the lab before they ship software. They have bee
It's happening often when two different vendor devices is connected each
other , LSA is recieved with different Checksum , just try to reload
proccess on both side.
On 03/27/2013 01:16 PM, Harry Hambi wrote:
Good morning all,
Can anybody help with the following error message,
Mar 27 08:57:34:N
What Gert is trying to say is that you should not configure half-duplex, or
disable CEF without very good reasons.
to your original question, bridging isn't a bad idea and can be
accomplished with the use of bridge-groups. Just be aware of any
limitations that your firewall may have with regards t
Good morning all,
Can anybody help with the following error message,
Mar 27 08:57:34:N:OSPF: intf rcvd bad pkt: Bad Checksum, rid 10.72.130.42, intf
addr 10.10.128.150, pkt size 1456, checksum 23730, pkt src addr 10.10.128.149,
kt type link state update
Rgds
Harry
Harry Hambi BEng(Hons) MIET
Hi,
On Wed, Mar 27, 2013 at 09:11:37AM +0200, Eugene van der Merwe wrote:
> Is this a stupid idea?
>
> On the Cisco I have this configuration:
>
> interface FastEthernet0/0
> ip address 196.x.x.x 255.255.255.0
> no ip route-cache cef
*this* is almost ever a stupid idea.
> duplex half
As is
Yes I've known several non priv show commands to crash their routers
alan
___
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/
Hi,
On Tue, Mar 26, 2013 at 11:19:14PM +0200, Dumitru Ciobarcianu wrote:
> You're sure you didn't mean 9006 or 9010 ? You can't have redundant RSPs
> in ASR9001, and the chassis is maxed at 12 10G ports...
Yeah, I was talking 9001 :-) - we currently shift about 5 Gbit/s around
per box, with 3-4 1
We have a Cisco 7200VXR and I want to try to bridge the ATM and Ethernet
interfaces.
The reason why I want to bridge the ATM and Ethernet interfaces is because
I want to move a firewall downstream from the border, and would prefer to
just plug in the Cisco as a bridge to the Internet instead of us
On Wed, 27 Mar 2013, Mattias Gyllenvarg wrote:
Very nice platform, we got hit by the "MPLS payload begins with 0x6"
bug. Couldn't believe it was true.
This was a forwarding bug affecting all ASR9k in 4.2.1. That was the
second major forwarding bug affecting 4.2.1 (the other one was ghost /32s
34 matches
Mail list logo