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.
-----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" =================================================================
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:46 EDT