On Fri, Nov 10, 2006 at 07:20:10AM +0200, Hank Nussbacher wrote:
> AS29449 is not the problem. It is the upstreams of AS5602 (KPNQwest
> Italia) and AS286 (KPN) that let this crap leak.
In fact, it may not even be the immediate upstreams. In our paper, we
describe specific examples where it's
On Fri, Nov 10, 2006 at 11:01:02AM +, [EMAIL PROTECTED] wrote:
>
> the preso link is below, you didnt read it yet.. :)
>
> you can hijack any address space providing your route is preferred either
> because it is more specific, less specific, shorter as-path..
Slides 13-15 of our Feb 2006
On Fri, Nov 10, 2006 at 05:55:40AM -1000, Randy Bush wrote:
>
> > Wouldn't they want to hijack more specifics to spam?
>
> no. see nick feamster's work, and the lightning talk i proxied
> for him in dallas.
Here are the links from our observations on this, from our Feb NANOG talk:
http://www.n
Martin Hannigan wrote:
My answer, in short, was to say that I see it as more of an enterprise
play because it's a managed service and the hardest part of
provisioning is typically the order cycle.
If you are an ISP, you are theoretically multi homed by definition
and your providers are going to
Martin Hannigan wrote:
[ SNIP ]
> If you are changing providers, which takes
awhile anyway,
That process seems to be getting quicker:
http://www.equinix.com/prod_serv/network/ed.htm
NOT an ISP product.
Independent of ED, one should be cautious when designing routing
protocols based
Josh Karlin wrote:
Hasn't that been said for years? Wouldn't perfect IRRs be great? I
couldn't agree more. But in the meanwhile, why not protect your own
ISP by delaying possible misconfigurations.Our proposed delay does
*not* affect reachability, if the only route left is suspicious, it
Alain Hebert wrote:
(Most of) The new generation of BGP experts are being formed in
smaller ISP... And this is where most of the mistakes happen...
^
---> Certainly not all.
A secondary point is that C-BGP could likely prove
Wouldn't a well-operated network of IRRs used by 95% of
network operators be able to meet all three of your
requirements?
-certified prefix ownership
-certified AS path ownership
-dynamic changes to the above two items
It seems to me that most of the pieces needed to do
this already exist. RPS
You can also see:
http://bgp.lcs.mit.edu/
which has a searchable archive back to 2001 for several feeds. We're
always interested in getting more feeds from folks to make this
searchable archive more comprehensive.
thanks,
-Nick
On Wed, Jan 05, 2005 at 07:06:17AM -0800, David Meyer wrote:
>
>
Simon,
We see many advertisements out of 83/8 at our various observation
points, but never 83.146.0.0/18. bgp.lcs.mit.edu provides various
perspectives. For example, at MIT:
Nothing from your prefix:
http://bgp.lcs.mit.edu/bgpview.cgi?time=between&start=2004-1-1&end=2004-4-15&bins=10&prefix=83
On Sat, Mar 13, 2004 at 04:19:40PM -0800, Will Yardley wrote:
>
> On Fri, Mar 12, 2004 at 11:37:25PM -0500, Joe Abley wrote:
> > On 12 Mar 2004, at 23:24, joe mcguckin wrote:
> >
> > > I suspect that each FE goes to a different AS...
> >
> > In that case, sample/count outbound traffic volumes b
Hi Nanog,
As you may know, I've been developing a tool called "RoLex" (Routing Lexer)
that performs various syntactic and conceptual checks on existing
BGP configurations. (To refresh your memory, see:
http://www.nanog.org/mtg-0310/feamster.html)
The checker now parses Cisco and Juniper IOS an
I should also mention that we are very open to feature requests from the
NANOG community. We are very interested in making our data and
interface more useful for folks.
-Nick
On Thu, Jan 23, 2003 at 11:39:48AM -0500, Nick Feamster wrote:
>
> Shameless plug time.
>
> You ma
Shameless plug time.
You may also enjoy:
http://bgp.lcs.mit.edu/
Which has 6 views, currently, thanks to many nanog types. We currently
have plans to add ~4 more feeds within the next month, and we are
definitely interested in getting more BGP feeds. (hint hint) :)
Typically, we like to place
We see instability from certain prefixes originated by C&W around this
time (indeed, they seem to be showing up across many of our views). See
http://bgp.lcs.mit.edu/bgpview.cgi?time=between&start=2002-11-5+12%3A00%3A00&end=2002-11-5+15%3A00%3A00&bins=50&prefix=&rel=eq&aspath=&asrel=contain&orig
Bradley et al,
FYI, the "advertise-inactive" feature was (at least until very recently)
a documentation bug. See the message included below from John Allen at
Junper.
Cheers,
Nick
--
Jennifer,
I just filed a doc-bug for this. Our documentation reads, "By default,
BGP stores
More detail on how Cisco does this at:
http://www.cisco.com/warp/public/459/25.shtml
specifically, see step 10:
"10. When both paths are external, prefer the path that was received first
(the oldest one). This step minimizes route-flap, since a newer path won't
displace an older one, even if i
Along these lines, I have a perl module (written in C) that parses 'sh ip
bgp' formatted output... It's still a bit beta, but let me know if you're
interested.
-Nick
>
> I have a perl script which converts the output of 'sh ip bgp' into SQL
> (MySQL). I keep 'prefix', 'neighbor AS' and 'AS pa
We noticed teleglobe sending us 400+ BGP announcements per day up until
March 22.
207.45.223.0/24
207.45.205.0/24
207.45.195.0/24
For example, the graph linked below shows where 207.45.223.0/24 sent us ~
400 updates per day for many months:
http://ginseng.lcs.mit.edu/bgpview.cgi?time=between&st
19 matches
Mail list logo
