I'm seeing the following in RouteViews (possibly since they started
getting data from paix):
route-views.oregon-ix.net>sh ip bgp 0.0.0.1
BGP routing table entry for 0.0.0.0/, version 19579757
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
6939 6461
216.218.252.152 from 216.218.252.152 (216.2t8.252.152)
Origin IGP, localpref 100, valid, external
6939 6461
216.218.252.145 from 216.218.252.145 (216.218.252.145)
Origin IGP, localpref 100, valid, external, best
Is this routeviews own set default or some other default route improperly
appearing in there (weren't routeviews filters supposed to filter out this
kind of all-net advertisements)?
P.S. And am I correct in assuming this 0.0.0.0/0 and not 0.0.0.0/8 route?
Nope to the former. Someone (6461) is advertising it. We
haven't traditionally filtered what we receive from our
peers. Note also that route views does not use routes from
the peers for forwarding traffic.
Dave
route-views.oregon-ix.net>sh ip bgp
...
* 0.0.0.0 216.218.252.152 0 6939 6461 i
*> 216.218.252.145 0 6939 6461 i
*> 1.0.0.0 64.50.230.1 0 4181 65333 i
route-views certainly carries some interesting data. 
6939 buys from 6461 yes? I don't see this from a 6939 peer or from any
6461 customers, sounds like an internal route of 6939 to me.
Hate to follow up to myself, but as someone just pointed out, 65333 is the
cymru bogons server. I guess we all have to remember that people
contributing to route-views are usually sending "customer" feeds,
sometimes with their own internal goo or without stripping things like
private ASNs which they would normally do when facing peers or transits.
Hi, NANOGers.
] Hate to follow up to myself, but as someone just pointed out, 65333 is the
] cymru bogons server.
Woohoo, we're on route-views! We've made the big time! That
said, please remember to strip off such things with peers and
customers.
Thanks,
Rob.
In a message written on Thu, Dec 18, 2003 at 03:12:17PM -0800, David Meyer wrote:
Nope to the former. Someone (6461) is advertising it. We
Speaking for 6461, if a customer asks for a default route, we send
them one.
The {problem,cool thing} about route-views is many people send it a full
table. That can {cause all sorts of analysis problems,give you a view
into things you wouldn't normally see}. YMMV.
We give a full view of our internal BGP routing table to RouteViews.
Anyway, we normally don't carry 0.0.0.0/0 internally, we've now filtered
it. We don't normally receive 0.0.0.0/0 on any of our backup transit
sessions, apparently it was configured on a new session by default.
I'm seeing the following in RouteViews (possibly since they started
getting data from paix):
route-views.oregon-ix.net>sh ip bgp 0.0.0.1
BGP routing table entry for 0.0.0.0/, version 19579757
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
6939 6461
216.218.252.152 from 216.218.252.152 (216.2t8.252.152)
Origin IGP, localpref 100, valid, external
6939 6461
216.218.252.145 from 216.218.252.145 (216.218.252.145)
Origin IGP, localpref 100, valid, external, best
Is this routeviews own set default or some other default route improperly
appearing in there (weren't routeviews filters supposed to filter out this
kind of all-net advertisements)?
P.S. And am I correct in assuming this 0.0.0.0/0 and not 0.0.0.0/8 route?
--
William Leibzon
Elan Networks
william@elan.net
+----------------- H U R R I C A N E - E L E C T R I C -----------------+
Rob,
Congratulations... You've become THE ASN that routes THE internet!!
I bet that must be worth some CVVs.
Owen
That brings up a question for me (and possibly others) whi try to use
routeviews for research purposes and need to determine if some route is
"real" the net (I realize everyone has different view of "real" internet -
view being both bgp term and general expression. I prefer widest view,
i.e. routes seen by end users at least somewhere)
So far I used simple/no algorithm when parsing routeviews data and took all
routes from there. Obviously this is not working very well with these kind of
private leaks.
So, any suggestions, if I should do any of the following:
1. Only routes that appears on routeviews from all peers
2. Only routes that appears from at least two peers in routeviews
3. Only routes that appears from x number of peers, where x is determined
as some percentage of peers routeview has in that particular dump
What would good percentage be then?
4. Some other way to get rid of leaked default and similar known errors.
And I'm curious what others are doing in this regard when using routeviews
data. For example when routeviews is providing dns ip->asn resolution,
what route(s) are being used there?