Re: MPLS tagging issue from Brian Buxton on 2010-06-25 (Ccielab archives 06/2010)

From: Brian Buxton <herrbuxy_at_gmail.com>
Date: Fri, 25 Jun 2010 07:05:09 -0400

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), add
>> rem binding
>> *Mar 1 13:49:12.036: tagcon: tibent(3.3.3.3/32): label 25 from 2.2.2.2:0
>> added
>> *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
>> *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: 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
>> >> *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: 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
>> >>>
>> >>>
>> >>>
>> >>> *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; Local LDP Ident 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; Local LDP Ident 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; Local LDP Ident 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; Local LDP Ident 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; Local LDP Ident 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; Local LDP Ident 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
>> >>>
>> >>>
>> _______________________________________________________________________
>> >>> 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

Blogs and organic groups at http://www.ccie.net
Received on Fri Jun 25 2010 - 07:05:09 ART

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