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.
Hi,
We want to perform some testing of consumer broadband connections over
the next three months. We are looking for somewhere to host a server
for throughput testing. Happy to pay. The main requirements are for a
neutral site well connected to all the major ISPs and for a network
connection to easily handle (i.e. not limit) throughput for consumer
speed connections - up to 200Mb/s (not gigatown).
The testing will be for about 5 mins worth of streams per hour from an
equal mix of ADSL, VDSL and UFB with tests staggered to occur one at a
time. Testing repeats every hour. We can lease or provide our own
server. If we get really lucky we'd like one site in Auckland and one
not in Auckland.
Any suggestions would be gratefully received.
Thanks,
Richard Nelson
WAND Network Research Group.
>From one of the .VU government coordinators:
We urgently need the following. Can anyone supply and where from. I can
assist with logistics from Auckland, Brisbane, Sydney. Please reply ASAP
Item Quantity Spec
USB RF Power Meter 1 Agilent U2041XA
Cable and Antenna Analyser 1 Sitemaster
PDR48 calibration kit 1 Sitemaster
Transmission Analyser 1 JDSU MTS-5800
Please contact me and I'll put you in touch if you can help
--
Andy Linton
Mobile: +64 22 474 7156
Skype: asjlnz
I understand as its generic firmware, I assume there will be many different compatible hardware options. The big thing though is the voip needs to be capable which may reduce your compatibility list.
The market in NZ has dramatically changed with computer stores selling less and less routers, and the home users just using the router issued free from their ISP.
And to make it work for an ISP in a fibre world, it needs to have a built in voip ATA
Software:
- WAN/LAN bridge mode
- uPNP
- IPv4 / IPv6
- Programmable 0.0.0.0/0 or gateway address when lan + wan in bridge mode
- voip must work when in bridge mode. Have had problems with zyxel and others having no gateway address breaking voip when in bridge mode
- router must be accessible from behind another nat gateway via a port forward. Enabling WAN admin access doesn’t always make this work with many routers
Hardware:
- Price point of $40-$50 so we can issue them free with service
- A higher priced, higher speed option would be good for fibre based services
- 3dbi antenna, 18db tx power
- 802.11n 2.4ghz option. We don’t see the need for ac for at least 3 years
There was recently a project between geekzone and telecom to build a "standard router for NZ" which was designed to be the perfect one with all the features that the GZ community wanted, could be issued for free by telecom and was capable of being used for DSL and fibre.
They got as far as taking bids for the project from companies like huawei and the likes.
Most of the features that the GZ community were proposing I found to be useless as an isp supplied router, but it would be worth looking at the feature list.
I think a bit of googling might be needed to get to the feature voting page in the forums - it may have been deleted.
Ray Taylor
Taylor Communications
ray(a)ruralkiwi.com
Ph 021-483-280
Network status 06-929-9082
-----Original Message-----
From: Dave Taht [mailto:dave.taht@gmail.com]
Sent: Tuesday, 10 March 2015 11:45 a.m.
To: Ray Taylor
Subject: Re: [nznog] openwrt capable routers for NZ?
always helpful to have that list. And have that list discussed publicly.
This is the only public talk I have given about wifi... see second half.
https://www.youtube.com/watch?v=Wksh2DPHCDI
On Mon, Mar 9, 2015 at 3:43 PM, Ray Taylor <ray(a)ruralkiwi.com> wrote:
> Im keen to take part
> Wouldn’t know anything about designing firmware other than the list of features that I need.
>
>
>
> Ray Taylor
> Taylor Communications
> ray(a)ruralkiwi.com
>
> Ph 021-483-280
> Network status 06-929-9082
>
>
>
> -----Original Message-----
> From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces@list.waikato.ac.nz] On Behalf Of Dave Taht
> Sent: Tuesday, 10 March 2015 11:14 a.m.
> To: Jed Laundry
> Cc: NZNOG(a)list.waikato.ac.nz
> Subject: Re: [nznog] openwrt capable routers for NZ?
>
> I see this thread has kind of died... I am looking for people willing to participate in the upcoming make-wifi-fast project. Along the way, we'll probably build a pretty good firmware for general use on some off-the-shelves piece of hardware, and it would be good to be able to test with your upcoming fiber deployment(s) as well as on the WISP sides of things.
>
> Please let me and jim gettys know if you are interested in helping out on this.
>
> --
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
>
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> NZNOG mailing list
> NZNOG(a)list.waikato.ac.nz
> http://list.waikato.ac.nz/mailman/listinfo/nznog
>
>
--
Dave Täht
Let's make wifi fast, less jittery and reliable again!
https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
We have 2x NanoStation M5's spare - let us know if you want them.
Bevan
On 17 March 2015 at 12:00, <nznog-request(a)list.waikato.ac.nz> wrote:
> Send NZNOG mailing list submissions to
> nznog(a)list.waikato.ac.nz
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.waikato.ac.nz/mailman/listinfo/nznog
> or, via email, send a message with subject or body 'help' to
> nznog-request(a)list.waikato.ac.nz
>
> You can reach the person managing the list at
> nznog-owner(a)list.waikato.ac.nz
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of NZNOG digest..."
>
>
> Today's Topics:
>
> 1. Ubiquiti gear for Vanuatu (Andy Linton)
> 2. Re: Ubiquiti gear for Vanuatu (Dean Pemberton)
> 3. Re: Ubiquiti gear for Vanuatu
> (Matthew Harrison - PrimoWireless Ltd)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 17 Mar 2015 11:53:20 +1300
> From: Andy Linton <asjl(a)nsrc.org>
> To: NZNOG List <nznog(a)list.waikato.ac.nz>
> Subject: [nznog] Ubiquiti gear for Vanuatu
> Message-ID:
> <CALS-_Orno8qXbJUY78nNPBcTig+v6=
> XkM5nzzmZOYPUneSHj4Q(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Here's what they're going to need.
> On Tue, Mar 17, 2015 at 11:01 AM, Jethro Webston wrote:
>
> > Hi Andy, thank you for your assistance. We use NanoBridge, NanoBeam, and
> > NanoStation M2 & M5.
> >
> > Cheers
> >
> >
> >
> Jethro
>
> We've had a number of offers already but if you have spares of these please
> record them at:
>
> http://aidez.vu
>
> Be specific with models and quantities if you can. Remember they will need
> power supplies and Ethernet cables as well. Fortunately .VU uses the same
> plugs as .NZ
> --
> Mail: asjl(a)nsrc.org
> Mobile: +64 22 474 7156
>
