Cisco ISR WAN failover met IP SLA

[Dysmael]

Ik heb 2 internetverbindingen op een ISR4431
Ik moet 1 eindpunt monitoren (8.8.8.8)
Als deze track down gaat wil ik een failover doen, van routering en NAT.

Interfaces

code:

interface Loopback200
 ip address 192.168.100.1 255.255.255.0
 ip nat inside
!
interface Port-channel1
 no ip address
 no negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  bridge-domain 1
 !
 service instance 101 ethernet
  encapsulation dot1q 101
  rewrite ingress tag pop 1 symmetric
  bridge-domain 101
 !
 service instance 102 ethernet
  encapsulation dot1q 102
  rewrite ingress tag pop 1 symmetric
  bridge-domain 102
 !
!

interface GigabitEthernet0/0/0
 no ip address
 negotiation auto
 channel-group 1 mode active
!
interface GigabitEthernet0/0/1
 no ip address
 negotiation auto
 channel-group 1 mode active
!

interface BDI1
 ip address 172.20.36.180 255.255.255.0
!
interface BDI101
 ip address 192.168.52.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip nat outside
!
interface BDI102
 ip address 192.168.51.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip nat outside

IP SLA monitoring en track

code:

ip sla 101
 icmp-echo 8.8.8.8 source-interface BDI101
 threshold 1000
 timeout 2000
 frequency 2
ip sla schedule 101 life forever start-time now
ip sla 102
 icmp-echo 8.8.8.8 source-interface BDI102
 threshold 1000
 timeout 2000
 frequency 2
ip sla schedule 102 life forever start-time now

track 101 ip sla 101 reachability
!
track 102 ip sla 102 reachability

ip route

code:

ip route 0.0.0.0 0.0.0.0 BDI101 192.168.52.254
ip route 0.0.0.0 0.0.0.0 BDI102 192.168.51.254

NAT

code:

ip nat inside source route-map ISP1 interface BDI102 overload
ip nat inside source route-map ISP2 interface BDI101 overload

route-map ISP1 permit 10 
 match ip address 20
 match interface BDI101
!
route-map ISP2 permit 10 
 match ip address 20
 match interface BDI102

EEM

code:

event manager applet check_isp1
 event track 101 state any
 action 1.0 cli command "enable"
 action 1.5 cli command "clear ip nat trans *"
 action 2.0 syslog priority notifications msg "Nat translation cleared!"
event manager applet check_isp2
 event track 102 state any
 action 1.0 cli command "enable"
 action 1.5 cli command "clear ip nat trans *"
 action 2.0 syslog priority notifications msg "Nat translation cleared!"

ACL

code:

#access-list 10 permit 192.168.51.0 0.0.0.255
#access-list 11 permit 192.168.52.0 0.0.0.255
access-list 20 permit 192.168.100.0 0.0.0.255

Ik heb BDI101 en BDI102 momenteel verbonden met een Firewall.
Dat worden twee verschillende routers (ISP1 en ISP2)

Dus 192.168.51.1 en 192.168.52.1 worden de publieke IPv4 adressen en 192.168.51.254 en 192.168.52.254 worden de IPv4 adressen van de routers vd providers.

Op de firewall kan ik verkeer van BDI101 en BDI102 blokkeren, om zo IP SLA te testen.

Ik kan natuurlijk niet de router van de provider pingen, die blijft werken als de internetverbinding wegvalt. De link tussen onze router en die van de provider blijft dan ook actief.

Als ik met beide lijnen actief een ping vanaf lo200 uitvoer dan werkt deze;

Verkeer gaat nu over de 192.168.52.254 gateway:

code:

RTR#ping 213.239.154.30 source lo200
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 213.239.154.30, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/6 ms
RTR#show ip nat tr
RTR#show ip nat translations 
Pro  Inside global         Inside local          Outside local         Outside global
icmp 192.168.52.1:15685    192.168.100.1:15685   213.239.154.30:15685  213.239.154.30:15685

Nu blokkeer ik 192.168.52.0 op de firewall.

Track 101 gaat down

code:

.Apr 20 2019 13:40:58.197 NL: track-sta (101) Change #16 ip sla 101, reachability Up->Down
.Apr 20 11:40:58.198: %TRACK-6-STATE: 101 ip sla 101 reachability Up -> Down
.Apr 20 2019 13:40:58.198 NL: track-sta (101) ip sla 101 reachability Up -> Down
.Apr 20 2019 13:40:58.324 NL: %HA_EM-5-LOG: check_isp1: Nat translation cleared!

Ik heb geen NAT translaties meer

code:

RTR#show ip nat translations        
Total number of translations: 0

Een nieuwe ping naar 213.239.154.30 wil weer via de 192.168.52.0 verbinding naar buiten

code:

RTR#ping 213.239.154.30 source lo200
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 213.239.154.30, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1 
.....
Success rate is 0 percent (0/5)
RTR#show ip nat translations        
Pro  Inside global         Inside local          Outside local         Outside global
icmp 192.168.52.1:15865    192.168.100.1:15865   213.239.154.30:15865  213.239.154.30:15865
Total number of translations: 1

Maar een ICMP echo naar een ander IP adres gaat wel over de 192.168.51.0 verbinding;

code:

RTR#ping 52.85.140.48 source lo200        
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 52.85.140.48, timeout is 2 seconds:
Packet sent with a source address of 192.168.100.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/16/17 ms
RTR#show ip nat translations      
Pro  Inside global         Inside local          Outside local         Outside global
icmp 192.168.51.1:15938    192.168.100.1:15938   52.85.140.48:15938    52.85.140.48:15938
Total number of translations: 1

Hoe kan dit?

Ik wil uiteindelijk bereiken dat;
IP SLA 101; icmp naar A, altijd via BDI101 (gateway X)
IP SLA 102: icmp naar A, altijd via BDI102 (gateway Y)

Ik kan niet toetsen op de beschikbaarheid van Gateways X of Y want die zullen altijd beschikbaar zijn.
De route naar A is niet bekend, ik wil toetsen op de beschikbaarheid van host A.

BDI101 moet NAT op worden toegepast
BDI102 moet alleen routeren (gaat naar andere router die NAT toepast)

10-tal statische routes naar BDI102 (alleen via BDI102 te bereiken)

0.0.0.0/0 naar BDI102

Als BDI102 uitvalt dan moet 0.0.0.0/0 via BDI102 (gw 1.1.1.1) naar buiten

Uitval van BDI102 bedoel ik dan de bereikbaarheid van 8.8.8.8 daarop, want de routers achter BDI102 kunnen nog wel bereikbaar zijn maar de internet breakout achter BDI102 is dat misschien niet.

Wat is hier de beste oplossing voor?

Ik wil dat beide IP SLA monitors altijd de verbinding testen via hun eigen gateway
Globale routing 'gw of last resort' moet BDI102 zijn
Als SLA102 (BDI102) down gaat (track 102) dan moet de routing naar BDI101 gaan.

Moet ik hiervoor VRF configureren of kan het nog anders?

[chup5528]

Volgens mij ben je je default route aan het load balancen nu, dezelfde metric. Staan ze allebei in je routing table? Zou verklaren waarom je twee PINGs allebei een andere kant op gaan.

Ik zou je secundaire route met een hogere metric erin zetten. Zodra je track 101 plat gaat moet de metric omgegooid worden, of de niet-werkende route moet weggehaald worden uit je routing table. Het makkelijkste is de track op te nemen in je ip route commando's:

ip route 0.0.0.0 0.0.0.0 BDI102 192.168.51.254 track 101
ip route 0.0.0.0 0.0.0.0 BDI101 192.168.52.254 10

Zodra track 101 nu plat gaat verdwijnt je default route naar BDI102 uit je routing table en pakt ie de default route op BDI101. Komt ie weer online, wordt ie weer in je routing table gezet en ga je weer over BDI102 naar buiten.

Om niet te NATten over BDI102 haal je simpelweg het 'ip nat outside' commando daar weg (en dan ook meteen 'ip nat inside source route-map ISP1 interface BDI102 overload' opruimen). Een clear ip nat translations is dan niet eens nodig bij een failover, je router gaat niet NATten over een interface waar dat commando niet op staat. BDI102 moet dan natuurlijk wel de route naar jouw interne netwerken kennen.

[Dysmael]

Yup, nadeel is dat als track101 down gaat, dan gaat de route down en kan de track nooit meer up komen.
Of ik zie wat over het hoofd.

Ik heb nu ISP1 en ISP2 als VRF geconfigureerd.
Volgens mij zit ik daarmee meer in de goede richting.
Sta open voor verbetering / aanvulling. Ben vast niet de eerste die hiermee strubbelt.
Bijna alle IP SLA & Track voorbeelden gaan uit van een interne router die gemonitored wordt. Daar is het prima voor. Werkt echter niet als route 0.0.0.0/0 up moet zijn voor de track om te werken.

[chup5528]

Daar heb je gelijk in. Zodra je VRFjes gaat pakken, moet je routes gaan leaken om ze te gaan gebruiken. Heb ik niet eerder gedaan, staat me van bij dat dat een erg ingewikkeld verhaal is.

Ander idee: route-maps op een paar loopback interfaces zetten met een next-hop adres van de desbetreffende ISP. Vervolgens die loopback interfaces gebruiken als source-interface voor je ip sla

[Dysmael]

PBR op loopbacks is volgens mij wel een goed idee ja

--

Ben vast wat te eigenwijs dat ik onderstaand ook werkend probeer te krijgen.
Lukt me dat niet dan is pbr op een loopback inderdaad de oplossing wel

Routes leaken prima, heb 2 VRF's die elkaar kunnen pingen.
Zit alleen nu met NAT; dat kan in IOS XE alleen met match-in-vrf (in zelfde VRF) met nat inside en nat outside
Schijnt dat het met IOS NVI wel zou kunnen (niet nat inside maar nat enabled) tussen VRF's

VRF1
VLAN A 192.168.1.1 GW 192.168.1.254 / nat outside
LO200 1.1.1.1/31 /nat inside
NAT werkt prima > 1.1.1.1:23424 > 192.168.1.1:234234 > 8.8.8.8

VRF2 kan alles in VRF1 pingen en omgekeerd, routes onderling met BGP (route leaking)

Nu probeer ik iets in VRF2 via 1.1.1.1 naar 0.0.0.0/0 te sturen.
Dat gaat nog niet,
Zit volgens mij heel dicht bij, zal iets heel doms over het hoofd zien

Voorbeeld:
VRF2 , VLAN 500 10.12.34.1/24
VRF1, VLAN 100 (internet) 45.56.78.89/29
VRF1, LO100 1.1.1.1/32

ip route vrf VRF2 0.0.0.0/0 1.1.1.1
> mag niet, 1.1.1.1 is this router.

[Dysmael]

Draait nu volgens mij aardig goed, met twee loopback interfaces.
route-map op een loopback kan niet, want een route-map wordt alleen bij ingress verkeer toegepast
er moet een route-map op de local ip policy worden toegepast (ip local policy route-map IPSLA)

Zo opgelost;

code:

interface Loopback100
 ip address 10.1.1.1 255.255.255.255
 ip nat inside
!
interface Loopback101
 ip address 10.2.2.2 255.255.255.255
 ip nat inside
!

access-list 100 permit icmp host 10.1.1.1 any
access-list 101 permit icmp host 10.2.2.2 any


route-map IPSLA permit 10
 match ip address 100
 set ip next-hop 192.168.51.254
!
route-map IPSLA permit 20
 match ip address 101
 set ip next-hop 192.168.52.254
!

ip local policy route-map IPSLA

interface BDI101
 description INTERN-GEEN-NAT-NODIG
 ip address 192.168.51.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip nat outside
!
interface BDI102
 description INTERNET-WEL-NAT-NODIG
 ip address 192.168.52.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip nat outside

ip nat inside source list 100 interface BDI101 overload
ip nat inside source list 101 interface BDI102 overload





ip sla 100
 icmp-echo 8.8.8.8 source-ip 10.1.1.1
 threshold 500
 timeout 1000
 frequency 2
ip sla schedule 100 life forever start-time now
ip sla 101
 icmp-echo 8.8.8.8 source-ip 10.2.2.2
 threshold 500
 timeout 1000
 frequency 2
ip sla schedule 101 life forever start-time now


ip route 0.0.0.0 0.0.0.0 192.168.51.254 10 track 100
ip route 0.0.0.0 0.0.0.0 192.168.52.254 20 track 101
ip route 0.0.0.0 0.0.0.0 192.168.51.254 200

block 192.168.51.0 > track 100 down > route met metric 10 is weg
route 192.168.52.254 wordt actief
block 192.168.52.0 > track 100 down > route met metric 20 is weg
(fallback terug naar eerste) route 192.168.51.254 wordt actief want die kijkt niet naar een track

Reden dat ik op beide Loopbacks NAT toepas is omdat die ip-adressen niet op het netwerk bekend zijn
Zou anders een publiek IPv4 adres moeten opofferen. Kan misschien wel maar als het niet hoeft.

Volgens mij zorgt deze opstelling ervoor dat;
vanaf 192.168.51.1 naar 8.8.8.8 wordt getoetst
vanaf 192.168.52.1 naar 8.8.8.8 wordt getoetst

NAT wordt nu alleen intern toegepast op 10.1.1.1 en 10.2.2.2 als ik het goed heb
Dus nog niet van andere IP's.
Dit moet ik nog controleren.

Lijkt aardig goed te gaan.
routes komen en gaan bij het blokkeren van IP verkeer op de firewall

edit:
heb nu het resultaat zoals ik wil, volgens mij niet op de meest aanbevolen manier

via int X is wel NAT nodig voor internet
via int Y is geen NAT nodig voor internet
Int Y is de standaard gateway

omdat voor de twee loopbacks wel NAT nodig is hebben int X en Y wel ip nat outside in de config
extra regel " ip nat inside ACL_LAN int X " leidt ertoe dat ACL_LAN via int X zit te NATten terwijl int Y beschikbaar is.

Dat nu opgelost door de event-manager in te stellen dat;

event_down
bij down track 100 over Y;
ip nat inside acl_lan int X

event_up
bij up track 100
clear ip nat tra for
no ip nat inside acl_lan int X

Resultaat is exact wat ik wil,
denk dat ik straks in de praktijk de NAT op de loopbacks helemaal kan uitschakelen maar functioneel is het nu wel.

Bedankt voor het meedenken @chup5528 ! De PBR / Route-maps is volgens mij wel de beste c.q. aanbevolen methode inderdaad.

[ Voor 16% gewijzigd door Dysmael op 21-04-2019 13:26 ]

[Uberprutser]

Ik zou sowieso niet alleen op Google (8.8.8.8 in dit geval) vertrouwen want die wil nog wel eens unresponsive op ICMP. Ik heb ook Cloudflare (1.0.0.1) erbij staan als extra check want hier zag ik regelmatig dat 8.8.8.8 niet bereikbaar was en daardoor het hele circus over ging naar de andere router, en terug en nog een keer.

[Dysmael]

Yes, thanks! 8.8.8.8 was een voorbeeld en voor de test.
Ik heb er nog geen goed eindpunt in staan momenteel maar denk dat ik een traceroute ga doen en 1 of meer vd hops die ik tegenkom als conditie inbouw.

Dus;
track 1 ip sla 1 reach
track 2 ip sla 2 reach
track 5 list boolean and
object 1
object 2

[sdktr]

int LAN1
ip nat inside

int WAN1 #primary
ip nat out

int WAN2 #secondary
! no nat config here

! re-route IP SLA probes to WAN1
route-map LOCAL_ORIGINATED
match ip add prefix IPSLA
set ip next-hop <Next-Hop WAN1>
!
ip prefix-list IPSLA perm 1.0.0.1/32
ip prefix-list IPSLA perm 8.8.8.8/32
!
ip local policy LOCAL_ORIGINATED

route-map PAT per 10
match ip add PAT_ACL
!
ip access-l ext PAT_ACL
permit <LAN SEGMENT> any
!
ip nat inside source route-map PAT int WAN1 overload
!
ip route 0.0.0.0 0.0.0.0 NEXTHOP-WAN1 track 1 10
ip route 0.0.0.0 0.0.0.0 NEXTHOP-WAN2 20
!
<ip sla track 1 goes here>

[Dysmael]

Dankjewel voor je bijdrage sdktr,
Misschien zie ik wat over het hoofd? ik zie in die config niet iets wat ik niet al had.