Re: mpls vpn's

Tony is exactly correct. But to clarify how;
In your output,
>> R2#sh mpls forwarding-table labels 201
>> Local Outgoing Prefix Bytes tag Outgoing Next Hop
>> tag tag or VC or Tunnel Id switched interface
>> 201 Pop tag 3.3.3.3/32 3238 Fa0/0 10.1.23.3

R2 is told to pop the tag for this prefix but it needs to be forwarded out of interface Fa0/0 to the next hop of 10.1.23.3. Therefore truly and routes to this next hop should be popped . Try by adding another prefix to the CE device and advertising it to the appropriate PE device.

Joe Sanchez
Sent from my iPad

On May 15, 2013, at 6:44 AM, Tony Singh <mothafungla_at_gmail.com> wrote:

> Well your CE shouldn't really be vrf aware, PE receives the packet after PHP
> of the transport label, looks at vpnv4 label and routes its accordingly as it
> knows it belongs to Cust-A as it or the other ends PE imposed the vpnv4 label
> in the first place
>
> --
> BR
>
> Tony
>
> Sent from my iPad
>
> On 15 May 2013, at 12:37, Paul Cocker <groupstudy_at_paulcocker.net> wrote:
>
>> Ah yes.... thanks Tony.
>>
>> R4#sh ip cef vrf CB 1.0.0.0
>> 1.0.0.0/8
>> nexthop 10.1.24.2 FastEthernet0/1 label 201 303
>> R4#
>>
>> and then on the PE...
>>
>> R2#sh mpls forwarding-table labels 201
>> Local Outgoing Prefix Bytes tag Outgoing Next Hop
>> tag tag or VC or Tunnel Id switched interface
>> 201 Pop tag 3.3.3.3/32 3238 Fa0/0 10.1.23.3
>> R2#
>>
>> and then on the CE...
>>
>> R3#sh mpls forwarding-table vrf CA
>> Local Outgoing Prefix Bytes Label Outgoing Next Hop
>> Label Label or VC or Tunnel Id Switched interface
>> 303 No Label 1.0.0.0/8[V] 0 Se1/1 point2point
>> 304 No Label 10.1.13.0/24[V] 0 aggregate/CA
>> 305 No Label 192.168.1.0/24[V] 0 Se1/1 point2point
>> R3#
>>
>> right, so that makes sense to me now...
>>
>> not quite sure how it drops into the correct VRF on the CE though?
>>
>> Thanks!
>> Paul
>>
>>
>>
>> On 15 May 2013 12:10, Tony Singh <mothafungla_at_gmail.com> wrote:
>> On the PE do "show ip cef vrf Cust-A x.x.x.x" this will show you the inner
> VPN label & the outer MPLS transport label, the label your looking at their is
> the VPNv4 label
>>
>> --
>> BR
>>
>> Tony
>>
>> Sent from my iPad
>>
>> On 15 May 2013, at 11:48, Paul Cocker <groupstudy_at_paulcocker.net> wrote:
>>
>>> Hi Group, hope you don't get duplicates of this mail. I've just switched
> to
>>> another email as nothing was getting though.
>>>
>>> Wonder if someone can clear up a query for me. I'm working through
> Narbiks
>>> MPLS section in his R&S workbook. I'm on the start of the MPLS VPN
> section.
>>>
>>> R1 ----- R3 ------ R2 ------- R4 ------ R5
>>>
>>> r1/r5 are CE's
>>> r3 / r4 are PE's
>>> R2 is a P
>>>
>>> On one PE , we have the following route for the other end of the network
> on
>>> R1.
>>>
>>> R4#sh ip bgp vpnv4 vrf CB 1.0.0.0
>>> BGP routing table entry for 1:20:1.0.0.0/8, version 8
>>> Paths: (1 available, best #1, table CB)
>>> Not advertised to any peer
>>> Local, imported path from 1:10:1.0.0.0/8
>>> 3.3.3.3 (metric 3) from 3.3.3.3 (3.3.3.3)
>>> Origin incomplete, metric 1, localpref 100, valid, internal, best
>>> Extended Community: RT:1:100
>>> mpls labels in/out nolabel/303
>>>
>>> So it uses label 303 for this. But how does it know which interface to
>>> use? I can't find 303 in the following tables,
>>>
>>> sh mpls forwarding table
>>> sh mpls ldp bindings
>>> sh mpls ip binding
>>>
>>> nor can I find it mentioned in the tables on the P router.
>>>
>>> I'm obviously missing something, as it works just fine end to end! Can
>>> someone explain how this works in LDP all the way to R1?
>>>
>>> Paul
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Wed May 15 2013 - 06:58:13 ART