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

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

TSHOOT – Part III, Dist-layer

tshoot-distlayer

Tar och bygger vidare på vårat tshoot-nät med Distribution-layer den här gången. Vi behöver bl.a. konfa upp EIGRP<->OSPF & RIP_NG <->OSPFv3 redistrubution.

Men först måste vi givetvis fixa L2/L3-konfig.. Tyvärr är just switch-funktionen i GNS3 väldigt begränsad (använder endast NM-16ESW-kort i 3640s), så våra port-channel nummer kommer inte stämma överens. Det finns inte heller möjlighet att skapa en L3-channel mellan DSW1 & DSW2 så här blir det endast en port som kommer användas.

Basic L3

R4

R4(config)#inte fa0/0
R4(config-if)#ip add 10.1.4.5 255.255.255.252
R4(config-if)#descrip to DSW1
R4(config-if)#no shut
R4(config-if)#ipv6 add 2026::2:1/122
R4(config-if)#inte fa0/1
R4(config-if)#ip add 10.1.4.9 255.255.255.252
R4(config-if)#desc to DSW2
R4(config-if)#no shut

DSW1

DSW1(config)#ip routing
DSW1(config)#ipv6 unicast-routing
DSW1(config)#int fa0/0
DSW1(config-if)#ip add 10.1.4.6 255.255.255.252
DSW1(config-if)#descrip to R4
DSW1(config-if)#no shut
DSW1(config-if)#ipv6 add 2026::2:2/122
DSW1(config)#int range fa1/13 - 14
DSW1(config-if-range)#descrip L3 Etherchannel to DSW2
DSW1(config-if-range)#no switchport
DSW1(config-if-range)#shut
DSW1(config-if-range)#
DSW1(config-if-range)#inte fa1/13
DSW1(config-if)#ip add 10.2.4.13 255.255.255.252
DSW1(config-if)#ipv6 add 2026::3:1/122
DSW1(config-if)#no shut

DSW2

DSW2(config)#ip routing
DSW2(config)#ipv6 uni
DSW2(config)#ipv6 unicast-routing
DSW2(config)#inte fa0/0
DSW2(config-if)#ip add 10.1.4.10 255.255.255.252
DSW2(config-if)#descrip to R4
DSW2(config-if)#no shut
DSW2(config-if)#int range fa1/13 - 14
DSW2(config-if-range)#descrip L3 Etherchannel to DSW1
DSW2(config-if-range)#no switchport
DSW2(config-if-range)#shut
DSW2(config-if-range)#inte fa1/13
DSW2(config-if)#ip add 10.2.4.14 255.255.255.252
DSW2(config-if)#no shut
DSW2(config-if)#ipv6 add 2026::3:2/122
DSW2(config-if)#exit

EIGRP

R4

R4(config)#router eigrp 10
R4(config-router)#no auto
R4(config-router)#no auto-summary
R4(config-router)#passive-
R4(config-router)#passive-interface default
R4(config-router)#no passive
R4(config-router)#no passive-interface fa0/0
R4(config-router)#no passive-interface fa0/1
R4(config-router)#network 10.1.4.4 0.0.0.3
R4(config-router)#network 10.1.4.8 0.0.0.3

DSW1

DSW1(config)#router eigrp 10
DSW1(config-router)#no auto-summary
DSW1(config-router)#passive-interface default
DSW1(config-router)#no passive-interface fa0/0
DSW1(config-router)#no passive-interface fa1/13
DSW1(config-router)#network 10.1.4.4 0.0.0.3
DSW1(config-router)#network 10.2.4.12 0.0.0.3

DSW2

DSW2(config)#router eigrp 10
DSW2(config-router)#no auto-summary
DSW2(config-router)#passive-interface default
DSW2(config-router)#no passive-interface fa0/0
DSW2(config-router)#no passive-interface fa1/13
DSW2(config-router)#network 10.1.4.8 0.0.0.3
DSW2(config-router)#network 10.2.4.12 0.0.0.3

RIPng

R4

R4(config-router)#inte fa0/0
R4(config-if)#ipv6 rip RIP_ZONE enable
R4(config-if)#int fa0/1
R4(config-if)#ipv6 rip RIP_ZONE enable

DSW1

DSW1(config)#inte fa0/0
DSW1(config-if)#ipv6 rip RIP_ZONE enable
DSW1(config)#int fa1/13
DSW1(config-if)#ipv6 rip RIP_ZONE enable

DSW2

DSW2(config)#inte fa0/0
DSW2(config-if)#ipv6 rip RIP_ZONE enable
DSW2(config)#int fa1/13
DSW2(config-if)#ipv6 rip RIP_ZONE enable

Redistribution

Då vi inte har multipoint-redistribution behöver vi inte använda oss av route-maps/tags i det här fallet.

R4(config)#router eigrp 10
R4(config-router)#redistribute ospf 1 metric 1500 1 255 1 1500
R4(config-router)#router ospf 1
R4(config-router)#redistribute eigrp 10 subnets
R4(config)#ipv6 router ospf 6
R4(config-rtr)#redistribute rip RIP_ZONE include-connected metric 20
R4(config)#ipv6 router rip RIP_ZONE
R4(config-rtr)#redistribute ospf 6 metric 5 include-connected

Verifiering

DSW2#sh ipv6 rip database
RIP process "RIP_ZONE", local RIB
 2026::2:0/122, metric 2, installed
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs
 2026::3:0/122, metric 2
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs
 2026::34:0/122, metric 7, installed
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs
 ::/0, metric 7, installed
 FastEthernet1/13/FE80::CE03:13FF:FE54:F10D, expires in 165 secs

Ping till R1 från DSW2

DSW2#ping ipv6 2026::12:1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2026::12:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/160/200 ms
DSW2#ping 10.1.1.1
Translating "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 = 52/111/192 ms

Vackert!

En trace till webservern fungerar dock ej:

DSW2#traceroute 209.65.200.241 Translating "209.65.200.241"
Type escape sequence to abort.
 Tracing the route to 209.65.200.241
1 10.1.4.9 16 msec 48 msec 48 msec
 2 10.1.1.9 108 msec 48 msec 44 msec
 3 10.1.1.5 40 msec 80 msec 84 msec
 4 10.1.1.1 140 msec 108 msec 156 msec
 5 * * *

Detta beror helt enkelt på att vi inte konfigurerat upp någon NAT ännu i R1 så trafiken hittar inte tillbaka. Det fixar vi imorgon tillsammans med DHCP-tjänsten & access-layer. 🙂

TSHOOT – Part I, Internet & BGP

bgp-internet

Tänkte fokusera på att sätta upp ovanstående del i detta inlägg vilket väl förhoppningsvis ska vara ganska basic.

Kan väl börja med webservern.

Webserver(config)#int fa0/0
Webserver(config-if)#ip add 209.65.200.241 255.255.255.248
Webserver(config-if)#no shut
Webserver(config-if)#exit
Webserver(config)#no ip routing
Webserver(config)#ip default-gateway 209.65.200.242

ISP:n har vi lite mer att fixa med.

ISP(config)#inte fa0/0
ISP(config-if)#ip add 209.65.200.242 255.255.255.248
ISP(config-if)#no shut
ISP(config-if)#descrip Webserver
ISP(config-if)#inte fa0/1
ISP(config-if)#ip add 209.65.200.226 255.255.255.252
ISP(config-if)#no shut
ISP(config-if)#descrip to C
ISP(config-if)#descrip to CustomerA
ISP(config-if)#exit

ISP(config)#router bgp 65002
ISP(config-router)#neighbor 209.65.200.225 remote-as 65001
ISP(config-router)#neighbor 209.65.200.225 shutdown
ISP(config-router)#neighbor 209.65.200.225 description CustomerA
ISP(config-router)#neighbor 209.65.200.225 default-originate
ISP(config-router)#redistribute connected route-map SetOrigin
ISP(config-router)#exit

ISP(config)#access-list 1 permit 209.65.200.240
ISP(config)route-map SetOrigin permit 10
ISP(config-route-map)#match ip address 1
ISP(config-route-map)#set origin igp
ISP(config-route-map)#route-map SetOrigin permit 20
ISP(config-route-map)#exit
ISP(config)#

Att sätta igp origin är väl egentligen inte nödvändigt men det blir åtminstone snyggare än att ha ett “?”. 😉

R1

R1(config)#int fa0/1
R1(config-if)#ip add 209.65.200.225 255.255.255.248
R1(config-if)#no shut
R1(config-if)#description to ISP
R1(config-if)#exit

R1(config)#router bgp 65001
R1(config-router)#neighbor 209.65.200.226 remote-as 65002
R1(config-router)#neighbor 209.65.200.226 description to ISP

Vi kan nu testa ta upp BGP-sessionen på ISPn och förhoppningsvis ska vi väl ha full connectivity mellan Webservern och R1 efter det.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route
Gateway of last resort is 209.65.200.226 to network 0.0.0.0
209.65.200.0/24 is variably subnetted, 3 subnets, 2 masks
B 209.65.200.240/29 [20/0] via 209.65.200.226, 00:03:13
B 209.65.200.224/30 [20/0] via 209.65.200.226, 00:03:13
C 209.65.200.224/29 is directly connected, FastEthernet0/1
B* 0.0.0.0/0 [20/0] via 209.65.200.226, 00:00:02

Verifiering:

R1#sh ip bgp
BGP table version is 4, local router ID is 209.65.200.225
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
*> 0.0.0.0 209.65.200.226 0 0 65002 i
*> 209.65.200.224/30
 209.65.200.226 0 0 65002 ?
*> 209.65.200.240/29
 209.65.200.226 0 0 65002 i
R1#ping 209.65.200.241
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/40/64 ms

BGP – Route Manipulation via Communities

Laddat upp med en dubbel espresso för nu är det dags att gå över Communities. Vi har i tidigare poster gått igenom hur vi kan påverka routing-beslut i BGP via:

Gemensamt för både AS_PATH Prepending & MED är dock att din peer/ISP måste acceptera att du skickar dessa attribut, något som är långt ifrån varken best practice eller vanligt förekommande. Oftast väljer istället ISP:n att helt enkelt ignorera dessa attribut från dina routing-uppdateringar om du försöker lägga till detta.

dualhomed

Tänk dig följande exempel – du som kund har köpt en dual-homed uppkoppling med en primär länk på 100Mbit & backup på 20Mbit. Hur stor tror du risken är att Telia skulle gå in och manuellt modifiera Weight eller Local Preference för dina länkar (alt. låta dig använda MED)? Med 10,000+ kunder så skulle det bli en del route-maps att hålla reda på för dem.. 😉

Det är istället här användandet av Communities kommer in i bilden. BGP Communitys är ett 32bitars värde, där i det “nya formatet” (ip bgp-community new-format) delas upp i två 16bitars värde. Best practice är att använda sitt AS-nummer i det första 16bitars fältet, och sedan använda det sista fältet enligt eget önskemål för att skapa sina communitys.

Så för en ISP med AS 300 hade dess community-värden exempelvis kunnat vara:

  • 300:1
  • 300:10
  • 300:25000
  • 300:60000

Om du istället skulle vilja använda det “gamla formatet” så skrivs hela värdet ut i en och samma 32bitars sträng. 300:10 hade då blivit:

0000 0001 0010 1100 0000 0000 1010

Vilket omskrivet i decimalt blir – 1,228,810. Så vi kan antingen skicka community-taggen 300:10, eller använda oss av det gamla formatet och skicka taggen 1228810 för att få samma effekt- ganska lätt att se vad som är enklast! 🙂

Vi annonserar sedan community-taggen tillsammans med övriga BGP Attribut som Origin/Next hop/AS-Path etc, Community räknas förövrigt som du kanske kommer ihåg från posten “BGP Key Attributes”  tidigare i veckan som ett “Optional Attribute“. Alla routrar har med andra ord inte stöd för detta!

Genom communitys kan vi som kund “tagga” våra routing-uppdateringar enligt de värden som vår ISP tagit fram. ISPn kan i sin tur sedan använda en default route-map för alla sina kunder där de matchar Community-värden och ifrån det sätter exempelvis ett förutbestämt Weight eller Local Preference värde.

En vanlig lösning verkar vara att ISPn skickar ett excel-blad med alla sina förutbestämda communitys och dess “åtgärder”, något i stil med detta:

Community-excel

Om vi som kund sedan taggar vårat nät 200.0.0.0/24 med community 300:10 kommer då ISPn att ändra Local Preference till 10. Taggar vi med community 300:201 så kommer ISPn istället att använda AS_Path Prepend och lägga till ytterligare ett AS-hopp. Vi kan även kombinera flera communities om vi så önskar, taggar vi samma route med 300:50 OCH 300:202 så ändras både Local Preference & AS_Path Prepending!

Det är ganska lätt att se hur enormt mycket mer skalbart och lättanvänt detta är för vår ISP, alternativet hade ju varit att skapa individuella route-maps för varje kund som önskar någon form av routing-modifiering..

Labbexempel

MED

Vi tar och testar detta i praktiken med ovanstående topologi.

  • Länken mellan R1 & R3 är på 50M
  • Länken mellan R1 & R4 är på 2M
  • Länken mellan R2 & R4 är på 100M

Vi vill således att vår ISP använder länken via R2-R4 primärt för trafik som kommer från “the Internet”. Att modifiera Weight eller AS_Path-Prepending fungerar ej i detta fall, vår ISP måste istället använda Local Preference. Om du inte förstår varför så föreslår jag att du går tillbaka och läser posterna relaterat till detta länkat överst i dedå det är rätt basic vid det här laget. 😉

Vår ISP har skickat följande lista med communities vi kan använda oss av:

Community-excel.2png

Vi börjar med att konfigurera upp vår egen utrustning så kollar vi senare på hur ISPn hanterar detta.

Med ren grundkonfig kan vi se att ISP just nu föredrar den sämre länken via R1 på 50Mbit för att nå nätet 10.0.12.0/24.

bgp-community-default

Vi börjar med att konfigurera R1 – men vad är det vi vill åstadkomma? Kom ihåg att för Local Preference så är högst värde bäst (default 100), vi vill med andra ord att ISP ändrar Local Preference till <100 för länken mellan R1 – R3, och sedan sätter ett ännu lägre värde för länken mellan R1 – R4.  Enligt excel-listan behöver vi då sätta följande communities:

  • Länken mellan R1 – R3 – community 65000:50
  • Länken mellan R1 – R4 – community 65000:10

Vi börjar dock med en access-lista:

access-list 1 permit 10.0.12.0 0.0.0.255

Sedan en route-map:

route-map PeerToR3 permit 10
match ip address 1
 set community 65000:50
route-map PeerToR4 permit 10
match ip address 1
 set community 65000:10

Hur får vi då routern att skicka communities till sina peers? Vi måste först aktivera “bgp-community new format” då vi använt oss av det nya formatet att skriva communities:

ip bgp-community new-format

Vi behöver sedan bara konfigurera följande mot våra peers:

router bgp 500
neighbor 191.0.0.2 route-map PeerToR3 out
neighbor 191.0.0.2 send-community
neighbor 191.0.0.6 route-map PeerToR4 out
neighbor 191.0.0.6 send-community

Vi gör i princip samma sak för R2, men här behöver vi egentligen inte ändra LP då vi sänkt de andra länkarna till <100, men det är ju bra träning om inte annat.. 🙂

access-list 1 permit 10.0.12.0 0.0.0.255
route-map PeerToR4 permit 10
match ip address 1
 set community 65000:110
ip bgp-community new-format
router bgp 500
neighbor 191.0.0.10 route-map PeerToR4 out
neighbor 191.0.0.10 send-community

Svårare än så är det inte!

Hur har då vår ISP konfigurerat sitt nät?

Vi skapar först något som kallas “community-list”, här specificerar vi våra communities så vi sedan kan använda oss av dessa i route-maps:

ip community-list 1 permit 65000:10
ip community-list 2 permit 65000:50
ip community-list 3 permit 65000:110

Dessa fungerar precis som en access-lista och det finns möjlighet att göra både standard & extended-versioner:

R3(config)#ip community-list ?
 <1-99> Community list number (standard)
 <100-500> Community list number (expanded)
 expanded Add an expanded community-list entry
 standard Add a standard community-list entry

Vi skapar sedan en default route-map vi använder till alla våra kunder:

route-map CUSTOMER_DEFAULT permit 10
match community 1
 set local-preference 10
route-map CUSTOMER_DEFAULT permit 20
match community 2
 set local-preference 50
route-map CUSTOMER_DEFAULT permit  30
match community 3
 set local-preference 110
route-map CUSTOMER_DEFAULT permit 40

Inget konstigt direkt, istället för match ip address där vi sedan använt oss av en access-lista använder vi här istället match community, vilket hänvisar till den ip community-list vi tidigare skapat.

ip bgp-community new-format
router bgp 65000
neighbor x.x.x.x route-map CUSTOMER_DEFAULT in

Detta ger följande resultat:

R3

bgp-community-finalr3

R4

bgp-community-finalr4

R5

bgp-community-finalr5

Vackert! Vi behöver givetvis inte begränsa oss till endast ändra Weight/Local Preference, möjligheterna är rätt rejäla 😉

R5(config-route-map)#set ?
 as-path Prepend string for a BGP AS-path attribute
 automatic-tag Automatically compute TAG value
 clns OSI summary address
 comm-list set BGP community list (for deletion)
 community BGP community attribute
 dampening Set BGP route flap dampening parameters
 default Set default information
 extcommunity BGP extended community attribute
 interface Output interface
 ip IP specific information
 ipv6 IPv6 specific information
 level Where to import route
 local-preference BGP local preference path attribute
 metric Metric value for destination routing protocol
 metric-type Type of metric for destination routing protocol
 mpls-label Set MPLS label for prefix
 nlri BGP NLRI type
 origin BGP origin code
 tag Tag value for destination routing protocol
 traffic-index BGP traffic classification number for accounting
 vrf Define VRF name
 weight BGP weight for routing table

Det får avsluta communities för den här gången, nästa post blir troligtvis om Route-Reflectors eller Confederations.

BGP – Lab, Configuring a Transit AS/ISP

Tänkte göra ett försök att sätta upp Jeremys Transit AS-lab från hans CCIP BGP-serie. Labben är uppbyggd enligt följande:

topology transit lab
scenario transit lab

requirements transit lab 1

requirements transit lab 2

Min lösning

gns3topology

Grundkonfig

!ISP1 Basic conf
inte s0/0
ip add 17.9.1.1 255.255.255.252
no shut
description To R2
clock rate 256000
int s0/1
ip add 17.9.1.5 255.255.255.252
no shut
description To R2
clock rate 256000
int lo0
ip add 11.11.11.11 255.255.255.255
no shut

!ISP2 Basic conf
inte s0/0
ip add 180.1.5.1 255.255.255.252
no shut
description To R1
clock rate 256000
int s0/1
ip add 180.1.5.5 255.255.255.252
no shut
description To R1
clock rate 256000
int lo0
ip add 22.22.22.22 255.255.255.255
no shut

!R1 Basic conf
int s0/0
ip add 17.9.1.2 255.255.255.252
no shut
description To ISP1
int s0/1
ip add 17.9.1.6 255.255.255.252
no shut
description To ISP1
int s0/2
ip add 10.1.1.5 255.255.255.252
no shut
clock rate 256000
description To R2
int s0/3
ip add 10.1.1.1 255.255.255.252
no shut
clock rate 256000
description To R3
int lo0
ip add 1.1.1.1 255.255.255.255

!R2 Basic conf
int s0/0
ip add 180.1.5.2 255.255.255.252
no shut
description To ISP2
int s0/1
ip add 180.1.5.6 255.255.255.252
no shut
description To ISP2
int s0/2
ip add 10.1.1.6 255.255.255.252
no shut
description To R1
int s0/3
ip add 10.1.1.9 255.255.255.252
no shut
clock rate 256000
description To R4
int lo0
ip add 2.2.2.2 255.255.255.255

!R3 Basic conf
int s0/0
ip add 150.1.0.1 255.255.255.252
no shut
description To Cust1
clock rate 256000
int s0/1
ip add 10.1.1.13 255.255.255.252
no shut
clock rate 256000
description To R4
int s0/3
ip add 10.1.1.2 255.255.255.252
no shut
description To R1
int lo0
ip add 3.3.3.3 255.255.255.255

!R4 Basic conf
int s0/0
ip add 10.1.1.10 255.255.255.252
no shut
description To R2
int s0/1
ip add 10.1.1.14 255.255.255.252
no shut
description To R3
int lo0
ip add 4.4.4.4 255.255.255.255
no shut
!Cust1 Basic conf
int s0/0
ip add 150.1.0.2 255.255.255.252
no shut
description To R3
int lo0
ip add 150.1.1.1 255.255.255.0

Configure IGP

  • Configure network-statements as specific as possible
  • Only advertise between internal routers
  • Use a hello-timer of 1 second / dead-timer of 3 seconds

Enligt uppgiften skulle vi använda oss av OSPF. Känns inte som något är nytt här så skriver bara ner den konfig jag skriver. Kom ihåg att vi sätter hello/deadtimers per interface! Glöm inte passive-interface default.

!R1
router ospf 1
passive-interface default
no passive-interface s0/2
no passive-interface s0/3
router-id 1.1.1.1
network 1.1.1.1 0.0.0.0 area 0
network 17.9.1.2 0.0.0.0 area 0
network 17.9.1.6 0.0.0.0 area 0
network 10.1.1.5 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
int s0/2
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R2
router ospf 1
passive-interface default
no passive-interface s0/2
no passive-interface s0/3
router-id 2.2.2.2
network 2.2.2.2 0.0.0.0 area 0
network 180.1.5.2 0.0.0.0 area 0
network 180.1.5.6 0.0.0.0 area 0
network 10.1.1.6 0.0.0.0 area 0
network 10.1.1.9 0.0.0.0 area 0
int s0/2
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R3
router ospf 1
passive-interface default
no passive-interface s0/3
no passive-interface s0/1
router-id 3.3.3.3
network 3.3.3.3 0.0.0.0 area 0
network 150.1.0.1 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0
network 10.1.1.13 0.0.0.0 area 0
int s0/1
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/3
ip ospf hello-interval 1
ip ospf dead-interval 3

!R4
router ospf 1
passive-interface default
no passive-interface s0/0
no passive-interface s0/1
router-id 4.4.4.4
network 4.4.4.4 0.0.0.0 area 0
network 10.1.1.14 0.0.0.0 area 0
network 10.1.1.10 0.0.0.0 area 0
int s0/0
ip ospf hello-interval 1
ip ospf dead-interval 3
int s0/1
ip ospf hello-interval 1
ip ospf dead-interval 3

Kom ihåg att verifiera så att alla nät är nåbara redan nu innan det börjar bli lite mer avancerat. 🙂

Full-mesh IGP

  • Peers should fail over based on IGP if any internal links fail
  • Set logical descriptions in BGP
  • Disable BGP synchronization

Steg 1 har vi redan löst delvis genom att konfigurera Loopbacks på R1-R4 som vi annonserar via OSPF. När vi sätter upp iBGP-relations nu så behöver vi endast använda loopback-adresserna istället för de fysiska länknäten. Kom ihåg att även ändra update-source (om du inte vet varför, se tidigare inlägg om iBGP transit-area)!

Steg 2 fixar vi genom descriptions per neighbor-statement, och BGP synchronization är avslaget per default i den IOS jag använder (v12.4(15)T13) (no synchronization).

!R1 iBGP
router bgp 500
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
no synchronization

!R2
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
neighbor 4.4.4.4 update-source Lo0
no synchronization

!R3
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 4.4.4.4 remote-as 500
neighbor 4.4.4.4 description iBGP to R4
neighbor 2.2.2.2 update-source Lo0
no synchronization

!R4
router bgp 500
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description iBGP to R1
neighbor 1.1.1.1 update-source Lo0
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description iBGP to R2
neighbor 2.2.2.2 update-source Lo0
neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 description iBGP to R3
neighbor 3.3.3.3 update-source Lo0
no synchronization

En sh ip bgp summary visar att vi är på rätt spår. 🙂

R1#sh ip bgp summary 
BGP router identifier 1.1.1.1, local AS number 500
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 500 6 7 1 0 0 00:03:47 0
3.3.3.3 4 500 4 5 1 0 0 00:01:55 0
4.4.4.4 4 500 4 4 1 0 0 00:00:12 0

Configure eBGP-peers between NL Fast & ISP1-2 and Customer

  • On redudant links, peers using loopback and provide loadbalancing
  • Configure authentication
  • Set logical descriptions for neighbors

Steg 1 skiljer sig inte jättemycket från vad vi nyss gjorde när vi satte upp iBGP-mesh. Som du förhoppningsvis kommer ihåg tillåter BGP endast en öppen session mot en neighbor, för redundanta länkar bör vi således använda Loopback-interface för att inte vara låsta till någon specifik länk. Kom ihåg att ändra update-source!

Lastbalansering skapar vi enklast via två statiska routes som båda pekar på ISP1/2s loopback-adress och vice-versa.

Autentisering har jag inte skrivit någon post om ännu men det är extremt enkelt att sätta upp i BPG som du kommer se nedan.

!R1 eBGP

ip route 11.11.11.11 255.255.255.255 17.9.1.1
ip route 11.11.11.11 255.255.255.255 17.9.1.5

router bgp 500
neighbor 11.11.11.11 remote-as 200
neighbor 11.11.11.11 description ISP1
neighbor 11.11.11.11 password cisco
neighbor 11.11.11.11 update-source lo0

!ISP1

ip route 1.1.1.1 255.255.255.255 17.9.1.2
ip route 1.1.1.1 255.255.255.255 17.9.1.6

router bgp 200
neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 description ISP1
neighbor 1.1.1.1 password cisco
neighbor 1.1.1.1 update-source Lo0

!R2

ip route 22.22.22.22 255.255.255.255 180.1.5.1
ip route 22.22.22.22 255.255.255.255 180.1.5.5

router bgp 500
neighbor 22.22.22.22 remote-as 300
neighbor 22.22.22.22 description ISP1
neighbor 22.22.22.22 password cisco
neighbor 22.22.22.22 update-source lo0
neighbor 22.22.22.22 ebgp-multihop 2

!ISP2

ip route 2.2.2.2 255.255.255.255 180.1.5.2
ip route 2.2.2.2 255.255.255.255 180.1.5.6

router bgp 300
neighbor 2.2.2.2 remote-as 500
neighbor 2.2.2.2 description ISP1
neighbor 2.2.2.2 password cisco
neighbor 2.2.2.2 update-source Lo0

Här fastande jag dock ett tag, av någon anledning fick jag inte upp någon adjacency? Varken debug ip bgp all eller wireshark gav några hintar om vad felet kunde tänkas vara. En show ip bgp summary visade endast att neighbor x.x.x.x var fast i “idle”. Tillslut kom jag dock på vad det var, gör du? Försök att finna lösningen själv!

facit i vit text (markera för svar): eBGP-multihop! TTL sätts som bekant till 1 för eBGP-relationsships, när vi använder Loopbacks behöver vi därför modifera detta via neighbor x.x.x.x ebgp-multihop 2. Har en tidigare post dedikerad om just detta om detta koncept är nytt för dig och finns att läsa här.

Announce networks in BGP appropriately

  • ISP1 & 2 should use filtered redistribution to announce their networks. Only networks located on the loopback-interfaces of ISP1&2 should enter the BGP-table
  • The Cust1-router should advertise its network using the network-statement
  • R1 & R2 should advertise the WAN-link subnet (currently 150.1.0.0/30) as 150.1.0.0/24

Här är det nog lika bra vi bryter ner det i mindre delar. Vi börjar med filtered redistribution!

Verkar som att det saknades i topologin jeremy skapade, men ISP1 ska tydligen ha mer än det loopback-nätet vi använder för att sätta upp eBGP. Jag skapade därför 5 nät på respektive router:

!R1
int lo1
ip add 200.10.0.1 255.255.255.0
int lo2
ip add 200.10.1.1 255.255.255.0
int lo3
ip add 200.10.2.1 255.255.255.0
int lo4
ip add 200.10.3.1 255.255.255.0
int lo5
ip add 200.10.4.1 255.255.255.0

!R2
int lo1
ip add 200.20.0.1 255.255.255.0
int lo2
ip add 200.20.1.1 255.255.255.0
int lo3
ip add 200.20.2.1 255.255.255.0
int lo4
ip add 200.20.3.1 255.255.255.0
int lo5
ip add 200.20.4.1 255.255.255.0

Vi hade enkelt kunnat lösa detta genom att använda network-statements för Loopback-näten, men i detta fall så önskas filtrering. Finns säkert många olika lösningar på detta men såhär tänkte jag:

Vi skapar först en prefix-lista:

!ISP1
 ip prefix-list LOOPBACKS seq 5 permit 200.10.0.0/24
 ip prefix-list LOOPBACKS seq 10 permit 200.10.1.0/24
 ip prefix-list LOOPBACKS seq 15 permit 200.10.2.0/24
 ip prefix-list LOOPBACKS seq 20 permit 200.10.3.0/24
 ip prefix-list LOOPBACKS seq 25 permit 200.10.4.0/24

 !ISP2
 ip prefix-list LOOPBACKS seq 5 permit 200.20.0.0/24
 ip prefix-list LOOPBACKS seq 10 permit 200.20.1.0/24
 ip prefix-list LOOPBACKS seq 15 permit 200.20.2.0/24
 ip prefix-list LOOPBACKS seq 20 permit 200.20.3.0/24
 ip prefix-list LOOPBACKS seq 25 permit 200.20.4.0/24

Sedan en route-map som endast tillåter nät som matchar vår prefix-lista, passar även på att sätta origin till igp när vi ändå är igång:

!ISP1 & 2
route-map LOOPBACK_FILTER permit 10
match ip address prefix-list LOOPBACKS
set origin igp

Och vi använder sedan route-mapen som filter när vi aktiverar redistribution av nät som är “Connected”:

!ISP1 & 2
router bgp 200 / 300
redistribute connected route-map LOOPBACK_FILTER

Det borde fixa biffen! En debug visar att vi är på rätt spår:

*Mar 1 02:18:30.707: BGP: Applying map to find origin for 200.10.4.0/24
*Mar 1 02:18:30.735: BGP: Applying map to find origin for 200.10.0.0/24
*Mar 1 02:18:30.739: BGP: Applying map to find origin for 200.10.1.0/24
*Mar 1 02:18:30.743: BGP: Applying map to find origin for 200.10.2.0/24
*Mar 1 02:18:30.747: BGP: Applying map to find origin for 200.10.3.0/24

Och en sh ip bgp på R4 visar att allt fungerar som det ska!

R4-bgplab

Next up var :

  • The Cust1-router should advertise its network using the network-statement

Denna router har just nu endast grundkonfig så vi får fixa allt grundläggande också! Då vi ej har en redundant lina behöver vi ej “krångla” med loopbacks/ebgp multihop. Observera också att kunden använder ett Privat-AS, vilket kan jämföras med privata ip-adresser, och bör således aldrig annonseras ut till internet(ISP1/2).

!R3
 router bgp 500
 neighbor 150.1.0.2 remote-as 64512
 neighbor 150.1.0.2 description Cust1
 neighbor 150.1.0.2 password cisco

!Cust1 (private AS)
 router bgp 64512
 no synchronization
 network 150.1.1.0 mask 255.255.255.0
 neighbor 150.1.0.1 remote-as 500
 neighbor 150.1.0.1 description NLFastISP
 neighbor 150.1.0.1 password cisco

Ser bra ut! Observera dock att vi just nu skickar med det privata as-numret till ISP:en.

isp1

Detta är inget som nämns i CCNP-boken så fick ta och googla lite, skönt nog var det väldigt enkelt att fixa!

!R1
router bgp 500
neighbor 11.11.11.11 remove-private-as

!R2
router bgp 500
neighbor 22.22.22.22 remote-private-as
  • R1 & R2 should advertise the WAN-link subnet (currently 150.1.0.0/30) as 150.1.0.0/24

Enklast tycker jag borde vara att göra enligt följande:

!R3
ip route 150.1.0.0 255.255.255.0 null0
router bgp 500
network 150.1.0.0 mask 255.255.255.0

Svårare än så behöver det nog inte vara..

isp1-null0

Woho!! 🙂

Verify

  • Verify that all expected neighbors have formed – check!
  • Verify that all expected routes appear – check!
  • ISP1 & 2 should be able to ping: Cust1 routes & NL FastISP WAN-link
ISP1#ping 150.1.0.1 source lo0
Success rate is 0 percent (0/5)
ISP1#ping 150.1.1.1 source lo0
Success rate is 0 percent (0/5)

Crap.. 🙂 Let the troubleshooting begin!

En traceroute visar att vi fastnar i R3:

ISP1#traceroute 150.1.0.2
Type escape sequence to abort.
Tracing the route to 150.1.0.2
1 17.9.1.6 36 msec
 17.9.1.2 48 msec
 17.9.1.6 72 msec
 2 10.1.1.2 8 msec 40 msec 124 msec
 3 * * *

Om du varit väldigt uppmärksam på skärmdumparna jag visat under labben här så kanske du redan upptäckt ett stort problem. Om vi kollar en skärmdump från R4 exempelvis:

r4-bgplab2

Endast 150.1.0.0/24 & 150.1.1.0/24 har valts till “best”-route och har därför inte lagt in i routing table! Det är även därför vi inte kan se ISP2’s routes i ISP1’s table.

isp1-null0

Problemet är helt enkelt att routrarna EJ har en route för den next-hop adressen som annonseras (förutom R1<->ISP1 och R2<->ISP2 tack vare sina statiska routes)!

Jag löste det enligt följande:

!R1
access-list 1 permit 11.11.11.11 0.0.0.0 
route-map LOOP_REDIST permit 10
match ip address 1
router ospf 1
redistribute static subnets route-map LOOP_REDIST

!R2
access-list 1 permit 22.22.22.22 0.0.0.0 
route-map LOOP_REDIST permit 10
match ip address 1
router ospf 1
redistribute static subnets route-map LOOP_REDIST

Let’s watch the magic happen! 🙂

r4-bgplab3

Och från ISP:

isp2

Vackert!

Vi bör dock se till att Customer1 får en default-route, vi vill ju inte hålla på och annonsera våra interna nät dit. Detta löser vi enklast genom följande:

!R3
router bgp 500
#neighbor 150.1.0.2 default-originate

Detta skickar en default-route till Cust1 via BGP! Enkelt. 🙂

custisp

Vi kan nu pinga som önskat!

ISP1#ping 150.1.1.1 source lo1
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/63/92 ms

ISP2#ping 150.1.1.1 source lo1
Success rate is 100 percent (5/5), round-trip min/avg/max = 52/83/140 ms

Finally! Ytterligare något man skulle kunna fixa till är att blockera ISP1 från att lära sig ISP2’s routes via vårat AS och vice versa, då detta gör oss till en transit-area även för dem – något vi absolut inte vill! Men klockan börjar bli väldigt sent och jag ska upp tidigt och jobba imorgon så tar och avslutar här. Problemet hade vi hur som enkelt löst genom route-maps, och endast tillåtit de nät vi specificerar att annonseras ut till AS200 & 300.

BGP – AS_Path Prepend & MED

AS_Path Prepend

Steg 4 i BGPs “best path selection”-process är som vi redan vet AS_PATH och vi har tagit upp hur denna process går till i flera tidigare inlägg, bland annat AS_SEQ Path Attribute & Path Selection Part II.

Genom att använda oss av AS_PATH Prepend får vi möjlighet att manuellt lägga till ytterligare AS i AS_PATH för en route och på så vis få den mindre attraktiv. Detta påverkar dock ej AS_Path Loop Prevention så vi har möjlighet att lägga till samma AS-nummer ett flertal gånger istället.

Om vi kollar från R7s perspektiv i ovanstående topologi, så har vi  exempelvis möjlighet att få routes vi lär oss från AS500 att se sämre ut genom att lägga till ytterligare AS_Path hopp.

En sh ip bgp visar följande just nu:

as_path

För alla externa 200.0.x.0/24-routes (förutom 200.0.3.0/24 pga weight 10 från ett tidigare inlägg) så väljer R7 att gå den kortare AS_Path vägen via AS500 -> AS 100.

Låt oss testa lägga till ytterligare AS för 200.0.1.0/24 & 200.0.2.0/24..

Först en access-lista prefix-lista (för att variera oss lite):

ip prefix-list AS_PATH seq 5 permit 200.0.1.0/24
ip prefix-list AS_PATH seq 10 permit 200.0.2.0/24

Vi skapar sedan en route-map:

route-map AS_PATH_PREPEND permit 10
match ip address prefix-list AS_PATH
set as-path prepend 500 500
route-map AS_PATH_PREPEND permit 20

Detta bör lägga till ytterligare två AS-hopp (500) för 200.0.1.0/24 & 200.0.2.0/24, och routern bör således föredra att  istället gå via R6(AS200) pga ett AS-hopp mindre.

as_path2

Stämmer bra!

Något som inte tas upp i boken (Official Certification Guide – CCNP ROUTE, Wendell Odom) men som kändes rätt intressant – borde vi inte genom detta även kunna påverka hur vi annonserar våra nät till andra AS?

Om vi tar från R7’s perspektiv igen, tänk om vi köpt en snabbare uppkoppling mot R6/AS200 än mot R4/As500, och således föredrar att våra kunder (ex. AS100) går via den routern istället för att nå 192.168.0.0/24? Vi har ju som kund ingen möjlighet att gå in och konfigurera ett annat företags/isps weight/local preference – men borde vi inte kunna annonsera ytterligare AS-hopp för den vägen vi anser vara “sämre”?

Vi testar!

Jag har tagit bort route-mapen vi skapade innan och börjar om från noll..

Först en prefix-lista:

ip prefix-list AS_PATH_INTERNAL permit 192.168.0.0/24

Sedan en route-map:

route-map RMAP-AS_PATH_INTERNAL permit 10
match ip address prefix-list AS_PATH_INTERNAL 
set as-path prepend 50 50
route-map RMAP-AS_PATH_INTERNAL permit 20

Och aktiverar den i BGP:

router bpg 50
neighbor 172.16.47.4 route-map RMAP-AS_PATH_INTERNAL out

Har som sagt ingen aning om detta fungerar eller ej, men kollar vi i R7 så är det ingen skillnad vilket kanske inte är helt lovande..

as_path3

Men i R4 har det hänt grejjer! 🙂

as_path4

Och en trace från AS100/R5 visar att det fungerar som önskat!

R5#traceroute 192.168.0.1 source lo5
Type escape sequence to abort.
Tracing the route to 192.168.0.1
1 172.16.51.1 12 msec 132 msec 12 msec
 2 172.16.12.2 140 msec 60 msec 92 msec
 3 172.16.23.3 52 msec 136 msec 20 msec
 4 172.16.36.6 116 msec 80 msec 112 msec
 5 172.16.76.7 92 msec * 108 msec

Coolt! Lite märkligt att det inte nämns något i boken om detta dock? Känns som det är ett väldigt smidigt sätt att influera vägvalet för ANDRA företag/AS till dina nät? 🙂 Svaret kommer kanske i nästa del då kapitlet heter “Influencing an Enterprise’s Inbound routes with MED”.

Multi Exit Discriminator (MED)

  • Is a path attribute
  • Purpose – Allows an AS to tell a neighboring AS the best way to forward packets into the first AS
  • Scope – Advertised by one AS into another, propagated inside the AS, but not send to any other autonomous systems
  • Range – 0 to 4,294,967,295 (2^32 – 1)
  • Which is best ? Smaller is better
  • Default – 0
  • Configuration – Via neighbor route-map out, using the set metric in the route-map

Boken tar upp ett problem med mina tankegångar ovan – är du ett mindre företag är risken stor att de publika nät du annonserar till “internet” summeras hos din ISP tillsammans med många andra kunder. Vilket i sin tur gör att alla potentiella justeringar du gör “försvinner”, vi kan dock fortfarande påverka det “sista” hoppet, mellan dig som kund och din ISP(er).

Det är här MED kommer in i bilden, det ger oss nämligen möjlighet att berätta för ISP:en vilken väg (exit point) som är att föredra in till ditt nät. MED skapades till en början för dual-homed nät, men har på senare tid expanderats och kan nu även användas för dual-multihomed lösningar! MED skickas till vår eBGP-neighbor och sprids sedan vidare till dess iBGP-peers. Informationen skickas dock EJ vidare till andra AS! Endast modifierandet av AS-path som vi gjorde tidigare kan göra detta.

MED

Om vi använder ovanstående topologi så ser BGP-table ut enligt följande innan vi gör några modifieringar:

med-bgptable

med-bgptable2

Och en traceroute från Internet till 10.0.12.0/24 visar att trafiken just nu väljer att gå via R5 -> R3 -> R1 -> R2.

Internet#traceroute 10.0.12.2 source 200.0.0.1
Type escape sequence to abort.
 Tracing the route to 10.0.12.2
1 140.0.0.2 12 msec 68 msec 36 msec
 2 172.0.35.3 40 msec 36 msec 48 msec
 3 191.0.0.1 112 msec 64 msec 84 msec
 4 10.0.12.2 [AS 500] 116 msec * 100 msec

Om vi nu säger att företaget har köpt följande länkhastigheter av sin ISP:

R1 -> R3 – 10Mbit
R1 -> R4 – 2Mbit
R2 – R4 – 100Mbit

Så är det ju klart och tydligt att den väg trafiken från internet tar till vårat nät är klart icke-optimalt.

Det blir då rätt självklart att vi på något sätt vill försöka influera vår eBGP-neighbor att istället gå via 100Mbits-länken. Kom ihåg att för MED så är lägst värde bäst, till skillnad mot Weight & Local preference.

Vi börjar med att konfa R1:

ip prefix-list INTERNAL permit 10.0.12.0/24
route-map SET-MED-R3 permit 10
 match ip address prefix-list INTERNAL
 set metric 50
 route-map SET-MED-R4 permit 10
 match ip address prefix-list INTERNAL
 set metric 100
router bgp 500
 neighbor 191.0.0.2 route-map SET-MED-R3 out
 neighbor 191.0.0.6 route-map SET-MED-R4 out

Och sedan för R2:

ip prefix-list INTERNAL permit 10.0.12.0/24
 route-map SET-MED-R4 permit 10
 match ip address prefix-list INTERNAL
 set metric 10
router bgp 500
 neighbor 191.0.0.10 route-map SET-MED-R4 out

Detta ger följande resultat i R3:

med-r3

R4:

med-r4

R5:

med-r5

Inte allt för krångligt!

Om vi gör en ny traceroute från Internet kan vi nu se att den tar den “snabbare” vägen:

Internet#traceroute 10.0.12.2 source 200.0.0.1
Type escape sequence to abort.
 Tracing the route to 10.0.12.2
1 140.0.0.2 44 msec 60 msec 8 msec
 2 172.0.45.4 44 msec 100 msec 88 msec
 3 191.0.0.9 56 msec * 16 msec

Men som synes nedan så skickas EJ MED-attributet vidare till nästa AS (25000) då vi ej kan se några värden längre.

med-internet

Vackert! Nu har vi endast maximum paths kvar att gå igenom innan vi är “klara” med CCNP’s BGP-del, även om vi gått ganska långt utanför “CCNP-scopet” i tidigare poster också. 😛

Kommer nog köra vidare på samma spår och fortsätta med BGP då det känns som vi fortfarande bara skrapat lite på ytan av vad som är möjligt. Behöver bara leta upp en ny bok som täcker det materialet (CCIE Certification Guide eller TCP/IP Routing vol2 misstänker jag).. 🙂

BGP – Local Preference & RIB-failures

Vi fortsätter på temat BGP Path Selection från föregående posten där vi kollade närmare på route manipulering via route-maps & weight-attributet.

Local Preference

  • Is a Path Attribute
  • Purpose – Identifies the best exit point from the AS to reach a given prefix
  • Scope – Throughout the AS in which it was set; not advertised to eBGP peers
  • Range – 0 through 4,294,967,295 (2^32 – 1)
  • Which is best? – Higher value is better
  • Default – 100
  • Changing the default – Using the bgp default local-preference n
  • Configuration – Via neighbor route-map; in option is required for updates from an eBGP peer

Efter Weight under BGP’s “best path selection”-process så hittar vi Local Preference, som tillskillnad från just Weight är det BGP Path Attribute. Detta betyder att det inte används endast lokalt av den routern vi konfigurerar det på utan att det annonseras vidare till andra. För Local Preference så är det dock endast till iBGP-neighbors vi annonserar detta!

Detta ger oss möjligheten att inom ett enskilt AS ge oss möjligheten att annonsera till alla iBGP-neighbors en önskad “exit point” för en specifik route vi lärt oss via eBGP. Själva utförandet görs genom en route-map på de inkommande routinguppdateringarna från vår eBGP-peer.

Om vi tittar närmare på ovanstående topologi så har vi ett full mesh-nät inom AS500 mellan R1,R2,R3 & R4. BGP table ser för tillfället ut enligt följande för R1:

bgp localpreference

Och R2:

bgp localpreference2

Du kanske redan har sett något som ser lite konstigt ut? För R2 så har vi default-värdet 100 på Local Preference för samtliga routes, men inte på R1? Vi har även routes markerade med r för R2, men mer om detta senare.

Detta beror på att som tidigare nämnt så används Local Preference endast inom iBGP, routes vi lärt oss från eBGP (R1) skickas endast med ett null värde och routern listar därför inget alls för dessa. R2, som inte har någon eBGP-neighbor utan lär sig alla routes via iBGP får dock default-värdet 100 för samtliga.

För att testa detta rent praktiskt – låt oss försöka konfigurera så att alla iBGP-peers i AS500 väljer omvägen via AS200 för att nå nätet 192.168.0.0/24, istället för direkt via R4 -> AS50.

Vilken router är det då vi ska utföra ändringen i? Om Local Preference justeras via en route-map på inkommande routing-uppdateringar från en eBGP-neighbor, så måste det ju vara i R3 vi ska ändra detta?

Vi börjar med att skapa en…. access-lista.

access-list 1 permit 192.168.0.0

Vi skapar sedan en route-map:

route-map LOCAL-PREF permit 10
match ip address 1
set local-preference 150
route-map LOCAL-PREF permit 20
router bgp 500
neighbor 172.16.36.6 route-map LOCAL-PREF in
do clear ip bgp *

Om allt fungerar som det ska så skall nu R3 annonsera detta till resterande iBGP-neighbors (R1,R2 & R4) som tack vare den högre Local pref. kommer välja att gå via R3(AS500) -> R6(AS200) -> R7(AS50) för att nå 192.168.0.0/24.

bgp localpref3

Sick! 🙂

Vi hade givetvis även kunnat ändra detta i R4 också, men då istället sänkt Local Preference <100 för att få samma effekt.

RIB-Failure

När BGP är klar med sin “BGP best path”-algoritm och har valt vilken väg som är bäst för en specifikt destination, har jag tidigare skrivit att detta skickas vidare till routerns routing table, detta är dock en sanning med modifikation..

BGP skickar nämligen den bästa routen till en annan process vid namnet “IOS Routing Table Manager” (RTM). IOS RTM väljer sedan den bästa routen för en destination mellan flera olika konkurrerande källor. En route kan ju som du bör veta vid det här laget även läras via IGP/BGP/Connected/Static route. IOS samlar den bästa routen från varje process och skickar detta vidare till RTM som sedan i sin tur väljer vilken route som är bäst. För att lyckas med detta används “Administrative Distance” (detta borde du verkligen kunna om du läst CCNA ;)..)

  • Connected – AD 0
  • Static – AD 1
  • EIGRP Summary route – AD 5
  • BGP – AD 20
  • EIGRP (internal) – AD 90
  • IGRP – AD 100
  • OSPF – AD 110
  • ISIS – AD 115
  • RIP – AD 120
  • ODR (On-Demand Routing) – AD 160
  • EIGRP (External) – AD 170
  • iBGP – AD 200
  • Unreachable – AD 255

I de flesta fall borde vi aldrig se en route vi lärt oss via BGP även finns i vår IGP-process eller som Connected (detta blir mer ett problem när vi senare börjar grotta ner oss i MPLS VPNs med BGP/IGP-redistribution). Men hur som helst, OM det skulle hända så finns det ett inbyggt kommando som kan vara bra att känna till – sh ip bgp rib-failures.

Om vi går tillbaka och kollar R2’s BGP-table igen från föregående exempel:

bgp localpreference2

En sh ip bgp rib-failures visar följande:

R2#sh ip bgp rib-failure 
Network Next Hop RIB-failure RIB-NH Matches
200.0.0.0 1.1.1.1 Higher admin distance n/a
200.0.1.0 1.1.1.1 Higher admin distance n/a
200.0.2.0 1.1.1.1 Higher admin distance n/a
200.0.3.0 1.1.1.1 Higher admin distance n/a

Detta listar routes som BGP anser vara bäst, men som RTM valt att ej lägga till i routing table – anledningen är tydlig här, iBGP har en AD på 200, och routern har valt att lägga till routes från en annan “källa” med lägre AD.

show ip route visar boven:

R2#sh ip route | i O E2 
O E2 200.0.0.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0
O E2 200.0.1.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0
O E2 200.0.2.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0
O E2 200.0.3.0/24 [110/1] via 172.16.12.1, 00:03:47, Serial0/0

RTM har fått information om samma routes från OSPF-processen med en AD på 110 och därför valt detta istället.

Detta orsakades på grund av ett konfigurationsfel i R1 där vi redistributade klassfulla BGP-nät in till OSPF-processen, efter att ha tagit bort detta försvann även rib-failure:

R2#sh ip bgp 
BGP table version is 86, local router ID is 2.2.2.2
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
*>i5.5.5.0/24 1.1.1.1 0 100 0 100 i
*>i6.6.6.0/24 3.3.3.3 0 100 0 200 i
*>i10.0.0.0/16 1.1.1.1 0 100 0 100 i
*>i192.168.0.0 3.3.3.3 0 150 0 200 50 i
*>i200.0.0.0 1.1.1.1 0 100 0 100 i
*>i200.0.1.0 1.1.1.1 0 100 0 100 i
*>i200.0.2.0 1.1.1.1 0 100 0 100 i
*>i200.0.3.0 1.1.1.1 0 100 0 100 i

Vackert!

BGP – Path Selection Part II & Weight

Detta blir en fortsättning på inlägget “AS_SEQ Path Attribute & Path Selection” så vi kan gå in lite mer på djupet över hur just BGPs best path selection går till.

För att bestämma vilken route som är bäst används följande kriterier i turordning tills den hittat en avgörande faktor, dvs om alla parametrar är identiska mellan två vägar för en specifik destination så är det tillslut den med lägst Router-ID som vinner. 🙂

  1. Largest Weight (cisco proprietary)
  2. Highest Local Preference
  3. Locally Originated
  4. Shortest AS Path
  5. Lowest Origin Type (i < e < ?)*
  6. Lowest MED (metric)
  7. eBGP over iBGP
  8. Lowest IGP metric to neighbor (Max. paths check – default 1)
  9. Older route
  10. Lowest Router-ID

*i = Injected from an IGP (using network-command), e = Injected from Exterior Gateway Protocol (EGP), ? = Undetermined

Det finns dock ett Steg 0 också, “Next hop: reachable?”, om routern inte kan nå den specificerade next-hop adressen kommer routern räknas som invalid.

För att lättare komma ihåg detta föreslår Cisco följande “ordramsa(?)” – N WLLA OMNI.

Ytterligare något som är bra att känna till är att Cisco särskiljer på rekommenderade metoder beroende på om vi vill modifiera “outbound”-eller “inbound”-routes.

För outbound rekommenderas:

  • Weight
  • Local Preference
  • AS_PATH

Och för inbound:

  • MED (metric)

Låt oss använda följande topologi igen och kontrollera hur valet gått till för exempelvis routen 200.0.3.0/24 i R7:

bgp AS-path

pathselection1

Först har vi weight, men vi kan se att värdet är satt till “0” för båda alternativen, ingen vinnare där med andra ord. Nästa steg är “Highest Local Preference”, men inte heller där finns det något värde satt, Tredje punkten, “Locally Originated” får vi inte heller någon match på då det är en extern route.

För fjärde punkten i listan – “Shortest AS Path”, kan vi dock se skillnad. Routen med next-hop adressen 172.16.47.4 har ett mindre AS-hopp än alternativet som går via AS200- > AS500 -> AS100. Denna route blir därför vald till “best route” och installeras i routerns routing table:

R7#sh ip route 200.0.3.0
Routing entry for 200.0.3.0/24
 Known via "bgp 50", distance 20, metric 0
 Tag 500, type external
 Last update from 172.16.47.4 05:53:45 ago
 Routing Descriptor Blocks:
 * 172.16.47.4, from 172.16.47.4, 05:53:45 ago
 Route metric is 0, traffic share count is 1
 AS Hops 2
 Route tag 500

Hur bär vi då oss åt om vi vill modifiera detta? I CCNP route räknar Cisco med att vi ska ha koll på följande fyra:

  • Weight
  • Local preference
  • AS_Path Lenght
  • MED (metric)

Vi börjar med den enklaste(?)..

Largest Weight

  • Is not a Path Attribute
  • Purpose – Identifies a single router’s best route
  • Scope – Set on inbound route Updates; influences only that one router’s choice
  • Range – 0 through 65-535 (2^16-1)
  • Which is best? – Bigger value is better
  • Default – 0 for learned routes, 32,768 for locally injected routes
  • Defining a new default – Not supported
  • Configuration – neighbor route-map (per prefix), neighbor weight (all routes from this neighbor)

Detta option är “Cisco proprietary” och räknas ej som ett “Path Attribute”. Vi behöver dock inte bry oss i om våra neighbors också använder Cisco’s hårdvara då Weight endast används lokalt! Om vi använder oss av samma topologi återigen, låt oss säga att vi hellre föredrar att trafiken från R7 tar den längre vägen via AS200 -> AS500 -> AS100 (då vi kanske har en snabbare uppkoppling mellan de kontoren). Konfigurationen blir då följande:

R7(config)#router bgp 50
R7(config-router)#neighbor 172.16.76.6 weight ?
 <0-65535> default weight
R7(config-router)#neighbor 172.16.76.6 weight 5
R7(config-router)#end
R7#clear ip bgp *

Kom ihåg att vi behöver starta om BGP-processen!

Detta leder till följande resultat:

pathselection-weight

R7 föredrar nu att gå via R6 trots att det är ett AS-hopp mer än direkt via R4/AS500.

Hur gör vi då om vi endast vill modifiera detta för en/flera specifika routes och inte alla? Route-maps! Vi tar bort ändringen ovan och försöker istället utföra samma sak men endast för routen 200.0.3.0/24.

Som du säkert gissat behöver vi först skapa en access-lista:

access-list 1 permit 200.0.3.0

Och sedan en route-map:

route-map WEIGHT-FILTER permit 10
match ip address 1
set weight 10

Vi applicerar sedan route-map:en i vårat neighbor-statement(!)

router bgp 50
neighbor 172.16.76.6 route-map WEIGHT-FILTER in
do clear ip bgp *

That’s it, detta ger följande resultat:

route-map weight

Fast vänta lite nu.. Jämför detta med det resultat vi fick innan vi applicerade route-mapen ovan. Vi saknar nu de alternativa vägarna för näten 5.5.5.0/24, 6.6.6.0/24 & 200.0.2.0/24! Du kanske redan listat ut varför det blir såhär, om inte föreslår jag att du tar en paus och försöker lösa det på egen hand innan du läser vidare.

I den access-lista vi skapade matchade vi endast nätet 200.0.3.0/24, så det är kanske inte så konstigt att vi endast ser detta nätet nu. Men vi kan ju inte gärna lägga till resterande nät i acl:en då vi endast ville ändra weight för 200.0.3.0?

Svaret ligger i route-map:en! Just nu har vi ju följande konfiguration:

access-list 1 permit 200.0.3.0
!
route-map WEIGHT-FILTER permit 10
match ip address 1
set weight 10

Det finns ju bevisligen inget statement för de övriga näten. Vi fixar detta enkelt med att skapa ett match-any statement som tillåter allt!

route-map WEIGHT-FILTER permit 20

Vi behöver inget match-statement då vi vill tillåta allt som inte redan matchats under sequence 10/ACL 1. Vi kör återigen en clear ip bgp * och håller tummarna..

route-map weight2

Kungligt! Nästa inlägg blir en fortsättning på samma ämne men då kollar vi istället på Local Preference & AS PATH_LENGHT.