RE: MPLS tagging issue from Tyson Scott on 2010-06-25 (Ccielab archives 06/2010)

From: Tyson Scott <tscott_at_ipexpert.com>
Date: Fri, 25 Jun 2010 09:06:23 -0400

Including details like running configurations can always help in narrowing
these things down quicker. Antonio beat me to the answer.

Regards,

Tyson Scott - CCIE #13513 R&S, Security, and SP

Managing Partner / Sr. Instructor - IPexpert, Inc.

Mailto: <mailto:tscott_at_ipexpert.com> tscott_at_ipexpert.com

From: Antonio Soares [mailto:amsoares_at_netcabo.pt]
Sent: Friday, June 25, 2010 8:22 AM
To: 'Brian Buxton'
Cc: 'Tyson Scott'; 'CCIE Groupstudy'
Subject: RE: MPLS tagging issue

Move to OSPF P2MP instead of Broadcast (R2-R3-R4). The problem you are
seeing is due to Next-hop propagation.

Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoares_at_netcabo.pt

_____

From: Brian Buxton [mailto:herrbuxy_at_gmail.com]
Sent: sexta-feira, 25 de Junho de 2010 12:05
To: Antonio Soares
Cc: Tyson Scott; CCIE Groupstudy
Subject: Re: MPLS tagging issue

I am including R2's configuration. I can't help believing the problem is
with R2. I notice that R3 has the same problem with R4's loopback coming up
"untagged" in the mpls FIB.

R2#sh run
Building configuration...

Current configuration : 2403 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
ip vrf RED
rd 65070:70
route-target export 65070:1
route-target import 65060:1
route-target import 65080:1
!
no ip domain lookup
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
archive
log config
  hidekeys
!
!
!
!
!
!
!
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
ip ospf 1 area 0
!
interface FastEthernet0/0
ip vrf forwarding RED
ip address 192.168.70.1 255.255.255.0
duplex auto
speed auto
!
interface Serial0/0
description R2
no ip address
encapsulation frame-relay
mpls ip
clock rate 2000000
no frame-relay inverse-arp
!
interface Serial0/0.234 multipoint
ip address 10.10.10.2 255.255.255.0
ip ospf network broadcast
ip ospf 1 area 0
snmp trap link-status
mpls ip
frame-relay map ip 10.10.10.4 204 broadcast
frame-relay map ip 10.10.10.3 203
frame-relay map ip 10.10.10.2 203 broadcast
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
no ip address
shutdown
clock rate 2000000
!
router ospf 1
router-id 2.2.2.2
log-adjacency-changes
!
router bgp 65000
bgp log-neighbor-changes
neighbor 3.3.3.3 remote-as 65000
neighbor 3.3.3.3 update-source Loopback0
neighbor 5.5.5.5 remote-as 65000
neighbor 5.5.5.5 update-source Loopback0
!
address-family ipv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 route-reflector-client
  neighbor 3.3.3.3 next-hop-self
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 route-reflector-client
  neighbor 5.5.5.5 next-hop-self
  no auto-summary
  no synchronization
exit-address-family
!
address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
  neighbor 3.3.3.3 route-reflector-client
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-community extended
  neighbor 5.5.5.5 route-reflector-client
exit-address-family
!
address-family ipv4 vrf RED
  neighbor 192.168.70.2 remote-as 65070
  neighbor 192.168.70.2 activate
  no synchronization
exit-address-family
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
!
!
!
mpls ldp router-id Loopback0 force
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

On Fri, Jun 25, 2010 at 6:59 AM, Brian Buxton <herrbuxy_at_gmail.com> wrote:

Yes.

R3#sh run int Lo0
Building configuration...

Current configuration : 81 bytes
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
ip ospf 1 area 0
end

On Fri, Jun 25, 2010 at 6:56 AM, Antonio Soares <amsoares_at_netcabo.pt> wrote:

Are you using /32 loopbacks ?

Regards,

Antonio Soares, CCIE #18473 (R&S/SP)
amsoares_at_netcabo.pt

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Brian Buxton

Sent: sexta-feira, 25 de Junho de 2010 11:48
To: Tyson Scott
Cc: CCIE Groupstudy
Subject: Re: MPLS tagging issue

Alright. When I was playing with sub-interfaces I forgot to reapply the
frame map. It is back and R4 can ping R3 again. I shut and no shut the
sub-interface and reproduced the same debug output.

*Mar 1 13:49:12.036: tagcon: announce labels for: 2.2.2.2/32; nh
10.10.10.2, Se0/0.42, inlabel 17, outlabel imp-null (from 2.2.2.2:0
<http://2.2.2.2:0/> ), add
rem binding
*Mar 1 13:49:12.036: tagcon: tibent(3.3.3.3/32): label 25 from
2.2.2.2:0added
*Mar 1 13:49:12.040: tib: Not OK to announce label; nh 10.10.10.3 not bound
to 2.2.2.2:0 <http://2.2.2.2:0/>
*Mar 1 13:49:12.040: tagcon: omit announce labels for: 3.3.3.3/32; nh
10.10.10.3, Se0/0.42, from 2.2.2.2:0 <http://2.2.2.2:0/> : add rem binding:
next hop = 10.10.10.3

On Fri, Jun 25, 2010 at 6:43 AM, Brian Buxton <herrbuxy_at_gmail.com> wrote:

> I lied. in my troubleshooting of MPLS I have apparently broken R4's
> ability to ping R3. I will fix and repost.
>
>
> On Fri, Jun 25, 2010 at 6:42 AM, Brian Buxton <herrbuxy_at_gmail.com> wrote:
>
>> Yes. All of the P and PE can ping all Lo0 and S0/0 interfaces. I tried
>> debug mpls ldp messages sent and received and observed the following.
>>
>> *Mar 1 13:38:17.432: tagcon: tibent(3.3.3.3/32): label 25 from
2.2.2.2:0added
>> *Mar 1 13:38:17.432: tib: Not OK to announce label; nh 10.10.10.3 not
>> bound
>> to
>> 2.2.2.2:0 <http://2.2.2.2:0/>
>> *Mar 1 13:38:17.436: tagcon: omit announce labels for: 3.3.3.3/32; nh
>> 10.10.10.
>> 3, Se0/0.42, from 2.2.2.2:0 <http://2.2.2.2:0/> : add rem binding: next
hop = 10.10.10.3
>>
>> It appears as though R4 sees R2's tag, but rejects it because the next
hop
>> isn't bound to R2. Any ideas on how to correct? Adrian asked me to post
>> the configs. That would be an awfully long post, but I can certainly
>> forward them to the list if you want.
>> On Thu, Jun 24, 2010 at 5:33 PM, Tyson Scott
<tscott_at_ipexpert.com>wrote:
>>
>>> Does R4 know how to get to 3.3.3.3? is it in the routing table? Are
>>> all the LDP source addresses in the RIB?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>>
>>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>>
>>> Mailto: tscott_at_ipexpert.com
>>>
>>>
>>>
>>>
>>>
>>> *From:* Brian Buxton [mailto:herrbuxy_at_gmail.com]
>>> *Sent:* Thursday, June 24, 2010 5:09 PM
>>>
>>> *To:* Tyson Scott
>>> *Cc:* CCIE Groupstudy
>>> *Subject:* Re: MPLS tagging issue
>>>
>>>
>>>
>>> I applied the commands and it changed the order that the IP bindings
>>> appear (so that the Lo0 is first). However still no ping from the CE to
CE.
>>>
>>>
>>>
>>> Interestingly, Both the CE on R5 and the CE on R3 can ping all
advertised
>>> addresses on the CE on R2. They just can't get to each other.
>>>
>>> On Thu, Jun 24, 2010 at 4:19 PM, Tyson Scott <tscott_at_ipexpert.com>
>>> wrote:
>>>
>>> It looks like R4 is the only one sourcing LDP from it's loopback
>>>
>>>
>>>
>>> Do the following on them and see if this solves the problem
>>>
>>> mpls ldp router-id lo0 force
>>>
>>>
>>>
>>> Also on R4 make sure you have
>>>
>>> no bgp default route-target filter
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>>
>>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>>
>>> Mailto: tscott_at_ipexpert.com
>>>
>>> Telephone: +1.810.326.1444, ext. 208
>>>
>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>>
>>> eFax: +1.810.454.0130
>>>
>>>
>>>
>>> IPexpert is a premier provider of Self-Study Workbooks, Video on Demand,
>>> Audio Tools, Online Hardware Rental and Classroom Training for the Cisco
>>> CCIE (R&S, Voice, Security & Service Provider) certification(s) with
>>> training locations throughout the United States, Europe, South Asia and
>>> Australia. Be sure to visit our online communities at
>>> www.ipexpert.com/communities and our public website at www.ipexpert.com
<http://www.ipexpert.com/>
>>>
>>>
>>>
>>> *From:* Brian Buxton [mailto:herrbuxy_at_gmail.com]
>>> *Sent:* Thursday, June 24, 2010 4:10 PM
>>> *To:* Tyson Scott
>>> *Cc:* CCIE Groupstudy
>>> *Subject:* Re: MPLS tagging issue
>>>
>>>
>>>
>>> Command output from each router follows. It seems to me that 3.3.3.3
>>> does appear to be an address bound between R2 and R3.
>>>
>>>
>>>
>>> R3#sh mpls ldp neigh
>>> Peer LDP Ident: 10.10.10.2:0 <http://10.10.10.2:0/> ; Local LDP
Ident 10.10.10.3:0 <http://10.10.10.3:0/>
>>> TCP connection: 10.10.10.2.646 - 10.10.10.3.43726
>>> State: Oper; Msgs sent/rcvd: 380/381; Downstream
>>> Up time: 05:25:30
>>> LDP discovery sources:
>>> Serial0/0, Src IP addr: 10.10.10.2
>>> Addresses bound to peer LDP Ident:
>>> 10.10.10.2 2.2.2.2
>>>
>>> R2#sh mpls ldp neigh
>>> Peer LDP Ident: 10.10.10.3:0 <http://10.10.10.3:0/> ; Local LDP
Ident 10.10.10.2:0 <http://10.10.10.2:0/>
>>> TCP connection: 10.10.10.3.43726 - 10.10.10.2.646
>>> State: Oper; Msgs sent/rcvd: 381/380; Downstream
>>> Up time: 05:25:52
>>> LDP discovery sources:
>>> Serial0/0, Src IP addr: 10.10.10.3
>>> * Addresses bound to peer LDP Ident:**
>>> 10.10.10.3 3.3.3.3
>>> * Peer LDP Ident: 4.4.4.4:0 <http://4.4.4.4:0/> ; Local LDP Ident
10.10.10.2:0 <http://10.10.10.2:0/>
>>> TCP connection: 4.4.4.4.646 - 10.10.10.2.56602
>>> State: Oper; Msgs sent/rcvd: 66/67; Downstream
>>> Up time: 00:50:37
>>> LDP discovery sources:
>>> Serial0/0, Src IP addr: 10.10.10.4
>>> Addresses bound to peer LDP Ident:
>>> 10.10.10.4 10.10.15.4 4.4.4.4
>>>
>>> R4#sh mpls ldp neigh
>>> Peer LDP Ident: 10.10.15.5:0 <http://10.10.15.5:0/> ; Local LDP
Ident 4.4.4.4:0 <http://4.4.4.4:0/>
>>> TCP connection: 10.10.15.5.49240 - 4.4.4.4.646
>>> State: Oper; Msgs sent/rcvd: 68/69; Downstream
>>> Up time: 00:52:39
>>> LDP discovery sources:
>>> Serial0/0.45, Src IP addr: 10.10.15.5
>>> Addresses bound to peer LDP Ident:
>>> 10.10.15.5 5.5.5.5
>>> Peer LDP Ident: 10.10.10.2:0 <http://10.10.10.2:0/> ; Local LDP
Ident 4.4.4.4:0 <http://4.4.4.4:0/>
>>> TCP connection: 10.10.10.2.56602 - 4.4.4.4.646
>>> State: Oper; Msgs sent/rcvd: 68/67; Downstream
>>> Up time: 00:51:13
>>> LDP discovery sources:
>>> Serial0/0.42, Src IP addr: 10.10.10.2
>>> Addresses bound to peer LDP Ident:
>>> 10.10.10.2 2.2.2.2
>>>
>>> R5#sh mpls ldp neigh
>>> Peer LDP Ident: 4.4.4.4:0 <http://4.4.4.4:0/> ; Local LDP Ident
10.10.15.5:0 <http://10.10.15.5:0/>
>>> TCP connection: 4.4.4.4.646 - 10.10.15.5.49240
>>> State: Oper; Msgs sent/rcvd: 69/69; Downstream
>>> Up time: 00:52:57
>>> LDP discovery sources:
>>> Serial0/0.54, Src IP addr: 10.10.15.4
>>> Addresses bound to peer LDP Ident:
>>> 10.10.10.4 10.10.15.4 4.4.4.4
>>>
>>> On Thu, Jun 24, 2010 at 3:34 PM, Tyson Scott <tscott_at_ipexpert.com>
>>> wrote:
>>>
>>> What is the output of show mpls ldp neighbors? Is R3 sending the Lo to
>>> R4
>>> as a route it is sending labels for?
>>>
>>> Regards,
>>>
>>> Tyson Scott - CCIE #13513 R&S, Security, and SP
>>> Managing Partner / Sr. Instructor - IPexpert, Inc.
>>> Mailto: tscott_at_ipexpert.com
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>> Brian Buxton
>>> Sent: Thursday, June 24, 2010 3:30 PM
>>> To: CCIE Groupstudy
>>> Subject: MPLS tagging issue
>>>
>>> Hello all,
>>>
>>> I am having trouble with a loopback not being tagged by a P router. R3
>>> Lo0
>>> can ping R5 Lo0, however the CE on vrf RED attached to R3 cannot ping
the
>>> CE
>>> on vrf RED attached to R5 even though the networks are making it to both
>>> PE
>>> BGP tables. I think I have narrowed the issue to a P router (R4) that
>>> has
>>> no CE attached. It does not appear to be tagging the R3 Lo0. This
seems
>>> to
>>> permit BGP to propogate, but break the actual traffic between the VRFs.
>>> I
>>> am including "sh ip bgp vpnv4 vrf RED" on both R3 and R5 as well as "sh
>>> mpls
>>> forwarding-table" on R2 and R4. Note the line in the R4 output that
>>> reads
>>> "18 Untagged 3.3.3.3/3 ..." This is what leads me to believe the
>>> problem lies on either R2 or R4. Any guidance is appreciated.
>>> Thank you,
>>> Brian
>>>
>>> R3 - R2 - R4 - R5
>>>
>>> R3 Lo0 = 3.3.3.3
>>> R5 Lo0 = 5.5.5.5
>>>
>>> R3#sh ip bgp vpnv4 vrf RED
>>> BGP table version is 237, local router ID is 10.10.10.3
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>> internal,
>>> r RIB-failure, S Stale
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>
>>> Network Next Hop Metric LocPrf Weight Path
>>> Route Distinguisher: 65080:70 (default for vrf RED)
>>> *>i6.6.6.6/32 5.5.5.5 0 100 0 65060 i
>>> *>i7.7.7.7/32 2.2.2.2 0 100 0 65070 i
>>> *> 8.8.8.8/32 192.168.80.2 0 0 65080 i
>>> *>i160.100.100.0/24 5.5.5.5 0 100 0 65060 i
>>> *>i160.110.110.0/24 5.5.5.5 0 100 0 65060 i
>>> *>i160.120.120.0/24 5.5.5.5 0 100 0 65060 i
>>> *>i170.100.100.0/24 2.2.2.2 0 100 0 65070 i
>>> *>i170.110.110.0/24 2.2.2.2 0 100 0 65070 i
>>> *>i170.120.120.0/24 2.2.2.2 0 100 0 65070 i
>>> *> 180.100.100.0/24 192.168.80.2 0 0 65080 i
>>> *> 180.110.110.0/24 192.168.80.2 0 0 65080 i
>>> *> 180.120.120.0/24 192.168.80.2 0 0 65080 i
>>> *>i192.168.60.0 5.5.5.5 0 100 0 65060 i
>>> *>i192.168.70.0 2.2.2.2 0 100 0 65070 i
>>> r> 192.168.80.0 192.168.80.2 0 0 65080 i
>>>
>>> R5#sh ip bgp vpnv4 vrf RED
>>> BGP table version is 252, local router ID is 10.10.15.5
>>> Status codes: s suppressed, d damped, h history, * valid, > best, i -
>>> internal,
>>> r RIB-failure, S Stale
>>> Origin codes: i - IGP, e - EGP, ? - incomplete
>>>
>>> Network Next Hop Metric LocPrf Weight Path
>>> Route Distinguisher: 65080:70 (default for vrf RED)
>>> *> 6.6.6.6/32 192.168.60.2 0 0 65060 i
>>> *>i7.7.7.7/32 2.2.2.2 0 100 0 65070 i
>>> *>i8.8.8.8/32 3.3.3.3 0 100 0 65080 i
>>> *> 160.100.100.0/24 192.168.60.2 0 0 65060 i
>>> *> 160.110.110.0/24 192.168.60.2 0 0 65060 i
>>> *> 160.120.120.0/24 192.168.60.2 0 0 65060 i
>>> *>i170.100.100.0/24 2.2.2.2 0 100 0 65070 i
>>> *>i170.110.110.0/24 2.2.2.2 0 100 0 65070 i
>>> *>i170.120.120.0/24 2.2.2.2 0 100 0 65070 i
>>> *>i180.100.100.0/24 3.3.3.3 0 100 0 65080 i
>>> *>i180.110.110.0/24 3.3.3.3 0 100 0 65080 i
>>> *>i180.120.120.0/24 3.3.3.3 0 100 0 65080 i
>>> r> 192.168.60.0 192.168.60.2 0 0 65060 i
>>> *>i192.168.70.0 2.2.2.2 0 100 0 65070 i
>>> *>i192.168.80.0 3.3.3.3 0 100 0 65080 i
>>>
>>> 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 10.10.15.0/24 0 Se0/0 10.10.10.4

>>> 17 Untagged 170.120.120.0/24[V] <http://170.120.120.0/24%5BV%5D>
<http://170.120.120.0/24%5bV%5d> \

>>> 0 Fa0/0 192.168.70.2

>>> 18 Untagged 170.110.110.0/24[V] <http://170.110.110.0/24%5BV%5D>
<http://170.110.110.0/24%5bV%5d> \

>>> 0 Fa0/0 192.168.70.2

>>> 19 Untagged 170.100.100.0/24[V] <http://170.100.100.0/24%5BV%5D>
<http://170.100.100.0/24%5bV%5d> \

>>> 684 Fa0/0 192.168.70.2

>>> 20 Untagged 7.7.7.7/32[V] <http://7.7.7.7/32%5BV%5D>
<http://7.7.7.7/32%5bV%5d> 1254

>>> Fa0/0 192.168.70.2
>>> 21 16 5.5.5.5/32 0 Se0/0 10.10.10.4
>>> 22 Pop tag 3.3.3.3/32 0 Se0/0 10.10.10.3
>>> 23 Pop tag 4.4.4.4/32 0 Se0/0 10.10.10.4
>>>
>>> R4#sh mpls forwarding-table
>>> Local Outgoing Prefix Bytes tag Outgoing Next Hop
>>> tag tag or VC or Tunnel Id switched interface
>>> 16 Pop tag 5.5.5.5/32 872 Se0/0.45 point2point
>>> 17 Pop tag 2.2.2.2/32 598 Se0/0.42 10.10.10.2
>>>
>>> *18 Untagged 3.3.3.3/32 0 Se0/0.42 10.10.10.3*
>>>
>>>
>>> Blogs and organic groups at http://www.ccie.net <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 <http://www.ccie.net/>
Received on Fri Jun 25 2010 - 09:06:23 ART

This archive was generated by hypermail 2.2.0 : Sun Aug 01 2010 - 09:11:38 ART