Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Community Member

BGP WAN issue: is it possible to selectively load-share routes between a Leased line and a DSL?

Hi All,

I have got a fairly complex issue, with a particular requirement.

I have a BGP/MPLS/VPN Core Network, with Core Routers CR0, CR1,,...,CR6.

A few vrfs are built on it; let's focus on vrf RED (that I will also call "Customer vrf").

A Customer router, a cisco CPE, is reached by 2 independent lines from my Core: a Leased Line (LL, an EFM presentation) that connects it directly to CR3, and a DSL that connects it to my Radius server, which then decides where to make it land; the DSL may land on CR0 (most probably), or also on CR1.

The CPE has got only 1 LAN Ethernet port, FastEthernet0/1 (for LAN range: 10.3.1.0/24).

It's got a WAN Eth. port for the EFM: FastEthernet0/0 (IP: 7.7.7.2/31, while the CR3's interface has got 7.7.7.3).

Connected on the other side of my MPLS Core NW, are some servers and firewalls for this Customer vrf; so when they need to reach the internet, they still pass through my MPLS Core, to go through their FWs (please ignore the direct lines in the diagram that connect CR3 and CR0 to the WWW: they are only for mind simplification of the picture).

Requirement: have the LL and the DSL always up at the same time; use the LL as primary to reach all the vrf intranet destinations (all EXCEPT TCP port 80), and use DSL as primary to use TCP=80 only.

But they also need to back each other up: if the LL goes down, the DSL will have to carry all the traffic, regardless whether it is for the WWW or not; and similarly if the DSL goes down, all traffic is to be carried by the LL.

Given the fact that also the Customer web traffic is to traverse my MPLS, I cannot simply identify web traffic as: default route (0.0.0.0 0.0.0.0); I instead must use extended ACL to identify TCP=80, as a Destination (in the direction: CPE -> WWW), or as a Source (for the direction: WWW -> CPE, the returning traffic).

I tried to imagine several different solutions; while it seems doable and pretty easy in the direction: CPE -> Core (i.e. policy routing, applying an inbound route-map on the LAN interface), the big problem is for the returning traffic.

CR3 can only make decisions based on BGP; CR0 has a per-user static route created by Radius, whose AD I can adjust; and this static route also gets redistributed into BGP. By doing so, it gets assigned some Communities, that unfortunately are necessary for my Core, and even more unfortunately they manipulate the Weight on all CR's that receive MP-BGP updates.

And CR0 also can learn the iBGP route via CR3 (and via the LL), with AD = 200 as usual.

The result is: if I allow the DSL static route to be written on CR0 with a smaller AD than 200, then it will go to CR0's Routing Table, will be redistributed, will be learned by all other CRs, in particular also by CR3, and will be preferred by all of them, over the LL route, due to its better weight.

To clarify this point: as we know the Weight is a parameter that doesn't travel on BGP updates, and is not on any RFC (being it Cisco proprietary only); but due to how Communities are configured in my Core Network and how route-maps react to them, basically the net result is as if Weight travelled with BGP updates.

On the other hand, if I set a higher AD for the DSL generated static route on CR0, it won't be used at all by CR0 nor advertised to any other CR.

So honestly I don't see any way how LL and DSl can both be up and sharing selected network traffic; let alone specifying a TCP port rather than a subnet....

Can someone please shed some light? I'm very confused.

Attaching a route-map to the dynamically generated static route on CR0 and/or CR1 is a possible option, because Radius allows me to reference to such route-map if I create it on the CR0 and Cr1 themselves.

On a last note: I do see a way to load-share "democratically" between LL and DSL: assign AD = 200 to the Radius-generated static, so that it evens up with iBGP routes; but this wouldn't do any good, I need to be able to tune load sharing selectively (for TCP80 vs. for any TCP different from 80), not just spit out packets randomly over the 2 WAN options.

Thanks in advance to whoever will feed some input: detailed ideas or configuration examples would be appreciated.

Luca

Everyone's tags (7)
3 REPLIES
Cisco Employee

Re: BGP WAN issue: is it possible to selectively load-share rout

Hi Luca,

Not sure if you have looked PfR solution. Performance routing allows you to create your class based on prefix or port number, and assign the type of traffic to a link-group. Within the link-group, you can config one link as primary and the other as backup. So in your case, you can have 2 classes, one for web traffic with TCP=80, and assign DSL link as primary, mpls as backup; rest for the other class, and assign mpls as primary, DSL as backup.

Check the PfR wiki page for some config examples.
http://docwiki.cisco.com/wiki/PfR:Home

HTH,
Lei Tian

Sent from Cisco Technical Support iPhone App

Community Member

BGP WAN issue: is it possible to selectively load-share routes b

Hi Lei,

honestly I didn't think of PfR, and it could be a good idea; the problem is that I would need to configure it network-wise, with MC, BRs etc, and it's not really feasible in my network; I was looking for some more simple solution, to configure only on CR3, CR0, and if needed on the CPE, letting BGP propagate the best route for each type of traffic (web vs. not_web).

This is a bespoke solution for a specific customer vrf (vrf red), that I don't plan to replicate in the future for other VRFs or other sites of the same red VRF...

Any ideas?

Thanks,

Luca

Cisco Employee

Re: BGP WAN issue: is it possible to selectively load-share rout

Hi Luca,

I agree with you, lot customers didnt go with PfR because of the complexity. Couple things I want point out, you dont have to enable PfR across the network to get the benefit, and MC/BRs can be configured on same box.

At the end, you need to manage the network, so if you feel the solution is too complex, and hard to troubleshoot, then it is not a good solution for you.

HTH,

Lei Tian

274
Views
0
Helpful
3
Replies
CreatePlease to create content