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 eigrpCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, + - replicated routeGateway of last resort is 2.2.8.1 to network 0.0.0.0D 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, dmzD 10.255.1.0 255.255.255.0 [90/1305856] via 10.255.0.23, 00:00:03, dmzD 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 terminalinterface tunnel2bandwidth 4096!endclear ip eigrp neighb
En vanuit de vestiging wordt keurig de route naar het hoofdkantoor via tunnel1 gestuurd:
spoke1#sh ip route eigrpCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, H - NHRP, l - LISPa - application route+ - replicated route, % - next hop override, p - overrides from PfRGateway of last resort is 3.2.2.1 to network 0.0.0.010.0.0.0/8 is variably subnetted, 8 subnets, 2 masksD 10.0.0.0/24 [90/1536512] via 10.255.1.1, 00:00:04, Tunnel1D 10.255.0.0/24 [90/1536256] via 10.255.1.1, 00:00:04, Tunnel1spoke1#
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 eigrpCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, + - replicated routeGateway of last resort is 2.2.8.1 to network 0.0.0.0D 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, dmzD 10.255.1.0 255.255.255.0 [90/1305856] via 10.255.0.23, 00:09:13, dmzD 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 topEIGRP-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 StatusP 10.255.2.0 255.255.255.0, 1 successors, FD is 1305856via 10.255.0.24 (1305856/1305600), dmzP 10.0.0.0 255.255.255.0, 1 successors, FD is 2816via Connected, insideP 10.255.1.0 255.255.255.0, 1 successors, FD is 1305856via 10.255.0.23 (1305856/1305600), dmzP 10.255.0.0 255.255.255.0, 1 successors, FD is 2816via Connected, dmzP 10.10.1.0 255.255.255.0, 2 successors, FD is 1306112via 10.255.0.23 (1306112/1305856), dmzvia 10.255.0.24 (1306112/1305856), dmzasa-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.1router eigrp 1906network 10.255.0.0 0.0.0.255network 10.255.1.0 0.0.0.255network 10.255.2.0 0.0.0.255passive-interface defaultno passive-interface Tunnel1no passive-interface GigabitEthernet0/2distance 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 tEnter configuration commands, one per line. End with CNTL/Z.hub2(config)#access-list 99 permit 10.10.1.0 0.0.0.255hub2(config)#exit*Jan 26 14:39:36.008: %SYS-5-CONFIG_I: Configured from console by admin on chub2#hub2#clear ip eigrp neighb 10.255.2.11hub2#
En vanuit hub2 is nu te zien dat de voorkeur voor het verkeer naar de spoke via hub1 gerouteerd wordt.
hub2#sh ip route eigrpCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, H - NHRP, l - LISPa - application route+ - replicated route, % - next hop override, p - overrides from PfRGateway of last resort is 4.4.11.1 to network 0.0.0.010.0.0.0/8 is variably subnetted, 7 subnets, 2 masksD 10.0.0.0/24 [90/3072] via 10.255.0.1, 00:03:15, GigabitEthernet0/2D 10.10.1.0/24[90/1306112] via 10.255.0.23, 00:03:15, GigabitEthernet0/2D 10.255.1.0/24[90/1305856] via 10.255.0.23, 00:03:15, GigabitEthernet0/2hub2#
De route is er nog wel via de DMVPN tunnel, maar is “duurder” geworden
hub2#show ip eigrp top 10.10.1.0/24EIGRP-IPv4 Topology Entry for AS(1906)/ID(10.255.2.1) for 10.10.1.0/24State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1306112Descriptor Blocks:10.255.0.23 (GigabitEthernet0/2), from 10.255.0.23, Send flag is 0x0Composite metric is (1306112/1305856), route is InternalVector metric:Minimum bandwidth is 100000 KbitTotal delay is 50020 microsecondsReliability is 255/255Load is 1/255Minimum MTU is 1460Hop count is 2Originating router is 192.168.2.110.255.2.11 (Tunnel2), from 10.255.2.11, Send flag is 0x0Composite metric is (1305856/2816), route is InternalVector metric:Minimum bandwidth is 100000 KbitTotal delay is 50010 microsecondsReliability is 255/255Load is 1/255Minimum MTU is 1460Hop count is 1Originating 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 routeCodes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGPD - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter areaN1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2E1 - OSPF external type 1, E2 - OSPF external type 2i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2ia - IS-IS inter area, * - candidate default, U - per-user static routeo - ODR, P - periodic downloaded static route, + - replicated routeGateway of last resort is 2.2.8.1 to network 0.0.0.0S* 0.0.0.0 0.0.0.0 [1/0] via 2.2.8.1, outsideC 2.2.8.0 255.255.255.248 is directly connected, outsideL 2.2.8.3 255.255.255.255 is directly connected, outsideC 10.0.0.0 255.255.255.0 is directly connected, insideL 10.0.0.1 255.255.255.255 is directly connected, insideD 10.10.1.0 255.255.255.0 [90/1306112] via 10.255.0.23, 00:01:41, dmzC 10.255.0.0 255.255.255.0 is directly connected, dmzL 10.255.0.1 255.255.255.255 is directly connected, dmzD 10.255.1.0 255.255.255.0 [90/1305856] via 10.255.0.23, 00:03:15, dmzD 10.255.2.0 255.255.255.0 [90/1305856] via 10.255.0.24, 00:02:40, dmzasa-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.