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
