Met de komst van vDSL, glasvezel, kabel internet én SLA’s zijn zakelijke Internet verbindingen steeds betrouwbaarder geworden. Door hierbij slim Internet-verbindingen te selecteren (verschillende providers) is het voor bedrijven interessant geworden om de MPLS wan verbinding te vervangen voor een zogenaamd overlay network, waarbij er gebruik wordt gemaakt van redundante Internet-verbindingen om de beschikbaarheid te verhogen. Hierdoor krijgt een bedrijf vaak een snellere WAN-verbinding tegen lagere kosten (mijn eerste business case hiervoor was in 2006/2007 met een kostenbesparing van 70% tov europese MPLS verbindingen) mét een hoge beschikbaarheid.
Dit soort overlay netwerken zijn vaak gebaseerd op een hub-spoke technologie (alle spokes registreren zich op de hub, de configuratie van de spoke is relatief eenvoudig en hetzelfde) waardoor schaalbaarheid ontstaat. De hub-spoke technologie zorgt er ook voor dat verkeer tussen spokes dynamisch verkeer versleuteld wordt. De Cisco technologie hiervoor heet DMVPN (Dynamic Multipoint VPN) en deze wordt vaak gebruikt in combinatie met EIGRP voor de dynamische routering.
Wanneer in een dual-hub topologie de vestiging óók gebruik maakt van twee Internet-providers kan de situatie zich voordoen dat WAN-verkeer over een Internet-verbinding heen loopt die problemen geeft, of over de backup verbinding in plaats van de actieve verbinding (in geval van active/passive op de vestiging). In deze blogpost geef ik een toelichting waarom EIGRP hiervoor zorgt én hoe je binnen EIGRP de routering zodanig kan aanpassen dat het verkeer wél over de juiste verbinding heen wordt gerouteerd.
Netwerk topologie
Onderstaand diagram is een zeer gangbaar ontwerp van een zogenaamd DMVPN op basis van dual-hub / dual-ISP oplossing. Hierbij wordt elke hub op een eigen Internet-provider aangesloten, zodat in geval van een provider-storing, het verkeer via de andere hub nog kan blijven doorgaan. Voor de beveiliging wordt het verkeer vanaf de vestigingen in een aparte DMZ interface getermineerd. Op de vestiging wordt ook gebruik gemaakt van een tweetal internet-verbindingen, zodat ook in geval van een storing op een van de tunnel-verbindingen, de ander het kan overnemen.
Probleemstelling
Als de twee Internet-verbindingen vanaf de vestiging identiek zijn (qua bandbreedte en snelheid), dan is er op zich geen probleem; de twee DMVPN tunnels gedragen zich in een active/active situatie. Dit wordt keurig getoond via de output “show ip route eigrp
” op de spoke router, waarin zichtbaar is dat het hoofdkantoor (10.0.1.0) bereikbaar is via beide hub-routers.
spoke1#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 3.2.2.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D 10.0.0.0/24 [90/26880512] via 10.255.2.1, 00:01:33, Tunnel2
[90/26880512] via 10.255.1.1, 00:01:33, Tunnel1
D 10.255.0.0/24 [90/26880256] via 10.255.2.1, 00:03:49, Tunnel2
[90/26880256] via 10.255.1.1, 00:03:49, Tunnel1
spoke1#
Op de ASA-HQ is ook te zien dat de spoke beschikbaar is via beide routes.
asa-hq# sh route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 2.2.8.1 to network 0.0.0.0
D 10.10.1.0 255.255.255.0 [90/1306112] via 10.255.0.24, 00:00:03, dmz
[90/1306112] via 10.255.0.23, 00:00:03, dmz
D 10.255.1.0 255.255.255.0 [90/1305856] via 10.255.0.23, 00:00:03, dmz
D 10.255.2.0 255.255.255.0 [90/1305856] via 10.255.0.24, 00:00:03, dmz
Echter, het probleem ontstaat wanneer tunnel2 bijvoorbeeld de backup verbinding is met een langzamere snelheid ten op zichte van de primaire verbinding. We passen tunnel2 aan naar een lagere bandbreedte dan tunnel1, om vanuit de vestiging het verkeer primair over tunnel1 te laten lopen:
configure terminal
interface tunnel2
bandwidth 4096
!
end
clear ip eigrp neighb
En vanuit de vestiging wordt keurig de route naar het hoofdkantoor via tunnel1 gestuurd:
spoke1#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 3.2.2.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
D 10.0.0.0/24 [90/1536512] via 10.255.1.1, 00:00:04, Tunnel1
D 10.255.0.0/24 [90/1536256] via 10.255.1.1, 00:00:04, Tunnel1
spoke1#
Echter, het probleem zit niet in de vestiging, maar op de ASA-HQ, daar wordt de vestiging (10.10.1.0/24) nog steeds via beide routers gerouteerd!
asa-hq# show route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 2.2.8.1 to network 0.0.0.0
D 10.10.1.0 255.255.255.0 [90/1306112] via 10.255.0.24, 00:08:25, dmz
[90/1306112] via 10.255.0.23, 00:08:25, dmz
D 10.255.1.0 255.255.255.0 [90/1305856] via 10.255.0.23, 00:09:13, dmz
D 10.255.2.0 255.255.255.0 [90/1305856] via 10.255.0.24, 00:09:13, dmz
En daarmee wordt er nog steeds verkeer over de langzamere downlink op de vestiging gestuurd, of in geval van een probleem op Internet, via een problematische provider. En daarmee wordt de WAN verbinding, ondanks de hoge beschikbaarheid, onbetrouwbaar.
De oorzaak hiervoor ligt in het gedrag van EIGRP zelf; EIGRP is routeringsprotocol dat zowel gebruik maakt van link-state als een distance-vector protocol. De bandbreedte is een van de vele metrics die gebruikt worden om te bepalen wat de meest optimale route is. En in feite is dat ook logisch, want vanuit de ASA gezien is de vestiging bereikbaar via twee paden; hub1 en hub2. De kosten voor beide paden zijn gelijk, namelijk 1 hop verwijderd én de bandbreedte op beide hub-routers is gelijk. Dus de ASA weet niet dat tunnel2 voor deze vestiging een langzamere verbinding is; met dus als gevolg dat verkeer “evenredig” verdeeld wordt. De metric vanuit de ASA is hetzelfde:
asa-hq# show eigrp top
EIGRP-IPv4 Topology Table for AS(1906)/ID(10.255.0.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.255.2.0 255.255.255.0, 1 successors, FD is 1305856
via 10.255.0.24 (1305856/1305600), dmz
P 10.0.0.0 255.255.255.0, 1 successors, FD is 2816
via Connected, inside
P 10.255.1.0 255.255.255.0, 1 successors, FD is 1305856
via 10.255.0.23 (1305856/1305600), dmz
P 10.255.0.0 255.255.255.0, 1 successors, FD is 2816
via Connected, dmz
P 10.10.1.0 255.255.255.0, 2 successors, FD is 1306112
via 10.255.0.23 (1306112/1305856), dmz
via 10.255.0.24 (1306112/1305856), dmz
asa-hq#
Nu is het mogelijk om op hub2 de bandbreedte aan te passen naar een lagere waarde, zodat al het verkeer over hub1 gerouteerd wordt. Dat kan wel in de situatie van één vestiging, maar in geval van tientallen of honderden sites, is dat geen wenselijke situatie. En wanneer één vestiging primair over hub1 moet gaan én voor een andere vestiging over hub2, is dat zelfs een onmogelijke situatie.
Oplossing
Het is mogelijk om toch te zorgen dat de ASA het verkeer voor een specifieke vestiging over een specifieke tunnel te laten routeren. Omdat de bandbreedte van de tunnel interface op een hub-router niet aangepast kan worden, zal voor specifieke routes een andere metric gekozen moeten worden om het verkeer over een specifieke router heen te kunnen laten lopen, zonder in te boeten op de functionaliteit van EIGRP voor de hoge beschikbaarheid.
Hiervoor kan je gebruik maken van de administratieve distance in combinatie met een access-list. Zoals bekend, maakt Cisco gebruik van administratieve distances per routerings-protocol om een voorkeur te geven aan routeringsprotocollen. Voor EIGRP kent Cisco twee distances, 90 voor interne routes en 170 voor externe routes (routes die geïnjecteerd worden in EIGRP).
Voor deze topologie zijn alle routes interne routes en hebben een distance van 90.
Binnen Cisco IOS routers kan je binnen het EIGRP protocol het commando distance gebruiken om netwerken die via een bepaalde interface binnenkomen een andere distance mee te geven. Door hier een standard access-list aan te koppelen wordt de distance alleen verhoogd voor die netwerken die op de access-list gekoppeld worden.
De configuratie wordt dan als volgt:
access-list 99 permit 127.0.0.1
router eigrp 1906
network 10.255.0.0 0.0.0.255
network 10.255.1.0 0.0.0.255
network 10.255.2.0 0.0.0.255
passive-interface default
no passive-interface Tunnel1
no passive-interface GigabitEthernet0/2
distance 95 10.255.1.0 0.0.0.255 99
!
In de configuratie is nu een standard access-list 99 opgenomen, met daarin alleen de host 127.0.0.1. Dit is gedaan om te zorgen dat de access-list in de configuratie blijft bestaan.
In de EIGRP configuratie is het commando distance 95 10.255.1.0 0.0.0.255 99
toegevoegd.
Dit commando geeft aan dat voor alle netwerken, die gematched worden op access-list 99 én binnenkomen over netwerk 10.255.1.0 / 24 de distance binnen EIGRP op 95 gezet moet worden.
Wanneer nu het netwerk van de vestiging wordt toegevoegd op de router waar het verkeer niet overheen gerouteerd wordt én de specifieke neighbor op die hub-router gecleard wordt, wordt de distance aangepast naar 95 en daarmee wordt ook de routering met de ASA-HQ aangepast. In dit voorbeeld wil ik ervoor zorgen dat verkeer over hub1 gerouteerd wordt, dus moet ik de aanpassing uitvoeren op hub2 router:
hub2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
hub2(config)#access-list 99 permit 10.10.1.0 0.0.0.255
hub2(config)#exit
*Jan 26 14:39:36.008: %SYS-5-CONFIG_I: Configured from console by admin on c
hub2#
hub2#clear ip eigrp neighb 10.255.2.11
hub2#
En vanuit hub2 is nu te zien dat de voorkeur voor het verkeer naar de spoke via hub1 gerouteerd wordt.
hub2#sh ip route eigrp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is 4.4.11.1 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
D 10.0.0.0/24 [90/3072] via 10.255.0.1, 00:03:15, GigabitEthernet0/2
D 10.10.1.0/24
[90/1306112] via 10.255.0.23, 00:03:15, GigabitEthernet0/2
D 10.255.1.0/24
[90/1305856] via 10.255.0.23, 00:03:15, GigabitEthernet0/2
hub2#
De route is er nog wel via de DMVPN tunnel, maar is “duurder” geworden
hub2#show ip eigrp top 10.10.1.0/24
EIGRP-IPv4 Topology Entry for AS(1906)/ID(10.255.2.1) for 10.10.1.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1306112
Descriptor Blocks:
10.255.0.23 (GigabitEthernet0/2), from 10.255.0.23, Send flag is 0x0
Composite metric is (1306112/1305856), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 50020 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1460
Hop count is 2
Originating router is 192.168.2.1
10.255.2.11 (Tunnel2), from 10.255.2.11, Send flag is 0x0
Composite metric is (1305856/2816), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 50010 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1460
Hop count is 1
Originating router is 192.168.2.1
En ook de ASA gaat nu verkeer voor 10.10.1.0/24 routeren via hub1:
asa-hq# sh route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 2.2.8.1 to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via 2.2.8.1, outside
C 2.2.8.0 255.255.255.248 is directly connected, outside
L 2.2.8.3 255.255.255.255 is directly connected, outside
C 10.0.0.0 255.255.255.0 is directly connected, inside
L 10.0.0.1 255.255.255.255 is directly connected, inside
D 10.10.1.0 255.255.255.0 [90/1306112] via 10.255.0.23, 00:01:41, dmz
C 10.255.0.0 255.255.255.0 is directly connected, dmz
L 10.255.0.1 255.255.255.255 is directly connected, dmz
D 10.255.1.0 255.255.255.0 [90/1305856] via 10.255.0.23, 00:03:15, dmz
D 10.255.2.0 255.255.255.0 [90/1305856] via 10.255.0.24, 00:02:40, dmz
asa-hq#
En hiermee kan in een ogenschijnlijk lastige situatie eenvoudig verkeer (tijdelijk) via een andere route gerouteerd worden. Deze oplossing kan ook gebruikt worden om bij eventuele problemen in een active/active spoke configuratie, of in geval van vreemde problemen via een provider, of latency/out-of-order packets, tijdelijk het verkeer over één hub te laten routeren om problemen uit te sluiten.