[cisco-bba] L2TP tunnel switching not copying dscp bits betweensession L2TP tunnel switching not copying dscp bits betweensession headers

[Tony Redstone]

Thanks, Oli and Paul!  We'll try the qos-group trick but there's a
couple of hundred Mb/s in and out through the LNS <-> LTS path so I'm
a bit concerned about the cpu expense in doing this.  We're running
12.2(28)SB3.

"However, it still has to be determined whether it should be necessary
to make the changes below or whether the TOS relfect feature needs to
be corrected for the C7X00 platforms."

FWIW, my vote would definitely be to have an additional configuration
option to allow LTS ToS reflection.  In the field, LTS often occurs
between different SPs so maintaining the current behaviour of
resetting the ToS would seem sensible and then have an extension to
the existing command to explicitly enable LTS ToS reflection.   The
qos-group trick seems like a very expensive way of achieving something
which no doubt could be done very cheaply if implemented in the most
appropriate place.

Many thanks again.

Regards,
Tony

On 8/15/06, Oliver Boehmer (oboehmer) <oboehmer at cisco.com> wrote:
> Tony Redstone <> wrote on Tuesday, August 15, 2006 5:14 PM:
> > We're terminating ppp users on the LNS and using "QoS: Per-Session
> > Shaping and Queuing on LNS" and "ip tos reflect" under the vpdn-group
> > to copy the end user payload dscp bits into the encapsulating L2TP
> > header.  This works fine.
> >
> > When L2TP traffic is tunnel switched through a cisco 7301 (LTS) the
> > dscp bits are reset in the outgoing L2TP session headers on egress
> > from the LTS.  This means we can't apply appropriate congestion
> > management either directly on egress from the LTS or further upstream.
> > [..]
> > Any suggestions as to how we can preserve the ToS byte during L2TP
> > tunnel switching?
>
> you could try to mark the pkts with a qos-group on ingress (i.e.
> match-all on the l2tp traffic and the dscp's) and then set the dscp on
> egress depending on the qos-group of the packet. Cumbersome, but I can't
> think of any other workaround right now..
>
>         oli
>