Bad routes update

[Robert Rockell]

After tearing down my inbound filter to only ONE peer of all of my pTLA
peers, I see the following bad routes (as path withheld to protect poor
non-filtering transit party that I used :)  )


block				Most downstream AS (not full path)
-----------------		----------------------------------
3FFE:400:1C0::0/48              8319
3FFE:900:1::0/48		1312
3FFE:900:2::0/48		3899
3FFE:902::0/32			8664
3FFE:F00:2::0/48		11261
3FFE:1108:40A::0/48		5539
3FFE:1108:1400::0/40		704
3FFE:2024:1::0/48		1205
3FFE:202A:1::0/64		1836
3FFE:2401::0/32			2118
3FFE:2610:2::0/48		8432
3FFE:2610:5::0/48		5469
3FFE:2620::0/32			1741
3FFE:2802::0/32			1312
3FFE:2900:5::0/48		1312
3FFE:2900:FFE1::0/48		4768
3FFE:2D00:2::0/48		3323
3FFE:2D00:3::0/48		8643
3FFE::0/16			2497 (prepended)


While this is a small list when considering every member of the 6bone, this
will obviously not scale should content on the 6bone become important.

Note: not all bad prefixes are leaking from the PTLA who owns that prefix.
For instance, the 3ffe:2900 prefix is coming from a customer of
3ffe:2900::/24 who is multihomed, but their other upstream is allowing this
prefix to be advertised. This is the case for many of them, BUT NOT ALL.

PTLA's: Please fix the easy ones, and pressure other pTLA's to fix the ones
that are out of your hands.

3ffe::/16 .... enough said. Please have this removed. You are offically
acting as default route (effectively) to 6bone. We appreciate it, but please
refrain. 

A couple suggestions to people who are concerned about fixing this (everyone
should be).

Rob's diatribe on how to stop this from happenning.
--------------------------------------------------


I. If you redistribute static/connected routes into bgp

1.tag [static connected] routes with a community, and filter on that 
community at your edges

-or-

2.try to aggregate via an access-list

Examples:
---------
I apologize for the cisco-centric configuration suggestions. Feel free to
port them to your bgp speaker and post them to the list.

1.
ipv access-list aggreagte permit any (0::0/0)
route-map aggregate-today permit 10
match ipv address aggregate
set community <as>:123

router bgp <as>
redistribute static route-map no-statics-out

then on your outbound filter:

ipv community-list 1 deny <as>:123
ipv community-list 1 permit .*

route-map filter-out permit 10
match community 1
set metric <internal> (insert transitive attribute tweaks here)

(note: the "match any and tag" technique works in v6 but not v4...
aggregation model says that for no reason should you route other people's
space, if you are a pTLA, unless it is a transit aggregate, and these SHOULD
NOT be static)



2. (this one is harder, and may not be possible with the given implemtations
of bgp4+ and access-lists that I have seen)

ipv prefix-list aggregate deny <prefix> le <prefix length - 1>

route-map aggregate-toady permit 10
match ipv prefix aggreagte
set <whatever> <however>

and apply it outbound.

#1 is more scalable, at least in my opinion. it also allows for a more
stable IBGP, especially since most people are running IBGP as their sole IGP
(RIP only carries you so far before one gets angry).

=================================================
II. If you are multi-homed:

Filter Outbound, please. It is simple.

ipv access-list firstprovider permit <provider one prefix>::/<length>

ipv access-list secondprovider permit <other prefix>::/<length>


Then simply

route-map <provider>-out permit 10
match ipv address <[first second] provider>
set attribute here




Bob, et al,

do we think there needs to be something more stringent in place for
providers who are allowing transit stray prefixes from other providers to
get injected into their IBGP and thus into EBGP (when I am multi-homed, and
send prefix A up provider B's pipe, and they accept it). 

When Ipv6 goes live, unless business is more good-willed than it is now,
this is going to break things, and one pTLA may not have much motivation to
fix the problem (unless flames on the 6bone mailing lists really hurt).

Anyway, if you've gotten this far, thanks for reading. Anyone who can
program their way out of a box, perhaps an expect script to pull this stuff
out and publish a report once a week would be nice. However, if someone is
going to knock down their filters temporarily to see the nastiness in the
6bone, they have to make sure their customers and peers do not see if for
that time period.



Thanks
Rob Rockell
Sprintlink Internet Service Center
Operations Engineering
703-689-6322
1-800-724-3329, PIN 385-8833
Ines|e gnyne qh vagr bz s|e Ino ngg una {e hgr bpu plxyne?