Re: Long AS Path

[Ryan L]

I didn't see anyone answer (sorry if I missed it and this is redundant) ...

In the path selection algorithm, local preference is processed before
AS-PATH.

Within your provider's AS, your prefixes could be a default localpref of
100, and learned prefixes from their peers 85, for example. In this case,
Intra-AS will always be preferred due to higher lpref.

You may prepend a handful of times out of your connection that is within
the provider's AS, thus making the overall AS-PATH longer, but localpref
still remains 100 vs. peer 85, so intra-AS still preferred.

Some providers allow you to send community attributes with your prefixes to
modify the localpref within the provider AS and make it lower than their
peer localpref. Solves this particular conundrum.

Couple examples:

https://onestep.net/communities/as3356/
https://onestep.net/communities/as1299/

Depending on your allocation size and your needs, if you wanted to force
all traffic over the "fast" link and use the "slow" link as an emergency
backup, it could be easier to just announce more specific routes out the
faster connection and send an aggregate out the backup one. No communities
needed in that scenario. All depends on what you need to do, of course.

HTH,
Ryan


On Thu, Jun 22, 2017 at 9:29 AM, Stephen Satchell  wrote:

> On 06/22/2017 04:27 AM, Jon Lewis wrote:
> >
> > You do have to wonder, what was the thought process that resulted in 35
> > being the right number of prepends "accomplish" whatever TE they were
> > shooting for?
> >
> > AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644
> > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
> > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
> > 55644 55644 55644 45271
> >
> > I don't mean to single out 55644.  It's just the first/most obnoxiously
> > long as-path I found when looking for long ones.
> >
> > I seriously doubt provider/customer/customer-of-customer relationships
> > ever get much deeper than a handful or so of ASNs...so if prepending a
> > few times doesn't get it done, 10-20-30 prepends are unlikely to help.
> >
> > In the above case, that long path is actually our best path.  We
> > localpref peering above transit.  So, it doesn't matter how many
> > prepends, they add, we're never going to not use this path if its
> > available.  We have transit paths to these routes that are only a single
> > handful of ASNs long.
>
>
> I think I understand the problem, and now I understand why prepends
> didn't do much for me.  Over the years, I tended two multi-homed sites.
> In both cases, the two uplinks had different speeds.  When I used
> prepend to try to get the outside world to prefer the faster link, some
> traffic was stubborn about coming in the slow one.
>
> Difference in speeds?  In the first network it was 45 mbps and 10 mbps.
> In the second network it was 16 mbps and 1.5 mbps.  Both network owners
> were too stingy at the time to opt for harmonized rates.
>
> Question:  how could communities be used to "force" preference for one
> uplink over another by the peers?  I'm long past needing this, but
> others might benefit.  (And when you stop learning, you're dead.)
>

Re: BFD on back-to-back connected BGP-speakers

[Ryan L]

Hugo, I think those are all valid potential reasons to use BFD. I use it
for some of the same reasons even on direct connect peers.

Only time I ever recall actively avoiding it if I had the capability was if
I had NSF/SSO, since they didn't used to (still don't?) play very well
together.

On Tue, Nov 29, 2016 at 1:23 PM, Hugo Slabbert  wrote:

> Good morning, nanog,
>
> Is there any/sufficient benefit in adding BFD onto BGP sessions between
> directly-connected routers?  If we have intermediate L2 devices such that
> we can't reliably detect link failures BFD can help us quickly detect peers
> going away even when link remains up, but what about sessions with:
>
> - eBGP with peering to interface addresses (not loopback)
> - no multi-hop
> - direct back-to-back connections (no intermediate devices except patch
>  panels)
>
> Possible failure scenarios where I could see this helping would be fat
> fingering (filters implemented on one or the other side drops traffic from
> the peer) or e.g. something catastrophic that causes the control plane to
> go away without any last gasp to the peer.
>
> Or is adding BFD into the mix in this type of setup getting into
> increasing effort/complexity (an additional protocol) for dimishing returns?
>
> --
> Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
> pgp key: B178313E   | also on Signal
>
>

Re: nested prefixes in Internet

[Ryan L]

Hopefully they would be flexible with this sort of policy under certain
circumstances.

I could see this as being somewhat problematic for mitigation providers,
since longer mask preemption is a commonly used method to take on traffic
for scrubbing, as well as customers potentially using a more specific for
migration activity. Or heck, even a less corner case scenario of traffic
engineering to a particular location via more specific route.

To me, it just sounds like more headache than it may be worth to have to
deal with that sort of thing.


On Mon, Nov 21, 2016 at 9:08 AM, Victor Sudakov  wrote:

> Niels Bakker wrote:
> > >I have reports that in case (2), some operators (e.g. Rostelecom)
> > >don't accept the /24 or even /23 prefix on the grounds that it is
> > >part of a larger /19 route already present in the routing table.
> > >
> > >Could they have a reason not to accept these more specific prefixes
> > >other than a whim?
> >
> > If you announce a prefix you must deliver traffic sent to addresses
> > covered by it.  You don't go announcing 0.0.0.0/0 to your peers either.
> >
> > If a customer takes a /24 and announces it elsewhere, a transit
> > provider runs the risk of accepting inbound traffic without having
> > the possibility to bill their customer for it if it accepts more
> > specifics from e.g. a peer.
>
> That's all correct from the point of view of the provider annoncing
> the /19 route, and should be their risk.
>
> My question was however from a different perspective. If AS333
> receives a /19 from AS111 and a /24 from AS222 (where AS222's /24 is
> nested within AS111's /19), what reason might AS333 have to ignore the /24?
> AS333 is not concerned with possible monetary relations between AS111
> and AS222.
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:suda...@sibptus.tomsk.ru
>