Configure eBGP from your edge to the client edge using
private-AS. Since I already have copy/paste templates (thanks
to RANCID), I make it a habit to ensure filters are at both
ends. Goes without saying that
BCP-38 is followed, and strict is deployed everywhere possible.
peer-group and
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
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
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
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
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
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.
---
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
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
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
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
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
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
268.1
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
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
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
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
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
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
m...@internode.com.auwrote:
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
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
20 matches
Mail list logo
