Re: [uknof] removing old circuit equipment - VMB/BTO

[Brian Candler]

On 19/07/2024 12:00, uknof-requ...@lists.uknof.org.uk wrote:

For Virgin Media Business - the following address may help -
kit&networkrecov...@virginmedia.co.uk


Hmm... it complies with RFC2822 section 3.2.4, but I suspect it was 
chosen to minimise the likelihood of mail getting through.

Re: [uknof] tail aggregator

[Brian Candler]

On 19/04/2024 15:27, uknof-requ...@lists.uknof.org.uk wrote:

So lots of P2P links from customer sites to Telehouse, but backhauled
via a single fat pipe (hope that makes sense). Guess local tails
would be provided by another provider to local node.

Does this exist? Do OR etc have such a service?


I seem to remember reading that OR were making a version of the EAD 
service where they would present all the circuits as vlans on a trunk 
instead of separate ports on a chassis.




I think it was EAD 2.0:

https://www.ispreview.co.uk/index.php/2023/09/openreach-uk-preparing-to-launch-ethernet-access-direct-2-0.html

Re: [uknof] CGNAT Solutions

[Brian Candler]

On 07/07/2023 17:14, Paul Mansfield wrote:

I think the key part is educating consumers to stop buying  that
hasn't got a "IPv6 Compatible" label on it.


I disagree. I don't think you can blame consumers for:

- Many ISPs not providing IPv6

- Almost all content providers not serving over IPv6

And frankly, consumers don't care. They buy it, they plug it in, it 
works. That's all they want - and it's not them who are holding back the 
deployment of v6.

Re: [uknof] CGNAT Solutions

[Brian Candler]

On 07/07/2023 12:00, uknof-requ...@lists.uknof.org.uk wrote:

--- this is what I wrote ---

Here's a thought.
Industry leading bodies* should announce that from 2026 all internet
connections sold in the UK will be IPv6 only, and thus all CPEs must
support IPv6 on the WAN and the LAN side, with no IPv4 on either. ISPs
can then offer a DNS64/NAT64 service for customers, particularly
consumers, who can't implement their own solution.


Here's a brief but interesting read with some real-world testing of 
IPv6-mostly networks:


https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/

It's encouraging that some OSes have built-in CLATs, and hence will 
function with NAT64 even in the absence of DNS64. However, Windows and 
Linux lag behind macOS and iOS/Android in this area.


There's also lots of legacy IoT around. Try telling a customer that 
their home heating or lighting or security camera will no longer work on 
your Internet service, because "we only do IPv6".


Therefore I think you're stuck with dual-stack on the LAN side for some 
time yet, in conjunction with a CLAT on the CPE.  I don't see that it 
causes any harm though - and if over time it becomes less and less used, 
then that's fine too.


The bigger problem I see is the complete unwillingness of the majority 
of content providers to make their content accessible over v6, even 
though in some cases it's only a few clicks for them to do it.  They 
*could* do it, but they don't.


A certain well-known broadcasting organization comes to mind - one which 
has been regarded as a technical leader for the last 100 years.


Until that changes, CGN will continue to be heavily used (which is what 
started this thread).

Re: [uknof] Eurostar and tools

[Brian Candler]

On 11/04/2023 12:00, Tom Storey  wrote:

they dont seem to have a
concept of checked baggage which I would otherwise happily pay for.


They advertise that they do, for "selected trains between London and 
Paris", which has to be "booked via our Travel Services team" 
:


https://www.eurostar.com/uk-en/travel-info/travel-planning/luggage/luggage-services

The conditions of carriage say that restricted items (e.g. DIY tools) 
are "ALLOWED AS REGISTERED (HOLD) LUGGAGE ONLY WHERE THIS SERVICE IS 
AVAILABLE"


https://www.eurostar.com/uk-en/conditions-carriage

Re: [uknof] OOB connectivity in Pulsant Trafford Park (was M247, Ball Green)

[Brian Candler]

On 21/03/2023 12:00, uknof-requ...@lists.uknof.org.uk wrote:

Looking for a /30 or /31 of IPv4 that is accessible globally, statically
routed and with ~10Mbps CIR.


Why IPv4?  IPv6 is the global out-of-band management network :-)

Re: [uknof] MIkrotik RoS7 BGP Woes

[Brian Candler]

On 02/11/2022 07:35, uknof-requ...@lists.uknof.org.uk wrote:

I am probably not the only one with a love/hate relationship with Mikrotik, 
sometimes it amazes me what you can do, but has anyone else been unfortunate 
enough to deploy a Mikrotik RoS7 BGP Route Reflector network?

I have had an issue for nearly a year now with stale BGP routes stuck in a loop 
between two route reflectors and can only over ride them with static routes 
which defeats the object of using routing protocols.

I get the usual arrogant response from Mikrotik, with no time lines. If only I 
had the budget to replace it with a different vendor.

This is small ISP network and I am seriously considering changing over to OSPF 
only in the core network - just makes route manipulation a little trickier.


Running on 6.48 and 6.49 here (without route reflectors).  This has its 
own issues though, in particular that IPv6 doesn't do recursive route 
lookups, so you need to add static routes to make BGP next-hops reachable.


If I were in your position, I think I would run standalone software 
route reflectors: BIRD has a good reputation, and is widely deployed as 
a route server at exchange points.


Dropping iBGP entirely from your core sounds like a recipe for trouble.

Re: [uknof] Bandwidth Shaping?

[Brian Candler]

On 06/07/2016 22:20, Iain Grant wrote:
Modifying the window size is not new, shorewall can do it - anything 
that can use the ifb driver in linux can!



Can you point me to some documentation to back up that assertion?

As I understand it, etinc and packeteer work by modulating the TCP 
receive window size. I can't find anything about ifb that says it can 
work that way.


It says it does "policing" (i.e. dropping packets out of profile) and 
"shaping" (i.e. delaying packets in a queue).
You can have "active queue management" using the FQ_CODEL algorithm, 
which stops your queues getting too full so that latency is reasonable, 
but as far as I can see it still basically just drops packets, or marks 
them with ECN flags, as a way of signalling the TCP sender to slow down.

Re: [uknof] Bandwidth Shaping?

[Brian Candler]

Presumably you want to put something on the *client* side of the 100M 
link, rather than on the ISP side where you could do it properly?


You could try http://www.etinc.com/

I haven't used it myself, and it's not cheap for 100Mbps. But I believe 
they do quite clever stuff to shape individual TCP streams by modifying 
the window size, rather than just dropping packets; and it's an 
appliance with a GUI.


There's technical info at http://www.etinc.com/58/Technology-Comparison

Regards, Brian.

[uknof] IPv6 and flat /48's

[Brian Candler]

I have now dealt with two UK providers who, when asked to add IPv6 to a 
business connection, have insisted on configuring a flat /48 on the CPE 
LAN port.


I was expecting them to configure a /64 interconnect on the LAN port, 
plus a /48 static route pointing to the customer's own router or 
firewall - or possibly DHCP prefix delegation.


As far as I can see, a flat /48 is going to require the customer to run 
NDP proxying for every block of /64 they use internally; and the CPE 
will end up maintaining separate NDP entries for every device inside the 
customer's network.


It seems broken by design to me. Am I right, or is this considered a 
reasonable way to interconnect these days?


Is it just because these ISPs don't understand IPv6, or they don't want 
to deal with managing static routes on the CPE?


Thanks,

Brian.

Re: [uknof] IPv6 usage explosion

[Brian Candler]

On 24/05/2016 11:12, Brandon Butterworth wrote:

That is one of the fundamental problems: deploying IPv6 does*not*  in
>the slightest reduce your need for IPv4 addresses!

I would have expected more v6 = less pressure on CGNAT box so can get
away with higher user to real IP ratio


Sure - if you're a carrier who does NAT on behalf of your customers. 
That means basically just the mobile networks. They force a load of 
stuff through proxies anyway.


For everyone else:

- If you're an edge network, then you're probably happy NATing to a 
single IPv4 address already


(Of course, there are some broken networks who try to NAT far too much 
onto a single IP, e.g. hotels with 1000 rooms. But their networks are 
built with an astounding lack of clue at the best of times)


- If you're a fixed-line ISP, you had better give real IPv4 addresses to 
your customers, or you die in the marketplace


In some markets, you might get away with NAT444 as a consumer ISP. But 
try telling a business customer they can't accept inbound VPN 
connections over IPv4.

Re: [uknof] IPv6 usage explosion

[Brian Candler]

> I've had internal discussions about pushing out IPv6 internally 
everywhere to save on v4


That is one of the fundamental problems: deploying IPv6 does *not* in 
the slightest reduce your need for IPv4 addresses!


You're still going to need as much IPv4 space as you ever did:
- for outbound access to the majority of the Internet (whether it be 
NAT44 or NAT64)

- to allow inbound access from the majority of the Internet

Today, deploying v6 will reduce the processor load on your NAT box, and 
nothing more. This will always be the case until the time it becomes 
feasible to deploy IPv6-only networks. This might happen when:


1. there's so little IPv4-only Internet that you don't care about not 
being fully connected (a very long way away)


2. NAT64 is as easy for a customer to deploy as NAT44 is today (possible 
- but even then ISPs will still need to deliver v4 to customers)


3. ISPs all provide robust, well-managed NAT64 services; and/or there's 
a public NAT64 service which the IPv4-only Internet is reachable through.



> I am utterly of the opinion that the opinions of your customers are 
really irrelevant here.


It's nice to see the customer service ethos still holds strong :-)

But there's a more important point: you can deliver IPv6 to a customer, 
but you can't make them drink.


As an ISP, your business is selling IP packets. It is perfectly natural 
that you should build your network to carry both flavours of IP packets; 
indeed, the work required to achieve this is relatively small.


That's not true for end users, who only care about selling chocolate 
bunnies or whatever.


Dual-stack is a great strategy for switching over a network from IPv4 to 
IPv6. But for most users, dual-stack is a rubbish strategy for permanent 
deployment. There are both initial and ongoing costs, and very little to 
show in the way of benefit.


And before anyone says it: no, there will not be any IPv6-only websites. 
Nobody's business plan involves putting up content which is only 
reachable over IPv6.


And no, the IoT does not need IPv6. The IoT runs today, on IPv4. And 
even with IPv6 they would still use meet-in-the-middle servers. Or do 
you really expect everyone to disable their firewall and allow inbound 
connections from the whole Internet?


Regards,

Brian.

Re: [uknof] BT deny demand for broadband without a dial tone

[Brian Candler]

A spokesmen for BT said: "Anyone using broadband uses a landline..."

sigh.


I have been told by someone lucky enough to live in a FTTP area, that BT 
*insist* on installing a copper pair alongside it for POTS service, whether you 
want it or not.

Re: [uknof] Fwd: internet connection record

[Brian Candler]

On 20/01/2016 16:40, uknof-requ...@lists.uknof.org.uk wrote:

A slightly more detailed description can be found in some of the Home
Office written evidence to the joint committee:

http://data.parliament.uk/writtenevidence/committeeevidence.svc/evidence
document/draft-investigatory-powers-bill-committee/draft-investigatory-p
owers-bill/written/26435.pdf

Page 29 provides the following items as the "core" of an ICR:

* Account reference
* Source IP
* Source port
* Dest IP
* Dest port
* Session start timestamp
That sounds rather like Netflow accounting - except "Account reference" 
would have to be externally obtained by looking up the customer's IP 
address in some other data source, e.g. RADIUS accounting.



And additionally, entities "whose quality may be degraded by a
numberof factors" and which "are desirable and will be sought where
feasible and cost effective to do so":

* URI domain/service identifier
* Session end timestamp
* Volumes transferred and direction
Netflow will also give you the last two. However looking at 
network-layer traffic can't possibly give you the domain. (Well, you 
could attempt to correlate network traffic with client DNS queries; but 
the presence of client caching and multiple clients behind NAT makes 
that pretty infeasible. Otherwise you can do DPI on HTTP, SMTP etc; but 
that won't work with the TLS versions of those)


It seems to me this whole thing is written by someone who thinks that:

1. "The Internet" and "The Web" are the same thing

2. "Internet Connection Records" are real things, which are already 
captured by ISPs in the course of their business (in the way that CDRs 
are captured by telephony providers)


Maybe that's true for mobile phone networks, who often funnel clients 
through their own NAT/proxy devices for the purposes of saving IP 
addresses and compressing content. But it's clearly not the case for 
fixed-line ISPs.


And what would be the requirements for *hosting* ISPs, who sell multiple 
1G and 10G ports?

Re: [uknof] AS Path Filters and Regex

[Brian Candler]

On 04/11/2015 11:00, James Bensley  wrote:

Unless anyone can give a compelling reason as to why I should see those
private and reserved ASNs in the global table, please let me know.
You can't filter out ASNs; you can only filter out the prefixes which 
carry those ASNs as attributes.


So what you are actually saying is: "these prefixes must be invalid if 
they have XYZ attribute". It's a bit like deciding that an E-mail is 
spam based on whether the sender has reverse DNS, or provides a valid 
EHLO name.


If you drop the route, then you may be hurting the remote network a 
little bit (by not being able to reach you), but you may also be hurting 
your own customers (by not being able to reach the remote network)


If your customer says they can reach the remote network through every 
other ISP they have tried but not yours, they are going to blame you.

Re: [uknof] Trimming the Routing Table

[Brian Candler]

On 02/11/2015 12:55, Brian Candler wrote:
Aside: a new 2901 with 2.5GB RAM should set you back less than a 
grand. However it may not have the throughput you need: it's rated at 
327Kpps, which is 167Mbps with 512-byte packets. 

I forgot 8 bits per byte, doh!  It's 167Mbps with 64-byte packets.

If your traffic mix has an average of 384 bytes per packet then you 
should be able to fill a gigabit (in one direction anyway)


Regards,

Brian.

Re: [uknof] Trimming the Routing Table

[Brian Candler]

> As a side note, does anybody have practical experience with taking two
> tables and how this affects FIB and memory?

Here I take two full feeds on two separate 2901's (IOS 15.2, each with 
2.5GB RAM) which iBGP with each other.


rtr1#sh bgp ipv4 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd
aaa.aa.aa.aaa   4   ii 10212329 8301380 31450264100 
12w4d  464785
xxx.xx.xxx.xxx  4  2480652   37924 314502611 00 
1w5d   554247


rtr1# sh bgp ipv6 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd

:xxx:::
4   567657   83036 33790410 00 
3w5d24596

::a:aaa::aaa
4   ii 1148950  831084 33790417 00 
12w4d   18914


rtr1#sh proc memory sorted
Processor Pool Total: 2368073936 Used:  578934948 Free: 1789138988
  I/O Pool Total:  117440512 Used:   18606288 Free:   98834224

 PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
 336   0  885066900 1989483932  430124080  0  0 BGP Router
 204   0  195215412  214911576   96650648  0  0 IP RIB 
Update

   0   0  151904364   90387224   57900300  0  0 *Init*
 237   0   13212848   201407603125708  0  0 IPv6 
RIB Event H

 277   01275836  183321264768  0  0 EEM Server
   0   0 2149920572 3079609700 8423482483563  0 *Dead*
 273   0 463520   3756 445548  0  0 VLAN 
Manager
 335   0 441272  22644 419044  0  0 
OSPF-100 Router

...

And the other one is similar:

rtr2#sh bgp ipv4 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd
yyy.yy.y.yyy4  17504637  139480 39393026 00 
12w4d  552998
bbb.bb.bb.bbb   4   ii 8301832 10212667 39393503 00 
12w4d  431682


rtr2#sh bgp ipv6 unicast summary
...
NeighborV   AS MsgRcvd MsgSent   TblVer InQ OutQ 
Up/Down  State/PfxRcd

:yyy:y:yy::y:y
4  1973378  139518  2167092 00 
12w4d   23160

::b:bbb::bbb
4   ii  831122 1148977  2167092 00 
12w4d   19563


rtr2#sh proc memory sorted
Processor Pool Total: 2368097488 Used:  568174800 Free: 1799922688
  I/O Pool Total:  117440512 Used:   18572320 Free:   98868192

 PID TTY  Allocated  FreedHoldingGetbufsRetbufs Process
 336   0  450496888  863316832  419524372  0  0 BGP Router
 204   0   952448683110848   94214820  0  0 IP RIB 
Update

   0   0  151998800   90378244   57906052  0  0 *Init*
 237   05513424 1059005523444  0  0 IPv6 
RIB Event H

 277   01275788  183321264720  0  0 EEM Server
   0   0 3713827068 3955372652 7495362440471  0 *Dead*
 273   0 463520   3756 445548  0  0 VLAN 
Manager
 335   0 423284  0 423068  0  0 
OSPF-100 Router

...

(x and y are upstreams, a/b are the iBGP peers)

So a little over half a gig in total is used on each router. I am doing 
only the most basic bogon filtering, otherwise accepting everything 
offered, no default, and no soft-reconfiguration inbound.


As I understand it, BGP soft reset makes soft-reconfiguration inbound 
unnecessary anyway:

http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/s_sftrst.html

Aside: a new 2901 with 2.5GB RAM should set you back less than a grand. 
However it may not have the throughput you need: it's rated at 327Kpps, 
which is 167Mbps with 512-byte packets.

http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf

Regards,

Brian.

[uknof] uknof list archive?

[Brian Candler]

At http://lists.uknof.org.uk/cgi-bin/mailman/listinfo/uknof/ it says
" To see the collection of prior postings to the list, visit theuknof 
Archives ."


However that link points to
http://lists.uknof.org.uk/pipermail/uknof/
which gives a 404.

Is there a publically-readable/searchable archive of the list?

Thanks,

Brian.

Re: [uknof] 10gb switch

[Brian Candler]

On 17/09/2015 21:12, Brian Candler wrote:
I have good experience with Netgear XSM7224S (only used for layer 2), 
but that's considerably more expensive. 

I remembered there is a cheaper model:
http://netgear.co.uk/business/products/switches/smart/XS712T.aspx#tab-techspecs

This is not a proper managed switch with CLI: it is a "smart" switch 
with web management only, maybe not even SNMP. And I have never used it 
so can't vouch for it.


However it does meet the "1U" requirement, and it does fit the budget 
(£966+VAT on comms-express.com). It has 12 copper ports, two of which 
can be SFP+ instead.

Re: [uknof] 10gb switch

[Brian Candler]

On 17/09/2015 18:50, Joseph Waite  wrote:

Looking for recommendations/suggestions for 10gig switch.

Requirements are minimum 4 x 10gig fibre ports.
Plus minimum 8 x 10gig, not fussed fiber or copper, rj45 or cx4

Only requirements on switch is lag group support & jumbo frames 9000 minimum.
Oh 1u and as low power as possible so no Cisco nexus stuff!!

Budget is under ?1k per switch preferably from a reputable supplier not eBay.
Doesn't have to be new!
I have a friend who bought some Dell 8024F's on Amazon - they are an 
end-of-life range but he's very happy with them. Said he paid about 
$2000.  They are 24 port 10G SFP+ with 4 10Gbase-T copper on the side. 
The SFP+ ports are 10G only.


http://www.amazon.com/Dell-575612798-PowerConnect-Manageable-Expansion/dp/B009T35B9O

I have good experience with Netgear XSM7224S (only used for layer 2), 
but that's considerably more expensive.

Re: [uknof] Openreach withdrawal of FTTC CPEs

[Brian Candler]

On 17/09/2015 10:19:46, James Bensley  wrote:

A common deployment is that we are using static IPs between CPE and
exchange device, then the customer is running DHCP relay (it's
configured on our CPE LAN interface) back to a central DHCP server
somewhere else in their WAN. We've had some issues with this not
working at a handful of exchanges and they were the only NGA sites we
had at those exchanges so we had nothing to compare against.
DHCP relay is just unicast UDP. It would be extremely evil if an 
upstream device were to intercept that and mangle it.


You could easily get around it though, for example by routing your DHCP 
traffic over IPSEC or GRE, or perhaps just by using non-standard port 
numbers.

Re: [uknof] Notice of Claimed Infringement

[Brian Candler]

On 14/09/2015 12:00, uknof-requ...@lists.uknof.org.uk wrote:

I don't disagree with some of the points others have raised, however I
am not going to potentially accuse my customer of breaking the law
without someone giving me something a bit more realiable to go on :)

I don't think there is any need to "accuse" your customer of anything.

You can simply inform them that you have received a message from the 
media company on date X, and forward them a copy of the message. The 
fact that you have received such message is not in dispute. What the 
customer chooses to do with that information is up to them.


For me, the bigger issue would be whether the ISP should store any 
information on their systems concerning either the incoming message or 
the fact that it has been forwarded to the customer.


An accusation that they were downloading "Jumbo Knockers - Part 3" in 
violation of copyright law could be considered "sensitive personal data" 
under the terms of the DPA; see

http://www.legislation.gov.uk/ukpga/1998/29/section/2
parts 2(f) and 2(g). If so, it has much more stringent controls on 
processing:

https://ico.org.uk/for-organisations/guide-to-data-protection/conditions-for-processing/

But IANAL.

Regards,

Brian.

Re: [uknof] TCP Trainee

[Brian Candler]

If my laptop was filling it's RWIN
then sending back the ACKs it would be like one in 10
That would be a great way to kill your TCP throughput. Once an RWIN of 
data had been sent, the transmitter would be forced to stop sending. 
There would then be an RTT pause until it was able to start sending 
again - or longer, if the ACK was lost.

Re: [uknof] TCP Trainee

[Brian Candler]

Alternatively you can just use the underlying tool directly, which for
>packet loss is owamp. By default it sends 10 packets per second, and it
>measures the packet loss and latency separately in each direction. (Latency
>measurements require good NTP sync at both ends).

Yes, configuring owamp is a pita. Thankfully gps devices are available, but
only one usb based one I know of emits a PPS signal to condition ntp.

Smokeping is good for ongoing monitoring. Flent I hope gets added to
perfsonar, also.

Also, I am unhappy with perfsonar as it uses (when last I looked) a
totally ancient linux kernel, which is incapable of dealing with
10+GigE well, and there have been so many post-bufferbloat-era
improvements in the tcp and driver stack that I would be very
reluctant to trust any tcp measurements it takes.

perfsonar provides you with the CentOS 6.5 kernel with the web100 
patches (http://www.web100.org/), so yes it's pretty old, but it has had 
some tuning.


Someone else wrote:


The most important limitation of perfsonar-like approaches for my use is
that they require a Linux-machine at the customer-end of the connection.
This is not really feasible with 1000+ lines.


One of the current perfsonar objectives is to make a low-cost probe (I 
think the target is $50-$100) which can be plugged into various points 
in your network and will respond to the various test types. The idea was 
to make it so cheap you could put one in every wiring closet.  I don't 
know how that project is progressing, and whether it will end up being 
100M or 1G capable.


In my case, I have deployed a few test endpoints which are Mac Minis 
running OSX, and have compiled bwctl/owamp/iperf3 on them (this is now 
in homebrew).  So you can have a central perfsonar box which schedules 
tests to the Mac Minis, but the Macs can be used as normal workstations 
for the rest of the time.


perfsonar can also do normal ping tests, which it does in the same way 
as smokeping (e.g. send a burst of 20 pings every 5 minutes). It's 
better than nothing, but nowhere near as sensitive to low-level packet 
loss as owamp.


Regards,

Brian.

Re: [uknof] TCP Trainee

[Brian Candler]

On 24/06/2015 10:44, Benny Amorsen wrote:


Brian Candler writes:


It turned out there was packet loss of 0.02% on the office line (i.e.
only 1 in 5000 packets dropped), which I was also able to demonstrate
directly using ping and owamp.

TCP is ridiculously sensitive to packet loss at the speeds we see today.
Lines are not permitted to have any measurable packet loss except when
there is congestion.

This does not combine well with e.g. 4G. When moving a mobile device
around, it is easy to have 0.1% packet loss or more, which means the
user will never see the 100Mbps+ speeds that 4G could theoretically
offer.

Application developers are likely to make work-arounds like opening
multiple TCP streams when fetching video or even abandoning TCP
altogether.


The provider managed to fix the packet loss by moving the exchange end
to a different switch port, and now the same download fills the whole
100Mbps.

I am impressed that the provider took a 0.02% packet loss seriously.
Many providers would not.
It took several months, lots of measurements collected at our side, and 
threats of moving to a different provider.



If you know of a way to measure 0.02% packet loss automatically with an
NMS, I would be happy to hear about it.
perfsonar PS toolkit. As well as very sensitive packet loss 
measurements, it can also do periodic burst transfers using iperf or 
similar tools to see how much throughput you can actually achieve.


The stack you get with perfsonar is:

- CentOS
- owamp, iperf/iperf3/nuttcp [low-level testing tools]
- bwctl [allows remote sites to request tests, ensures no two throughput 
tests at the same time]

- esmond [database for storing the results]
- test scheduler
- GUI to configure test schedules and draw graphs

esmond can be queried via a REST interface, so in principle it shouldn't 
be too hard to integrate with an NMS.


Alternatively you can just use the underlying tool directly, which for 
packet loss is owamp. By default it sends 10 packets per second, and it 
measures the packet loss and latency separately in each direction. 
(Latency measurements require good NTP sync at both ends).


Regards,

Brian.

Re: [uknof] TCP Trainee

[Brian Candler]

I have downloaded a 100MB test file on my colo box from another box in
the US which climbed to just over 100Mbps before the end of the file
was reached.


What's the problem - what speed were you expecting from the spreadsheet?

There are a whole bunch of things which can affect the total throughput of TCP, 
including:

* Packet loss - https://en.wikipedia.org/wiki/TCP_tuning#Packet_loss
* What speed the remote box is able to send at (may be limited by CPU, 
bandwidth of remote connection etc)

Here's a real-world example. I was on an office 100Mbps fibre line. When 
downloading a file from Greece (75ms RTT away) the throughput was limited to 
about 3Mbps.  But my home FTTC line, with no packet loss, was maxing out the 
line at 67Mbps.

It turned out there was packet loss of 0.02% on the office line (i.e. only 1 in 
5000 packets dropped), which I was also able to demonstrate directly using ping 
and owamp.

The provider managed to fix the packet loss by moving the exchange end to a 
different switch port, and now the same download fills the whole 100Mbps.

Connecting to a local server using speedtest.net didn't demonstrate the problem 
- it showed ~75Mbps. This is for two reasons: speedtest.net chooses a nearby 
server with a low RTT, and the client opens four concurrent TCP streams.

Regards,

Brian.

Re: [uknof] ntp1.linx.net jitter

[Brian Candler]

It suddenly looks a lot healthier :-)

# ntpq -p
 remote   refid  st t when poll reach   delay offset  
jitter

==
+ntp1.linx.net   .PPS.1 u 1049 1024  3779.611 -0.128   0.672
-ntp2.linx.net   .GPS.1 u   63 1024  377   10.243 -0.227   0.035

Thanks, whatever you did.

Cheers,

Brian.

[uknof] ntp1.linx.net jitter

[Brian Candler]

Anybody else notice that ntp1.linx.net is jittery but ntp2.linx.net is 
stable as a rock?


$ ntpq -p
 remote   refid  st t when poll reach   delay offset  
jitter

==
...
+ntp1.linx.net   .PPS.1 u  174 1024  3774.677 0.289  36.181
*ntp2.linx.net   .GPS.1 u  501 1024  3775.631 0.006   0.253

This is despite the fact that the path to ntp2 appears to go through a 
bunch more hops, and some FastEthernet interfaces.


I'm not a LINX member so don't have an official way to report this, but 
maybe someone here will pick it up?


Regards,

Brian Candler.

$ sudo traceroute -I ntp1.linx.net
traceroute to ntp1.linx.net (195.66.241.3), 30 hops max, 60 byte packets
...
 3  ae-125-3511.edge5.london1.Level3.net (4.69.166.41)  4.415 ms 4.425 
ms  4.424 ms
 4  ae-125-3511.edge5.london1.Level3.net (4.69.166.41)  4.423 ms 4.422 
ms  4.434 ms
 5  DAISY-GROUP.edge5.London1.Level3.net (212.187.138.166)  4.878 ms  
4.896 ms  4.975 ms
 6  te0-2-0.ar06.tn5.bb.daisyplc.net (62.72.137.182)  4.935 ms 4.927 
ms  4.898 ms
 7  te0-2-0.ar06.tn5.bb.daisyplc.net (62.72.137.182)  4.588 ms 4.617 
ms  4.593 ms

 8  ge0-3.tr5.linx.net (195.66.248.33)  4.686 ms  4.882 ms  4.885 ms
 9  ntp1.linx.net (195.66.241.3)  4.873 ms  4.856 ms  4.844 ms

$ sudo traceroute -I ntp2.linx.net
traceroute to ntp2.linx.net (195.66.241.10), 30 hops max, 60 byte packets
...
 3  ae-125-3511.edge5.london1.Level3.net (4.69.166.41)  4.436 ms 4.448 
ms  4.447 ms
 4  ae-125-3511.edge5.london1.Level3.net (4.69.166.41)  4.443 ms 4.440 
ms  4.452 ms
 5  DAISY-GROUP.edge5.London1.Level3.net (212.187.138.166)  4.876 ms  
4.900 ms  5.096 ms
 6  te0-2-0.ar06.tn5.bb.daisyplc.net (62.72.137.182)  4.877 ms 4.803 
ms  4.751 ms
 7  te0-2-0.ar06.tn5.bb.daisyplc.net (62.72.137.182)  4.553 ms 4.606 
ms  4.607 ms

 8  ge0-3.tr5.linx.net (195.66.248.33)  4.630 ms  4.648 ms  4.729 ms
 9  fe2-1-502.tr2.linx.net (195.66.249.9)  4.680 ms  4.642 ms  4.635 ms
10  fe6-1.tr1.linx.net (195.66.248.57)  4.981 ms  5.086 ms  5.099 ms
11  ge0-3-101.tr6.linx.net (195.66.248.13)  5.444 ms  5.274 ms 5.124 ms
12  fe6-0.tr3.linx.net (195.66.248.180)  5.332 ms  5.272 ms  5.363 ms
13  ntp2.linx.net (195.66.241.10)  5.449 ms  5.448 ms  5.466 ms

Re: [uknof] BT mail

[Brian Candler]

Thanks to everyone who answered privately.

In summary, BT has been moving users off Yahoo and back onto their own 
systems (*).


If when you login to read mail online you get to
https://btmail.bt.com/cp/ps/main/index#mail
(which I did) then this is a migrated account.

This means you have to connect using manually-configured IMAP rather 
than the Yahoo! account settings in iPad.


Cheers,

Brian.

(*) Some fluffy information at
http://bt.custhelp.com/app/answers/detail/a_id/44789/~/we%27re-changing-bt%27s-portal-and-email-services

[uknof] BT mail

[Brian Candler]

Anyone here know anything about the btinternet.com (Yahoo) mail service?

I'm trying to help someone who has one of these accounts. The 
username/password works fine logging into the BT/Yahoo desktop site. But 
if you try to login at m.yahoo.com, it says:


" Your account needs updating. Please sign in at login.yahoo.com from a 
desktop computer so that Yahoo can guide you through the process safely 
and securely."


But doing that just logs in and takes you to home.bt.com - no further 
instructions.


I tried changing the password to a new one, and back again, at
https://register.btinternet.com/cgi-bin/chpasswdsso
but that didn't fix it.

The upshot is that this account doesn't work on an iPad for collecting 
mail (nor with the Yahoo app, which also says to)


Clues gratefully received.

Regards,

Brian.

Re: [uknof] Vodafone UK/AS25135, 1.2.3.50 O RLY?

[Brian Candler]

On 17/09/2014 11:00, Greg Choules  wrote:

My*guess*  is that there are insufficient RFC1918 (v4) addresses to go around 
both 3G and 4G mobile terminals and since everything that needs to go 
externally will be NATed to a public IP anyway it doesn't matter what is used 
between your handset and VF's packet core. Anything you choose potentially 
looks like you are squatting on someone else's space. At least they picked what 
looked like an unannounced (at the time) prefix.
If you want infrastructure IPs which are unroutable but don't clash with 
your customers' use of RFC 1918, there's 100.64.0.0/10 from RFC 6598.

Re: [uknof] Belfast

[Brian Candler]

On 11/09/2014 09:34, Charlie Boisseau  wrote:

Erm.. I hate to break it to you, but Belfast is in Britain.

We might not be able to say the same about Scotland soon:-(, but Northern 
Ireland is still part of Britain
Technically I believe we are the United Kingdom of Great Britain and 
Northern Ireland.


(But people do seem to use "Britain" and "United Kingdom" somewhat 
interchangeably)

Re: [uknof] Small L3 switch with unnumbered ethernet

[Brian Candler]

On 10/09/2014 21:42, Nick Hilliard wrote:

On 09/09/2014 15:00, Brian Candler wrote:

I'm looking for a small layer 3 switch with 2 x 10G interfaces and which
supports unnumbered point-to-point ethernet subinterfaces.

me3600 if you like cisco boxes?

I'm fine with Cisco, but don't know their metro-specific products or how 
they compare feature/price-wise with the standard products.

[uknof] Small L3 switch with unnumbered ethernet

[Brian Candler]

I'm looking for a small layer 3 switch with 2 x 10G interfaces and which 
supports unnumbered point-to-point ethernet subinterfaces.


Application is a native ethernet access network, with customers 
presented on different tagged VLANs. No PPPoE/BRAS. Using /31 
point-to-point subnets would be trivial but would burn 50% of v4 address 
space, so I want to be able to give each customer the next available 
/32. Finding compatible CPE is not a problem.


What I've found so far:

* Juniper feature "unnumbered ethernet" is disabled on any switch 
smaller than EX9200 :-(

http://pathfinder.juniper.net/feature-explorer/search-features.html
http://www.juniper.net/techpubs/en_US/junos13.3/topics/usage-guidelines/interfaces-configuring-an-unnumbered-interface.html 



* Cisco feature "IP unnumbered for VLAN-SVI interfaces" is not on the 
Cat 3750-X switches, but looks like it is on the 3650 and 3850 with IOS XE

http://tools.cisco.com/ITDIT/CFN/jsp/by-feature-technology.jsp

Does anybody know of any other options? A real router would also be 
considered if it's in the compact L3 switch price bracket.


Thanks,

Brian.

Re: [uknof] UK IPv6 Taskforce

[Brian Candler]

Incidentally, I recently asked about getting IPv6 added to an existing 
Easynet 100M office leased line. The account manager said they could, 
but would charge £395+VAT for doing it. So that idea went by the wayside.


Regards,

Brian.

Re: [uknof] UK IPv6 Taskforce

[Brian Candler]

On 05/09/2014 17:15, Richard Patterson  wrote:

there's plenty of things that content providers may care about
that'll be broken under NAT44 and can be resolved by adopting IPv6.

...

Geolocation tracking and/or CDN steering.
Access restrictions (Betting sites blocking multiple users behind one IP).
You think geolocation is going to be done at a finer resolution than /64 
in IPv6?


Ditto for access restrictions. Many clients enable privacy addresses by 
default. Hence if you have a business need to block someone by their 
network location, you would have no option but to block at least the /64.

Re: [uknof] UK IPv6 Taskforce

[Brian Candler]

On 05/09/2014 09:43, Andy Davidson  wrote:

giving users native v6 and NAT44 gives content companies an opportunity to 
sidestep the brokenness by simply adopting V6
I'd say that giving users native V6 and NAT44 gives the content 
companies *no reason whatsoever* to adopt V6, since they know all their 
content is reachable via the tried-and-tested V4 path anyway. It's not 
broken on their side.

Re: [uknof] UK IPv6 Taskforce

[Brian Candler]

I sometimes wonder if the larger, established ISPs, sitting on their old
allocations of IPv4 addresses, have a vested interest in preserving the
status quo since without a functioning IPv6, the lack of IPv4 space is a
barrier to new competitors entering the market.

I don't see a need to invoke any conspiracy theories.

I hope people won't be offended if I give a highly simplified model of 
the participants in the Internet:


  end user(1) - access ISP(2) - transit ISP(3) - hosting 
ISP(4) - content provider(5)


Now, only one of these groups is really feeling the pain of address 
depletion, and that's the access ISPs(2). Some feel that pain badly, and 
it's certainly true that there's no way you could enter the market as an 
access ISP in the UK given a /22 of address space.


The hosting ISPs(4) also feel some pain - especially if they are doing 
things like VM hosting, one IP per instance. If you want to become the 
next Amazon EC2, you are not going to get far on a /22.


But I'd say nobody else is affected by this problem. In particular, the 
content providers(5) have been sharing IP addresses for years (with HTTP 
virtual hosts, reverse proxies/load balancers, and CDNs). A /22 is 
plenty of space for a new content provider.


So the first point to make is: if you want to throw subsidy money at the 
problem, you don't necessary want to do this to the access ISPs, but to 
everyone else.


To be fair, the transit ISPs(3) have pretty much finished the rollout. 
Essentially it was just pasting some config into their routers.


Now, what about the content providers? As it would be pretty simple for 
them to IPv6-enable, why don't they? To take a random example, why isn't 
www.bbc.co.uk reachable via IPv6? That's an organisation which is not 
short of either technical expertise or budget.


I suspect the problem is finding a reason *for* them to turn on IPv6. 
Any website's users fall into these groups:


(1) IPv4 only
(2) IPv6 + IPv4, dual stack
(3) IPv6 + NAT64/DNS64, maybe a few
(4) pure IPv6 only, of which there are precisely zero

By putting their content on IPv4, they reach all their users. By putting 
it on IPv6, they reach nobody else. Putting it on IPv6 carries some 
setup cost, and some risk, and some ongoing support cost. So where's the 
business case? Will they do it from the kindness of their hearts, just 
to help out the poor Access ISPs who are being squeezed?


Here's another question: at what point will IPv6-only content start to 
appear? Won't that force access ISPs and end users to pick up IPv6?


What content providers care about is getting to the maximum number of 
eyeballs. If they need an IPv4 address to do this they will get one, and 
even if that address costs $1,000 that's still cheap. They often pay 
many, many times more than this just to get an attractive domain name.


Looking back in history, remember when websites stopped supporting IE5: 
it was when the proportion of IE5 users fell below about 1%. So I'd 
predict the same here: that is, content providers might put up IPv6-only 
content when IPv4-only users account for less than about 1% of their 
audience. Not all eyeballs are equally valuable: in some cases it might 
be when IPv4-only *business* users account for less than 1% of all 
*business* users.


As for the end users, in general they don't know or care. They are using 
HTTP(S) for buying and selling stuff, and just want it to work. You may 
be a geek who wants to ssh into your fridge, but if so, you are not 
representative.


And lastly, back to the the access ISPs. If they're the ones suffering 
the pain, shouldn't they be leading the way? Well, yes and no. Access 
ISPs only succeed at scale, working on miniscule margins in a cut-throat 
market, and have to minimise every cost. The tiniest increase in support 
calls will have a big impact on their bottom line. So if they have 
enough IPv4 addresses, and given they know all the content will be on 
IPv4 (see above), then unless their target market is geeks or gamers, 
they may be more profitable not deploying IPv6.


All because IPv6 was not built as an extension to the Internet, but as a 
replacement for it :-(


Regards,

Brian.

Re: [uknof] Reverse DNS by 3rd Party

[Brian Candler]

I have good experience with GoDaddy Premium DNS. It's astonishingly 
cheap, for an unlimited number of zones, and provides two anycast 
servers. I use them in conjunction with an off-site secondary VM for 
more resilience.


You can either use their web interface to manage the zones (and permit 
access to your off-site secondary servers if you want those); or you can 
configure GoDaddy as a slave to another nameserver that you control.


Regards,

Brian.

[uknof] Easynet performance issue

[Brian Candler]

I'm looking for someone who has a high speed (100Mbps+) connection or 
server hosting on Easynet (AS4589) to do a handful of performance tests 
to help debug an issue I'm seeing. This would just be a run of 
iperf2/iperf3 and timing the download of a couple of large files.


If you're up for that, please could you contact me via private E-mail.

Thanks,

Brian Candler.