Re: MPLS forwarding in partial mesh frame-relay networks

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
Received on Fri Jan 22 2010 - 08:00:08 ART