– The following is an excerpt from the upcoming edition of the:

IPexpert MPLS Operation and Troubleshooting book.

Introduction to Label Distribution

Thus far in this book we have discussed the values and characteristics of labels, we have dealt with their meaning and how they affect the creation of both the control and forwarding planes used in MPLS. Throughout this entire process we have only loosely referred to the exchange of labels between label switching devices. Now it is time to discuss the process and mechanism behind this exchange or advertising process.

There are two methods at our disposal to exchange labels and their associated bindings between devices that are peered. The key word here is “peered”. Whether we are using the Cisco proprietary Tag Switching or the industry standard Label Distribution Protocol (LDP) as the mechanism of choice to communicate label information, it all still boils down simply to peering relationships and the rules governing those peers. For the purpose of our discussion we will deal specifically with LDP from this point forward.

When MPLS is enabled on an integrated services router (ISR) LDP is the default label distribution protocol. It is this protocol that dynamically creates and governs the label switched path in our network. So it must be noted that everything we have discussed up to this point regarding label generation, assignment, and exchange is maintained by this single protocol. Additionally LDP is also responsible for the formation of the peering relationships we mentioned earlier. It is these relationships that facilitate the exchange of our local label bindings between peers.

At this time we should define and innumerate the major operational roles this protocol will be responsible for in terms our discussions in this chapter. Primarily we can outline three such functions:

• Dynamic discovery of adjacent LDP Peers
• Peering and session establishment
• Regulation of peer-to-peer communication and label exchange

We will now initiate an introduction to the concepts associated with these major operational functions in their own individual sections.

Read Full Entry »

INTRODUCTION

This mini-configuration lab, dealing with SNMP, will be conducted using three routers connected via FastEthernet. We will run OSPF area 0 on all devices and advertise all configured interfaces into OSPF process 1. This network is simple enough to be emulated on dynamips/dynagen, GNS3 or through the use of live equipment. In my case I will be using Proctorlabs gear connected according to the following topology:

Read Full Entry »

Introduction

As networks began to expand and take on more responsibilities the need for some type of tool that would allow efficient and scaled management and monitoring of servers, workstations, routers and switches became immediately apparent and Simple Network Management Protocol (SNMP) was developed to meet this specific need. Now through the use of this protocol administrators can manage network performance, isolate and resolve technical problems, and develop data driven models for future network growth. SNMP operates by sending information to Network Management Servers (NMS). The NMS learns about problems in the network by receiving traps or inform messages generated by the individual device running SNMP or what is more commonly called the managed device.

In the previous description we mentioned one of the three critical components that are a part of an SNMP controlled network. If the first component is the managed device itself, which for the purposes of this discussion would be a router or a switch, then the two remaining elements would be the agent and the NMS. Keep in mind that the component we call the agent is actually a process that resides on an actual node or device. So the agent could also be considered a logical construct or a software module rather than a physical device, but as such it must reside on a managed device be it a router, switch, server or workstation. That leaves the NMS whose role is to gather and preserve the management information from all of the running agents in the network. The NMS maintains information for all devices in the managed network, where the actual agents themselves maintain all local management information. Additionally, an NMS is responsible for controlling managed devices as well as simply monitoring them. This control comes in the form of applications that the NMS can execute on a periodic or as needed basis to meet certain goals.

Read Full Entry »

IPexpert’s CCIE R&S Written and Lab Bundle -  Buy a Bundle, Save a Bundle

Buy a Bundle, Save a Bundle! This week IPexpert has an incredible deal for CCIE R&S Candidates! We have bundled some of our most requested materials together and are offering them at a significantly reduced price. This one of a kind bundle offers CCIE R&S aspirants the opportunity to build strong foundational knowledge of all the technologies encountered on the CCIE R&S Lab Exam. Become an an EXPERT in R&S Today!

 

What’s Included in IPexpert’s CCIE R&S Written & Lab Bundle?

• CCIE R&S Online Written and Lab Fundamentals Bootcamp Course with Special Guest CCIE Instructors
• CCIE R&S Blended Learning Solution (Streaming/Electronic)
• IPexpert’s New IPv4/6 Multicast Operation and Troubleshooting Guide

Retail Price $3097
Promotional Price $1449

Note:

• Offer ends Friday, February 17th, 2012 at 5:00 PM EST
• Valid for all new orders only, and orders must be placed through website (not called in or ordered via telephone).
• Cannot be combined with any other promotion or discount.

 

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