|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: URPF on small BGP-enabled customers?
I guess it's been a while since I've played with it, but isn't this pretty
well what happens with uRPF anyhow?
The asymmetric routing problem is illustrated ascii stylee below.
AS1
/
ASYOU - AS-OTHERGUY
\ /
CUSTOMER
Say somebody in AS1 wants traffic from your customer. The request comes in
through you, and to your customer. For whatever reason (internet exchange
peering is more attractive to the customer, whatever - the point is, ignore
the AS-path, because the customer has fiddled with their traffic - ie:
always follow the money) their return traffic is going via AS-OTHERGUY.
Their shortest path to AS1 is through you, so they throw the return traffic
your way. Of course, your routing table resolves the best path for all
customer routes to AS-CUSTOMER, so it drops all traffic coming in from
AS-OTHERGUY.
I don't think your solution would fix that, as AS-OTHERGUY's announcements
would have a longer AS-path than your direct peering with the customer.
(I reserve the right to be totally wrong and have completely misunderstood
all mechanisms involved, btw ;) )
Internet
[email protected] - 03/06/2005 14:58
To: Christian MACNEVIN
cc: christopher.morrow, will, nanog
Subject: Re: URPF on small BGP-enabled customers?
[email protected] wrote:
> At an old transit provider I was at, we had a pig of a time dealing with
> uRPF. It doesn't like asymmetric routing at all, which is commonplace
when
> you've got customers homed at exchange points for one.
This is why I say there should be a feature that will work like a dynamic
ACL but is fed from BGP. All the prefixes you learn from customer A via
BGP are put into an automatic ACL, default is deny. Then you apply this
dynamic ACL to the interface the customer is connected to. Of course it
still doesn't work if you send traffic from prefixes you don't announce but
for 70-80% of the cases it's a big step forward in automation. This also
gets rid of any differences between ACL on the forwarding plane and on the
routing protocol plane. All prefix filters are defined in BGP
configuration.
Forwarding layer follows and never gets out of sync again.
Random example syntax:
router bgp 65500
neighbor 192.168.2.2 remote-as 65501
neighbor 192.168.2.2 dynamic ACL 10001 receive #put received prefixes
here
neighbor 192.168.2.2 prefix-list CUST65501
... #usual stuff
#only this one is controlled
ip prefix-list extended CUST65501
permit ip 172.16.0.0/16 any
permit ip 10.0.0.0/8 any
#ACL on interface follows BGP received prefixes
interface f0/0/0
ip access-group 10001 in #same as in BGP neighbor config
And Voila! Problem automagically solved.
--
Andre
This message and any attachments (the "message") is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
**********************************************************************************************
BNP Paribas Private Bank London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Securities Services London Branch is authorised
by CECEI & AMF and is regulated by the Financial Services
Authority for the conduct of its investment business in the
United Kingdom.
BNP Paribas Fund Services UK Limited is authorised and
regulated by the Financial Services Authority.
|