VRF leaking multiple private circuits to one shared backup circuit?

[Alkemyst71]

We have a building that has multiple clients and as a 'value added' option we have decided to put in a back up circuit that we currently are only using for one key customer.  Our goal though is to have that connection shared as other's need it.

We have VRFs set up for each client and everything is working fine.

What we need is the config example to route this backup traffic out the backup circuit and allow that traffic to return properly to the said VRFs.  This backup connection will have to exist on a switch as well as the router in place is full.  We could add another module to it if it's an absolute necessity, but we are trying to avoid any down time for this network.

Sample Config:

ip vrf bbs-CLIENT1
description BBS CLIENT1
rd 1010:1
route-target export 1010:1
route-target import 1010:1
!
ip vrf bbs-CLIENT2
description BBS CLIENT2
rd 1009:1
route-target export 1009:1
route-target import 1009:1
!

!

interface GigabitEthernet0/0.340
description CLIENT2 LAN
encapsulation dot1Q 340
ip vrf forwarding bbs-CLIENT2
ip address [CLIENT2 LAN] 255.255.255.0
ip nat inside
ip virtual-reassembly in
!

interface GigabitEthernet0/0.375
description CLIENT1 LAN
encapsulation dot1Q 375
ip vrf forwarding bbs-CLIENT1
ip address [CLIENT2 LAN] 255.255.255.0
ip nat inside
ip virtual-reassembly in
!

interface GigabitEthernet0/1.2007
description CLIENT2 PUBLIC WAN
encapsulation dot1Q 2007
ip vrf forwarding bbs-CLIENT2
ip address [CLIENT2 PUBLIC WAN] 255.255.255.252
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nat outside
ip virtual-reassembly in
!
interface GigabitEthernet0/1.2014
description CLIENT1 PUBLIC WAN
encapsulation dot1Q 2014
ip vrf forwarding bbs-CLIENT1
ip address [CLIENT1 PUBLIC WAN] 255.255.255.252
ip nat outside
ip virtual-reassembly in
!
ip route vrf bbs-CLIENT1 0.0.0.0 0.0.0.0 [CLIENT1 PUBLIC WAN]
ip route vrf bbs-CLIENT2 0.0.0.0 0.0.0.0 [CLIENT2 PUBLIC WAN]

!

route-map CLIENT1_NAT permit 10
match ip address 111

!
match interface GigabitEthernet0/1.2014
!
route-map CLIENT2_NAT permit 10
match ip address 105
!
access-list 105 permit ip [CLIENT2 LAN] 0.0.0.255 any
access-list 111 permit ip [CLIENT1 LAN] 0.0.0.255 any

!

Thanks!

[Georg Pauwen]

Hello,

--> Our goal though is to have that connection shared as other's need it.

What criteria do you want this to be based on ? Should the backup be used only when the primary is down, or when the primary has a certain load ?

[Alkemyst71]

It will be used only when the Primary is down.  The problem is also there are multiple primaries to track.  All clients have their own primary connections.

[Georg Pauwen]

Hello,

you could configure one IP SLA per VRF/Customer and track the default route, then install the backup route when the primary is down. It would look like below:

track 1 ip sla 1 reachability
!
ip sla 1
icmp-echo 8.8.8.8 source-ip CLIENT1_PUBLIC_WAN_IP_LOCAL
vrf bbs-CLIENT1
timeout 1000
frequency 10
threshold 500
exit
!
ip sla schedule 1 life forever start-time now
!
ip route vrf bbs-CLIENT1 0.0.0.0 0.0.0.0 CLIENT1_WAN_IP_REMOTE track 1
ip route vrf bbs-CLIENT1 0.0.0.0 0.0.0.0 BACKUP_ROUTE_IP

track 2 ip sla 2 reachability
!
ip sla 2
icmp-echo 8.8.8.8 source-ip CLIENT2_PUBLIC_WAN_IP_LOCAL
vrf bbs-CLIENT2
timeout 1000
frequency 10
threshold 500
exit
!
ip sla schedule 2 life forever start-time now
!
ip route vrf bbs-CLIENT2 0.0.0.0 0.0.0.0 CLIENT2_WAN_IP_REMOTE track 2
ip route vrf bbs-CLIENT2 0.0.0.0 0.0.0.0 BACKUP_ROUTE_IP

[Giuseppe Larosa]

Hello @Alkemyst71 , @Georg Pauwen ,

please play with route targets extcommunities MP BGP attribute

the central site must export an additional RT value for net 0.0.0.0/0 for example 0.0.0.0/0 with RT 1010:999

the central site will import all the clients' VRF RT values and will pass these networks to an external FW appliance

all the spoke sites will import the backup route 0.0.0.0/0 as they have an addtional route target import.

Each VRF is a separate IPv4 space with a potential of 4 billions IPv4 addresses.

There is no need of complex IP SLA use route targets and separate the central site in two different VRFs: client1 and central-site.

see the book below

https://www.bookdepository.com/MPLS-VPN-Architectures-II-Ivan-Pepelnjak/9781587051128

Hope to help

Giuseppe

[Alkemyst71]

We are not running any dynamic routing protocols.