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
Received on Fri Jan 22 2010 - 13:26:29 ART
This archive was generated by hypermail 2.2.0 : Thu Feb 04 2010 - 20:28:41 ART