R3 distribute a label for 3.0.0.0/8 (pop tag), but R2 doesn't use it because
there is a longest match 3.3.3.3/32 (from static)
The problem is that 3.3.3.3/32 has not remote binding label.
R2#sh mpls ldp bindings 3.0.0.0 255.0.0.0
tib entry: 3.0.0.0/8, rev 7
remote binding: tsr: 3.3.3.3:0, tag: imp-null
R2#sh mpls ldp bindings 3.3.3.3 255.255.255.255
tib entry: 3.3.3.3/32, rev 6
local binding: tag: 16
When you fix loopback netmask to /32 (or fix static route to /8), BGP
recursive lookup will find label for next-hop 3.3.3.3
R2#sh mpls ldp bindings 3.3.3.3 255.255.255.255
tib entry: 3.3.3.3/32, rev 6
local binding: tag: 16
remote binding: tsr: 3.3.3.3:0, tag: imp-null
I never put attention in this problem, because using of IGP on backbone
prevents it....
mirco.
On Mon, Nov 23, 2009 at 11:00 PM, Divin Mathew John <divinjohn_at_gmail.com>wrote:
> 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
Received on Mon Nov 23 2009 - 23:33:16 ART
This archive was generated by hypermail 2.2.0 : Tue Dec 01 2009 - 06:36:29 ART