[c-nsp] BGP failover for two traffic types

[Ivan Pepelnjak]

Are the VOICE and DATA traffic going to distinct servers? If that's the
case, you can tweak the BGP route selection policy on the CE router. See
this article for an example (not too far off from what you're looking for):

http://www.nil.com/ipcorner/ScalablePolicyRouting/

If you cannot distinguish VOICE and DATA based on destination addresses,
policy routing is the next obvious option (we all love to hate). OER might
also work, but I haven't worked with it enough to have an informed opinion
(another technology way too long on my to-do list).

Ivan
 
http://www.ioshints.info/about
http://blog.ioshints.info/

> -----Original Message-----
> From: Adam Greene [mailto:maillist at webjogger.net] 
> Sent: Thursday, July 23, 2009 1:55 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] BGP failover for two traffic types
> 
> Hi,
> 
> I have a CE router doing eBGP peering with two of my PE 
> routers over distinct WAN circuits. The CE router services 
> two netblocks on its LAN
> interface: one is for VOICE, the other (secondary IP address) 
> is for DATA.
> 
> I want the customer's DATA traffic to flow to/from PE1 by 
> default, and voice traffic to flow to/from PE2 by default. In 
> the event of an outage on one of the circuits, I want all 
> traffic to flow over the circuit that's still up.
> 
> I already know how to manipulate the traffic inbound to the 
> CE router in this way, using conditional BGP advertisements. 
> However, I can't figure out how to make the customer's 
> outbound traffic prefer one link or another depending on 
> whether it's DATA or VOICE, except by using route-maps, and 
> those don't play nice as far as failing over to a backup link 
> if the primary link is down.
> 
> I've toyed with the idea of trying to use VRF for this 
> application, but I'm pretty new to it and don't know if it's 
> really a viable approach.
> 
> Interested in ideas ... should I attempt a solution based on 
> VRF? Or maybe there is a simpler solution ....
> 
> thanks,
> Adam 
> 
> 
> 
>