Re: MPLS VPN Encapsulation problem

is the MPLS encapsulation failed error because of the fact that R2
fails to get a label from R3 for 3.3.3.3/32 ? so. R2 fails to find a
label advertised by R3 for this particular prefix?

On Tue, Nov 24, 2009 at 1:59 AM, Bryan Bartik <bbartik_at_ipexpert.com> wrote:
> Mirco,
>
> That's not needed in this case. But you would use that in a
> carrier-supporting-carrier scenario where one ISP is using MPLS VPN services
> to support an ISP that is also using MPLS.
>
> It's definitely not for the faint of heart :) but you can try one of
> Antonio's scenarios here:
>
> http://www.ccie18473.net/dynamips/dynamips.htm#csc-cc-mpls
>
>
> On Mon, Nov 23, 2009 at 1:11 PM, Mirco Orlandi <mirco.orlandi_at_gmail.com>wrote:
>
>> Very good lab to understand better ldp bindings. Thanks.
>> but, what about "mpls ip" enabled under (PE)<>(CE) interface?
>>
>>
>> !
>> interface FastEthernet0/0
>> ip vrf forwarding CA
>> ip address 10.1.12.2 255.255.255.0
>> mpls ip
>> !
>>
>> I have vrf-aware ldp binding ("show mpls ldp binding vrf CA") but this is
>> not a classic MPLS VPN environment.
>> Can you suggest a real scenario where make sense?
>>
>> mirco.
>>
>>
>> On Mon, Nov 23, 2009 at 5:14 AM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>>
>>> Nate,
>>>
>>> That is a good question. The reason is because you already had a more
>>> specific entry in your LIB for 3.3.3.3 (from the static route). If your
>>> static routes were pointed at 3.0.0.0/8 and 2.0.0.0/8 then it would work.
>>>
>>> On Sun, Nov 22, 2009 at 7:37 PM, Nate Lee <natetlee_at_gmail.com> wrote:
>>>
>>> > Thanks Bryan, that seemed to have solved it. I was under the impression
>>> > that I only needed to have a /32 route to the loopback on the local
>>> router,
>>> > not that the loopback itself had to actually be a /32.
>>> >
>>> > After doing some reading, it looks like this is because there is no
>>> label
>>> > on
>>> > R2 for 3.3.3.3/32 while one exists for 3.0.0.0/8. Why does it not use
>>> the
>>> > larger and more inclusive 3.0.0.0/8 label binding which shows the
>>> correct
>>> > imp-null value to send the packet across?
>>> >
>>> > From R2:
>>> >
>>> > tib entry: 3.0.0.0/8, rev 9
>>> > remote binding: tsr: 3.3.3.3:0, tag: imp-null
>>> >
>>> > Thanks again!
>>> >
>>> > Nate
>>> >
>>> > On Sun, Nov 22, 2009 at 7:25 PM, Bryan Bartik <bbartik_at_ipexpert.com>
>>> > wrote:
>>> >
>>> > > Nate,
>>> > >
>>> > > Your loopbacks are /8 so what I guess is happening is R2 is
>>> advertising a
>>> > > label for 2.0.0.0/8 and R3 is advertising a label for 3.0.0.0/8. This
>>> > > prefix does not match what is in your IGP (or static route in your
>>> case).
>>> > >
>>> > > Change the loopbacks to /32 and try it again.
>>> > >
>>> > > On Sun, Nov 22, 2009 at 6:05 PM, Nate Lee <natetlee_at_gmail.com> wrote:
>>> > >
>>> > >> I'm hoping that I missed something very simple here, or maybe not
>>> since
>>> > I
>>> > >> have spent an inordinate amount of time trying to figure out what I
>>> did
>>> > >> wrong.
>>> > >>
>>> > >> I am just getting started with MPLS VPNs and setup a simple network
>>> with
>>> > >> R1
>>> > >> (CE) <> R2 (PE) <> R3(PE) <> R4 (CE), so no P routers in the mix at
>>> all
>>> > (I
>>> > >> tried it with a P router between the PEs but it didn't work so this
>>> is
>>> > my
>>> > >> stripped down version to help me narrow the problem down).
>>> > >>
>>> > >> I am running iBGP between R2 and R3 and am redistributing static
>>> routes
>>> > >> for
>>> > >> each CE routers loopbacks on the PE routers as well as redistributing
>>> > >> connected into the ipv4 vrf address-family in BGP. Each PE has only
>>> a
>>> > >> single VRF tied to its CE facing interface.
>>> > >>
>>> > >> My problem is that I cannot ping from CE to CE or from VRF interface
>>> to
>>> > >> VRF
>>> > >> interface between the PE routers. All routes show up across BGP and
>>> > >> populate into the VRF routing tables fine, but when I try to ping
>>> from
>>> > the
>>> > >> VRF interface on R2 to the VRF interface on R3, I get an MPLS
>>> > >> encapsulation
>>> > >> failed error. I have checked the CEF table, the label bindings and
>>> > label
>>> > >> forwarding tables and everything looks good.
>>> > >>
>>> > >> Here is what I get when I do a PING VRF CA 10.1.34.3 so 10.1.12.2.
>>> This
>>> > >> is
>>> > >> R2's CE facing VRF CA interface to R3's CE facing VRF CB interface.
>>> > >>
>>> > >> *Mar 1 01:30:01.675: IP: s=10.1.12.2 (local), d=10.1.34.3
>>> > >> (FastEthernet0/1), len 100, MPLS encapsulation failed
>>> > >> *Mar 1 01:30:01.679: ICMP type=8, code=0
>>> > >>
>>> > >> I am assuming that I am missing something small, but I can't seem to
>>> > >> figure
>>> > >> out what it is.
>>> > >>
>>> > >> Here are my configs on R2 and R3:
>>> > >>
>>> > >> R2:
>>> > >>
>>> > >> ip vrf CA
>>> > >> rd 1:1
>>> > >> route-target export 1:100
>>> > >> route-target import 1:100
>>> > >> !
>>> > >> interface Loopback0
>>> > >> ip address 2.2.2.2 255.0.0.0
>>> > >> !
>>> > >> interface FastEthernet0/0
>>> > >> ip vrf forwarding CA
>>> > >> ip address 10.1.12.2 255.255.255.0
>>> > >> mpls ip
>>> > >> !
>>> > >> interface FastEthernet0/1
>>> > >> ip address 10.1.23.2 255.255.255.0
>>> > >> mpls ip
>>> > >> !
>>> > >> router bgp 100
>>> > >> no bgp default ipv4-unicast
>>> > >> bgp log-neighbor-changes
>>> > >> neighbor 3.3.3.3 remote-as 100
>>> > >> neighbor 3.3.3.3 update-source Loopback0
>>> > >> !
>>> > >> address-family ipv4
>>> > >> neighbor 3.3.3.3 activate
>>> > >> neighbor 3.3.3.3 next-hop-self
>>> > >> no auto-summary
>>> > >> no synchronization
>>> > >> exit-address-family
>>> > >> !
>>> > >> address-family vpnv4
>>> > >> neighbor 3.3.3.3 activate
>>> > >> neighbor 3.3.3.3 send-community both
>>> > >> exit-address-family
>>> > >> !
>>> > >> address-family ipv4 vrf CA
>>> > >> redistribute connected
>>> > >> redistribute static
>>> > >> no synchronization
>>> > >> exit-address-family
>>> > >> !
>>> > >> ip forward-protocol nd
>>> > >> ip route 3.3.3.3 255.255.255.255 10.1.23.3
>>> > >> ip route vrf CA 1.1.1.1 255.255.255.255 10.1.12.1
>>> > >>
>>> > >> R3:
>>> > >>
>>> > >> ip vrf CB
>>> > >> rd 2:2
>>> > >> route-target export 1:100
>>> > >> route-target import 1:100
>>> > >> !
>>> > >> interface Loopback0
>>> > >> ip address 3.3.3.3 255.0.0.0
>>> > >> !
>>> > >> interface FastEthernet0/0
>>> > >> ip vrf forwarding CB
>>> > >> ip address 10.1.34.3 255.255.255.0
>>> > >> mpls ip
>>> > >> !
>>> > >> interface FastEthernet0/1
>>> > >> ip address 10.1.23.3 255.255.255.0
>>> > >> mpls ip
>>> > >> !
>>> > >> router bgp 100
>>> > >> no bgp default ipv4-unicast
>>> > >> bgp log-neighbor-changes
>>> > >> neighbor 2.2.2.2 remote-as 100
>>> > >> neighbor 2.2.2.2 update-source Loopback0
>>> > >> !
>>> > >> address-family ipv4
>>> > >> neighbor 2.2.2.2 activate
>>> > >> no auto-summary
>>> > >> no synchronization
>>> > >> exit-address-family
>>> > >> !
>>> > >> address-family vpnv4
>>> > >> neighbor 2.2.2.2 activate
>>> > >> neighbor 2.2.2.2 send-community both
>>> > >> exit-address-family
>>> > >> !
>>> > >> address-family ipv4 vrf CB
>>> > >> redistribute connected
>>> > >> redistribute static
>>> > >> no synchronization
>>> > >> exit-address-family
>>> > >> !
>>> > >> ip forward-protocol nd
>>> > >> ip route 2.2.2.2 255.255.255.255 10.1.23.2
>>> > >> ip route vrf CB 4.4.4.4 255.255.255.255 10.1.34.4
>>> > >> !
>>> > >>
>>> > >>
>>> > >> Blogs and organic groups at http://www.ccie.net
>>> > >>
>>> > >>
>>> _______________________________________________________________________
>>> > >> Subscription information may be found at:
>>> > >> http://www.groupstudy.com/list/CCIELab.html
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >>
>>> > >
>>> > >
>>> > > --
>>> > > Bryan Bartik
>>> > > CCIE #23707 (R&S, SP), CCNP
>>> > > Sr. Support Engineer - IPexpert, Inc.
>>> > > URL: http://www.IPexpert.com
>>> >
>>> >
>>> > Blogs and organic groups at http://www.ccie.net
>>> >
>>> > _______________________________________________________________________
>>> > Subscription information may be found at:
>>> > http://www.groupstudy.com/list/CCIELab.html
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>> --
>>> Bryan Bartik
>>> CCIE #23707 (R&S, SP), CCNP
>>> Sr. Support Engineer - IPexpert, Inc.
>>> URL: http://www.IPexpert.com
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Bryan Bartik
> CCIE #23707 (R&S, SP), CCNP
> Sr. Support Engineer - IPexpert, Inc.
> URL: http://www.IPexpert.com
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Sent from Karnataka, India
Oscar Wilde  - "Arguments are to be avoided; they are always vulgar
and often convincing." -
http://www.quotationspage.com/quote/23638.html
Blogs and organic groups at http://www.ccie.net