>
> Yes, you replace your 61xx cards with 67xx cards. You can't do this sort
> of thing with qos or copp.
The 67xx series cards aren't supported by the sup32, though. Would 65xx
line cards do the trick?
Andrew
It's nice to give Kazakhstan a break for a week or so. :p
On Sat, Aug 22, 2009 at 12:56 AM, Matthew Moyle-Croft
wrote:
> I'm guessing that the top 20 unstable ASes are Korean or Asian is related
> to the cable cuts in Asia?
>
>
> cidr-rep...@potaroo.net wrote:
>
>> BGP Update Report
>> Interval:
I'm guessing that the top 20 unstable ASes are Korean or Asian is
related to the cable cuts in Asia?
cidr-rep...@potaroo.net wrote:
BGP Update Report
Interval: 13-Aug-09 -to- 20-Aug-09 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds
This report has been generated at Fri Aug 21 21:11:35 2009 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date
BGP Update Report
Interval: 13-Aug-09 -to- 20-Aug-09 (7 days)
Observation Point: BGP Peering with AS131072
TOP 20 Unstable Origin AS
Rank ASNUpds % Upds/PfxAS-Name
1 - AS4961 516762 6.6%6379.8 -- DISC-AS-KR Daewoo Information
System
2 - AS9767 3
On Aug 21, 2009, at 3:47 PM, Brian Dickson wrote:
My institution has a single /16 spread across 2 sites: the lower /
17 is
used at site A, the upper /17 at site B. Sites A & B are connected
internally. Currently both sites have their own ISPs and only
advertise
their own /17's. For redund
> My institution has a single /16 spread across 2 sites: the lower /17 is
> used at site A, the upper /17 at site B. Sites A & B are connected
> internally. Currently both sites have their own ISPs and only advertise
> their own /17's. For redundancy we proposed that each site advertise
> both t
On Thu, Aug 20, 2009 at 07:56:14PM -0500, Clue Store wrote:
> Most of my staff are still under the impression in Cisco land that the
> "network 10.0.0.0 255.255.255.0" statement injects than network into OSPF,
> when it simply turns on OSPF for the interfaces that are in that network.
So most of y
On Fri, Aug 21, 2009 at 10:07:44AM -0400, Dustin Schuemann wrote:
> Is anyone else seeing packet loss on Level3.
>
> 6. ge-6-11-137.car2.Detroit1.Level3.net 2.9%35
> 372.1 148.6 19.4 704.8 127.4
> 7. ae-11-11.car1.Detroit1.Level3.net 8.6%35
> 2
Grzegorz Janoszka wrote:
No, BGP does not work this way. But you may force some carriers to have
only /16. First, you may try to announce the /17's with the community
no-export, so they will be seen only by your direct ISP, not by the rest
of the world. Or you may try to use some other commun
Gaynor, Jonathan wrote:
My institution has a single /16 spread across 2 sites: the lower /17 is
used at site A, the upper /17 at site B. Sites A & B are connected
internally. Currently both sites have their own ISPs and only advertise
their own /17's. For redundancy we proposed that each site
Hi Jon,
If I personally saw it, I wouldn't bother since I would assume there would be a
method to your madness. ;-)
Jeff
-Original Message-
From: Gaynor, Jonathan [mailto:jonathan.gay...@fccc.edu]
Sent: Friday, August 21, 2009 10:58 AM
To: nanog@nanog.org
Subject: Redundancy & Summa
On 21/08/2009 17:04, Roland Dobbins wrote:
Yes, but this is evil and dangerous in a customer-facing environment;
transparent mode is the preferred option, in most circumstances.
It is very evil, yes. SXH and later support VTPv3 which allows you to
disable VTP on a per port basis. But as you
On Aug 21, 2009, at 10:57 PM, Nick Hilliard wrote:
Or unless you're running VTP
Yes, but this is evil and dangerous in a customer-facing environment;
transparent mode is the preferred option, in most circumstances.
---
Ro
My institution has a single /16 spread across 2 sites: the lower /17 is
used at site A, the upper /17 at site B. Sites A & B are connected
internally. Currently both sites have their own ISPs and only advertise
their own /17's. For redundancy we proposed that each site advertise
both their own /
On 21/08/2009 16:39, Roland Dobbins wrote:
Chopping up the layer-2 broadcast domain for a given VLAN into smaller
pieces via pVLANs can't hurt, either, as long as the hosts have no need
to talk to one another - and it has other benefits, as well.
Unless your broadcast storm happens on an untagg
Roland Dobbins wrote:
Chopping up the layer-2 broadcast domain for a given VLAN into smaller
pieces via pVLANs can't hurt, either, as long as the hosts have no need
to talk to one another - and it has other benefits, as well.
Or you hit the extreme DSL concentrator end where you crank out q-in
On Aug 21, 2009, at 10:23 PM, Nick Hilliard wrote:
there are two things you care about: storm control and port security
(mac address counting).
Chopping up the layer-2 broadcast domain for a given VLAN into smaller
pieces via pVLANs can't hurt, either, as long as the hosts have no
need t
Peter,
This question would be better directed at cisco-nsp, but...
On 21/08/2009 11:39, Peter George wrote:
I have several Catalyst 6500 (Supervisor 32) aggregation switches with
WS-X6148A-GE-TX and WS-X6148-GE-TX line cards.
These line cards do not support storm-control/broadcast suppression.
Is anyone else seeing packet loss on Level3.
6. ge-6-11-137.car2.Detroit1.Level3.net 2.9%35
372.1 148.6 19.4 704.8 127.4
7. ae-11-11.car1.Detroit1.Level3.net 8.6%35
268.1 161.5 21.3 691.8 156.0
8. ae-8-8.ebr2.Chicago1.Level3.net
Hello,
I have several Catalyst 6500 (Supervisor 32) aggregation switches with
WS-X6148A-GE-TX and WS-X6148-GE-TX line cards.
These line cards do not support storm-control/broadcast suppression. This
impacted us badly during a recent spanning tree event.
As it stands, we are at risk of overwhel
21 matches
Mail list logo
