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

Passive-Interface Command Behavior in OSPF,EIGRP & RIP

The passive - interface command is used in all routing protocols to disable sending updates out from a specific interface. However the command behavior varies from o­ne protocol to another.

In RIP this command will disable sending multicast updates via a specific interface but will allow listening to incoming updates from other RIP speaking neighbors.

This simply means that the router will still be able to receive updates o­n that passive interface and use them in the routing table.

In EIGRP the passive-interface command stops sending outgoing hello packets, hence the router can not form any neighbor relationship via the passive interface. This behavior stops both outgoing and incoming routing updates.

In OSPF the passive-interface has a similar behavior to EIGRP. The command suppresses hello packets and hence neighbor relationships.

I have o­nly o­ne final note here regarding sending unicast updates:

If you used the neighbor command under the RIP process, the router will send unicast updates as well as multicast updates. The passive-interface command must be used disable multicast updates and allowing o­nly unicast.

In EIGRP the neighbor command disables multicast updates o­n an interface by default and allows o­nly unicast updates.

Read More

Summarization In EIGRP And RIP

Summarization in RIP and EIGRP can be configured manually using the IP summary-address command or automatically using auto-summary command. When auto summarization behaves in effect routers as shown in the steps below:

Subnets are summarized to their classful boundary before being sent to neighbors if they are not part of the major subnet of the exit interface. EIGRP automatically installs a discard route in the local routing table. RIP does not install a discard route by default.
In the following example we will explore EIGRP with automatic summarization enabled:

Router1 is connected to Router2 by a serial link and each router has loopback interfaces configured as shown in following diagram

Summarization
Router1 Configuration (same configuration applies to Router2)

R1(config)#router eigrp 10
R1(config-router)#auto-summary
R1(config-router)#network 131.108.0.0
R1(config-router)#network 137.99.0.0
Router1 routing table:

R1(config-router)#do sh ip route eigrp
137.99.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 137.99.0.0/16 is a summary, 00:04:54, Null0 <– discard route
131.108.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 131.108.3.0/24 [90/2297856] via 131.108.2.2, 00:06:00, Serial1/0 <– was not summarized
D 131.108.0.0/16 is a summary, 00:05:15, Null0 <– discard route
Router2 routing table:

R2(config-router)#do sh ip route eigrp
D 137.99.0.0/16 [90/2297856] via 131.108.2.1, 00:05:29, Serial1/0 <– Summarized subnet
131.108.0.0/24 is subnetted, 3 subnets
D 131.108.5.0 [90/2297856] via 131.108.2.1, 00:05:50, Serial1/0 <– non summarized route
Automatic summarization summarized:

R1 installs discard routes pointing to the null interface before sending summaries.
R1 sends the summarized route 137.99.0.0/16 to R2.
R1 sends 131.108.5.0/24 un-summarized because its part of the major subnet of the its exit interface.

Read More

Digging Into OSPF as a PE-CE Protocol

The default behavior of redistribution of VRF aware OSPF will lead to the MPLS VPN cloud trying to emulate OSPF. This is done using a “Super Backbone” which is hierarchically above area zero. RFC4577 explains in great detail how this should ideally work.

The whole point of this behavior is to mask the VPNv4 BGP from the customer networks. Traditionally if you redistribute any protocol into OSPF it will be created as an LSA type 5 (external). In Cisco’s implementation all LSAs of type 1-3 will be advertised out the egress PE(s) as type 3.

Given the topology below assume that the link from CE1-CE2 is not active (for the moment). All Ethernet links have been set to a network type of point-to-point for simplification.

Looking at the link state database we can see the summary prefixes (type 3) all have the router ID of the nearby PE. This means that the “Super Backbone” is working, converting area zero LSA type 1 into type 3 at the egress PE. It is important to make sure that the process IDs match between PEs. The process ID configured on the PE is attached in the form of an extended community, under the ospf process you can manually set the value to be attached to the ext-community;

OSPF DOMAIN ID:0×0005:0x0000007B0200

router ospf 123 vrf cust
domain-id type 0005 value 000000000123

OSPF DOMAIN ID:0×0005:0×000000000123

An issue which can occur when implementing OSPF as the PE-CE protocol, which I have seen first hand in a production network is that the “Super Backbone” cannot be treated as a transit network as it would in a layer two VPN. I can imagine that enterprises and even the people who design/architect for enterprises (not trying to have a dig a CCIE RS holders) do not take into consideration how OSPF MPLS VPNs actually work. You cannot just make the MPLS VPN cloud a single area, even if all the PE-CE links are in area zero all LSAs will be type three after they have crossed the cloud.

CE1#show ip ospf 123 database router adv 172.0.0.2

OSPF Router with ID (172.0.0.1) (Process ID 123)
Router Link States (Area 0)

Adv Router is not-reachable
LS age: 481
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 172.0.0.2
Advertising Router: 172.0.0.2
LS Seq Number: 80000004
Checksum: 0xD09A
Length: 60
Number of Links: 3

The LSAs (from CE2) are inside the database (on CE1) but they will not ever be able to be used for forwarding because the topology has broken the “Area 0 must be contiguous” rule. CE2 is in fact sending LSA type 1 for both Area0 and Area1 but all LSAs from Area0 are marked “Adv Router is not reachable” above.

Another thing worth noting is that in regular OSPF the “advertising router” for an LSA stays the same within an area and is changed at the border (by an ASBR/ABR). This is consistent with the “ever router must know every other router in the area” concept. This is also applied to the Superbackbone. The “advertising router” for an LSA will be changed as it is advertised out the egress PE. This combined with some of the above shows how the Superbackbone truly does act as an area hierarchically above area zero.

Read More

Configuration of Frame-Relay Interfaces

Frame relay interfaces can be configured as Physical, Multipoint and point-to-point interfaces. Frame relay routing protocols and mostly all network configurations are heavily affected by interface type selected.

In the following diagram R1 is connected to R2 using frame-relay and we are going to explore different configuration options.

Task1: Configure frame-relay PVC between R1 and R2 using Physical interfaces are considered to be multipoint interfaces by default, which means that address resolution is essential in order for both ends to communicate. Address resolution can be accomplished manually using the frame-relay map command or dynamically using inverse ARP.

Dynamic address resolution using InArp:

R1 configuration:

R1(config)#int s1/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#frame-relay inverse-arp
R1(config-if)#ip address 10.10.12.1 255.255.255.0
R1(config-if)#no shut

R2 configuration:

R2(config)#int s1/0
R2(config-if)#encapsulation frame-relay
R2(config-if)#frame-relay inverse-arp
R2(config-if)#ip address 10.10.12.2 255.255.255.0
R2(config-if)#no shut
Configuration Notes:

Configuration Notes:

DLCI is automatically received from the frame-relay switch and assigned to the physical interface by default. We don’t need to make any special configuration for DLCIs when using physical interfaces. Frame relay address resolution is accomplished dynamically using inverse ARP as shown in the following command's output.

Verification and troubleshooting:

R1#ping 10.10.12.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.12.2, timeout is 2 seconds:

!!!!!

The success rate is 100 percent (5/5), round-trip min/Avg/max = 40/112/232 ms

R1#sh frame-relay map

Serial1/0 (up): IP 10.10.12.2 dlci 102 (0×66,0×1860), dynamic, Broadcast, CISCO, status defined, active

R2#ping 10.10.12.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.12.1, timeout is 2 seconds:

!!!!!

The success rate is 100 percent (5/5), round-trip min/Avg/max = 28/114/288 ms

R2#sh frame-relay map

Serial1/0 (up): IP 10.10.12.1 dlci 201 (0xC9,0×3090), dynamic,

Broadcast,

CISCO, status defined, active

Manual address resolution:

If Inverse ARP requests are disabled, address resolution must be configured manually using the frame-relay map command.

R1(config)#int s1/0
R1(config-if)#no frame-relay inverse-arp
R1(config-if)#frame-relay map ip 10.10.12.2 102 broadcast
R2(config)#int s1/0
R2(config-if)#no frame-relay inverse-arp
R2(config-if)#frame-relay map ip 10.10.12.1 201 broadcast

The broadcast keyword is optional but recommended as it allows broadcast and multicast traffic to traverse the PVC.

Verification and troubleshooting:

R1#ping 10.10.12.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/155/376 ms

R1#sh frame-relay map
Serial1/0 (up): ip 10.10.12.2 dlci 102(0×66,0×1860), static,
broadcast,
CISCO, status defined, active

R2#ping 10.10.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/101/248 ms

R2#sh frame-relay map
Serial1/0 (up): ip 10.10.12.1 dlci 201(0xC9,0×3090), static,
broadcast,
CISCO, status defined, active

Task2: configure the frame-relay connection between R1 and R2 using multipoint sub interfaces:

Dynamic address resolution:

R1(config-subif)#int s1/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#int s1/0.21 multipoint
R1(config-subif)#ip address 10.10.12.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 102
R2(config)#int s1/0
R2(config-if)#encapsulation frame-relay
R2(config-if)#int s1/0.21 multipoint
R2(config-subif)#ip address 10.10.12.2 255.255.255.0
R2(config-subif)#frame-relay interface-dlci 201

Verification and Troubleshooting:

R1#sh frame-relay map
Serial1/0.21 (up): ip 10.10.12.2 dlci 102(0×66,0×1860), dynamic,
broadcast,, status defined, active
R2#sh frame-relay map
Serial1/0.21 (up): ip 10.10.12.1 dlci 201(0xC9,0×3090), dynamic,
broadcast,, status defined, active

Manual address resolution:

R1(config-subif)#int s1/0.21
R1(config-subif)#frame-relay map ip 10.10.12.2 102 broadcast
R2(config-subif)#int s1/0.21
R2(config-subif)#frame-relay map ip 10.10.12.1 201 broadcast

R1#show frame-relay map
Serial1/0.21 (up): ip 10.10.12.2 dlci 102(0×66,0×1860), static,
broadcast,
CISCO, status defined, active

R2#sh frame-relay map
Serial1/0.21 (up): ip 10.10.12.1 dlci 201(0xC9,0×3090), static,
broadcast,
CISCO, status defined, active

Task3: Configure frame-relay connection between R1 & R2 using point-to-point Subinterfaces.

Point-to-Point interfaces do not need any kind of address resolution, only the DLCI must be assigned to the subinterface using the frame-relay interface-dlci command.

R1(config)#int s1/0
R1(config-if)#encapsulation frame-relay
R1(config-if)#int s1/0.12 point-to-point
R1(config-subif)#ip address 10.10.12.1 255.255.255.0
R1(config-subif)#frame-relay interface-dlci 102
R2(config)#int s1/0
R2(config-if)#encapsulation frame-relay
R2(config-if)#int s1/0.12 point-to-point
R2(config-subif)#ip address 10.10.12.2
R2(config-subif)#frame-relay interface-dlci 201

Verification and Troubleshooting:

R1#sh frame-relay map
Serial1/0.12 (up): point-to-point dlci, dlci 102(0×66,0×1860), broadcast
Status defined, active
R2#sh frame-relay map
Serial1/0.12 (up): point-to-point dlci, dlci 201(0xC9,0×3090), broadcast
Status defined, active

Read More