From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Mon Aug 21 2006 - 13:49:58 ART
Tim,
Let's take a look at your example on the command line and it
will become a little clearer:
SW1--150.1.1.0/24--R1--150.1.12.0/24--R2--150.1.23.0/24--R3--150.1.3.0/2
4--SW2
SW1 and SW2 are IP only hosts defaulting to R1 and R3 respectively. R1,
R2, and R3 have OSPF enabled on all interfaces and have MPLS enabled on
networks 150.1.12.0/24 and 150.1.23.0/24. R2 is LDP adjacent with R1
and R3. The following occurs when the link between R1 and R2 is
activated on R1:
R1#debug mpls ldp advertisements
LDP label and address advertisements debugging is on
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#int s0/0.1
R1(config-subif)#no shut
R1(config-subif)#end
R1#
%SYS-5-CONFIG_I: Configured from console by console
R1#
%OSPF-5-ADJCHG: Process 1, Nbr 150.1.23.2 on Serial0/0.1 from LOADING to
FULL, Loading Done
tagcon: Assign peer id; 150.1.12.2:0: id 0
%LDP-5-NBRCHG: LDP Neighbor 150.1.12.2:0 is UP
tagcon: peer 150.1.12.2:0 (pp 0x82B99038): advertise 150.1.1.1
tagcon: peer 150.1.12.2:0 (pp 0x82B99038): advertise 150.1.12.1
tagcon: peer 150.1.12.2:0 (pp 0x82B99038): advertise 150.1.23.0/24,
label 16 (#6)
tagcon: peer 150.1.12.2:0 (pp 0x82B99038): advertise 150.1.3.0/24, label
17 (#8)
tagcon: peer 150.1.12.2:0 (pp 0x82B99038): advertise 150.1.1.0/24, label
3 (imp-null) (#14)
tagcon: peer 150.1.12.2:0 (pp 0x82B99038): advertise 150.1.12.0/24,
label 3 (imp-null) (#20)
R1 is directly connected to 150.1.1.0/24 and 150.1.12.0/24. These
prefixes are advertised with an implicit null (imp-null) label to R2.
This means that when R2 sends traffic to either of these destinations
towards R1 it should first pop (remove) it's label. This process on R2
is called a penultimate hop pop, or PHP, since it is the next
(penultimate) hop away from the destination. Now move up to R2 and
check it's label mappings:
R2#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 150.1.1.0/24 0 Se0/0.1 point2point
17 Pop tag 150.1.3.0/24 520 Se0/1 point2point
For prefix 150.1.1.0/24 R2 has assigned an incoming label of 16
and an outgoing label of "Pop tag". This means that when R3 sends a
packet to R2 destined for 150.1.1.0/24 it will have a label of 16. R2
will then remove label 16 and send the IP packet unlabeled to R1 (per
the PHP process). Based on this output we can assume that if label
distribution was successful R3 should be using label 16 for outgoing
traffic to 150.1.1.0/24:
R3#show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 16 150.1.1.0/24 0 Se1/3 point2point
17 Pop tag 150.1.12.0/24 0 Se1/3 point2point
Per this output we can see that when R3 sends traffic to
150.1.1.0/24 out Se1/3 (towards R2) the outgoing label will be 16. Now
let's look at the actual traffic flow:
R2#debug mpls packets
MPLS packet debugging is on
SW2#ping 150.1.1.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
R2#
MPLS: Se0/1: recvd: CoS=0, TTL=254, Label(s)=16
MPLS: Se0/0.1: xmit: (no label)
MPLS: Se0/0.1: recvd: CoS=0, TTL=254, Label(s)=17
MPLS: Se0/1: xmit: (no label)
R2 receives a labeled packet in Se0/1 (the connection to R3)
with a label of 16. The label is popped (removed) and sent out Se0/0.1
(to R1) as a native IP packet per the PHP process. R1 receives a normal
IP packet and performs normal forwarding of the ICMP echo. R2 then
receives a labeled packet in Se0/0.1 (from R1) with a label of 17 (the
ICMP echo-reply from SW1). Per the forwarding table R2 knows to pop
this label and transmit the packet to R3, as R2 is the penultimate hop
for this destination.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Tim
> Sent: Monday, August 21, 2006 9:30 AM
> To: 'Chris Broadway'; ccielab@groupstudy.com
> Subject: RE: MPLS newbie w/ a couple basic Q's
>
> Hey Chris,
>
>
>
> Thanks for bearing with me as I try to absorb what's going on here.
>
>
>
> I need to think about the first part of what you wrote some more but
let
> me
> confirm I understand the 2nd part regarding the 3 labels for net-D on
rtr-
> 2.
>
>
>
> To stay in sync, I'll repeat the network diagram here:
>
>
>
> net-A rtr-1 net-B rtr-2 net-C rtr-3 net-D
>
>
>
>
>
> rtr-1 generates a label, let's say its = 10, for net-D and advertises
it
> to
> rtr-2.
>
>
>
> rtr-2 generates a label, = 20, for net-D and advertises it to rtr-1
and
> rtr-3.
>
>
>
> rtr-3 generates a label, = 30, for net-D and advertises it to rtr-2.
>
>
>
> So, now rtr-2 knows of 3 labels for net-D.
>
>
>
> When a packet for net-D arrives on rtr-1, rtr-1 will use the label 20
it
> learned from rtr-2 to send the packet to rtr-2, correct?
>
>
>
> And, once the labeled packet gets to rtr-2, rtr-2 will then use the
label
> it
> learned from rtr-3 (30) to send the labeled packet to rtr-3, correct?
>
>
>
> So, in this example, label 10 will never be used, right?
>
>
>
> However, if rtr-2 for some reason ever did need to send traffic for
net-D
> to
> rtr-1 ( assuming a different topology), it would then use label=10 to
send
> traffic to rtr-1.
>
>
>
> Am I close to being accurate in this description?
>
>
>
> Thanks again, Tim
>
>
>
>
>
> _____
>
> From: Chris Broadway [mailto:midatlanticnet@gmail.com]
> Sent: Monday, August 21, 2006 9:52 AM
> To: Tim
> Subject: Re: MPLS newbie w/ a couple basic Q's
>
>
>
> To answer the first portion, you have to look at the whole picture and
the
> current method of MPLS deployment. You would have your LSRs running
MPLS
> in
> the MPLS domain and either OSPF or ISIS be the IGP for this domain.
This
> is
> on your diagram as rtr1,rtr2, and rtr3. Network "D" is also
important
> and
> contributes to the operation and how things get labeled. Consider
rtr3
> the
> "edge" of the MPLS domain (LER). It would have a BGP relationship to
the
> gateway router for Network "D". This would make rtr 3 aware of the
BGP
> table from Network D. YOU DO NOT WANT THE CORE LSRs TO HAVE THIS
> KNOWLEDGE.
> Since your diagram is only three routers, rtr2 would be the "CORE"
LSR,
> simply because it is not a LER. All LERs would have an IBGP peering
to
> each
> other. This would make all LERs aware of Network D. This means rtr1
> would
> now know how to get to Network D, is through rtr3. But how does he
get to
> rtr3? This is where the IGP is used. The IGP is used only as the
> transport
> for the BGP. Even if there were 100 routes in network D, rtr2 would
only
> see the IGP to rtr1 and 3 in its routing table. The BGP table of the
LERs
> is what would show all the routes. With all this said, I have not
> discussed
> layer2 or 3 VPN and VRFs used with MPLS. But it would generally still
> follow this principle.
>
>
>
> The second portion:
>
> the router knows of the label coming from rtr1 and rtr3. Also the
router
> knows of the label it gives for traffic going to rtr1 and 3. The
> operation
> from rtr2 would sound something like this:
>
>
>
> "I see signaling coming in on label 30...I know anything from label 30
is
> from rtr1. The signaling is trying to get to rtr3...I know I have to
swap
> label 30 with 35 for signaling going to rtr3"
>
>
>
> Then the opposite happens for the reverse traffic. The important
thing
> here
> is that all that is set up before the actual traffic flow. The MPLS
> signaling (LDP or RSVP) is what determines the label paths and sets up
the
> binding database. If the signaling does not happen, MPLS cannot work.
>
>
>
>
>
> -Broadway
>
>
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:58 ART