TSHOOT – Part V, DHCP & NAT

bgp-internet

Då var det endast NAT & DHCP kvar att konfa upp (tidigare inlägg finns här). Förhoppningsvis sparar jag in en del tid nu till certet när jag faktiskt “hittar i nätet” och bara behöver fokusera på att leta efter fel istället.

Har sett att gns3vault.com har en hel del troubleshoot-labbar jag tänkte försöka mig på under veckan för lite extra träning. Men det är bara 7 dagar kvar nu och på något vis ska jag även försöka hinna nöta in repetition av Switch också… Att försöka sig på två cert samtidigt efter bara 3 veckors plugg = låååånga dagar (8-22 ftw). Ett under att jag inte drömmer om cisco än… 😀

Inbillar mig dock att switch är enklare än route, och tshoot räknar jag kallt med att inte behöva läsa någon teori inför… Så om allt går vägen så är jag faktiskt CCNP-certifierad nästa vecka, ett litet steg på vägen iaf…

NAT

Gjorde det enkelt för mig och tillät NAT för alla 10.1.x.x-10.2.x.x adresser, men har ingen info om hur cisco själva gör, antagligen är det väl bara ex. vlan10&20 som NATas.

R1(config)#ip access-list extended NAT
R1(config-ext-nacl)#remark NAT-ACL
R1(config-ext-nacl)#permit ip 10.1.0.0 0.0.255.255 any
R1(config-ext-nacl)#permit ip 10.2.0.0 0.0.255.255 any
R1(config-ext-nacl)#exit
R1(config)#interface fa0/1
R1(config-if)#ip nat outside
R1(config-if)#interface s1/0.12 point-to-point
R1(config-subif)#ip nat inside
R1(config-subif)#exit
R1(config)#ip nat inside source list NAT interface fa0/1 overload

HostA#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 = 172/207/236 ms

R1#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 209.65.200.225:1 10.1.1.6:1 209.65.200.241:1 209.65.200.241:1
icmp 209.65.200.225:34 10.2.1.10:34 209.65.200.241:34 209.65.200.241:34

Vackert. 🙂

DHCP

R4

R4(config)#ip dhcp excluded-address 10.2.1.1 10.2.1.10
R4(config)#ip dhcp excluded-address 10.2.1.254
R4(config)#ip dhcp excluded-address 10.2.2.1 10.2.2.10
R4(config)#ip dhcp pool VLAN10
R4(dhcp-config)#network 10.2.1.0 /24
R4(dhcp-config)#domain-name TSHOOT
R4(dhcp-config)#dns-server 10.2.1.254
R4(dhcp-config)#default-router 10.2.1.254
R4(dhcp-config)#exit
R4(config)#ip dhcp pool VLAN20
R4(dhcp-config)#network 10.2.2.0 /24
R4(dhcp-config)#domain-name TSHOOT
R4(dhcp-config)#dns-server 10.2.2.1
R4(dhcp-config)#default-router 10.2.2.1
R4(dhcp-config)#exit

Då R4 ligger utanför broadcast-domänen för både VLAN10 & 20 behöver vi konfa upp ip-helpers på både DSW1 & DSW2.

DSW1

DSW1(config)#inte vlan 10
DSW1(config-if)#ip helper-address 10.1.4.5
DSW1(config-if)#int vlan 20
DSW1(config-if)#ip helper-address 10.1.4.5

DSW2

DSW2(config)#inte vlan 10
DSW2(config-if)#ip helper-address 10.1.4.9
DSW2(config-if)#int vlan 20
DSW2(config-if)#ip helper-address 10.1.4.9

Vi kan verifiera så allt är ok med vår host på vlan10.

HostA(config)#inte fa0/0
HostA(config-if)#no ip add
HostA(config-if)#ip add dhcp
HostA(config-if)#end

HostA#sh inte fa0/0
FastEthernet0/0 is up, line protocol is up
 Hardware is AmdFE, address is cc04.05e0.0000 (bia cc04.05e0.0000)
 Description: Host-connection to Vlan 10
 Internet address will be negotiated using DHCP
...

*Mar 1 10:00:32.361: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.2.1.11, mask 255.255.255.0, hostname HostA

HostA#sh inte fa0/0
FastEthernet0/0 is up, line protocol is up
 Hardware is AmdFE, address is cc04.05e0.0000 (bia cc04.05e0.0000)
 Description: Host-connection to Vlan 10
 Internet address is 10.2.1.11/24

Det var sista delen i min “TSHOOT”-serie. Vi har nu konfat upp hela det här nätet från grunden, mycket enklare än vad jag hade räknat med faktiskt.

tshoot-whiteboard

Och det färdiga resultatet:

tshoot-done

GNS3-filen med färdiga konfigs finns att tanka hem här, troligtvis behöver du dock lägga till vlan:en på Dist & Access-switcharna igen.

TSHOOT – Part IV, Access-layer

tshoot-access

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

Layer 2

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

DSW1

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

DSW2

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

ASW1

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

ASW2

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

Access-ports

ASW1

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

ASW2

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

Management-Vlan

DSW1

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

DSW2

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

ASW1

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

ASW2

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

MLS Routing

DSW1

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

DLSW2

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

HSRP

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

DSW1

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

DSW2

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

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

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

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

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

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

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

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

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

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

TSHOOT – Part III, Dist-layer

tshoot-distlayer

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

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

Basic L3

R4

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

DSW1

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

DSW2

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

EIGRP

R4

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

DSW1

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

DSW2

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

RIPng

R4

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

DSW1

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

DSW2

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

Redistribution

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

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

Verifiering

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

Ping till R1 från DSW2

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

Vackert!

En trace till webservern fungerar dock ej:

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

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

TSHOOT – Part II, Frame-Relay, IPv6 & OSPF

tshoot-ospf

Frame-Relay är min överlägset svagaste sida så det här är verkligen välkommen repetition. Innan vi börjar med OSPF etc så lär vi först fixa basic L2-connectivity.

Frame-Relay IPv4

R1

R1(config)#interface s1/0
 R1(config-if)#encapsulation frame-relay
 R1(config-if)#no shut
 R1(config-if)#
 R1(config-if)#interface s1/0.12 point-to-point
 R1(config-subif)#ip add 10.1.1.1 255.255.255.252
 R1(config-subif)#frame-relay interface-dlci 102
 R1(config-fr-dlci)#desc to R2

R2

R2(config)#interface s1/0
 R2(config-if)#encapsulation frame-relay
 R2(config-if)#no shut
 R2(config-if)#
 R2(config-if)#interface serial 1/0.21 point-to-point
 R2(config-subif)#ip add 10.1.1.2 255.255.255.252
 R2(config-subif)#desc to R1
 R2(config-subif)#frame-relay interface-dlci 201
 R2(config-fr-dlci)#
 R2(config-fr-dlci)#interface serial 1/0.23 point-to-point
 R2(config-subif)#ip add 10.1.1.5 255.255.255.252
 R2(config-subif)#desc to R3
 R2(config-subif)#frame-relay interface-dlci 203
 R2(config-fr-dlci)#end

R3

R3(config)#interface s1/0
 R3(config-if)#encapsulation frame-relay
 R3(config-if)#no shut
 R3(config-if)#
 R3(config-if)#interface serial 1/0.32 point-to-point
 R3(config-subif)#ip add 10.1.1.6 255.255.255.252
 R3(config-subif)#frame-relay interface-dlci 302
 R3(config-fr-dlci)#
 R3(config-fr-dlci)#interface serial 1/0.34 point-to-point
 R3(config-subif)#ip add 10.1.1.9 255.255.255.252
 R3(config-subif)#frame-relay interface-dlci 304
 R3(config-fr-dlci)#

R4

R4(config)#interface s1/0
 R4(config-if)#encapsulation frame-relay
 R4(config-if)#no shut
 R4(config-if)#
 R4(config-if)#interface serial 1/0.43 point-to-point
 R4(config-subif)#ip add 10.1.1.10 255.255.255.252
 R4(config-subif)#desc to R3
 R4(config-subif)#frame-relay interface-dlci 403

Frame-Relay IPv6

R1

R1(config)#ipv6 unicast-routing
 R1(config)#int s1/0.12 point-to-point
 R1(config-subif)#ipv6 add 2026::12:1/122

R2

R2(config)#ipv6 unicast-routing
 R2(config)#interface s1/0.21 point-to-point
 R2(config-subif)#ipv6 add 2026::12:2/122
R2(config-subif)#interface s1/0.23 point-to-point
 R2(config-subif)#ipv6 add 2026::1:1/122
 R2(config-subif)#end

R3

R3(config)#ipv6 unicast-routing
 R3(config)#interface s1/0.32 point-to-point
 R3(config-subif)#ipv6 add 2026::1:2/122
 R3(config-subif)#end

Mellan R3 & R4 ska vi enligt skissen istället ha en GRE-tunnel. Se tidigare inlägg här för mer info om hur vi sätter upp statiska/6to4/ISATAP-IPv6 tunnlar.

R3

R3(config)#interface Tunnel0
 R3(config-if)#ipv6 address 2026::34:1/122
 R3(config-if)#tunnel source s1/0.34
 R3(config-if)#tunnel destination 10.1.1.10
 R3(config-if)#tunnel mode ipv6ip

R4

R4(config)#ipv6 unicast-routing
 R4(config)#interface Tunnel0
 R4(config-if)#ipv6 address 2026::34:2/122
 R4(config-if)#tunnel source s1/0.43
 R4(config-if)#tunnel destination 10.1.1.9
 R4(config-if)#tunnel mode ipv6ip

OSPFv2

Inget avancerat här direkt, glöm bara inte att annonsera default-routen från R1 till övriga (default-information originate).

R1

R1(config)#router ospf 1
 R1(config-router)#router-id 1.1.1.1
 R1(config-router)#network 10.1.1.0 0.0.0.3 area 12
 R1(config-router)#default-information originate

R2

R2(config)#router ospf 1
 R2(config-router)#router-id 2.2.2.2
 R2(config-router)#network 10.1.1.0 0.0.0.3 area 12
 R2(config-router)#network 10.1.1.4 0.0.0.3 area 0

R3 – Kom ihåg “Totally Not-so-stubby” för area 34!

R3(config)#router ospf 1
 R3(config-router)#router-id 3.3.3.3
 R3(config-router)#network 10.1.1.4 0.0.0.3 area 0
 R3(config-router)#network 10.1.1.8 0.0.0.3 area 34
 R3(config-router)#area 34 nssa no-summary

R4

R4(config)#router ospf 1
 R4(config-router)#router-id 4.4.4.4
 R4(config-router)#network 10.1.1.8 0.0.0.3 area 34
 R4(config-router)#area 34 nssa

OSPFv3

R1

R1(config-rtr)#interface Serial1/0.12 point-to-point
R1(config-subif)# ipv6 ospf 6 area 12

R2

R2(config)#interface Serial1/0.21 point-to-point
R2(config-subif)# ipv6 ospf 6 area 12
R2(config-subif)#interface Serial1/0.23 point-to-point
R2(config-subif)# ipv6 ospf 6 area 0

R3

R3(config)#ipv6 router ospf 6
R3(config-rtr)#area 34 nssa no-summary
R3(config-rtr)#exit
R3(config)#interface Serial1/0.32 point-to-point
R3(config-subif)#ipv6 ospf 6 area 0
R3(config)#interface Tunnel0
R3(config-if)# ipv6 ospf 6 area 34

R4

R4(config)#ipv6 router ospf 6
 R4(config-rtr)#area 34 nssa
 R4(config-rtr)#exit
 R4(config)#interface Tunnel0
 R4(config-if)# ipv6 ospf 6 area 34

Verifiering

En hel del adresser att testa så enklast är att göra ett TCL-script istället.

R1#tclsh
 R1(tcl)#tclsh
R1(tcl)#foreach address {
 +>(tcl)#209.65.200.241
 +>(tcl)#209.65.200.242
 +>(tcl)#209.65.200.226
 +>(tcl)#209.65.200.225
 +>(tcl)#10.1.1.1
 +>(tcl)#10.1.1.2
 +>(tcl)#10.1.1.5
 +>(tcl)#10.1.1.6
 +>(tcl)#10.1.1.9
 +>(tcl)#10.1.1.10
 +>(tcl)#2026::12:1
 +>(tcl)#2026::12:2
 +>(tcl)#2026::1:1
 +>(tcl)#2026::1:2
 +>(tcl)#2026::34:1
 +>(tcl)#2026::34:2
 +>(tcl)#} { ping $address re 3 }
 Translating "209.65.200.241"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.241, timeout is 2 seconds:
 ..!
 Success rate is 33 percent (1/3), round-trip min/avg/max = 136/136/136 ms
 Translating "209.65.200.242"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.242, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 16/34/60 ms
 Translating "209.65.200.226"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.226, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 20/32/44 ms
 Translating "209.65.200.225"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 209.65.200.225, timeout is 2 seconds:
 ...
 Success rate is 0 percent (0/3)
 Translating "10.1.1.1"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 28/58/76 ms
 Translating "10.1.1.2"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 28/34/48 ms
 Translating "10.1.1.5"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 8/38/76 ms
 Translating "10.1.1.6"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.6, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 60/89/112 ms
 Translating "10.1.1.9"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.9, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 36/64/92 ms
 Translating "10.1.1.10"
Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 92/118/152 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::12:1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 0/1/4 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::12:2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 8/46/84 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::1:1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 16/25/36 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::1:2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 44/70/88 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::34:1, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 24/52/68 ms
 Type escape sequence to abort.
 Sending 3, 100-byte ICMP Echos to 2026::34:2, timeout is 2 seconds:
 !!!
 Success rate is 100 percent (3/3), round-trip min/avg/max = 84/112/160 ms
 R1(tcl)#tclquit
 R1#ping 2026::34:2
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2026::34:2, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 36/100/160 ms
 R1#ping ipv6 2026::34:2
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2026::34:2, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 60/80/104 ms
 R1#ping 2026::34:1
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 2026::34:1, timeout is 2 seconds:
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 40/56/76 ms

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 – Internal BGP & Transitarea

Kommer skriva några inlägg som går mer in på djupet på det teoretiska men just nu är jag mer sugen på att labba lite. 🙂 Byggde upp denna topologi hämtad från Renee Molenaar’s “How to Master CCNP Route”:

ibgp ebgp

  • Varje router har ett loopback-interface med sitt router-id (ex. R1 – 1.1.1.1/R2 2.2.2.2)
  • OSPF används som IGP inom AS500
  • R5 & R6 annonserar sin loopback-interface över BGP

R5’s grundkonfig:

interface Loopback0
 ip address 5.5.5.5 255.255.255.0
 !
 interface FastEthernet0/0
 ip address 172.16.51.5 255.255.255.0
 !
 router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 5.5.5.0 mask 255.255.255.0
 neighbor 172.16.51.1 remote-as 500

R1:

interface Loopback0
 ip address 1.1.1.1 255.255.255.0
 !
 interface FastEthernet0/0
 ip address 172.16.51.1 255.255.255.0
 !
 interface Serial0/0
 ip address 172.16.12.1 255.255.255.0
 clock rate 128000
 !
 interface Serial0/1
 ip address 172.16.14.1 255.255.255.0
 clock rate 128000
 !
 router ospf 1
 log-adjacency-changes
 passive-interface FastEthernet0/0
 network 0.0.0.0 255.255.255.255 area 0
 !
 router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor 172.16.51.5 remote-as 100
 no auto-summary

R3:

interface Loopback0
 ip address 3.3.3.3 255.255.255.0
 !
 interface FastEthernet0/0
 ip address 172.16.36.3 255.255.255.0
 !
 interface Serial0/0
 ip address 172.16.43.3 255.255.255.0
 clock rate 128000
 !
 interface Serial0/1
 ip address 172.16.23.3 255.255.255.0
 clock rate 2000000
 !
 router ospf 1
 log-adjacency-changes
 passive-interface FastEthernet0/0
 network 0.0.0.0 255.255.255.255 area 0
 !
 router bgp 500
 no synchronization
 bgp log-neighbor-changes
 neighbor 172.16.36.6 remote-as 200
 no auto-summary

R6:

interface Loopback0
 ip address 6.6.6.6 255.255.255.0
 !
 interface FastEthernet0/0
 ip address 172.16.36.6 255.255.255.0
 !
 router bgp 200
 no synchronization
 bgp log-neighbor-changes
 network 6.6.6.0 mask 255.255.255.0
 neighbor 172.16.36.3 remote-as 500
 no auto-summary

En show ip route på R5 & R6 visar följande:

R5

Gateway of last resort is not set
5.0.0.0/24 is subnetted, 1 subnets
 C 5.5.5.0 is directly connected, Loopback0
 172.16.0.0/24 is subnetted, 1 subnets
 C 172.16.51.0 is directly connected, FastEthernet0/0

R6

Gateway of last resort is not set
6.0.0.0/24 is subnetted, 1 subnets
 C 6.6.6.0 is directly connected, Loopback0
 172.16.0.0/24 is subnetted, 1 subnets
 C 172.16.36.0 is directly connected, FastEthernet0/0

Och R1 & R3:

R1

1.0.0.0/24 is subnetted, 1 subnets
 C 1.1.1.0 is directly connected, Loopback0
 2.0.0.0/32 is subnetted, 1 subnets
 O 2.2.2.2 [110/65] via 172.16.12.2, 00:26:08, Serial0/0
 3.0.0.0/32 is subnetted, 1 subnets
 O 3.3.3.3 [110/129] via 172.16.14.4, 00:26:08, Serial0/1
 [110/129] via 172.16.12.2, 00:26:08, Serial0/0
 4.0.0.0/32 is subnetted, 1 subnets
 O 4.4.4.4 [110/65] via 172.16.14.4, 00:26:08, Serial0/1
 5.0.0.0/24 is subnetted, 1 subnets
 B 5.5.5.0 [20/0] via 172.16.51.5, 00:22:25
 172.16.0.0/24 is subnetted, 6 subnets
 C 172.16.51.0 is directly connected, FastEthernet0/0
 O 172.16.43.0 [110/128] via 172.16.14.4, 00:26:11, Serial0/1
 O 172.16.36.0 [110/138] via 172.16.14.4, 00:26:11, Serial0/1
 [110/138] via 172.16.12.2, 00:26:11, Serial0/0
 O 172.16.23.0 [110/128] via 172.16.12.2, 00:26:11, Serial0/0
 C 172.16.12.0 is directly connected, Serial0/0
 C 172.16.14.0 is directly connected, Serial0/1

R3

1.0.0.0/32 is subnetted, 1 subnets
 O 1.1.1.1 [110/129] via 172.16.43.4, 00:31:22, Serial0/0
 [110/129] via 172.16.23.2, 00:31:22, Serial0/1
 2.0.0.0/32 is subnetted, 1 subnets
 O 2.2.2.2 [110/65] via 172.16.23.2, 00:31:12, Serial0/1
 3.0.0.0/24 is subnetted, 1 subnets
 C 3.3.3.0 is directly connected, Loopback0
 4.0.0.0/32 is subnetted, 1 subnets
 O 4.4.4.4 [110/65] via 172.16.43.4, 00:31:38, Serial0/0
 6.0.0.0/24 is subnetted, 1 subnets
 B 6.6.6.0 [20/0] via 172.16.36.6, 00:22:24
 172.16.0.0/24 is subnetted, 6 subnets
 O 172.16.51.0 [110/138] via 172.16.43.4, 00:31:51, Serial0/0
 [110/138] via 172.16.23.2, 00:32:50, Serial0/1
 C 172.16.43.0 is directly connected, Serial0/0
 C 172.16.36.0 is directly connected, FastEthernet0/0
 C 172.16.23.0 is directly connected, Serial0/1
 O 172.16.12.0 [110/128] via 172.16.23.2, 00:32:50, Serial0/1
 O 172.16.14.0 [110/128] via 172.16.43.4, 00:32:01, Serial0/0

Så R1 känner till R5’s loopback, och R3 känner till R6’s loopback. Men ska vi lyckas skicka trafik mellan R5 <-> R6 så behöver vi ju även ordna så R1 & R3 sprider denna information mellan varandra. Det är här iBGP (internal BGP) kommer in i bilden. Konfigurationen är i princip densamma, vi använder dock loopback-interfacen för att inte riskera tappa adjacency om vi skulle få problem med någon länk.

R1:

neighbor 3.3.3.3 remote-as 500
neighbor 3.3.3.3 update-source Loopback0

R3:

neighbor 1.1.1.1 remote-as 500
neighbor 1.1.1.1 update-source Loopback0

Observera att vi måste specificera vilket source-interface vi skall använda, då neighbor-statement måste matchas (specificerar vi inte vilket används utgående interface istället).

R5 kan nu se R6s nät och vice versa:

R5#sh ip route | beg Gat
 Gateway of last resort is not set
5.0.0.0/24 is subnetted, 1 subnets
 C 5.5.5.0 is directly connected, Loopback0
 6.0.0.0/24 is subnetted, 1 subnets
 B 6.6.6.0 [20/0] via 172.16.51.1, 00:04:34
 172.16.0.0/24 is subnetted, 1 subnets
 C 172.16.51.0 is directly connected, FastEthernet0/0
R6#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.36.3, 00:04:49
 6.0.0.0/24 is subnetted, 1 subnets
 C 6.6.6.0 is directly connected, Loopback0
 172.16.0.0/24 is subnetted, 1 subnets
 C 172.16.36.0 is directly connected, FastEthernet0/0

Så nu borde vi med andra ord kunna pinga mellan siterna.. Eller?

R5#ping 6.6.6.6 source 5.5.5.5
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
 .....
 Success rate is 0 percent (0/5)
R5#traceroute 6.6.6.6 source 5.5.5.5
Type escape sequence to abort.
 Tracing the route to 6.6.6.6
1 172.16.51.1 56 msec 48 msec 32 msec
 2 172.16.14.4 44 msec 52 msec 60 msec
 3 172.16.14.4 !H * !H

Tillskillnad från IGP’s så betyder det inte att vi kan nå en route bara för att den finns i vårat routing table när vi använder BGP!

Vi fastnade i R4, hur ser då routing table ut där, kom ihåg att vi endast satt upp neighbor mellan R1 <-> R3?

Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
 O 1.1.1.1 [110/65] via 172.16.14.1, 00:51:28, Serial0/1
 2.0.0.0/32 is subnetted, 1 subnets
 O 2.2.2.2 [110/129] via 172.16.43.3, 00:51:18, Serial0/0
 [110/129] via 172.16.14.1, 00:51:18, Serial0/1
 3.0.0.0/32 is subnetted, 1 subnets
 O 3.3.3.3 [110/65] via 172.16.43.3, 00:51:08, Serial0/0
 4.0.0.0/24 is subnetted, 1 subnets
 C 4.4.4.0 is directly connected, Loopback0
 172.16.0.0/24 is subnetted, 6 subnets
 O 172.16.51.0 [110/74] via 172.16.14.1, 00:51:55, Serial0/1
 C 172.16.43.0 is directly connected, Serial0/0
 O 172.16.36.0 [110/74] via 172.16.43.3, 00:52:05, Serial0/0
 O 172.16.23.0 [110/128] via 172.16.43.3, 00:52:06, Serial0/0
 O 172.16.12.0 [110/128] via 172.16.14.1, 00:51:56, Serial0/1
 C 172.16.14.0 is directly connected, Serial0/1

Som synes har vi ingen route till varken R5 eller R6. Vi skulle kunna lösa detta genom att redistributa BGP-informationen till OSPF, men hur giltig är den lösningen om vi tänker oss att vi är ute “IRL” och BGP innehåller 350,000k+ routes? 😛

Vi behöver således sätta upp neighbors med både R4 & R2. Något som är unikt för iBGP är att vi måste konfigurera fullmesh när det kommer till neighbor-relationships, detta pga split-horizon för bgp agerar lite speciellt (mer om detta senare).

R1

router bgp 500
 bgp log-neighbor-changes
 neighbor 2.2.2.2 remote-as 500
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 4.4.4.4 remote-as 500
 neighbor 4.4.4.4 update-source Loopback0

R2

router bgp 500
 neighbor 1.1.1.1 remote-as 500
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 3.3.3.3 remote-as 500
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 4.4.4.4 remote-as 500
 neighbor 4.4.4.4 update-source Loopback0

R3

router bgp 500
 neighbor 2.2.2.2 remote-as 500
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 4.4.4.4 remote-as 500
 neighbor 4.4.4.4 update-source Loopback0

R4

router bgp 500
 neighbor 1.1.1.1 remote-as 500
 neighbor 1.1.1.1 update-source Loopback0
 neighbor 2.2.2.2 remote-as 500
 neighbor 2.2.2.2 update-source Loopback0
 neighbor 3.3.3.3 remote-as 500
 neighbor 3.3.3.3 update-source Loopback0
R1#sh ip bgp summary
 BGP router identifier 1.1.1.1, local AS number 500
 BGP table version is 27, main routing table version 27
 2 network entries using 240 bytes of memory
 2 path entries using 104 bytes of memory
 3/2 BGP path/bestpath attribute entries using 372 bytes of memory
 2 BGP AS-PATH entries using 48 bytes of memory
 0 BGP route-map cache entries using 0 bytes of memory
 0 BGP filter-list cache entries using 0 bytes of memory
 Bitfield cache entries: current 2 (at peak 3) using 64 bytes of memory
 BGP using 828 total bytes of memory
 BGP activity 14/12 prefixes, 14/12 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
 2.2.2.2 4 500 9 10 27 0 0 00:05:08 0
 3.3.3.3 4 500 45 45 27 0 0 00:16:53 1
 4.4.4.4 4 500 7 8 27 0 0 00:03:19 0
 172.16.51.5 4 100 56 66 27 0 0 00:52:19 1

Nu borde vi ha lite bättre action!

Ping från R5 -> R6:

R5#ping 6.6.6.6 source 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 5.5.5.5 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 76/139/184 ms
R5#traceroute 6.6.6.6 source 5.5.5.5
Type escape sequence to abort.
Tracing the route to 6.6.6.6
1 172.16.51.1 56 msec 52 msec 60 msec
 2 172.16.12.2 136 msec 100 msec 68 msec
 3 172.16.23.3 96 msec 76 msec 144 msec
 4 172.16.36.6 172 msec * 256 msec

En sh ip route på R3 visar följande:

Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
 O 1.1.1.1 [110/129] via 172.16.43.4, 01:04:09, Serial0/0
 [110/129] via 172.16.23.2, 01:04:09, Serial0/1
 2.0.0.0/32 is subnetted, 1 subnets
 O 2.2.2.2 [110/65] via 172.16.23.2, 01:03:59, Serial0/1
 3.0.0.0/24 is subnetted, 1 subnets
 C 3.3.3.0 is directly connected, Loopback0
 4.0.0.0/32 is subnetted, 1 subnets
 O 4.4.4.4 [110/65] via 172.16.43.4, 01:04:25, Serial0/0
 5.0.0.0/24 is subnetted, 1 subnets
 B 5.5.5.0 [200/0] via 172.16.51.5, 00:20:34
 6.0.0.0/24 is subnetted, 1 subnets
 B 6.6.6.0 [20/0] via 172.16.36.6, 00:55:10
 172.16.0.0/24 is subnetted, 6 subnets
 O 172.16.51.0 [110/138] via 172.16.43.4, 01:04:37, Serial0/0
 [110/138] via 172.16.23.2, 01:05:37, Serial0/1
 C 172.16.43.0 is directly connected, Serial0/0
 C 172.16.36.0 is directly connected, FastEthernet0/0
 C 172.16.23.0 is directly connected, Serial0/1
 O 172.16.12.0 [110/128] via 172.16.23.2, 01:05:37, Serial0/1
 O 172.16.14.0 [110/128] via 172.16.43.4, 01:04:47, Serial0/0

Se dock nexthop-adressen! Till skillnad från IGPs som EIGRP/OSPF så ändras inte nexthop-adressen när en route annonseras inom iBGP. Just nu annonserar vi ju dock länknäten inom OSPF,  med hur löser vi detta om så inte är fallet?

Vi konfar om OSPF så endast länknäten inom AS500 & loopback-interfacen annonseras.

En show ip route på R1 ser nu ut såhär:

Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
 C 1.1.1.0 is directly connected, Loopback0
 2.0.0.0/32 is subnetted, 1 subnets
 O 2.2.2.2 [110/65] via 172.16.12.2, 00:02:39, Serial0/0
 3.0.0.0/32 is subnetted, 1 subnets
 O 3.3.3.3 [110/129] via 172.16.14.4, 00:02:29, Serial0/1
 [110/129] via 172.16.12.2, 00:02:29, Serial0/0
 4.0.0.0/32 is subnetted, 1 subnets
 O 4.4.4.4 [110/65] via 172.16.14.4, 00:02:19, Serial0/1
 5.0.0.0/24 is subnetted, 1 subnets
 B 5.5.5.0 [20/0] via 172.16.51.5, 01:28:21
 172.16.0.0/24 is subnetted, 5 subnets
 C 172.16.51.0 is directly connected, FastEthernet0/0
 O 172.16.43.0 [110/128] via 172.16.14.4, 00:04:18, Serial0/1
 O 172.16.23.0 [110/128] via 172.16.12.2, 00:04:28, Serial0/0
 C 172.16.12.0 is directly connected, Serial0/0
 C 172.16.14.0 is directly connected, Serial0/1

Observera att vi inte längre ser 6.6.6.0/24-nätet! Anledningen till detta är att R1 inte kan resolve’a next-hop adressen som R6 annonserar (172.16.36.6) och den ignorerar därför routen!

Samma sak gäller givetvis för R3. Vi kan lösa detta på två sätt, antingen genom att annonsera ut länknätet via ex. OSPF som vi gjorde tidigare, eller kommandot “next-hop-self”. R3 kommer då ersätta next-hop adressen 172.16.36.6 till sin egen loopback 3.3.3.3, och då denna adress finns i routing table borde vi återigen se nätet i R1. Låt oss testa..

R1

neighbor 2.2.2.2 next-hop-self
 neighbor 3.3.3.3 next-hop-self
 neighbor 4.4.4.4 next-hop-self

R3

neighbor 1.1.1.1 next-hop-self
 neighbor 2.2.2.2 next-hop-self
 neighbor 4.4.4.4 next-hop-self

En show ip route på R1 visar nu följande:

Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
 C 1.1.1.0 is directly connected, Loopback0
 2.0.0.0/32 is subnetted, 1 subnets
 O 2.2.2.2 [110/65] via 172.16.12.2, 00:09:06, Serial0/0
 3.0.0.0/32 is subnetted, 1 subnets
 O 3.3.3.3 [110/129] via 172.16.14.4, 00:08:56, Serial0/1
 [110/129] via 172.16.12.2, 00:08:56, Serial0/0
 4.0.0.0/32 is subnetted, 1 subnets
 O 4.4.4.4 [110/65] via 172.16.14.4, 00:08:48, Serial0/1
 5.0.0.0/24 is subnetted, 1 subnets
 B 5.5.5.0 [20/0] via 172.16.51.5, 01:34:47
 6.0.0.0/24 is subnetted, 1 subnets
 B 6.6.6.0 [200/0] via 3.3.3.3, 00:00:31
 172.16.0.0/24 is subnetted, 5 subnets
 C 172.16.51.0 is directly connected, FastEthernet0/0
 O 172.16.43.0 [110/128] via 172.16.14.4, 00:10:45, Serial0/1
 O 172.16.23.0 [110/128] via 172.16.12.2, 00:10:55, Serial0/0
 C 172.16.12.0 is directly connected, Serial0/0
 C 172.16.14.0 is directly connected, Serial0/1

Låt oss testa en pinga från R5 – R6:

R5#ping 6.6.6.6 source 5.5.5.5
Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
 Packet sent with a source address of 5.5.5.5
 !!!!!
 Success rate is 100 percent (5/5), round-trip min/avg/max = 76/139/184 ms

Wohoo! 🙂 Känns som det får avsluta första inlägget om BGP, känns som detta kommer bli riktigt kul nördig som man är.. 🙂

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