Are any other L3 customers seeing the large number of /25 and smaller routes from L3? I'm seeing almost 2500 of these routes in 4/8, some but not as many in 8/8 and still more in L3's non-US allocations. Looking at the AS paths for a handful of those specific networks I only see them via our L3 connection and not via our other 2 upstreams. I'm seeing paths to the larger aggregate networks via our other upstreams of course; the Oregon and AT&T route servers see the same aggregates too. To be more accurate we actually touch L3's acquisition form a year or so ago, Telcove (19094). All of the small routes are originating from L3 though (3356).
Best I can tell L3 is aggregating before it advertises to a peer but not before it advertises to a customer. Or, on the otherhand, perhaps L3 is advertising without aggregation to Telcove and Telcove is not aggregating before advertising to us.
So, that said, what is everyone else doing to perform sanity checks on their learned routes? Are a good many implementing RIR filtering and dropping everything smaller than a /24? L3 of course isn't the only source of these tiny routes but it's so obvious I saw it and wasn't even looking for it. This would explain why I'm getting so many more routes from L3 too. I'm getting 232k from AT&T, 233.5k from Cox and 244k from L3.
Thanks
Justin
We're getting 231740 routes from Level(3) at this moment.... hit me
offline with some specific prefixes and I'd be happy to share what we
see...
Paul Stewart
Senior Network Administrator
Nexicom
5 King St. E., Millbrook, ON, LOA 1GO
Phone: 705-932-4127
Web: http://www.nexicom.net
Nexicom - Connected. Naturally.
Justin Shore wrote:
So, that said, what is everyone else doing to perform sanity checks on their learned routes? Are a good many implementing RIR filtering and dropping everything smaller than a /24? L3 of course isn't the only source of these tiny routes but it's so obvious I saw it and wasn't even looking for it. This would explain why I'm getting so many more routes from L3 too. I'm getting 232k from AT&T, 233.5k from Cox and 244k from L3.
Two sides to this coin:
1) ProviderX (L3 in this case) is allowing you to see some of their internal routing information. If by chance those more-specifics come with MED and you have multiple connections to them, you can choose to make intelligent routing decisions via MED. You could have circuitous routing though, should you not get the more-specifics over a subset of your connections
2) ProviderX is demonstrating their incompetence in routing and filtering. This is just an inkling of the goofy stuff and potential landmines lurking within their network. You should open tickets, escalate to management, and abandon this provider ASAP.
Reality? Probably middle ground here. You could choose to filter them by prefix length and let it be, or _ask_ them what's up.
My $0.02,
Pete
Are any other L3 customers seeing the large number of /25 and smaller
routes from L3? I'm seeing almost 2500 of these routes in
4/8, some but
not as many in 8/8 and still more in L3's non-US allocations.
I am pretty sure that L3 allows anything up to a /28 (they used to,
anyway, from my old notes on their policy) on customer peering sessions.
It may be /25 now. Non-peering sessions explicitly disallow anything
longer than a /24, according to 'whois -h whois.radb.net as3356':
remarks: The following import actions are common to every
remarks: Level 3 non-customer peering session:
...
remarks: - Prefixes shorter than /8 or longer than /24 are
remarks: not announced.
Global Crossing does the same, as do many other providers. Best thing
is to just deny anything longer than /24 at your border if you do not
have multiple egress points to this one provider. To be sure they are
customers, check the community string to see if it is 3356:123.
-evt
I don't think it's option 1. We've been a direct Level3 customer for several years and though we're not filtering on RIR minimums yet (ask me again in January 
we do have some basic sanity filtering in place. Level3 isn't sending us anything longer than /24 and hasn't at least in recent history (according to my distribute-list).
This was an isolated error which has been fixed and safeguards added to prevent it from happening again. Normally we do not announce anything larger than /24 to any eBGP neighbor and we accept down to /32 from customers assuming the prefix is registered.
-Kevin (Level3)
Just to followup with the list, there was a small omission in the filtering of the routes on our peering session. That accounts for the more specific routes we were seeing. L3 made the filtering change on their side and we're back down to within a percent or less of our other BGP peers. It wasn't hurting us; our hardware isn't up against any resource limits; I just happened to notice it and thought I'd take the opportunity to inquire about RIR filtering with the group. Thanks for the quick work on this one, Roy and Kevin.
I am still interested in implementing some minimum allocation filtering on our borders. I can't think of any reason to accept anything below the minimum of a /24. Can anyone else? None of the DNS root servers are on anything smaller than a /24 are they? Does anyone have any suggestions for implementing this in a sane manner? I'm assuming matching 0.0.0.0/0 ge 24 would be sufficient unless there are some exceptions like perhaps the root servers.
Thanks
Justin
Justin Shore wrote:
Hello,
Is any MXLogic Mail admins subscribed to this list, or anyone who has a contact inside MXLogic that can contact me off list? Multiple outbound gateways have been having problems with the MXLogic inbound servers over the past few days and the tier1 support continues to say that our IP's are not on their blacklists and that there shouldn't be anything wrong.
Thanks for the help!
-Ray
inbound servers over the past few days >and the tier1 support
continues to say that our IP's are not on their blacklists and that
there shouldn't be anything >wrong.
What IP addresses and what does the banner say on drop?
-M<