[c-nsp] Growing BGP tables

[Joe Maimon]

Jon Lewis wrote:

>On Fri, 28 Jan 2005, Joe Maimon wrote:
>
>  
>
>>>That's incredible.  I can't believe that so few people would see the
>>>benefit in this.  I know one of those attachments was mine.
>>>      
>>>
>
>  
>
>>This is something discussed a while back, how to deal with those who
>>insert more specifics, right?
>>This was also mentioned as neccessary to avoid the loophole in Team
>>Cymru bogons, correct?
>>    
>>
>
>I think these are two similar but very separate issues being talked about
>together, when maybe they shouldn't.
>
>In the bogons case, I'd love to be able to take a bogon feed from a
>trusted source (i.e. team cymru) and have those routes put in the table as
>"special poison routes".  I don't ever want another peer to be able to
>advertise any of those routes or more specifics, and if they do, I want to
>ignore those routes.  The same logic could be applied to abusive networks
>you don't want to exchange traffic with.
>
>  
>
This is just a less special-case then the below, its the same concept. 
Here you wish to ignore ALL more specifics, below you wish to ignore 
more specifics that have either same next-hop, same as-path or whatnot. 
But still, when Team Cymru withdraws the bogon, you want the decision 
process to kick in for any routes you had received that were previously 
more specific.

Really you wish to tag what other routes will match the ones you receive 
based upon the peer you learned them from. Any routes learned from bogon 
servers would be tagged as matching any route thats more specific.

>The more general issue of ignoring more specifics for those who announce
>CIDRs and subnets of them for no obvious (or operational to me) reason is
>far more complicated as ideally you'd like the previously ignored more
>specifics to magically resurface if the aggregate route disappears.
>  
>
1) The decision process should select them as best routes, nothing 
magical about that.
2) at that point, and not previously, is when they will be advertised to 
peers.

>If we treat these as separate issues/features, would it be that hard to
>have a route-map match statement in the very near future that could check
>incoming routes against a certain set of routes (perhaps by the next hop
>IP of the already installed routes) and reject them based on that?
>
>i.e.
>Assume I have a feed of bogon routes and have their next-hop IP set to
>192.0.2.1.
>
>route-map blah-input deny 10
> match existing-next-hop 192.0.2.1
>route-map blah-input permit 20
>....
>
>That doesn't seem like it'd be rocket science to implement...but then I've
>never seen cisco's BGP code.
>
>----------------------------------------------------------------------
> Jon Lewis                   |  I route
> Senior Network Engineer     |  therefore you are
> Atlantic Net                |
>_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>  
>