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.netReceived on Mon Nov 23 2009 - 13:29:52 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:29 ART