Re: MPLS forwarding in partial mesh frame-relay networks

Yeah i got that.

On Sat, Jan 23, 2010 at 12:08 AM, Bryan Bartik <bbartik_at_ipexpert.com> wrote:

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

-- 
Sent from Bengaluru, Karnataka, India
Blogs and organic groups at http://www.ccie.net