[c-nsp] Basic inbound BGP path preferencing query

[Joshua Riesenweber]

Hi all,
Thanks for all the replies, I had a feeling that with a single /24 there would be very little I could do. 
I had a  read through this doco, which described the scenario I'm talking about.http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13762-40.html#conf5

They also suggest the way to do it is with AS-path prepend, but in the example they use x2 /24 subnets.
I will look into a /23 and try my luck.


Cheers,Josh


> From: Steve.Housego at itps.co.uk
> To: joshua.riesenweber at outlook.com; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] Basic inbound BGP path preferencing query
> Date: Tue, 27 Jan 2015 14:52:04 +0000
> 
> You could always use an as-path prepend,
> 
> Announce yours routes with the same prefix from both connections
> 
> route 1 would show as AS123 AS5089 AS-XX
> route 2 would show as AS123 AS123 AS174 AS-XX
> 
> This allows more traffic to come in via route 1, whilst still utilising
> route 2, (you can also add multiple pre-prends if required). For example
> AS174 will prefer customer routes so traffic from as174 to your as123
> should always come in that path. Any of AS174¹s peerings may prefer that
> route if they don¹t also peer with AS5089 for example.
> 
> This obviously only works per entire subnet rather than individual IP¹s
> but it still allows you to utilise both links un-equally (if that¹s a
> word? :).
> 
> SteveH
> 
> 
> -----Original Message-----
> From: Joshua Riesenweber <joshua.riesenweber at outlook.com>
> Reply-To: "joshua.riesenweber at outlook.com" <joshua.riesenweber at outlook.com>
> Date: Tuesday, 27 January 2015 01:28
> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
> Subject: [c-nsp] Basic inbound BGP path preferencing query
> Resent-From: Steve Housego <Steve.Housego at it-ps.com>
> 
> >Hi all,
> >I'm looking for a bit of insight from someone with more BGP experience
> >than me. (I've tried searching around the 'net trying to find an elegant
> >solution.)
> >I have the common enterprise configuration of 2x WAN links multi-homed
> >with 2x ISPs. I have a single /24 public IP allocation being advertised
> >out both links, and are using MEDs  to preference one link.
> >I'd like to load balance across both links, unfortunately, one link is
> >lower-bandwidth and has a smaller data quota from the ISP.One simple
> >solution is upgrading to a /23. Then I can preference a unique /24 subnet
> >over each link, and assign the large bandwidth-consuming devices to that
> >particular subnet on my better WAN link.
> >My only hesitation is that configuration potentially uses more IP
> >addresses than I need. Does anyone have any tips on preferencing certain
> >IP addresses inbound through one link if I am only advertising a single
> >/24?
> >If there's a better way of doing this your ideas are welcome.
> >
> >Cheers,Josh
> >_______________________________________________
> >cisco-nsp mailing list  cisco-nsp at puck.nether.net
> >https://puck.nether.net/mailman/listinfo/cisco-nsp
> >archive at http://puck.nether.net/pipermail/cisco-nsp/
> 
> [http://www.it-ps.com/wp-content/uploads/2013/12/itps-logo.png]
> 
> "Helping Your ICT Budget Deliver to its Maximum Potential"
> 
> Steve Housego
> Principal Consultant
> 
> IT Professional Services
> Axwell House
> Waterside Drive
> Metrocentre East Business Park
> Gateshead
> Tyne & Wear NE11 9HU
> 
> T. 0191 442 8300
> F. 0191 442 8301
> 
> Steve.Housego at itps.co.uk<mailto:Steve.Housego at itps.co.uk>
> 
> 
> Check out our new website at www.it-ps.com <http://www.it-ps.com/> and see how we can help your IT budget deliver more for less.
> 
> [http://itpswebhost01.it-ps.com/customer_images/itps/twitter]<http://twitter.com/#!/itpsltd>  [http://itpswebhost01.it-ps.com/customer_images/itps/facebook] <http://www.facebook.com/pages/ITPS/180607505381380>   [http://itpswebhost01.it-ps.com/customer_images/itps/linkedin] <http://uk.linkedin.com/in/itpsltd>
> 
> Company No. 3930001<tel:3930001> registered in England
> VAT No. 734 1935 33<tel:734%201935%2033>
> 
>