Daily Archives: April 12, 2013

4.1.a Implement and troubleshoot MPLS operations

from: http://www.cisco.com/en/US/tech/tk436/tk428/technologies_q_and_a_item09186a00800949e5.shtml#qa4

Upstream and downstream are relative terms in the MPLS world. They always refer to a prefix (more appropriately, an FEC). These examples further explain this.

/image/gif/paws/4649/mpls-downstrmA.jpg

For FEC 10.1.1.0/24, R1 is the “Downstream” LSR to R2.

For FEC 10.1.1.0/24, R2 is the “Upstream” LSR to R1.

/image/gif/paws/4649/mpls-downstrmB.jpg

For FEC 10.1.1.0/24, R1 is the “Downstream” LSR to R2. And, R2 is the “Downstream” LSR to R3.

/image/gif/paws/4649/mpls-downstrmC.jpg

For FEC 10.1.1.0/24, R1 is the “Downstream” LSR to R2. For FEC 10.2.2.0/24, R2 is the “Downstream” LSR to R1.

Data flows from upstream to downstream to reach that network (prefix).

/image/gif/paws/4649/mpls-downstrmD.jpg

The R4 routing table has R1 and R2 as the “next-hops” to reach 10.1.1.0/24.

4.1.a Implement and troubleshoot MPLS operations

first, it’s not a competition…

i’ve read through wendell’s ccie r&s mpls section a couple of times and it wasn’t enough… the subject is obviously a lot bigger than 70 pages… i’ve been sitting on the fence for a while knowing that i would supplement that somehow, but how… mpls vpn architectures 1 and 2 are the defacto standard for the subject, however, they were written in 2000… i’ve also read that they can be heavy on atm and tag, THAT AREN’T USED ANYMORE… and books are expensive even if they are pdf’s…

deghein’s book was written in 2005, a little better… there has been a passing reference to tag, so far, and that’s ok… there’s gonna be some atm because it was written in 2005, get over it…

but the real reason… and it’s a personal one because i know me…  it says fundamentals in the title, which i translate to nuts and bolts… i need nuts and bolts, the brass tacks; i want to be hand carried because i assume nothing… i approach a book as if i know nothing… if a book goes from 0 to 60 in 2.3 seconds i am done…

fundamentals… reinforcement… this stuff is too big without constant reference points…

4.1.a Implement and troubleshoot MPLS operations

or the mpls ldp ID…

roger perkin has  a nice article on this here…http://www.rogerperkin.co.uk/ccie/index.php/mpls/mpls-ldp-router-id-loopback0-force/ 

it is also discussed in DeGhein’s MPLS Fundamentals in chapter 4

the router id preference for ldp works like it does for ospf and bgp… the theory behind the value of using the loopback in all cases is well documented…

pe1(config)#do sh mpls ldp discovery
Local LDP Identifier:
192.168.14.1:0
Discovery Sources:
Interfaces:
FastEthernet1/0 (ldp): xmit/recv
LDP Id: 192.168.24.2:0
FastEthernet1/1 (ldp): xmit/recv
LDP Id: 192.168.34.4:0

note this is the highest active interface ip address…

pe1(config)#do sh ip int brie
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        192.168.15.1    YES manual up                    up
FastEthernet0/1        192.168.16.1    YES manual up                    up
FastEthernet1/0        192.168.12.1    YES NVRAM  up                    up
FastEthernet1/1        192.168.14.1    YES NVRAM  up                    up
FastEthernet2/0        unassigned      YES NVRAM  administratively down down
FastEthernet2/1        unassigned      YES NVRAM  administratively down down
Loopback0              1.1.1.1         YES manual up                    up

also note that there is an active loopback so what gives?

i added the loopback after the LID had already been determined… you can force it to change…

pe1(config)#mpls ldp router-id lo0 force
pe1(config)#
*Apr 12 11:39:57.776: %LDP-5-INFO: default: LDP ID removed
*Apr 12 11:39:57.792: %LDP-5-NBRCHG: LDP Neighbor 192.168.34.4:0 (1) is DOWN (LDP Router ID changed)
*Apr 12 11:39:57.792: %LDP-5-NBRCHG: LDP Neighbor 192.168.24.2:0 (2) is DOWN (LDP Router ID changed)

pe1(config)#do sh mpls ldp disco
Local LDP Identifier:
1.1.1.1:0
Discovery Sources:
Interfaces:
FastEthernet1/0 (ldp): xmit/recv
LDP Id: 192.168.24.2:0
FastEthernet1/1 (ldp): xmit/recv
LDP Id: 192.168.34.4:0

sh mpls ldp disco detail will give you hello and holdtime’s…

pe1(config)#do sh mpls ldp disco detail
Local LDP Identifier:
1.1.1.1:0
Discovery Sources:
Interfaces:
FastEthernet1/0 (ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms; Transport IP addr: 1.1.1.1
LDP Id: 192.168.24.2:0
Src IP addr: 192.168.12.2; Transport IP addr: 192.168.24.2
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 192.168.24.0/24
Password: not required, none, in use
Clients: IPv4, mLDP
FastEthernet1/1 (ldp): xmit/recv
Enabled: Interface config
Hello interval: 5000 ms; Transport IP addr: 1.1.1.1
LDP Id: 192.168.34.4:0
Src IP addr: 192.168.14.4; Transport IP addr: 192.168.34.4
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Reachable via 192.168.34.0/24
Password: not required, none, in use
Clients: IPv4, mLDP

sh tcp brief is also your buddy here:

pe2#sh tcp brie
TCB       Local Address               Foreign Address             (state)
68883684  3.3.3.3.35933               1.1.1.1.179                  ESTAB
688822F4  3.3.3.3.48108               2.2.2.2.646                  ESTAB
69507584  3.3.3.3.646                 4.4.4.4.40376                ESTAB

4.1.a Implement and troubleshoot MPLS operations

why sp’s don’t need bgp in their core, and why it is needed on the edge…

from luc de Ghein:

When the IP network of a service provider must forward traffic, each router must look up the
destination IP address of the packet. If the packets are sent to destinations that are external to the
service provider network, those external IP prefixes must be present in the routing table of each
router. BGP carries external prefixes, such as the customer prefixes or the Internet prefixes. This
means that all routers in the service provider network must run BGP.

MPLS, however, enables the forwarding of packets based on a label lookup rather than a lookup
of the IP addresses. MPLS enables a label to be associated with an egress router rather than with
the destination IP address of the packet. The label is the information attached to the packet that
tells every intermediate router to which egress edge router it must be forwarded. The core routers
no longer need to have the information to forward the packets based on the destination IP address.
Thus, the core routers in the service provider network no longer need to run BGP.
The router at the edge of the MPLS network still needs to look at the destination IP address of the
packet and hence still needs to run BGP. Each BGP prefix on the ingress MPLS routers has a BGP
next-hop IP address associated with it. This BGP next-hop IP address is an IP address of an egress MPLS router. The label that is associated with an IP packet is the label that is associated with this BGP next-hop IP address. Because every core router forwards a packet based on the attached MPLS label that is associated with the BGP next-hop IP address, each BGP next-hop IP address of an egress MPLS router must be known to all core routers. Any interior gateway routing
protocol, such as OSPF or ISIS, can accomplish this task.

quote of the day, fec…

forwarding equivalence class can mean a few things, similarly… it mostly means prefix, and by extension, prefix fondling…

have at it wendell:

Generally speaking, an FEC is a set of packets that receives the same forwarding treatment by
a single LSR. For simple MPLS unicast IP forwarding, each IPv4 prefix is an FEC. For MPLS
VPNs, each prefix in each VRF is an FEC—making the prefix 10.3.3.0/24 in VRF-A a different
FEC from the 10.3.3.0/24 prefix in VRF-B. Alternately, with QoS implemented, one FEC might
be the set of packets in VRF-A, destined to 10.3.3.0/24, with DSCP EF in the packet, and
another FEC might be packets in the same VPN, to the same subnet, but with a different
DSCP value.