Re: MPLS forwarding in partial mesh frame-relay networks

From: Rich Collins <nilsi2002_at_gmail.com>
Date: Thu, 21 Jan 2010 19:07:20 -0500

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 Thu Jan 21 2010 - 19:07:20 ART

This archive was generated by hypermail 2.2.0 : Thu Feb 04 2010 - 20:28:41 ART