Hi Steve,
Thanks for that, yes it does appear to be all untagged (and non-IP) frames
which get assigned ‘unwanted’ EXP values. This seems to occur despite the
trust/untrust/mutate state of the xconnect interface.
There is no control over the downstream traffic, the xconnect is to encapsulate
a
IIRC the EXP values for non-IP traffic are mapped directly from the .1p COS
values. Depending on your flavor of STP this field may not even exist, in
which case I suspect it is being treated as COS0. Is it possible to have
the downstream device push a .1q tag?
Cheers,
Steve
On Fri, Feb 9, 2018 at
Hi all,
Is anyone aware of a feature which allows the EXP value on an STP frame to be
set when it is encapsulated by a xconnect on a 6500?
Example config:
int gi1/1
description Customer Port
xconnect 1.2.3.4 666 encapsulation mpls
service-policy input set-exp-3
policy-map set-exp-3
clas
> Marco Marzetti
> Sent: Friday, February 09, 2018 10:34 AM
>
> Hello,
>
> It's been a few weeks I've been working on EVPNs and IOS-XR 6.1 and i
> wonder if ther's a way to couple AC and PW status so that you can
propagate
> PE-CE link failures end-to-end.
>
> I know it's supported for "regular"
I will be using ASRs, route based VPNs with VTIs.
Mike
On Thu, Feb 8, 2018 at 6:13 PM, Jeff Orr wrote:
> We use HA VPN (HSRP) for our IPSEC based business partners. It has worked
> well for years, but I’m only partly happy.
>
> We have built our data centers to be as independent as possibly. M
Hello,
It's been a few weeks I've been working on EVPNs and IOS-XR 6.1 and i
wonder if ther's a way to couple AC and PW status so that you can
propagate PE-CE link failures end-to-end.
I know it's supported for "regular" EVPNs (RFC7432), but EVPN-VPWS
(RFC8214) is definitely a special case.
Here
