VRF-Lite & BGP

Tänkte skriva ett kortare inlägg om ett rätt intressant problem jag stötte på tidigare vilket löstes med hjälp av VRF-Lite och lite trixande med BGP. Topologin som önskades var enligt följande:

lightvrf

Länken mot ISP-1 önskades vara primär pga bättre serviceavtal & bandbredd samtidigt som länken till ISP-2 endast skulle användas som backup. Både ISP-1 & 2 genererar en default-route samt annonserar varsitt 10.x.0.0/23-nät. Det fanns även önskemål att AS #666 skulle agera transit mellan ISP-1 & 2.

lightvrfigp

Som IGP användes EIGRP inom AS #666 samt mellan R1 – ISP-1 och OSPF mellan R3 – ISP-2 där respektive länknät redistributas. Detta är egentligen helt onödigt men användes för att göra uppgiften lite mer komplicerad bara. 🙂

Problematiken var dock att ISP-1 & ISP-2 består av en och samma router! Den fysiska topologin ser nämligen ut enligt följande:

lightvrftopologi

Med andra ord behöver vi dela upp R1 till två virtuella routrar med separata routing tables & bgp-adjacencys. Detta löser vi med hjälp av VRF-Lite! 🙂

Låt oss ta och kika lite närmare på konfigen för respektive router.

R2

interface Serial1/0
 ip address 12.0.0.2 255.255.255.252
 description Primary uplink to ISP-1
 no shut
interface Loopback3
 description For testing
 ip address 172.32.0.1 255.255.255.0
 no shut
interface Loopback4
 description For testing
 ip address 172.32.1.1 255.255.255.0
 no shut

interface FastEthernet0/0
 description to MLS1
 ip address 172.16.11.11 255.255.255.0
 ip hello-interval eigrp 101 2
 ip hold-time eigrp 101 6
 ip authentication mode eigrp 1 md5
 ip authentication key-chain eigrp 1 s3cr3t
 ip summary-address eigrp 101 172.32.0.0 255.255.254.0 5
 duplex full
 speed 100
 no shut

IGP-konfig

Då vi endast vill redistributa in länknätet mellan R1 & ISP-1 till EIGRP 101 använde jag en en route-map, passade även på att tagga route’sen om vi skulle behöva utföra någon filtrering senare.

!Internal IGP-routing
router eigrp 101
 redistribute eigrp 666 route-map EIGRP666-EIGRP101
 passive-interface default
 no passive-interface FastEthernet0/1
 network 172.16.0.0
 network 172.32.0.0 0.0.0.255
 network 172.32.1.0 0.0.0.255
 no auto-summary
 eigrp router-id 172.16.99.11

ip prefix-list EIGRP666-EIGRP101 seq 5 permit 12.0.0.0/30

route-map EIGRP666-EIGRP101 permit 10
 match ip address prefix-list EIGRP666-EIGRP101
 set metric 100000 100 255 1 1500
 set tag 1666

route-map EIGRP666-EIGRP101 deny 20

!External IGP routing ISP-1
router eigrp 666
 passive-interface default
 no passive-interface Serial1/0
 network 12.0.0.0 0.0.0.3
 no auto-summary

BGP

Inga konstigheter här, peer-groups för lite mer “kompakt” konfig.

router bgp 666
 no synchronization
 bgp log-neighbor-changes
 network 172.16.0.0
 network 172.32.0.0 mask 255.255.254.0
 redistribute eigrp 666

 neighbor 12.0.0.1 remote-as 65001
 neighbor 12.0.0.1 description ISP-1

 neighbor IBGP peer-group
 neighbor IBGP remote-as 666
 neighbor IBGP next-hop-self
 neigbhor IBGP password s3cr3t

 neighbor 172.16.11.1 peer-group IBGP
 neighbor 172.16.11.1 description MLS1
 neighbor 172.16.13.3 peer-group IBGP
 neighbor 172.16.13.3 description MLS2
 neighbor 172.16.33.33 peer-group IBGP
 neighbor 172.16.33.33 description R3
 no auto-summary

Konfigen är mer eller mindre identisk för R3.

Default-route

Som nämndes tidigare önskades företaget att vi använda denna länk som primär, både ISP-1 & 2 genererade varsin default-route. Att ändra local pref för samtliga routes vi lär oss från ISP-1 hade inte varit något hit då det även skulle påverka trafik vi är transit för. Tänkte istället använda en route-map som sätter en högre local pref endast för default-routen. Vi behöver även se till så att vi ej annonserar default-routen vidare utanför vårat AS.

R2

router bgp 666
 neighbor 12.0.0.1 prefix-list DEFAULT-ROUTE-BLOCK out
 neighbor 12.0.0.1 route-map ISP1-routes in

ip prefix-list DEFAULT-ROUTE-BLOCK seq 5 deny 0.0.0.0/0
ip prefix-list DEFAULT-ROUTE-BLOCK seq 10 permit 0.0.0.0/0 le 32

ip prefix-list default-route seq 5 permit 0.0.0.0/0

route-map ISP1-routes permit 10
 match ip address prefix-list default-route
 set local-preference 150

route-map ISP1-routes permit 20

R3

router bgp 666
 neighbor 13.0.0.1 prefix-list DEFAULT-ROUTE-BLOCK out
 neighbor 13.0.0.1 route-map ISP2-routes in

ip prefix-list DEFAULT-ROUTE-BLOCK seq 5 deny 0.0.0.0/0
ip prefix-list DEFAULT-ROUTE-BLOCK seq 10 permit 0.0.0.0/0 le 32

ip prefix-list default-route seq 5 permit 0.0.0.0/0

route-map ISP2-routes permit 10
 match ip address prefix-list default-route
 set local-preference 110

route-map ISP2-routes permit 20

Vilket ger följande resultat:

R3#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 4
Paths: (2 available, best #1, table Default-IP-Routing-Table)
 Not advertised to any peer
 65001
  172.16.11.11 (metric 30720) from 172.16.11.11 (172.32.1.1)
   Origin IGP, metric 0, localpref 150, valid, internal, best
 65002
  13.0.0.1 from 13.0.0.1 (2.2.2.2)
   Origin IGP, metric 0, localpref 100, valid, external

VRF-Lite / R1

Nu över till det lite roligare. 🙂 VRF:er har vi ju redan konfat i flera tidigare inlägg, så detta är väl inte direkt något nytt men själva användningsområdet  är något jag aldrig stött på tidigare.

interface Loopback1
 ip vrf forwarding ISP-1
 ip address 10.1.0.1 255.255.255.0

interface Loopback2
 ip vrf forwarding ISP-1
 ip address 10.1.1.1 255.255.255.0

interface Loopback3
 ip vrf forwarding ISP-2
 ip address 10.2.0.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

interface Loopback4
 ip vrf forwarding ISP-2
 ip address 10.2.1.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0

interface Loopback5
 ip vrf forwarding Shared
 ip address 1.1.1.1 255.255.255.255

interface Loopback6
 ip vrf forwarding Shared
 ip address 2.2.2.2 255.255.255.255

interface Loopback11
description Management - RID
ip address 11.11.11.11 255.255.255.255

interface Serial0/0/0
 description ISP-1 to CustomerA-R1
 ip vrf forwarding ISP-1
 ip address 12.0.0.1 255.255.255.252
 ip summary-address eigrp 666 10.1.0.0 255.255.254.0 5

interface Serial0/0/1
 description ISP-2 to CustomerA-R3
 ip vrf forwarding ISP-2
 ip address 13.0.0.1 255.255.255.252
 ip ospf 1 area 666

Vi konfar först upp några VRF-instanser, shared simulerar i detta fallet externa routes/internet. La även till en export-map för att endast exportera 1.1.1.1/32 och 2.2.2.2/32 från Shared till ISP-1 & ISP-2 vrf:erna.

ip vrf ISP-1
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:1

ip vrf ISP-2
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:2

ip vrf Shared
 rd 65000:3
 export map ISP-Loopback-Inject
 route-target export 65000:3
 route-target import 65000:3
 route-target import 65000:1
 route-target import 65000:2

route-map ISP-Loopback-Inject permit 10
 match ip address prefix-list ISP-1
 set extcommunity rt 65000:1 additive

route-map ISP-Loopback-Inject permit 20
 match ip address prefix-list ISP-2
 set extcommunity rt 65000:2 additive

route-map ISP-Loopback-Inject deny 30

IGP

Då vi använder oss av vrf:er måste vi även justera våra IGP-instanser precis som tidigare.

router eigrp 666
 passive-interface default
 no passive-interface Serial0/0/0
 no auto-summary

 address-family ipv4 vrf ISP-1
  network 10.1.0.0 0.0.0.255
  network 10.1.1.0 0.0.0.255
  network 12.0.0.0 0.0.0.3
  no auto-summary
  autonomous-system 666
  exit-address-family
 eigrp router-id 1.1.1.1

router ospf 1 vrf ISP-2
 router-id 2.2.2.2
 log-adjacency-changes
 area 0 range 10.2.0.0 255.255.254.0
 passive-interface default
 no passive-interface Serial0/0/1

BGP

Här stöter vi på ett litet problem då vi endast kan ha en aktiv BGP-instans, dvs skriver vi “router bgp 65001” kan vi ej konfa upp “router bgp 65002” för ISP-2 efteråt.

BGP har ju dock som bekant en hel del roliga funktioner vi kan använda oss av, och i detta fall kan vi lösa problemet med hjälp av “local-as“, “no-prepend” & “replace-as“. Klicka på respektive för mer info, Lostintransit.se har även en läsvärd artikel om detta här!

router bgp 65000
 no synchronization
 bgp log-neighbor-changes
 no auto-summary

 address-family ipv4 vrf Shared
  redistribute connected
  no synchronization
  exit-address-family

 address-family ipv4 vrf ISP-2
  neighbor 13.0.0.2 remote-as 666
  neighbor 13.0.0.2 local-as 65002 no-prepend replace-as
  neighbor 13.0.0.2 activate
  neighbor 13.0.0.2 default-originate
  no synchronization
  bgp router-id 2.2.2.2
  network 10.2.0.0 mask 255.255.255.0
  network 10.2.1.0 mask 255.255.255.0
  aggregate-address 10.2.0.0 255.255.254.0 summary-only
  exit-address-family

 address-family ipv4 vrf ISP-1
  neighbor 12.0.0.2 remote-as 666
  neighbor 12.0.0.2 local-as 65001 no-prepend replace-as
  neighbor 12.0.0.2 activate
  neighbor 12.0.0.2 default-originate
  no synchronization
  bgp router-id 1.1.1.1
  network 10.1.0.0 mask 255.255.255.0
  network 10.1.1.0 mask 255.255.255.0
  aggregate-address 10.1.0.0 255.255.254.0 summary-only
  exit-address-family

Vilket ger följande resultat:

R1#sh ip bgp neighbors 12.0.0.1
 BGP neighbor is 12.0.0.1, remote AS 65001, external link
 BGP version 4, remote router ID 1.1.1.1
 BGP state = Established, up for 00:45:25
 Last read 00:00:16, last write 00:00:31, hold time is 180, keepalive interval is 60 seconds

R3#sh ip bgp neighbors 13.0.0.1
 BGP neighbor is 13.0.0.1, remote AS 65002, external link
 BGP version 4, remote router ID 2.2.2.2
 BGP state = Established, up for 00:46:18
 Last read 00:00:05, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds

R2#sh ip bgp vpnv4 vrf ISP-1
 BGP table version is 60, 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
 Route Distinguisher: 65000:1 (default for vrf ISP-1) VRF Router ID 1.1.1.1
 *> 1.1.1.1/32 0.0.0.0 0 32768 ?
 *> 2.2.2.2/32 12.0.0.2 0 666 65002 ?
 s> 10.1.0.0/24 0.0.0.0 0 32768 i
 r> 10.1.0.0/23 0.0.0.0 32768 i
 s> 10.1.1.0/24 0.0.0.0 0 32768 i
 *> 10.2.0.0/23 12.0.0.2 0 666 65002 i
 *> 13.37.0.0/16 0.0.0.0 0 32768 ?
 *> 172.16.0.0 12.0.0.2 28416 0 666 i
 *> 172.32.0.0/23 12.0.0.2 128256 0 666 i

R2#sh ip bgp vpnv4 vrf ISP-1
 BGP table version is 60, 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
 Route Distinguisher: 65000:1 (default for vrf ISP-1) VRF Router ID 1.1.1.1
 *> 1.1.1.1/32 0.0.0.0 0 32768 ?
 *> 2.2.2.2/32 12.0.0.2 0 666 65002 ?
 s> 10.1.0.0/24 0.0.0.0 0 32768 i
 r> 10.1.0.0/23 0.0.0.0 32768 i
 s> 10.1.1.0/24 0.0.0.0 0 32768 i
 *> 10.2.0.0/23 12.0.0.2 0 666 65002 i
 *> 13.37.0.0/16 0.0.0.0 0 32768 ?
 *> 172.16.0.0 12.0.0.2 28416 0 666 i
 *> 172.32.0.0/23 12.0.0.2 128256 0 666 i

Vi kan även verifiera att vår transit fungerar som önskat, ISP-1 har följande information för 2.2.2.2/32 som ligger på samma router men under ISP-2s VRF.

R2#sh ip bgp vpnv4 vrf ISP-1 2.2.2.2/32
 BGP routing table entry for 65000:1:2.2.2.2/32, version 50
 Paths: (1 available, best #1, table ISP-1)
 Not advertised to any peer
 666 65002
 12.0.0.2 from 12.0.0.2 (172.16.99.11)
 Origin incomplete, localpref 100, valid, external, best
 Extended Community: RT:65000:1
 mpls labels in/out 31/nolabel

Vackert! VRF-Lite ger oss ett enkelt sätt att segmentera upp en router om vi exempelvis måste separera två avdelningar från varandra som ansluter till en och samma router. Fler läsvärda artiklar om detta finns här:

http://packetlife.net/blog/2009/apr/30/intro-vrf-lite/

Inter-VRF routing using VRF-lite

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

BGP – Route Redistribution & Filtering

bgp AS-path

Här kommer ett enkelt exempel på hur vi utför redistribution & filtrering in till BGP (som egentligen inte skiljer sig något från de övriga protokollen som vi redan labbat med). Låt oss säga att vi vill redistributa näten 200.0.2.0/24 & 200.0.3.0/24 från R5 in till BGP.

Vi skapar först en access-lista (eller prefix-list):

access-list 1 permit 200.0.2.0
access-list 1 permit 200.0.3.0

Sedan en route-map:

route-map FILTER permit 10
match ip address 1

Vi går sedan in under BGP-processen och aktiverar redistribute men filtrerar med hjälp av vår route-map.

router bgp 100
redistribute connected route-map FILTER

Easy peasy.. Vi kan nu se förändringen i exempelvis R7:

R7#sh ip bgp
BGP table version is 15, local router ID is 192.168.0.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
* 5.5.5.0/24 172.16.76.6 0 200 500 100 i
*> 172.16.47.4 0 500 100 i
*> 6.6.6.0/24 172.16.76.6 0 0 200 i
* 172.16.47.4 0 500 200 i
*> 192.168.0.0 0.0.0.0 0 32768 i
* 200.0.2.0 172.16.76.6 0 200 500 100 ?
*> 172.16.47.4 0 500 100 ?
* 200.0.3.0 172.16.76.6 0 200 500 100 ?
*> 172.16.47.4 0 500 100 ?
R7#sh ip route | beg Gat
Gateway of last resort is not set
5.0.0.0/24 is subnetted, 1 subnets
B 5.5.5.0 [20/0] via 172.16.47.4, 00:20:19
 6.0.0.0/24 is subnetted, 1 subnets
B 6.6.6.0 [20/0] via 172.16.76.6, 00:19:48
B 200.0.2.0/24 [20/0] via 172.16.47.4, 00:06:16
 172.16.0.0/24 is subnetted, 2 subnets
C 172.16.47.0 is directly connected, FastEthernet0/0
C 172.16.76.0 is directly connected, FastEthernet0/1
B 200.0.3.0/24 [20/0] via 172.16.47.4, 00:06:16
C 192.168.0.0/24 is directly connected, Loopback0

Redistribution – Expert Lab

Tänkte ta mig an labben jag nämnde i föregående inlägg från Petr Lapukhov.

Topologin är följande:

expert redistribution

EIGRP AS 123 has been preconfigured on router BabyDoll,SweetPea and Rocket.

  • OSPF Area 0 (Process 234) has been preconfigured on router SweetPea, Rocket and Blondie.
  • EIGRP AS 356 has been preconfigured on router Rocket, BlueJones and Amber.
  • RIP Version 2 has been preconfigured on router Blondie, Amber and WiseMan.
  • Router BabyDoll’s loopback0 interface is advertised in EIGRP AS123.
  • Router SweetPea’s, Blondie’s and Rocket’s loopback0 interfaces are advertised in OSPF Area 0.
  • Router Amber’s and BlueJones’s loopback0 interfaces are advertised in EIGRP AS356.
  • Router WiseMan’s loopback0 interface is advertised in RIPV2.
  • Configure 2-way redistribution on router SweetPea and Rocket between EIGRP AS123 and OSPF.
  • Configure redistribution on router Rocket between EIGRP AS356 and OSPF.
  • Configure redistribution on router Blondie between RIPV2 and OSPF.
  • Ensure you have full connectivity at this moment, every network / loopback should be reachable from any device.

Själva konfigureringen gick smärtfritt och borde inte ställa till några problem vid det här laget.

Troubleshooting:

  1. Remove the “network 1.0.0.0” command on router BabDoll and replace it by redistributing the loopback0 interface into EIGRP AS123.
  2. Do a traceroute from router SweetPea and Rocket to 1.1.1.1, you notice packets are sent through the OSPF network. Ensure they take the most optimal route to the destination.
  3. Ensure all traffic will be sent using the FastEthernet links. The Frame-Relay links should only be used as a backup when the FastEthernet links are down.

Steg 1 & 2

Easy stuff, konfade följande:

BabyDoll(config-router)#no network 1.0.0.0
BabyDoll(config-router)#redistribute connected

En show ip route från SweetPea & Rocket visar dock följande:

SweetPea

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:02:08, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
 3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.234.3, 00:31:32, Serial1/0
O E2 192.168.45.0/24 [110/20] via 192.168.234.4, 00:31:32, Serial1/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.234.4, 00:31:33, Serial1/0
 5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [110/20] via 192.168.234.3, 00:31:33, Serial1/0
 6.0.0.0/24 is subnetted, 1 subnets
O E2 6.6.6.0 [110/20] via 192.168.234.3, 00:31:37, Serial1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [110/20] via 192.168.234.4, 00:31:38, Serial1/0
C 192.168.234.0/24 is directly connected, Serial1/0
O E2 192.168.35.0/24 [110/20] via 192.168.234.3, 00:31:38, Serial1/0

Rocket

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
O E2 1.1.1.0 [110/20] via 192.168.234.2, 00:14:50, Serial2/0
 2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [110/65] via 192.168.234.2, 00:44:09, Serial2/0
 3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
O E2 192.168.45.0/24 [110/20] via 192.168.234.4, 00:44:09, Serial2/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.234.4, 00:44:10, Serial2/0
 5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/156160] via 192.168.35.5, 00:54:56, FastEthernet1/0
 6.0.0.0/24 is subnetted, 1 subnets
D 6.6.6.0 [90/156160] via 192.168.35.6, 00:54:57, FastEthernet1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [110/20] via 192.168.234.4, 00:44:11, Serial2/0
C 192.168.234.0/24 is directly connected, Serial2/0
C 192.168.35.0/24 is directly connected, FastEthernet1/0

Så Sweetpea tar för tillfället rätt väg direkt till R1, men Rocket går via OSPF/Frame-Relay switchen -> R2 -> R1 – suboptimal routing!

Varför det blir såhär har vi gått igenom många gånger tidigare, OSPF har lägre AD än vad EIGRP har, så Rocket ersätter sin egna route med den SweetPea annonserar.  Vi testar med en enkel lösning först och höjer AD för OSPFs externa routes.

router ospf 234
distance ospf external 180

Vi konfar detta på både SweetPea & Rocket, de använder nu routen som annonseras av EIGRP istället och går direkt till R1.

1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:03:58, FastEthernet0/0

Detta leder dock till rätt konstiga problem för andra nät! Om vi kör en sh ip route på SweetPea visas följande:

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:07:03, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
 3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [110/65] via 192.168.234.3, 00:07:03, Serial1/0
D EX 192.168.45.0/24 
 [170/1709312] via 192.168.123.3, 00:07:01, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [110/65] via 192.168.234.4, 00:07:04, Serial1/0
 5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [180/20] via 192.168.234.3, 00:07:04, Serial1/0
 6.0.0.0/24 is subnetted, 1 subnets
O E2 6.6.6.0 [180/20] via 192.168.234.3, 00:07:05, Serial1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [180/20] via 192.168.234.3, 00:06:44, Serial1/0
C 192.168.234.0/24 is directly connected, Serial1/0
O E2 192.168.35.0/24 [180/20] via 192.168.234.3, 00:07:05, Serial1/0

SweetPea tror nu att den ska gå via Rocket för att nå exempelvis 192.168.45.0.

En traceroute visar dock följande:

SweetPea#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.234.3 24 msec 24 msec 20 msec
 2 * * * 
 3 192.168.234.3 60 msec 60 msec 36 msec
 4 * * * 
 5 192.168.234.3 88 msec 124 msec 52 msec
 6 * * * 
 7 192.168.234.3 112 msec 88 msec 116 msec
 8 * * *

Kollar vi Rocket så ser vi varför det loopas:

7.0.0.0/24 is subnetted, 1 subnets
D EX 7.7.7.0 [170/1709312] via 192.168.123.2, 00:05:42, FastEthernet0/0

expert redistribution 2

SweetPea skickar till Rocket som i sin tur skickar tillbaka till SweetPea. Här körde jag fast rätt rejält och tog istället och läste Petr Lapukhovs blogg om detta, se http://blog.ine.com/2008/02/09/understanding-redistribution-part-i/. Där anger han bl.a. två regler vi alltid ska utgå ifrån:

1 – Router should always prefer internal prefix information over any external information.

2 – Split-Horizon – Never redistribute a prefix injected from domain A into B back to domain A

Han menar också att vi ska tänka på att OSPF endast är en transit-area/core, och bör således ha bäst information generellt sätt. Vi bör därför se till att den föredrar OSPFs uppdateringar istället för EIGRPs som endast används “ute i kanterna”. OSPF’s AD för interna routes är 110 som standard, EIGRP har 90. Vi behöver således sänka AD’t till <90:

router ospf 234
distance ospf intra-area 80 
distance ospf inter-area 80 
distance ospf external 160

Vi behöver ju dock få R2 & R3 att hellre använda EIGRP för 1.1.1.0/24-nätet (R1’s loopback), detta kan vi lösa genom en access-lista istället:

access-list 1 permit 1.1.1.0
router ospf 234
distance 171 0.0.0.0 255.255.255.255 1

Detta ändrar distance för den specifika routern till 171, R2 & R3 kommer således föredra EIGRP External som har 170 per default.

Kollar vi återigen sh ip route så ser det nu mycket bättre ut:

SweetPea

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:03:30, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
 3.0.0.0/24 is subnetted, 1 subnets
O 3.3.3.0 [80/65] via 192.168.234.3, 00:03:30, Serial1/0
O E2 192.168.45.0/24 [160/20] via 192.168.234.4, 00:03:30, Serial1/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [80/65] via 192.168.234.4, 00:03:30, Serial1/0
 5.0.0.0/24 is subnetted, 1 subnets
O E2 5.5.5.0 [160/20] via 192.168.234.3, 00:03:30, Serial1/0
 6.0.0.0/24 is subnetted, 1 subnets
O E2 6.6.6.0 [160/20] via 192.168.234.3, 00:03:30, Serial1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [160/20] via 192.168.234.4, 00:03:30, Serial1/0
C 192.168.234.0/24 is directly connected, Serial1/0
O E2 192.168.35.0/24 [160/20] via 192.168.234.3, 00:03:30, Serial1/0

Rocket

Gateway of last resort is not set
C 192.168.123.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
D EX 1.1.1.0 [170/156160] via 192.168.123.1, 00:03:41, FastEthernet0/0
 2.0.0.0/24 is subnetted, 1 subnets
O 2.2.2.0 [80/65] via 192.168.234.2, 00:03:41, Serial2/0
 3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0
O E2 192.168.45.0/24 [160/20] via 192.168.234.4, 00:03:41, Serial2/0
 4.0.0.0/24 is subnetted, 1 subnets
O 4.4.4.0 [80/65] via 192.168.234.4, 00:03:41, Serial2/0
 5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/156160] via 192.168.35.5, 00:03:41, FastEthernet1/0
 6.0.0.0/24 is subnetted, 1 subnets
D 6.6.6.0 [90/156160] via 192.168.35.6, 00:03:41, FastEthernet1/0
 7.0.0.0/24 is subnetted, 1 subnets
O E2 7.7.7.0 [160/20] via 192.168.234.4, 00:03:41, Serial2/0
C 192.168.234.0/24 is directly connected, Serial2/0
C 192.168.35.0/24 is directly connected, FastEthernet1/0

Vi har inte längre några routing loopar eller suboptimal routing för 1.1.1.0/24-nätet.  En traceroute till 7.7.7.7 borde således fungera nu:

SweetPea#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.234.4 48 msec 32 msec 20 msec
 2 192.168.45.7 64 msec * 24 msec
Rocket#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.234.4 36 msec 24 msec 8 msec
 2 192.168.45.7 16 msec

Stabilt!

Vi ser rätt tydligt vad farligt det kan vara att gå in och ändra AD som gäller generellt för hela routern, utan detta bör göras specifikt för det önskade nätet endast för att undvika märkliga problem.

Steg 3

Ensure all traffic will be sent using the FastEthernet links. The Frame-Relay links should only be used as a backup when the FastEthernet links are down.

Som det är i nuläget använder vi alltid OSPF som transit-area för att ta mellan näten, med ett undantag – R6 <-> R1. En sh ip route på BlueJones(R6) visar följande:

Gateway of last resort is not set
2.0.0.0/24 is subnetted, 1 subnets
D EX 2.2.2.0 [170/1709312] via 192.168.35.3, 00:13:15, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.35.3, 02:03:27, FastEthernet0/0
D EX 192.168.45.0/24 [170/1709312] via 192.168.35.3, 00:13:15, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
D EX 4.4.4.0 [170/1709312] via 192.168.35.3, 00:13:15, FastEthernet0/0
 5.0.0.0/24 is subnetted, 1 subnets
D 5.5.5.0 [90/156160] via 192.168.35.5, 02:12:26, FastEthernet0/0
 6.0.0.0/24 is subnetted, 1 subnets
C 6.6.6.0 is directly connected, Loopback0
 7.0.0.0/24 is subnetted, 1 subnets
D EX 7.7.7.0 [170/1709312] via 192.168.35.3, 00:13:16, FastEthernet0/0
D EX 192.168.234.0/24 
 [170/1709312] via 192.168.35.3, 02:03:29, FastEthernet0/0
C 192.168.35.0/24 is directly connected, FastEthernet0/0

Den ser helt enkelt inte 1.1.1.0/24-nätet. Alla andra routrar känner dock till nätet, R2 & R3 har lärt sig via EIGRP, R4  via OSPF från R1&R2, R5& R7 via RIP från R4,

Det bör ju således vara R3 eller R4’s jobb att informera R6, problemet är dock att vi endast redistributar mellan OSPF AS 234 & EIGRP 356 i Rocket. Vi löser detta genom att göra en two-way dist. mellan AS 123 & 356.

router eigrp 123
redistribute eigrp 356 metric 1500 1 255 1 1500
router eigrp 356
redistribute eigrp 123 metric 1500 1 255 1 1500
BlueJones#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
 Known via "eigrp 356", distance 170, metric 1709312, type external
 Redistributing via eigrp 356
 Last update from 192.168.35.3 on FastEthernet0/0, 00:01:15 ago
 Routing Descriptor Blocks:
 * 192.168.35.3, from 192.168.35.3, 00:01:15 ago, via FastEthernet0/0
 Route metric is 1709312, traffic share count is 1
 Total delay is 110 microseconds, minimum bandwidth is 1500 Kbit
 Reliability 255/255, minimum MTU 1500 bytes
 Loading 1/255, Hops 1

Sweet!

Advanced

Vi har nu fullt flöde genom nätet, vi har dock fortfarande kvar uppgiften att flytta “transit-arean” från OSPF till EIGRP 356. och endast använda OSPF som backup. Det är nu vi kommer till CCIE-nivån av redistribution-tekniker  här kan jag ärligt säga att jag inte lyckades hitta någon lösning som fungerade. Petr har som tur var dock gjort en bloggpost om hur olika “redistribueringsproblem” kan lösas och finns att hitta här. Kommer använda hans post som guide för att ha en chans att slutföra detta, med förhoppning att kanske om ett år så fixar jag detta på egen hand! 🙂

Det vi vill göra är att ge route’s som kommer från EIGRP356 mer “önskvärda” än de vi lär oss från OSPF & RIP. Routrarna vi behöver modifiera är därmed “border routers” (R2,R3, R4 & R5).

The OSPF and EIGRP 356 domains are both transit. That means, when redistributing from the OSPF domain to EIGRP 356 we should accept the OSPF native prefixes (per the ACLs configured above) in addition to the transit RIP and EIGRP 123 prefixes. The latter prefixes could also be injected into EIGRP 356 natively, from the respective routing domains. Therefore, when accepting the transit routes from the OSPF domain, we should give them the metric value, which makes the prefixes less preferable. For out example, we will use EIGRP metric “1 100 1 1 1” for the “non-native” injected prefixes, which is less preferable than our default “1 1 1 1 1” due to the higher “delay” component value

Vi behöver först skapa access-listor som delar upp de olika näten efter vilken “domain” de kommer ifrån.

ip access-list standard RIP_PREFIXES
 permit 192.168.45.0
 permit 7.7.7.0
ip access-list standard OSPF_PREFIXES
 permit 192.168.234.0
 permit 2.2.2.0
 permit 3.3.3.0
 permit 4.4.4.0
ip access-list standard EIGRP_123_PREFIXES
 permit 192.168.123.0
 permit 1.1.1.0
ip access-list standard EIGRP_356_PREFIXES
 permit 192.168.35.0/24
 permit 6.6.6.0
 permit 5.5.5.0
 permit 3.3.3.0

R3

Vi tar sedan och skapar route-maps, vi börjar med R3:

För OSPF till EIGRP 356:

route-map OSPF_TO_EIGRP_356 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_356 permit 20
 match ip address EIGRP_123_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_356 permit 30
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1

Vi ger med andra ord ett högre metric för RIP & OSPF-näten när de går via OSPF-domänen. genom att modifera K2-värdet till 100.

Vi måste ju dock även göra det åt andra hållet (EIGRP 356 -> OSPF):

route-map EIGRP_356_TO_OSPF permit 10
 match ip address EIGRP_356_PREFIXES
!
route-map EIGRP_356_TO_OSPF permit 20
 match ip address RIP_PREFIXES
 set metric 100

Vi behåller en låg metric för 356-näten men vi vill ju få RIP-näten mindre attraktiva. Vi behöver givetvis inte ha med EIGRP AS123 här då vi inte vill redistributa det från 356 -> OSPF.

Mellan EIGRP 356 <-> 123 modifierar vi inte metricen då de både redan använder sig av samma routing-protokoll, vi vill dock ge RIP-prefixen ett sämre metric:

route-map EIGRP_123_TO_EIGRP_356 permit 10
 match ip address EIGRP_123_PREFIXES
!
route-map EIGRP_356_TO_EIGRP_123 permit 10
match ip address EIGRP_356_PREFIXES
!
route-map EIGRP_356_TO_EIGRP_123 permit 20
match ip address RIP_PREFIXES
set metric 1 1 1 1 1

Tillsist har vi EIGRP 123 <- > OSPF kvar:

route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map EIGRP_123_TO_OSPF permit 10
match ip address EIGRP_123_PREFIXES

Vi aktiverar sedan route-mapsen via:

router ospf 234
 redistribute eigrp 356 route-map EIGRP_356_TO_OSPF subnets
 redistribute eigrp 123 route-map EIGRP_123_TO_OSPF subnets
!
router eigrp 123
 redistribute ospf 234 route-map OSPF_TO_EIGRP_123
 redistribute eigrp 356 route-map EIGRP_356_TO_EIGRP_123
!
router eigrp 356
 redistribute eigrp 123 route-map EIGRP_123_TO_EIGRP_356
 redistribute ospf 234 route-map OSPF_TO_EIGRP_356

One down.. Three to go! 🙂

R2

Här finns endast EIGRP 123 & OSPF 234 domänen. För att möjliggöra “backup”-routing via OSPF-domänen om länken till R3 går ner behöver vi även redistributa in EIGRP356 & RIP-routes till EIGRP 123. Värt att tillägga är dock att för RIP-näten så kommer de ju även senare annonseras via R4->R3 -> EIGRP AS123, vi behöver därför sätta ett “bättre” metric när de kommer från OSPF-domänen. För EIGRP123 -> OSPF behöver vi endast redist. de interna näten.

Vi återanvänder ACL’en från tidigare men route-mapsen blir enligt följande:

route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 1 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 1 1 1 1 1
!
route-map EIGRP_123_TO_OSPF permit 10
match ip address EIGRP_123_PREFIXES
Inga konstigheter här, vi aktiverar redist. genom:
router eigrp 123
 redistribute ospf 234 route-map OSPF_TO_EIGRP_123
!
router ospf 234
 redistribute eigrp 123 route-map EIGRP_123_TO_OSPF subnets

R4

Här behöver vi endast hantera OSPF <-> RIP. Vi har redan konfigurerat så R3 annonserar RIP-näten till OSPF med en metric på 100, vi kan därför lämna den som default här. För OSPF in till RIP sätter vi en metric på 8  (hopcount), och för “transit-prefixen” EIGRP 123 & EIGRP 356 sätter vi ett högre värde. Vi kan då ge en bättre väg från R5 till dessa nät senare.

route-map RIP_TO_OSPF permit 10
 match ip address RIP_PREFIXES 
!
route-map OSPF_TO_RIP permit 10
 match ip address OSPF_PREFIXES
 set metric 8
!
route-map OSPF_TO_RIP permit 20
 match ip address EIGRP_123_PREFIXES
 set metric 12
!
route-map OSPF_TO_RIP permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 12
Och vi aktiverar redist med:
router rip
 redistribute ospf 234 route-map OSPF_TO_RIP
!
router ospf 234
 redistribute rip route-map RIP_TO_OSPF subnets

R5

Last up! Här kommer vi redistributa mellan EIGRP 356 & RIP. Vi behåller vårat standard metric på 8 för de interna RIP-näten samt EIGRP-näten från AS123 & 356 för att göra denna väg mer attraktiv än att gå via OSPF, som vi sätter till 12.

route-map RIP_TO_EIGRP_356 permit 10
 match ip address RIP_PREFIXES
 set metric 1 1 1 1 1
!
route-map EIGRP_356_TO_RIP permit 10
 match ip address EIGRP_356_PREFIXES
 set metric 8
!
route-map EIGRP_356_TO_RIP permit 20
 match ip address OSPF_PREFIXES
 set metric 12
!
route-map EIGRP_356_TO_RIP permit 30
 match ip address EIGRP_123_PREFIXES
 set metric 8

Tro det eller ej men vi är tyvärr inte klara än! 😀 Vi går fortfarande över OSPF-domänen för vissa av näten.

Men genom att justera AD-värdena för respektive router ska vi nog kunna lösa detta nu! Den uppgiften vi hade från GNS3Vault skiljde sig från den lösningen Petr skrev om så här fanns det ingen hjälp att få, men detta var ju löjligt basic om vi jämför med allt vi gjort tidigare.

Konfigen blev följande:

R2
router ospf 234
distance ospf external 190
R3
router ospf 234
distance ospf external 190
R4
router ospf 234
distance ospf external 190

R5
router rip
distance 190

Jag fick även gå in och modifiera route-mapen på R2 då pga vi manuellt satt metrics så började R1/BabyDoll lastbalansera mellan R2&R3 för att nå EIGRP AS356- & RIP-domänerna.

route-map OSPF_TO_EIGRP_123 permit 10
 match ip address OSPF_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 20
 match ip address RIP_PREFIXES
 set metric 1 100 1 1 1
!
route-map OSPF_TO_EIGRP_123 permit 30
 match ip address EIGRP_356_PREFIXES
 set metric 1 100 1 1 1
!
route-map EIGRP_123_TO_OSPF permit 10
 match ip address EIGRP_123_PREFIXES

Verifiering

Från R1 – > R7:

BabyDoll#traceroute 7.7.7.7
Type escape sequence to abort.
Tracing the route to 7.7.7.7
1 192.168.123.3 52 msec 24 msec 64 msec
 2 192.168.35.5 44 msec 92 msec 20 msec
 3 192.168.45.7 84 msec * 72 msec

R2 -> R5:

SweetPea#traceroute 5.5.5.5
Type escape sequence to abort.
Tracing the route to 5.5.5.5
1 192.168.123.3 20 msec 56 msec 28 msec
 2 192.168.35.5 44 msec * 20 msec

R4 -> R2:

Blondie#traceroute 2.2.2.2
Type escape sequence to abort.
Tracing the route to 2.2.2.2
1 192.168.234.2 32 msec * 48 msec

*Kom ihåg att vi tillät att trafik med destination direkt till OSPF-domänen ej behövde cirkulera hela nätet.

R4 – > R1:

Blondie#traceroute 1.1.1.1
Type escape sequence to abort.
Tracing the route to 1.1.1.1
1 192.168.45.5 36 msec 24 msec 20 msec
 2 192.168.35.3 36 msec 20 msec 28 msec
 3 192.168.123.1 28 msec * 60 msec

Så vackert att man nästan blir tårögd! 😉

Detta avslutar det här inlägget och nu känns det allt som det får räcka med redistribution ett tag framöver, next up – BGP! 🙂

Vill du testa själv så har GNS3Vault en färdig grundtopologi att hämta här.

Redistribution – Labs

Har tillbringat eftermiddagen med att göra GNS3 Vaults Redistribute-labbar.

RIP to EIGRP redistribution

RIP to OSPF redistribution

Dessa två var väldigt enkla, inget speciellt att tänka på.. Men denna var rätt intressant:

One-Way Redistribution

Oneway

  • All IP addresses have been preconfigured for you.
  • Configure OSPF on router Ace and Aggie and only advertise network 192.168.12.0 /24.
  • Configure EIGRP AS 1 on router Ace, Aggie and Abu. Only advertise network 192.168.13.0 /24 and 192.168.23.0 /24.
  • Redistribute the loopback0 interface in EIGRP AS 1 on router Abu.
  • Redistribute EIGRP information into OSPF on router Ace.
  • Do a traceroute from router Aggi or Ace to network 3.3.3.0 /24. You notice that you are not using the most optimal path…fix this problem so router Aggie uses the most optimal path.

Det var den sista punkten som ställde till det. Kontrollerar vi routing table på Aggie kan vi se följande:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:03:09, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
O E2 3.3.3.0 [110/500] via 192.168.12.1, 00:00:08, FastEthernet1/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Aggie väljer helt enkelt att gå via Ace för att komma till 3.3.3.3/24 istället för att gå direkt ner till Abu via fa0/0. En show topology table för EIGRP visar dock att vi ju faktiskt känner till “den bättre vägen” men trots detta väljer att gå via Ace.

Aggie#sh ip eigrp topology 
IP-EIGRP Topology Table for AS(1)/ID(192.168.23.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
 r - reply Status, s - sia Status
P 3.3.3.0/24, 0 successors, FD is Inaccessible
 via 192.168.23.3 (1709312/1706752), FastEthernet0/0
P 192.168.13.0/24, 1 successors, FD is 30720
 via 192.168.23.3 (30720/28160), FastEthernet0/0
P 192.168.23.0/24, 1 successors, FD is 28160
 via Connected, FastEthernet0/0

Varför? EIGRP External-routes har en AD av 170, OSPF’s E1/E2 har 110! Lösningen är helt enkelt att modifiera Aggie’s AD, exempelvis genom att höja OSPF’s external över 170.

router ospf 1
distance ospf external 200

Kollar vi återigen routing table kan vi nu se följande:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:10:07, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.23.3, 00:00:01, FastEthernet0/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Labben hittar du här.

Multipoint One-way Redistribution

Oneway

Uppgiften är egentligen densamma som vi hade tidigare, skillnaden är att vi nu ska redistributa EIGRP-informationen på både Ace & Aggie in till OSPF, tidigare gjorde vi detta endast på Ace. Vilka problem kan detta leda till?

Routing table för Ace ser bra ut:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.13.3, 00:32:00, FastEthernet0/0
D 192.168.23.0/24 [90/30720] via 192.168.13.3, 00:34:03, FastEthernet0/0

Men för Aggie är det samma problem som innan:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:33:31, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
O E2 3.3.3.0 [110/500] via 192.168.12.1, 00:00:01, FastEthernet1/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Vi gör återigen samma lösning på Aggie;

router ospf 1
distance ospf external 200

Resultatet blir:

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
D 192.168.13.0/24 [90/30720] via 192.168.23.3, 00:38:07, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
D EX 3.3.3.0 [170/1709312] via 192.168.23.3, 00:00:02, FastEthernet0/0
C 192.168.23.0/24 is directly connected, FastEthernet0/0

Men om vi nu kontrollerar routing-tabel för Ace så har något hänt..

Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet1/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 3.0.0.0/24 is subnetted, 1 subnets
O E2 3.3.3.0 [110/500] via 192.168.12.2, 00:00:08, FastEthernet1/0
D 192.168.23.0/24 [90/30720] via 192.168.13.3, 00:38:14, FastEthernet0/0

Vafan! Kom ihåg att vi endast kan gäller lokalt för routern vi ändrar på, Ace anser därför nu att den har en bättre väg till 3.3.3.0/24-nätet via Aggie istället.

Vi är med andra ord tvungna att lägga in “distance ospf external 200” även på Ace. Efter detta är allt frid och fröjd igen.. 🙂 Även om det är väldigt enkelt just nu så är det ju bara att sätta sig in i vilka märkliga problem & routing-loopar detta kan leda till i större topologier.

Labben hittar du här.

RIP to EIGRP Two-Way Redistribution & Route Tagging

routetagg redist

  • All IP addresses have been preconfigured for you.
  • RIP and EIGRP have been preconfigred for you on the corresponding routers.
  • Enable two-way redistribution between RIP and EIGRP on router Lassie and Willy.
  • You notice that router Willy or Lassie are sending traffic to 4.4.4.4 towards router Flipper, make sure you get rid of this sub-optimal routing.
  • Use route tagging to accomplish this.

Precis som labben säger tror Willy att bästa vägen för att nå 4.4.4.4 är via Flipper(!) efter vi lagt in grundkonfig.

Gateway of last resort is not set
R 192.168.12.0/24 [120/1] via 192.168.13.1, 00:00:08, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.13.1, 00:00:08, FastEthernet0/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
R 4.4.4.0 [120/6] via 192.168.13.1, 00:00:08, FastEthernet0/0
D 192.168.24.0/24 [90/30720] via 192.168.34.4, 00:03:40, FastEthernet1/0
C 192.168.34.0/24 is directly connected, FastEthernet1/0

Varför? Jo precis som tidigare, RIP har en AD på 120, EIGRP External har 170, Willy kommer med andra ord alltid föredra att gå via Flipper istället för direkt ner till Skippy. Inte helt optimalt direkt.. Den här gången fick vi dock inte modifiera AD-värdet utan ska istället använda oss av route tagging, nice!

Om vi börjar med RIP -> EIGRP, så behövs först en access-lista som definierar vilka routes vi vill tagga (RIP):

ip access-list standard RIP
 permit 1.1.1.1
 permit 192.168.12.0 0.0.0.255
 permit 192.168.13.0 0.0.0.255

Vi bygger sedan en route-map som märker dessa med tag 10, och blockerar routes märkte med tag 5 (fixar vi senare):

route-map RIP-INTO-EIGRP deny 5
 match tag 5

route-map RIP-INTO-EIGRP permit 10
 match ip address RIP
 set tag 10

Och samma sak för EIGRP -> RIP:

ip access-list standard EIGRP
 permit 4.4.4.4
 permit 192.168.24.0 0.0.0.255
 permit 192.168.34.0 0.0.0.255
route-map EIGRP-INTO-RIP deny 5
 match tag 10

route-map EIGRP-INTO-RIP permit 10
 match ip address EIGRP
 set tag 5

En show ip route för Lassie & Willie ser nu ut enligt följande:

Willy

Gateway of last resort is not set
R 192.168.12.0/24 [120/1] via 192.168.13.1, 00:00:20, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.13.1, 00:00:20, FastEthernet0/0
C 192.168.13.0/24 is directly connected, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
D EX 4.4.4.0 [170/156160] via 192.168.34.4, 00:09:53, FastEthernet1/0
D 192.168.24.0/24 [90/30720] via 192.168.34.4, 00:09:53, FastEthernet1/0
C 192.168.34.0/24 is directly connected, FastEthernet1/0
Lassie
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
 1.0.0.0/24 is subnetted, 1 subnets
R 1.1.1.0 [120/1] via 192.168.12.1, 00:00:06, FastEthernet0/0
R 192.168.13.0/24 [120/1] via 192.168.12.1, 00:00:06, FastEthernet0/0
 4.0.0.0/24 is subnetted, 1 subnets
D EX 4.4.4.0 [170/156160] via 192.168.24.4, 00:04:00, FastEthernet1/0
C 192.168.24.0/24 is directly connected, FastEthernet1/0
D 192.168.34.0/24 [90/30720] via 192.168.24.4, 00:04:00, FastEthernet1/0

Sådär ja! Vill du också göra denna labb så finns den här.

Ska brygga mig en stor kanna kaffe och sätta mig med advanced distribution-labben gjord av Petr Lapukhov (CCIEx4 :D). Den är dock främst riktad mot de som studerar inför CCIE-Lab men rekommenderades även för de som verkligen ville gå in på djupet under sina ccnp-studier, och det vill vi ju givetvis! Det får dock bli en egen post om jag nu lyckas. 😉