Advanced CCIE Routing & Switching

Transcription

Advanced
CCIE Routing & Switching
v5.0
www.MicronicsTraining.com
Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP
VOL-III
CCIE R&S by Narbik Kocharians
Advanced CCIE R&S Work Book 5.0
© 2015 Narbik Kocharians. All rights reserved
Page 1 of 24
Lab 3 – OSPF Broadcast Networks
Lo0
2::2/64
Lo0
1::1/64
:2
:1
R2
R1
F0/0
F0/0
10::/64
Lo0
7::7/64
G0/0
Lo0
8::8/64
G0/0
:8
:7
R8
R7
Task 1
Configure the routers based on the above topology, DO NOT configure any routing
protocol. If this configuration is performed properly, these routers should be able to
ping their directly connected routers. The Link-local IPv6 address of the routers should
be set to fe80::1, fe80::2, fe80::7 and fe80::8 for routers R1, R2, R7 and R8 respectively.
On SW1:
SW1(config)#int range f0/1-2 , f0/7-8
SW1(config-if-range)#Swi mode acc
SW1(config-if-range)#Swi acc vl 100
SW1(config-if-range)#Spanning portf
SW1(config-if-range)#No shut
On R1:
R1(config)#int f0/0
Page 2 of 24
R1(config-if)#ipv6 address 10::1/64
R1(config-if)#ipv6 address fe80::1 Link-local
R1(config-if)#No shut
R1(config)#int lo0
On R2:
R2(config)#int f0/0
R2(config)#int lo0
On R7:
R7(config)#int g0/0
R7(config)#int lo0
On R8:
R8(config)#int g0/0
R8(config)#int lo0
To verify the configuration:
On R1:
R1#Ping 10::2
Type escape sequence to abort.
Page 3 of 24
Sending 5, 100-byte ICMP Echos to 10::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
R1#Ping 10::7
!!!!!
R1#Ping 10::8
!!!!!
Task 2
Configure OSPF area 0 on all routers and run their directly connected interfaces. Ensure
that loopback interfaces are advertised with their correct mask. You should configure
0.0.0.1, 0.0.0.2, 0.0.0.7 and 0.0.0.8 as the router IDs of R1, R2, R7 and R8 respectively.
R7 and R8 should use an address-family to accomplish this task. R7 should be the DR for
this segment.
On All Routers:
Rx(config)#ipv6 unicast-routing
Rx(config-router)#int lo0
Rx(config-if)#ipv6 ospf network point-to-point
On R1:
R1(config)#ipv6 router ospf 1
R1(config-rtr)#router-id 0.0.0.1
R1(config)#int f0/0
R1(config-if)#ipv6 ospf 1 area 0
Page 4 of 24
R1(config-if)#int lo0
On R2:
R2(config)#int f0/0
R2(config-if)#ipv6 ospf 1 are 0
R2(config-if)#ipv6 ospf 1 are 0
You should see the following console message:
%OSPFv3-5-ADJCHG: Process 1, Nbr 0.0.0.1 on FastEthernet0/0 from LOADING
to FULL, Loading Done
On R7:
R7(config)#router ospfv3 1
R7(config-router)#address-family ipv6 unicast
R7(config-router-af)#router-id 0.0.0.7
Just like OSPFv2 the router with the highest priority will be elected as the DR for that given segment, that’s
if all the routers on that given segment come up at the same time. But if the priority of all routers are the
same the tie breaker is the router-id, this means that the router with the highest router-id will win the DR
election.
R7(config)#int g0/0
R7(config-if)#ospfv3 1 ipv6 area 0
R7(config-if)#ospfv3 priority 2
%OSPFv3-5-ADJCHG: Process 1, IPv6, Nbr 0.0.0.1 on GigabitEthernet0/0 from
LOADING to FULL, Loading Done
Page 5 of 24
On R8:
R8(config-if)#int G0/0
To ensure that R7 is the DR, we need to clear ip ospf process on all routers:
R8#Clear ipv6 ospf process
Reset selected OSPFv3 processes? [no]: y
On R1:
R1#Show ipv6 route ospf
IPv6 Routing Table - default - 8 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
O
O
O
2::/64 [110/2]
via FE80::2, FastEthernet0/0
7::/64 [110/2]
8::/64 [110/2]
Page 6 of 24
R1#Show ipv6 ospf database network
OSPFv3 Router with ID (0.0.0.1) (Process ID 1)
Net Link States (Area 0)
LS age: 63
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Network Links
Link State ID: 3 (Interface ID of Designated Router)
Advertising Router: 0.0.0.7
LS Seq Number: 80000003
Checksum: 0xDD05
Length: 40
Attached Router: 0.0.0.7
We can see that it’s the DR that floods LSA Type 2s, and on this segment R7 is the DR with a router-id of
0.0.0.7; DR is the only router that is responsible for flooding Network LSAs or LSA Type-2s. We can also see
that Network LSAs also reveal the router IDs of all routers that are attached to this Broadcast Multiaccess
network.
On R8:
R8#Show ospfv3 neighbor
OSPFv3 1 address-family ipv6 (router-id 0.0.0.8)
Neighbor ID
0.0.0.1
0.0.0.2
0.0.0.7
Pri
1
1
2
State
FULL/DROTHER
FULL/DROTHER
FULL/DR
Dead Time
00:00:35
00:00:35
00:00:38
Interface ID
3
3
3
Interface
GigabitEthernet0/0
GigabitEthernet0/0
GigabitEthernet0/0
R8#Show ospfv3 data network
Net Link States (Area 0)
LS age: 536
Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
LS Type: Network Links
Link State ID: 3 (Interface ID of Designated Router)
Page 7 of 24
Advertising Router: 0.0.0.7
LS Seq Number: 80000003
Checksum: 0xDD05
Length: 40
Based on the output of the following show command we can see that hellos are exchanged every 10
seconds and the dead interval is set to 40 seconds:
R8#Show ospfv3 int g0/0 | Inc Timer
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Let’s see the destination address of OSPF hello messages on OSPF Broadcast network types:
R8#Debug ospfv3 hello
OSPFv3 hello debugging is on for process 1, IPv6, Default vrf
OSPFv3-1-IPv6 HELLO Gi0/0: Send hello to FF02::5 area 0 from FE80::8
interface ID 3
We can see that the hello messages are sent to a Multicast group address of FF02::5, this means that the
G0/0 interface of R8 must have joined this Multicast address, let’s see this information:
R8#Show ipv6 interface g0/0 | Inc FF
FF02::1
FF02::2
FF02::5
FF02::6
FF02::FB
FF02::1:FF00:8
We can see that R8 has joined many Multicast groups, let’s explain these groups:




FF02::1 – All nodes within the local segment
FF02::2 – All routers within the local segment, the local router will only join this group if the “IPv6
unicast-routing” command is configured.
FF02::5, and FF02::6 – These are OSPF groups, ::5 is all OSPF routers and ::6 is the DR/BDR. R7 is the
DR on this segment, but R8 is the BDR and this is why it has joined this group.
FF02::FB – This is the mDNS
Page 8 of 24

FF02::1:FF00:8 – The Solicited Node Multicast group.
R1#Undebug all
All possible debugging has been turned off
Let’s identify the major points of an OSPF Broadcast Network type:





Ethernet Networks default to OSPF Broadcast Network types.
The timers are 10/40, meaning that the Hello interval is 10 seconds and the dead interval is set to
40 seconds.
Next hop does NOT change. In the output of the above “Show ipv6 route ospf” command we can
see that the next hop IP address is the IP address of the F0/0 or the G0/0 interface of the router
that originated the route.
DR and optionally BDR election will take place in Broadcast Multiaccess networks such as Ethernet.
In Broadcast network types the hellos are sent to Multicast destination of FF02::5.
Task 2
Lab Setup:
To copy and paste the initial configurations, go to “Advanced-init” “IPv6”
“OSPFv3” Lab-3-Task-2.
Page 9 of 24
Lo0
1::1/64
.1
R1
F0/0
AREA 0
DMVPN
10::/64
:8
F0/0
G0/0
R8
8::8/64
Lo0
.2
G0/0
R2
:7
R7
2::2/64
Lo0
7::7/64
Lo0
Configure OSPFv3 on the tunnel and Loopback 0 interfaces of all routers based on the
following policy:





R1 is the hub and R2, R7, and R8 are configured as spokes, DO NOT change the
topology.
Configure the tunnel interfaces of all routers to be OSPFv3 broadcast network
type.
The Loopback interfaces should be advertised with their correct mask.
Configure the router-IDs of the routers to be 0.0.0.1, 0.0.0.2, 0.0.0.7, and 0.0.0.8
for R1, R2, R7 and R8 respectively.
The DMVPN network is configured, if you need to change the DMVPN network,
DO NOT configure it using dynamic mapping.
Before we configure OSPFv3 let’s see if we have reachability to the tunnel IPv6 addresses:
On R1:
Page 10 of 24
R1#Ping 10::2
!!!!!
R1#Ping 10::7
!!!!!
R1#Ping 10::8
!!!!!
On All Routers:
Rx(config)#IPv6 unicast-routing
On R1:
To see the interface ID of the tunnel:
R1#Show ipv6 inter br | B Tunne
Tunnel1
FE80::1
10::1
[up/up]
R1(config)#int lo0
R1(config-if)#ipv6 ospf network point-to-point
R1(config-if)#int tunnel 1
R1(config-if)#ipv6 ospf network broadcast
Page 11 of 24
On R2:
R2#Show ipv6 inter br | B Tunne
Tunnel2
FE80::2
10::2
[up/up]
R2(config)#int tunnel 2
R2(config-if)#ipv6 ospf network broadcast
R2(config)#int lo0
R2(config-if)#ipv6 ospf network point-to-point
On R7:
R7#Show ipv6 inter bri | B Tunne
Tunnel7
FE80::7
10::7
[up/up]
R7(config)#int lo0
R7(config-if)#ospfv3 network point-to-point
R7(config)#int tunn 7
R7(config-if)#ospfv3 network broadcast
On R8:
R8#Show ipv6 inter br | B Tunnel
Tunnel8
[up/up]
Page 12 of 24
FE80::8
10::8
R8(config)#int lo0
R8(config-if)#ospfv3 network point-to-point
R8(config-if)#int tunnel 8
R8(config-if)#ospfv3 network broadcast
On R1:
R1#Show ipv6 ospf neighbor
R1#
We can see that the routers did not establish an OSPFv3 adjacency. We know that in OSPF Broadcast
Network types the Hellos are sent to destination Multicast address of FF02::5, since we have configured
OSPFv3 on a NBMA network (DMVPN), let’s check and see if we provided Multicast capability:
On R1:
R1#Show run int tunnel 1 | B interface
interface Tunnel1
no ip address
no ip redirects
ipv6 address FE80::1 link-local
ipv6 address 10::1/64
ipv6 nhrp map 10::8/128 192.1.8.8
ipv6 nhrp map 10::7/128 192.1.7.7
ipv6 nhrp map 10::2/128 192.1.2.2
ipv6 nhrp network-id 111
ipv6 ospf network broadcast
ipv6 ospf 1 area 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end
Page 13 of 24
Based on the above output, we can see that Multicast is NOT mapped, let’s check R2:
On R2:
R2#Show run int tunnel 2 | B interface
interface Tunnel2
no ip address
no ip redirects
ipv6 address FE80::2 link-local
ipv6 address 10::2/64
ipv6 nhrp map 10::1/128 192.1.1.1
ipv6 nhrp network-id 222
ipv6 ospf network broadcast
ipv6 ospf 1 area 0
tunnel source FastEthernet0/0
tunnel mode gre multipoint
end
Actually we can see two problems in the above configuration, the first problem is that the configuration
does not provide support for Multicast traffic. The second problem is that the wrong IPv6 address is
mapped to the NBMA-IP. In IPv6, the routing protocols use the link local IPv6 address to establish
adjacency, but the output of the above show command reveals that the actual IPv6 address is mapped to
the NBMA-IP and not the link-local IPv6 address.
Let’s provide Multicast capability to R1 and R2’s Tunnel interface. To provide Multicast capability, we need
to map Multicast to the NBMA-IP address, the NBMA-IP is the IP address of the tunnel source.
On R1:
R1#Show run int f0/0 | Inc ip address
ip address 192.1.1.1 255.255.255.0
On R2:
R2#Show run int f0/0 | Inc ip address
ip address 192.1.2.2 255.255.255.0
On R1:
R1(config)#Int tunnel 1
R1(config-if)#ipv6 nhrp map multicast 192.1.2.2
Page 14 of 24
On R2:
Now, let’s map the correct IPv6 address to the NBMA-IP:
On R1:
R1(config-if)#No ipv6 nhrp map 10::2/128 192.1.2.2
R1(config-if)#ipv6 nhrp map fe80::2/128 192.1.2.2
On R2:
%OSPFv3-5-ADJCHG: Process 1, Nbr 0.0.0.2 on Tunnel1 from LOADING to FULL,
Loading Done
On R1:
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
O
2::/64 [110/1001]
via FE80::2, Tunnel1
Let’s fix the configuration of the hub (R1) for the other spokes (R7, and R8):
On R1:
Page 15 of 24
On R7:
%OSPFv3-5-ADJCHG: Process 1, IPv6, Nbr 0.0.0.1 on Tunnel7 from LOADING to
FULL, Loading Done
On R8:
R8(config)#int tun 8
%OSPFv3-5-ADJCHG: Process 1, IPv6, Nbr 0.0.0.1 on Tunnel7 from LOADING to
FULL, Loading Done
On R1:
R1#Show ipv6 ospf neighbor
Neighbor ID
0.0.0.2
0.0.0.7
0.0.0.8
Pri
1
1
1
State
FULL/DROTHER
FULL/DROTHER
FULL/DR
Dead Time
00:00:32
00:00:37
00:00:32
Interface ID
23
9
9
Interface
Tunnel1
Tunnel1
Tunnel1
Page 16 of 24
We can see that R8 which happens to be one of the spokes is the DR, we should always configure the hub
router as the DR, let’s configure this and verify:
On R2:
R2(config-if)#ipv6 ospf priority 0
R2#Show ipv6 ospf interface tunne 2 | inc Pri
Transmit Delay is 1 sec, State DROTHER, Priority 0
On R7:
R7(config-if)#ospfv3 priority 0
R7#Sh ospfv3 inter tunn 7 | in Pri
On R8:
R8(config-if)#ipv6 ospf priority 0
R8#Sh ospfv3 inter tunn 8 | in Pri
We need to clear the OSPF process for the changes to take affect:
On R2:
R2#Clear ipv6 ospf process
Reset ALL OSPF processes? [no]: Y
Page 17 of 24
On R7 and R8:
Rx#Clear ospfv3 process
Reset selected OSPFv3 processes? [no]: Y
On R8:
R8#Show ospfv3 neighbor
Neighbor ID
0.0.0.1
Pri
1
State
FULL/DR
Dead Time
00:00:30
Interface ID
23
Interface
Tunnel8
H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea
IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, ls - LISP site
ld - LISP dyn-EID, a - Application
O
O
O
1::/64 [110/1001]
2::/64 [110/1001]
7::/64 [110/1001]
R8#Ping 1::1
.....
Success rate is 0 percent (0/5)
The ping failed.
We know that on Broadcast network types the next-hop IP address is set based on the originating router,
we can see that in the routing table, the next-hop IPv6 address to reach 1::/64 network is FE80::1 which is
the link-local IPv6 address of R1, do we have an IPv6 nhrp mapping for that IPv6 address?
Page 18 of 24
Let’s verify:
R8#Show ipv6 nhrp
FE80::1/128 via FE80::1
Tunnel8 created 00:19:33, never expire
Type: static, Flags: used
NBMA address: 192.1.1.1
Let’s see if we can ping the link-local IPv6 address of R1:
R8#Ping fe80::1
Output Interface: Tunnel8
Sending 5, 100-byte ICMP Echos to FE80::1, timeout is 2 seconds:
Packet sent with a source address of FE80::8%Tunnel8
!!!!!
We are successful, does this mean that we must have an IPv6 nhrp mapping for the actual IPv6 address as
well?
Let’s configure and verify:
R8(config-if)#ipv6 nhrp map 10::1/128 192.1.1.1
On R1:
R1(config-if)#ipv6 nhrp map 10::8/128 192.1.8.8
On R8:
R8#Ping 1::1
!!!!!
OK, we can see why, the reason the pings failed initially was because the source IPv6 address of the ping
Page 19 of 24
was the tunnel’s IPv6 address and since we did not have any mapping configured for that IPv6 address, the
pings failed.
Does this mean that if the same ping was sourced from the loopback 0 interface of R8, it would be
successful?
Let’s try this; before we try, let’s examine the routing table of R8 and R7, they must have an ipv6 nhrp
mapping to the next-hop IPv6 address, let’s verify:
R8#Show ipv6 route 7::7
Routing entry for 7::/64
Known via "ospf 1", distance 110, metric 1001, type intra area
Route count is 1/1, share count 0
Routing paths:
FE80::7, Tunnel8
Last updated 00:32:19 ago
Let’s see if we have an IPv6 mapping for the next-hop IPv6 address of fe80::7:
R8#Show ipv6 nhrp
10::1/128 via 10::1
Type: static, Flags:
FE80::1/128 via FE80::1
No, the local router does not have an IPv6 nhrp mapping for the next-hop IPv6 address of FE80::7. Let’s
configure one:
Now, let’s check R7:
On R7:
R7#Show ipv6 route 8::/64
Routing entry for 8::/64
Known via "ospf 1", distance 110, metric 1001, type intra area
Page 20 of 24
Route count is 1/1, share count 0
Routing paths:
FE80::8, Tunnel7
Last updated 00:34:43 ago
R7#Show ipv6 nhrp
FE80::1/128 via FE80::1
Let’s configure an IPv6 nhrp mapping for the next-hop IPv6 address of fe80::8:
On R8:
R8#Ping 7::7 Source Lo0
Packet sent with a source address of 8::8
!!!!!
Perfect, it worked. Let’s configure IPv6 nhrp mappings on all routers in a full mesh manner:
On R2:
On R7:
Page 21 of 24
On R2:
R2#Ping 1::1 source Lo0
!!!!!
!!!!!
!!!!!
On R1:
!!!!!
!!!!!
Page 22 of 24
On R7:
!!!!!
NBMA networks can be configured in two ways: Point-to-point and/or Multipoint.
If the network (DMVPN in this case) is configured in a Point-to-point manner, the routers have Unicast,
Multicast and/or Broadcast capability. In Point-to-point networks, there can only be another router on the
other end of the link, so as long as the destination network is in the routing table, we should be able to
reach that destination.
If the network (DMVPN in this case) is configured in a Multipoint manner, we have unicast reachability
only, but Broadcast/Multicast capability can be available if it’s provided.
Since in multipoint networks there can potentially be more than one router on the other end of the tunnel
or link, the local router MUST have a mapping to the next-hop IPv6 address/es or else, NLRI can not be
achieved.
In this lab, since the spoke routers didn’t have NHRP mappings to the next-hop IPv6 address of the other
endpoints, they could not reach the advertised networks and we had to configure full mesh NHRP
mappings.
In broadcast network types the next-hop IP address is not changed, and if the network is NBMA in nature,
such as DMVPN, and it’s configured in Multipoint manner, we have to remember the following important
points:



Multicast capability must be provided.
Spokes must have NHRP mappings to the next-hop IPv6 address to have reachability to the
networks that other endpoints are advertising.
The hub router should be configured as the DR, and a BDR is not needed. To achieve this, the spoke
routers MUST have an OSPFv3 priority of zero so they never participate in DR election.
Page 23 of 24
Task 3
Erase the startup configuration of the routers, the config.text and the VLAN.dat of the
switches and reload them before proceeding to the next lab.
Page 24 of 24

Advanced CCIE Routing & Switching

Transcription

Similar documents

Internet Evolution in Oman 9th MENOG Meeting

VitalQIP 8.0 PR1 slides - Alcatel

How to still get connected from Iran using Your Freedom Document version

IPv6.br

IPv6 in Daily Use

Document 6464927

Details - VoiceBootcamp