[93461] in North American Network Operators' Group
Re: "Neighbor maximum-prefix" option on routers
daemon@ATHENA.MIT.EDU (Jeff Aitken)
Mon Nov 20 09:18:24 2006
Date: Mon, 20 Nov 2006 09:17:28 -0500
From: Jeff Aitken <jaitken@aitken.com>
To: Alexander Koch <efraim@clues.de>
Cc: nanog@nanog.org
In-Reply-To: <20061120085306.GA23127@shekinah.ip.tiscali.net>
Errors-To: owner-nanog@merit.edu
On Mon, Nov 20, 2006 at 09:53:06AM +0100, Alexander Koch wrote:
> Ain't that a bit over- engineered? If you have a prefix list
> (presumably to a customer) do you want to seriously shutdown
> the session when he sends you random prefixes because it is
> easy to break when you are new to it? Would create unneeded
> tickets I'd say. Prefix lists (exact match) with no max-prefix
> (as those are then rejected anyway) work fine here...
There are several direct applications in provider networks that Joe
alluded to, such as customer-triggered blackholes. However, if you're
going to let your customers deaggregate, you need some other way of
protecting your network from stupidity/maliciousness on your
customers' part. You might do something like this, in cisco-speak:
router bgp xxx
neighbor 1.2.3.4 remote-as yyy
neighbor 1.2.3.4 description my customer with ASN yyy
neighbor 1.2.3.4 prefix-list FROM-ASyyy in
neighbor 1.2.3.4 route-map from-cust in
neighbor 1.2.3.4 maximum-prefix 100
[...]
!
ip prefix-list FROM-ASyyy sequence 5 permit 10.0.0.0/8 le 32
ip prefix-list FROM-ASyyy sequence 10 permit 172.16.0.0/12 le 32
!
route-map from-cust permit 10
match community customer-blackhole
set ip next-hop <null0, or whatever>
set community no-export
!
route-map from-cust permit 20
match ip address prefix-list longer-than-/24
set community no-export
!
route-map from-cust permit 30
set community my-customer-route-community
!
Now, in addition to being able to announce his two aggregates, your
customer can announce more-specific routes (all the way up to /32)
to be blackholed or just for traffic-engineering purposes within your
network. However, you're still protected if he announces more than
his configured maximum number of routes (100 in this example).
To answer your question, yes I absolutely want to shut down a peering
session with a misbehaving ASN *regardless* of whether or not that ASN
is a peer or customer. The stability of my network (and therefore, my
ability to provide service to my other customers) depends on it.
--Jeff