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 09:11:56 -0400

That was it. much appreciated. I would have included sooner but was trying
to prevent sending a novel unnecessarily.

thank you

On Fri, Jun 25, 2010 at 9:06 AM, Tyson Scott <tscott_at_ipexpert.com> wrote:

> 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: 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), 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 - 09:11:56 ART

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