I am in the process of turning up a new transit connection with SprintLink. My
network is a multi-homed stub AS and I only announce 5 prefixes. Having the bright
idea to incrementally move some traffic onto the new line I didn't announce all 5
immediately and I localpref'd ^1239$ to get some outbound traffic moving -- and the
result is of course that they drop any of my outbound traffic sourced from prefixes
I'm not announcing yet. This really smells like URPF but of course nobody at Sprint
has even confirmed that they are actually dropping packets.
This is new to me, but I haven't bought any new transit in the past 18 months -- is
this common practice on multihomed BGP customers now? I could force things to work
by always advertising all my prefixes out to them with the obvious downside of
living in fear of my outbound traffic being dropped if I ever need to withdraw any
of them.
If they're paranoid enough to manually filter my BGP announcements it's not much
more work to manually filter my source addresses too (nevermind the fact that I
already do it myself, but...)
I'm working through the SprintLink noc/support process but I'm surprised this
hasn't happened to any of their other customers before now.
I am in the process of turning up a new transit connection with SprintLink. My
network is a multi-homed stub AS and I only announce 5 prefixes. Having the bright
idea to incrementally move some traffic onto the new line I didn't announce all 5
immediately and I localpref'd ^1239$ to get some outbound traffic moving -- and the
result is of course that they drop any of my outbound traffic sourced from prefixes
I'm not announcing yet. This really smells like URPF but of course nobody at Sprint
has even confirmed that they are actually dropping packets.
They might not, or the person in tech support might not know what you are
asking about... if its part of the 'standard config template' chances are
high there are LOTS of folks who don't know what it is or does
If they're paranoid enough to manually filter my BGP announcements it's not much
more work to manually filter my source addresses too (nevermind the fact that I
already do it myself, but...)
the want to avoid manually filtering source addresses is exactly why uRPF
was brought into existence (one of the reasons atleast). It's lower
impact, on some cards/chassis/os's, than actual filters and certainly
lower management headache to maintain. Keep in mind that sprint has
probably a few hundred interfaces on that one router, with a few thousand
routers (atleast, again I'm not a sprint person) with similar interface
counts... managing acls on a hundred thousand interfaces (non-standard
acls) isn't a simple task.
I'm working through the SprintLink noc/support process but I'm surprised this
hasn't happened to any of their other customers before now.
perhaps other customers just announce their /24 to each provider and don't
care about traffic engineering? or they atleat announce the depref'd
routes incase of failure?
This is new to me, but I haven't bought any new transit in the past 18 months -- is
this common practice on multihomed BGP customers now? I could force things to work
by always advertising all my prefixes out to them with the obvious downside of
living in fear of my outbound traffic being dropped if I ever need to withdraw any
of them.
I (a network much, much smaller than Sprint) do uRPF on all ports, but also inform BGP customers (nine-page handoff documentation) that they are uRPFed. However, in conjunction with community support for adjusting localpref, we set a sufficient weight on the announcement so that the edge node sees the customer link as preferred even if the rest of our network doesn't, and therefore the uRPF check passes.
I don't think advertising more-specifics through other connections would actually work, as the Sprint edge router would still want to reach the more-specifics through the Sprint network, rather than the customer link. It's all a matter of what the FIB says.
This is new to me, but I haven't bought any new transit in the past 18 months -- is
this common practice on multihomed BGP customers now? I could force things to work
by always advertising all my prefixes out to them with the obvious downside of
living in fear of my outbound traffic being dropped if I ever need to withdraw any
of them.
I (a network much, much smaller than Sprint) do uRPF on all ports, but also inform BGP customers (nine-page handoff documentation) that they are uRPFed. However, in conjunction with community support for adjusting localpref, we set a sufficient weight on the announcement so that the edge node sees the customer link as preferred even if the rest of our network doesn't, and therefore the uRPF check passes.
This sounds like the better approach. Although this is still not strictly what the customer want, because all peers of the same edge will prefer the edges path.
