Busy summer & recertified CCNP

Been a few months since my last post as I’ve had a crazy busy summer/autumn and it will probably take a while longer until I get going again. Cisco has introduced their new revamped certifications track which looks hard but very interesting, I’ll probably give the DevOps-track a go next year. But for now I’ve recently renewed my CCNP R&S for another 3 years at least.

So what have I been up to the last few months?

I became a dad!

We bought a house!

And everything else feels pretty minor in comparison.. I’ve still been doing some coding though as I’ve attempted to build a smart home (project ongoing..) via Home Assistant and IoT.

Lots of hair pulling to get everything working but it’s slowly coming together now with more and more automation’s running to make everyday life a little simpler. I have a project open over at GitHub that’s updated now and then when I find some time to spare (happens very rarely now for some reason..). 🙂

SNMPv3

SNMPv3 introducerades redan 1999 men blev accepterad som en full “internet standard” av IETF 2004 med RFC 3411-3418 och innehåller en rad säkerhetsförbättringar mot de mer vanligt använda SNMPv1 & SNMPv2c. Konfigurationen är betydligt mer komplicerad men har fördelen att autentisering nu kan göras på användarnivå istället för endast via community-sträng samt kryptering av snmp-paketen.

I SNMPv1/v2c krävs endast korrekt community-sträng för att få åtkomst till RO/RW-rättigheter, vilket skickas helt i klartext. Så en “hacker” behöver endast avlyssna management-trafiken och vänta tills någon skickar en giltig request, inte helt säkert med andra ord.

CBT har en väldigt bra micronugget som går igenom grunderna i SNMPv3 samt hur vi konfigurerar det i en router/switch:

Tänkte även testa konfigurera upp snmp på en ubuntu-server för lite pollning etc!

Installera SNMP-agenten (daemon), manager & mibs via:

sudo apt-get install snmpd snmp snmp-mibs-downloader

Kommentera sedan bort raden ”mibs :” i filen /etc/snmp/snmp.conf och lägg till följande info i /etc/snmp/snmpd.conf:

rocommunity public
rwcommunity private

Starta sedan om snmp-daemon med “service snmpd restart”.

Vi bör nu kunna göra SNMPv2 pollningar utan problem. Vi börjar med att ange om vi vill hämta (snmpget) eller ändra (snmpset) information, version av snmp, community-sträng, ip-adress och tillsist vilken OID vi vill kontrollera –  i detta fall uptime.

netadm01@netadm01:~$ snmpget -v2c -c public 127.0.0.1 system.sysUpTime.0
Vilket ger föjande svar:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1072) 0:00:10.72

Sweet! Om vi vill kontrollera samtliga OIDs under ett visst träd kan vi använda oss av snmpwalk istället, och utan att specificera något sub-träd så finns det bevisligen en hel del OIDs att polla. 🙂

netadm01@netadm01:~$ snmpwalk -v 2c -c public 127.0.0.1 . | wc –l
4217

Vill vi ändra en parameter använder vi som sagt snmpset istället, som exempelvis:

Plats:
netadm01@netadm01:~$ snmpset -v2c -c private-netadm01 127.0.0.1 sysLocation.0 s "Vasteras, Sweden"
Kontakt:
netadm01@netadm01:~$ snmpset -v2c -c private-netadm01 127.0.0.1 sysContact.0 s "Jonas, www.roadtoccie.se"
Verifiering:
netadm01@netadm01:~$ snmpget -v2c -c public 127.0.0.1 sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: Vasteras, Sweden
netadm01@netadm01:~$ snmpget -v2c -c public 127.0.0.1 sysContact.0
SNMPv2-MIB::sysContact.0 = STRING: Jonas, www.roadtoccie.se

SNMPv3

För att konfigurera upp använder och grupper till v3 krävs lite ytterligare steg.

Vi skapar användare via antingen “net-snmp-config –create-snmpv3-user” eller genom att manuellt lägga till följande i /var/lib/snmpd.conf:

createUser admin MD5 adminpassword DES adminpasswordx
createUser guest MD5 guestpassword DES guestpasswordx

Vi sätter sedan vilka rättigheter respektive användare har i /usr/share/snmp/snmpd.conf:

rouser admin auth .1.3.6.1.2.1
rwuser admin priv .1.3.6.1.2.1
rouser guest priv .1.3.6.1.2.1

Admin-användaren får endast R/O-rättigheter om den använder sig av auth, men R/W om vi även använder kryptering vid autentisering, guest får endast R/O-rättigheter.

snmpset & snmpget för v3 är lite omständigare att skriva:

snmpset -v 3 -u admin -l authPriv -a MD5 -A adminpassword -x DES -X adminpasswordx localhost .1.3.6.1.2.1.1.6.0 s "MDH, basement"
snmpget -v 3 -u admin -l authPriv -a MD5 -A adminpassword -x DES -X adminpasswordx localhost sysLocation.0

För att göra det enklare kan vi fördefiniera en default-användare med tillhörande lösenord genom att modifiera “~/.snmp/snmp.conf” och lägga till följande:

defSecurityName admin
defAuthType MD5
defSecurityLevel authPriv
defAuthPassphrase adminpassword
defPrivType DES
defPrivPassphrase adminpasswordx
defVersion 3

Vi behöver därefter endast skriva “snmpget localhost sysLocation.0”.

Vackert! Nästa inlägg blir troligtvis om enklare script i python när jag väl lyckats sätta mig in i det lite bättre.

CCNP Security-track uppdaterat!

CCNP_Security_zcc

Cisco annonserade nyligen att de kommer lägga ner specialist-certifieringarna inom CCNP Security fr.o.m. 21 April inom ASA/VPN/Firewall & VPN och ersätta dessa med mer generella cert inom:

  • Implementing Cisco Edge Network Security Solutions (SENSS)
  • Implementing Cisco Threat Control Solutions (SITCS)
  • Implementing Cisco Secure Access Solutions (SISAS)
  • Implementing Cisco Secure Mobility Solutions (SIMOS)

Lite tråkigt för jag var rätt sugen på att åtminstone ta ASA & VPN-certen i framtiden, men förhoppningsvis är väl SENSS & SIMOS bara en förbättrad variant av dessa. Mer info finns att läsa här.

Labbar på SNMPv3 just nu och kommer även börja kolla lite på python för enklare script osv nästa vecka så ska försöka få upp några inlägg om det i dagarna.

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

BGP – Advanced BGP Lab, del 3

Fortsättning från tidigare inlägg om GNS3Vaults Advanced BGP-lab som finns att läsa här & här.

Path Modifications

bgp-advanced-lab

  • When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.
  • Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP.
  • When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.
  • When R6 sends a ping towards the loopback interface on R11 it should go through AS300.
  • R7 should prefer the path through R11 for all external networks except for 172.16.1.1.
  • Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Vi har just nu full konvergens och kan pinga samtliga loopbacks i vår topologi.

1. When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.

Tar vi en titt på R4 först kan vi se följande:

R4#sh ip bgp
BGP table version is 34, local router ID is 4.4.4.4
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
* 1.1.1.0/24 2.2.2.2 0 100 i
*> 3.3.3.3 0 100 i

Den föredrar just nu vägen via R3 för att nå R1s loopback 1.1.1.1. Då vi endast fick ändra konfigurationen på R3 för att styra om trafiken behöver vi använda oss av något Path Attribute. Varken Weight eller Local Preference kan ju hjälpa oss i detta fall då R4 ligger i ett eget AS. MED eller AS-Path Prepending däremot!

R3(config)#ip prefix-list R1-Loopback permit 1.1.1.0/24
R3(config)#route-map R1-Loopback-MED permit 10
R3(config-route-map)#match ip add prefix-list R1-Loopback
R3(config-route-map)#set as-path prepend 100 100
R3(config-route-map)#route-map R1-Loopback-MED permit 20
R3(config-route-map)#exit
R3(config)#router bgp 100
R3(config-router)#neighbor 4.4.4.4 route-map R1-Loopback-MED out

R4#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 35
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to update-groups:
 1 2
 100 100 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, valid, external
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external, best

2Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP. When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.

R1(config)#int lo1
R1(config-if)#ip add 172.16.1.1 255.255.255.0
R1(config)#router rip
R1(config-router)#network 172.16.1.0

R4#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 38
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 1 2
 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, valid, external
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external, best

I detta fall behöver vi endast ändra BGP lokalt, och bör således använda oss av “Weight”.

R4(config)#ip prefix-list R1-Loopback2 permit 172.16.1.0/24
R4(config)#route-map R1-Loopback2-Weight permit 10
R4(config-route-map)#match ip add prefix-list R1-Loopback2
R4(config-route-map)#set weight 10
R4(config-route-map)#route-map R1-Loopback2-Weight permit 20
R4(config-route-map)#exit
R4(config)#router bgp 10
R4(config-router)#neighbor 3.3.3.3 route-map R1-Loopback2-Weight in

R4#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 39
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
 Advertised to update-groups:
 1 2
 100
 3.3.3.3 from 3.3.3.3 (3.3.3.3)
 Origin IGP, localpref 100, weight 10, valid, external, best
 100
 2.2.2.2 from 2.2.2.2 (2.2.2.2)
 Origin IGP, localpref 100, valid, external

3. When R6 sends a ping towards the loopback interface on R11 it should go through AS300.

Just nu tar R6 vägen via R7->R11.

R6#traceroute 11.11.11.11
Type escape sequence to abort.
Tracing the route to 11.11.11.11
1 192.168.67.7 24 msec 28 msec 68 msec
 2 192.168.117.11 56 msec 72 msec *

Känns som vi kan använda oss av Weight här med då local preference även hade annonserats till R7.

R6(config)#ip prefix-list R11-Loopback permit 11.11.11.0/24
R6(config)#route-map R11-Loopback-Weight permit 10
R6(config-route-map)#match ip add prefix-list R11-Loopback
R6(config-route-map)#set weight 10
R6(config-route-map)#route-map R11-Loopback-Weight permit 20
R6(config-route-map)#exit
R6(config-router)#neighbor 5.5.5.5 route-map R11-Loopback-Weight in

R6#sh ip bgp 11.11.11.0/24
BGP routing table entry for 11.11.11.0/24, version 1007
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 1 2
 300 400
 5.5.5.5 from 5.5.5.5 (5.5.5.5)
 Origin IGP, localpref 100, weight 10, valid, external, best
 400
 7.7.7.7 (metric 156160) from 7.7.7.7 (7.7.7.7)
 Origin IGP, metric 0, localpref 100, valid, internal
 300 400
 4.4.4.4 from 4.4.4.4 (4.4.4.4)
 Origin IGP, localpref 100, valid, external

4. R7 should prefer the path through R11 for all external networks except for 172.16.1.1.

Vi kan använda oss av Weight här med men själva tillvägagångssättet blir lite annorlunda nu när vi vill matcha allt utom just 172.16.1.0/24-nätet.

R7(config)#ip prefix-list R1-Loopback-R11 permit 172.16.1.0/24
R7(config)#route-map RM-Redirect-to-R11 permit 10
R7(config-route-map)#match ip address prefix-list R1-Loopback-R11
R7(config-route-map)#route-map RM-Redirect-to-R11 permit 20
R7(config-route-map)#set weight 20
R7(config-route-map)#exit
R7(config)#router bgp 200
R7(config-router)#neighbor 11.11.11.11 route-map RM-Redirect-to-R11 in

Vi sätter helt enkelt weight för alla nät som inte matchas i vår första sequence, dvs allt utom 172.16.1.0/24.

Jämför vi 172.16.1.0/24 med 1.1.1.0/24 kan vi se följande:

R7#sh ip bgp 172.16.1.0
BGP routing table entry for 172.16.1.0/24, version 12
Paths: (2 available, best #2, table Default-IP-Routing-Table)
 Advertised to update-groups:
 1
 400 300 100
 11.11.11.11 from 11.11.11.11 (11.11.11.11)
 Origin IGP, localpref 100, valid, external
 300 100
 6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
 Origin IGP, metric 0, localpref 100, valid, internal, best

R7#sh ip bgp 1.1.1.0/24
BGP routing table entry for 1.1.1.0/24, version 43
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 2
 400 300 100
 11.11.11.11 from 11.11.11.11 (11.11.11.11)
 Origin IGP, localpref 100, weight 20, valid, external, best
 300 100
 6.6.6.6 (metric 156160) from 6.6.6.6 (6.6.6.6)
 Origin IGP, metric 0, localpref 100, valid, internal

5. Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Här behöver vi istället filtrera bort routing-uppdateringar för 172.16.1.0/24 i R4 & R5 mot R6. Då vi redan har en prefix-lista konfad på R4 som matchar 172.16.1.0/24-nätet återanvänder vi den istället.

R4(config)#do sh ip prefix-list
ip prefix-list R1-Loopback2: 1 entries
 seq 5 permit 172.16.1.0/24
R4(config)#route-map AS200 deny 10
R4(config-route-map)#match ip add prefix-list R1-Loopback2
R4(config-route-map)#route-map AS200 permit 20
R4(config-route-map)#exit
R4(config)#router bgp 10
R4(config-router)#neighbor 6.6.6.6 route-map AS200 out

Jag blir dock osäker på hur vi ska blockera AS200 från att lära sig om nätet via As400 istället (utan att lägga in specifik filtrering där också)?

R6#sh ip bgp 172.16.1.0/24
BGP routing table entry for 172.16.1.0/24, version 1015
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
 Advertised to update-groups:
 2
 400 300 100
 7.7.7.7 (metric 156160) from 7.7.7.7 (7.7.7.7)
 Origin IGP, metric 0, localpref 100, valid, internal, best

Som synes tar den nu istället vägen via R7 -> AS400 R11  -> R10-> AS300 R9..  Jag skulle vilja säga att vi ej har någon möjlighet att påverka vad ett annat AS  i sin tur gör med näten vi annonserar till  dem. För att lösa labben hade jag lagt in samma filter på R11 mot R7 också.

Då var vi tillslut klara med den avancerade labben, gick trots allt väldigt smärtfritt skönt nog. 🙂 MDH har släppt slutprojektet i CCNP-kursen nu så eventuella inlägg närmaste tiden kommer troligtvis handla om det.

BGP – Advanced BGP Lab, del 2

EBGP & Redistribution

  • Configure EBGP between AS-peers
  • Configure BGP authentication between R7 and R11, use password VAULT
  • Make sure all BGP neighbor relationships are working before you continue with the next steps.
  • Advertise all physical and loopback interfaces in BGP, you are not allowed to use the “network” command to achieve this.
  • Achieve full connectivity, every IP address should be pingable. Use a TCLSH script to do this.

Detta blir en fortsättning på gårdagens lab som finns att läsa här. Kom ihåg att varje BGP Speaker kräver en specifik route till respektive neighbor, en default-route räcker ej. Då vi endast annonserar Loopbacks inom IGPs/AS (förutom sub-AS10 & 20/confederation) behöver vi även sätta upp statiska routes. Glöm inte heller ebgp-multihop den här gången… 🙂

EBGP

R2

router bgp 100
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.24.4

R3

router bgp 100
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 255
 neighbor 4.4.4.4 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.34.4

R4

router bgp 10
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 ebgp-multihop 255
 neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 ebgp-multihop 255
 neighbor 3.3.3.3 update-source Loopback0
neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 ebgp-multihop 2
 neighbor 6.6.6.6 update-source Loopback0
ip route 2.2.2.0 255.255.255.0 192.168.24.2
ip route 3.3.3.0 255.255.255.0 192.168.34.3
ip route 6.6.6.0 255.255.255.0 192.168.46.6

R5

router bgp 10
 neighbor 6.6.6.6 remote-as 200
 neighbor 6.6.6.6 ebgp-multihop 2
 neighbor 6.6.6.6 update-source Loopback0
ip route 6.6.6.0 255.255.255.0 192.168.56.6

EBGP-förhållandet mellan confederation-AS #10 & #20 konfigurerade vi upp i gårdagens inlägg här.

R6

router bgp 200
 neighbor 4.4.4.4 remote-as 300
 neighbor 4.4.4.4 ebgp-multihop 2
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 5.5.5.5 remote-as 300
 neighbor 5.5.5.5 ebgp-multihop 2
 neighbor 5.5.5.5 update-source Loopback0
ip route 4.4.4.0 255.255.255.0 192.168.46.4
 ip route 5.5.5.0 255.255.255.0 192.168.56.5

R7

router bgp 200
 neighbor 11.11.11.11 remote-as 400
 neighbor 11.11.11.11 ebgp-multihop 2
 neighbor 11.11.11.11 update-source Loopback0
ip route 11.11.11.0 255.255.255.0 192.168.117.11

R9

router bgp 20
 neighbor 10.10.10.10 remote-as 400
 neighbor 10.10.10.10 ebgp-multihop 2
 neighbor 10.10.10.10 update-source Loopback0
ip route 10.10.10.0 255.255.255.0 192.168.109.10

R10

router bgp 400
 neighbor 9.9.9.9 remote-as 300
 neighbor 9.9.9.9 ebgp-multihop 2
 neighbor 9.9.9.9 update-source Loopback0
ip route 9.9.9.0 255.255.255.0 192.168.109.9

R11

router bgp 400
 neighbor 7.7.7.7 remote-as 200
 neighbor 7.7.7.7 ebgp-multihop 2
 neighbor 7.7.7.7 update-source Loopback0
ip route 7.7.7.0 255.255.255.0 192.168.117.7

Authentication

Enligt labben behöver vi sätta upp autentisering mellan R7 – R11 med lösenordet “VAULT”.

R7 
 router bgp 200
 neighbor 11.11.11.11 password VAULT

R11
 router bgp 400
 neighbor 7.7.7.7 password VAULT

Redistribution

Nästa steg är att annonsera alla fysiska interface (inkl. loopbacks) in i BGP, vi får ej använda “network”. Enklast bör väl vara att köra redistribute på connected, route-map:en är bara för att göra det lite snyggare och sätta origin till IGP istället för “unknown”.

route-map REDIST_C permit 10
 set origin igp

router bgp x
 redistribute connected route-map REDIST_C

La in ovanstående på samtliga routrar i topologin. Vilket gav följande i R1:

R1#sh ip bgp
 BGP table version is 10, local router ID is 1.1.1.1
 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
 *> 1.1.1.0/24 0.0.0.0 0 32768 i
 r>i2.2.2.0/24 2.2.2.2 0 100 0 i
 r>i3.3.3.0/24 3.3.3.3 0 100 0 i
 * i4.4.4.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i5.5.5.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i6.6.6.0/24 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i7.7.7.0/24 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i8.8.8.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i9.9.9.0/24 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.12.0 2.2.2.2 0 100 0 i
 *> 0.0.0.0 0 32768 i
 * i192.168.13.0 3.3.3.3 0 100 0 i
 *> 0.0.0.0 0 32768 i
 *>i192.168.24.0 2.2.2.2 0 100 0 i
 *>i192.168.34.0 3.3.3.3 0 100 0 i
 * i192.168.45.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.46.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.56.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.58.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.67.0 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i
 * i192.168.89.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.109.0 4.4.4.4 0 100 0 300 i
 * i 4.4.4.4 0 100 0 300 i
 * i192.168.117.0 4.4.4.4 0 100 0 300 200 i
 * i 4.4.4.4 0 100 0 300 200 i

Som synes är det endast näten inom AS100 den lägger till i routing-tabellen.. Anledningen till detta är rätt enkel, R1 har ingen route till 4.4.4.4 (next-hop). Enklaste lösningen är väl att konfigurera next-hop-self på våra border-routers istället.

R2

router bgp 100
 neighbor 1.1.1.1 next-hop-self

R3

router bgp 100
 neighbor 1.1.1.1 next-hop-self

Och så vidare, behöver göra detta på varje border-router vars neighbor saknar egna routes för loopbacks i andra AS.

TCL Verifiering

tclsh
foreach address {
1.1.1.1
2.2.2.2
3.3.3.3
4.4.4.4
5.5.5.5
6.6.6.6
7.7.7.7
8.8.8.8
9.9.9.9
10.10.10.10
11.11.11.11
} { ping $address repeat 1 }

R1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 128/128/128 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 120/120/120 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 140/140/140 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 192/192/192 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 144/144/144 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 252/252/252 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 324/324/324 ms

R5

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 212/212/212 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 104/104/104 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 132/132/132 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 60/60/60 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 44/44/44 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 32/32/32 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 100/100/100 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 184/184/184 ms

R11

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 308/308/308 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 216/216/216 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 280/280/280 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 148/148/148 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 68/68/68 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 36/36/36 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 152/152/152 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 9.9.9.9, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 80/80/80 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.10.10.10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 56/56/56 ms
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 11.11.11.11, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 1/1/1 ms

Vackert! Nu är det bara den roliga biten kvar med “path modifications” men det får allt vänta till nästa vecka då det är party ikväll. 🙂

BGP – Advanced BGP Lab, del 1

Var ett tag sedan jag konfigurerade något nu så fick lite abstinens… 😉 Tänkte göra ett försök på Renée’s “Advanced BGP-Lab” ikväll från www.gns3vault.com.

Topologin ser ut enligt följande:

bgp-advanced-lab

R1 – R2: 192.168.12.X / R1 – R3: 192.168.13.X / R3 – R4: 192.168.34.X (where X = Router number) etc..

Every router has a Loopback0 interface: X.X.X.X (where X = Router number)

  • Configure each Autonomous System (AS) with a different IGP:
    AS100: RIP
    AS300: OSPF
    AS200: EIGRP
    AS400: OSPF
  • Do not configure the IGP on the interfaces connecting to another AS. For example; R3 should not send any RIP routing updates towards R4.
  • Make sure the loopbacks are advertised in the IGP’s.
  • Configure BGP on every router, make sure you have the right IBGP and EBGP configurations. AS300 has to be configured as a confederation.
  • R1 has to be configured as a route-reflector for R2 and R3.
  • Configure on all routers that BGP updates are sourced from the Loopback0 interface.
  • Configure BGP authentication between R7 and R11, use password VAULT
  • Make sure all BGP neighbor relationships are working before you continue with the next steps.
  • Advertise all physical and loopback interfaces in BGP, you are not allowed to use the “network” command to achieve this.
  • Achieve full connectivity, every IP address should be pingable. Use a TCLSH script to do this.
  • When R4 sends a ping to the loopback interface of R1 it should choose the path through R2. You are only allowed to make changes on R3.
  • Create another loopback interface on R1 with ip address 172.16.1.1 /24, advertise this in RIP.
  • When R4 sends a ping to the 172.16.1.1 address it should take the path through R3, you are only allowed to make changes on R4.
  • When R6 sends a ping towards the loopback interface on R11 it should go through AS300.
  • R7 should prefer the path through R11 for all external networks except for 172.16.1.1.
  • Configure AS300 so it is no longer a transit AS for AS200 to reach 172.16.1.1 in AS100. AS400 should not be influenced.

Får se hur långt vi hinner idag, kommer troligtvis att bli (minst) två inlägg istället. Men låt oss börja med basics, sätta upp IGPs inom respektive AS.

IGP Routing

  • Configure each Autonomous System (AS) with a different IGP:
    AS100: RIP
    AS300: OSPF
    AS200: EIGRP
    AS400: OSPF
  • Do not configure the IGP on the interfaces connecting to another AS. For example; R3 should not send any RIP routing updates towards R4.
  • Make sure the loopbacks are advertised in the IGP’s.

Finns inte direkt något speciellt att tänka på här. Använd passive-interface default enligt best practice och kom ihåg att annonsera Loopback för respektive router.

RIP / AS100

R1
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 1.0.0.0
 network 192.168.12.0
 network 192.168.13.0
 no auto-summary

R2
 router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 2.0.0.0
 network 192.168.12.0
 no auto-summary

R3
 router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 3.0.0.0
 network 192.168.13.0
 no auto-summary

OSPF / AS300

R4
 router ospf 300
 router-id 4.4.4.4
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet2/0
 network 4.4.4.0 0.0.0.255 area 0
 network 192.168.45.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

 R5
router ospf 300
 router-id 5.5.5.5
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 5.5.5.0 0.0.0.255 area 0
 network 192.168.45.0 0.0.0.255 area 0
 network 192.168.58.0 0.0.0.255 area 0

 interface Loopback0
 ip ospf network point-to-point

 R8
 router ospf 300
 router-id 8.8.8.8
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 no passive-interface FastEthernet1/0
 network 8.8.8.0 0.0.0.255 area 0
 network 192.168.58.0 0.0.0.255 area 0
 network 192.168.89.0 0.0.0.255 area 0

 interface Loopback0
 ip ospf network point-to-point

R9
 router ospf 300
 router-id 9.9.9.9
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet1/0
 network 9.9.9.0 0.0.0.255 area 0
 network 192.168.89.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

Anledningen till att jag lagt till “ospf network point-to-point” är för att OSPF per default annars sätter network-type till stub för Loopbacks och endast annonserar våra nät som en /32.

EIGRP / AS200

R6
 router eigrp 200
 passive-interface default
 no passive-interface FastEthernet0/0
 network 7.7.7.0 0.0.0.255
 network 192.168.67.0
 no auto-summary

R7
 router eigrp 200
 passive-interface default
 no passive-interface FastEthernet1/0
 network 6.6.6.0 0.0.0.255
 network 192.168.67.0
 no auto-summary

OSPF / AS400

R10
router ospf 400
 router-id 10.10.10.10
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.10.10.0 0.0.0.255 area 0
 network 192.168.110.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

R11
router ospf 400
 router-id 11.11.11.11
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet1/0
 network 11.11.11.0 0.0.0.255 area 0
 network 192.168.110.0 0.0.0.255 area 0

interface Loopback0
 ip ospf network point-to-point

BGP

IBGP & Route-reflector

  • Configure BGP on every router
  • Configure on all routers that BGP updates are sourced from the Loopback0 interface.
  • R1 has to be configured as a route-reflector for R2 and R3.

Allt är relativt standard, kom ihåg att ändra update-source när vi använder Loopback-adresser för peering.

R1 – Kom ihåg route-reflector mot R2 & R3!

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 100
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 2.2.2.2 route-reflector-client
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 3.3.3.3 route-reflector-client
 no auto-summary

R2

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

R3

router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 update-source Loopback0
 no auto-summary

Blir lite tjatigt att ta med i princip identisk konfig för R6, R7, R10 & R11 så hoppar över det.

R4, R5, R8 & R9 tar vi nästa punkt då det ska konfigureras confederations istället.

Confederations

  • AS300 has to be configured as a confederation.

Vi tar och börjar med att sätta upp två confederations inom AS300, Sub-AS 10 & 20. Om du vill läsa mer om confederations har jag ett gammalt inlägg som går igenom detta relativt grundligt här.  Vanligtvis använder man privata AS-nummer för detta men tar och följer labben slaviskt nu.. 🙂

R4

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 20
 neighbor 5.5.5.5 remote-as 10
 neighbor 5.5.5.5 update-source Loopback0
 no auto-summary

R5

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 20
 neighbor 4.4.4.4 remote-as 10
 neighbor 4.4.4.4 update-source Loopback0
 neighbor 8.8.8.8 remote-as 20
 neighbor 8.8.8.8 update-source Loopback0
 no auto-summary

R8

router bgp 20
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 10
 neighbor 5.5.5.5 remote-as 10
 neighbor 5.5.5.5 update-source Loopback0
 neighbor 9.9.9.9 remote-as 20
 neighbor 9.9.9.9 update-source Loopback0
 no auto-summary

R9

router bgp 20
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 300
 bgp confederation peers 10
 neighbor 8.8.8.8 remote-as 20
 neighbor 8.8.8.8 update-source Loopback0
 no auto-summary

Det var all konfig.. Men tyvärr fungerade det inte riktigt som önskat. IBGP kom upp utan problem men av någon anledning får jag ej upp någon neighbor mellan R5 <-> R8.

R5#sh ip bgp
 *Mar 1 06:30:59.486: %SYS-5-CONFIG_I: Configured from console by consolesummary
 BGP router identifier 5.5.5.5, local AS number 10
 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 4.4.4.4 4 10 27 27 1 0 0 00:23:08 0
 8.8.8.8 4 20 0 0 0 0 0 never Idle

En debug ip bgp events gav inte heller någon vettig information. Tillslut kom jag äntligen på vad felet var: ebgp-multihop! TTL för EBGP är ju per default satt till 1, så när paketet när R5/R8 kastas paketet istället för att vidarebefordras till Loopback. Detta var inte direkt första gången jag åkt dit på den grejjen.. 🙂

R5
 neighbor 8.8.8.8 ebgp-multihop 2
 R8
 neighbor 5.5.5.5 ebgp-multihop 2

Nu ser det bättre ut!

R8#sh ip bgp summary
 BGP router identifier 8.8.8.8, local AS number 20
 BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 5.5.5.5 4 10 4 4 1 0 0 00:00:29 0
 9.9.9.9 4 20 15 15 1 0 0 00:11:38 0

Detta får räcka för idag, känns som inlägget blir lite väl långt annars. Fortsättning följer!

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… 🙂