OSPF – Path Selection with Non-Backbone Transit Areas

Pretty much done with EIGRP labs for now and started with OSPF instead where I found a really interesting lab regarding using non-backbone areas as transit. The traffic really didn’t behave the way I “thought” it should based on what i’ve read earlier, the lab looked like this:

Requirements

  • Disable the link between R3 & R7 and make sure traffic in area 2 still can reach the rest of the network
  • Modify SPF calculations so that R4 can’t be used for transit traffic in area 1 to area 0, don’t use cost
  • Traffic from R9 should route via R1 to reach R8

By disabling the link between R3 – R7 traffic in area 2 will be separated from the rest of the network as traffic isn’t allowed to pass via another non-backbone area. We can verify this in R7 as it shouldn’t consider R6 an ABR.

R7#sh ip ospf border-routers

OSPF Router with ID (150.1.7.7) (Process ID 1)

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

Checking the OSPF database we still see R3’s LSAs until they age out, but no summary-routes (LSA Type 3) are advertised from R6.

R7#sh ip ospf database

OSPF Router with ID (150.1.7.7) (Process ID 1)

Router Link States (Area 2)

Link ID ADV Router Age Seq# Checksum Link count
150.1.3.3 150.1.3.3 262 0x80000002 0x002840 1
150.1.6.6 150.1.6.6 182 0x80000003 0x0073AA 1
150.1.7.7 150.1.7.7 181 0x80000005 0x00DD03 5
150.1.9.9 150.1.9.9 254 0x80000002 0x008AF8 3

Net Link States (Area 2)

Link ID ADV Router Age Seq# Checksum
155.1.67.6 150.1.6.6 182 0x80000001 0x00C5A1
155.1.79.9 150.1.9.9 255 0x80000001 0x003517

Summary Net Link States (Area 2)

Link ID ADV Router Age Seq# Checksum
150.1.1.1 150.1.3.3 269 0x80000001 0x00B973
150.1.2.2 150.1.3.3 269 0x80000001 0x00A486
150.1.3.3 150.1.3.3 319 0x80000001 0x0028D8
150.1.4.4 150.1.3.3 269 0x80000001 0x0051C0
150.1.5.5 150.1.3.3 279 0x80000001 0x0032DE
150.1.6.6 150.1.3.3 253 0x80000002 0x002FDC
150.1.8.8 150.1.3.3 248 0x80000001 0x00FC0D
150.1.10.10 150.1.3.3 244 0x80000001 0x00DC28
155.1.0.1 150.1.3.3 269 0x80000001 0x0079B0
155.1.0.2 150.1.3.3 269 0x80000001 0x006FB9
155.1.0.3 150.1.3.3 309 0x80000001 0x00FD02
155.1.0.4 150.1.3.3 269 0x80000001 0x0032DF
155.1.0.5 150.1.3.3 279 0x80000001 0x001EF3
155.1.5.0 150.1.3.3 279 0x80000001 0x0023ED
155.1.8.0 150.1.3.3 248 0x80000001 0x000C01
155.1.10.0 150.1.3.3 244 0x80000001 0x00FF0A
155.1.13.0 150.1.3.3 319 0x80000001 0x00965E
155.1.23.0 150.1.3.3 319 0x80000001 0x0028C2
155.1.45.0 150.1.3.3 279 0x80000001 0x00697F
155.1.58.0 150.1.3.3 279 0x80000001 0x00D902
155.1.108.0 150.1.3.3 248 0x80000001 0x00BBEC
155.1.146.0 150.1.3.3 269 0x80000001 0x00186A

We solve this by setting up a virtual link between R6 & R1, remember we’re not supposed to send area 2’s traffic to R4.

! R6

router ospf 1
 area 1 virtual-link 150.1.1.1

! R1

router ospf 1
 area 1 virtual-link 150.1.6.6

R6 will now have a virtual connection to area 0 and can now act as an ABR to area 2.

R6#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
150.1.1.1 0 FULL/ - - 155.1.146.1 OSPF_VL0
150.1.1.1 1 FULL/DROTHER 00:00:35 155.1.146.1 GigabitEthernet1.146
150.1.4.4 1 FULL/BDR 00:00:37 155.1.146.4 GigabitEthernet1.146
150.1.7.7 1 FULL/BDR 00:00:31 155.1.67.7 GigabitEthernet1.67

R6#sh ip ospf interface 
OSPF_VL0 is up, line protocol is up 
Internet Address 155.1.146.6/24, Area 0, Attached via Not Attached
Process ID 1, Router ID 150.1.6.6, Network Type VIRTUAL_LINK, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Configured as demand circuit
Run as demand circuit
DoNotAge LSA allowed
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:08
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Can not be protected by per-prefix Loop-Free FastReroute
Can not be used for per-prefix Loop-Free FastReroute repair paths
Index 1/1/4, flood queue length 0
Next 0x0(0)/0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 1, Adjacent neighbor count is 1 
Adjacent with neighbor 150.1.1.1 (Hello suppressed)
Suppress hello for 1 neighbor(s)
R6#sh ip ospf database self-originate

OSPF Router with ID (150.1.6.6) (Process ID 1)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count
150.1.6.6 150.1.6.6 739 0x80000003 0x00F126 1

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum
150.1.6.6 150.1.6.6 739 0x80000002 0x00BF34
150.1.7.7 150.1.6.6 739 0x80000002 0x00B43C
150.1.9.9 150.1.6.6 739 0x80000002 0x009457
155.1.7.0 150.1.6.6 739 0x80000002 0x00B939
155.1.9.0 150.1.6.6 739 0x80000002 0x00AD42
155.1.37.0 150.1.6.6 739 0x80000002 0x006E66
155.1.67.0 150.1.6.6 739 0x80000002 0x00199E
155.1.79.0 150.1.6.6 739 0x80000002 0x009E0C
155.1.146.0 150.1.6.6 739 0x80000002 0x00B0B7

R7 now see’s R6 as an ABR which in turn will send summary-LSAs for the rest of the network.

R7#sh ip ospf border-routers

OSPF Router with ID (150.1.7.7) (Process ID 1)

Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 150.1.6.6 [1] via 155.1.67.6, GigabitEthernet1.67, ABR, Area 2, SPF 6

R7#sh ip ospf database | beg Summary
Summary Net Link States (Area 2)

Link ID ADV Router Age Seq# Checksum
150.1.1.1 150.1.3.3 814 0x80000001 0x00B973
150.1.1.1 150.1.6.6 311 0x80000001 0x0035C8
150.1.2.2 150.1.3.3 814 0x80000001 0x00A486
150.1.2.2 150.1.6.6 306 0x80000002 0x005CB1
150.1.3.3 150.1.3.3 864 0x80000001 0x0028D8
150.1.3.3 150.1.6.6 306 0x80000002 0x0047C4
150.1.4.4 150.1.3.3 814 0x80000001 0x0051C0
150.1.4.4 150.1.6.6 306 0x80000002 0x00F303
150.1.5.5 150.1.3.3 824 0x80000001 0x0032D
....

R7#sh ip route 150.1.8.8
Routing entry for 150.1.8.8/32
Known via "ospf 1", distance 110, metric 5, type inter area
Last update from 155.1.67.6 on GigabitEthernet1.67, 00:06:17 ago
Routing Descriptor Blocks:
* 155.1.67.6, from 150.1.6.6, 00:06:17 ago, via GigabitEthernet1.67
Route metric is 5, traffic share count is 1

Even if we enable R3’s link to R7 now the traffic will still prefer the route via R6 as it has a lower metric to R8, indifferent to the fact that a virtual-link is needed to traverse that area.

R7#sh ip ospf database summary 150.1.8.8

OSPF Router with ID (150.1.7.7) (Process ID 1)

Summary Net Link States (Area 2)

LS age: 976
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.8.8 (summary Network Number)
Advertising Router: 150.1.3.3
LS Seq Number: 80000001
Checksum: 0xFC0D
Length: 28
Network Mask: /32
MTID: 0 Metric: 1002

LS age: 493
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.8.8 (summary Network Number)
Advertising Router: 150.1.6.6
LS Seq Number: 80000001
Checksum: 0xB538
Length: 28
Network Mask: /32
MTID: 0 Metric: 4

By checking the metric you may already have realized how the traffic is currently flowing to R8 which was a surprise to myself. By setting up a virtual-link between R6 & R1 I thought that the transit traffic from area 2 would also route that way. But no, not at all!

R7#traceroute 150.1.8.8 numeric 
Type escape sequence to abort.
Tracing the route to 150.1.8.8
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.67.6 7 msec 3 msec 4 msec
2 155.1.146.4 5 msec 5 msec 5 msec
3 155.1.45.5 6 msec 6 msec 6 msec
4 155.1.58.8 6 msec * 6 msec

How come? Let’s dive in to R6’s database.

R6#sh ip ospf database summary 150.1.8.8

OSPF Router with ID (150.1.6.6) (Process ID 1)

Summary Net Link States (Area 0)

LS age: 484 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 150.1.8.8 (summary Network Number)
Advertising Router: 150.1.5.5
LS Seq Number: 80000001
Checksum: 0xAE43
Length: 28
Network Mask: /32
MTID: 0 Metric: 2

So R5 is the ABR originating the summary-LSA with a metric of 2, so what is R6’s preferred path to R5?

R6# sh ip ospf database router 150.1.5.5

OSPF Router with ID (150.1.6.6) (Process ID 1)

Router Link States (Area 0)

LS age: 501 (DoNotAge)
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 150.1.5.5
Advertising Router: 150.1.5.5
LS Seq Number: 80000004
Checksum: 0x56B2
Length: 108
Area Border Router
Number of Links: 7

Link connected to: a Stub Network
(Link ID) Network/subnet number: 150.1.5.5
(Link Data) Network Mask: 255.255.255.255
Number of MTID metrics: 0
TOS 0 Metrics: 1

Link connected to: a Transit Network
(Link ID) Designated Router address: 155.1.45.5
(Link Data) Router Interface address: 155.1.45.5
Number of MTID metrics: 0
TOS 0 Metrics: 1

 Link connected to: another Router (point-to-point)
(Link ID) Neighboring Router ID: 150.1.4.4
(Link Data) Router Interface address: 155.1.0.5
Number of MTID metrics: 0
TOS 0 Metrics: 1000

Traffic is going directly from R6 to R4 even though that it isn’t R6s virtual-link to area 0! This functionality is further explained in RFC 2328 section 16.3, examining transit area’s summary-LSAs.

16.3.  Examining transit areas' summary-LSAs

        This step is only performed by area border routers attached to
        one or more non-backbone areas that are capable of carrying
        transit traffic (i.e., "transit areas", or those areas whose
        TransitCapability parameter has been set to TRUE in Step 2 of
        the Dijkstra algorithm (see Section 16.1).

        The purpose of the calculation below is to examine the transit
        areas to see whether they provide any better (shorter) paths
        than the paths previously calculated in Sections 16.1 and 16.2.
        Any paths found that are better than or equal to previously
        discovered paths are installed in the routing table.

Apparently the parameter TransitCapability is on by default in all cisco-routers, which results in R6 preferring the route via R4 as it has lower metric even though the route is passing a non-backbone area. This functionality can be disabled however and that is also how we solve the labs requirement that traffic has to pass via R1.

! R6

router ospf 1
no capability transit

R6’s metric to R8 is updated to reflect the new path via R1:

R6#sh ip route 150.1.8.8
Routing entry for 150.1.8.8/32
Known via "ospf 1", distance 110, metric 1003, type inter area
Last update from 155.1.146.1 on GigabitEthernet1.146, 00:00:25 ago
Routing Descriptor Blocks:
* 155.1.146.1, from 150.1.5.5, 00:00:25 ago, via GigabitEthernet1.146
Route metric is 1003, traffic share count is 1

R6#traceroute 150.1.8.8
Type escape sequence to abort.
Tracing the route to 150.1.8.8
VRF info: (vrf in name/id, vrf out name/id)
1 155.1.146.1 5 msec 4 msec 4 msec
2 155.1.146.4 5 msec 5 msec 5 msec
3 155.1.45.5 7 msec 6 msec 7 msec
4 155.1.58.8 7 msec * 7 msec

Very interesting! Even though it’s uses may be very specific and not commonly used in the “real world” it feels like it certainly can be something that they throw at you at the CCIE-exam.

 

MPLS & MP-BGP Del 2

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

Customer-MPLS

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

NL PE KistaRed

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

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

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

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

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

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

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

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

NL PE KistaRed

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

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

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

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

NLKista-Edge

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

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

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

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

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

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

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

Traceroute mellan Kista- & Kiruna-kontoret:

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

Routing-tabellen för Kista-kontoret:

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

PE

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

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

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

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