Pretty sure you can just get Chorus to turn the DEI option off now.

Cheers
Dave

On Thu, Aug 20, 2015 at 2:25 PM, Mike Taylor <mtaylor@totalteam.co.nz> wrote:
Apologies for the BUMP so long after this is all done, but,

Does anyone have a working config for re-marking DEI=0, incoming, on a
Cisco ME3660, with service-instances, running IOS 15.3
(me360x-universalk9-mz.153) ?

(and as I write this, I'm thinking that I might have to upgrade  to 15.4
to get the 'set dei 0' command inside a service policy...)

Any help at all would be appreciated, My Lab-fu is failing hard today :-)

Mike
--

On 08/10/14 20:11, NGW Network Operations Centre wrote:
> I can confirm with working with Brent and the Chorus team that yes
> this is related to what Dylan is referring to.
>
> In particular we tracked our issue down to some Cisco switching gear
> and found:
>
> The Layer 2 packet header with CFI / DFI bit set to 0 indicates a
> standard Ethernet frame and passes to other Ethernet ports without
> issue. As soon as this is set to 1 then the packets get dropped when
> forwarding to an Ethernet port which is set as an access port. This is
> due to the switches thinking CFI bit 1 being set is a Token Ring frame
> which does not confirm to Ethernet MAC standards.
>
> On ME 3600x and 3800x switches you can rewrite the DEI bit with some
> policy maps from 1 to 0 and it should happily pass this along. Link
> for those interested:
> http://www.cisco.com/c/en/us/td/docs/switches/metro/me3600x_3800x/software/release/15-1_2_ey/configuration/guide/3800x3600xscg/swqos.pdf
>
> The above is also likely to be subject to IOS running so you may need
> to do some further checking or late night upgrades.
>
> As far as Juniper gear goes our transport network passed the traffic
> without issue through trunks and access ports to the Cisco's. Running
> 12.3 firmware.
>
> With the MX's it looks like at least 12.3 or higher supports also
> rewriting the DEI bit on ingress. Link for those interested:
> http://www.juniper.net/techpubs/en_US/junos12.3/topics/usage-guidelines/cos-applying-ieee-802-1p-rewrite-rules-to-dual-vlan-tags.html
>
> I also believe version 14 (which is not JTAC recommended) supports DEI
> bit rewrite on any of the EX equipment also.
>
> Anyway hopefully the above may help anyone out there experiencing
> issue with this.
>
>
>
>
> On 8/10/2014 5:35 p.m., Dylan Hall wrote:
>> While tinkering with CityLink we hit the same issue. Anything above
>> 2.5Mbps was marked discard eligible and was being discarded by CPE
>> Cisco switches (ME3400).
>>
>> We figured out this is because in the old days the discard eligible
>> bit used to mean "this packet has originated on a token ring network,
>> the byte order of the mac addresses is different". The Cisco was
>> happy to forward the frames across trunks, but would drop the packets
>> on access ports on the assumption the workstation connected wouldn't
>> know how to understand the mac addresses. This was on IOS 12.2.50ish.
>>
>> I don't recall the details, but a change was made by Chorus that
>> resolved the issue. Pete - do you recall the details?
>>
>> Thanks,
>>
>> Dylan
>>
>>
>>
>>
>> On 8 October 2014 16:46, Brent Marquis <Brent.Marquis@chorus.co.nz
>> <mailto:Brent.Marquis@chorus.co.nz>> wrote:
>>
>>     Result!
>>
>>     Having been inundated with replies yesterday (which was great!)
>>     we’ve narrowed this issue down to a probable cause…
>>
>>
>>
>>     The new Chorus ‘Accelerate’ plans use Two Rate Three Colour
>>     marking on the low priority part of the service, which includes a
>>     low priority CIR of 2.5mbps.
>>
>>     The EIR above this, up to the low priority plan speed (i.e
>>     100mbps, 200mbps, 1gig, etc), is marked as discard eligible with
>>     the VLAN header DEI(CFI) bit.
>>
>>
>>
>>     Collaborative debug/information sharing with Chorus, Fastcom,
>>     Callplus, Inspire and DTS has shown that Chorus is, in fact,
>>     forwarding all traffic from our handover as expected, but traffic
>>     marked with DEI=1 is lost/discarded in RSP networks.
>>
>>     The affected RSPs are discussing this with equipment vendors to
>>     find solutions or workarounds. I’m not keen to name names, as
>>     it’s the RSPs equipment, but if anyone has experience with DEI
>>     marking causing issues on various switches, I’m sure help would
>>     be appreciated.
>>
>>
>>
>>     In parallel, we are looking at disabling DEI marking, but being
>>     that this was an integral part of the new plans, I need to engage
>>     a few people around chorus to find a way forward here.
>>     Considering some RSPs are consuming DEI=1 without issue, we don’t
>>     want to break things that they may be doing.  Not to mention this
>>     would be a change to a lot of our QoS policies, so need some
>>     sanity testing and deployment to production, etc.
>>
>>
>>
>>     Thanks to the RSPs involved, although I suspect we all have some
>>     work to do to get clear of this issue completely…
>>
>>
>>
>>     Thanks,
>>
>>     Brent
>>
>>
>>
>>     Brent Marquis *|* Layer 2 Network Specialist
>>
>>      Chorus *|* *T : *+6448964169 <tel:%2B6448964169> *| **M
>>     :*+64272290923 <tel:%2B64272290923>
>>
>>
>>
>>     *From:*nznog-bounces@list.waikato.ac.nz
>>     <mailto:nznog-bounces@list.waikato.ac.nz>
>>     [mailto:nznog-bounces@list.waikato.ac.nz
>>     <mailto:nznog-bounces@list.waikato.ac.nz>] *On Behalf Of *Brent
>>     Marquis
>>     *Sent:* Tuesday, 7 October 2014 3:38 p.m.
>>     *To:* noc@ngw.co.nz <mailto:noc@ngw.co.nz>;
>>     nznog@list.waikato.ac.nz <mailto:nznog@list.waikato.ac.nz>
>>
>>
>>     *Subject:* Re: [nznog] UFB Upload Issues
>>
>>
>>
>>     I’ve only heard about it recently.
>>
>>     I’m investigating at the moment – instead of me running back via
>>     account managers to track down technical peoples details, can
>>     RSPs experiencing this email me please?  Particularly if you have
>>     some kind of test connection where you can push some traffic
>>     through while I debug at our end.
>>
>>
>>
>>     I have some theories, but I’m double checking all our
>>     configuration at the moment to rule that out definitively.  I
>>     certainly can’t replicate it in our lab.
>>
>>
>>
>>     Thanks,
>>
>>     Brent
>>
>>
>>
>>     Brent Marquis *|* Layer 2 Network Specialist
>>
>>      Chorus *|* *T : *+6448964169 <tel:%2B6448964169> *| **M
>>     :*+64272290923 <tel:%2B64272290923>
>>
>>
>>
>>     *From:*nznog-bounces@list.waikato.ac.nz
>>     <mailto:nznog-bounces@list.waikato.ac.nz>
>>     [mailto:nznog-bounces@list.waikato.ac.nz] *On Behalf Of
>>     *"NOC@NGWnoc"@ngw.co.nz <mailto:%22NOC@NGWnoc%22@ngw.co.nz>
>>     *Sent:* Tuesday, 7 October 2014 2:43 p.m.
>>     *To:* nznog@list.waikato.ac.nz <mailto:nznog@list.waikato.ac.nz>
>>     *Subject:* Re: [nznog] UFB Upload Issues
>>
>>
>>
>>     Yes, we have the same issues but also on the 100/50 plans, not
>>     just limited to auckland pops, it's with Chorus, but they are
>>     scratching heads still, ETA to be confrimed, so far we have been
>>     waiting over 5 weeks for a answer.
>>
>>     -- NOC @ Next Generation Wholesale - ngw.co.nz <http://ngw.co.nz>
>>
>>     On 7/10/2014 2:36 p.m., Dave Mill wrote:
>>
>>         Hi all
>>
>>
>>
>>         If any RSPs currently have any reports of 100/20 UFB Right
>>         Performing customers having only 2M upload could you contact
>>         me offlist? If you do contact me I'm really interested in
>>         where your BNG is and where your customers are with the issue.
>>
>>
>>
>>         If any end users are on 100/20 with only 2M upload also feel
>>         free to contact me. I'm more interested in your location and
>>         your ISP in this case.
>>
>>
>>
>>         Cheers
>>
>>         Dave
>>
>>
>>
>>         (representing Inspire Net in this post)
>>
>>
>>
>>         _______________________________________________
>>
>>         NZNOG mailing list
>>
>>         NZNOG@list.waikato.ac.nz <mailto:NZNOG@list.waikato.ac.nz>
>>
>>         http://list.waikato.ac.nz/mailman/listinfo/nznog
>>
>>
>>
>>     This communication, including any attachments, is confidential
>>     and may be legally privileged. If you are not the intended
>>     recipient, you should not read it - please contact me
>>     immediately, destroy it, and do not copy or use any part of this
>>     communication or disclose anything about it. Thank you. No
>>     confidentiality or privilege is waived or lost by any
>>     mis-transmission or error. Please note that this communication
>>     does not designate an information system for the purposes of the
>>     Electronic Transactions Act 2002.
>>
>>
>>
>>
>>
>>     _______________________________________________
>>     NZNOG mailing list
>>     NZNOG@list.waikato.ac.nz <mailto:NZNOG@list.waikato.ac.nz>
>>     http://list.waikato.ac.nz/mailman/listinfo/nznog
>>
>>
>>
>>
>> _______________________________________________
>> NZNOG mailing list
>> NZNOG@list.waikato.ac.nz
>> http://list.waikato.ac.nz/mailman/listinfo/nznog
>
>
>
> _______________________________________________
> NZNOG mailing list
> NZNOG@list.waikato.ac.nz
> http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog