IPv6 routing protocol redistribution


Though the transition period from IPv4 to IPv6 is going to last for a long time in which both protocols will coexist, we shouldn’t forget that the final goal of IPv6 is to completely replace IPv4.

The best way to gain more experience with the new intricacies and challenges of IPv6 is to test IPv6-based services in the presence of IPv4 as well in a pure IPv6 environment.

The purpose of this lab is to test redistribution between IPv6 routing protocols in an exclusively IPv6 environment.

So I am following exactly the same scenario as the previous post about IPv4 redistribution and I will point out some particularities related to IPv6.

I will start by the problematic design of redistribution from one routing domain into another with lower (better) administrative distance.

If you are not familiar with routing redistribution I strongly recommend you to take a look at the previous post.

Redistribution from one routing domain into another with lower (better) administrative distance:

All the following topologies are subject to the same concept:

As an example, I picked up the case where the source routing domain is EIGRP (internal prefix AD =90 and external prefix AD = 170) and the destination domain is OSPF with a better AD of 110.

Picture 1: Lab High level design


Picture 2: Low level design


Lab content:

1- Redistribution
2- Test connectivity from the BR R1
3- Solutions to overcome suboptimal paths
   3.1- Control paths by controlling the redistribution at the border routers
   3.2- Change the AD per-prefixes
   3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list
   3.4- Prefix summarization
4- Troubleshooting notes5- Conclusion

1- Redistribution

- Redistribute 2001:DB8:123:3333::/64 (external domain/connected) into EIGRP at R3

The network 2001:DB8:123:3333::/64 can be administred with a different IGP than EIGRP or just a directly connected network (a loopback interface in our case).

Because EIGRP differentiates between internal and external prefixes by assigning different Administrative Distances, the prefix 2001:DB8:123:3333::/64 become (D EX) with AD=170.

ipv6 router eigrp 123
router-id 3.3.3.33
no shutdown
redistribute ospf 123 metric 1500 1 100 1 1500 route-map to-eigrp include-connected
!
ipv6 prefix-list ospf-pfx seq 5 permit 2001:DB8:123:3333::/64
!

!

route-map to-eigrp permit 10

match ipv6 address prefix-list ospf-pfx

set tag 3333

Picture 3: redistribution at R3:


- Mutual redistribution between EIGRP & OSPF at R2

For the sake of simplicity, EIGRP prefixes are redistributed into OSPF and vice-verse on R2.

R2:

ipv6 router eigrp 123
router-id 2.2.2.2
no shutdown
redistribute ospf 124 metric 1500 1 100 1 1500 include-connected
!
ipv6 router ospf 124
router-id 2.2.2.22

log-adjacency-changes

redistribute eigrp 123 route-map from-eigrp include-connected

!

!ipv6 prefix-list eigrp-prfx seq 10 permit 2001:DB8:123:2222::/64

ipv6 prefix-list eigrp-prfx seq 20 permit 2001:DB8:123:1111::/64

ipv6 prefix-list eigrp-prfx seq 30 permit 2001:DB8:123:13::/126

ipv6 prefix-list eigrp-prfx seq 40 permit 2001:DB8:123:23::/126

!

ipv6 prefix-list ospf-prfx seq 10 permit 2001:DB8:124:14::/126

ipv6 prefix-list ospf-prfx seq 20 permit 2001:DB8:124:24::/126

ipv6 prefix-list ospf-prfx seq 30 permit 2001:DB8:124:4444::/64

!

!

route-map from-ospf permit 10

match ipv6 address prefix-list ospf-prfx

!

route-map from-eigrp permit 10

match ipv6 address prefix-list eigrp-prfx

!

route-map from-eigrp permit 20

match tag 3333

R1:

ipv6 router eigrp 123
router-id 1.1.1.11
no shutdown
!
ipv6 router ospf 124
router-id 1.1.1.1

Picture4: Mutual redistribution between EIGRP & OSPF at R2


2-Test connectivity from the BR R1

R1#sh ipv6 route
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3333::/64 [110/20], tag 3333

via FE80::C003:42FF:FED8:0, FastEthernet0/0


R1#

R1#sh ipv6 eigrp topology
IPv6-EIGRP Topology Table for AS(123)/ID(1.1.1.11)

P 2001:DB8:123:3333::/64, 0 successors, FD is Inaccessible, tag is 3333

via FE80::C002:42FF:FED8:0 (1732352/1706752), FastEthernet0/1


R1#

R1#sh ipv6 eigrp topology
IPv6-EIGRP Topology Table for AS(123)/ID(1.1.1.11)Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status

P 2001:DB8:124:14::/126, 0 successors, FD is Inaccessible

via FE80::C002:42FF:FED8:0 (1757952/1732352), FastEthernet0/1

P 2001:DB8:123:13::/126, 1 successors, FD is 281600

via Connected, FastEthernet0/1

P 2001:DB8:123:1111::/64, 1 successors, FD is 128256

via Connected, Loopback1

P 2001:DB8:123:3333::/64, 0 successors, FD is Inaccessible, tag is 3333

via FE80::C002:42FF:FED8:0 (1732352/1706752), FastEthernet0/1

P 2001:DB8:123:2222::/64, 1 successors, FD is 435200

via FE80::C002:42FF:FED8:0 (435200/409600), FastEthernet0/1

P 2001:DB8:124:24::/126, 0 successors, FD is Inaccessible

via FE80::C002:42FF:FED8:0 (1757952/1732352), FastEthernet0/1

P 2001:DB8:123:23::/126, 1 successors, FD is 307200

via FE80::C002:42FF:FED8:0 (307200/281600), FastEthernet0/1

P 2001:DB8:124:4444::/64, 0 successors, FD is Inaccessible

via FE80::C002:42FF:FED8:0 (1757952/1732352), FastEthernet0/1

R1#

R1#sh ipv6 route 2001:DB8:123:3333::3/64
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3333::/64 [110/20], tag 3333

via FE80::C003:42FF:FED8:0, FastEthernet0/0


R1#

0 Successor(s), FD is 4294967295 (Inaccessible)

Is seen in the EIGRP topology table (IPv4/IPv6). Remember that in a border router each protocol will separately calculate the route to a given destination and submit it to the RIB for the “competition”. The RIB will choose the best route to the prefix+mask and the unique winner protocol is the one with the lowest administrative distances.

Other protocols (losers) not happy with the decision of the RIB will mark their best route in their protocol table

  • EIGRP uses “0 Successor(s), FD is 4294967295 (Inaccessible)”
  • BGP uses “r> (RIB-failure)”

So EIGRP calculated a route to 2001:DB8:123:3333::3/64 directly through R3 and OSPF calculated a route to the same prefix 2001:DB8:123:3333::3/64 through R4.

The RIB will choose OSPF of course because it has better (smaller) administrative distance of 110 against 170 for EIGRP.

R1#ping ipv6 2001:DB8:123:3333::3Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:123:3333::3, timeout is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 60/68/84 ms

R1#

R1#traceroute ipv6 2001:DB8:123:3333::3

Type escape sequence to abort.

Tracing the route to 2001:DB8:123:3333::3

1 2001:DB8:124:14::2 32 msec 20 msec 20 msec

2 2001:DB8:124:24::1 48 msec 56 msec 40 msec

3 2001:DB8:123:3333::3 84 msec 32 msec 76 msec

R1#

Picture 5: primary path


The primary path to the prefix 2001:DB8:123:3333::3 is chosen through OSPF domain which is suboptimal because it is 1st redistributed into EIGRP123 then a second time into OSPF124.

We know that during redistribution between different protocols there is inevitable loss of homogeneity of routing information due to deformation of criteria: attributes for BGP, BW and delay for EIGRP, cost for OSPF and hop for RIP.

So what we can do at the border router to influence the choice of the best route to a given prefix?

3- Solutions

  • 3.1- Control paths by controlling the redistribution at the border routers:

    This could be a case where your routing and security policies do not allow to reveal your internal prefixes and traffic to an external domain.

  • 3.2- Change the AD per-prefixes:

    In case you need to guarantee route redundancy for internal traffic even through external domains.

  • 3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list.
  • 3.4- Perform summarization to shorter subnet mask on the source router (remove from the competition by transform)

    So at the destination router receiving the update the longest prefix is selected

3.1- Control paths by controlling the redistribution at the border routers:

Simply do not make redundant or unnecessary redistribution, remember the split horizon between domains with multiple border routers:

DO NOT redistribute a prefix to its domain of origin, if needed, make the metric worse than those internally available.

3.2- Change the AD per-prefixes:

ipv6 router ospf 124
distance ospf external 180

R1(config-rtr)#do route6
IPv6 Routing Table – 14 entries

D 2001:DB8:123:23::/126 [90/307200]

via FE80::C002:42FF:FED8:0, FastEthernet0/1


D 2001:DB8:123:2222::/64 [90/435200]

via FE80::C002:42FF:FED8:0, FastEthernet0/1

EX 2001:DB8:123:3333::/64 [170/1732352], tag 3333

via FE80::C002:42FF:FED8:0, FastEthernet0/1


R1(config-rtr)#

Now prefixes originated from EIGRP, including the redistributed 2001:DB8:123:3333::/64, are reachable through EIGRP, because their OSPF EXT variants have worse administrative distance 180 against 170.

R1(config-rtr)#do sh ipv6 ospf data OSPFv3 Router with ID (1.1.1.1) (Process ID 124)

Type-5 AS External Link States

ADV Router Age Seq# Prefix

2.2.2.22 970 0x80000006 2001:DB8:123:13::/126

2.2.2.22 970 0x80000006 2001:DB8:123:23::/126

2.2.2.22 970 0x80000006 2001:DB8:123:1111::/64

2.2.2.22 970 0x80000006 2001:DB8:123:2222::/64

2.2.2.22 970 0x80000006 2001:DB8:123:3333::/64

R1(config-rtr)#

Let’s simulate a failure in the link between R1 and R3:

R3(config)#int fa0/0
R3(config-if)#sh
R3(config-if)#
*Mar 1 04:26:19.938: %DUAL-5-NBRCHANGE: IPv6-EIGRP(0) 123: Neighbor FE80::C000:42FF:FED8:1 (FastEthernet0/0) is down: interface down
*Mar 1 04:26:21.910: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 1 04:26:22.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
R3(config-if)#

Now, EIGRP prefixes reachable through OSPF.

R1(config-rtr)#do sh ipv6 route
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:23::/126 [180/20]
via FE80::C003:42FF:FED8:0, FastEthernet0/0
OE2 2001:DB8:123:2222::/64 [180/20]
via FE80::C003:42FF:FED8:0, FastEthernet0/0

OE2 2001:DB8:123:3333::/64 [180/20], tag 3333

via FE80::C003:42FF:FED8:0, FastEthernet0/0


R1(config-rtr)#

3.3- Filter prefixes from IGPs into the routing table using inbound distribute-list.

Before applying distribute list inbound under OSPF

IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3333::/64 [110/20], tag 3333
via FE80::C003:42FF:FED8:0, FastEthernet0/0

R1#

R1:

R1(config)#ipv6 router ospf 124
R1(config-rtr)#distribute-list prefix-list 3333_prfx in
R1(config-rtr)#exit
R1(config)#ipv6 prefix-list 3333_prfx deny 2001:DB8:123:3333::/64
R1(config)#ipv6 prefix-list 3333_prfx seq 10 permit ::/0 le 128

Note the default route used in the prefix-list ::/0 le 128 is different from the one used in IPv6 default static route abd the routing table ::/0

R1(config)#do route6
IPv6 Routing Table – 14 entries

EX
2001:DB8:123:3333::/64 [170/1732352], tag 3333
via FE80::C002:42FF:FED8:0, FastEthernet0/1

R1(config)#

3.4- Prefix summarization:

Let’s perform summarization of the prefix 2001:DB8:123:3333::3 on R3 to a shorter mask length of /60 before announcing it to R4 then to R1.

R4 before summarization:

R4#route6
IPv6 Routing Table – 14 entries

via FE80::C001:42FF:FED8:0, FastEthernet0/1
OE2
2001:DB8:123:3333::/64 [110/20], tag 3333

R4#

R1 before summarization:

R1(config-rtr)#do route6
IPv6 Routing Table – 15 entries

EX
2001:DB8:123:3333::/64 [170/1732352], tag 3333
via FE80::C002:42FF:FED8:0, FastEthernet0/1

R1(config-rtr)#

To keep the routing information consistent inside OSPF area, summarization has to be done at the ABR or ASBR.

Summarization on R2 (ASBR router):

R2(config)#no router ospf 124
R2(config-rtr)#summary-prefix 2001:DB8:123:3333::3/60

Now let’s take a look again at the routing table of R1 and R4:

R4#route6
IPv6 Routing Table – 14 entries

OE2 2001:DB8:123:3330::/60 [110/20]
via FE80::C001:42FF:FED8:0, FastEthernet0/1

R4#

R1(config-rtr)#do route6
IPv6 Routing Table – 16 entries

OE2 2001:DB8:123:3330::/60 [110/20]

via FE80::C003:42FF:FED8:0, FastEthernet0/0

EX 2001:DB8:123:3333::/64 [170/1732352], tag 3333

via FE80::C002:42FF:FED8:0, FastEthernet0/1


R1(config-rtr)#

R1 has received the summary address 2001:DB8:123:3330::/60 and consider it as different from 2001:DB8:123:3333::/64 received through EIGRP.

To forward traffic, RIB will chooses the longest match i.e. 2001:DB8:123:3333::3

R1#traceroute ipv6 2001:DB8:123:3333::3
 
Type escape sequence to abort.

Tracing the route to 2001:DB8:123:3333::3

1 2001:DB8:123:3333::3 60 msec 24 msec 60 msec

R1#

 

4-Troubleshooting notes

*) Redistribution doesn’t work :
- Check typing errors in route-maps and prefix-lists names because IOS will not alert you in case of the following errors during redistribution:
– Wrong route map name
– Wrong ACL/prefix-list name inside the route-map
– Default metric not configured (EIGRP/RIP/IS-IS)
- Check whether the prefix you want to redistribute exists in the RIB of the border router and belongs to the IGP source of the redistribution.
- IPv6 routing requires only link-local addresses (fe80::/10) to a establish the relationships within a segment, even if the mask or the subnet doesn’t match.

The discrepancies will emerge later. So make sure to carefully plan and deploy your address scheme.

*) EIGRP for IPv6 is by default shut down

*) Misconfiguration errors:

- Many IPv6 commands are the same as for IPv4, the keyword “ip” is replaced by “ipv6″. Nevertheless, what is easy to do can also be easy not to do. After a couple of hours with the contrast of the CLI, you will start glazing over J and you will notice that the device doesn’t react to your commands.

That’s a sign that something intrinsically wrong, like typing in the wrong router console, copy/past wrong fragments or typing “ip” instead of “ipv6.”

5- Conclusion

Following some techniques used to manipulate internal routing protocol paths:

1- Control what prefixes and where to redistribute.

2- Manipulate AD per-prefix (be careful with this technique!)

3- Filter prefixes from IGPs into the routing table using inbound distribute-list.

4- Summarization to shorter subnet mask on the source router.


About these ads

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

One Response to IPv6 routing protocol redistribution

  1. anil v says:

    Great post
    Illustration of what can go wrong and plenty can

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: