[166077] in North American Network Operators' Group
Re: Regarding source based outbound routing (with redundancy)
daemon@ATHENA.MIT.EDU (joel jaeggli)
Sat Oct 5 14:55:31 2013
From: joel jaeggli <joelja@bogus.com>
In-Reply-To: <CAL9jLaYNTt1Gqb61AvtLLezLuSdAWt8DHTs62vYAcTv9_8oxew@mail.gmail.com>
Date: Sat, 5 Oct 2013 11:55:09 -0700
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: NANOG Mailing List <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_3297AD07-F349-4B6F-A359-F3D545C3AEE4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Oct 5, 2013, at 11:43 AM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
> On Sat, Oct 5, 2013 at 2:08 PM, joel jaeggli <joelja@bogus.com> wrote:
>>=20
>> On Oct 5, 2013, at 9:45 AM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
>>=20
>>> you really don't want to do policy routing :(
>>>=20
>>=20
>> PBR has this tendency to be brittle in the face of topology changes.
>=20
> yup, exactly my point :(
>=20
>> There are much better way to outbound load-balance between providers =
offering same or similar quality routes to the same destination.
>>=20
>> multi-AS multipath will do that if the peers are on the same router. =
BGPaddpath
>> can do it for you if the peers are spread across routers.
>=20
> these both will require seeing the longer prefix from the right peer
> though, right? and selecting that would just be like natural selection
> anyway=85
so at this level if I can install two best paths in the fib then great =
I'll just hash flows between them=85 this does nothing for source based =
path selection but it does a lot for load-balancing between peers =
especially if there's substantial overlap of equidistant paths. If you =
have say 2914/3356 and you look at the amount of traffic that you can =
load-balance between them instead of simply tie-breaking on router-id or =
however far do your path algorythm you get, it's significant enough to =
matter.
> yikes, I suppose you could:
> 1) generate the longer prefix internally
> 2) set it's next-hop to something reachable out both (all) peers
> 3) metric the preferred peer's next-hop appropriately
> 4) profit
>=20
> but that sounds also kind of messy and prone to odd failures when
> changes are made :(
I go for the low hanging fruit, which is better usage of the information =
I already have.
> you'd be adding complexity that you'd have to track through the life
> of your network :( (and explain to anyone 'not you' working on the
> network)
>=20
> -chris
>=20
>> joel
>>=20
>>> On Sat, Oct 5, 2013 at 12:19 PM, Anurag Bhatia <me@anuragbhatia.com> =
wrote:
>>>> Hello there!
>>>>=20
>>>>=20
>>>> I am trying to do a source based outbound routing between multiple
>>>> upstreams. Usually I picked outbound via localpref but here I wish =
to use
>>>> Provider 1 for say 10.10.10.0/24 while provider 2 for small chunk =
of it say
>>>> 10.10.10.0/28. I wish to keep failover support and thus so if =
provider 2
>>>> fails, I wish to push traffic again via Provider 1.
>>>>=20
>>>> Is this is possible only with VRF or I can push for some specific =
match
>>>> rule in route maps?
>>>>=20
>>>>=20
>>>>=20
>>>> Thanks.
>>>>=20
>>>> --
>>>>=20
>>>>=20
>>>>=20
>>>> Anurag Bhatia
>>>> anuragbhatia.com
>>>>=20
>>>> Linkedin <http://in.linkedin.com/in/anuragbhatia21> |
>>>> Twitter<https://twitter.com/anurag_bhatia>
>>>> Skype: anuragbhatia.com
>>>=20
>>=20
>=20
--Apple-Mail=_3297AD07-F349-4B6F-A359-F3D545C3AEE4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iEYEARECAAYFAlJQYI0ACgkQ8AA1q7Z/VrJ1OwCZAQrrG0IsFyZzR1uvLoVUqbjT
K3UAn3uzCJtywiD2KKzQxe/YJpy+YvqZ
=8t+q
-----END PGP SIGNATURE-----
--Apple-Mail=_3297AD07-F349-4B6F-A359-F3D545C3AEE4--
