Stuck with BGP.

Started by jericho, July 08, 2015, 09:10:54 AM

Previous topic - Next topic

jericho

Hi,

I'm struggling with what is probably a fairly trivial thing and would be grateful for any suggestions.

I have a BGP link (single router at each end, 2 links between them) to a data centre. The network design I've been handed by our architecture group states that under normal operations, link A should only be used by a small group of servers, with everything else using the other link instead. In the event of either link failing then just run everything over whatever link is still available.

All of the servers are on the same /26 subnet (which is what is being advertised), with the important ones spread across it rather than being grouped in any useful manner. The systems team are gradually moving them to a better arrangement.

At the moment I've got it working using static routes with higher priorities for the preferred route, but I'm sure there is a better way of doing it. I've been looking at route-maps and prefix-lists to try and change the local preference for certain hosts, but as the overall subnet is what is being advertised (and I can't change that) the match statement never seems to get picked up.

Does anyone have any better way of doing this, or am I better of sticking with the static routes?

Thanks in advance for any help.

J

Reggle

There are better ways... But personally: static is simpler for the time being and you can leverage the 'suboptimal-static-routes' configuration to put pressure on other teams to properly design the servers: one VLAN (or part of a subnet so you don't lose two IP addresses because of segmentation) for critical/application A, one for non-critical/application B.

jericho

Thanks, I'll stick as I am until everything is tidied up.

To save my sanity, am I on the right track with route maps & prefix lists?

wintermute000

#3
if this is not public (and I doubt it) where /24 is minimum and anything less than a /22 (from memory) gets a frown from **NOG mailing lists lol

Then you could just use a more specific advertisement for your small subset of hosts (host routes if required). If that link fails then the advertisement goes away.
You can get really fancy with inject maps, advertise maps and all the rest of that jazz.


PL/RM/localpref would work fine but a better design (almost always :) ) is to use communities to set localpref instead of prefix lists. much more scalable, and lets the sending site 'announce' the preference in effect.

LynK

Quote from: wintermute000 on July 09, 2015, 06:51:59 AM
if this is not public (and I doubt it) where /24 is minimum and anything less than a /22 (from memory) gets a frown from **NOG mailing lists lol

Then you could just use a more specific advertisement for your small subset of hosts (host routes if required). If that link fails then the advertisement goes away.
You can get really fancy with inject maps, advertise maps and all the rest of that jazz.


PL/RM/localpref would work fine but a better design (almost always :) ) is to use communities to set localpref instead of prefix lists. much more scalable, and lets the sending site 'announce' the preference in effect.

This is the best way of doing it. Create more specific routes for the intended servers, and whallah! the more specific = matched first. Pretty much what otanx said. But I wanna feel important too. :rock:
Sys Admin: "You have a stuck route"
            Me: "You have an incorrect Default Gateway"

Otanx

Quote from: LynK on July 09, 2015, 08:21:07 AM
Quote from: wintermute000 on July 09, 2015, 06:51:59 AM
if this is not public (and I doubt it) where /24 is minimum and anything less than a /22 (from memory) gets a frown from **NOG mailing lists lol

Then you could just use a more specific advertisement for your small subset of hosts (host routes if required). If that link fails then the advertisement goes away.
You can get really fancy with inject maps, advertise maps and all the rest of that jazz.


PL/RM/localpref would work fine but a better design (almost always :) ) is to use communities to set localpref instead of prefix lists. much more scalable, and lets the sending site 'announce' the preference in effect.

This is the best way of doing it. Create more specific routes for the intended servers, and whallah! the more specific = matched first. Pretty much what otanx said. But I wanna feel important too. :rock:

Man I need to stop drinking.  :cheers: I think he means what wintermute000 said.

jericho

Quote from: wintermute000 on July 09, 2015, 06:51:59 AM
if this is not public (and I doubt it) where /24 is minimum and anything less than a /22 (from memory) gets a frown from **NOG mailing lists lol

Then you could just use a more specific advertisement for your small subset of hosts (host routes if required). If that link fails then the advertisement goes away.
You can get really fancy with inject maps, advertise maps and all the rest of that jazz.


PL/RM/localpref would work fine but a better design (almost always :) ) is to use communities to set localpref instead of prefix lists. much more scalable, and lets the sending site 'announce' the preference in effect.

Nope, all private.

Unfortunately I don't have access to the other end of the link. The admins there don't seem to be particularly interested in talking to me either, so I've got to make it work with by playing round at this end only.

Thanks for the help.

J

NetworkGroover

Quote from: LynK on July 09, 2015, 08:21:07 AM
But I wanna feel important too. :rock:

Hahaha.... that's awesome. I'm sure that statement could be applied in many of our conversations - myself included...
Engineer by day, DJ by night, family first always

wintermute000

Don't forget return traffic, you might be forced to use pbr.

Sent from my SM-G920I using Tapatalk


FilipiNomad

Are you actually peered on both links?  Do you have two neighbor statements on each router?  One for each link.

jericho

Quote from: FilipiNomad on July 09, 2015, 07:12:12 PM
Are you actually peered on both links?  Do you have two neighbor statements on each router?  One for each link.
Yep, at least at my end. As I have two peering up I'm presuming its right at the other end as well.

Quote from: wintermute000 on July 09, 2015, 06:51:59 AM
You can get really fancy with inject maps, advertise maps and all the rest of that jazz.
I missed that line at first reading, but having just read up on inject maps and had a play, it now seems to be doing exactly what I want. Thankyou.

Quote from: wintermute000 on July 09, 2015, 06:11:30 PM
Don't forget return traffic, you might be forced to use pbr.
Fun, more research. Having said that, they were handed the same design docs by the architect, so hopefully they have got it sorted at their end. I've pinged them an email to check but as they have ignored every other attempt at communication over the last 2 months I'm not holding my breath.

Thanks again for the help.

Cheers

J

FilipiNomad

#11
You can advertise more specific routes for the small set of servers through Link A.  Then, you can advertise the /26 through both links but set a lower MED for the advertisements through Link B so that everything else goes through Link B.  All of these affect incoming traffic only.

Manipulating outgoing traffic based on source can be done with PBR, but I don't recommend it.  I try to avoid PBR at all cost except as a temporary solution.  If there's no need to manipulate outgoing traffic based on source, then I would stay away from it.  Use local pref instead to manipulate outgoing traffic based on destination.