Re: MPLS forwarding in partial mesh frame-relay networks

Cool. In case you are wondering how the router might know the next-hop
address belongs to the downstream LSR...it is contained in an address
mapping message. The LSR basically sends all its interfaces addresses, so
the peer can look them up and tell if it can install the label or not. If
you do a "show mpls ldp neighor" at the bottom you will see a section called
"Addresses bound to peer LDP Ident:"

On Fri, Jan 22, 2010 at 11:31 AM, Divin Mathew John <divinjohn_at_gmail.com>wrote:

> Oh.! Thats was something !
>
>
> On Fri, Jan 22, 2010 at 11:56 PM, Steve Shaw <shaw38_at_gmail.com> wrote:
>
>> Bryan,
>>
>> Thanks! That's the rule I was looking for.
>>
>> Steve
>>
>> On Fri, Jan 22, 2010 at 1:03 PM, Bryan Bartik <bbartik_at_ipexpert.com>
>> wrote:
>>
>> > Rich,
>> >
>> > An LSR will only install a label for a prefix if the next-hop for that
>> > prefix is an address that belongs to the router from which it learned
>> the
>> > label. So if Router B's next-hop for Router C is Router C's address, it
>> will
>> > not install the label because the label was learned from Router A.
>> >
>> > What you can do to fix this is install a static route on router B for
>> C's
>> > address that points to A as the next-hop. Now the label learned from A
>> will
>> > be installed.
>> >
>> > On Fri, Jan 22, 2010 at 6:00 AM, Steve Shaw <shaw38_at_gmail.com> wrote:
>> >
>> >> Rich,
>> >>
>> >> Thanks for the reply. Try changing the OSPF network type on your serial
>> >> interfaces from point-to-multipoint to broadcast (with the hub as the
>> DR)
>> >> and you should see the behavior I mentioned.
>> >>
>> >> r2#show ip route
>> >>
>> >> 1.0.0.0/32 is subnetted, 1 subnets
>> >> O 1.1.1.1 [110/65] via 10.123.123.1, 00:09:33, Serial0/0.1
>> >> 2.0.0.0/32 is subnetted, 1 subnets
>> >> C 2.2.2.2 is directly connected, Loopback0
>> >> 3.0.0.0/32 is subnetted, 1 subnets
>> >> O 3.3.3.3 [110/65] via 10.123.123.3, 00:00:29, Serial0/0.1
>> >> 10.0.0.0/24 is subnetted, 1 subnets
>> >> C 10.123.123.0 is directly connected, Serial0/0.1
>> >>
>> >> 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 1.1.1.1/32 0 Se0/0.1 point2point
>> >> 17 Untagged 3.3.3.3/32 0 Se0/0.1 point2point
>> >>
>> >> -Steve
>> >>
>> >>
>> >> On Thu, Jan 21, 2010 at 7:07 PM, Rich Collins <nilsi2002_at_gmail.com>
>> >> wrote:
>> >>
>> >> > Hi,
>> >> >
>> >> > I tried to quickly reproduce this scenario but perhaps I didn't
>> >> > configure the way you did. I see the hop at the hub however.
>> Usually
>> >> > it is this way though for spoke to spoke via the multipoint hub??
>> >> > Which interfaces did you use for your targeted session?
>> >> >
>> >> > -Rich
>> >> >
>> >> > R2#sh mpls ldp neighbor
>> >> > Peer LDP Ident: 1.1.1.1:0; Local LDP Ident 2.2.2.2:0
>> >> > TCP connection: 1.1.1.1.646 - 2.2.2.2.42761
>> >> > State: Oper; Msgs sent/rcvd: 10/10; Downstream
>> >> > Up time: 00:01:02
>> >> > LDP discovery sources:
>> >> > Serial1/0.1, Src IP addr: 10.123.123.1
>> >> > Addresses bound to peer LDP Ident:
>> >> > 10.123.123.1 1.1.1.1
>> >> > Peer LDP Ident: 3.3.3.3:0; Local LDP Ident 2.2.2.2:0
>> >> > TCP connection: 3.3.3.3.12741 - 2.2.2.2.646
>> >> > State: Oper; Msgs sent/rcvd: 9/9; Downstream
>> >> > Up time: 00:00:37
>> >> > LDP discovery sources:
>> >> > Targeted Hello 2.2.2.2 -> 3.3.3.3, active, passive
>> >> > Addresses bound to peer LDP Ident:
>> >> > 10.123.123.3 3.3.3.3
>> >> > R2#sh mp
>> >> > R2#sh mpl
>> >> > R2#sh mpls fo
>> >> > R2#sh mpls forwarding-table
>> >> > Local Outgoing Prefix Bytes tag Outgoing Next Hop
>> >> > tag tag or VC or Tunnel Id switched interface
>> >> > 16 Pop tag 1.1.1.1/32 0 Se1/0.1
>> point2point
>> >> > 17 17 3.3.3.3/32 0 Se1/0.1
>> point2point
>> >> > 18 19 10.123.123.3/32 0 Se1/0.1
>> point2point
>> >> > 19 Untagged 10.123.123.1/32 0 Se1/0.1
>> point2point
>> >> > R2#sh ip c
>> >> >
>> >> >
>> >> > R2#sh ip cef 3.3.3.3
>> >> > 3.3.3.3/32, version 12, epoch 0, cached adjacency to Serial1/0.1
>> >> > 0 packets, 0 bytes
>> >> > tag information set
>> >> > local tag: 17
>> >> > fast tag rewrite with Se1/0.1, point2point, tags imposed: {17}
>> >> > via 10.123.123.1, Serial1/0.1, 0 dependencies
>> >> > next hop 10.123.123.1, Serial1/0.1
>> >> > valid cached adjacency
>> >> > tag rewrite with Se1/0.1, point2point, tags imposed: {17}
>> >> > R2#sh ip rou
>> >> >
>> >> > R2#sh ip route ospf
>> >> > 1.0.0.0/32 is subnetted, 1 subnets
>> >> > O 1.1.1.1 [110/65] via 10.123.123.1, 00:23:42, Serial1/0.1
>> >> > 3.0.0.0/32 is subnetted, 1 subnets
>> >> > O 3.3.3.3 [110/129] via 10.123.123.1, 00:23:42, Serial1/0.1
>> >> > 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
>> >> > O 10.123.123.3/32 [110/128] via 10.123.123.1, 00:23:42,
>> >> Serial1/0.1
>> >> > O 10.123.123.1/32 [110/64] via 10.123.123.1, 00:23:42,
>> >> Serial1/0.1
>> >> > R2#sh ip o
>> >> > R2#sh ip ospf n
>> >> > R2#sh ip ospf neighbor
>> >> >
>> >> > Neighbor ID Pri State Dead Time Address
>> >> Interface
>> >> > 10.123.123.1 255 FULL/ - 00:01:30 10.123.123.1
>> >> > Serial1/0.1
>> >> > R2#
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > On Mon, Jan 18, 2010 at 11:48 AM, Steve Shaw <shaw38_at_gmail.com>
>> wrote:
>> >> > > Guys (and Gals),
>> >> > >
>> >> > > I came across this scenario in a mock lab. Three routers sharing a
>> >> single
>> >> > > subnet (10.123.123.0/24) frame relay network:
>> >> > >
>> >> > > - A, B, C where A is the hub site with a single multi-point
>> >> > > sub-interface
>> >> > > - B/C as spokes with single point-to-point sub-interfaces with
>> PVCs
>> >> to
>> >> > A
>> >> > > - All are running OSPF (Non-broadcast, A is the DR) and MPLS LDP
>> >> > > - Loopbacks are A (1.1.1.1/32), B (2.2.2.2/24) and C (3.3.3.3/32
>> )
>> >> and
>> >> > > advertised in OSPF with the correct mask
>> >> > > - Targeted LDP session built between B and C
>> >> > >
>> >> > > The issue I can't wrap my head around is how B and C know there is
>> are
>> >> > > incomplete MPLS-VPN LSPs between them. I *believe* this is a sanity
>> >> check
>> >> > > function of MPLS forwarding on the router but looking for a
>> >> confirmation.
>> >> > >
>> >> > > From the perspective of B as the ingress LSR to C as the egress
>> LSR:
>> >> > >
>> >> > > B is learning the loopback of C (3.3.3.3/32) with the next-hop
>> >> unchanged
>> >> > so
>> >> > > it appears directly connected:
>> >> > >
>> >> > > B#show ip cef 3.3.3.3
>> >> > > 3.3.3.3/32, version 28, epoch 0, cached adjacency to Serial0/0.1
>> >> > > 0 packets, 0 bytes
>> >> > > tag information set
>> >> > > local tag: 17
>> >> > > via 10.123.123.3, Serial0/0.1, 0 dependencies
>> >> > > next hop 10.123.123.3, Serial0/0.1
>> >> > > valid cached adjacency
>> >> > > tag rewrite with Se0/0.1, point2point, tags imposed: {}
>> >> > >
>> >> > > In B's LIB, B is being told to pop the IGP label prior to
>> forwarding
>> >> to C
>> >> > > which would be correct if they were directly connected:
>> >> > >
>> >> > > B#show mpls ldp bindings 3.3.3.3 32
>> >> > > tib entry: 3.3.3.3/32, rev 6
>> >> > > local binding: tag: 17
>> >> > > remote binding: tsr: 1.1.1.1:0, tag: 17
>> >> > > remote binding: tsr: 3.3.3.3:0, tag: imp-null
>> >> > >
>> >> > > However, in the LFIB, B is removing the label stack completely:
>> >> > >
>> >> > > B#show mpls forwarding-table 3.3.3.3
>> >> > > Local Outgoing Prefix Bytes tag Outgoing Next Hop
>> >> > > tag tag or VC or Tunnel Id switched interface
>> >> > > 17 Untagged 3.3.3.3/32 0 Se0/0.1
>> >> point2point
>> >> > >
>> >> > >
>> >> > > From a layer 3 perspective, routers B and C appear to be directly
>> >> > connected.
>> >> > > But from a layer 2 perspective, there is actually 2 hops from B to
>> C
>> >> > through
>> >> > > the frame-relay network and hub router A.
>> >> > >
>> >> > > Based on the LIB, if B was to attempt to forward an MPLS-VPN
>> labeled
>> >> > packet
>> >> > > to C, B would:
>> >> > >
>> >> > > 1. Pop the top (IGP) label
>> >> > > 2. Forward the frame out it's serial interface toward A
>> >> > > 3. A would receive the labeled packet, attempt to do a lookup on
>> the
>> >> > > MPLS-VPN label (now top label w/ BoS bit set) and drop the packet
>> >> > >
>> >> > > To prevent the above scenario from occurring, does B place an entry
>> in
>> >> > the
>> >> > > LFIB to completely remove the stack since it knows the LSP is
>> >> incomplete?
>> >> > >
>> >> > > Thanks for the help,
>> >> > >
>> >> > > Steve
>> >> > >
>> >> > >
>> >> > > 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
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > 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 Bengaluru, Karnataka, India
>

-- 
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