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
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)
Since it seems to be ipv6 month here at NZNog I thought I would bring this up.
Some of you have commented that Orcon is in trial mode for IPv6 and are probably wondering why we haven’t progressed.
We have had IPV6 enabled for a while and have a good number of ipv6 customers online now. However we found an issue on the Chorus network which stopped us rolling it out further. (UFB ipv6 was another battle which requires beer!)
What we found was some Chrous DSLAMS with certain card types would drop IPV6CP packets in one direction when doing the PPPoE->PPPoA conversation. It would seem that these cards don’t support Ipv6. Weirdly enough it would seem it is the newer card types used for Broadband IP. (citation needed). This in itself isn’t a major but we also found our NFV4 modem would reset its entire PPPoE stack if the IPV6CP conversation started but didn’t complete as expected, so customers would constantly be disconnected and cycle around. (The Genius modem works well with ipv6)
The NFV4 issue aside (we are resolving with the Vendor). We approached the Chorus tech team and they helped identify the issue but that’s is where its hit a brick wall. The Chorus op team are not keen on fixing the issue nationwide as it involves new code versions, a massive amount of testing and a long rollout program. (I can understand where they are coming from).
To summarise:
IPV6 doesn’t work on Chorus EUBA on some line card types
Only affect PPPoE->PPPoA translation
PPPoE end to end is fine.
Chorus say IPV6 not supported on EUBA
Customer numbers effected are smallish.
We will fix the NFV4 issue, but keen to rollout more IPV6 to all customers, not just the lucky ones on card types which work.
Has any other ISP’s (the bigger ones especially) noticed this? As it will require some pressure to get some progress.
Cheers,
Simon Allard
Orcon/Callplus
[cid:image92256e.PNG@016ea4ce.48a80470]
Simon Allard // Senior Network Architect
D: 09 550 2790 M: 020 100 0790 F:
www.callplus.co.nz<http://www.callplus.co.nz> | www.slingshot.co.nz<http://www.slingshot.co.nz> | www.flip.co.nz<http://www.flip.co.nz> | www.orcon.net.nz<http://www.orcon.net.nz>
This message and any attachments contain privileged and confidential information. If you
are not the intended recipient of this message, you are hereby notified that any use,
dissemination, distribution or reproduction of this message is prohibited.
If you have received this message in error please notify the sender immediately via email
and then destroy this message and any attachments.
at the end of my talk someone asked me what routers I would recomend
to try this stuff on here, and I sort of dodged the question.
If you can come up with a list of routers available here (meet me
later?), I can tell you what I know about each chipset. (I have
evaluated dozens of these over the last year...)
In general ath9k based gear is currently best (entirely open wifi
driver), with nearly every manufacturer shipping stuff based on that.
I see there is a lot of ubnt here, and most of their older products
are well supported by openwrt.
There is some good work beginning on the latest round of chipsets, but
by and large the firmware for 802.11ac is closed....
And so on. I should also point out that there are plenty of other OSes
available, and that I'm opposed to a monoculture of any
hardware/software combination.
See:
https://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/
for more details.
--
Dave Täht
thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
Thanks!
Ill keep plodding away and get a draft to the list and yourself to attach.
---
Me: nz.linkedin.com/in/bmmurrah
Ph: +6427 375 7897
Email: bmurrah(a)icloud.com
PGP: https://keybase.io/airbridge
> On 26/02/2015, at 1:48 pm, Stephen Quayle <stephenwq(a)gmail.com> wrote:
>
> Hey,
> Bit of a nzlog list lurker, I'd just like to give some support for this idea you're proposing.
>
> Any further information about this act is greatly welcomed.
>
> I'm particularly curious on what might changes might typically be required to give notification of, and what might not.
> We've already seem some implications for research based set ups, and possibly some hint of the difficulty of certifying open source instead of vendor supplied solutions.
>
> An area of interest was what this means for universities and where they might fall into it, as that's a bit different to your average business, or your average telco, yet i believe they could fall under broad ISP or carrier terms for general users. Often their networks and resources can be fairly public and they can have research arms that might struggle with the same issues as REANNZ.
>
> Just like to say thanks for anything you can provide in terms of knowledge and interpretation to the community, even if it just starts discussion.
>
> Cheers,
> Stephen
<http://techliberty.org.nz/the-gcsbs-brake-on-innovation/>
Excerpt:
Trying to do the same in NZ, but govt's TICSA legislation makes
deploying SDN/NFV in backbone networks challenging
http://t.co/91MUpxfOnw
— Steve Cotter (@SteveCotter) February 22, 2015
[...]
So this is a statement by the CEO of a government owned company
whose purpose is to "establish and operate the Advanced Network in
order to promote education, research and innovation for the benefit
of New Zealand" saying that they can't do the research and
development work they need to do because the bureaucrats in the NCSC
at the GCSB are holding them back.
--
Michael
Hi NZNOG Community,
APNIC’s regional training program is designed to grow the skills of
network operators to effectively deploy and manage network technology in
the Asia Pacific.
APNIC is currently assessing the training needs and requirements of the
Asia Pacific Internet community to help plan and improve its training
program so it can meet the community's future requirements.
You can help us by taking part in the Training Survey below:
https://www.apnic.net/trainingsurvey
As an added incentive, anyone completing the survey before 7 March 2015
will be entered into a prize draw for an iPad Air 2. There will be a
further draw for another iPad Air 2 after the survey closes on 20 March
2015, so early birds have two chances to win!
All responses provided will remain confidential and will only be used by
APNIC for the purposes of planning its training and technical assistance
programs.
Thank you for helping APNIC improve its training services.
Kind regards,
_______________________________________________________________________
APNIC Secretariat secretariat(a)apnic.net
Asia Pacific Network Information Centre (APNIC) Tel: +61 7 3858 3100
PO Box 3646 South Brisbane, QLD 4101 Australia Fax: +61 7 3858 3199
6 Cordelia Street, South Brisbane, QLD http://www.apnic.net
_______________________________________________________________________
After getting carried away coding at the SDN workshop this week I've
gone and flashed an RB750 with the latest openwrt (chaos calmer), and
discovered that the package/dependency management lacks the finesse of
something like debian/ubuntu:
root@OpenWrt:~# opkg install openvswitch
Installing openvswitch
(2.3.1-0dfed4ba9c8a16a1f316d709b7831a4e139472d4) to root...
Downloading http://downloads.openwrt.org/snapshots/trunk/ar71xx/mikrotik/packages/packa….
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies
for openvswitch:
* kmod-udptunnel4 * kmod-udptunnel6 *
* opkg_install_cmd: Cannot install package openvswitch.
digging deeper, it appears that kmod-udptunnel is built for
ar71xx/nand (https://downloads.openwrt.org/snapshots/trunk/ar71xx/nand/packages/base/)
but not for the mikrotik fork
(https://downloads.openwrt.org/snapshots/trunk/ar71xx/mikrotik/packages/base/)
questions:
- has anyone got this running? im going to build kmod-udptunnel from
source and then opkg install openvswitch, but was hoping i wouldn't
have to
- does anyone have a preference for ar71xx-mikrotik over ar71xx-nand?
i know Dean has deployed ovs from source on older mikrotiks running
attitude adjustment, who else is playing in this space?
cheers
sam
Morning all,
Wondering if anyone else is noticing that the ird website is taking quite some time to load, has been happening since late last week or earlier this week judging from reports.
Tested from our network and also on 4G from Spark, same issue.
Looking at a debug of the page, we get a 301 after 25 seconds, then we get a 24 second delay for a 200 OK then things start loading a bit later out of a cache from the looks.
If anyone that looks after the IRD infrastructure is on the list, feel free to reply offlist.
Many thanks
--
Kind regards,
Barry Murphy / Chief Operating Officer
Hello all,
I'm working for a small web/mail hosting company.
I've recently noticed a lot of blacklisted IP addresses from NZ based ISPs being dished out, part of our intrusion prevention methods involve denying connections from these addresses.
How do these blacklisted IP addresses get unlisted? Is it the responsibility of the customers of these ISPs or it is the responsibility of the ISP?
Daniel Christie
