Re: [uknof] MIkrotik RoS7 BGP Woes

[Nick Hilliard]

Aled Morris via uknof wrote on 02/11/2022 11:27:
If you need an inexpensive, reliable, route reflector, perhaps you could 
consider one of the free softwares?  BIRD comes to mind.  The RR doesn't 
need to be in the packet routing path after all.


there are good reasons to keep RRs out of the forwarding path.  For one 
thing, it simplifies policy management.


Bird is excellent for plain ipv4 / ipv6 RR functionality, if you don't 
need fancier features, e.g. ISIS, MPLS, advanced AFIs, ORR, etc.


Nick

Re: [uknof] MIkrotik RoS7 BGP Woes

[Nick Hilliard]

Brian Candler wrote on 02/11/2022 07:57:
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.


also, routeros6 silently drops OSPFv3 LSAs with the LA bit set, which is 
problematic, because this would be how other routing stacks (e.g. cisco 
/ juniper / bird) would advertise /127 and /128 interface prefixes.


Apparently this has been fixed on routeros 7.

Nick

Re: [uknof] Sending kit to European data centers

[Nick Hilliard]

John P Bourke wrote on 31/01/2021 21:21:
What happens now hen you want to send kit or spares to your 
installations in the EU ?


There is paperwork.  Do you have to pay VAT ?

What if you bring it back for repair ?

I guess you just buy in the EU ?


Moving equipment across customs barriers is a thundering headache and 
can be surprisingly expensive.  If this is something you need to do on 
anything other than a very occasional basis, you should think about 
getting professional advice from a shipping agent about what to expect. 
I don't know enough about the exact details of the UK/EU trade deal to 
know what exact pitfalls are there, but every one of the EU <-> not-EU 
shipments that have passed my desk over the last 5 years have caused 
inordinate headwreck of one form or another - delays, expense, paperwork 
- and in most cases, all three.


There are various options for purchasing kit:

0. buy in UK, ship to EU and handle the awful, awful pain yourself
1. use a VAR in UK who can fulfil orders in EU from UK
1.1. use a VAR in UK who has an EU operating company and can fulfil 
orders in EU from EU

2. use a VAR in EU, and pay from UK
3. set up a local operating company in EU and handle everything from there

If you have reasonable volume requirements and a tangible EU business 
ops split, option 3 has a good deal of merit associated with it, but it 
requires business changes and buy-in from higher-ups.  In other words, 
it's a business strategy change rather than an operational change in 
procurement practice.  If you have not-insubstantial business operations 
in the EU, it's likely that this would be the best long term option.


Probably you need to bin the idea of return-to-uk for repair, unless 
you're ok with the idea of regularly applying power drills to your 
cranium and stabbing out your eyes with rusty forks.   Not judging, btw 
- some people do this for a living.


Nick

Re: [uknof] UK interconnects and Brexit

[Nick Hilliard]

Chris Russell wrote on 11/12/2020 20:14:
  If COVID has taught us anything, (tbf, we already knew a lot of this 
within IT/NetOps in general)  it's that hybrid working can work. I see 
something similar for UKNOF speakers too.


it's showing us that our businesses can coast along reasonably well in 
the short term on the basis of existing relationships, but new 
relationships are hard to make without face-to-face contact.  The effect 
of this lack of contact on business is hard to quantify, but it's real.


Nick

Re: [uknof] UK interconnects and Brexit

[Nick Hilliard]

Kurtis Lindqvist wrote on 11/12/2020 15:38:

On 11 Dec 2020, at 16:02, Nick Hilliard  wrote:

At the moment this is true - most of the US-EU wet plant built in
the 1998-2003 time-frame terminated in the UK, but when Grace
Hopper is completed in 2022, it will only be the second
americas-europe build with a direct span to the UK in nearly 20
years.

Not sure I would agree with this. TAT-14 lands in Denmark Netherlands
and France as well as the UK.

tat-14 will be 21 by the time grace hopper is due to go into service.


There IS a lot of traffic exchanged in the UK and some does pass
through for all kind of reasons but real word traffic paths are more
complicated than this


yip, L3 != L1.  Real-world traffic flies in plenty of unexpected directions.

Nick

Re: [uknof] UK interconnects and Brexit

[Nick Hilliard]

Stephen Wilcox wrote on 11/12/2020 14:22:
There's no reason there should be - the UK terminates* cables from the 
US and nominally Africa already which are not part of the EU or 
dependent upon any UK EU law.


At the moment this is true - most of the US-EU wet plant built in the 
1998-2003 time-frame terminated in the UK, but when Grace Hopper is 
completed in 2022, it will only be the second americas-europe build with 
a direct span to the UK in nearly 20 years.


2015: GTT Express - CA-{IE,UK}
2016: AEC-1 - US-IE
2018: Marea - US-ES
2020: Dunant - US-FR
2021: EllaLink - BR-PT
2020: Havfrue/AEC-2 - US-{IE,DK,NO}
2022: Grace Hopper US-{UK,ES}
2022: Amitie US-{UK,FR}

The US-Europe links built in the 1998-2003 era are still working fine, 
but they're getting on in life and won't last the decade. All the future 
builds appear to have the option of bypassing the UK entirely.  So, not 
an issue for UK law per-se, but it does raise issues about where and how 
traffic will flow in future.


Nick

Re: [uknof] West coast main line

[Nick Hilliard]

Tom Hill wrote on 25/09/2020 12:09:

(Except when Network Rail's contractors dumped 20kton of ballast on the
side of the tracks, including on top of the comms ducting, which wasn't
even sunk, ergo why they thought it could survive that weight I do not
know. They didn't move it quickly either, and of course "force majeure".)


but if there was no requirement to prohibit dumping ballast on the side 
ducting, it was fully process compliant, right?


Nick

Re: [uknof] Large DDoS attacks on nameservers of ISP's

[Nick Hilliard]

Pim van Stam wrote on 02/09/2020 10:39:

* target: mainly namservers of an ISP


out of interest, resolvers or auth servers?

Nick

Re: [uknof] Virgin Media DNS issues North London

[Nick Hilliard]

Matt Carlin wrote on 03/07/2020 15:48:
...And just after typing up the paragraph above, I'm able to ping 
151.101.192.81 (bbc.co.uk) with packets up to 1472 bytes, but no

higher. I still can't ping the name though.
1472 payload is what you would expect from an end-to-end MTU of 1500 
bytes, so it's unlikely to be an MTU problem.


There's a lot that can go wrong on cable systems. The usual problems 
relate to poor SNR due to cable plant faults.  These are very localised 
and will only affect small areas.  If there are more widespread issues, 
then there may be problems affecting connectivity into the head-end, 
which would be more generic layer 3 connectivity issues rather than 
anything specific to cable plant or the CMTS farm.


Nick

Re: [uknof] virtualUKNOF on 20th July 2020 - Registrations now open ; Last Call for Presentations

[Nick Hilliard]

Chris Russell wrote on 01/07/2020 17:43:
  This one will be Zoom, funnily enough I had this discussion with Job S 
yesterday about another conference.  Reason for Zoom is specifically at 
this point, we and Bogons both know it and it works for us in webinar mode.


  The point you (and Job yesterday) raise though is valid, we will 
definitely try and look into other conferencing systems. It's a balance 
between time/resources to learn a new system specifically for webinars, 
vs being as open as possible so we can't guarantee we'll have switched 
by a specific time but we will look.


yep, totally get the trade-off here.  In the case of Zoom, the 
functionality and hassle-free setup is great from the point of view of 
conference organisers, but it's pretty frustrating to try to join a 
meeting where the conference organiser has enabled "join from browser" 
and you click on the browser link and it eventually tells you to 
download an installable.  Thanks but no thanks.


  Will add this, for anyone not on the RIPE / LINX future of conferences 
discussion (involving NANOG too) , things like this are being discussed 
- yesterdays catch up was good, lots of information sharing  there are a 
raft of questions right now in terms of how we move forward and what we 
can do attract sponsorship, increase reach and whether being online 
increases diversity. We in this sense being those who run Internet 
conferences. Keep and eye for a post on RIPE labs in the near future on 
this once they've had a chance to write things up.


Great.  I was lurking on that session yesterday (via ipad) and should 
really have brought it up then.


Nick

Re: [uknof] virtualUKNOF on 20th July 2020 - Registrations now open ; Last Call for Presentations

[Nick Hilliard]

Denesh Bhabuta :: UKNOF wrote on 01/07/2020 15:21:

I am pleased to announce that registration for virtualUKNOF July 2020
(taking place on 20th July) is now open. The meeting will take place
as a Zoom webinar and registration is required to participate.

The meeting will only be broadcast live over Zoom and each registrant
will receive a unique Zoom access link.


Hi Denesh,

Sounds great - as always many thanks for organising.

Can I ask about two issues which are recurrent across many online events 
at the moment?


1.  do they support clientless access or are you stuck with having to 
install a local client of some form? Zoom seems to require a browser 
plug-in to work on a browser, and these plugins don't work on all 
systems.  By comparison, lots of other online systems support webrtc 
(e.g. uberconference, bluejeans and piles of others).


2.  why does zoom / webex / etc need to know who we are? I really don't 
want the conferencing system to know who I am.


I know these are awkward questions, but if online video conferences are 
going to be the thing for the next while, maybe we need to get these 
things out into the open and take a good look at them.


Nick

Re: [uknof] Thought for the day: announce the end of IPv4 internet connections by 2026

[Nick Hilliard]

Will Hargrave wrote on 27/05/2020 12:46:
I’m sure you know this but: what this misses is the vast amount of their 
actual CDN traffic, i.e. the actual bulk of the content. I don’t think 
i’m giving away secrets when I say there is substantial IPv6 traffic there.


Most people will never email Netflix and barely look at their website.


this is exactly the point though.  Cherry-picking the higher volume data 
sources and sinks is one thing, but the real cost and diminishing value 
of ipv6 deployment is associated with the long tail - both from a 
content publisher and content consumer point of view.


Nick

Re: [uknof] Thought for the day: announce the end of IPv4 internet connections by 2026

[Nick Hilliard]

Paul Mansfield wrote on 27/05/2020 11:47:

I was surprised how many services aren't but you'd think they could/should be
https://ipv6.watch/


this should give some indication of the complexity, and therefore the 
cost, of service availability over ipv6.


Nick

Re: [uknof] Thought for the day: announce the end of IPv4 internet connections by 2026

[Nick Hilliard]

Per Bilse wrote on 26/05/2020 12:03:
Money talks, it's that simple.  Until the current state of affairs 
becomes less profitable (one way or another), the current state will

prevail.

  this

ipv4 will fade when it becomes more expensive and troublesome than ipv6. 
 If we attempt to short-cut this process and kill ipv4 with policy and 
artificial deadlines, it will will fail just like it failed with the ISO 
/ OSI debacle all those years ago.


The fact that ipv4 is still with us is an extraordinary testament to its 
resilience.


Nick

Re: [uknof] Thought for the day: announce the end of IPv4 internet connections by 2026

[Nick Hilliard]

Per Bilse wrote on 25/05/2020 10:17:
IPv6 remained a draft standard, accompanied by various additional RFCs 
and related documents, until it was finally consolidated in RFC8200 a 
few years ago; the process took nearly 20 years, and the promotion to 
full standard was partly prompted by an administrative change in the RFC 
process.


and we're still working through protocol bugs introduced in rfc8200 :-(

Nick

Re: [uknof] Public IPv4 Addresses Required

[Nick Hilliard]

Ray Bellis wrote on 09/05/2020 13:15:
When I was an undergrad I wrote up a document on how to get uuencoded 
data from ListServs through the various relays that would corrupt them 
because they didn't use ASCII.


yes, that was a real nuisance.  Lots of the bitnet relays also did 
things like trim lines for white space, which confused the heck out of


The doc was widely distributed (although I can't find a copy any more) 
and I was exchanging emails about it with one of the admins of the 
"simtel20" ListServ archive.


Keith Petersen?  He was way ahead of his time.

Nick

Re: [uknof] Public IPv4 Addresses Required

[Nick Hilliard]

David Reader wrote on 07/05/2020 13:19:
Sat at SunOS workstations in a /16 wide open to the whole world & 
naively exposing telnet, ftp, finger, and so on..


At the time, it was a bit rude and neurotic not to expose all these 
services.


Nick

Re: [uknof] Public IPv4 Addresses Required

[Nick Hilliard]

Tim Chown wrote on 07/05/2020 10:45:

Well, let’s rephrase it.  Organisations have had many years to form a
considered plan; that may mean they choose to move progressively to
adopt IPv6 (witness Sky, EE, Mythic, BT, Facebook, Akamai,
Cloudflare, etc) or they have a plan that, for whatever reason,
sidelines IPv6 for the time being.  But having made those
considerations, to complain that there is suddenly no IPv4 address
space available, well…


there's nothing to stop an organisation from planning and fully 
deploying ipv6, and then being inconvenienced because there's no ipv4 
address space available.  The two aren't incompatible :-)


Nick

Re: [uknof] Public IPv4 Addresses Required

[Nick Hilliard]

Tim Chown wrote on 06/05/2020 16:29:

Organisations have had 20 years to form a plan to adopt and deploy IPv6.  It’s 
not rocket science.


it's more to do with motivation than whether it's rocket science. 
Installing stable ipv4 connectivity was troublesome enough when it 
started, but the motivation was high.  IPv6 is an evolution of this with 
a level of gain that, regrettably, does not interest many people.


Nick

Re: [uknof] Open Source Software

[Nick Hilliard]

Leigh Harrison wrote on 06/02/2020 08:55:
Quick question to the community; I’m wondering what kinds of open source 
software folks are using out there and what you’ve used and found 
useful/not useful over the years.


A more interesting question is whether the headline packages which we 
all use are more or less useful than the infrastructure packages that 
they depend on.


Here's the package count from some VMs tied into an orchestrated server 
deployment:



# salt --out=json -G os:Ubuntu pkg.list_pkgs | jq '. | to_entries[] | .value | 
keys[]' | sort | uniq | wc -l
4082


Is wireshark is more useful than bpf or nginx more useful than libiconv? 
 Try deinstalling either and seeing what happens.


Nick

Re: [uknof] MacBook Pro Keys - Update!

[Nick Hilliard]

Catalin Dominte wrote on 20/01/2020 14:49:
I complained to Apple about the replacement time, for something they got 
wrong in the first place. Told them I would invoice them for every day 
that laptop sits on their shelf if the keyboard is not replaced within 
one working day. Made a bit of a fuss when the shop was completely full, 
and they agreed quickly to stop losing customers .


They obliged, and hey presto replacement sorted in 9 hours.


this might work if you're dealing directly with Apple, but if you're 
dealing with a Apple Premium Reseller, the workflow is:


- APR diagnoses problem
- APR sends faulty component to nearest Apple support centre
- Apple support centre sends replacement by return
- APR replaces part

A couple of years ago, I dropped a mbp into an APR for a fan 
replacement.  Two motherboard replacements later and after a litany of 
denials followed by a stand-up argument with the poor sod who handled 
the repair, they finally agreed that the fan needed to be replaced.  It 
took a couple of weeks without the laptop to sort all this.  These days 
for small repairs like this, I usually get parts from The Bookyard and 
do the repair myself.


Usually the APR will make the correct diagnosis first time, but 
sometimes it can go hilariously wrong.


Nick

Re: [uknof] Rats eating fibres in ducts

[Nick Hilliard]

I can't comment on SWA / CST armoured cable plant in ducts, but having 
had pet rats for several years, they enjoy chewing through everything 
from PE and similar plastics through to steel braiding. The only thing 
that will stop them is the point at which their teeth are no longer able 
to physically tear through whatever material they're presented with, 
which means non trivial thicknesses of steel.


If I were you, I would find out if there were any rat owners in the 
locality and ask them if you could string a couple of sections of 
whatever cabling you're planning to use inside their cage for a week or 
two and see what happens to it.  Then extrapolate the damage from the 
test period of a week or two to the planned cable lifetime of several 
years.  Most rat fanciers wouldn't be bothered by this because their 
pets will have a long history of chewing the cage bars, which are made 
of steel.  I.e. this is no more damaging to them than what they have 
already.


They're wonderful pets btw.

Nick

David Round wrote on 14/11/2019 12:44:
Until recently we had never had an issue with rats damaging our fibres 
in our many underground ducts. Over the last few years we have been 
installing CST armoured fibres because other people have had problems 
with rodents and also we judged that CST would probably be enough to 
stop new cables sawing through existing ones when they were drawn in – a 
problem we have had. Just recently we have had two cases of rat damage 
with a number of fibres being cut. These were older, unarmoured duct 
grade cables. Our two pronged plan was to pull in replacement CST 
armoured cables and try and control the rats. When talking to the rodent 
control chap though, I got a bit of a surprise. He said that the rats 
would prefer to gnaw on the armoured cable and would easily cut through 
the CST armour. Does anyone have any real-world experience of this? 
Should we be installing SWA armoured? Are there any other actions we 
should be considering? The rodent control chap suggested sealing up the 
ends of the ducts in each chamber, not to stop the rats, but to allow us 
to track them so that we can find where they are getting in to the network.


Thank you in advance for any advice.

David

*Mae croeso i chi gysylltu gyda'r Brifysgol yn Gymraeg neu Saesneg*

*You are welcome to contact the University in Welsh or English*

*Rhif Elusen Gofrestredig 1141565 - Registered Charity No. 1141565*

Gall y neges e-bost hon, ac unrhyw atodiadau a anfonwyd gyda hi, gynnwys 
deunydd cyfrinachol ac wedi eu bwriadu i'w defnyddio'n unig gan y sawl y 
cawsant eu cyfeirio ato (atynt). Os ydych wedi derbyn y neges e-bost hon 
trwy gamgymeriad, rhowch wybod i'r anfonwr ar unwaith a dilewch y neges. 
Os na fwriadwyd anfon y neges atoch chi, rhaid i chi beidio a defnyddio, 
cadw neu ddatgelu unrhyw wybodaeth a gynhwysir ynddi. Mae unrhyw farn 
neu safbwynt yn eiddo i'r sawl a'i hanfonodd yn unig ac nid yw o 
anghenraid yn cynrychioli barn Prifysgol Bangor. Nid yw Prifysgol Bangor 
yn gwarantu bod y neges e-bost hon neu unrhyw atodiadau yn rhydd rhag 
firysau neu 100% yn ddiogel. Oni bai fod hyn wedi ei ddatgan yn 
uniongyrchol yn nhestun yr e-bost, nid bwriad y neges e-bost hon yw 
ffurfio contract rhwymol - mae rhestr o lofnodwyr awdurdodedig ar gael o 
Swyddfa Cyllid Prifysgol Bangor.


This email and any attachments may contain confidential material and is 
solely for the use of the intended recipient(s). If you have received 
this email in error, please notify the sender immediately and delete 
this email. If you are not the intended recipient(s), you must not use, 
retain or disclose any information contained in this email. Any views or 
opinions are solely those of the sender and do not necessarily represent 
those of Bangor University. Bangor University does not guarantee that 
this email or any attachments are free from viruses or 100% secure. 
Unless expressly stated in the body of the text of the email, this email 
is not intended to form a binding contract - a list of authorised 
signatories is available from the Bangor University Finance Office.

Re: [uknof] Old routers to recycle / sell

[Nick Hilliard]

Tom Hill wrote on 27/09/2019 09:56:

Yes, yes they did. I suspect someone, somewhere will still be consuming
parts for the those boxes, and so they're likely useful to the vendor.


+ the vendor can ensure that the kit doesn't end up on the used / resale 
market.


Nick

Re: [uknof] Current State of Multicast on the Internet?

[Nick Hilliard]

Neil J. McRae wrote on 02/09/2019 17:53:

BT TV is delivered via multicast. Works lovely and we sell TV connect
for those that want their content delivered via multicast.


intra-domain multicast is alive and kicking, and has a pile of 
interesting and viable applications:  one of these is TV delivery over 
residential access connections.


Inter-domain multicast is dead and buried.

Nick

Re: [uknof] BGP VLAN from NTT - Netwise

[Nick Hilliard]

Matthew Butt - Netwise wrote on 02/09/2019 15:04:

Hi there Nick,

Apologies, but I'm not sure how else to explain this - price isnt the
issue. It wouldn’t matter whether it was £25 or £250. It is the fact
that NTTs stance is that they will only now sell BGP services
directly to the end user/network.

My question is, is anyone else experiencing the same? If not, are you
able to quote me please for a 10Mbps VLAN or dedicated port directly
onto NTTs network (or transparently through your own) with BGP and a
full table.


Then wouldn't it be possible to take the client in on a l2vpn / p2p 
ethernet connection, and hook this up to a physical cross-connect into 
the NTT service?  It's more expensive, but there's no reason that it 
wouldn't work.


Maybe part of the issue here seems to be that NTT isn't in the business 
of providing low speed transport services, e.g. anything less than 10G 
carrier.


Nick

Re: [uknof] BGP VLAN from NTT - Netwise

[Nick Hilliard]

Matthew Butt - Netwise wrote on 02/09/2019 13:59:

Thanks Brandon but that's the issue; NTT are saying that you couldn't
supply the service. Their stance is that they will only provide BGP
services now directly to the end user...our customer. My customer has
no interest in becoming a direct client of NTTs just for a single
very low traffic BGP service.
So the issue then is that the price is too high.  If so, this sounds 
like a normal business decision of trying to make a call between what's 
a requirement and what's a nice-to-have based on a direct cost.


Nick

Re: [uknof] UKNOF44 - BA Pilots' Strike

[Nick Hilliard]

The train is more comfortable if you're already in Dublin, but if anyone 
is flying to Dublin to get to UKNOF, the Aircoach 705-X is probably the 
more convenient.  Pickup is just outside the door of Arrivals in Dublin 
airport (there are stops at T1 and T2) and it's an express service to 
Glengall Street in Belfast, which is 3 minutes walk from the Assembly 
Buildings:


https://goo.gl/maps/bZFUfrphNieb5EGUA

It's £10 each way, and takes 1h50m.  Service is hourly, on the hour.

The train is available from Connolly Station (take the 747 bus and get 
out at Talbot Street, or take a taxi).  Service is every two hours, and 
it the journey is 2h10m.  €19 single or €35 return.  You can buy tickets 
at the machines in Connolly.


Nick


Martin Hannigan wrote on 23/08/2019 21:56:


The train via Dublin is also pleasant enough  if you can get on the island.

On Fri, Aug 23, 2019 at 16:41 Denesh Bhabuta - UKNOF 
mailto:den...@uknof.org.uk>> wrote:


Hi

One of our delegates posted the following on FB for anyone affected
by the BA strikes:

=
For people flying on BA to UKNOF in Belfast on September 9th who are
likely to be affected by the BALPA strike, there's currently
availability on Aer Lingus flights to Belfast City Airport.

Since BA have codeshare arrangements with Aer Lingus I was just able
to get moved onto EI935 / BA2135 (departs 15:15 LHR) just by talking
directly with BA Customer Services.
=

Regards
Denesh

On 23 Aug 2019, at 21:38, David Murray mailto:d...@davemurray.net>> wrote:


Hi,

FYI, British Airways have announced strike dates on the 9th and
10th September over UKNOF44.

-- https://www.bbc.com/news/business-49451142

Sadly the flights I had booked have just been cancelled. Will have
to seek alternative arrangements.

Hopefully not too many of you are caught up in this.

-- Dave.

Re: [uknof] RPKI ROV & Dropping of Invalids - Africa

[Nick Hilliard]

Mark Tinka wrote on 09/04/2019 13:05:
In the mean time, we are happy to answer any questions you may have 
about our deployments. Thanks.


Hi Mark, Ben,

Afrinic's rpki manifest signature expired on april 6th and wasn't fixed 
for several hours.  This may have caused validation failure during that 
period.  Couple of things:


1. Did you see any operational impact from this, or are you monitoring 
for this sort of failure on your networks?


2. the trust anchor has an expiry date some time in 2027.  Does the 
afrinic community have an opinion about trust anchor with extended 
lifetimes like this?


Nick

Re: [uknof] WHOIS Syntax Fail

[Nick Hilliard]

Not supported on standard Whois. Try this instead:

http://irrexplorer.nlnog.net/search/51551

Nick

Sent from my iWotsit.

> On 14 Aug 2018, at 09:40, James Bensley  wrote:
> 
> Morning All,
> 
> What am I doing wrong? I've had most of a coffee and still can't see
> what I'm missing.
> 
> How do I search an IRR (RIPE specifically) for the AS-SET that
> contains $ASN using native "whois" ?
> 
> For example - AS51551, I want to peer with them so I want their AS-SET
> so that I can accept their routes, and all downstream customer routes.
> I personally know it is called "AS-UPDATA" but I can't find any option
> that will let me find that without knowing it in advance, or by
> guessing it, e.g. most AS-SETs are called NETWORK-AS, AS-NETWORK,
> ASNETWORK etc.
> 
> Is this not possible within the native whois client?
> 
> Cheers,
> James.
> 

Re: [uknof] Equinix DB4

[Nick Hilliard]

Phil Bartlett wrote on 02/08/2018 11:16:

Good morning
I have a customer who is looking for 10G internet access in DB4. Can anyone 
recommend a carrier who is onnet here?

Or if you are on-net, can you provide this?


not sure which carriers are available in DB4, but there is a reasonable 
selection in DB3 and Equinix have campus fibre between the two sites.


Nick

Re: [uknof] 'White Box' switching and OS - Any experiences worth sharing?

[Nick Hilliard]

Richard Halfpenny wrote:
> but running the ports at 1G on Trident-II is a real no-no.

running the ports at 1G on Trident-II is a no-no if there is egress
pressure on the 1G ports.  If the traffic bursts on the 1G port are
predominantly ingress, then that may not be a major issue.  Most
organisations will have traffic profiles which are substantially more
heavily loaded one way or the other, so this isn't as clear-cut as
"don't ever do this".  Monitoring egress drops is always a sensible
thing to do.

Also the trident chipset will only operate in cut-thru mode if all ports
on the device are configured to be the same speed, which will impact on
buffer utilisation.

Nick

Re: [uknof] Dos Protected Transit

[Nick Hilliard]

Jospeh Waite wrote:
> Wondering if any of you can of know of anyone who can fulfil the
> following requirement for me.
> > I need 50-100mb of clean Transit with a /23 with full Ddos
> protection.
> I need this provisioned, ideally today/tomorrow.
> Based on the above would need to be from someone in Star Suite in
> THN, as were looking to put the customer in our rack there, and we
> can get the xconnect in quickly, I can go down tonight and run the
> cable!

Can you pay up front in used twenties?

Nick

Re: [uknof] GCSC critical infrastructure protection questions: your input needed.

[Nick Hilliard]

Malcolm Hutty wrote:
> I'm not going to judge the specific work Bill's Working Group is doing,
> as I'm not sufficiently sighted. But on the broader issue of whether
> this /type/ of engagement is advisable, and Nick's challenge to it, I
> would give a qualified "Yes": of course I recognise the risks, but
> nonetheless it is in our community's long term interests to engage.

Agreed that it is important to engage with legal and regulatory bodies.
 The issue is that legislation tends to be a rather blunt instrument and
as you and Kurtis point out, it is very important to be careful about
language, not least because once something is enshrined in laws or
international treaties, the language becomes embedded and very difficult
to change afterwards.

Regarding Bill's suggestion about excluding civilian infrastructure from
"cyber-warfare", it would be useful and probably productive to see this
discussed at the UN, but am not sure that an online poll is going to do
justice to the sort of nuance necessary to provide informed support for
what he's proposing.

Nick

Re: [uknof] GCSC critical infrastructure protection questions: your input needed.

[Nick Hilliard]

Bill Woodcock wrote:
> One of PCH’s long-term efforts has been to encourage governments to 
> restrict their use of offensive cyber attacks against civilian 
> networks. We've successfully gotten that effort out of the U.N., 
> where it was floundering, and into a well-supported stand-alone 
> commission.  It’s being taken seriously by governments, and will be 
> one of the main topics under discussion at the Global Conference on 
> Cyberspace in Delhi next week.

couple of comments:

- the term "critical infrastructure" has a specific legal meaning in the
European Union, and may be a good idea to either change the terminology
here or else make it clear that when the UN talks about "critical
infrastructure", it will mean something different to what the European
Union means.

- regarding IXPs specifically, there is little to no basis for
categorising them the vast majority of them as "critical" on the basis
that if you turn an IXP off, or if it fails due to technical or
administrative reasons, traffic will generally re-route somewhere else
within BGP dead-time seconds and most people will probably not even
notice.  This isn't the case with some larger IXPs, but the vast
majority of them can fail in service, you get a short blip, and life
carries on.

> But that’s a distraction from the issue: do we think
> [hospitals|schools|the power grid|IXPs|root servers|whatever] should
> not be cyber-attacked by governments, or are we just fine with them
> being attacked?

- once organisations gain political protection status of one form or
another, they also attract legal / regulatory obligations.  So the
question for e.g. IXPs should be reframed as: given that most IXPs are
not in fact critical to the operation of the Internet in any meaningful
sense of the word (i.e. the world can continue on without them), is the
attraction of gaining a mention on a UN declaration worth the cost of
the regulatory obligations that will inevitably ensue?

Nick

Re: [uknof] Article: "IPv6 update: A look at the security and privacy improvements"

[Nick Hilliard]

Paul Mansfield wrote:
> the web page demanded an email address in order to read it.

er, no it didn't - the entire article text was available if you scrolled
down.

Nick

Re: [uknof] bulk buying network cables with a possibility of bulk returns?

[Nick Hilliard]

Or do a rough assessment of what is needed?  Cables aren't expensive in
bulk, and a small stock is always useful to have.

Nick

Simon Gunton wrote:
> Just eBay them in some large batches?
> 
> Simon
> 
> On 8 Jun 2017 8:34 pm, "Jack Kay" >
> wrote:
> 
> Not sure about returning unused..
> 
> I bulk buy our cables from cablenet.co.uk 
> 
> 
>> On 8 Jun 2017, at 17:15, Paul Mansfield
>> >
>> wrote:
>>
>> thanks to someone for suggesting off-list to try CableMonkey.co.uk
>> .
>> hopefully we can get something in place before the office move in just
>> a month's time!
>>
> 

Re: [uknof] Example of total DC loss

[Nick Hilliard]

Neil J. McRae wrote:
> That telehouse one below was 1997 I was in the building - it was bad but
> amusing watching the telehouse ops guys running around like headless
> chickens!

from personal experience, I can say that the silence which ensues from a
power failure in a data centre is seriously creepy.

Also, due respects to anyone caught in the situation where the entire
show has derailed.  The term "blind panic" doesn't do justice to the
situation.

Nick

Re: [uknof] US based cisco distributor

[Nick Hilliard]

Tim Bray wrote:
> A lot of companies can't cope with price changes.  So they have probably
> just whacked up the price to makesure they don't lose out if prices go
> up again.
> 
> I'm surprised you can't just buy from a UK cisco distributor.  Expect to
> pay some import duty and VAT on kit coming from the US.

most larger networking kit suppliers can quote in US$, so if you do
this, you will not end up losing out due to exchange-rate price gouging
in the supply chain, even if you still end up paying the brexit premium.

Nick

Re: [uknof] US based cisco distributor

[Nick Hilliard]

Neil J. McRae wrote:
> Does that apply to software licensing? 

I don't know, but in the absence of anything to say to the contrary,
would suspect so.

Nick

Re: [uknof] US based cisco distributor

[Nick Hilliard]

Chris Russell wrote:
>  IIRC - if you are any form of Cisco Partner, you can only buy from
> Cisco Official Refurb Channels and Cisco Official Disties within your
> region.

the Levis vs Tesco ECJ ruling may be relevant in this case.

Nick

Re: [uknof] RIPE policy change for new LIR formation

[Nick Hilliard]

Paul Thornton wrote:
> I'm locked into something of a battle of wills with the RIPE NCC at the
> moment, trying to establish a new LIR.  This is something I've done for
> UK companies plenty of times in the past with no problems at all.
> 
> Apparently, they now[1] reject certificates of registration that are
> more than two years old as "too old".

Seems like a peculiar misunderstanding of british law, and that of
several other jurisdictions in the RIPE service region. Did you ask the
new-lir people for the RIPE NCC's formal legal position regarding both
this change, and how it relates to documents produced by Companies House?

It's the same situation in IE: registration documents issued by the
Companies Registration Office are legitimate as long as the company
still legally exists (which can be checked online).  They will not issue
a new document unless there is a reason in irish law to do so, and would
react to any request for an updated version with a degree of bemused
disinterest that would make any bureaucrat's heart flutter with admiration.

Nick

Re: [uknof] MTP Single Mode cables - Wanted

[Nick Hilliard]

Tom Hill wrote:
> Answer: because the "short reach" optics are cheaper. But why do they
> exist if the "long reach" ones work over short distances?

this comes down to whether SMF transceivers are inherently more
expensive than MMF, or whether they're more expensive because they're
produced in lower quantities and don't have the same economy of scale.

If the latter, the entire situation is chicken-and-egg which is
benefiting exactly no-one.

Nick

Re: [uknof] Urgently need attenuators

[Nick Hilliard]

Charlie Boisseau wrote:
> If anyone has any 5db or 10db attenuators sitting in a spares box
> somewhere in London, I could do with a handful.  We’re having to rush
> a new mux into our THN-HEX span tomorrow to connect up our new DDoS
> scrubbing kit to the rest of our network.  Some bugger keeps DoS’ing
> us and it’s getting quite tiresome!

You may also not need proper attenuators, depending on the recommended
receive power levels.  It's worth looking up the spec sheets for
information on what will work and what won't.

If you are completely stuck but have a light meter, there's always the
wrap-the-patch-lead-around-a-pencil trick.  If it's taped in place and
measured carefully for attenuation, it can be useful as a
rough-and-ready mechanism to get you out of a hole while waiting for
delivery of proper attenuators.

Nick

Re: [uknof] EU IXP Pricing

[Nick Hilliard]

Tom Hill wrote:
> IXP mbit/sec cost:
> https://docs.google.com/spreadsheets/d/18ztPX_ysWYqEhJlf2SKQQsTNRbkwoxPSfaC6ScEZAG8/edit#gid=0

Dave's preso at GPF was intended to refer specifically to the largest 4
IXPs in europe rather than to the IXP ecosystem as a whole.

The costings denomination in US$ at today's exchange rate was surprising
for two reasons: first, many if not most US companies who get
connectivity at european IXPs will both take in their revenue and foot
the bill in euros or UK£, not US$, thereby insulating the company
against currency fluctuations.  Secondly, there was a 30% drop in the €
and £ compared to the US$ over the period shown on his graphs.  In other
words, a 30% drop in effective pricing has been omitted from the graphs.
 If you take this into account, AMS-IX's pricing drops are
proportionally larger than transit drops and the core argument of the
talk is weakened.

The reason given for making this decision was because infrastructure /
equipment costs are generally based on US$.  That's fine except that the
primary cost of running an IXP in europe has never been related to
hardware costs - capex generally makes up a surprisingly small amount of
the overall expenditure of an IXP.  The #1 cost of most IXPs is relating
to hiring people.  This is often overlooked in the US because most US
IXPs are run either on a voluntary basis (i.e. unpaid or else well below
market rates), or else owned/run by data centres, who run them as
inhouse value-adds.  There are some exceptions to this, but not many.
European IXPs are mostly independent, self-funded organisations which
usually pay reasonable rates to retain staff.

Obviously, it's up to any organisation how they want to handle their
staffing requirements, but there is nothing stopping anyone from running
an IXP in europe using donated hardware and volunteers chipping in a
hand or having staff seconded from their primary jobs, and where the
equipment is located in a single hosting facility with no inter-site
connectivity.  This would certainly cause prices to drop, no doubt about it.

The other aspect that was omitted from this talk is that some of the
larger European IXPs do stuff which is unrelated to shifting bits
between switch ports.  E.g. public advocacy (LINX), DNS root servers
(Netnod).  I'm not going to pretend to be a neutral observer in this:
this is important work.  If the internet community doesn't step up to
sustain efforts against the tsunami of regulatory stupidity it
constantly faces, we will end up being ruled by an unholy triad of the
ITU, the european commish and (in the case of the uk) a wholly
unrestrained Home Office.

It's understandable that some people would prefer just to pay for
bit-shifting.  If that's what they want, there is nothing to stop them
from voting with their wallets and moving their traffic elsewhere: it's
a free and fully unregulated market.

> 5) With the exception of INEX, all the prices used are publicly available

INEX's pricing is publicly available.  The google spreadsheet was
updated earlier with the correct url.

Nick
INEX CTO hat on

Re: [uknof] IPv6 usage explosion

[Nick Hilliard]

Mark Tinka wrote:
> On 24/May/16 11:01, Nick Hilliard wrote:
>> double-triple-nat?
>>
>> You know I'm not joking.
> 
> You're a braver man than I am...

I'm certainly not advocating it, but it is what people will do in order
to save themselves from getting over them hump of moving to ipv6.

Nick

Re: [uknof] IPv6 usage explosion

[Nick Hilliard]

Mark Tinka wrote:
> Well, when you can't assign anymore IPv4 addresses to your new
> customers, what will you do?

double-triple-nat?

You know I'm not joking.

Nick

Re: [uknof] Mikrotik as Service Provider Router

[Nick Hilliard]

Adrian Bolster wrote:
> Oure whole core is Mikrotik, no Juniper or Brocade in sight! We're
> running 3 IPv4 and 2 IPv6 eBGP sessions over 2 Mikrotik Routerboards, 2
> 1gibt/s point to point and 1 10gbit/s to a different provider, each with
> a full routing table and they don't even break a sweat.

on larger network cores, it becomes an issue that ospfv3 on routeros
doesn't support prefixes with the LA-bit set (section A.4.1.1 of
rfc5340).  This is the sort of route that you get if you inject a
Loopback address into an ospfv3 area on junos or ios/xr.  There's no
warning or anything - mikrotiks will silently drop these routes without
logging them, which is an extraordinary thing to do.  Also, routeros
doesn't support recursive routing on ipv6.  These two problems mean that
ipv6 routing with bgp/ospfv3 is pretty much unusable on anything other
than small networks with a handful of routers.

> http://forum.mikrotik.com/viewtopic.php?f=14=51124=82ee66add2fee4269874516870713e40=50#p518060

Nick

Re: [uknof] Virginmedia - observation

[Nick Hilliard]

wand...@yahoo.co.uk wrote:
> how did netflix and google learn
> that his PI space has a direct route to VM, obviously you could pick it
> up from the BGP tables, but are they really looking?

yes, they actively look for better paths (lower latency + packet loss).
 Mostly this is related to the path between the nearest CDN node and the
DNS resolver that the end user is using.  For this reason, it's a good
idea to use in-house DNS resolvers for customer and it's a bad idea to
have customers use 8.8.8.8, opendns and other public servers.

If the BGP network you're talking about is concerned by the cost of
doing this over VM / the tier2, they should look at whether a connection
to an IXP would reduce their costs.

Nick

Re: [uknof] Juniper SRX as PE Node Problem

[Nick Hilliard]

Paul Bone wrote:
> We are quite a small service provider and have just expanded our MPLS
> and the issue was not seen before - is it common to use an anycast
> address as default route destination then?

No idea how common it is in the wider context, but I've used it
routinely for some years and with a small number of exceptions (e.g.
Miktotik ipv6 and other systems which don't support recursive route
resolution), it works extremely well.

> Interestingly, the ME3600 PE nodes I have are actually picking the
> nearest RR for default so there appears to be a difference between
> IOS and Junos.

yeah, junos handles mpls route resolution differently to ios.

Saku Ytti's advice is still good though: if you don't advertise default
routes, you can avoid an entire category of problems.

Nick

Re: [uknof] Juniper SRX as PE Node Problem

[Nick Hilliard]

Paul Bone wrote:
> The problem I have is that the SRX240 is receiving the default route
> from both route reflectors but is actually preferring and forwarding
> traffic to the route reflector with the lowest router ID (show route
> detail confirms this) and ignoring the underlying IGP metrics from the
> global OSPF table.
> 
> This is causing sub-optimal routing of traffic.

This approach works well:

http://blog.ip.fi/2011/08/when-should-you-advertise-default-route.html

Nick

Re: [uknof] Fwd: internet connection record

[Nick Hilliard]

Neil J. McRae wrote:
> Not really, we aren't blocking anything here

Sorry, what??

Nick

Re: [uknof] BGP configuration best practices from ANSSI and others

[Nick Hilliard]

On 17/12/2015 13:51, Matthew Walster wrote:
> 1. Don't use uRPF on a peering router, and if you are, loose mode seems
> pretty dumb on a full transit router.

on system which tie null0 into the urpf mechanism, this is a good means of
implementing s/rtbh.  Strict urpf at a peering exchange is obviously
bananas, unless you're a leaf network or if you hate your customers.  Fine
at the customer edge; useless everywhere else.

> 2. Those are some really bad filtering examples, and if you just used it as
> a factsheet there are missing entries which you may falsely assume don't
> matter. Filtering all >/48 v6 prefixes seems a little odd too -- why that 
> size?

same as /24 for ipv4: it stops people who accidentally leak their entire
interior routing table from causing damage to everyone else.

> 3. TCP MD5 for BGP. They say it's not cryptographically secure, then go on
> to say you should use a strong password. Which? How about just using the
> MD5 password as a prevention of fat-finger incidents as I imagine 90% of
> people do (the rest assuming that it provides a level of security it
> doesn't provide)?

md5 for bgp is a good idea at IXPs.  The reason why is that IP addresses
are re-used from time to time and unless you clean out your old peering
sessions regularly, you can potentially end up accidentally peering with
chancers who spoof old members' ASNs.  Otherwise they're a bit useless, but
hey, if your security policy demands them, there's no reason to have a
fight about it.  They're harmless.

Nick

Re: [uknof] BGP configuration best practices from ANSSI and others

[Nick Hilliard]

I vote for Matthew.  He who makes the complaint fixes the problem.

Nick

On 17/12/2015 14:18, Peter Knapp wrote:
> So whose volunteering to write the update?!
> 
> Peter Knapp
>  
> 
> 
> -Original Message-
> From: uknof [mailto:uknof-boun...@lists.uknof.org.uk] On Behalf Of Nick 
> Hilliard
> Sent: 17 December 2015 14:16
> To: Matthew Walster; Gavin Henry
> Cc: uk...@uknof.org.uk
> Subject: Re: [uknof] BGP configuration best practices from ANSSI and others
> 
> On 17/12/2015 13:51, Matthew Walster wrote:
>> 1. Don't use uRPF on a peering router, and if you are, loose mode 
>> seems pretty dumb on a full transit router.
> 
> on system which tie null0 into the urpf mechanism, this is a good means of 
> implementing s/rtbh.  Strict urpf at a peering exchange is obviously bananas, 
> unless you're a leaf network or if you hate your customers.  Fine at the 
> customer edge; useless everywhere else.
> 
>> 2. Those are some really bad filtering examples, and if you just used 
>> it as a factsheet there are missing entries which you may falsely 
>> assume don't matter. Filtering all >/48 v6 prefixes seems a little odd too 
>> -- why that size?
> 
> same as /24 for ipv4: it stops people who accidentally leak their entire 
> interior routing table from causing damage to everyone else.
> 
>> 3. TCP MD5 for BGP. They say it's not cryptographically secure, then 
>> go on to say you should use a strong password. Which? How about just 
>> using the
>> MD5 password as a prevention of fat-finger incidents as I imagine 90% 
>> of people do (the rest assuming that it provides a level of security 
>> it doesn't provide)?
> 
> md5 for bgp is a good idea at IXPs.  The reason why is that IP addresses are 
> re-used from time to time and unless you clean out your old peering sessions 
> regularly, you can potentially end up accidentally peering with chancers who 
> spoof old members' ASNs.  Otherwise they're a bit useless, but hey, if your 
> security policy demands them, there's no reason to have a fight about it.  
> They're harmless.
> 
> Nick
> 
> 
> 

Re: [uknof] reliably detecting a bridge over ethernet?

[Nick Hilliard]

On 15/12/2015 13:21, Alex Brooks wrote:
> I know that Bradford Networks will sell you a system that does this
> automatically with HP and Cisco gear.  I don't know how it actually
> 'works' under the hood in detail, but know that it involves an LDAP
> directory and an SNMP trap.

that probably works by either 802.1x or else locking down the mac address
and issuing traps when different mac addresses are seen on the port.  This
is a different problem set to detecting whether a point-to-point link has
intermediate bridges.

Nick

Re: [uknof] AS Path Filters and Regex

[Nick Hilliard]

On 31/10/2015 08:19, James Bensley wrote:
> Six of one, half a dozen of the other

wait now, step back a sec.

On the internet, we care about reachability.  Reachability is determined by
prefixes.  So by inference we care about whether prefixes are legit or not,
for some definition of "legit".

The AS path is not much more than the distance vector metric for eBGP.  The
only thing you're using the AS path for is to compare the network distance
across multiple upstreams/peers.

If there's junk in the as path of one form or another - e.g. weird confed
stuff, private intermediate ASNs, upstream monopoly providers doing strange
things with customer ASNs, asn typos, as23456, etc - does this make a
meaningful statement about the legitimacy of the prefix?  I'd say that
nuking reachability because an AS path is displeasing was a pretty
arbitrary approach to handling reachability hygiene because you have no way
of knowing why the AS path is like that and whether that actually means
anything.

Bear in mind that the leaf ASN loses control of the as path the moment they
announce their prefix to their peers / upstreams.  Their upstream has full
control to update / insert / delete anything in there that they please.

I've been at the receiving end of monopoly upstreams doing crazybad dumb
stuff with as paths and it's not pretty.  It doesn't reflect badly on the
legitimacy of the prefix in any way - it's merely a statement that the
intermediate network is clueless, but was in the circumstances the only
thing which stopped the leaf network from going completely dark for days at
a time.

If you're going to do this, I'd suggest you measure what prefixes you're
cutting out first and try to make some judgement about whether they are
legitimate from some other point of view.  Maybe it's not going to matter a
whole lot, but I'd suspect that you're fixing the wrong problem in terms of
tackling prefix origination legitimacy, and in some - perhaps many - cases,
you're going to end up punishing leaf networks for third party stupidity
which they cannot control.

This is apart from ruining your convergence completion time.

Nick

Re: [uknof] AS Path Filters and Regex

[Nick Hilliard]

On 30/10/2015 16:57, James Bensley wrote:
> What do others have, what have I missed?

the asn32 filter can be written as "_42_", or perhaps "_42[0-9]{8}_"

TBH, I'd question the value of filtering weird asns.  What matters is
filtering out weird prefixes.  If you filter out weird ASNs, all you're
doing is chewing up the CPU on your RP.

Nick

Re: [uknof] NETCONF and device health stats

[Nick Hilliard]

On 25/09/2015 14:14, Neil J. McRae wrote:
> On the network side each individual atom is simple enough to automate
> (but rarely provides any value) but the area we have completely failed
> as an industry is pulling those atoms together as a set of services or a
> capability outcome, mostly down to our lack of ambition to change how we
> create and operate networks (interconnect and peering are top of the
> list for change in my view).

it's easy enough to complain about tools and constructs not being there,
but there's another fundamental problem, namely that the config semantic
requirements of the network are complicated relative to the simplicity of
the config atoms.  Mixing in different language interpretations from
different vendors adds to the mess.

Nick

Re: [uknof] NETCONF and device health stats

[Nick Hilliard]

On 25/09/2015 09:46, James Bensley wrote:
> I'm looking to build a tool that is vendor agnostic

Along the lines of e.g. https://github.com/spotify/napalm

?

Nick

Re: [uknof] 10gb switch

[Nick Hilliard]

On 18/09/2015 13:29, Maria Blackmore wrote:
> What does throughput and latency look like in the real world?

if they're trident/T+/T2 chipsets, then they will do line rate on all ports
with small packets.  Latency is dependent on forwarding mode, i.e. slightly
lower for cut-thru than for store-n-forward.  afair, the cut-thru marketing
latency on T2 is 500ns.

Bear in mind that linux is only the control plane operating system and has
nothing to do with the underlying forwarding mechanism.

Nick

Re: [uknof] Layer 2 from Ireland to london

[Nick Hilliard]

On 10/04/2015 18:17, Rod Beck wrote:
 A single protected circuit is easier.

easier for what?

You end up paying 2x for a mechanism which still has a single point of
failure designed in to your underlying network infrastructure - namely the
routers connected to each end - while completely failing to get any
potential advantage from the wave which isn't being used.  This is a silly
way of handling resiliency in an IP world because IP networks assume that
the underlying network infrastructure doesn't work like this.
Circuit-switched networks do, but the vast majority of the world's traffic
runs on ip these days and will continue to do so in future.

All the while, you'll end up paying exorbitant charges for network
termination kit because equipment vendors know that they can royally gouge
people for STM capable kit compared to e.g. 1G or 10G router ports.  It's
even worse when you get into multiple wave service because your scaling
costs go up by 2x more than necessary and you completely lose out on
economy of scale.

If you want actual resiliency at a reasonable cost point, get multiple
unprotected waves from different providers and run bfd + mpls FRR.
Protected circuits are a relic from a bygone era with increasingly little
relevance in today's networks.

Nick

Re: [uknof] BGP Communities with 32-bit ASN

[Nick Hilliard]

On 16/03/2015 18:01, Catalin Dominte wrote:
 ... which will break if you start providing transit and your
 downstreams expect bgp community support.
 
 by expect community support do you mean:
 1: passing on to the customers the communities received from the transit
 providers or 
 2: providing your own communities downstream to the customers?
 
 both of those fit the community support description :)

#1 is pretty standard and will work fine.

#2 means that you will need to use unregistered numbers for the global
administrator part of the bgp community.  If you're ok with using
unregistered numbers in this sort of situation, it will work.  Personally I
think it's pretty ghetto for transit service and if a transit provider were
to present me with this as an option, I'd use a different provider.

Nick

Re: [uknof] BGP Communities with 32-bit ASN

[Nick Hilliard]

On 16/03/2015 17:28, Catalin Dominte wrote:
 The way I do it is use an internal community for my policies, and then
 overwrite it when I hand it over to the Transit provider, so it matches the
 upstream policy. 
 
 Far easier than renumbering the AS number across the live network :)

... which will break if you start providing transit and your downstreams
expect bgp community support.

Nick

Re: [uknof] Interception of communications and equipment interference consultation

[Nick Hilliard]

On 08/02/2015 18:56, Rod Beck wrote:
 How is terrorism defined?

anything we don't like.

Nick

Re: [uknof] Stocking of spares?

[Nick Hilliard]

On 16/01/2015 15:24, Ash Scott wrote:
 How do you manage your spares and keep the spare count true to the actual
 count?

Regular and public floggings for infractions.

There's no easy way to do this, and we're all guilty of sneaking stuff out
of stockrooms from time to time (just the once, honest, no rly).
Ultimately, this is a management problem rather than a technical problem.

Nick

Re: [uknof] Stocking of spares?

[Nick Hilliard]

On 16/01/2015 15:43, Gord Slater wrote:
 the stock areas will think twice because of that, I'm sure. Of course that
 assumes that all thieves actually think lol

I should clarify that my previous email referred to sneaking stuff out of
the stock room for legitimate company purposes and just not bothering to
update the stock lists because it's a pain in the bum and we're all a bit
lazy about filling forms and ticking boxes.  I.e. not pilfery / theft.

If there is a theft problem, that is an entirely different situation which
required legal and/or professional HR advice.  At the very least, you will
need formal procedures in place to handle asset theft, as in the event of
people being found out, it will normally mean dismissal if not criminal
proceedings.

Nick

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

[Nick Hilliard]

On 16/09/2014 16:15, Leo Vegoda wrote:
 I would be surprised if Google was announcing APNIC's research prefixes
 without a suitable LOA. 

http://www.merit.edu/mail.archives/nanog/msg06402.html

Nick

Re: [uknof] Belfast

[Nick Hilliard]

On 16/09/2014 20:19, Tom Hill wrote:
 On 15/09/14 10:39, Donal Cunningham wrote:
 I propose a variant on Godwin's Law (I suggest Hilliard's Law)
 which states that As an online discussion grows longer, the
 probability of Fr. Ted being quoted approaches 1.
 
 Motion seconded.

to be fair, the collected wisdom of Fr Ted far surpasses anything which
might pass as political discourse on either of these two sorry islands.

Nick

Re: [uknof] Belfast

[Nick Hilliard]

On 14/09/2014 12:21, Mark Blackman wrote:
 Does “Britain unambiguously refer to “Great Britain” or “the British
 Isles” or “the United Kingdom”?

That would be an ecumenical matter now, Fr. Ted.

Nick

Re: [uknof] Belfast

[Nick Hilliard]

On 11/09/2014 11:30, David Farrell wrote:

On 11/09/2014 09:39, Nick Hilliard wrote:


...except for the anachronistic british isles thing.

North-West European Archipelago?


we should have competing marches to see who has the better name.  That's 
sure to settle the issue.


Nick

Re: [uknof] Loopholes, Ethics and Business Acumen with Ofcom and RIPE

[Nick Hilliard]

On 05/09/2014 12:11, Gavin Henry wrote:

On 5 September 2014 11:50, Neil J. McRae n...@domino.org wrote:

You can¹t please all of the people all of the time.


Yep, that's where I got to. Didn't want to come across ranty.


everyone is well aware of the RIPE /22 loophole.  It costs a average of 
€3.66 per address + overheads, but is labour intensive.  If you feel you 
can fix this without breaking other things, by all means submit a proposal 
to one of the ripe mailing lists.


Nick

Re: [uknof] Openreach Modem Issue

[Nick Hilliard]

On 27/08/2014 10:28, Richard Halfpenny wrote:
 Annoyingly the ECI B-Focus has Ethernet autonegotiation issues with some
 kit, notably Mikrotik RB2011's and RB951G's :(

It would be really nice if Mikrotik supported hard-wiring ethernet
settings, so that you could get around this sort of problem.

Nick

Re: [uknof] Openreach Modem Issue

[Nick Hilliard]

On 27/08/2014 10:36, Stuart Howlette wrote:
 /interface ethernet set auto-negotation=no speed=SPEED duplex=DUPLEX
 
 Unless I'm missing something, that works fine

this is not supported across all microtik kit unfortunately, particularly
on gigabit ports.

Nick

Re: [uknof] Dublin Connectivity

[Nick Hilliard]

On 12/08/2014 10:41, Nick Ryce wrote:
 Can anyone recommend  an ISP in Dublin to provide access services that
 could be back hauled to THN and handed over at L2?

what sort of access services are you talking about?

Nick

Re: [uknof] Emergency Cisco networking help in New York?

[Nick Hilliard]

On 09/05/2014 14:47, William Salt wrote:
 Does anyone know anyone/companies that have an engineer to send out?

maybe ask for remote hands in nyc on the NANOG mailing list?

Nick

Re: [uknof] Guestimating fibre distances and RTT

[Nick Hilliard]

On 29/04/2014 19:21, James Bensley wrote:
 What is the general rule of thumb when guestimating round trip time
 for new fibre installs?

1ms per 100km of fibre cable. -ish.

Nick

Re: [uknof] Possible Prefix Hijack - BGPmon alert - what to do?

[Nick Hilliard]

On 02/04/2014 21:39, Gavin Henry wrote:
 Looking for some tips. What can I do about this? First time I've seen
 one.

Nothing to be done.  They'll eventually stop doing it.  FWIW, this is
affecting ~320,000 prefixes on the DFZ according to bgpmon.

Updates on https://twitter.com/bgpmon/

Nick

Re: [uknof] Openbgpd for BGP peering with LINX and media converter requirement

[Nick Hilliard]

On 26/03/2014 22:41, Neil J. McRae wrote:
 Which is great - but in my view it's a path to pain for a variety of
 reasons. Can you keep plugging in as many of my competitors like this
 please? :)

Neil, I'm puzzled as to how you think remote ixp peering might work, if not
over physical/virtual l2 connections?

Nick

Re: [uknof] Openbgpd for BGP peering with LINX and media converter requirement

[Nick Hilliard]

On 27/03/2014 12:00, Neil J. McRae wrote:
 If I need scale I can get a circuit and put a router on site and get a
 bunch of other benefits and then get the real benefits of being at an IXP
 in whole rather than virtually, with better QoE and a lot more certainty
 about shared fates. YMMV.

the same argument can be made about using PNIs instead of IXPs for
interconnection.

Provisioned properly, most service providers aren't going to see much of a
practical difference between connecting to their IXP over a switch and
connecting directly with a router.  For a larger organisations, it makes
less sense to put a switch in the middle but let's face it, most
organisations which connect to IXPs aren't giants.

So yes: YMMV.  Mileage varies quite a good chunk across the sort of
provider profile you see at IXPs.  Don't write off something which makes
plenty of sense for a small organisation just because it makes almost none
for a large one.

Nick

Re: [uknof] Openbgpd for BGP peering with LINX and media converter requirement

[Nick Hilliard]

On 25/03/2014 16:20, Randhir Prakash wrote:
 This is my first post as a community member !
 
 I wish to use a Openbgpd using OpenBSD box to connect and peer with LINX
 members.

you will need use an ethernet card where the OpenBSD driver supports
interrupt mitigation.  Otherwise, the box will be hammered when the packet
load increases.

Nick

Re: [uknof] Rack Recommendations

[Nick Hilliard]

On 27/02/2014 13:15, Mike Hughes wrote:
 One of my out and out pet hates is circuits delivered as just flying tails
 with plugs on the end, left hanging in  a hapazard manner around the
 cabinet, with no proper termination or strain relief.

nothing more depressing than a colocation centre trying to explain why this
is a good idea.  :-(

Nick

Re: [uknof] DNS/NTP censured, a solution !

[Nick Hilliard]

On 14/02/2014 11:54, Giles Davis wrote:
 Keith Mitchell wrote:
 Universal BCP38 source address validation is needed more badly then ever :-(
   
 It really is.

It really is, but bear in mind that a single 1GE connection with no urpf
can be used to create ~250-300G of backscatter traffic.

This means that there's only a requirement to have a single unscrupulous or
incompetent ISP with GE in the world to allow a devastating DoS to be
launched against anyone anywhere.

Nick

Re: [uknof] Media Converters

[Nick Hilliard]

On 11/10/2013 15:51, Peter Knapp wrote:
 How about these with the frame you can see in the back of the picture.
 We have them where needs must and have never had any bother.

Lucky you.  I've trouble with Allied Telesis converters :-(

Nick