IPV6: Transitioning From IPV4 To IPV6

The theory is that when you begin to migrate your IPv4 network towards IPv6, you start at the edge of the network and work your way towards the core. This requires thought on how we will have IPv4 and IPv6 working with each other side by side.

To achieve this, we have 2 approaches with 3 overall methods.

1. Translating
2. Encapsulating

• Dual Stack
• 6-to-4 Tunnel
• NAT-PT

Dual Stack

A host runs dual stack when it runs both IPv4 and IPv6. Dual stack helps meet the migration challenge we face when end users want to keep using their favorite IPv4-based apps while the network moves forward to IPv6-based apps.

6-to-4 Tunnel

Cisco documentation states that setting up a 6-to-4 tunnel is very simple on the host ends of the tunnel. A 6-to-4 tunnel is also automatic, is torn down when the session ends and is a scalable solution.

6-to-4 tunnelling is accomplished by taking an IPv6 packet and encapsulating it into an IPv4 packet (protocol type 41) for transport across the IPv4 section of the network, then de-encapsulating it when the remote edge router is ready to route it across the IPv6 network. The IPv6 networks shown in this method are sometimes referred to as IPv6 islands.

6-to-4 tunnels also have a reserved IPv6 address prefix for edge routers. These prefixes begin with 2002 and are followed by the router’s IPv4 address expressed in hex. These prefixes carry a /48 prefix, such as 2002:1234:83cd::/48.

Hex Example of IPv4 to Hex Conversion

The IPv4 address of the interface involved in the tunneling is vital in determining the correct IPv6 address for the tunnel. Let’s say the IPv4 address of one of the routers is220.200.18.42. We know the address for the corresponding tunnel interface begins with 2002, to complete the rest we break down each octet into hex:

• 220 = 13 units of 16, 12 units of 1 = hex value is DC
• 200 = 12 units of 16, 8 units of 1 = hex value is C8
• 18 = 1 unit of 16, 2 units of 1 = hex value is 12
• 42 = 2 units of 16, 10 units of 1 = hex value is 2A

The IPv6 address for the tunnel interface is 2002:DCC8:122A::/48.

NAT-PT

NAT-Protocol Translation works much the same as normal NAT.  If you have IPv6 hosts that need to intercommunicate with IPv4 hosts on another segment, NAT-PT may be the perfect solution.

NAT routers translate private IPv4 addresses to public IPv4 addresses, and back again; NAT-PT routers translate IPv6 addresses to IPv4 addresses, and back again.

Read More

Route Distribution of OSPF Protocol

Redistributing into OSPF

Example syntax:

R1(config)#router ospf 1 R1(config-router)#redistribute connected % Only classful networks will be redistributed R1(config-router)#redistribute connected subnets

Notice there is no seed metric required for redistribution into OSPF. OSPF has a default seed metric of 20, so none has to be specified with the redistribute command.

What OSPF does require is the subnets option to be enabled — if you want subnets to be redistributed into OSPF.

OSPF Defaults with Route Redistribution

• The route has a metric of 20, OSPF’s default seed metric
• The route is marked as “E2″, short for External-Type 2. This is the default routing code for a route redistributed into OSPF. An E2 metric reflects only the cost from the ASBR to the external destination. It does not reflect the cost from the local router to the ASBR itself. This would be covered by an E1 metric which is not the default for route redistribution with OSPF.

Default Seed Metrics

RIP and EIGRP have a seed metric of “infinity”, and you know no routes with a metric of “infinity” are ever going to be placed into a routing table. Both RIP and EIGRP require a default seed metric to be defined during the redistribution process.

OSPF has a default seed metric of 20, as well as defaulting to a route type of E2. There’s always an exception, and the exception here is that BGP routes are given a metric of 1 by OSPF. Be really careful when redistributing BGP into OSPF.

Another link-state protocol, ISIS has a default seed metric of zero, and it does allow routes to be redistributed without a specified seed metric.

OSPF’s default seed metric can be changed in the redistribute command itself.

Example:R2(config)#router ospf 1 R2(config-router)#redistribute eigrp 100 ? metric Metric for redistributed routes metric-type OSPF/IS-IS exterior metric type for redistributed routes route-map Route map reference subnets Consider subnets for redistribution into OSPF tag Set tag for routes redistributed into OSPF <cr> R2(config-router)#redistribute eigrp 100 metric ? <0-16777214> OSPF default metric R2(config-router)#redistribute eigrp 100 metric 30 % Only classful networks will be redistributed R2(config-router)#redistribute eigrp 100 metric 30 subnets

*Remember to add the word subnets to the end to ensure classless networks can be advertised and not the default of classful.

Read More

Route Distribution of RIP

Redistribution with RIP

R1(config)#router rip R1(config-router)#redistribute static ? metric Metric for redistributed routes route-map Route map reference <cr>

The <cr> is a little misleading here. While the command redistribute static is a complete command, it’s not enough to do the job when redistributing routes into RIP – we need to plant a seed metric. RIP will not understand the metric applied to an OSPF route for example, by planting this seed we are in fact manually setting the metric in a format that RIP understands.

Example:

We know that RIP uses hop count as it’s metric. If we redistribute an OSPF route into RIP that has a cost of 74 – a common OSPF metric – RIP doesn’t want anything to do with that route, since RIP considers a metric of 16 to be ”unreachable”. Therefore we must manually specify the seed metric value.

A good seed metric value for RIP is 2, as the route travels through the RIP domain it will of course increment as per any other route with a dynamic routing protocol.

In a hub and spoke topology, the router connected to both the spoke routers is known as the Border Router. This is the router where will be performing route redistribution.

Example RIP config to enable the redistribution of routes from OSPF into the RIP domain:

R1(config)#router rip R1(config-router)#redistribute ospf 1 metric 2 R1(config-router)#redistribute connected metric 2

More to follow on Route Redistribution from the OSPF spoke router…

Read More

Policy Based Routing

Policy-based routing, generally referred to as “policy routing”, is the use of route maps to determine the path a packet will take to get to its final destination.

* I remember the PBR lab in the CCNP Route exam. The requirement was to redirect a users machine via a slow WAN link. This involving setting their next hop IP to that of the 56k WAN link, as apposed to the 2Mbps Serial WAN link. Nice!

* For QoS purposes, traffic can be “marked” by policy routing in order to give different levels of service to various classes of traffic.

PBR Rules

• Policy routing doesn’t affect the destination of the packet, but does affect the path that is taken to get there.
• Policy routing can forward traffic based on the source IP address or the destination IP address (with the use of an extended ACL).
• Policy routing can be configured globally or on a per-interface level.
• If a packet doesn’t match any of the specific criteria in a route map, or does match a line that has an explicit deny statement, the data is sent to the routing process and will be processed normally.

Applying policy routing on an interface affects only packets arriving on that interface – in this case, Serial0.

R2(config)#int s0 R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Applying the policy globally applies the route map to packets generated on the router, not on all packets received on all interfaces.

R2(config)#ip local policy route-map CHANGE_NEXT_HOP

Verify either or both with show ip policy.

Chris Bryant Tip: If you don’t want to route packets that don’t match a route-map clause, the set command must be used to send those packets to the null0 interface. Naturally, this set command should be the final set command in the route map.

Route Map Configuration

1. Create an ACL to identify the traffic. (Standard or Extended where relevant)

R2(config)#access-list 32 permit host 20.4.4.4

2. Create Route Map with intuitive name.

R2(config)#route-map EXAMPLE permit 10 R2(config-route-map)#match ip address 29 R2(config-route-map)#set ip next-hop 40.1.1.1 R2(config-route-map)#route-map EXAMPLE deny 20 R2(config-route-map)#match ip address 30

3. Apply route map under interface or globally (Where applicable!)

R2(config)#int s0 R2(config-if)#ip policy route-map CHANGE_NEXT_HOP

Read More

Metric Manipulation Of EIGRP Protocol

EIGRP is the most complex metric between all routing protocols metrics, in this post we are trying to clear the calculation of this metric as much as possible.

Let's begin..

EGIRP metric is a composite metric made up of 5 parameters listed as follows:

• Bandwidth.
• Delay.
• Load.
• Reliability.
• MTU.

All these parameters are used to find the metric of the path by substitution in the following formula:

metric = [K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]

Where K1 through K5 are constants that can be changed with the metric weights command,The default behavior in EIGRP is to use Bandwidth and Delay only by setting K1and K3 values to 1 and all other K values to zero.

Applying the default constants the formula is reduced to:

metric= [(10,000,000/minBandwidth) + Sum of delays/10] x 256.

Let's clarify with an example:

R2#sh IP eigrp topology 1.1.1.1 /32
IP-EIGRP (AS 10): Topology entry for 1.1.1.1 /32
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
Routing Descriptor Blocks:
172.16.123.1 (Serial1/0), from 172.16.123.1, Send flag is 0x0
The composite metric is (2297856/128256), Route is Internal
Vector metric:
Minimum bandwidth is 1544 Kbit
Total delay is 25000 microseconds
Reliability is 255/255
The load is 1/255
Minimum MTU is 1500
The hop count is 1

Using the above information we can calculate the metric as follows:

metric = [10,000,000/1544 + 25000/10] x 256 = (6476 + 2500) x 256 = 2297856 ; The final result matches the EIGRP calculation as shown in the above output.

Whenever you try to change the metric of a specific path the best practice is to change the delay along the path, rather than the bandwidth of the interfaces. The main reason is that the bandwidth value may affect many other configured features like QOS or OSPF calculations.

Read More

Different EIGRP Timers (hello, hold-down and active)

Today at work I have run into troubleshooting an EIGRP problem with one of our customers; while troubleshooting this problem I started making every optimization I know about EIGRP. In this post I am sharing with you EIGRP timers I adjusted in order to clear up the problem.

Hello interval timer:

Hello interval is the rate at which EIGRP sends hello packets. The command ip hello-interval eigrp can be used to set the hello interval time manually.

Hello interval defaults to 60 seconds for low-speed, NBMA networks and 5 seconds for other types of networks.

Hold-down timer:

This is the amount of time that a router will consider a neighbor alive without receiving  hello packets. The hold time is typically three times the hello interval. You can adjust the hold time with the ip hold-time eigrp command.

Unlike OSPF changing the hello timer does not automatically adjust the hold down timer.

Sometimes hello packets are lost in congested networks and neighbor relationships start to flap; in such cases you may want to increase the hold-down time.

Increasing the hold-down timer delays convergence, this is  an undesirable effect. If the default hello/hold time value is not suitable for your network try to find the value that best suits your network.

Active timer:

This timer controls the time the router waits after sending a query before declaring the route stuck in active (SIA) and resetting the neighbor relationship. To avoid this neighbor resetting you can temporary increase the active timer until you solve the problem by eliminating the cause.

The timers active-time command can be used to adjust the active timer.

Read More