Havard.Eidnes@runit.sintef.no wrote:
Last month I described the idea of an special prefix access list on de.comm.internet.routing that basically solves that problem.
The syntax would look something like this:
'access-list 1000 permit bgp-neighbor 1.2.3.4 received-networks' 'access-list 1100 permit bgp-neighbor 1.2.3.4 announced-networks'
It simply conscructs an automatic ip prefix access-list based on the prefixes received/announced to/from the BGP peer. This has the cute side effect that all ip filters can be done in one place; the bgp configuration.
Umm, how is this significantly different from doing RPF (Reverse Path Forwarding) checks for unicast packets, as I described earlier, and as already implemented by Cisco?
It allows asymetric routing.
If I understand what you're trying to do correctly, doing the "received-networks" would be to just turn on RPF checking on the incoming interface from the neighbor, while doing "announced- networks" will mean that you either have to make sure you have RPF checking on all your edges or that all interfaces on this particular customer access router has RPF checking turned on.
Well... What I imagine is an prefix based packet filter (no rule list). This would be as fast as the routing table lookup. Lets have a look what the router does with that feature: 1. ip packet comes enters through interface s0/0 2. ip packet source address gets checked against prefix filter. The prefix filter contains and allows only prefixes received from bgp neighbor 1.2.3.4 3. process the packet as usual
The 'permit received-networks' part looks pretty promising for an easy implementation because the router has to perform an bgp table lookup anyway for each incoming ip packet.
Um, that's not quite correct. The router does a forwarding table lookup for the destination address in each packet when doing packet forwarding; the forwarding table is being built from (among other sources) the BGP routing database.
Yes.
Doing the RPF check for unicast packets adds a second forwarding table lookup for each packet (look up the source and see if the packet entered on an interface where we have a route pointing back out), so it does have a cost, but demanding CEF (as Cisco does) reduces that cost over the other potential alternatives.
The problem with RPF is that as doesn't work in environments with asymetric routing. -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs@pipeline.ch