CPT_Core#show mpls forwarding-table 196.44.74.254
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
34 Pop tag 196.44.74.254/32 5353017 Se4/0 point2point
This is from the router that has the 10.100.100.1 vrf interface.
Thanks
-----Original Message-----
From: Giles Heron [mailto:giles@packetexchange.net]
Sent: Thursday, June 06, 2002 6:55 PM
To: Duane de Witt
Cc: cisco-nsp@puck.nether.net
Subject: RE: [nsp] MPLS TE
On Thu, 2002-06-06 at 15:46, Duane de Witt wrote:
> This is what I noticed when doing a lookup on the actual interface I
am
> trying to get to.
>
> RBA_Core#show ip cef vrf test 10.100.100.1
> 10.100.100.1/32, version 12, epoch 0, per-packet sharing
> 0 packets, 0 bytes
> Flow: AS 0, mask 32
> tag information set
> local tag: VPN-route-head
> fast tag rewrite with
> Recursive rewrite via 196.44.74.2/32, tags imposed {66}
> via 196.44.74.2, 0 dependencies, recursive
> next hop 196.44.74.2, Tunnel101 via 196.44.74.2/32
> valid adjacency
> tag rewrite with
> Recursive rewrite via 196.44.74.2/32, tags imposed {66}
> Recursive load sharing using 196.44.74.2/32.
>
> RBA_Core#show mpls forwarding-table vrf test 10.100.100.1 de
> RBA_Core#show mpls forwarding-table vrf test 10.100.100.1 detail
> Local Outgoing Prefix Bytes tag Outgoing Next Hop
> tag tag or VC or Tunnel Id switched interface
> None Recursive 10.100.100.1/32 0
> Recursive rewrite via 196.44.74.2/32, Tag Stack{66}
> 00042000
> No output feature configured
>
> This comes from the router with the tunnels. 196.44.74.2 is the
loopback
> interface of the router that the vrf with 10.100.100.1 is on.
>
> Any ideas? I don't know what a recursive rewrite is.
I think it means that it will have to add another label to get to
196.44.74.2 via the tunnel (since it isn't directly connected).
But I'd still like to see the "show mpls forwarding-table
196.44.74.254".
It's the oldest rule in IP networks - if A can't ping B then start by
seeing if B has a valid route to A.
Giles
> -----Original Message-----
> From: Giles Heron [mailto:giles@packetexchange.net]
> Sent: Thursday, June 06, 2002 5:19 PM
> To: Duane de Witt
> Cc: cisco-nsp@puck.nether.net
> Subject: RE: [nsp] MPLS TE
>
> what does a "show mpls forwarding-table 196.44.74.254" look like?
>
> the other possibility I suppose is that one of the two tunnels in the
> other direction is broken? Does it work with either one of the two
> tunnels disabled?
>
> Giles
>
> On Thu, 2002-06-06 at 13:21, Duane de Witt wrote:
> > >From 196.44.74.2 the packets take one path up to 196.44.74.254. To
> get
> > back they go through both tunnels which take different paths. I
don't
> > think it is an MTU problem because if I disable one tunnel and just
> run
> > with one path things work perfectly.
> >
> >
> > -----Original Message-----
> > From: Giles Heron [mailto:giles@packetexchange.net]
> > Sent: Thursday, June 06, 2002 2:24 PM
> > To: Duane de Witt
> > Cc: cisco-nsp@puck.nether.net
> > Subject: RE: [nsp] MPLS TE
> >
> > where is the ingress to the tunnels?
> >
> > you should be able to do "show mpls forwarding-table a.b.c.d" for
> that?
> >
> > (in other words in the core you should have 2 sets of tunnels - one
> > pointing to 196.44.74.2 and one pointing to the other end).
> >
> > Giles
> >
> > On Thu, 2002-06-06 at 09:49, Duane de Witt wrote:
> > > Thanks
> > >
> > > Does this confirm that there are reverse paths?
> > >
> > > RBA_Core#show mpls forwarding-table 196.44.74.2
> > > Local Outgoing Prefix Bytes tag Outgoing Next
Hop
> >
> > > tag tag or VC or Tunnel Id switched interface
> >
> > > 23 Untagged[T] 196.44.74.2/32 4483970449 Tu100
> point2point
> >
> > > Untagged[T] 196.44.74.2/32 1910687302 Tu101
> point2point
> >
> > >
> > > [T] Forwarding through a TSP tunnel.
> > > View additional tagging info with the 'detail' option
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Giles Heron [mailto:giles@packetexchange.net]
> > > Sent: Thursday, June 06, 2002 12:31 PM
> > > To: Matt Ryan
> > > Cc: Duane de Witt; 'cisco-nsp@puck.nether.net'
> > > Subject: RE: [nsp] MPLS TE
> > >
> > > the other possibility is broken forwarding in the LSP from the
> > > destination back to the source.
> > >
> > > "normal" traffic may be able to pop out of the tunnel and then be
> > routed
> > > hop-by-hop, whilst VPN traffic of course will be discarded as the
> > > destination IPs are unknown at the core LSRs.
> > >
> > > I have seen this in the past with TDP LSPs.
> > >
> > > In fact the first thing to check is that there are LSPs in the
> reverse
> > > direction ;-)
> > >
> > > Giles
> > >
> > > On Thu, 2002-06-06 at 08:40, Matt Ryan wrote:
> > > > MTU issue as the label stack grows?
> > > >
> > > >
> > > > Matt.
> > > > -----Original Message-----
> > > > From: Duane de Witt [mailto:duane@uis.co.za]
> > > > Sent: 06 June 2002 08:24
> > > > To: 'cisco-nsp@puck.nether.net'
> > > > Subject: [nsp] MPLS TE
> > > >
> > > >
> > > > Hi Everyone
> > > >
> > > > Has anyone come across a problem where when using multiple paths
> to
> > a
> > > > destination with TE any traffic within a VRF doesn't get any
> return
> > > packets?
> > > >
> > > > I have two TE tunnels going from one router to another using
> > different
> > > > paths. Any normal traffic works fine, but as soon as I put the
> > traffic
> > > in a
> > > > VRF I can see the icmp packets hit the destination and I can see
> the
> > > return
> > > > packets been sent, but they never reach the source router.
> > > >
> > > > Thanks
> > > >
> > > >
> > > > Regards
> > > >
> > > > Duane de Witt
> > > > Siemens Business Services
> > > > Tel. +27 11 652 7613
> > > > Fax. +27 11 652 2018
> > > >
> > > >
> > > >
> > >
> >
>
------------------------------------------------------------------------
> > > ------
> > > > Live Life in Broadband
> > > > www.telewest.co.uk
> > > >
> > > >
> > > > The information transmitted is intended only for the person or
> > entity
> > > to which it is addressed and may contain confidential and/or
> > privileged
> > > material.
> > > > Statements and opinions expressed in this e-mail may not
represent
> > > those of the company. Any review, retransmission, dissemination or
> > other
> > > use of, or taking of any action in reliance upon, this information
> by
> > > persons or entities other than the intended recipient is
prohibited.
> > If
> > > you received this in error, please contact the sender immediately
> and
> > > delete the material from any computer.
> > > >
> > > >
> > > >
> > >
> >
>
========================================================================
> > > ======
> > > --
> > > =================================================================
> > > Giles Heron Principal Network Architect PacketExchange Ltd.
> > > ph: +44 7880 506185 "if you build it they will yawn"
> > > =================================================================
> > >
> > >
> > --
> > =================================================================
> > Giles Heron Principal Network Architect PacketExchange Ltd.
> > ph: +44 7880 506185 "if you build it they will yawn"
> > =================================================================
> >
> >
> --
> =================================================================
> Giles Heron Principal Network Architect PacketExchange Ltd.
> ph: +44 7880 506185 "if you build it they will yawn"
> =================================================================
>
>
-- ================================================================= Giles Heron Principal Network Architect PacketExchange Ltd. ph: +44 7880 506185 "if you build it they will yawn" =================================================================
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:46 EDT