Hi all
We have finally fixed our 2M upload issues on Chorus UFB accelerate plans.
Skip to the end of this email if you just want an example fix.
Along the way we established a couple of incorrect "facts". Some of which I
shared with this list.
These were:
1) DEI marked packets were being silently dropped on ingress from the
Chorus handover
2) Junos 12.3 fixed this issue
Recently I deemed that "fact" 1) was wrong and hence "fact" 2) was a bit
irrelevant.
Here's a crude diagram of our typical set-up:
<Chorus handover> <-> [1] <MX80> [2] <-> MPLS/VPLS over Backhaul fibre <->
[3] <PMR MPLS MX> [4] <-> [5] <PMR BNG>
Where the numbers in the square brackets are interfaces where I performed
some traffic stats.
I deemed that DEI=1 marked packets were still showing up at [1] and [3].
They were not showing up at interfaces [4] and [5]. This deemed my above
"facts" incorrect.
With Juniper CoS you classify on ingress and rewrite on egress. Once we
deemed that DEI marked packets were not being dropped at [1] and instead
were being dropped between [3] and [4] we can now rewrite these before
interface [4]. As we need to rewrite on egress we'll do this at point [2].
In our test case interface [2] is actually xe-1/2/0.388 . And a simple fix
for the issue is under the class-of-service section implement:
interfaces {
xe-1/2/0 {
unit 388 {
rewrite-rules {
ieee-802.1ad {
ieee-802.1ad-dei-rewrite;
vlan-tag outer;
}
}
}
}
}
rewrite-rules {
ieee-802.1ad ieee-802.1ad-dei-rewrite {
forwarding-class best-effort {
loss-priority low code-point 0000;
loss-priority high code-point 0000;
}
}
}
The key is to use a ieee-802.1ad rewrite rule rather than a ieee-802.1
rule. The leftmost bit of the 4 bit code-point is the DEI bit. This is all
assuming that all traffic is classified as best-effort at interface [1] -
if that is not the case then re-write the DEI bit for your other queues as
well.
You only need to rewrite the outer vlan DEI bit.
This is tested on Junos 12.3R8.7 on a MX80.
Thanks to all involved in helping fix this - Steve K, Vance and Ivan
especially.
Cheers
Dave
We have just detected some more of the KFC delivery scam websites on our network. They’re starting to register a lot of domains! I’m getting in touch with the registrars now to get them taken down but may take some time as it’s outside business hours.
getkfcnow.co.nz
getkfcnow.com.au
ilovekfc.co.nz
kfcnow.co.nz
kfcnow.com.au
kfctime.co.nz
kfctohome.co.nz
timeforkfc.co.nz
Regards,
Cody Cooper | Head of Broadband
DDI: +64 (3) 928-2645, ext 9892
Mob: +64 (21) 666-505
Why not Go MAD today? Visit gomad.co.nz <http://gomad.co.nz/>
Asia Pacific Regional Internet Conference on Operational Technologies
(APRICOT)
15th February - 26th March 2016, Auckland, New Zealand
https://2016.apricot.net
CALL FOR PAPERS
===============
The APRICOT 2016 Programme Committee is now seeking contributions for
Presentations and Tutorials for APRICOT 2016.
We are looking for presenters who would:
- Offer a technical tutorial on an appropriate topic;
- Participate in the technical conference sessions as a speaker;
- Convene and chair panel sessions of relevant topics.
Please submit on-line at:
http://papers.apricot.net/user/login.php?event=34
CONFERENCE MILESTONES
---------------------
Call for Papers Opens: 2 November 2015
Draft Program Published: As Papers Confirmed
Final Deadline for Submissions: 25 January 2016
Final Program Published: 1 February 2016
Final Slides Received: 8 February 2016
**NOTE THAT REGARDLESS OF DEADLINESSLOTS ARE FILLED
ON A FIRST COME, FIRST SERVED BASIS***
PROGRAMME MATERIAL
------------------
The APRICOT Programme is organised in three parts, including
workshops, tutorials and the conference.
Topics for tutorials and the conference must be relevant to Internet
Operations and Technologies:
- IPv4 / IPv6 Routing and operations
- IPv6 deployment and transition technologies
- Internet backbone operations
- ISP and Carrier services
- IXPs and Peering
- Research on Internet Operations and Deployment
- Pacific/Oceania Internet
- Software Defined Networking / Network Function Virtualisaton
- Network security issues (NSP-SEC, DDoS, Anti-Spam, Anti-Malware)
- DNS / DNSSEC
- Internet policy (Security, Regulation, Content Management,
Addressing, etc)
- Access and Transport Technologies, including Cable/DSL, 3G/LTE,
wireless, metro ethernet, fibre, MPLS
- Content & Service Delivery (Multicast, Voice, Video, "telepresence",
Gaming) and Cloud Computing
CfP SUBMISSION
--------------
Draft slides for both tutorials and conference sessions MUST be
provided with CfP submissions otherwise the Programme Committee will
be unable to review the submission. For avoidance of doubt this means
that submissions which do not include slides will be rejected
immediately. For work in progress, the most current information
available at time of submission is acceptable.
All draft and complete slides must be submitted in PDF format
only.
Final slides are to be provided by the specified deadline for
publication on the APRICOT website.
Prospective presenters should note that the majority of speaking slots
will be filled well before the final submission deadline. The PC may,
at their discretion, retain a limited number of slots up to the final
submission deadline for presentations that are exceptionally timely,
important, or of critical operational importance. Every year we turn
away submissions, due to filling up all available program slots before
the deadline. Presenters should endeavour to get material into the
PC sooner rather than later
Please submit on-line at:
http://papers.apricot.net/user/login.php?event=34
Any questions or concerns should be addressed to the Programme
Committee by e-mail at:
pc-chairs at apricot.net
We look forward to receiving your presentation proposals.
Mike Jager & Dean Pemberton
Co-Chairs, APRICOT 2016 Programme Committee
Evening,
Anyone from 2talk on the list?
I can't get hold of anyone via the wholesale support number or the NOC
number I have on-hand.
Having some issues with inbound calls affecting a number of customers.
*Jesse Archer*
*General Manager*Full Flavour
*p. *07 577 0099 *ddi*. 07 281 1391
*s*. Skype "myfullflavour"
*e*. jesse(a)fullflavour.nz <jesse(a)fullflavourmedia.co.nz>
*w*. fullflavour.nz <http://www.fullflavourmedia.co.nz/>
*a. *Basestation, 148 Durham Street, Tauranga
*a*. PO Box 16306, Bethlehem 3176, New Zealand
Can someone from the above please contact me off list as some of our IP ranges are not working for NZ customers.
Kind regards,
Matthew Harrison
The Top Dog / Managing Director
[http://www.primowireless.co.nz/primo_office_move.jpg]<http://www.primowireless.co.nz/help/contact-us>
The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.
Dear networkers from around the world,
Internet interconnection is largely unregulated. However, in some countries, public regulation has emerged – be it through transparency rules, mandatory peering or licensing terms.
Currently, we lack an overview about where regulation exists and we know little about how it affects internet connectivity on a global scale.
To start filling this information gap, I have set up a short survey for network engineers, peering coordinators and network-savvy legal staffers. The goal is to crowdsource an initial overview about formal regulation of internet interconnection around the world.
Please participate! It takes no more than 10 minutes and will serve the community: http://limesurvey.hiig.de/index.php/675663?lang=en <http://limesurvey.hiig.de/index.php/675663?lang=en>
I will publish the results under a Creative Commons license.
Also, please consider helping by forwarding the link to fellow interconnection professionals - think of your Facebook, VKontakte or LinkedIn groups, of chat channels and mailing lists. The more regional diversity, the better. Thank you!
Thank you!
Kind regards,
Uta Meier-Hahn
PhD Candidate
Alexander von Humboldt Institute for Internet and Society
Oberwallstr. 9 | 10117 Berlin
meier-hahn(a)hiig.de <mailto:meier-hahn@hiig.de> | T +49 30 200 760-82 | www.hiig.de/en
Hi All,
The recent KFC incident has highlighted a lack of awareness of where
to effectively report online security issues. A point made worse by
New Zealand not having a CSIRT. At the NZITF we're working to create
New Zealand’s first public facing Computer Security Incident Response
Team (or CSIRT).
Essentially, we have decided it's time to stop talking about creating
a CSIRT and instead partner with like-minded companies to fund and
incubate a small, agile team to prove the value that a public-facing
CSIRT can bring to New Zealand.
We have produced a short 1-pager about why the NZITF are setting up
CSIRTnz and what we hope to achieve.
http://nzitf.org.nz/pdf/NZITF-CSIRT-ValProp.pdf
Feel free to get in touch (info(a)nzitf.org.nz) if you, or your
organisation wants to know more about the initiative.
In the mean time, while we get this all setup, any incidents sent to
info(a)nzitf.org.nz will receive attention, and we'll look to provide
co-ordination, albeit on a best efforts basis.
Regards,
Dean
Hi Folks,
Anyone know of NZ-based Global Gateway or Spark infrastructure that
responds to ICMP ping requests globally? On or off-list reply fine.
I've found hosts in AS4648 that respond to ping selectively - from some,
but not all of the servers I'm using to collect data for my project on
peering in the Pacific http://pacpeer.org/ Bizarre & frustrating things
going on with this network. Same for AS4771.
Failing that happy to take suggestions for Auckland based single-homed
customers on AS4648 or AS4771 that are fibre connected with 1-2ms latency
from provider core - and don't mind the occasional ping.
I've got Atlas probes I can ping, but they're on the end of consumer tails
& that mucks up the stats.
Thanks,
Jon
All,
You might’ve seen ‘kfcdelivery.co <http://kfcdelivery.co/>.nz’ pop up on social media today. It’s a scam.
If you have the ability to block this website so your users cannot reach it, please do so.
If you have stuck your CC details in there, cancel your card.
It is hosted through CloudFlare, don’t block the IPs, but perhaps you can filter on your DNS or something.
I have reached out to the registrar for the domain to get it blocked (discount domains). If anyone has a contact there other than support@ to get it pulled ASAP, please use it - I don’t know anyone there.
The logic of the site is roughly:
<snip>
# Validate input and set error if validation fails
if(error){
"You must fill in the red fields"
}else{
"Our servers are down due to heavy traffic, please try again later"
}
# send data to servers anyway
</snip>
--
Nathan Ward
Those of you that use the ISP survey from Stats NZ might like to know that the’ve reissued it, silently, following discovery of discrepancies between this release and previous releases for historical data. Basically they re-ran the random rounding for historical data and got different random values from before. This is now fixed and the latest spreadsheet is consistent with previous ones.
http://www.stats.govt.nz/~/media/Statistics/Browse%20for%20stats/ISPSurvey/…
Jay
--
Jay Daley
Chief Executive
NZRS Ltd
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley
