On Wed, May 22, 2002 at 03:29:00PM -0500, Sean Crocker wrote:
> >1. Using the "tunnel destination" command, and then "autoroute announce"
> >to inform the routing process of the tunnel's existence. In the figure,
> >assume that I have a tunnel between R1 and R3. Then, if I set the tunnel
> >destination to be R3, all traffic between R1 and R3 would use this tunnel,
> >right? (assuming that the tunnel metric is the shortest path between R1
> >and R3).
>
> Yes
>
> >Also, can I set the tunnel destination to an IP address other than R3? For
> >instance can I set the tunnel destination to C2, and would this have the
> >effect of sending all traffic between R1 and C2 via the tunnel?
>
> Sure, you can set the destination to something else, but I
> think you're misunderstanding what "tunnel destination" does.
> It specifies the TE egress LER, not the FEC.
Right; just to clarify, the TE tunnel destination address must be a TE
RID; if you set the destination address to C2, the tunnel won't come up.
>
> >2. Setting static routes to use the tunnel interface. e.g. "ip route
> ><dest_addr> <mask> tunnel 10"
>
> That's one way but may not be optimal. Setting a relative or
> absolute metric on the LSP, then configuring "autoroute
> announce" as you mentioned above is a more standard way.
>
> >Is there any other technique that allows one to have more control over the
> >traffic that can be mapped into an MPLS tunnel? (Say by specifying an
> >access list to map the traffic, or by using other IP header fields etc.?)
>
> Sure, policy based routing. You match packets based on
> criteria you define, then you "shunt" the matched packets
> across the LSP (out the Tunnel interface).
you can also do forwarding-adjacency if you run ISIS; very similar to
autoroute, though, and doesn't really solve any additional problems.
eric
>
> Sean
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:45 EDT