October 2014 - NZNOG - lists.nznog.org

Is there anyone on the list using mikrotik hardware to receive UFB Handovers from Chorus?
by Alexander Neilson 10 Oct '14

10 Oct '14

Hey Everyone We have just stood up our first Chorus UFB Handovers in Auckland and Wellington and while the Mikrotik’s are showing the interfaces as running Chorus are telling me their end is “operationally down”. I have tried changing all the settings I have on my end and they are still reporting the same result. I have tried alternative optics, checked light levels with a meter, and even had a Chorus tech out to take a look. Chorus originally pointed to the SFP+ being the issue, now they are saying the config is wrong on my device and that they aren’t “seeing layer two”. I have asked them for any errors on the port or similar and they haven’t reported any to me. I am a little stumped here and would appreciate the advice of anyone doing either 1G or 10G HO Links for UFB with Chorus who could provide any input or any idea of issues they have seen with the configs that would help me diagnose this issue and resolve it. Thank you for your time. Regards Alexander Alexander Neilson Neilson Productions Limited alexander(a)neilson.net.nz 021 329 681 022 456 2326

5 7

Re: [nznog] UFB Upload Issues
by Peter Ensor 09 Oct '14

09 Oct '14

The change in the CFI to DEI occurred between the 802.1q 2005 and the 2011 versions. In 802.1q 2005 section 9.6 Octet 1 bit 5 was defined for use as CFI (Canonical Format Indicator) whereas in the 2011 version of the standard (also shown in section 9.6), this bit has been redefined as the DEI (Discard Eligible Indicator) bit. The diagram is for a single .Q tag but I assume it also applies to additional tags. Cheers, Peter. > From: Nathan Ward [mailto:nznog(a)daork.net] > Sent: Thursday, 9 October 2014 1:26 p.m. > To: Brent Marquis; Dave Mill; Don Stokes > Cc: nznog(a)list.waikato.ac.nz > Subject: Re: [nznog] UFB Upload Issues > > > On 9 October 2014 at 1:09:42 pm, Brent Marquis > (brent.marquis(a)chorus.co.nz(mailto:brent.marquis(a)chorus.co > .nz))<mailto:brent.marquis(a)chorus.co.nz(mailto:brent.marqu > is(a)chorus.co.nz))> wrote: > > > Sorry for the quick reply to myself! > > > > It actually seems like Don might not be 100% correct. > > > > I don?t have IEEE access to get the .1q standard? But > Wikipedia suggests it has been updated in 2005 for CFI to > be DEI: > > > http://en.wikipedia.org/wiki/IEEE_802.1ad > > > > Drop eligible indicator (DEI): a 1-bit field. (formerly > CFI[note > 1](http://en.wikipedia.org/wiki/IEEE_802.1Q#cite_note-2)[2 > ](http://en.wikipedia.org/wiki/IEEE_802.1Q#cite_note-3)) > May be used separately or in conjunction with PCP to > indicate frames eligible to be dropped in the presence of > congestion.[3](http://en.wikipedia.org/wiki/IEEE_802.1Q#ci > te_note-4) > > > With the note suggesting ? ?IEEE 802.1Q-2005 clause 9.6? > > > > If it?s on Wikipedia, it must be true?. Right? J > > The quote above is from the 802.1q page. If you read the > page you link to, the 802.1ad page, you get: > > In IEEE 802.1ad the CFI is replaced by a Drop Eligibility > Indicator (DEI), increasing the functionality of the PCP > field. > > Key bit is ?802.1ad?, not 802.1q. Using 0x88a8 vs > 0x8100/0x9100 is signalling that you?re using 802.1ad vs. > stacked 802.1q, so should set this bit appropriate to the > tag type. I?m with Don on this one - the frame type bits > signal how to interpret the following bits, you can?t just > swap them around. > > People should really just use 0x88a8 - those who aren?t, > can I ask why not? Is it because you?re trying to tunnel > it over a switch that doesn?t support 802.1ad or > something? I?m not saying it?s wrong, I?m interested in > understanding the situations in which you might do this. > > -- > Nathan Ward > 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. > >

3 2

Taking down `rpki-validator.lab.hotplate.co.nz' for a bit
by Michael Fincham 08 Oct '14

08 Oct '14

Hi all, I've noticed a few NZNOGish looking addresses hitting this service periodically, even though an automated upgrade to the rpki-ca package broke the database updates some months ago :) Thanks for checking it out, folks who did, and I hope you found it useful! Just a quick note to let everyone know I'm taking the validator app down for a bit until I have time to fix it and find it a new home (I'm currently paying for a whole VM for it to live on which seems a little unnecessary given it's partially broken). In the mean time, BGPmon has a (much more comprehensive) service you can query via WHOIS: <http://www.bgpmon.net/securing-bgp-routing-with-rpki-and-roas/> -- Michael

2 1

Re: [nznog] UFB Upload Issues (Ewen McNeill)
by Peter Ensor 08 Oct '14

08 Oct '14

Just for clarification, a 802.1ad (TPID = 88a8) does not need to have both a SVLAN and CVLAN. It is allowed to only be a single VLAN tag. This will occur when a an untagged packet ingresses a BS3/3a/4 type service at the UNI (Upstream frame). This frame will be wrapped with a SVLAN but because it did not contain any original CVLAN tag, there will not be any CVLAN tag in the packet that egresses the UFB Handover connection. My reading is that on a 802.1ad interface. the TPID = 88a8 indicates that it is a SVLAN whereas a TPID = 8100 would indicate that it is CVLAN or QinQ. Since both TPID's now use the DEI bit (since the 2011 standard) I'm not sure how else the two frames would be different. Cheers, Peter. Hi Brent, On 9/10/14 16:03, Brent Marquis wrote: > It just gets slightly more confusing. [...] > Which would mean your interpretation is that CFI on 802.1q only applies > if there is also an 88a8 802.1ad tag preceding it. Based on looking at the 802.1Q-2005 specification and 802.1ad-2005 specification that Nathan linked to, it seems to me that the intent of both 802.1Q-2005 and 802.1ad-2005 was that ethertype=0x8100 would mean "interpret the header as a 802.1Q VLAN Tag/802.1ad CVLAN Tag", both of which have the same bit pattern, and semantics -- including a CFI bit rather than a DEI bit. This is section 9.6 in both specifications (which makes sense since 802.1ad was based on 802.1Q). By contrast, in 802.1ad there is a SVLAN tag, with a separate ethertype (0x88a8), which is the same except that it has a DEI bit in the same bit position that 802.1Q/802.1ad has the CFI bit. This is section 9.7 in the 802.1ad specification. It seems to me that the intent was: if ethertype=0x8100 then bit is interpreted as CFI, else if ethertype=0x88a8 then bit is interpreted as DEI. Which gives an unambiguous interpretation, without needing any context (much easier for an ASCI implementation). So I'm pleased IEEE seem to have thought of this problem in advance and tried to avoid ambiguity. However, setting DEI on an 802.1ad frame with ethertype 0x88a8, then changing the ethertype of the outer tag to 0x8100 ("for compatibility" :-) ) seems to either (a) require force-clearing that bit to avoid confusion, or (b) lead to a potential for misinterpretation that causes traffic to be discarded. > IMO, our interface is .1ad and we dont believe being nice and tweaking > the ethertype at RSP request changes that :) but let me see what I can > find out from our Vendor. FWIW, it appears to me that sending two 0x8100 tags stacked is not 802.1ad, but some "pre-standard" double tagging. Even if the frames started out 802.1ad compliant. 802.1ad seems to require a SVLAN tag (0x88a8) around a CVLAN tag (0x8100). Although it appears the difference mostly only matters for the interpretation of this one bit (DEI or CFI). If Chorus is going to offer 0x8100-double-tagging (ie, two 0x8100 tags stacked, pre-802.1ad Q-in-Q) it seems like it'd maximise compatibility if you were able to clear bit 5 (CFI on 0x8100/DEI on 0x88a8) of the tag in that specific case (ie, two stacked 0x8100 tags). Ewen PS: For reference, Nathan's links: http://www.stephan-robert.ch/attachments/File/TIN08/802-1Q-2005.pdf https://github.com/yhaz/homeenv/blob/master/specs/802.1ad-2005.pdf beware the 802.1ad one is a revision 4 draft (they went to revision 6 before the release AFAICT: http://www.ieee802.org/1/pages/802.1ad.html); if you want to argue with vendors it might pay to get the official standard from IEEE directly.

2 1

APRICOT 2015 Programme Committee - call for volunteers
by Dean Pemberton 08 Oct '14

08 Oct '14

Hi everyone, The APRICOT 2015 Programme Committee is responsible for the solicitation and selection of suitable presentation and tutorial content for the APRICOT 2015 conference (http://2015.apricot.net/). The APIA Board selects a new Programme Committee each year and is now seeking nominations from the community. As part of APIA's partnership with APNIC, the PC will be responsible for building the technical & operational content for both APRICOT in Fukuoka, Japan in February/March 2015 and the APNIC 40 Conference in September 2015. Eligible PC candidates are those who have attended APRICOT & APNIC conferences in the recent past, have broad technical knowledge of Internet operations, and have reasonable familiarity with the format of APRICOT & APNIC conferences. Having constructive opinions and ideas about how the programme content might be improved is of high value too. PC members are expected to work actively to solicit content for the two events and review submissions for technical merit. The PC meets by conference call, weekly in frequency during the three months prior to each event. If you are interested in joining the PC and meet the above eligibility criteria, please send a brief note to "apia-sec at apia.org". The note should include affiliation (if any) and contact details (including e-mail address), and a brief description of why you would make a good addition to the PC. PC members receive complimentary registration for the event they helped assemble the programme for. The APIA Board will accept nominations received by the end of Friday 24 October, 2014, and will announce the new PC shortly thereafter. Many thanks! Mark Tinka, Raphael Ho & Dean Pemberton (APRICOT 2015 PC Chairs)

1 0

Re: [nznog] UFB Upload Issues
by Brent Marquis 08 Oct '14

08 Oct '14

Hi Craig, Yes, I spotted that this morning, hence we need some document updates - my understanding (it's not my document) is that specific wording hung around from an old version of the document and it was intended to point out that we will not utilise DEI/colour marking from RSPs into our network. Thanks, Brent BrentMarquis Layer 2 Network Specialist T +6448964169 M +64272290923 E Brent.Marquis(a)chorus.co.nz -----Original Message----- From: Craig Whitmore [mailto:lennon(a)orcon.net.nz] Sent: Thursday, 9 October 2014 10:44 a.m. To: Brent Marquis; nznog(a)list.waikato.ac.nz Subject: RE: [nznog] UFB Upload Issues Maybe I'm a little confused but reading the TUG it says DEI is not used /aware? Page 48 of the Chorus NGA TUG it states... Canonical Format Indicator (CFI) or Discard Eligible Indicator (DEI) is set to 0. DEI applies to the 802.1ad outer tag and is not used, i.e. NGA is not colour-aware. ???? -----Original Message----- From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Brent Marquis Sent: Thursday, 9 October 2014 9:44 a.m. To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] UFB Upload Issues Thanks for pushing all that info back into the list. I know of 1 RSP which has Juniper equipment that seems to be discarding CFI/DEI=1. I guess some switches need a bit of config to recognise CFI as DEI or to re-write it entirely (luckily there haven't been any hardware issues yet) 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.

1 0

Call for Papers NZNOG 2015
by Richard Nelson 05 Oct '14

05 Oct '14

It turns out that June is much too early to issue the CFP for NZNOG next January. So here it is again. We are negotiating with some interesting international speakers but we rely on submissions from the local community to make the programme interesting. Remember there is a prize of a trip to Japan. Richard. -------- The NZNOG organising committee invites papers for its 13th annual conference, to be hosted at the Distinction Hotel, Rotorua, New Zealand from 26 - 30th January 2015. There will the three day Workshops 26 – 28 January, a day of tutorials on 28 January with the main conference on 29 – 30 January. The best local conference paper as judged by the trustees in association with the programme committee will win a trip to APRICOT 2015, to be held jointly with APAN 39 in Fukuoka, Japan, from February 24th to March 6th 2015. Umm that’s right, an all[1] expenses paid trip to JAPAN!!!! It's a real thing. Two people have won this in previous years and to be honest they seemed pretty happy with the prize. Conference objective: The NZNOG conference, workshops and tutorials are a once-a-year opportunity for individuals and organisations involved in Internet operations to meet and share the latest in Internet operations, technologies practices and receive high quality training. The event is unique in New Zealand and attracts technical, skilled individuals with a genuine interest in Internet operations and Internetworking technologies. Submit a paper: Presenters are invited to submit abstracts of their paper for consideration by Monday 20th October. Abstracts should be no more than one page long and provide a summary of your networking-related subject matter. Please note that full slide decks will be required by late November. To submit your paper please e-mail: talks(a)nznog.org When considering a presentation, remember that the NZNOG audience is mainly comprised of technical network operators and engineers with a wide range of experience levels from beginners to multi-year experience. There is a strong orientation to offer core skills and basic knowledge in SIGs and to address issues relevant to the day-to-day operations of ISPs and network operators in the conference sessions. Note: The inclusion of a title, bio, topic, abstract, and slides with proposals is not compulsory but will help us determine the quality of your proposal and increase the likelihood it will be accepted. The organising committee will evaluate proposals based on fit with the conference’s objective and its ability to stimulate lively discussions around the current state of New Zealand networking. The best local paper will be judged by a selection of the trustees and the programme committee. It will be expected the best paper is submitted by the winner for presentation at APRICOT. More details on paper submission can be found at http://www.nznog.org/call-for-papers For more information about the conference visit www.nznog.org or contact: talks(a)nznog.org [1] where 'all' means Return Flights, Accommodation and Conference Fees. You still need to pay for things like food and entertainment. Most of what you need to eat/drink is covered in the conference though. We're also open to cases of special needs should you win. --------

1 0