Re: MPLS forwarding in partial mesh frame-relay networks

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
Blogs and organic groups at http://www.ccie.net