Reliable Policy-based routing

Here’s another lab taking on how to set up reliable policy-based routing. The basic configuration is identical to a previous lab I did about policy-routing, so if you’re interested in the basics I suggest you also take a look there for an easier intro. This one ends up using some pretty nifty functions within route-maps to set up a secondary next-hop tied in with IP SLA-tracking & CDP that I haven’t seen earlier.

Lab requirements:

Basic routing:

  1. Configure a default-route on R3 towards R1s local interface (Gi1.13)
  2. Configure a default-route on R4 & R6 towards R1s local interface (Gi1.146)
  3. Configure a default-route on R5 towards R1s DMVPN-interface (Tu0)
  4. Configure static routes thru the DMVPN-cloud on R3 for R5’s Lo0, and vice versa on R5 for R3’s lo0

Policy-routing:

  1. Configure policy-routing on R1 so that traffic sourced from R4s G1.146 is routed to R3 over Gi1.13
  2. Configure policy-routing on R1 so that traffic sourced from R6s Gi1.146 is routed to R5 over DMVPN

Reliability:

  1. Configure CDP between R1 & R5 over DMVPN-cloud
  2. Configure IP SLA on R1 that confirms connection to R3 every 5 seconds
  3. Modify R1’s policy-routing so that if R1 loses ICMP reachability to R3, traffic from R4 is rerouted to R5 over the DMVPN-cloud
  4. Modify R1’s policy-routing so that if R1 loses R5 as CDP-neighbor, traffic from R6 is rerouted to R3 over the ethernet link (Gi1.13)

Let’s start with the easy stuff, the basic routing is very… basic, no explanation needed.

! Basic-1 R3

ip route 0.0.0.0 0.0.0.0 Gi1.13 155.1.13.1

! Basic-2
! R4

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! R6

ip route 0.0.0.0 0.0.0.0 Gi1.146 155.1.146.1

! Basic-3 R5

ip route 0.0.0.0 0.0.0.0 Tu0 155.1.0.1

! Basic-4
! R3
ip route 150.1.5.5 255.255.255.255 Tu0 155.1.0.5

! R5
ip route 150.1.3.3 255.255.255.255 Tu0 155.1.0.3

As in the previous lab, R1 has no routes so we won’t be able to pass much traffic yet.  Let’s take a look at setting up the policy-routing prerequisites so we can start testing basic functionality. First we’ll need an access-list to match the source-address of R4 & R6, then we manually set next-hop with a route-map and attach it to our incoming interface.

! Policy-routing R1

ip access-list extended R4
 permit ip host 155.1.146.4 any

ip access-list extended R6
 permit ip host 155.1.146.6 any

route-map RPR permit 10
 match ip address R4
 set ip next-hop 155.1.13.3

route-map RPR permit 20
 match ip address R6
 set ip next-hop 155.1.0.5

interface Gi1.146
 ip policy route-map RPR

We should now have basic connectivity finally, packets from R4 should be routed to R3 first whatever the destination:.

R4#ping 150.1.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/6/6 ms

R4#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 4 msec 4 msec
 2 155.1.13.3 5 msec 5 msec 5 msec
 3 155.1.0.5 5 msec * 5 msec

Packets from R6 should be routed to R5 first whatever the destination:

R6#ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/12/27 ms

R6#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 4 msec 4 msec
 2 155.1.0.5 5 msec 5 msec 5 msec
 3 155.1.0.3 5 msec * 5 msec

Everything is looking fine so far! Now to the tricky part with setting up reliability, cdp is easy though. We just enable it on both of our tunnel interfaces:

! Reliability-1 R1 & R5
cdp run
interface Tu0
 cdp enable

Next requirement was to set up IP SLA that tracks the connection between R1 & R3’s Gi1.13 every 5 seconds. We’ll do this in R1 as it will be the router doing the policy-routing later.

! Reliability-2 R1
ip sla 100
 icmp-echo 155.1.13.3 source-interface Gi1.13
 frequency 5

ip sla schedule start-time now life forever

track 1 ip sla 100 state

Let’s verify that everything’s OK this far:

R1#sh ip sla statistics 100
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
 Latest RTT: 4 milliseconds
Latest operation start time: 17:00:09 UTC Wed Apr 11 2018
Latest operation return code: OK
Number of successes: 63
Number of failures: 0
Operation time to live: Forever

R1#sh track
Track 1
 IP SLA 100 state
 State is Up
 3 changes, last change 00:16:29
 Latest operation return code: OK
 Latest RTT (millisecs) 3
 Tracked by:
 Route Map 0

R5#sh cdp neighbors detail 
-------------------------
Device ID: R1
Entry address(es): 
 IP address: 155.1.0.1
Platform: cisco CSR1000V, Capabilities: Router IGMP 
Interface: Tunnel0, Port ID (outgoing port): Tunnel0
Holdtime : 138 sec

Version :
Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S6, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2017 by Cisco Systems, Inc.
Compiled Mon 24-Jul-17 20:01 by mcpre

advertisement version: 2
Management address(es): 
 IP address: 155.1.0.1

Next step on how to use tracking with policy-routing had me stuck for quite a while, scrolling thru the Cisco Docs I finally found a page that had some examples of what we’re trying to do at:

Configuration Guides -> IP Routing: Protocol-Independent Configuration Guide – > PBR Support for Multiple Tracking Options

First requirement was to use our IP SLA 100 / Track 1 that’s currently verifying connection is up between R1 & R3. Our route-map currently looks like this for reference:

route-map RPR permit 10
 match ip address R4
 set ip next-hop 155.1.13.3
route-map RPR permit 20
 match ip address R6
 set ip next-hop 155.1.0.5

We’ll modify the first entry by removing the static next-hop for R4 and replace it with the command “set ip next-hop verify-availability [next-hop-address sequence track object]”. We also have to add something as a fallback next-hop if the tracker goes down, here the “set ip default” command looks like what we want to use. You can find more info here:

Configuration Guides -> IP Routing: Protocol-Independent Configuration Guide – > Policy-Based Routing Default Next-Hop Routes

“set ip default next-hop ip-address [ip-address]”- Specifies the next hop for routing packets if there is no explicit route for this destination.

Our final route-map for policy-routing R4 will look like this:

route-map RPR permit 10
 match ip address R4
 set ip-next verify availability 155.1.13.3 1 track 1
 set ip default next-hop 155.1.0.5

For R6 I had much bigger problems however. Here we were supposed to use CDP for tracking but I couldn’t manage to find any specific information about it more than that “set ip-next verify availability” has CDP-support. A quick google-search showed that it’s really basic however, we only use the actual command “set ip-next verify availability” and IOS will automatically do CDP-lookups before setting the chosen next-hop, in this case we still need the static set ip next-hop however. The final result will look something like this:

route-map RPR permit 20
 match ip address R6
 set ip next-hop 155.1.0.5
 set ip next-hop verify-availability
 set ip default next-hop 155.1.13.3

Let’s verify again:

R1#sh route-map
route-map RPR, permit, sequence 10
 Match clauses:
 ip address (access-lists): R4 
 Set clauses:
 ip next-hop verify-availability 155.1.13.3 1 track 1 [up]
 ip default next-hop 155.1.0.5
 Policy routing matches: 6 packets, 276 bytes
route-map RPR, permit, sequence 20
 Match clauses:
 ip address (access-lists): R6 
 Set clauses:
 ip next-hop 155.1.0.5
 ip next-hop verify-availability
 ip default next-hop 155.1.13.3
 Policy routing matches: 18 packets, 828 bytes

A traceroute from R4 should always take the route via R3 as long as there’s reachability between R1 & R3:

R4#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 8 msec 5 msec 5 msec
 2 155.1.13.3 5 msec 5 msec 5 msec
 3 155.1.0.5 5 msec * 5 msec

Let’s see what happens when we take down the connection between R1 & R3:

R1#debug ip policy 
Policy routing debugging is on

R3(config)#int gi1.13
R3(config-subif)#shut

PBR Nexthop: Unregister tracking for 155.1.13.3, handle: 7F74CD6A6768
PBR Nexthop Callback invoked: 7F74F117B6C0, (155.1.13.3) tableid 0, status: 0, type: SET NEXTHOP TRACKINGmap: RPR, sequence: 10
PBR Control Plane Notification: 155.1.0.5 PBR_CP_SET_DEFAULT_NEXTHOP
Policy NextHop Inquiry: RPR seq: 10, type: SET DEFAULT NEXTHOP Nexthop: 155.1.0.5SW_OBJ_TYPE: 1E, SW_HANDLE: 7F74F1108FE8
PBR CP Notification sent: Type:SET DEFAULT NEXTHOP, 155.1.0.5SW_OBJ_TYPE: 1E, SW_HANDLE: 7F74F1108FE8

Let’s do another traceroute, the traffic should jump directly to R5 instead:

R4#traceroute 150.1.5.5
Type escape sequence to abort.
Tracing the route to 150.1.5.5
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 4 msec 4 msec 4 msec
 2 155.1.0.5 4 msec * 4 msec

Sweet! Let’s try the same for R6, all traffic should always first be redirected to R5:

R6#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 5 msec 5 msec 4 msec
 2 155.1.0.5 5 msec 5 msec 5 msec
 3 155.1.0.3 5 msec * 5 msec

Looking good so far. Lets disable CDP on R5s Tunnel0 interface and wait out the hold-timer (180 seconds), not a very fast switchover with default timers…

! R5
interface Tu0
 no cdp enable

After a long wait R5 is no longer showed in cdp-table:

R1#sh cdp neighbors 
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
 S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone, 
 D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
R10 Gig 1 172 R I CSR1000V Gig 1
R2 Gig 1 126 R I CSR1000V Gig 1
R3 Gig 1 131 R I CSR1000V Gig 1
R6 Gig 1 132 R I CSR1000V Gig 1
R7 Gig 1 166 R I CSR1000V Gig 1
R4 Gig 1 151 R I CSR1000V Gig 1
R8 Gig 1 150 R I CSR1000V Gig 1
R9 Gig 1 158 R I CSR1000V Gig 1

A traceroute should now go directly to R3 instead (don’t forget to open the interface we previously shutdown).

R6#traceroute 150.1.3.3
Type escape sequence to abort.
Tracing the route to 150.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
 1 155.1.146.1 6 msec 5 msec 3 msec
 2 155.1.0.5 5 msec 5 msec 5 msec
 3 155.1.0.3 5 msec * 5 msec

Not what we were hoping for.. Traffic is for some reason still routed over to R5 even though we have no CDP-reachability. I tried troubleshooting this forever but finally found a notation that there’s apparently a bug in the CSR-1000V routers when it comes to verify-availability & CDP tracking(!!). The config looks OK though from other examples I could find so this is how it’s “supposed” to work at least.. Fun times. 🙂

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. :

CCNP – MDH Switchprojekt del 2

Har varit lite dåligt med inlägg på senare tid, har pluggat multicast senaste ~2 veckorna men inte riktigt funnit motivationen att skriva inlägg om de mer teoretiska bitarna då det redan finns så oändligt med info om det redan.

Tänkte istället visa några av lösningarna vi använt oss av i switch-projektet som nämdes i tidigare inlägg.

Topologin ser ut enligt följande:

switchprojekt

Vi kör EIGRP på alla L3-enheter, dvs R1-3, S1 & S3.

MSTP

7. Konfigurera MSTP på alla switchar. Lägg VLAN 10 och 20 till instans 1, och VLAN 30 och 99 till instans 2. Gör S1 till spanning-tree root for instans 1 och backup root för instans 2. S3 skall vara root for instans 2 och backuproot för instans 1.

S1

spanning-tree mode mst
spanning-tree mst configuration
 name cisco
 revision 1
 instance 1 vlan 10, 20
 instance 2 vlan 30, 99
!
spanning-tree mst 1 priority 24576
spanning-tree mst 2 priority 28672

S2

spanning-tree mode mst
spanning-tree mst configuration
 name cisco
 revision 1
 instance 1 vlan 10, 20
 instance 2 vlan 30, 99

S3

spanning-tree mode mst
spanning-tree mst configuration
 name cisco
 revision 1
 instance 1 vlan 10, 20
 instance 2 vlan 30, 99
!
spanning-tree mst 1 priority 28672
spanning-tree mst 2 priority 24576

HSRP

8. S1 och S3 skall vara gateways för VLANen och ni skall använda HSRP för redundans. för access layer hosts i VLANs 10, 20, 30, and 99.
9. S1 skall vara active HSRP router för VLAN 10 och 20 konfigurera S3 som backup. Konfigurera S3 som active router för VLAN 30 och 99 och S1 som backup för dessa VLAN.

S1

interface Vlan10
 description Client
 ip address 172.16.10.1 255.255.255.0
 ip helper-address 172.16.32.193
 standby 1 ip 172.16.10.254
 standby 1 priority 150
 standby 1 preempt
 no shutdown
!
interface Vlan20
 description Voice
 ip address 172.16.20.1 255.255.255.0
 standby 1 ip 172.16.20.254
 standby 1 priority 150
 standby 1 preempt
 no shutdown
!
interface Vlan30
 description Server
 ip address 172.16.30.1 255.255.255.0
 ip helper-address 172.16.32.193
 standby 2 ip 172.16.30.254
 standby 2 priority 80
 no shutdown
! 
interface Vlan99
 description Management
 ip address 172.16.99.1 255.255.255.0
 standby 2 ip 172.16.99.254
 standby 2 priority 80
 no shutdown

S3

interface Vlan10
 description Client
 ip address 172.16.10.3 255.255.255.0
 ip helper-address 172.16.32.193
 standby 1 ip 172.16.10.254
 standby 1 priority 80
 no shutdown
!
interface Vlan20
 description Voice
 ip address 172.16.20.3 255.255.255.0
 standby 1 ip 172.16.20.254
 standby 1 priority 80
 no shutdown
!
interface Vlan30
 description Server
 ip address 172.16.30.3 255.255.255.0
 ip helper-address 172.16.32.193
 standby 2 ip 172.16.30.254
 standby 2 priority 120
 standby 2 preempt
 no shutdown
!
interface Vlan99
 ip address 172.16.99.3 255.255.255.0
 standby 2 ip 172.16.99.254
 standby 2 priority 120
 standby 2 preempt

EIGRP

16. På S1 och S3 ska ni routa med EIGRP, det som skall synas i routingtabellerna på 2800-routrarna är en manuellt summerad adress av de adresser som finns på S1, S2 och S3. Givetvis skall adresser som används på R1, R2 och R3 summeras på lämpligt sätt om man tittar på det i någon av 3560-switcharna.

Fixade en visio-bild så det blir lite tydligare vad det är som efterfrågas:

summary-projekt

Konfigen för S1 & S3 är väldigt simpel.

S1

interface FastEthernet0/5
 description To R1
 no switchport
 ip address 172.16.11.1 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 GRPM
 ip summary-address eigrp 1 172.16.0.0 255.255.0.0
 srr-queue bandwidth share 1 30 35 5
 priority-queue out 
 mls qos trust dscp
 auto qos trust 
 speed 100
 duplex full

S3

interface FastEthernet0/5
 description To R1
 no switchport
 ip address 172.16.33.3 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 GRPM
 ip summary-address eigrp 1 172.16.0.0 255.255.0.0
 srr-queue bandwidth share 1 30 35 5
 priority-queue out 
 mls qos trust dscp
 spanning-tree portfast
 speed 100
 duplex full

För R1 vill vi endast annonsera 172.16.32.0/24 ner till S1, och 172.16.0.0/16 upp till R2.

interface FastEthernet0/1
 description to S1
 ip address 172.16.11.11 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 GRPM
 ip summary-address eigrp 1 172.16.32.0 255.255.255.0 5
 duplex full
 speed 100
 auto qos voip trust 
 service-policy output AutoQoS-Policy-Trust
 no shutdown

För att filtrera bort alla “Connected”-nät och endast annonsera 172.16.0.0/16 till R2 behöver vi dock använda oss av en distribute-list.

interface Serial0/0/0
 description to R2
 bandwidth 256000
 ip address 172.16.32.1 255.255.255.192
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 GRPM
 auto qos voip trust 
 clock rate 256000
 service-policy output AutoQoS-Policy-Trust
 no shutdown

ip prefix-list INTERNAL-R2 seq 5 permit 172.16.0.0/16

router eigrp 1
 passive-interface default
 no passive-interface FastEthernet0/1
 no passive-interface Serial0/0/0
 no passive-interface Serial0/0/1
 network 172.16.0.0 0.0.255.255
 distribute-list prefix INTERNAL-R2 out Serial0/0/0
 no auto-summary

Samma sak gäller för R3.

interface FastEthernet0/1
 description to S1
 ip address 172.16.33.13 255.255.255.0
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 GRPM
 ip summary-address eigrp 1 172.16.32.0 255.255.255.0 5
 duplex full
 speed 100
 auto qos voip trust 
 service-policy output AutoQoS-Policy-Trust
 no shutdown

interface Serial0/0/0
 description to R1
 bandwidth 256000
 ip address 172.16.32.66 255.255.255.192
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 GRPM
 auto qos voip trust 
 clock rate 256000
 service-policy output AutoQoS-Policy-Trust
 no shutdown

ip prefix-list INTERNAL-R2 seq 5 permit 172.16.0.0/16

router eigrp 1
 passive-interface default
 no passive-interface FastEthernet0/1
 no passive-interface Serial0/0/0
 no passive-interface Serial0/0/1 
 network 172.16.0.0 0.0.255.255
 distribute-list prefix INTERNAL-R2 out Serial0/0/1
 no auto-summary

Då jag nu precis börjat läsa CCDP denna vecka samtidigt som CCNP-kursen kan vi nog komma tillbaka till den här topologin och införa lite förbättringar senare. 🙂

CCNP – MDH Switchprojekt

MDH har släppts ett mindre projekt som ska sammanfatta större delen av Switch i CCNP, är lite osäker på deadline men vi är i princip redan klara (tog 1 dag :P).

switchprojekt

Kraven var följande:

1. Använd 172.16.0.0/16 för denna case-study

  • Gör lämplig adressering
  • Denna skall återspeglas i tydlig adressplan

2. Länken mellan S1 och S3 skall vara en L3-länk med Etherchannel. Välj lämplig lastbalanseringsmetod och motivera era val.

3. Sätt S1 -> S2 och S3 -> S2 till trunkar. Den första skall vara statisk, den andra skall förhandla. Förklara de olika alternativen man kan använda för trunkar samt för- och nack-delar med att göra på de olika sätten.

Använd de dubbla förbindelserna till att skapa etherchannels med lämplig lastbalansering för en L2-länk och motivera ert val av metod.

4. Skapa en VTP-domän med lösenord. Alla enheter skall vara i ”transparent”. Förklara VTP och vilka ”mode” en enhet kan vara.

5. Alla switchar skall ha VLAN 10 med namn CLIENT, VLAN 20 med namn VOICE, VLAN 30 med namn SERVER, and VLAN 99 med namn MGMT. Tilldela respektive av dem ett subnät av lämplig storlek från er adressplan.

6. Se till att VLAN 1 inte används till användardata eller management och att ”native” återfinns på ett oanvänt VLAN.

7. Konfigurera MSTP på alla switchar. Lägg VLAN 10 och 20 till instans 1, och VLAN 30 och 99 till instans 2. Gör S1 till spanning-tree root for instans 1 och backup root för instans 2. S3 skall vara root for instans 2 och backup
root för instans 1.

  • Beskriv MSTP och en annan variant av Spanning-tree som går att konfigurera på labbutrustningen. Ge också exempel på fördelar och nackdelar med de olika varianterna.

8. S1 och S3 skall vara gateways för VLANen och ni skall använda HSRP för redundans. för access layer hosts i VLANs 10, 20, 30, and 99.

9. S1 skall vara active HSRP router för VLAN 10 och 20 konfigurera S3 som backup. Konfigurera S3 som active router för VLAN 30 och 99 och S1 som backup för dessa VLAN.

10. På S2, skapa en SVI för MGMT VLAN 99 med en lämplig adress från adressplanen och en default gateway.

11. Sätt PortFast på alla access-portar.

  • Förklara PortFast och vilka fördelar det ger.

12. Endast de VLAN som konfigurerats på switcharna får färdas över trunkarna.

13. På S2 skall Fa0/6 vara access port i CLIENT VLAN 10 och till att lita på Cisco IP-telefoners CoS med AutoQoS.
Använd VOICE VLAN 20 som voice VLAN.

14. På S2 ska Fa0/6 köra port security med två tillåtna MAC adresser. Använd sticky learning. Stäng porten vid
överträdelse, men den skall automatiskt öppnas efter två minuter.

  • Beskriv Port Security

15. Port Fa0/8 ska vara access port i SERVER VLAN 30.

16. På S1 och S3 ska ni routa med EIGRP, det som skall synas i routingtabellerna på 2800-routrarna är en manuellt
summerad adress av de adresser som finns på S1, S2 och S3. Givetvis skall adresser som används på R1, R2
och R3 summeras på lämpligt sätt om man tittar på det i någon av 3560-switcharna.

17. Ni skall ha en DHCP-server på R2 som skall dela ut adresser till CLIENT och SERVER. DHCP snooping ska
onfigureras enligt best practice på alla enheter.

  • Beskriv DHCP-snooping

18. Skapa ett Tcl script som testar att ni når alla aktiva enheter från S1 respektive S3.

Återkommer med hur vi konfade upp nätet efter vi lämnat in projektet men här ovan är iaf vår färdiga topologi, antar att det kan räknas som fusk om jag lägger ut vår konfig här redan nu… 🙂

CCNP Certifierad!

CISCO_CCNP

1000/1000 på Switch 642-813
945/1000 på TSHOOT 642-832

Tshoot var riktigt kul men oväntat lätt faktiskt. Var förvånande att man ej kunde använda sig av varken debug eller traceroute från klienterna men det gick bevisligen bra ändå. 🙂

Nu blir det en liten paus för att jobba ikapp min andra kurs i linux innan det är dags att sätta siktet på CCIE written.

TSHOOT – Part IV, Access-layer

tshoot-access

Vi fortsätter från tidigare inlägg där vi avslutade med att konfa upp L3/Routing/Redist. mellan R4 & DSW1 & 2. Innan vi ger oss på att konfa NAT & DHCP så fixar vi klart vårat access-layer först. Är lite osäker på om det ens är möjligt att sätta upp HSRP över switch-modulen men det märker vi väl.. 🙂

Layer 2

För att lägga till VLAN i NM-16ESW måste vi använda legacy-metoden “vlan database”, observera även att vi måste använda “show vlan-switch”.

DSW1

DSW1#vlan database
 DSW1(vlan)#vlan 10
 VLAN 10 added:
 Name: VLAN0010
 DSW1(vlan)#vlan 20
 VLAN 20 added:
 Name: VLAN0020
 DSW1(vlan)#vlan 200
 VLAN 200 added:
 Name: VLAN0200
 DSW1(vlan)#exit
 DSW1(config)#int range fa1/9 - 10
 DSW1(config-if-range)#switchport mode trunk
 DSW1(config-if-range)#switchport trunk encapsulation dot1q
 DSW1(config-if-range)#description to ASW1
 DSW1(config-if-range)#channel-group 1 mode on
 Creating a port-channel interface Port-channel1
 DSW1(config-if-range)#
 DSW1(config)#int range fa1/5 - 6
 DSW1(config-if-range)#switchport trunk encapsulation dot1q
 DSW1(config-if-range)#switchport mode trunk
 DSW1(config-if-range)#descrip to ASW2
 DSW1(config-if-range)#channel-group 4 mode on
 Creating a port-channel interface Port-channel4
 DSW1(config-if-range)#

DSW2

DSW2#vlan database
 DSW2(vlan)#vlan 10
 VLAN 10 added:
 Name: VLAN0010
 DSW2(vlan)#vlan 20
 VLAN 20 added:
 Name: VLAN0020
 DSW2(vlan)#vlan 200
 VLAN 200 added:
 Name: VLAN0200
 DSW2(vlan)#exi
 APPLY completed.
 Exiting....
DSW2(config)#int range fa1/9 - 10
 DSW2(config-if-range)#switchport trunk encaps dot1q
 DSW2(config-if-range)#switchport mode trunk
 DSW2(config-if-range)#desc to ASW2
 DSW2(config-if-range)#channel-group 1 mode on
 Creating a port-channel interface Port-channel1
DSW2(config-if-range)#int range fa1/5 - 6
 DSW2(config-if-range)#switchport trunk encaps dot1q
 DSW2(config-if-range)#switchport mode trunk
 DSW2(config-if-range)#desc to ASW1
 DSW2(config-if-range)#channel-group 5 mode on
 Creating a port-channel interface Port-channel5

ASW1

ASW1#vlan database
 ASW1(vlan)#vlan 10
 VLAN 10 added:
 Name: VLAN0010
 ASW1(vlan)#vlan 20
 VLAN 20 added:
 Name: VLAN0020
 ASW1(vlan)#vlan 200
 VLAN 200 added:
 Name: VLAN0200
 ASW1(vlan)#exit
 APPLY completed.
 Exiting....
ASW1(config)#no ip routing
 ASW1(config)#int range fa1/9 - 10
 ASW1(config-if-range)#switchport trunk encaps dot1q
 ASW1(config-if-range)#switchport mode trunk
 ASW1(config-if-range)#desc to DSW1
 ASW1(config-if-range)#channel-group 1 mode on
 Creating a port-channel interface Port-channel1
ASW1(config)#inte range fa1/5 - 6
 ASW1(config-if-range)#switchport trunk encaps dot1q
 ASW1(config-if-range)#switchport mode trunk
 ASW1(config-if-range)#desc to DSW2
 ASW1(config-if-range)#channel-group 5 mode on
 Creating a port-channel interface Port-channel5

ASW2

ASW2#vlan database
 ASW2(vlan)#vlan 10
 VLAN 10 added:
 Name: VLAN0010
 ASW2(vlan)#vlan 20
 VLAN 20 added:
 Name: VLAN0020
 ASW2(vlan)#vlan 200
 VLAN 200 added:
 Name: VLAN0200
 ASW2(vlan)#exit
 APPLY completed.
 Exiting....
ASW2(config)#no ip routing
 ASW2(config)#int range fa1/9 - 10
 ASW2(config-if-range)#switchport trunk encap dot1q
 ASW2(config-if-range)#switchport mode trunk
 ASW2(config-if-range)#desc to DSW2
 ASW2(config-if-range)#channel-group 1 mode on
 Creating a port-channel interface Port-channel1
ASW2(config-if-range)#int range fa1/5 - 6
 ASW2(config-if-range)#switchport trunk encap dot1q
 ASW2(config-if-range)#switchport mode trunk
 ASW2(config-if-range)#desc to DSW1
 ASW2(config-if-range)#channel-group 4 mode on
 Creating a port-channel interface Port-channel4

Access-ports

ASW1

ASW1(config)#int range fa1/0 - 4
 ASW1(config-if-range)#switchport mode access
 ASW1(config-if-range)#switchport access vlan 10
 ASW1(config-if-range)#description Vlan10

ASW2

ASW2(config)#int range fa1/0 - 4
 ASW2(config-if-range)#switchport mode access
 ASW2(config-if-range)#switchport access vlan 20
 ASW2(config-if-range)#descrip Vlan20

Management-Vlan

DSW1

DSW1(config)#interface vlan 200
 DSW1(config-if)#ip add 192.168.1.129 255.255.255.248
 DSW1(config-if)#desc Management

DSW2

DSW2(config)#interface vlan 200
 DSW2(config-if)#ip add 192.168.1.130 255.255.255.248
 DSW2(config-if)#desc Management

ASW1

ASW1(config)#int vlan 1
 ASW1(config-if)#shut
 ASW1(config-if)#int vlan 200
 ASW1(config-if)#ip add 192.168.1.131 255.255.255.248
 ASW1(config-if)#desc Management

ASW2

ASW2(config-if-range)#ex
 ASW2(config)#int vlan 1
 ASW2(config-if)#shut
 ASW2(config-if)#inte vlan 200
 ASW2(config-if)#ip add 192.168.1.132 255.255.255.248
 ASW2(config-if)#desc Management

MLS Routing

DSW1

DSW1(config)#interface vlan 10
 DSW1(config-if)#ip add 10.2.1.1 255.255.255.0
 DSW1(config-if)#desc Vlan 10, Users
 DSW1(config-if)#interface vlan 20
 DSW1(config-if)#ip add 10.2.2.2 255.255.255.0
 DSW1(config-if)#desc Vlan 20, Servers
 DSW1(config-if)#exit
 DSW1(config)#router eigrp 10
 DSW1(config-router)#network 10.2.1.0 0.0.0.255
 DSW1(config-router)#network 10.2.2.0 0.0.0.255
 DSW1(config-router)#exit

DLSW2

DSW2(config)#interface vlan 10
 DSW2(config-if)#ip add 10.2.1.2 255.255.255.0
 DSW2(config-if)#desc Vlan 10, Users
 DSW2(config-if)#interface vlan 20
 DSW2(config-if)#ip add 10.2.2.1 255.255.255.0
 DSW2(config-if)#desc Vlan 20, Servers
 DSW2(config-if)#exit
 DSW2(config)#router eigrp 10
 DSW2(config-router)#network 10.2.1.0 0.0.0.255
 DSW2(config-router)#network 10.2.2.0 0.0.0.255
 DSW2(config-router)#end

HSRP

Endast Vlan10 använde HSRP och enligt spec. ska DSW1 vara Active, vi sätter därför prion över 100 som annars är default.

DSW1

DSW1(config)#interface vlan 10
 DSW1(config-if)#standby 1 ip 10.2.1.254
 DSW1(config-if)#standby 1 preempt
 DSW1(config-if)#standby 1 priority 150

DSW2

DSW2(config)#interface vlan 10
 DSW2(config-if)#standby 1 ip 10.2.1.254
 DSW2(config-if)#standby 1 preempt
 DSW2(config-if)#standby 1 priority 100
DSW1#sh standby brief
 P indicates configured to preempt.
 |
 Interface Grp Prio P State Active Standby Virtual IP
 Vl10 1 150 P Active local 10.2.1.2 10.2.1.254

Tyvärr verkade det som jag stött på en bugg här.
Klienter kan pinga DSW1’s riktiga IP-adress 10.2.1.1, men inte den virtuella gatewayen.

HostA#ping 10.2.1.254
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.2.1.254, timeout is 2 seconds:
 .....
 Success rate is 0 percent (0/5)

 HostA#ping 10.2.1.1
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 12/43/68 ms

Slår vi över till DSW2 istället så fungerar det utan problem märkligt nog.

DSW2(config)#int vlan 10
 DSW2(config-if)#standby 1 prio
 DSW2(config-if)#standby 1 priority 160
 DSW2(config-if)#end
 DSW2#
 *Mar 1 03:58:36.031: %HSRP-5-STATECHANGE: Vlan10 Grp 1 state Standby -> Active
 *Mar 1 03:58:36.355: %SYS-5-CONFIG_I: Configured from console by console
HostA#ping 10.2.1.254
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.2.1.254, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 8/16/32 ms
 HostA#ping 10.2.1.1
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 12/24/48 ms
 HostA#ping 10.2.1.2
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 10.2.1.2, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 12/228/1032 ms

Skumt! Verkar inte vara den enda som har samma problem för den delen men har inte lyckats hitta någon vettig lösning på problemet. Har tillsvidare lämnat DSW2 som Active istället, huvudsaken är väl att vi har en “virtuell gateway” till vår host.

Vi har nu åtminstone fullt flöde genom hela nätet!

HostA#ping 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/136/176 ms
HostA#traceroute 10.1.1.1
Type escape sequence to abort.
Tracing the route to 10.1.1.1
1 10.2.1.2 28 msec 56 msec 24 msec
 2 10.1.4.9 64 msec 28 msec 32 msec
 3 10.1.1.9 72 msec 108 msec 68 msec
 4 10.1.1.5 180 msec 120 msec 56 msec
 5 10.1.1.1 152 msec 200 msec 176 msec

Då återstår endast NAT på R1 & DHCP-servern på R4. 🙂 

MDH Lab – Private-VLANs & VACL

Topologi

pvlan

Objectives

  • Secure the server farm using private VLANs.
  • Secure the staff VLAN from the student VLAN.
  • Secure the staff VLAN when temporary staff personnel are used.

Background

In this lab, you will configure the network to protect the VLANs using router ACLs, VLAN ACLs, and private VLANs. First, you will secure the new server farm by using private VLANs so that broadcasts on one server VLAN are not heard by the other server VLAN.

Service providers use private VLANs to separate different customers’ traffic while utilizing the same parent VLAN for all server traffic. The private VLANs provide traffic isolation between devices, even though they might exist on the same VLAN.

You will then secure the staff VLAN from the student VLAN by using a RACL, which prevents traffic from the student VLAN from reaching the staff VLAN. This allows the student traffic to utilize the network and Internet services while keeping the students from accessing any of the staff resources.

Lastly, you will configure a VACL that allows a host on the staff network to be set up to use the VLAN for access but keeps the host isolated from the rest of the staff machines. This machine is used by temporary staff employees.

Genomförande

L2 basic konfig

Då vi ska använda oss av Private-VLANs i den här labben måste vi konfigurera våra switchar till VTP mode Transparent.

S1

Switch(config)#hostname S1
 S1(config)#line con 0
 S1(config-line)#logging sync
 S1(config-line)#!Trunk-links till S2
 S1(config-line)#int range fa0/1 - 2
 S1(config-if-range)#switchport trunk encaps dot1q
 S1(config-if-range)#switchport mode trunk
 S1(config-if-range)#description to S2
 S1(config-if-range)#channel-protocol lacp
 S1(config-if-range)#channel-group 1 mode active
 Creating a port-channel interface Port-channel 1
S1(config-if-range)#
 S1(config-if-range)#!Trunk-links till S3
 S1(config-if-range)#int range fa0/3 - 4
 S1(config-if-range)#switchport trunk encaps dot1q
 S1(config-if-range)#switchport mode trunk
 S1(config-if-range)#description to S2
 S1(config-if-range)#channel-protocol lacp
 S1(config-if-range)#channel-group 2 mode active
 Creating a port-channel interface Port-channel 2
S1(config-if-range)#exit
 S1(config)#vtp mode transparent
 Setting device to VTP TRANSPARENT mode.
S1(config)#vlan 100,150,200
 S1(config-vlan)#exit

S3

Switch(config)#hostname S3
 S3(config)#line con 0
 S3(config-line)#logging sync
 S3(config-line)#!Trunk-links till S2
 S3(config-line)#int range fa0/1 - 2
 S3(config-if-range)#switchport trunk encaps dot1q
 S3(config-if-range)#switchport mode trunk
 S3(config-if-range)#description to S2
 S3(config-if-range)#channel-protocol lacp
 S3(config-if-range)#channel-group 1 mode active
 Creating a port-channel interface Port-channel 1
S3(config-if-range)#
 S3(config-if-range)#!Trunk-links till S1
 S3(config-if-range)#int range fa0/3 - 4
 S3(config-if-range)#switchport trunk encaps dot1q
 S3(config-if-range)#switchport mode trunk
 S3(config-if-range)#description to S1
 S3(config-if-range)#channel-protocol lacp
 S3(config-if-range)#channel-group 2 mode passive
 Creating a port-channel interface Port-channel 2
S3(config-if-range)#exit
 S3(config)#
 S3(config)#vtp mode transparent
 Setting device to VTP Transparent mode for VLANS.
 S3(config)#vlan 100,150,200
 S3(config-vlan)#exit

S2

Switch(config)#hostname S2
 S2(config)#line con 0
 S2(config-line)#logging sync
 S2(config-line)#!Trunk-links till S1
 S2(config-line)#int range fa0/1 - 2
 S2(config-if-range)#switchport mode trunk
 S2(config-if-range)#description to S1
 S2(config-if-range)#channel-protocol lacp
 S2(config-if-range)#channel-group 1 mode passive
 Creating a port-channel interface Port-channel 1
S2(config-if-range)#
 S2(config-if-range)#!Trunk-links till S3
 S2(config-if-range)#int range fa0/3 - 4
 S2(config-if-range)#switchport mode trunk
 S2(config-if-range)#description to S3
 S2(config-if-range)#channel-protocol lacp
 S2(config-if-range)#channel-group 2 mode passive
 Creating a port-channel interface Port-channel 2
S2(config-if-range)#exit
 S2(config)#
S2(config)#vtp mode transparent
Setting device to VTP Transparent mode for VLANS.
S2(config)#vlan 100,150,200
S2(config-vlan)#exit

HSRP

S1

S1(config)#interface vlan 1
 S1(config-if)#ip add 172.16.1.10 255.255.255.0
 S1(config-if)#no shut
 S1(config-if)#standby 1 ip 172.16.1.1
 S1(config-if)#standby 1 preempt
 S1(config-if)#standby 1 priority 100
 S1(config-if)#
 S1(config-if)#interface vlan 100
 S1(config-if)#ip add 172.16.100.10 255.255.255.0
 S1(config-if)#no shut
 S1(config-if)#standby 1 ip 172.16.100.1
 S1(config-if)#standby 1 preempt
 S1(config-if)#standby 1 priority 150
 S1(config-if)#
 S1(config-if)#interface vlan 150
 S1(config-if)#ip add 172.16.150.10 255.255.255.0
 S1(config-if)#no shut
 S1(config-if)#standby 1 ip 172.16.150.1
 S1(config-if)#standby 1 preempt
 S1(config-if)#standby 1 priority 150
 S1(config-if)#
 S1(config-if)#interface vlan 200
 S1(config-if)#ip add 172.16.200.10 255.255.255.0
 S1(config-if)#no shut
 S1(config-if)#standby 1 ip 172.16.200.1
 S1(config-if)#standby 1 preempt
 S1(config-if)#standby 1 priority 100
 S1(config-if)#

S3

S3(config)#interface vlan 1
 S3(config-if)#ip add 172.16.1.30 255.255.255.0
 S3(config-if)#no shut
 S3(config-if)#standby 1 ip 172.16.1.1
 S3(config-if)#standby 1 preempt
 S3(config-if)#standby 1 priority 150
 S3(config-if)#
 S3(config-if)#interface vlan 100
 S3(config-if)#ip add 172.16.100.30 255.255.255.0
 S3(config-if)#standby 1 ip 172.16.100.1
 S3(config-if)#standby 1 preempt
 S3(config-if)#standby 1 priority 100
 S3(config-if)#
 S3(config-if)#interface vlan 150
 S3(config-if)#ip add 172.16.150.30 255.255.255.0
 S3(config-if)#standby 1 ip 172.16.150.1
 S3(config-if)#standby 1 preempt
 S3(config-if)#standby 1 priority 100
 S3(config-if)#
 S3(config-if)#interface vlan 200
 S3(config-if)#ip add 172.16.200.30 255.255.255.0
 S3(config-if)#standby 1 ip 172.16.200.1
 S3(config-if)#standby 1 preempt
 S3(config-if)#standby 1 priority 150
 S3(config-if)#

Verifiering

S1#sh standby brief
 P indicates configured to preempt.
 |
 Interface Grp Pri P State Active Standby Virtual IP
 Vl1 1 100 P Standby 172.16.1.30 local 172.16.1.1
 Vl100 1 150 P Active local 172.16.100.30 172.16.100.1
 Vl150 1 150 P Active local 172.16.150.30 172.16.150.1
 Vl200 1 100 P Standby 172.16.200.30 local 172.16.200.1

Private-VLANs

PVLANs provide layer 2-isolation between ports within the same broadcast domain. There are three types of PVLAN ports:

  • Promiscuous— A promiscuous port can communicate with all interfaces, including the isolated and community ports within a PVLAN.
  • Isolated— An isolated port has complete Layer 2 separation from the other ports within the same PVLAN, but not from the promiscuous ports. PVLANs block all traffic to isolated ports except traffic from promiscuous ports. Traffic from isolated port is forwarded only to promiscuous ports.
  • Community— Community ports communicate among themselves and with their promiscuous ports. These interfaces are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.

Mer info om just PVLANs och design-rekommendationer finns att läsa här!

Vi börjar med att konfigurera upp våra secondary-vlans (Isolated- & Community-PVLAN) i S1 & S3.

S1(config)#vlan 151
S1(config-vlan)#private-vlan isolated
S1(config-vlan)#exit
S1(config)#!Community
S1(config)#vlan 152
S1(config-vlan)#private-vlan community
S1(config-vlan)#exit
S1(config)#

S3(config)#vlan 151
S3(config-vlan)#private-vlan isolated
S3(config-vlan)#exit
S3(config)#!Community
S3(config)#vlan 152
S3(config-vlan)#private-vlan community
S3(config-vlan)#exit

Vi behöver sedan associera våra PVLAN med “parent”-vlanet 150, “primary:n”.

S1(config)#vlan 150
S1(config-vlan)#private-vlan primary
S1(config-vlan)#private-vlan association 151,152
S1(config-vlan)#exit

S3(config)#vlan 150
S3(config-vlan)#private-vlan primary
S3(config-vlan)#private-vlan association 151,152
S3(config-vlan)#exit

Då vi i detta exemplet använder SVI’s för att routa trafik direkt i switchen behöver vi även knyta våra Secondary-vlan till primaryn (150).

S1(config)#interface vlan 150
S1(config-if)#private-vlan mapping 151,152
S1(config-if)#
*Mar 1 01:35:40.794: %PV-6-PV_MSG: Created a private vlan mapping, Primary 150, Secondary 151
*Mar 1 01:35:40.794: %PV-6-PV_MSG: Created a private vlan mapping, Primary 150, Secondary 152

S3(config)#int vlan 150
S3(config-if)#private-vlan mapping 151,152
S3(config-if)#
*Mar 1 01:35:37.170: %PV-6-PV_MSG: Created a private vlan mapping, Primary 150, Secondary 151
*Mar 1 01:35:37.170: %PV-6-PV_MSG: Created a private vlan mapping, Primary 150, Secondary 152

Verifiera med “show vlan private-vlan”:

S1#sh vlan private-vlan
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
150 151 isolated 
150 152 community

Nu återstår det endast att koppla interfacen till respektive secondary-vlan. Enligt uppgiften ska fördelningen se ut enligt följande:

  • Fa0/5-10 – Isolated
  • Fa0/11-15 – Community

S1

S1(config)#int range fa0/5 - 10
S1(config-if-range)#description Isolated-port
S1(config-if-range)#switchport mode private-vlan host
S1(config-if-range)#switchport private-vlan host-association 150 151
S1(config-if-range)#
S1(config-if-range)#int range fa0/11 - 15
S1(config-if-range)#description Community-port
S1(config-if-range)#switchport mode private-vlan host
S1(config-if-range)#switchport private-vlan host-association 150 152

S3

S3(config)#int range fa0/5 - 10
S3(config-if-range)#description Isolated-port
S3(config-if-range)#switchport mode private-vlan host
S3(config-if-range)#switchport private-vlan host-association 150 151
S3(config-if-range)#
S3(config-if-range)#int range fa0/11 - 15
S3(config-if-range)#description Community-port
S3(config-if-range)#switchport mode private-vlan host
S3(config-if-range)#switchport private-vlan host-association 150 152

Verifiering

S3#show vlan private-vlan
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
150 151 isolated Fa0/5, Fa0/6, Fa0/7, Fa0/8, Fa0/9, Fa0/10
150 152 community Fa0/11, Fa0/12, Fa0/13, Fa0/14, Fa0/15

RACL

Vi skulle även skydda Vlan 200 (172.16.200.0/24) från Vlan 100 (172.16.100.0/24), vilket vi gör enkelt med en vanlig ACL.

S1(config)#ip access-list extended RACL
S1(config-ext-nacl)#deny ip 172.16.100.0 0.0.0.255 172.16.200.0 0.0.0.255
S1(config-ext-nacl)#permit ip any any
S1(config-ext-nacl)#exit
S1(config)#interface vlan 200
S1(config-if)#ip access-group RACL in

S3

S3(config)#ip access-list extended RACL
S3(config-ext-nacl)#deny ip 172.16.100.0 0.0.0.255 172.16.200.0 0.0.0.255
S3(config-ext-nacl)#permit ip any any
S3(config-ext-nacl)#exit
S3(config)#interface vlan 200
S3(config-if)#ip access-group RACL in
S3(config-if)#

VACL

Vlan-ACL är ett nytt koncept i CCNP, mer info finns att läsa här! Istället för att knyta det till ett interface används det istället direkt på VLAN:et, själva konfigureringen påminner väldigt mycket om route-maps som vi använt oss mycket av i tidigare inlägg om ex. route-filtering.

Enligt specifikationen skulle vi blockera hosten 172.16.100.150 från att nå någon annan på vlan 100. Vi skapar först en ACL för att ha något att använda i match-statement.

S1(config)#ip access-list extended VACL-BLOCK
S1(config-ext-nacl)#permit ip host 172.16.100.150 172.16.100.0 0.0.0.255
S1(config-ext-nacl)#exit

S3(config)#ip access-list extended VACL-BLOCK
S3(config-ext-nacl)#permit ip host 172.16.100.150 172.16.100.0 0.0.0.255
S3(config-ext-nacl)#exit

Vi bygger sedan vår VLAN Access-map, glöm inte att utan en match all/permit så blockerar vi all trafik precis som en vanlig ACL.

S1(config)#vlan access-map AM-VACL-BLOCK 10
S1(config-access-map)#match ip addr VACL-BLOCK
S1(config-access-map)#action drop
S1(config-access-map)#exit
S1(config)#vlan access-map AM-VACL-BLOCK 20
S1(config-access-map)#action forward
S1(config-access-map)#exit
S1(config)#

S3(config)#vlan access-map AM-VACL-BLOCK 10
S3(config-access-map)#match ip addr VACL-BLOCK
S3(config-access-map)#action drop
S3(config-access-map)#exit
S3(config)#vlan access-map AM-VACL-BLOCK 20
S3(config-access-map)#action forward
S3(config-access-map)#exit
S3(config)#

Sen återstår det bara att knyta detta till vlan:et.

S1(config)#vlan filter AM-VACL-BLOCK vlan-list 100
S3(config)#vlan filter AM-VACL-BLOCK vlan-list 100

Tyvärr har vi inga host att testa med så vi får helt enkelt räkna med att allt är ok! 😉

MDH Lab – Securing STP

Topologi

stp-secure

Objectives

  • Secure the Layer 2 spanning-tree topology with BPDU guard.
  • Protect the primary and secondary root bridge with root guard.
  • Protect switch ports from unidirectional links with UDLD.

Background

This lab is a continuation of Lab 6-1 and uses the network configuration set up in that lab. In this lab, you will secure the network against possible spanning-tree disruptions, such as rogue access point additions and the loss of stability to the root bridge by the addition of switches to the network.

The improper addition of switches to the network can be either malicious or accidental. In either case, the network can be secured against such a disruption.

Genomförande

Då det är precis samma topologi & HSRP-konfiguration som förra labben använder jag samma konfig nu.

BPDU-Guard

BPDU-guard konfigurerade jag redan i förra labben men vi kan väl ta det igen bara för att repetera.

S2(config)#int range fa0/6 - 20 
S2(config-if-range)#switchport mode access
S2(config-if-range)#switchport access vlan 100
S2(config-if-range)#switchport port-security
S2(config-if-range)#switchport port-security max 2
S2(config-if-range)#switchport port-security mac-address sticky
S2(config-if-range)#spanning-tree portfast
S2(config-if-range)#spanning-tree bpduguard enable

Observera att vi endast konfigurerar BPDU-guard på access-portar, och fungerar endast om vi även använder PortFast.

Root-guard

Root-guard skyddar mot switchar som felaktigt skickar ut BPDU-paket med högre Bridge-priority för att försöka ta över rollen som root-bridge. I vår topologi har vi endast tre switchar, med S1 som primary för vl1 & vl200, och S2 som primary för vl100 kan vi enkelt säga att vi aldrig vill att access-switchen ska kunna bli root för något av vlanen. Vi ställer därför in root-guard på portarna ner mot S2 i både S1 & S3.

S1(config)#spanning-tree vlan 1,200 root primary
S1(config)#spanning-tree vlan 100 root secondary
S3(config)#spanning-tree vlan 100 root primary
S3(config)#spanning-tree vlan 1,200 root secondary
S1(config)#int range fa0/1 - 2 , po1
S1(config-if-range)#spanning-tree guard root
S1(config-if-range)#
*Mar 1 03:23:32.781: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port Port-channel1.
S3(config)#int range fa0/1 - 2 , po1
S3(config-if-range)#spanning-tree guard root
S3(config-if-range)#
*Mar 1 03:24:13.205: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port Port-channel1.

UDLD

UDLD använder vi för att upptäcka unidirectional-forwarding främst vid fiberuppkopplingar, men det finns även möjlighet att konfigurera detta på vanliga ethernet-interface också.

UDLD

Så i mina ögon är aggresive-mode helt klart det bästa valet när vi konfigurerar upp UDLD, vilket vi gör enligt följande:

S1(config)#int range fa0/3 - 4 
S1(config-if-range)#udld port aggressive
S3(config)#int range fa0/3 - 4
S3(config-if-range)#udld port aggressive

Observera att vi endast lägger in det på de fysiska interfacen, det är ej möjligt att använda UDLD över en port-channel.

S1#sh udld fa0/3
Interface Fa0/3
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 7
Time out interval: 5
Entry 1
 ---
 Expiration time: 38
 Device ID: 1
 Current neighbor state: Bidirectional
 Device name: FDO1303Y3H8 
 Port ID: Fa0/3 
 Neighbor echo 1 device: FDO1303X3CX
 Neighbor echo 1 port: Fa0/3
Message interval: 15
 Time out interval: 5
 CDP Device name: S3

 Storm-Control

Används för att förhindra att broadcast-trafik sänker våra förbindelser i s.k. broadcast-stormar (orsakat av en loop), mer info finns att läsa här. Själva konfigurationen är rätt enkel, vi lägger in detta på våra trunk-länkar mellan S1-S2-S3.

Do not configure traffic storm control on ports that are members of an EtherChannel. Configuring traffic storm control on ports that are configured as members of an EtherChannel puts the ports into a suspended state.

Vi lägger därför in konfigen direkt på port-channeln istället.

S1(config)#int range po1 - 2
S1(config-if-range)#storm-control broadcast level ?
 <0.00 - 100.00> Enter rising threshold
 bps Enter suppression level in bits per second
 pps Enter suppression level in packets per second
S1(config-if-range)#storm-control broadcast level 60
S2(config)#inte range po1 - 2
S2(config-if-range)#storm-control bbroadcast level 60
S3(config)#int range po1 - 2
S3(config-if-range)#storm-control broadcast level 60

MDH Lab – HSRP & Securing L2

Topologi

6-1

Objectives

  • Secure the Layer 2 network against MAC flood attacks.
  • Prevent DHCP spoofing attacks.
  • Prevent unauthorized access to the network using AAA and 802.1X.

Background

A fellow network engineer that you have known and trusted for many years has invited you to lunch this week.

At lunch, he brings up the subject of network security and how two of his former co-workers had been arrested for using different Layer 2 attack techniques to gather data from other users in the office for their own personal gain in their careers and finances. The story shocks you because you have always known your friend to be very cautious with security on his network.

His story makes you realize that your business network has been cautious with external threats, Layer 3–7 security, firewalls at the borders, and so on, but insufficient at Layer 2 security and protection inside the local network. When you get back to the office, you meet with your boss to discuss your concerns.

After reviewing the company’s security policies, you begin to work on a Layer 2 security policy. First, you establish which network threats you are concerned about and then put together an action plan to mitigate these threats. While researching these threats, you learn about other potential threats to Layer 2 switches that might not be malicious but could threaten network stability.

You decide to include these threats in the policies as well. Other security measures need to be put in place to further secure the network, but you begin with configuring the switches against a few specific types of attacks, including MAC flood attacks, DHCP spoofing attacks, and unauthorized access to the local network. You plan to test the configurations in a lab environment before placing them into production.

Genomförande

Hoppar återigen över grundkonfigen för att få upp Port-channels/Trunking/VLAns, se tidigare inlägg för detta.

Vi börjar med att sätta upp HSRP mellan S1 & S3.

S1

S1(config)#int vlan 1 
S1(config-if)#ip add 172.16.1.10 255.255.255.0
S1(config-if)#standby 1 ip 172.16.1.1
S1(config-if)#standby 1 priority 100
S1(config-if)#standby 1 preempt
S1(config-if)#
S1(config-if)#int vlan 100
S1(config-if)#ip add 172.16.100.10 255.255.255.0
S1(config-if)#standby 1 ip 172.16.100.1
S1(config-if)#standby 1 priority 150
S1(config-if)#standby 1 preempt
S1(config-if)#
S1(config-if)#int vlan 200
S1(config-if)#ip add 172.16.200.10 255.255.255.0
S1(config-if)#standby 1 ip 172.16.200.1
S1(config-if)#standby 1 priority 100
S1(config-if)#standby 1 preempt
S1(config-if)#end

S3

S3(config)#int vlan 1 
S3(config-if)#ip add 172.16.1.30 255.255.255.0
S3(config-if)#standby 1 ip 172.16.1.1
S3(config-if)#standby 1 priority 150
S3(config-if)#standby 1 preempt
S3(config-if)#
S3(config-if)#int vlan 100
S3(config-if)#ip add 172.16.100.30 255.255.255.0
S3(config-if)#standby 1 ip 172.16.100.1
S3(config-if)#standby 1 priority 100
S3(config-if)#standby 1 preempt
S3(config-if)#
S3(config-if)#int vlan 200
S3(config-if)#ip add 172.16.200.30 255.255.255.0
S3(config-if)#standby 1 ip 172.16.200.1
S3(config-if)#standby 1 priority 150
S3(config-if)#standby 1 preempt
S3(config-if)#
S1#sh standby brief
 P indicates configured to preempt.
 |
Interface Grp Pri P State Active Standby Virtual IP
Vl1 1 100 P Standby 172.16.1.30 local 172.16.1.1
Vl100 1 150 P Active local 172.16.100.30 172.16.100.1
Vl200 1 100 P Standby 172.16.200.30 local 172.16.200.1

Nästa uppgift var att säkra vårat nät mot DHCP-spoofing attacker. För att lyckas med detta kan vi använda oss av “dhcp snooping“.

Då endast S2 är access-layer switch med användare inkopplade behöver vi bara konfa snooping där.

S2

S2(config)#!Aktiverar DHCP-snooping funktionen
S2(config)#ip dhcp snooping 
S2(config)#!Startar DHCP-snooping för vlan 100 & 200
S2(config)#ip dhcp snooping vlan 100,200

Alla portar räknas som per default untrusted, dvs får EJ skicka DHCPOFFERs & DHCPACKs. Vi måste därför konfigurera trusted där vi har vår DHCP-server. I detta fall har vi ingen lokalt på lanet, därför sätter vi trunk-portarna till trusted.

S2(config)#inte range fa0/1 - 4 , po1 - 2
S2(config-if-range)#ip dhcp snooping trust

Vi kan verifiera vår konfig med “sh ip dhcp snooping”.

S2#sh ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
100,200
DHCP snooping is operational on following VLANs:
100,200
DHCP snooping is configured on the following L3 Interfaces:
Insertion of option 82 is enabled
 circuit-id format: vlan-mod-port
 remote-id format: MAC
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
Verification of giaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Int
*Mar 1 02:14:22.416: %SYS-5-CONFIG_I: Configured from console by consoleerface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/1 yes unlimited
FastEthernet0/2 yes unlimited
FastEthernet0/3 yes unlimited
FastEthernet0/4 yes unlimited
Port-channel1 yes unlimited
Port-channel2 yes unlimited

MAC-flood attacker blir bara lite repetition från CCNA, genom att begränsa antal mac-adresser en port kan lära sig behöver vi inte vara rädda för att råka ut för cam-table overflow. Även här behöver vi endast konfa S2 då det är den enda switchen i access-layer.

S2(config)#int range fa0/6 - 20 
S2(config-if-range)#switchport mode access
S2(config-if-range)#switchport access vlan 100
S2(config-if-range)#switchport port-security
S2(config-if-range)#switchport port-security max 2
S2(config-if-range)#switchport port-security mac-address sticky
S2(config-if-range)#spanning-tree portfast
S2(config-if-range)#spanning-tree bpduguard enable

Detta gör att switchen endast kan lära sig max 2st mac-adresser per interface (2×15 =  30 mac-adresser).

För att begränsa access till nätet är ett alternativ att använda oss av 802.1x, vilket kräver att användarna autentiserar sig innan porten slår över till forwarding. Mer info om dot1x finns att läsa här.

S2(config)#aaa new-model
S2(config)#!Autentiserar anvandare mot anvandardatabasen som ligger lokalt pa switchen
S2(config)#aaa authentication dot1x default local
S2(config)#!aktiverar dot1x
S2(config)#dot1x system-auth-control
S2(config)#!skapar anvndare
S2(config)#username admin1 password cisco
S2(config)#username user1 password cisco
S2(config)#username user2 password cisco
S2(config)#inte range fa0/6 - 20
S2(config-if-range)#!aktiverar dot1x-autentisering pa interfacen
S2(config-if-range)#dot1x port-control auto
S2(config-if-range)#
*Mar 1 02:28:23.114: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/11, changed state to down
*Mar 1 02:28:23.131: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/18, changed state to down

Observera att både Fa0/11 & Fa0/18 genast gick ner efter vi la in konfigen, detta pga användarna ej är autentiserade ännu.

S2#sh dot1x interface fa0/11
Dot1x Info for FastEthernet0/11
-----------------------------------
PAE = AUTHENTICATOR
PortControl = AUTO
ControlDirection = Both 
HostMode = SINGLE_HOST
Violation Mode = PROTECT
ReAuthentication = Disabled
QuietPeriod = 60
ServerTimeout = 30
SuppTimeout = 30
ReAuthPeriod = 3600 (Locally configured)
ReAuthMax = 2
MaxReq = 2
TxPeriod = 30
RateLimitPeriod = 0

Rekommenderat är dock att koppla autentiseringen mot en extern RADIUS-server istället.

MDH Lab – IP SLA ICMP & Jitter

Topologi

lab-ipsla

Objectives

  • Configure trunking, VTP, and SVIs.
  • Implement IP SLAs to monitor various network performance characteristics.

Background

Cisco IOS IP service level agreements (SLAs) allow users to monitor network performance between Cisco devices (switches or routers) or from a Cisco device to a remote IP device.

Cisco IOS IP SLAs can be applied to VoIP and video applications as well as monitoring end-to-end IP network performance.In this lab, you configure trunking, VTP, and SVIs. You configure IP SLA monitors to test ICMP echo network  and jitter performance between S1 and each switch.

Genomförande

Hoppar över grundkonfigen för Etherchannels/Vlan/VTP/Trunkar så all L2-konfig är redan klart. Se tidigare inlägg om detta skulle vara intressant..

Vi börjar med att konfa upp L3 för samtliga switchar.

S1

S1(config)#int vlan 1
 S1(config-if)#ip add 172.16.1.1 255.255.255.0
 S1(config-if)#no shut
 S1(config-if)#int vlan 100
 S1(config-if)#ip add 172.16.100.1 255.255.255.0
 S1(config-if)#int vlan 200
 S1(config-if)#ip add 172.16.200.1 255.255.255.0
 S1(config-if)#exit
 S1(config)#ip routing

S2

S2(config)#inte vlan 1
 S2(config-if)#ip add 172.16.1.102 255.255.255.0
 S2(config-if)#no shut

S3

S3(config)#inte vlan 1
 S3(config-if)#ip add 172.16.1.103 255.255.255.0
 S3(config-if)#no shut

Då återstår det endast att sätta upp IP SLA. Enligt labben ska vi konfigurera upp ICMP-Echo & Jitter på S1 mot både S2 & S3.

För att kunna testa just jitter behöver vi konfigurera IP SLA-responders på S2 & S3, detta behövs dock inte om vi endast vill använda ICMP.

S2 & S3

S2(config)#ip sla responder
 S2(config)#ip sla responder udp-echo ipaddress 172.16.1.1 port 2525
S3(config)#ip sla responder
 S3(config)#ip sla responder udp-echo ipaddress 172.16.1.1 port 2525

Vi konfar sedan upp SLA-mätningen på S1. Vi behöver en SLA-instans per mätnings-funktion, då vi vill testa både ICMP & Jitter behövs därför två mot S2 och två mot S3.

S1

S1(config)#ip sla 20
 S1(config-ip-sla-echo)#icmp-echo 172.16.1.102
 S1(config-ip-sla-echo)#frequency 5
 S1(config-ip-sla-echo)#timeout 1000
 S1(config-ip-sla-echo)#exit
 S1(config)#
S1(config)#ip sla 25
 S1(config-ip-sla)#udp-jitter 172.16.1.102 2525
 S1(config-ip-sla-jitter)#frequency 20
 S1(config-ip-sla-jitter)#precision milliseconds
 S1(config-ip-sla-jitter)#timeout 1000
 S1(config-ip-sla-jitter)#exit
 S1(config)#
S1(config)#ip sla 30
 S1(config-ip-sla)#icmp-echo 172.16.1.103
 S1(config-ip-sla-echo)#frequency 5
 S1(config-ip-sla-echo)#timeout 1000
 S1(config-ip-sla-echo)#exit
 S1(config)#
S1(config)#ip sla 35
 S1(config-ip-sla)#udp-jitter 172.16.1.103 2525
 S1(config-ip-sla-jitter)#frequency 20
 S1(config-ip-sla-jitter)#precision milliseconds
 S1(config-ip-sla-jitter)#timeout 1000
 S1(config-ip-sla-jitter)#exit
 S1(config)#end

Vi behöver sedan bara schemalägga och starta våra IP SLA-mätningar.

S1(config)#ip sla schedule 20 life forever start-time now
S1(config)#ip sla schedule 25 life forever start-time now
S1(config)#ip sla schedule 30 life forever start-time now
S1(config)#ip sla schedule 35 life forever start-time now

Vi kan verifiera vår IP-SLA konfig med “sh ip sla configuration”.

S1#sh ip sla configuration 25
IP SLAs, Infrastructure Engine-II.
Entry number: 25
Owner: 
Tag: 
Type of operation to perform: udp-jitter
Target address/Source address: 172.16.1.102/0.0.0.0
Target port/Source port: 2525/0
Type Of Service parameter: 0x0
Request size (ARR data portion): 32
Operation timeout (milliseconds): 1000
Packet Interval (milliseconds)/Number of packets: 20/10
Verify data: No
Vrf Name: 
Control Packets: enabled
Schedule:
 Operation frequency (seconds): 20
 Next Scheduled Start Time: Start Time already passed
 Group Scheduled : FALSE
 Randomly Scheduled : FALSE
 Life (seconds): Forever
 Entry Ageout (seconds): never
 Recurring (Starting Everyday): FALSE
 Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
 Number of statistic hours kept: 2
 Number of statistic distribution buckets kept: 1
 Statistic distribution interval (milliseconds): 20
Enhanced History:

Det går även att verifiera på S2 & S3 så att de verkligen tar emot förfrågningar från S1.

S2#sh ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 8 Number of errors: 0 
Recent sources:
 172.16.1.1 [01:13:22.643 UTC Mon Mar 1 1993]
 172.16.1.1 [01:13:02.644 UTC Mon Mar 1 1993]
 172.16.1.1 [01:12:42.638 UTC Mon Mar 1 1993]
 172.16.1.1 [01:12:22.639 UTC Mon Mar 1 1993]
 172.16.1.1 [01:12:02.641 UTC Mon Mar 1 1993]
Recent error sources:
udpEcho Responder: 
 IP Address Port
 172.16.1.1 2525

För att se resultatet av våra mätningar, använd “show ip sla statistics”.

S1#sh ip sla statistics
Round Trip Time (RTT) for Index 20
 Latest RTT: 8 ms
Latest operation start time: *01:14:11.767 UTC Mon Mar 1 1993
Latest operation return code: OK
Number of successes: 40
Number of failures: 1
Operation time to live: Forever

Round Trip Time (RTT) for Index 25
 Latest RTT: 2 ms
Latest operation start time: *01:13:55.904 UTC Mon Mar 1 1993
Latest operation return code: OK
RTT Values
 Number Of RTT: 10
 RTT Min/Avg/Max: 2/2/4 ms
Latency one-way time milliseconds
 Number of Latency one-way Samples: 0
 Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
 Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
Jitter time milliseconds
 Number of SD Jitter Samples: 9
 Number of DS Jitter Samples: 9
 Source to Destination Jitter Min/Avg/Max: 0/1/2 ms
 Destination to Source Jitter Min/Avg/Max: 0/1/1 ms
Packet Loss Values
 Loss Source to Destination: 0 Loss Destination to Source: 0
 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values
 Calculated Planning Impairment Factor (ICPIF): 0
 Mean Opinion Score (MOS): 0
Number of successes: 11
Number of failures: 0
Operation time to live: Forever

Round Trip Time (RTT) for Index 30
 Latest RTT: 1 ms
Latest operation start time: *01:14:15.038 UTC Mon Mar 1 1993
Latest operation return code: OK
Number of successes: 40
Number of failures: 0
Operation time to live: Forever

Round Trip Time (RTT) for Index 35
 Latest RTT: 2 ms
Latest operation start time: *01:14:04.217 UTC Mon Mar 1 1993
Latest operation return code: OK
RTT Values
 Number Of RTT: 10
 RTT Min/Avg/Max: 1/2/3 ms
Latency one-way time milliseconds
 Number of Latency one-way Samples: 0
 Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
 Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
Jitter time milliseconds
 Number of SD Jitter Samples: 9
 Number of DS Jitter Samples: 9
 Source to Destination Jitter Min/Avg/Max: 0/1/1 ms
 Destination to Source Jitter Min/Avg/Max: 0/1/2 ms
Packet Loss Values
 Loss Source to Destination: 0 Loss Destination to Source: 0
 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values
 Calculated Planning Impairment Factor (ICPIF): 0
 Mean Opinion Score (MOS): 0
Number of successes: 10
Number of failures: 0
Operation time to live: Forever

IP SLA går dock att använda till så mycket mer än att bara köra lite jitter/udp-test sen, exempelvis PBR/HSRP-tracking etc, vilket jag kommer ta upp i senare inlägg. 🙂