CIS 185 CCNP ROUTE Ch. 8 Implementing IPv6 – Part 2 Rick Graziani Cabrillo College [email protected] Last Updated: Fall 2010

CIS 185 CCNP ROUTECh. 8 Implementing IPv6 – Part 2

Rick Graziani

Cabrillo College

[email protected]

Last Updated: Fall 2010

2

Materials

Book: Implementing Cisco IP Routing

(ROUTE) Foundation Learning Guide: Foundation learning for the ROUTE 642-902 Exam

By Diane Teare Book

ISBN-10: 1-58705-882-0 ISBN-13: 978-1-58705-882-0

eBook ISBN-10: 0-13-255033-4 ISBN-13: 978-0-13-255033-8

IPv6 Routing Protocols

Static routes RIP new generation (RIPng) (defined in RFC 2080, RIPng for IPv6) OSPFv3 (defined in RFC 5340, OSPF for IPv6) EIGRP for IPv6 Multiprotocol Border Gateway Protocol Version 4 (MP-BGP4 or

MBGP) (defined in RFC 2545, Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, and RFC 4760, Multiprotocol Extensions for BGP-4)

3

Ipv6 unicast-routing global configuration command enables IPv6 routing Required before any ipv6 routing protocol can be configured

4

Router(config)# ipv6 unicast-routing

IPv6 Static Routes

Types of static routes (same as IPv4) A directly attached static route is created using only the interface-type and

interface-number parameters.

Router(config)# ipv6 route 2001:CC1E::/32 serial 0/0/0

A recursive static route is created using only the next-hop address parameter.

Router(config)# ipv6 route 2001:CC1E::/32 2001:12::1

A fully specified static route includes both the outgoing interface and the next hop address.

Router(config)# ipv6 route 2001:CC1E::/32 ser 0/0/0 2001:12::1

A floating static route Router(config)# ipv6 route 2001:CC1E::/32 ser 0/0/0 15 5

Router(config)# ipv6 route ipv6-prefix/prefix-length {ipv6-address | interface-type interface-number [ipv6-address]} [administrative-distance] [administrative-multicast-distance | unicast | multicast] [next-hop-address] [tag tag]

6

R1(config)# ipv6 unicast-routingR1(config)# ipv6 route 13::/64 s0/1/0R1# show ipv6 route staticIPv6 Routing Table - 9 entries<output omitted>

S 13::/64 [1/0] via ::, Serial0/1/0

R2(config)# ipv6 unicast-routingR2(config)# ipv6 route ::/64 s0/1/0R2# show ipv6 route staticIPv6 Routing Table - 7 entries<output omitted>

S ::/64 [1/0] via ::, Serial0/1/0

Default ::

7

R1# ping 13::13:1 !!!!!

R1#

R2# ping 11::11:1 !!!!!

R2# ping 10::10:1 !!!!!

R2#

8

RIPng (the Next Generation)For Enterprise Networks

9

RIPv2 vs RIPngAdvertises routes for…Layer 3/4 protocolsUDP PortSource IP addressMulticast Update destination (All RIP

routers)AuthenticationUse Distance VectorDefault Administrative distanceSupports VLSMAutomatic summarizationUses Split HorizonUses Poison Reverse30 second periodic full updatesUses triggered updatesUses Hop Count metricMetric meaning infinitySupports route tags

IPv4 IPv6IPv4, UDP IPv6, UDP520 521IPv4 address IPv6 link-local

address224.0.0.9 FF02::9

RIP-specific uses IPv6 AH/ESPyes yes120 120yes yesyes N/Ayes yesyes yesyes yesyes yesyes yes16 16yes yes

10

R1(config)# ipv6 unicast-routing

R1(config)# interface FastEthernet0/0

R1(config-if)# ipv6 address 2012::1/64

R1(config-if)# ipv6 rip luigi enable

R1(config)# interface FastEthernet0/1



R1(config)# interface Serial0/0/0






R1(config)# ipv6 router luigi

Enable IPv6 routing

Configure an IPv6 addressing and enable RIPng, process “luigi"

Create the RIPng process named “luigi“

11

R3# show ipv6 routeIPv6 Routing Table - Default - 19 entriesCodes: C - Connected, L - Local, S - Static, U - Per-user Static

route B - BGP, M - MIPv6, R - RIP, I1 - ISIS L1<output omitted>

R 2005::/64 [120/3] via FE80::11FF:FE11:1111, Serial0/0/0 via FE80::22FF:FE22:2222, Serial0/0/1R 2012::/64 [120/2] via FE80::11FF:FE11:1111, Serial0/0/0 via FE80::22FF:FE22:2222, Serial0/0/1

All next-hop IP addresses that begin with FE80 – RIPng uses link local addresses as next-hop addresses.

RIPng over Frame Relay

See our text book for an example of RIPng over Frame Relay.

12

13

OSPFv3

OSPFv3

14

OSPF vs OSPFv3Advertises routes for…Layer 3 protocolIP Protocol TypeSource IP addressMulticast – all SPF routersMulticast – All Designated routersUses Link State logicSupports VLSMRID process, compared to OSPFv2LSA flooding and aging compared to OSPFv2Area structure compared to OSPFv2Packet typesLSA flooding and aging compared to OSPFv2RID 32-bit LSIDCost metric, bandwidthSupports route tagsDR/BDR election compared to OSPFv2Periodic re-flooding every…AuthenticationNeighbor checks compared to OSPFv2 (table 5-5)multiple instances per interface

IPv4 IPv6IPv4 IPv689 89IPv4 addressIPv6 link-local224.0.0.5 FF02::5224.0.0.6 FF02::6 yes yesyes yessame samesame samesame samesame samesame sameyes yesyes yesyes yesyes yesyes yes30 minutes 30 minutesOSPF-specific uses IPv6

AH/ESPsame no "same subnet"

checkno yes

15

OSPF Version 3 (OSPFv3) (RFC 2740) Router ID:

OSPFv3 uses the same process as OSPFv2 including an IPv4 address. If there are no IPv4 addresses configured, the router ID (IPv4 address)

must be explicitly configured.

Similar to OSPF for IPv4: Same mechanisms, but a major rewrite of the internals of the protocol

Updated features for IPv6: Every IPv4-specific semantic is removed Carry IPv6 addresses Link-local addresses used as source

OSPF interfaces connect to links instead of to IP subnets. Multiple IPv6 subnets can be assigned to a single link, and two nodes can

talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix), because they use the link-local addresses, rather than the global unicast addresses, to communicate.

OSPF for IPv6 therefore runs per-link instead of the IPv4 behavior of per-IP-subnet

OSPFv3 has explicit support for multiple instances per link through the instance ID field in the packet header. This feature allows separate routing domains, each running OSPF, to use a

common link. A single link could belong to multiple areas. Instances need to have the same instance ID to communicate with each

other. By default, the instance ID is 0

16

Example of two instances of OSPFv3 running on the same physical network segment, using two different IPv6 prefixes.

17

OSPFv3—Similarities with OSPFv2

OSPFv3 is OSPF for IPv6 (RFC 2740): Based on OSPFv2, with enhancements Distributes IPv6 prefixes Runs directly over IPv6

OSPFv3 & v2 can be run concurrently, because each address family has a separate SPF (ships in the night).

OSPFv3 uses the same basic packet types as OSPFv2: Hello Database description blocks (DDB) Link state request (LSR) Link state update (LSU) Link state acknowledgement (ACK)

Neighbor discovery and adjacency formation mechanism are identical. LSA flooding and aging mechanisms are identical.

The multicast addresses used by OSPFv3 are as follows: FF02::5—This address represents all SPF routers on the link-local scope;

it is equivalent to 224.0.0.5 in OSPFv2. FF02::6—This address represents all designated routers (DRs) on the

link-local scope; it is equivalent to 224.0.0.6 in OSPFv2.

18

Two routers and two areas Area 1 Area 0

19

Summarizes area 0’s routes to the 2001:410::/32 route

Creates the “ipv6 router ospf 100” process dynamically

Creates the “ipv6 router ospf 100” process dynamically

Enable the interface for OSPFv3



This network has three areas.

20

These routers do not have any IPv4 addresses configured, so the 32-bit router ID must be configured with the router-id command

21



R1(config-if)# ipv6 address 12:12::1/64

R1(config-if)# ipv6 ospf 1 area 0

R1(config)# interface Fa0/0



R1(config)# ipv6 router ospf 1

R1(config-router)# router-id 0.0.0.1










This output is from R2, and indicates that R2 has a FULL relationship with R1.

22

R2# show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface

0.0.0.1 1 FULL/ - 00:00:39 6 Serial0/1/0

R2# show ipv6 ospf interface serial 0/1/0Serial0/1/0 is up, line protocol is upLink Local Address FE80::219:55FF:FE92:B212, Interface ID 6Area 0, Process ID 1, Instance ID 0, Router ID 0.0.0.2Network Type POINT_TO_POINT, Cost: 64Transmit Delay is 1 sec, State POINT_TO_POINT,Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Hello due in 00:00:06Index 1/3/3, flood queue length 0Next 0x0(0)/0x0(0)/0x0(0)<output omitted>

R2 was configured earlier. Here is the configuration for

R4

23
















OSPF portion of R4’s routing table Includes the 12:12::/64 inter-area

route; the link between R1 and R2.

24

R4# show ipv6 route ospf

OI 12:12::/64 [110/65] via FE80::219:55FF:FE92:B212, FastEthernet0/0

R1 was configured earlier. Here is the configuration for

R3

25
















OSPF portion of R3’s routing table

26


OI 12:12::/64 [110/65] via FE80::219:56FF:FE2C:9F60, FastEthernet0/0

OI 24:24::/64 [110/66] via FE80::219:56FF:FE2C:9F60, FastEthernet0/0

R3# ping 24:24::4!!!!!

R3#

Area 13 can be configured to be a totally stubby area since the area has only one ABR which it can use to get anywhere outside of the area.

R3 now only has a default route (::/0), but it can still ping R4 successfully

27




R3(config-if)# ipv6 ospf 1 area 13 stub









R1(config-if)# ipv6 ospf 1 area 13 stub no summary



TotallyStubby

28

TotallyStubby


OI ::/0 [110/2] via FE80::219:56FF:FE2C:9F60, FastEthernet0/0

R3# ping 24:24::4!!!!!

R3#

R3 now only has a default route (::/0), but it can still ping R4 successfully.

29

EIGRP for IPv6

For Winnebago Networks

30

EIGRP vs EIGRP for IPv6

Advertises routes for…

Layer 3 protocol for EIGRP messages

Layer 3 header protocol type

UDP Port

Uses Successor, Feasible Successor

Uses Dual

Supports VLSM

Can perform automatic summarization

Uses triggered updates

Default metric bandwidth and delay

Multicast Update destination

Authentication

IPv4 IPv6IPv4 IPv688 88N/A N/Ayes yesyes yesyes yesyes N/Ayes yesyes yes224.0.0.10 FF02::10EIGRP-specific IPv6 AH/ESP

31

EIGRP RID decision steps based on IPv4 configuration:

1. Use the configured value (using the eigrp router-id a.b.c.d EIGRP subcommand under the ipv6 router eigrp command)

2. Use the highest IPv4 address on an up/up loopback interface

3. Use the highest IPv4 address on an up/up non-loopback interface

IOS lets you stop and start the EIGRP process with the shutdown and no shutdown router mode subcommands.

After initial configuration, the EIGRP for IPv6 process starts in shutdown mode,

1. To start the EIGRP process it is required to issue the no shutdown

EIGRP for IPv6

EIGRP for IPv6 configuration All interfaces have IPv6 addresses, including the three loopback interfaces

on R3.

32

33


R1(config)# interface Serial0/0/0.2 point-to-point


R1(config-if)# ipv6 eigrp 100




R1(config)# ipv6 router eigrp 100


R1(config-router)# no shutdown





R3(config)# interface loopback 301












34

R1# show ipv6 route eigrp

D 3:1::/64 [90/2297856] via FE80::3, Serial 0/0/0.3

D 3:2::/64 [90/2297856] via FE80::3, Serial 0/0/0.3

D 3:3::/64 [90/2297856] via FE80::3, Serial 0/0/0.3

35


















36


D 3:1::/64 [90/3321856] via FE80::2, Serial 0/0/0.2D 3:2::/64 [90/3321856] via FE80::2, Serial 0/0/0.2D 3:3::/64 [90/3321856] via FE80::2, Serial 0/0/0.2D 12::/64 [90/2681856] via FE80::2, Serial 0/0/0.2D 13::/64 [90/2681856] via FE80::2, Serial 0/0/0.2

R4# ping 3:1::3!!!!!

37

R4# show ipv6 eigrp neighbors

IPv6-EIGRP neighbors for process 1

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 Link-local address: Se0/0/0.2 14 01:50:51 3 200 0 82

FE80::2

38







R4(config-router)# eirgp stub


Remember an EIGRP stub router indicates in its hello packet to all neighboring routers its status as a stub router.

The neighboring routers do not query the stub router for any routes. Since R4 is a stub router, it should be configured as such, to stop

unnecessary queries going to it. If the link goes down between R3 and R1, there are no queries sent to R4

Only an update and a reply message are received, telling R4 about the deleted route.

X

No EIGRP Queries sent to R4 EIGRP

Update

EIGRP Reply

Stub

39

EIGRP Summary





R3(config-if)# ipv6 summary-address eigrp 100 3::/16













Another feature supported by EIGRP for IPv6 is route summarization.

Unlike EIGRP for IPv4, this protocol does not automatically summarize

40

EIGRP Summary





R3(config-if)# ipv6 summary-address eigrp 100 3::/16














D 3::/16 [90/3321856] via FE80::2, Serial 0/0/0.2D 12::/64 [90/2681856] via FE80::2, Serial 0/0/0.2D 13::/64 [90/2681856] via FE80::2, Serial 0/0/0.2

R4# ping 3:1::3!!!!!

MBGP

41

Multiprotocol BGP IPv6-specific extensions incorporated into MBGP include the following:

The NEXT_HOP and Network Layer Reachability Information (NLRI) attributes are expressed as IPv6 addresses and prefixes.

Operates by identifying two separate protocols: Carrier protocol Passenger protocol

42

BGP: IPv4 PrefixesTCP Header

IPv4 Header


IPv4 Header


IPv6 Header

In an all-IPv4 environment, BGP establishes sessions using IPv4 IPv4 is the carrier protocol

The routes that BGP advertises are also IPv4 IPv4 is also the passenger protocol

43


IPv4 Header

Protocols other than IPv4 also need to advertise reachability information: MPLS VPN Multicast IPv6 prefixes for BGP

MBGP extensions allow these and other protocols to be carried using BGP. An analogy is that BGP is a truck that can transport multiple payloads.

BGP “truck” (IPv4) could be used to transport “payloads” (IPv6 prefixes) The carrier protocol is IPv4 The passenger protocol is IPv6 prefixes being advertised )44


IPv4 Header

In an all IPv6 environment, BGP can be used as both the: Carrier protocol Passenger protocol Both the truck and the payload are IPv6

In this case IPv6 is used to: Establish BGP sessions BGP advertises IPv6 prefixes

45


IPv6 Header

The first section: router bgp configuration defines a 32-bit router ID (which must be

configured in an IPv6-only network) The peering session is established using IPv6, so IPv6 is the carrier

protocol. The second section:

address-family ipv6 command defines the passenger protocol, the protocol that is to be advertised using MBGP.

The passenger protocol is IPv6. 46


IPv6 Header

Policy-based routing (PBR) allows the network administrator to define a routing policy other than destination-based routing using the routing table. Sometimes called traffic engineering Provide a higher degree of control over routing Available for both IPv4 and IPv6

Like IPv4, IPv6 PBR is based on: match commands for identifying the traffic to be policy-based routed set commands for defining how that traffic will be routed

47

IPv6 Policy Base Routing (PBR)

Recall that PBR is configured on the interface that receives the traffic that should be routed differently than the default path.

R1: The traffic is received on the FastEthernet 0/0 interface If the packets are from R4’s loopback interface, they will be routed via R3

Otherwise they will be routed normally, through R2. Notice the ipv6 commands which are similar to ipv4:

match ipv6 address ipv6 access-list permit ipv6

Can verify with ping and debug ipv6 policy commands 48

R1(config)# interface fa 0/0

R1(config-if)# ipv6 policy route-map PBR_SOURCE_ADDRESS

R1(config)# route-map PBR_SOURCE_ADDRESS permit 10

R1(config-route-map)# match ipv6 address SOURCE_104

R1(config-route-map)# set ipv6 next-hop 123::3

R1(config)# ipv6 access-list SOURCE_104

R1(config-ipv6-acl)# permit ipv6 104::/64 any

IPv6 Redistribution

49

IPv6 Redistribution

Similar to IPv4, IPv6 routing information can be redistributed between routing protocols, and between instances of routing protocols.

The examples used in this section are a bit complex, maybe more than they need to be, but…

This also is a good review of IPv4 redistribution. It’s exactly the same only different.

50

Routers R1, R2, and R3 will all be configured for RIP but in two different RIP processes: R1R2 R1R3

The networks on the R2 and R3 loopback and lower serial interfaces will be redistributed into the RIP processes.

51

RIPng Redistribution

R1: We are only configuring the RIP process R1R3

R2: We have only configured the RIP process R1R2.

52


R2(config)# interface Serial0/0/0.1

R2(config-if)# ipv6 rip R1R2 enable

R2(config)# ipv6 router rip R1R2





Since the processes are different, we may expect that R2 would only send, and not receive, updates from R1.

The debug output shows both sending and receiving happening Notice that both processes by default use the FF02::9 multicast group address

(for all RIPng routers) and use port 521. 53









R2# debug ipv6 rip 1

2

1

2

R2, the redistribute connected command is configured under the R1R2 R2 will advertise its connected routes (24::/64 and 102::/64) to R1. The update is using the default FF02::9 multicast group address (for all RIPng

routers) and port 521. The connected routes are being redistributed with a default metric of 1.

54









R2(config-router)# redistribute connectedR2# debug ipv6 rip

R1’s routing table contains routes to R2’s loopback and serial interface networks

55









R2(config-router)# redistribute connected

R1# show ipv6 route rip

R 24::/64 [120/2] via FE80::2, Serial0/0/0R 102::/64 [120/2] via FE80::2, Serial0/0/0

R3, enabling the R1R3 RIPng process. Viewing R3’s routing table confirms that it is also learning R2’s redistributed

routes, network 24::/64 and 102::/64. All three of the RIPng routers are:

Advertising to the same multicast address using the same port number Therefore learning from each other.

56






R3(config)# interface Serial1/1.7



R3# show ipv6 route rip

R 24::/64 [120/3] via FE80::2, Serial1/1.7R 102::/64 [120/3] via FE80::2, Serial1/1.7

To segregate the RIPng domains, the port number and or the multicast group address parameters must be changed.

Changing the port number to 1013 on R3 and R1 (for the R1R3 process). The multicast group address was left as the default FF02::9. The routing tables on both routers are checked

there are no longer any RIP routes on either router. R1 and R3 are no longer listening to the updates from R2, because they are using

different ports. 57





R1(config-router)# port 1013 multicast-group FF02::9


R3(config)# interface Serial1/1.7




Port 1013Dest FF02::9


R3# clear ipv6 route *R3# show ipv6 route rip

R3#

To allow R1 and R3 to see R2’s connected routes again: R1 is first configured to be part of the R1R2 process

R1 again sees the routes sent (redistribute connected) from R2 R1 remains in the R1R3 process too R1 configured to redistribute the R1R2 routes into the R1R3 process. R1 configured to redistribute the R1R3 routes into the R1R2 process

R3’s routing table shows the R1R2 redistributed networks 24::/64 and 102::/64 Notice that the directly connected network 123::2/64 was not redistributed.

58







R1(config-router)# redistribute R1R2





R3# show ipv6 route ripR 24::/64 [120/3] via FE80::1, Serial1/1.7R 102::/64 [120/3] via FE80::1, Serial1/1.7

In IPv4, if you redistribute a protocol, by default you also redistribute the subnet on the interfaces over which the protocol is running.

In IPv6 this is not the default behavior. To redistribute the subnet on the interfaces over which the protocol is running in IPv6, use:

include-connected keyword redistribute-connected router command

59












R3# show ipv6 route ripR 24::/64 [120/3] via FE80::1, Serial1/1.7R 102::/64 [120/3] via FE80::1, Serial1/1.7

The metrics of redistributed routes can be changed with route maps. R3 is configured to redistribute its connected

routes Loopback is advertised with a metric of 5 hops Serial network is advertised with a metric of 15

hops. Thus, when these metrics get to R1, they will be 6

hops and 16 hops respectively.60

<some configuration omitted>




R3(config-router)# redistribute connected route-map CONN_PREFIX

R3(config)# route-map CONN_PREFIX permit 10

R3(config-r-map)# match ipv6 address PREFIX_34

R3(config-r-map)# set metric 15

R3(config)# route-map CONN_PREFIX permit 20

R3(config-r-map)# match ipv6 address prefix-list PREFIX_103

R3(config-r-map)# set metric 5

R3(config)# ipv6 access-list PREFIX_34


R3(config)# ipv6 prefix-list PREFIX_103 permit 103::/64

If there is a match the metric is set to 15 (hops)

If there is a match the metric is set to 5 (hops)

15 hops

5 hops

R1 has learned about network 103::/64 with a metric of 6. However R1 has no knowledge of network 34::/64 because it had reached a metric of

16(unreachable) This example shows the importance of the seed metric value chosen when redistributing.

R1# show ipv6 route ripR 24::/64 [120/2] via FE80::2, Serial1/1.7R 102::/64 [120/2] via FE80::2, Serial1/1.7R 103::/64 [120/6] via FE80::1, Serial1/1.7

Disclaimer: This example is probably more complex than it needs to be but it is a good review of redistribution and route filtering.

Extending our previous example, we will be redistributing: Connected interfaces into OSPFv3 Redistributing between different OSPFv3 processes Redistributing between OSPFv3 and RIPng

Issues examined include: Metrics used in distribution Suboptimal routing Routing loops encountered and resolved

62

Redistribution: RIPng and OSPFv3

L104:104::1/64

Confirm that the mutual redistribution is configured and working between the two RIP processes

show ipv6 protocols show ipv6 rip

63

L104:104::1/64

First we redistribute R3’s connected loopback interface into OSPFv3 on R3 Redistributes the connected routes with:

metric type 1 tag of 3333 route map called LOOPBACKS.

Metric type 1 (OE1) routes add the external cost to the internal cost of each link Metric type 2 (OE2) routes (default) the cost of these routes is always the external cost only. Route map LOOPBACKS matches routes permitted by the ACL L103, only the loopback

interface network to be redistributed into OSPFv3. 64


R3(config-router)# redistribute connected metric-type 1 tag 3333 route-map LOOPBACKS

R3(config)# route-map LOOPBACKS permit 10

R3(config-r-map)# match ipv6 address L103

R3(config)# ipv6 access-list L103



OI 102::1/128 [110/64] via FE80::2, Serial 0/0/0.2OE1 103::/64 [110/84], tag 3333 via FE80::3, Serial0/0/0.3

Tag 3333Metric type 1

L104:104::1/64

R2 and R3 do not see any OSPFv3 networks yet (everything is directly connected) R4 must be configured to redistribute between its two OSPFv3 processes Connected routes are also redistributed into both processes.

65


R4(config-router)# redistribute ospf 2




R4(config-router)# redistribute connected Tag 3333Metric type 1

L104:104::1/64

All routes appear on both routers.

R2 and R3 see all other routes as type 2.

Since type 2 routes do not include the internal network cost, suboptimal routing could result.

66








OE2 34::/64 [110/20] via FE80::4, Serial 0/0/0.4OE2 103::/64 [110/84], tag 3333 via FE80::4, Serial 0/0/0.4OE2 104::/64 [110/20] via FE80::4, Serial 0/0/0.4

Tag 3333Type 1


OE2 24::/64 [110/20] via FE80::4, Serial 0/0/0.4OE2 102::1/128 [110/64] via FE80::4, Serial 0/0/0.4OE2 104::/64 [110/20] via FE80::4, Serial 0/0/0.4

L104:104::1/64

Now configure mutual redistribution between RIPng and OSPFv3, starting on R2 OSPFv3 and connected routes are redistributed into RIPng RIPng and connected routes are redistributed into OSPFv3

Routes redistributed into RIP must have a metric configured otherwise they are considered “unreachable”

Routes redistributed into OSPF have a default metric of 20 67



R2(config-router)# redistribute ospf 1 metric 1



R2(config-router)# redistribute rip R1R2

L104:104::1/64







68







L104:104::1/64







R1# show ipv6 route ripR 24::/64 [120/2] via FE80::2, Serial0/0/0R 34::/64 [120/2] via FE80::3, Serial0/0/0R 102::/64 [120/2] via FE80::2, Serial0/0/0R 102::1/128 [120/2] via FE80::3, Serial0/0/0R 103::/64 [120/2] via FE80::3, Serial0/0/0R 104::/64 [120/2] via FE80::2, Serial0/0/0

R1 sees all networks but let’s make sure it is optimal routing.

69

L104:104::1/64

R3# show ipv6 route | 10[14]::/64

OE2 101::/64 [110/20] via FE80::4, Serial 0/0/0.4OE2 104::/64 [110/20] via FE80::4, Serial 0/0/0.4

R4 trace - The path goes through R2 (24::2) and then to R1, which is the optimal path.

Also shown in R3’s routing table Command and regular expression

section 10[14]::64 means that only networks 101 or 104 are displayed).

R3 is learning about both 101 and 104 via R4 with OSPFv3 (AD = 110)

However it would be better to get to 101 via R1 with RIPng (AD = 120)

This is suboptimal routing. A trace from R3 to the 101 loopback

confirms that it goes via R4, to R2, and then to R1.

70

L104:104::1/64

R3# show ipv6 route | 10[14]::/64


R3 is learning about 101 from both: R1 via RIPng (AD = 120) R4 via OSPFv3 (AD = 110)

The OSPFv3 route preferred because of the lower administrative distance

This can be easily fixed but there are other problems when multiple routers doing redistribution such as routing loops (feedback loops).

AD 120

AD 110

Solution Redistribute OSPFv3 routes into RIPng, but prevent those same routes

from going back into OSPFv3 Redistribute RIPng routes into OSPFv3, but prevent those same routes

from going back into RIPng. Route filtering can be configured to implement this solution.

71

X X

X X

L104:104::1/64

72



R3(config-router)# redistribute ospf 2 metric 1 route-map OSPF_TO_RIP

R3(config)# route-map OSPF_TO_RIP deny 10

R3(config-r-map)# match ipv6 address prefix-list RIP_NATIVE

R3(config)# route-map OSPF_TO_RIP permit 20

R3(config)# ipv6 prefix-list RIP_NATIVE seq 5 permit 101::/64


R1(config-router)# redistribute rip R1R2 route-map RIP_NOT_OSPF



R1(config)# route-map RIP_NOT_OSPF permit 10


R1(config)# route-map RIP_NOT_OSPF deny 20








73

RIPng process – redistribution is modified to refer to a route map OSPF_TO_RIP OSPF_TO_RIP route map:

Denies routes matched by the RIP_NATIVE ACL from being redistributed RIP_NATIVE ACL identifies the R1 loopback network 101

Permits all other routes to be redistributed. Network 101 will be denied from being redistributed into RIPng, because it was

originally a RIPng learned route. All other routes will be redistributed.

L104:104::1/64







X

74

Exactly the same for R3 RIPng process – redistribution is modified to refer to a route map OSPF_TO_RIP OSPF_TO_RIP route map:

Denies routes matched by the RIP_NATIVE ACL from being redistributed RIP_NATIVE ACL identifies the R1 loopback network 101

Permits all other routes to be redistributed. Network 101 will be denied from being redistributed into RIPng, because it was originally a RIPng

learned route. All other routes will be redistributed.

L104:104::1/64







X








75









R1 configuration filters routes going between the two RIP processes. In each RIP process redistribution modified to refer to a route map RIP_NOT_OSPF The route map permits only routes that match the prefix list RIP_NATIVE to be redistributed; only

the 101 network matches. Only the RIPng network 101 is redistributed between the two RIP processes No other routes (ones from OSPFv3) will be redistributed into the other RIP process.

L104:104::1/64






















Routing Loops fixed butNeed to address suboptimal routing

77

L104:104::1/64

R3# show ipv6 route | 10[14]::/64


Suboptimal Routing R3 is learning about 101 from both:

R1 via RIPng (AD = 120) R4 via OSPFv3 (AD = 110)

The OSPFv3 route preferred because of the lower administrative distance

AD 120

AD 110

Solution: Give RIPng preference, with a lower administrative distance, for those networks that should be learned via RIPng Use the distance command under the RIPng process.

R3 and R2: RIP administrative distance is set to 109 (lower than the OSPFv3 AD 110. R2 and R3: Routing tables confirm that R2 and R3 now reach the 101 network via

RIPng. Pings and traceroutes network has full end-to-end connectivity.

78

L104:104::1/64


R2(config-router)# distance 109

R2# show ipv6 route | 10[14]::/64R 101::/64 [109/2] via FE80::4, Serial 0/0/0.123OE2 104::/64 [110/20] via FE80::4, Serial 0/0/0.4


R3(config-router)# distance 109

R3# show ipv6 route | 10[14]::/64R 101::/64 [109/2] via FE80::4, Serial 0/0/0.123OE2 104::/64 [110/20] via FE80::4, Serial 0/0/0.4

AD 120

AD 110

AD 109

To summarize the issues and solutions observed in this example: OSPFv3 does not redistribute connected networks by default The metric and metric type may be reset when redistributing:

Solution: Explicitly configure the seed metric and metric type. Redistribution may cause suboptimal routing and routing loops:

Solutions: Change AD and apply route filtering (route maps). 79

Not covered in this section of Chapter 8: RIPng, OSPFv3, and MBGP Redistribution

80

CIS 185 CCNP ROUTECh. 8 Implementing IPv6 – Part 2

Rick Graziani

Cabrillo College

[email protected]

Last Updated: Fall 2010

Documents

CIS 185 CCNP ROUTE Ch. 8 Implementing IPv6 – Part 2 Rick Graziani Cabrillo College [email protected] Last Updated: Fall 2010