According to most in the “know” regarding IPv6, IPv4 is NOT going away in our lifetime. Pockets of the current protocol for networking will continue to exist for the foreseeable future; they might just get smaller and smaller, and more dispersed. Why is this? It is because of the rich transition mechanisms that exist to allow IPv4 and IPv6 to co-exist.

In this post, we are going to cover one of the IPv4 to IPv6 transition mechanisms that we ran out of time for when we conducted an evening session of our CCIE R&S Lab Fundamentals Bootcamp course here at IPexpert. This feature is termed a Manual Configured Tunnels (MCT). It is a statically defined, point-to-point type of method for connected two network areas of IPv6 that might be separated by IPv4-only network devices.

One of the beauties of this Manually Configured Tunnel (MCT) is that they are supported by most of the stacks and routers that you might run into within production networks today. This transition mechanism is specified in RFC 4213. This RFC specifies the methodology for manually configured IPv6-over-IPv4 tunnels for transporting IPv6 packets over an existing IPv4 network.

If you are a fan of history, this simple and direct approach is one of the first transition mechanisms developed with the intent of ensuring that IPv6 packets can be successfully transported through IPv4 only network devices. Manually Configured Tunnels use protocol 41(IPv6) to encapsulate the traffic, and the tunnel encapsulation is determined from the static configuration information present on the tunneling node. The tunneling node can actually be a dual-stack router or host. For MCTs, additional information such as the packets of interests are found out based on the configuration/routing table in the node.

In the Cisco world, you might consider MCTs for stable connections that might require regular communication between two edge routers. In order to create the tunnel, you assign an IPv6 address to the tunnel, and you use the existing IPv4 addresses on your edge dual-stack devices for tunnel source and destination.

Here is an example configuration on two dual-stack Cisco routers. Notice the use of RIPng to enable dynamic routing information to pass through the “sea” of IPv4-only devices:

ROUTERA

ROUTERA(config)# ipv6 unicast-routing

ROUTERA(config)# interface loopback 0

ROUTERA(config-if)# ipv6 rip ROUTERARIPNG enable

ROUTERA(config-if)# exit

ROUTERA(config)# interface tunnel 0

ROUTERA(config-if)# ipv6 address 2001:13::1/64

ROUTERA(config-if)# tunnel source fastethernet0/0

ROUTERA(config-if)# tunnel destination 10.20.20.3

ROUTERA(config-if)# tunnel mode ipv6ip

ROUTERA(config-if)# ipv6 rip ROUTERARIPNG enable

ROUTERA(config-if)# end

 

ROUTERB

ROUTERB(config)# ipv6 unicast-routing

ROUTERB(config)# interface loopback 0

ROUTERB(config-if)# ipv6 rip ROUTERBRIPNG enable

ROUTERB(config-if)# exit

ROUTERB(config)# interface tunnel 0

ROUTERB(config-if)# ipv6 address 2001:13::3/64

ROUTERB(config-if)# tunnel source fastethernet0/0

ROUTERB(config-if)# tunnel destination 10.10.10.1

ROUTERB(config-if)# tunnel mode ipv6ip

ROUTERB(config-if)# ipv6 rip ROUTERBRIPNG enable

ROUTERB(config-if)# end

Notice how straightforward this configuration is, and also notice the critical importance of the tunnel mode command in order to ensure the use of the Manually Configured Tunnel.

In future blog posts, we will examine other important options for the smooth transition between IPv4 and IPv6.

Anthony Sequeira CCIE, CCSI

Twitter: @compsolv

Facebook: http://www.facebook.com/compsolv

 

In this post, we are going to cover a feature that we ran out of time for when we conducted an evening session of our CCIE R&S Lab Fundamentals Bootcamp course here at IPexpert. This feature was the 802.1q tunneling feature. You will often hear it referred to as simply Q-in-Q tunneling.

In production network environments, Q-in-Q tunneling often shows up in Metro Ethernet environments. In these networks, service providers are interested in providing transparent Layer 2 services to clients. This option is appealing since the customer devices do not need special, high-end equipment to run things like MPLS, and the customer equipment can be freed from running a routing protocol, as would be found in a Layer 3 MPLS VPN environment.

In Q-in-Q tunneling, the service provider takes the traffic received from a customer and “tunnels” this traffic by appending a new Ethernet header with a new 802.1Q tag. This outer tag that service provider adds is often referred to as the “Metro Tag” for the most obvious application in Metro Ethernet environments as we have described. Adding this special new tag allows the service provider to identify traffic as belonging to a certain customer, and allows the provider to transport the traffic through their cloud without worrying about overlapping customer VLAN IDs.

Q-in-Q tunneling can be combined with Layer 2 Protocol tunneling to allow customers to send Layer 2 protocols through the service provider cloud as well. Examples of such protocols would be CDP, STP, and VTP traffic.

When you engage in Q-in-Q tunneling, Cisco recommends that you increase the system MTU since the frame size is now larger. System MTU should be increased to 1504 bytes per Cisco’s documentation.

Here is a sample configuration of this Q-in-Q and Layer 2 Protocol tunneling configuration:

system mtu 1504
!
interface fa0/1
switchport access vlan 10
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
no cdp enable

While this information here has you ready for the Written Exam, if you are interested in studying this feature in greater depth for the Lab Exam, use the link below:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750e_3560e/software/release/12.2_37_se/configuration/guide/swtunnel.html

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv

 

In this post, we are going to cover a feature that we ran out of time for when we conducted an evening session of our CCIE R&S Lab Fundamentals Bootcamp course here at IPexpert. This feature was the “Router on a Stick” configuration. This is of course when we perform inter-VLAN routing using an external router. The router has an interface that we use to form a trunk link with a port on the switch. In order to enable this configuration, you use subinterfaces on the router port. These logical subinterfaces allow you to associate VLAN IDs with particular subinterfaces that will possess an appropriate IP address for that subnet. This IP address can be used as the default gateway for devices that are connected to that particular VLAN via the switch.

So what is the official process for this router on a stick configuration? Well, here is how it works:

Step 1 – traffic from a PC in VLAN 10 enters the switch. The switch access port configuration is simple and straightforward. For example, switchport mode access; switchport access vlan 10.

Step 2 – the traffic exits the trunk link to the router and arrives on the subinterface that is bound to VLAN 10.

Step 3 – the router examines the destination IP address and realizes that the packet must be routed out of another subinterface on the router. It sends the packet out of the other subinterface and that directs the packet over the trunk back to the switch.

Step 4 – the frame arrives at the Layer 2 switch and is sent to the destination VLAN port.

For both the written and the lab exam, you might be required to interpret, or perform this configuration. Here is a sample configuration on the switch. Notice how amazingly straightforward this configuration is:

SWITCH1

vlan 10,20
interface fa0/1
switchport mode trunk
switchport trunk native vlan 99
switchport trunk allowed vlan 10,20

Now here is the  configuration of the router. This is the rather unique part. Notice the assignment of the VLAN ID to the subinterfaces. This must be accomplished before a subinterface and be provided an IP address in this case:

ROUTER 1

interface fa0/0.10
encapsulation dot1q 10
ip address 10.10.10.1 255.255.255.0
interface fa0/0.20
encapsulation dot1q 20
ip address 10.20.20.1 255.255.255.0

Please not that your subinterface ID does not need to match the VLAN ID, but I certainly like to do it that way as it aids me in maintaining and troubleshooting the network.

For the written exam, we want to be sure that we are aware of the Advantages and Disadvantages of such a configuration. Here  are the advantages:

• Layer 3 services are not required on the switch
• It is a simple and easy to understand implementation
• The router enables inter-VLAN communication

The disadvantages of such a configuration are as follows:

• The router is a single point of failure
• The single traffic path of the single trunk is also a single point of failure
• The single trunk link might experience congestion
• There is increased latency in this design

So there you have readers! Everything you might need to know about the basics of this configuration for the written and lab exam!

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv
Facebook: http://www.facebook.com/compsolv