What's the general consensus (hah! ;) regarding the use of RFC5291 BGP outbound route filtering? It's worked well for me in the lab, but I have yet to use it in a live environment (and I don't know that most service providers would know what I was talking about if I asked for it). Does it work great or does it end up being more pain than it's worth? Thanks :w
On 31 May 2012, at 18:18, Wayne Tucker wrote:
What's the general consensus (hah! ;) regarding the use of RFC5291 BGP outbound route filtering? It's worked well for me in the lab, but I have yet to use it in a live environment (and I don't know that most service providers would know what I was talking about if I asked for it). Does it work great or does it end up being more pain than it's worth?
Hi Wayne, In my experience, ORF is not particularly widely deployed in live network deployments. It has some potential to be difficult to manage where implementations begin to experience complexities in building UPDATE message replication groups (where peers have a dynamic advertisement (egress) policy due to ORF, then this may mean that the number of peers with common UPDATE policies reduces, and hence concepts like policy-driven UPDATE groups become less efficient). This may impact the scaling of your BGP speakers in ways that are not easy to model - and hence may be undesirable on PE/border devices where control-plane CPU is a concern. Further to this, there is, or has been, some disconnect in the modes of ORF that are supported between various speakers - for instance, some vendors support only prefix-based ORF, where others support only RT-based, which causes some barriers to implementation. In an inter-domain context, I have seen some discussion of ORF as a means by which an L3VPN customer may choose to receive only a subset of their routing information at particular "low feature" sites - but the inter-operability issues mentioned above resulted in this not being deployed. Do you have a similar deployment case? Cheers, r.
On Thu, May 31, 2012 at 10:59 AM, Rob Shakir <rjs@rob.sh> wrote:
It has some potential to be difficult to manage where implementations begin to experience complexities in building UPDATE message replication groups (where peers have a dynamic advertisement (egress) policy due to ORF, then this may mean that the number of peers with common UPDATE policies reduces, and hence concepts like policy-driven UPDATE groups become less efficient). This may impact the scaling of your BGP speakers in ways that are not easy to model - and hence may be undesirable on PE/border devices where control-plane CPU is a concern.
Makes sense - ORF would reduce the net amount of processing required, but puts more of it on the advertising side.
In an inter-domain context, I have seen some discussion of ORF as a means by which an L3VPN customer may choose to receive only a subset of their routing information at particular "low feature" sites - but the inter-operability issues mentioned above resulted in this not being deployed. Do you have a similar deployment case?
My deployment case is as an end user of multiple ISPs. At previous jobs (at service providers) I got used to the flexibility provided by multiple full tables, but at this job I don't have the budget for hardware that's really designed to handle that. Without ORF, my choices are: 1.) default prefixes only Way too little control for my taste. I'm stuck either letting it pick one "best" 0/0 to use or tweaking the config so that I can do ECMP (which freaks out support staff when their traceroute bounces around). 2.) default + subset (such as customer routes) Better than #1, but less flexible if I want to steer a prefix anywhere other than to a service provider which is advertising it to me. 3.) default + full Flexible in that I can filter what I accept and still rely on the 0/0 prefix for "full" reachability. The control plane on my routers can handle that many prefixes in memory, but it bogs them down a bit and I have to be careful of how many prefixes I let into the forwarding table. Thanks for the input. It sounds like ORF could be viable, but only if the service provider is amenable and the equipment is compatible. :w
participants (2)
-
Rob Shakir -
Wayne Tucker