[27233] in North American Network Operators' Group
Re: Strange announcements
daemon@ATHENA.MIT.EDU (Danny McPherson)
Thu Feb 10 11:13:42 2000
Message-ID: <38A2E259.D7F6B82D@tcb.net>
Date: Thu, 10 Feb 2000 09:07:53 -0700
From: Danny McPherson <danny@tcb.net>
MIME-Version: 1.0
To: nanog@merit.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: owner-nanog-outgoing@merit.edu
This was resultant of some left over garbage from a deomonstration I was
planning to perform during the route filtering panel Tuesday morning, I
had forgot about it (JUST KIDDING!!!).
It's obvious that it was the result of a configuration error and it's
long since been corrected. Fortunately, it didn't [completely] break
anything.
It does, however, serve as a nice follow-on to my comments regarding
providers needing the ability to perform prefix-based filtering on a
per-peer level in addition to the current "just BGP customer routes are
filtered". Filtering of this level would require vendors to support
hundreds of thousands of lines of ingress prefix-based filtering
policies, something that's not __completely available today.
Presumably, this same set of policies could also be used to perform
unicast RPF-type functions WRT SA-based packet filtering. This would
scope the effects of IP spoofing considerably, and remove some of the
vulnerabilities regarding unauthenticated origination of BGP routes.
A widely-deployed explicit acceptence model (prefix filtering) would
also allow providers (who are concerned with de-aggregation and the like
hosing their routers) to remove prefix-length based policies, and Save
all the "rural" multi-homed folks.
Of course, this also assumes that scalable backend infrastructure and
systems are in place to authenticate database object entries, etc..
Then again, an SS7-type solution with backend databases and an
out-of-band network populating SCPs, along with a completely static
transport system, provides support for number portability, perhaps we're
simply overlooking something?
-danny
[snip]
To QWEST NOC PEOPLE
Folks,
You appear to be announcing 198.133.219.0, which is the
network that www.cisco.com lives on, whats strange is that
you are then transiting this route onto GTEI [AS1] to deliver
the traffic. This is fairly sub-optimal and I'm sure incorrect.
kenny>sh ip bgp 198.133.219.25
BGP routing table entry for 198.133.219.0/24, version 23258497
Paths: (4 available, best #1, advertised over IBGP)
3356 209
209.244.160.57 from 209.244.160.57 (209.244.2.210)
Origin IGP, metric 4401, localpref 100, valid, external, best
3356 209, (received-only)
209.244.160.57 from 209.244.160.57 (209.244.2.210)
Origin IGP, metric 4401, localpref 100, valid, external
1 109
4.1.74.105 from 4.1.74.105 (4.0.4.8)
Origin IGP, metric 11340, localpref 100, valid, external
Dampinfo: penalty 492, flapped 1 times in 00:00:23
1 109, (received-only)
4.1.74.105 from 4.1.74.105 (4.0.4.8)
Origin IGP, metric 11340, localpref 100, valid, external
kenny>traceroute www.cisco.com
Type escape sequence to abort.
Tracing the route to www.cisco.com (198.133.219.25)
1 serial4-0-3.hsa1.nyc1.Level3.net (209.244.160.57) [AS 3356] 0 msec 0
msec 0 msec
2 hsipaccess2.Denver1.Level3.net (209.244.2.61) [AS 3356] 48 msec 48
msec 48 msec
3 hsipaccess2.Seattle1.Level3.net (209.244.2.23) [AS 3356] 76 msec 72
msec 76 msec
4 209.0.227.130 [AS 3356] 76 msec 200 msec 148 msec
5 sea-core-01.inet.qwest.net (205.171.26.53) [AS 209] 76 msec 72 msec
76 msec
6 sfo-core-02.inet.qwest.net (205.171.5.105) [AS 209] 84 msec 84 msec
84 msec
7 sjo-core-01.inet.qwest.net (205.171.5.121) [AS 209] 80 msec 80 msec
80 msec
8 sjo-edge-05.inet.qwest.net (205.171.22.46) [AS 209] 84 msec 84 msec
80 msec
9 a5-0-1.sanjose1-nbr1.bbnplanet.net (4.24.145.1) [AS 1] 84 msec 84
msec 84 msec
10 p4-0.paloalto-nbr2.bbnplanet.net (4.0.1.1) [AS 1] 84 msec 84 msec 84
msec
11 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) [AS 1] 84 msec 84 msec
84 msec
12 * * *
13 pigpen.cisco.com (192.31.7.9) [AS 109] 88 msec 88 msec 88 msec
14 www.cisco.com (198.133.219.25) [AS 209] 88 msec 84 msec 88 msec
A fix/explanation would be useful.
Regards,
Neil.
--
Neil J. McRae C O L T I N T E R N E T
neil@COLT.NET
