MPLS & MP-BGP Del 2

Tänkte fortsätta på det tidigare inlägget där vi satte upp ett core-nät med MPLS & MP-BGP, och visa ett simplet exempel på hur vi installerar två kundsiter som kopplas samman via VPN (VRF) för att utbyta dynamisk routing.

Customer-MPLS

Företaget använder sig av OSPF internt där varje regionalkontor placeras i en egen area (i detta fall 461), och upplänken mot PE/Core i area 0.

NL PE KistaRed

Vi skapar först en VRF-instans som är unik för kunden, i detta fall vrf LIGHT med “route distinguisher” till 300:10. Routes märkta med just 300:10 importeras till denna routers vrf-instans (LIGHT) samtidigt som vi exporterar lokala vrf-routes till samma instans för annonsering vidare till övriga PEs.

ip vrf LIGHT
 rd 300:10
 route-target both 300:10

Konfigurera upp lämpligt interface med tillhörande VRF:

interface s0/3
 description LIGHT-Internal Kista
 ip vrf forwarding LIGHT
 ip address 37.46.2.1 255.255.255.252

Då PE-routern ska peera med kundens OSPF-instans krävs lite av en specialare, tänk på att vi redan kör OSPF som IGP inom core-nätet och där vill vi absolut ej ha in några routes från denna kund. Vi kan däremot köra flera samtidiga OSPF-instanser som vi sedan placerar i olika vrf:er, i detta fall en för vrf LIGHT. Redistribution krävs mellan OSPF & MP-BGP instansen för att KistaRed ska annonsera andra vrf LIGHT OSPF-routes den lär sig via just MP-BGP från andra PEs.

router ospf 310 vrf LIGHT 
 router-id 37.46.2.1
 auto-cost reference-bandwidth 20000000
 redistribute bgp 46 subnets
 network 37.46.2.0 0.0.0.3 area 0

Vi skapar sedan en MP-BGP instans för kunden, samma sak här – använd redistribution:

router bgp 46
 address-family ipv4 vrf LIGHT
  redistribute ospf 310 vrf LIGHT
  no synchronization
  exit-address-family

NL PE KistaRed

ip vrf LIGHT
 rd 300:10
 route-target both 300:10

interface s0/3
 description LIGHT-Internal Kiruna
 ip vrf forwarding LIGHT
 ip address 37.46.2.5 255.255.255.252

router ospf 310 vrf LIGHT
 router-id 37.46.2.5
 auto-cost reference-bandwidth 20000000
 redistribute bgp 46 subnets
 network 37.46.2.4 0.0.0.3 area 0

router bgp 46
 address-family ipv4 vrf LIGHT
  redistribute ospf 310 vrf LIGHT
  no synchronization
  exit-address-family

NLKista-Edge

Edge-routern behöver sedan endast konfigureras med OSPF-instansen för att det ska hoppa igång.

!Downlink to CustomerLAN, demo with Loopback
interface Loopback0
 description to CustomerLAN Kista
 ip address 10.46.0.1 255.255.254.0
 ip ospf network point-to-point

interface Serial1/3
 description to ISP-NL-KistaRed
 ip address 37.46.2.2 255.255.255.252

interface Serial1/2
 description to ISP-NL-KistaBlue
 ip address 37.46.2.6 255.255.255.252

router ospf 310
 router-id 37.46.128.1
 auto-cost reference-bandwidth 20000000
 network 37.46.2.0 0.0.0.3 area 0 
 network 37.46.2.4 0.0.0.3 area 0
 network 10.46.0.0 0.0.63.255 area 461

Verifikation Customer-MPLSKiruna Ett till kontor sattes upp i Kiruna med identisk konfig för att kunna köra lite tester. Ping från Kista- till Kiruna-kontoret:

NL-Office-Kista#ping 10.46.64.1 source lo0
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/43/60 ms

Traceroute mellan Kista- & Kiruna-kontoret:

NL-Office-Kista#traceroute 10.46.64.1 source lo0
Type escape sequence to abort.
Tracing the route to 10.46.64.1
1 37.46.2.5 36 msec
37.46.2.1 20 msec
37.46.2.5 28 msec
2 37.46.2.9 44 msec
37.46.2.13 48 msec
37.46.2.9 60 msec
3 37.46.2.14 100 msec
37.46.2.10 72 msec
37.46.2.14 24 msec

Routing-tabellen för Kista-kontoret:

NL-Office-Kista#sh ip route | beg Gateway
37.0.0.0/30 is subnetted, 4 subnets
O IA 37.46.2.8 [110/65] via 37.46.2.5, 00:02:54, Serial1/2
[110/65] via 37.46.2.1, 00:02:54, Serial1/3
O IA 37.46.2.12 [110/65] via 37.46.2.5, 00:02:54, Serial1/2
[110/65] via 37.46.2.1, 00:02:54, Serial1/3
C 37.46.2.0 is directly connected, Serial1/3
C 37.46.2.4 is directly connected, Serial1/2
10.0.0.0/18 is subnetted, 2 subnets
C 10.46.0.0 is directly connected, Loopback0
O IA 10.46.64.0 [110/129] via 37.46.2.5, 00:01:56, Serial1/2
[110/129] via 37.46.2.1, 00:01:56, Serial1/3

PE

KistaBlue#sh ip bgp vpnv4 vrf LIGHT
BGP table version is 15, local router ID is 37.46.255.102
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 300:10 (default for vrf LIGHT)
* i10.46.0.0/23 37.46.255.101 65 100 0 ?
*> 37.46.2.6 65 32768 ?
* i10.46.2.0/23 37.46.255.103 65 100 0 ?
*>i 37.46.255.104 65 100 0 ?
* i37.46.2.0/30 37.46.255.101 0 100 0 ?
*> 37.46.2.6 128 32768 ?
* i37.46.2.4/30 37.46.255.101 128 100 0 ?
*> 0.0.0.0 0 32768 ?
*>i37.46.2.8/30 37.46.255.103 0 100 0 ?
* i 37.46.255.104 128 100 0 ?
* i37.46.2.12/30 37.46.255.103 128 100 0 ?
*>i 37.46.255.104 0 100 0 ?

KistaBlue#sh ip route vrf LIGHT | beg Gateway
Gateway of last resort is not set
37.0.0.0/30 is subnetted, 4 subnets
B 37.46.2.8 [200/0] via 37.46.255.103, 00:22:17
B 37.46.2.12 [200/0] via 37.46.255.104, 00:22:32
O 37.46.2.0 [110/128] via 37.46.2.6, 00:22:59, Serial0/3
C 37.46.2.4 is directly connected, Serial0/3
 10.0.0.0/23 is subnetted, 2 subnets
O IA 10.46.0.0 [110/65] via 37.46.2.6, 00:22:59, Serial0/3
B 10.46.2.0 [200/65] via 37.46.255.104, 00:22:32

Svårare än så är det faktiskt inte. 🙂

CCDP – Tenta & Multipath TCP

Har nu skrivit klart tentorna för både CCNP & CCDP-kurserna jag gått under vintern och känns faktiskt som att det gick riktigt bra återigen. 🙂 CCNP var väl väntat men CCDP har allt varit lite knepig att få grepp om.

Skriva CCDP-certet känns dock långt borta ännu då jag fortfarande är rätt vilsen när det kommer till datacenter/e-commerce/SAN.  Märks verkligen vilken stor skillnad det blir när man ej har möjlighet att labba på utrustningen utan endast läser teorin, borde allt försöka få tag i någon gammal nexus-switch till labbet här hemma sen.

Känner mig hur som helst mer taggad på att plugga vidare mot CCIEv5 istället då den nya blueprinten ser riktigt rolig ut och all gammal teknik som frame-relay fasats ut.

MPTCP

Läste hur som helst en rätt intressant artikel om Multipath TCP som snart verkar bli accepterad som en ny standard. Mer info finns att läsa här och den officiella RFC:en 6824 finns här.

CCDP – MPLS & MP-BGP

Är mitt uppe i tentavecka så finns inte direkt någon tid att posta här just nu tyvärr, räknar med att vara “back on track” till nästa vecka igen. Tänkte hur som helst ta och skriva ett kortare inlägg om implementeringen av MPLS & MP-BGP för en mindre ISP i projektet som nämndes i gårdagens inlägg.

projekt-light

Mitt uppdrag var att föreslå förbättringar och ta fram detaljerade designförslag för både core-nät och internkontor utifrån ovanstående topologi samt följande information:

  • Agerar ISP åt börsnoterade företag
  • IPv4 37.0.0.0/8
  • IPv6 2001:beef::/16
  • 1000st anställda
    • Prag 500st (Huvudkontor)
    • Brno 300st
    • Plzeñ 50st
    • Cern (Schweiz) 25st
    • Amsterdam 25st
    • Birmingham 25st
    • Kista 25st
    • Santa Cruz de Tenerife 25st
    • Kiruna 25st
  • Består av dotterbolagen:
    • NetherLight
    • CanarieLight
    • NorthernLight
    • UKLight
  • Önskar informativa övervakningsmöjligheter för kundens länkar
  • Önskar erbjuda en kostnadseffektiv tjänst med QoS
  • Kontoren i Plzeñ & Brno erbjuder även Datacenter & Storage-lösningar

IGP

igp

Då det befintliga core-nätet helt saknar redundans (exempelvis endast en switch utplacerad i Amsterdam) föreslogs istället  ovanstående uppgradering av nätet. Core-nätet byggs upp i par för respektive land/ort (rött & blått), där varje nod förutom en direktlänk till sin överliggande motsvarighet även har en länk till sin ”core-partner”.

Som underliggande IGP-protokoll till BGP användes OSPF #300 inom core-nätet. Detta då både OSPF & BGP tillskillnad från EIGRP är en öppen standard och tillåter företaget att använda en mixed-vendor lösning.

OSPF låter oss även segmentera nätet i enlighet med de confederations som tagits fram för BGP, med undantaget att CERN här flyttades till en egen area för att hålla Area 0 så liten som möjligt.

Summering utförs i varje ABR, vilket blir väldigt enkelt tack vare att ip-adresseringen följer samma numrering som confederations & area-nummer (ex. NorthernLight 37.46.x.x/16). Reference-bandwith har även justerats till 2 Terabit då OSPF per default ej ser skillnad på länkar över 100Mbit.

Konfigurationsexempel – NorthernLight KistaBlue

router ospf 300
 router-id 37.46.255.102
 log-adjacency-changes
 passive-interface default
 no passive interface Serial0/1
 no passive interface Serial0/2
 no passive interface FastEthernet0/0
 no passive interface FastEthernet0/1
 auto-cost reference-bandwidth 20000000
 area 46 range 37.46.0.0 255.255.0.0
 network 37.31.46.4 0.0.0.3 area 0
 network 37.46.0.0 0.0.255.255 area 46

BGP

BGP Confederations används för att segmentera nätet och minska antalet IBGP neighbor-relationer som annars skulle behövas, detta då IBGP kräver en full-mesh relation för att utbyta routinguppdateringar (förutsatt att de ej använder sig av route-reflectors). Nedan följer ett konfigurationsexempel för confederations i NetherLights PEs, exempelvis AmsterdamRed.

router bgp 31
 bgp confederation identifier 300
 bgp confederation peers 34 42 44 46

Inom varje confederation används sedan full-mesh IBGP peering, förutom i Czechlight där antalet BGP Speakers var något fler än övriga länder och nätet kompletterades därför även med Route-Reflectors.  

czechlights-bgp

PE PragRed

router bgp 42
 no synchronization
 bgp router-id 37.42.63.101
 bgp cluster-id 1
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 31 
 neighbor czechlight peer-group
 neighbor czechlight remote-as 42
 neighbor czechlight update-source Loopback0
 neighbor czechlight route-reflector-client
 neighbor 37.31.42.1 remote-as 31
 neighbor 37.31.42.1 description AmsterdamRed
 neighbor 37.42.63.102 peer-group czechlight
 neighbor 37.42.63.102 description PragBlue
 neighbor 37.42.127.101 peer-group czechlight
 neighbor 37.42.127.101 description PlzenRed
 neighbor 37.42.127.102 peer-group czechlight
 neighbor 37.42.127.102 description PlzenBlue
 neighbor 37.42.191.101 peer-group czechlight
 neighbor 37.42.191.101 description BrnoRed
 neighbor 37.42.191.102 peer-group czechlight
 neighbor 37.42.191.102 description BrnoBlue
 no auto-summary

MPLS

För att sätta upp MPLS användes följande konfig, vi behöver endast peera mot andra PEs över vpnv4 (vilket dock i detta nät blir varje core-router).

PE AmsterdamRed
mpls label protocol ldp
interface FastEthernet0/0
 description to AmsterdamBlue
 ip address 37.31.255.1 255.255.255.252
 mpls ip

interface Serial0/0
 description to PragRed
 ip address 37.31.42.1 255.255.255.252 
 mpls ip

interface FastEthernet0/1
 description to ISP-Peer

  interface FastEthernet0/1.10
   encapsulation dot1Q 1 native
   ip vrf forwarding Internet_Access
   ip address 37.31.255.5 255.255.255.252

interface Serial0/1
 description to KistaRed
 ip address 37.31.46.1 255.255.255.252
 mpls ip

ip bgp-community new-format

router bgp 31
 no synchronization
 bgp router-id 37.31.255.1
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 32 42 44 46 
 neighbor 37.31.42.2 remote-as 42
 neighbor 37.31.42.2 description PragRed
 neighbor 37.31.46.2 remote-as 46
 neighbor 37.31.46.2 description KistaRed
 neighbor 37.31.255.102 remote-as 31
 neighbor 37.31.255.102 description AmsterdamBlue
 neighbor 37.31.255.102 update-source Loopback0
 no auto-summary

  address-family vpnv4
   neighbor 37.31.42.2 activate
   neighbor 37.31.42.2 send-community both
   neighbor 37.31.46.2 activate
   neighbor 37.31.46.2 send-community both
   neighbor 37.31.255.102 activate
   neighbor 37.31.255.102 send-community both
   exit-address-family

mpls ldp router-id Loopback0 force

VRFs

Följande VRFs sattes upp tillsvidare:

  • 300:10 Light-Internal  
  • 300:20 Light-Datacenter 
  • 300:30 Light-Storage  
  • 300:300 Internet_Access 
    • Här importeras samtliga kund-VRF:er som önskar Internet-access och innehåller full BGP routing-table, kräver att kunden har en publik ip-adress och annonseras till andra peering-partners
  • 300:301 Internet_Defaultroute 
    • Innehåller endast en default-route ut mot internet (till VRF Internet_Access). Används för kunder som ej använder BGP och importeras in i kundens VRF (vi vill inte exportera full bgp-table till varje VRF-instans)

Konfigexempel:

ip vrf Internet_Access
 rd 300:300
 export map DEFAULT-INJECT
 route-target import 300:300
 route-target import 300:310
ip vrf Internet_Defaultroute
 rd 300:301
 route-target export 300:301
 route-target import 300:301
ip vrf LIGHT
 rd 300:10
 route-target export 300:10
 route-target import 300:10

För att exportera default-routen från Internet_Access till VRF: 300:301 användes en export-map (route-map).

ip prefix-list DEFAULT-ROUTE seq 5 permit 0.0.0.0/0
route-map DEFAULT-INJECT permit 10
 match ip address prefix-list DEFAULT-ROUTE
 set extcommunity rt 300:301
route-map DEFAULT-INJECT permit 20
 set extcommunity rt 300:300

Vill vi sedan ge en kund internetaccess exporterar vi deras VRF till 300:300 och importerar 300:301 enligt följande:

ip vrf Cust-FortiAB
 rd 300:1001
 route-target export 300:1001
 route-target export 300:300
 route-target import 300:1001
 route-target import 300:301

För att få in full bgp-table till VRF: Internet_Access behöver vi endast peera mot andra ISPs över den specifika VRF:en. För att säkerställa att varken våra peering-partner eller Lightkoncernen och dess externa kunder av misstag skulle börja annonsera privata adresser används prefixlistor för att filtrera routing-uppdateringar både in & ut.

interface FastEthernet0/1.10
 description to ISP-1
 encapsulation dot1Q 1 native
 ip vrf forwarding Internet_Access
 ip address 37.31.255.5 255.255.255.252

ip prefix-list rfc1918 deny 0.0.0.0/8 le 32
ip prefix-list rfc1918 deny 10.0.0.0/8 le 32
ip prefix-list rfc1918 deny 127.0.0.0/8 le 32
ip prefix-list rfc1918 deny 169.254.0.0/16 le 32
ip prefix-list rfc1918 deny 172.16.0.0/12 le 32
ip prefix-list rfc1918 deny 192.0.2.0.0/24 le 32
ip prefix-list rfc1918 deny 192.168.0.0/16 le 32
ip prefix-list rfc1918 deny 224.0.0.0/3 le 32
ip prefix-list rfc1918 permit 0.0.0.0/0 le 32

router bgp 31
 address-family ipv4 vrf Internet_Access
  neighbor 37.31.255.6 remote-as 100
  neighbor 37.31.255.6 activate
  neighbor 37.31.255.6 prefix-list rfc1918 in
  neighbor 37.31.255.6 prefix-list rfc1918 out
  aggregate-address 37.0.0.0 255.0.0.0 summary-only
  exit-address-family

Vilket ger följande routing-tabell på ISP-1:

ISP-1#sh ip route bgp
 200.200.200.0/32 is subnetted, 1 subnets
 B 200.200.200.200 [20/0] via 37.31.255.5, 00:02:59
 217.21.0.0/26 is subnetted, 2 subnets
 B 217.21.0.64 [20/0] via 37.31.255.5, 00:02:59
 B 217.21.0.0 [20/0] via 37.31.255.5, 00:02:59
 37.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
 B 37.0.0.0/8 [20/0] via 37.31.255.5, 00:00:03

Blev tyvärr en väldigt kort inlägg det här men har inte riktigt tid just nu att gå på djupet och förklara mer ingående, får ta nya tag efter nästa veckas tentor. 🙂

CCDP – Projektet äntligen klart

Blev igår äntligen helt klar med mitt CCDP-projekt jag jobbat med senaste fyra veckorna, landade tillslut på 77 sidor och iaf enligt mig själv en hel del snygga lösningar – men det återstår att se vad feedbacken blir från kursansvariga sen. 🙂

projekt

Då jag har tenta i både design och routing nästa vecka får vi se hur mycket tid det kommer finnas till att skriva inlägg här, men några stycken ska jag allt försöka hinna med – framförallt om MP-BGP/MPLS/VRF-leaking som är riktigt intressant!

Fullt upp med design-kursen!

Har tyvärr inte haft tid att posta några inlägg på senare tid men har en hel del att gå igenom sen när jag väl känner att jag är i fas igen. Jobbar just nu med slutprojektet i Design (CCDP) som visade sig vara en heeel del jobb.

czechlightfull

Uppgiften består i att ta fram en design för ovanstående ISP, förutom att designa core-nätet ska vi även ta fram design för de interna kontorens LAN + VPN/Firewalls/IPS/QoS/Övervakning. Då jag dessutom kör hela projektet solo blir det lite extra.. spännande.. 😀

  • Huvudkontor Prag 500st
  • Brno 300st (+ datacenter + storage)
  • Plzen 50st (+ datacenter + storage)
  • Cern (Schweiz) 25st
  • Amsterdam 25st
  • Birmingham 25st
  • Kista 25st
  • Santa Cruz de Tenerife 25st
  • Kiruna

Jobbar just nu med att ta fram en design för Core-nätet för samtliga länder och testar mig fram i GNS3 hur jag bäst ska implementera alltihop, grymt kul! Börjat sätta mig in i MPLS/MP-BGP/VRF-leaking och börjar få till en riktigt snygg lösning nu om jag får säga det själv (även om det inte är lika vackert i gns3). 🙂

czeclightgns3

CCDP – High Availability & VSS

Tänkte skriva ett inlägg om Cisco’s VSS, vilket är en Cisco-proprietär lösning för att clustra två (eller fler, implementeras i par) fysiska 6500/4500 switch-chassin till en virtuell switch, vilket vi kommer se senare har en hel del fördelar sett till både prestanda & redundans. VSS finns just nu endast tillgängligt på Ciscos Catalyst 4500 & 6500-serie.

vss6500

High Availability

Layer 2 Looped

l2-loopad

Ovanstående är väl den vanligaste lösningen som åtminstone jag fått lära mig från CCNA/CCNP-spåret när vi vill ha redundans i access-lagret. Vi kör Lager 2 upp till distributions-lagret som i sin tur använder sig av något FHRP som HSRP eller VRRP.

Detta leder dock i sin tur att endast en distributions-switch är aktiv gateway (den andra står i standby och tar endast emot ~50% av returtrafiken tack vare lastbalansering), redundanta länkar blockeras dessutom av spanning-tree. Vi använder helt enkelt endast ~50-60% av den tillgängliga prestandan.

Genom att använda PVST/MST skulle vi dock åtminstone kunna lastbalansera mellan VLAN:en genom att göra D1 Active/RB för Vlan 20 och D2 Active/RB för Vlan 30 exempelvis, observera att STP-topologin kommer se annorlunda ut för de olika vlanen.

Layer 2 Loopfree

l2-loopfri

Om vi istället skulle konvertera etherchanneln mellan distributions-switcharna till en L3-länk kommer STP att släppa blockeringen på upplänkarna då det inte längre finns risk för någon loop, däremot är vi nu tvungna att använda oss av lokala vlan (vilket är en relativt ovanligt lösning fortfarande och kan vara svårt att realisera).

Vi kommer fortfarande endast ha en aktiv gateway, men vi kan åtminstone dela upp detta mellan distributions-switcharna för att få lastbalansering per vlan.

Layer 3 Routed

l3-routed

En tredje lösningen är att använda oss av ett helt routat nät, dvs köra Lager 3 hela vägen ner till access-lagret och låta exempelvis OSPF sköta hanteringen av redundanta länkar. Vi slipper även använda STP och det finns nu möjlighet att faktiskt använda all tillgänglig kapacitet då vi inte heller behöver något FHRP.

Detta är dock en betydligt dyrare lösning då det kräver access-switchar med MLS-funktioner och är därför inte heller den speciellt vanlig.

Cisco’s GLBP är även en tänkbar lösning för Layer 2-topologierna då det tillåter oss att ha flera aktiva gateways för ett och samma vlan, men verkar inte finnas implementerat i speciellt många switch-modeller ännu. Mer info om GLBP finns här & här!

Virtual Switching System

vss-logical

Då VSS slår samman distributions-switcharna till en logisk enhet ger det oss flera av fördelarna i likhet med den routade modellen. Vi behöver inte oroa oss för Spanning-tree och behöver heller inte använda oss av ett FHRP för Gateway-redundans.  Det ger oss även möjlighet att sätta upp en variant av Etherchannel (MEC) trots att vi terminerar kablarna i två skilda chassin, mer om detta längre ner i inlägget.

VSS-domain

VSS använder sig av SSO & NSF för att snabbt kunna svänga över till Standby-routern om ett fel skulle inträffa. Den aktiva switchen sköter alla “Control Plane”-funktioner som exempelvis:

  • Management (SNMP, Telnet, SSH)
  • Layer 2 Protokoll (BPDU, PDUs, LACP, PAgP etc)
  • Layer 3 Protokoll (OSPF, EIGRP etc)
  • Software data

Observera dock att “Data Plane” fortfarande är aktivt på Standby-switchen och används fullt ut till skillnad mot exempelvis HSRP! Både Active & Standby sköter individuellt forwarding lookups för inkommande trafik via “Policy Feature Card (PFC)”.

Vi kan verifiera vilken switch som är aktiv via kommandot “show switch virtual”:

vss#show switch virtual
Switch mode: Virtual Switch
Virtual switch domain number: 200 
Local switch number: 1 
Local switch operational role: Virtual Switch Active 
Peer switch number: 2 
Peer switch operational role: Virtual Switch Standby

Virtual-MAC

vss-mac

När vi bootar upp vår virtuella switch kommer den som är Active att sätta sin MAC-adress på samtliga Layer 3-interface, standby-switchen hämtar denna information och använder samma MAC på sina egna interface. Även om ett avbrott inträffar och Standby slår över till Active kommer den fortfarande att behålla denna MAC-adress! Startar vi däremot om båda switcharna och Dist-2 behåller sin roll som active kommer mac-adressen att ändras (till 5678 i ovanstående exempel).

Det finns även möjlighet att istället använda en virtuell mac-adress för att försäkra sig om att MAC-adressen alltid kommer vara densamma oavsett vilken av switcharna som blir aktiv efter omstart.  Switchen räknar själv ut adressen genom att kombinera VSS-gruppnumret med en pool av VSS-adresser. Konfigurationen är enligt följande:

VSS(config-vs-domain)# switch virtual domain 100
VSS (config-vs-domain)#mac-address use-virtual
Configured Router mac address (0008.e3ff.fd34) is different from operational 
value (0013.5f48.fe40). Change will take effect after the configuration is saved 
and the entire Virtual Switching System (Active and Standby) is reloaded.
VSS(config-vs-domain)#

VSL – Virtual Switch Link

En speciell typ av Etherchannel sätts upp mellan switcharna, VSL, för att ge den aktiva switchen möjlighet att kontrollera hårdvaran i standby-switchen. Den används även för att skicka information om “line card status”, Distributed Forwarding Card (DFC) programmering, system management, diagnostik men även vanlig data-trafik när det är nödvändigt.

vss-vsh

För att försäkra sig om att VSL-control frames har prioritet över vanlig datatrafik enkapsuleras data i en speciell “Virtual Switch Header (VSH)” på 32 bitar och sätter Priority-biten till 1. All trafik lastbalanseras och använder underliggande Etherchannel-protokollen LACP eller PAgP för att sätta upp kanalen. 6500 Switcharna har förövrigt en hel del mer hashing-scheman att använda till skillnad mot 3650 vi använder i skolan. 😉

vss(config)#port-channel load-balance ? 
dst-ip Dst IP Addr 
dst-mac Dst Mac Addr 
dst-mixed-ip-port Dst IP Addr and TCP/UDP Port 
dst-port Dst TCP/UDP Port 
mpls Load Balancing for MPLS packets 
src-dst-ip Src XOR Dst IP Addr 
src-dst-mac Src XOR Dst Mac Addr 
src-dst-mixed-ip-port Src XOR Dst IP Addr and TCP/UDP Port 
src-dst-port Src XOR Dst TCP/UDP Port 
src-ip Src IP Addr 
src-mac Src Mac Addr 
src-mixed-ip-port Src IP Addr and TCP/UDP Port 
src-port Src TCP/UDP Port

Har vi dessutom ett Supervisor Engine 2T-kort kan vi använda lastbalansera baserad på VLAN-information:

VSS2T(config)# port-channel load-balance ?
dst-ip Dst IP Addr 
dst-mac Dst Mac Addr 
dst-mixed-ip-port Dst IP Addr and TCP/UDP Port
dst-port Dst TCP/UDP Port
mpls Load Balancing for MPLS packets
src-dst-ip Src XOR Dst IP Addr 
src-dst-mac Src XOR Dst Mac Addr 
src-dst-mixed-ip-port Src XOR Dst IP Addr and TCP/UDP Port
src-dst-port Src XOR Dst TCP/UDP Port
src-ip Src IP Addr 
src-mac Src Mac Addr 
src-mixed-ip-port Src IP Addr and TCP/UDP Port
src-port Src TCP/UDP Port
vlan-dst-ip Vlan, Dst IP Addr 
vlan-dst-mixed-ip-port Vlan, Dst IP Addr and TCP/UDP Port
vlan-src-dst-ip Vlan, Src XOR Dst IP Addr 
vlan-src-dst-mixed-ip-port Vlan, Src XOR Dst IP Addr and TCP/UDP Port
vlan-src-ip Vlan, Src IP Addr 
vlan-src-mixed-ip-port Vlan, Src IP Addr and TCP/UDP Port

Fantastiskt nog har Cisco även implementerat en ny funktion för att faktiskt verifiera vilken väg trafiken tar, något som var oerhört omständigt tidigare, är väl bara att hoppas att detta även kommer i nyare IOS-versioner för de “enklare” switcharna också sen.

Det har även implementeras något som kallas “Adaptive Load-balacing”, vilket gör att switchen inte längre behöver behöver resetta sina portar om ett interface tas bort/läggs till i etherchanneln (avbrott som annars varade ~200-300ms, vilket på en 10Gb-länk kan vara en hel del förlorad data).

vss#sh etherchannel load-balance hash-result ?
interface Port-channel interface
ip IP address
ipv6 IPv6 
l4port Layer 4 port number 
mac Mac address 
mixed Mixed mode: IP address and Layer 4 port number 
mpls MPLS 
vss#sh etherchannel load-balance hash-result interface port-channel 120 ip 192.168.220.10 192.168.10.10 
Computed RBH: 0x4 
Would select Gi1/2/1 of Po120

vss-vslboot

När vi aktiverat VSS på switcharna används RRP för att bestämma vilken av switcharna som ska ta rollen som Active. Vi kan på förhand bestämma vilken vi vill ha som aktiv genom att konfigurera priority på båda switcharna.

Det finns även möjlighet till att konfigurera preemption, men detta avråder man ifrån att använda i Arch-boken då det leder till längre konvergenstid. VSL Etherchanneln måste bestå av minst två 10Gb-länkar (max 8) och ska helst termineras i två skilda linjekort för maximal redundans.

Multichassis EtherChannel (MEC)

vss-mec

En av de största fördelarna med VSS förutom den ökade redundansen är möjligheten att sätta upp en variant på Etherchannel trots att den fysiska kopplingen går till två skilda chassin. Lösningen kallas Multichassis Etherchannel (MEC) och kan konfigureras som både L2 eller L3. I princip fungerar MEC precis som en helt vanlig Etherchannel men något som däremot skiljer sig är hur lastbalanseringen utförs.

Istället för att endast använda en hashing-algoritm för att bestämma vilken port som skall användas prioriterar MEC alltid lokala interface över interface den behöver gå via VSL-länken för att nå. För trafik som måste floodas ut på VLANet (broadcast, multicast eller unknown unicast) skickas en kopia av paketet över VSL-länken, men från den dokumentation jag hittat ignoreras tydligen detta paket av mottagaren då den förutsätter att paketet redan skickats ut på LAN:et vilket låter lite märkligt, så hur väl detta stämmer låter jag vara osagt…

Inkommande “Control Plane”-trafik som STP, PAgP eller VTP-data kommer däremot att vidarebefordras över VSL-länken till Active-switchen då det bara finns en aktiv RP. MEC har förövrigt stöd för både PAgP & LACP och alla förhandlingar sköts av Active-switchen.

Om samtliga lokala interface på något av chassina skulle gå ner konverteras MEC till en vanlig Etherchannel och trafiken fortsätter skickas över VSL-länken istället utan något längre avbrott.

Redundans

Standby-switchen använder följande funktioner för att upptäcka eventuella fel som uppstår på primären:

  • VSL Protocol
  • Cisco Generic Online Diagnostics (GOLD) failure event
  • CDL-based hardware assistance
  • Full VSL-link down

vss-failover

Om standby upptäcker ett avbrott initieras en SSO switchover och den tar över rollen som Active vilket enligt Cisco ska ta under sekunden att göra.  Om däremot det endast är en av VSL-länkarna som går ner fortsätter switcharna precis som vanligt, däremot kommer trafik som skickas över återstående VSL-länkar att få en höjd delay på ~50-100ms.

Om däremot samtliga VSL-länkar går ner uppstår det en hel del problem!

vss-dualactive

Standby upptäcker att den inte längre har kontakt med Active och initierar därför en SSO failover och går själv över till Active-state. Men switchen som redan var i Active kommer däremot endast tro att den tappat kontakt med Standby och fortsätter som vanligt. Vi har nu två switchar som båda är i Active och som bl.a. använder samma IP- & MAC-adresser.

Detta leder ju i sin tur till en hel del problem som ip-konflikter och BPDU’s som skickas med samma Bridge-ID m.m. Det är därför väldigt viktigt med hög redundans för just VSL-länkarna och Cisco’s rekommendationer med att vi terminerar anslutningarna i olika linjekort.  Cisco har även implementerat ytterligare några säkerhetsfunktioner för att upptäcka detta så snabbt som möjligt:

  • Enchanced PAgP
  • Layer 3 BFD
  • Fast Hello

vss-pagp

Enhanced PAgP skickar vid avbrott på VSL-länken direkt ut ett PAgP-meddelande med TLV-fältet innehållandes dess VSS Active ID. Om de upptäcker en mismatch kommer den ena switchen direkt ställa sig i Recovery-mode istället.

Vi aktiverar detta via:

vss#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
vss(config)#switch virtual domain 10 
vss(config-vs-domain)#dual-active detection pagp 
vss(config-vs-domain)#dual-active trust channel-group 20 
vss(config-vs-domain)#

vss-fasthellos

Fast Hello’s kräver en dedikerad L2-länk mellan switcharna som endast används för att skicka just Fast Hellos, konfigen är dock väldigt simpel.

vss(config)# interface fastethernet 1/2/40
vss(config-if)# dual-active fast hello
WARNING: Interface FastEthernet1/2/40 placed in restricted config mode. All 
extraneous configs removed!
vss(config)# switch virtual domain 10
vss(config-vs-domain)# dual-active detection fast hello
vss(config-vs-domain)# exit)

BFD spar vi till en annan gång då det känns värdigt ett helt eget inlägg. :

CCDP – Cisco’s PPDIOO Lifecycle

cisco-ppdioo

PPDIOO är Cisco’s best practice-upplägg för hur ett nätverk ska implementeras/designas/uppgraderas och är uppbyggt enligt följande sex faser.

  • Prepare

Går egentligen endast ut på att sammanställa information från “High level managers” om vad företaget har för affärsmål, vilka produker de använder, funktioner som saknas och vad som skulle kunna tänkas behövas i framtiden.

Exempel: Om kunden vill implementeras ett WLAN behöver vi först ta reda på mer information. Hur många användare kommer använda WLAN:et? Kommer det användas av endast anställda eller ska det även finnas tillgängligt för gäster? Vilka applikationer ska supportas? Säkerhet? Hastigheter?

Nästa steg är ett leta efter hårdvara som matchar dessa krav.

  • Plan

Här gör vi en “audit” av det nuvarande nätverket och beroende på vilken typ av projekt vi ska implementera bestämmer vad vi behöver se över mer ingående. Exempelvis IOS Versioner, CPU/Minnes-användning, nuvarande trafiktyper och beslastning via Netwflow, länkbelaastningar etc.

Nästa steg är att planera implementationen genom att göra steg för steg instruktioner, vi måste även inkludera “stopping points” där vi testar konfigurationen och “roll backs” om något skulle gå fel.

Exempel: Din kund vill implementera ett 802.11N WLAN, vi behöver då bl.a. kontrollera om switcharna har stöd för PoE, finns det tillräckligt med tillgänglig bandbredd i det befintliga nätverket för att supporta dessa hastigheter m.m. Vi bör även utföra en site-survey och kartlägga eventuella störningskällor och existerande WLAN för kanal-planering.

  • Design

Baserat på vilka krav från kunden vi fått fram i “Prepare”-fasen och den tekniska information vi sammanställt i “Prepare”-fasen kan vi nu börja designa en ny topologi. Detta bör inkludera alla delar (IP-adressering, VLANs, redundans, säkerhet etc) som vi kan behöva senare i projektet.

Exempel: Efter site-survey och inventering av det nuvarande nätverket kan vi designa en plan innehållande inköp av hårdvara (AP’s/WLC/PoE-Switchar etc), ritning med placering av APs, nätverksdiagram, subnetting osv.

  • Implement

Det är nu vi implementerar vår nya topologi genom att installera ny hårdvara och konfigurera nätet. Om vi gjort ett bra jobb i “Plan”-fase ska det egentligen bara att följa dokumentationen steg för steg. Vi bör även testa lösningen flera gånger under tiden vi implementerar nätet för att upptäcka problem tidigt.

Exempel : Hårdvaran vi beställt (AP, WLC, Radius-server & switchar) har nu anlänt till kunden. Vi följer implementeringsplanen och installerar switcharna, konfigurerar WLCs, sätter upp APs och konfigurerar alla enheter. Vi bör även testa WLAN:et så allt fungerar tillfredsställande innan vi exempelvis implementerar säkerhet som Dot1x och ACLs.

  • Operate

Det nya nätverket är nu i drift och används i det dagliga arbetet. Vi bör här även ha implementerat övervakning av både hårdvara och prestande samt se till att vi har de senaste mjukvaruuppdateringarna etc.

  • Optimize

Utifrån de eventuella problem/brister vi upptäcker i “Operate”-fasen bör nätet optimeras genom att införa både små och stora förbättringar till det nuvarande nätet. Om det är något väldigt kritiskt bör vi dock gå tillbaka till första steget igen och göra om hela cykeln.

Exempel: Användare av WLANet klagar på att det är undermålig prestanda i en viss del av lokalen. Via en spectrum/protocol-analyzer upptäcker vi att det finns annan utrustning i närheten som också använder 5 GHz-bandet som vi missat i vår site-survey. Vi löser problemet genom att byta frekvens på närliggande APs.

CCDP!

ccdp_design_large

Fick i veckan dispans av MDH för att läsa deras CCDP-kurs redan nu över vintern tillsammans med de som läser 3:e året, sweet! Så får skjuta lite på CCIE-studierna  och läsa design istället. 🙂