Re: [uknof] Openreach OSA Channel Numbering

[Rob Evans]

Hi,

> https://www.openreach.co.uk/cpportal/content/dam/cpportal/public/images-and-documents/home/help-and-support/sins/documents/SIN_514.pdf

Just to note there are two products, OSA Filter Connect, which uses Adva 
equipment and is documented in SIN 489, then OSEA Filter Connect, which uses 
Ciena equipment and is documented in SIN514.

Cheers,
Rob

Re: [uknof] Openreach OSA Channel Numbering

[Rob Evans]

Hi,

> Can anyone point me in the right direction to understand what DWDM channels I 
> can put over an Openreach OSA?

Assuming you mean OSA Filter Connect, then it’s documented in SIN489 — 
obviously it depends on the filter module and single/dual fibre.

Cheers,
Rob

Re: [uknof] I want fibre!!!

[Rob Evans]

Hi,

> I went a walkaround for work purposes with an OR engineer a while back in the 
> city centre, he was looking for the T-node which wasn't in the place 
> documented so had to pop a few lids.  Every time there were other provider 
> fibres in there, and he tutted and grumbled that while everyone else was 
> "allowed to use" OR ducts, they were not permitted to use anyone else's.  
> This seemed a little odd to me at the time, since if everyone could use OR 
> ducts generally, there surely wouldn't be the need for so much digging.  So 
> perhaps this grant is only in certain areas, like city centres.



Cheers,
Rob

Re: [uknof] BGP attributes 20 & 21 in the DFZ

[Rob Evans]

Hi,

> Prefix 144.124.0.0/16 from origin ASN(s) AS786 (JANET) has attribute(s) {20}
> Prefix 147.143.0.0/16 from origin ASN(s) AS786 (JANET) has attribute(s) {20}
> Prefix 137.44.0.0/16 from origin ASN(s) AS786 (JANET) has attribute(s) {20}
> Prefix 159.86.128.0/18 from origin ASN(s) AS786 (JANET) has attribute(s) {20}
> Prefix 193.39.172.0/22 from origin ASN(s) AS786 (JANET) has attribute(s) {20}
> Prefix 46.254.200.0/21 from origin ASN(s) AS786 (JANET) has attribute(s) {20}
> Prefix 92.245.224.0/19 from origin ASN(s) AS786 (JANET) has attribute(s) {20}

I have my suspicions about these.  The part of the network they originate in is 
not managed directly by us, and there were some shenanigans involved to get 
multicast working at one point in history (attribute 20 is a Cisco solution for 
multicast in MPLS).  I’ll follow up.

Rob

Re: [uknof] Age Old Question - Juniper vs Cisco

[Rob Evans]

> Can anyone give a full difference between the MX204, MX204-IR and MX204-R, am 
> I correct in assuming the MX204-R is the router with no restrictions.

Assuming it is the same as the linecards, IR would be limited to 32 L3VPNs.

We have a reasonable number of MX960s with MPC7Es, but I’d definitely recommend 
picking the right size of box for your requirements, there’s a fairly hefty 
penalty for the chassis-based systems.

Cheers,
Rob

Re: [uknof] UK interconnects and Brexit

[Rob Evans]

Hi,


Sorry to bring up the B word but is Brexit causing UK operators to
have to renegotiate transit and peering arrangements with their
continental counterparts?


Transit and peering not so much as we do most of it in the UK so getting 
the packet passports is their problem. :-)


We’ve been through a lot of prep over the last couple of years on 
supply chains and spares holdings, and trying to reduce the probability 
of our support contractors going “yes, the nearest replacement card 
we’ve got for your P1 fault is in Amsterdam, it will be with you in 
four hours^H^H^H^H^Hdays^H^H^H^Hweeks.”


Plus work on our relationship with the pan-European R network, which 
is co-funded by the EC.



Looking at this: https://www.submarinecablemap.com/
I imagine a fair amount of connectivity into western, central and
eastern Europe will be dependent on connections via the European
Union.


It’s also a concern for our Irish counterparts who would prefer their 
traffic to the rest of Europe not to transit the non-EU UK.  
Unfortunately there’s little in the way of infrastructure to avoid it 
at the moment…


Cheers,
Rob

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

[Rob Evans]

ISP B is just starting out and has to pay RIPE fees and get on a waiting list 
for a /24. All the while being unable to provide IPv4 services.


Or go to a broker and buy a /24 or whatever from a network that can
make do with fewer addresses.


The good news at the moment is that the RIPE waiting list is quite short:



Cheers,
Rob

Re: [uknof] Public IPv4 Addresses Required

[Rob Evans]

Hi,

> One of which is the ridiculous amount of IPv4 addresses historically
> assigned to some educational institutions by JISC :-)

Most Universities have addresses directly allocated to them from days
that pre-date the Regional Internet Registries (especially the /16s).

> Public IPv4 addresses direct on PCs, Mobile Devices on Guest Wifi Networks,
> internal Printers I have seen this with my own eyes.

Those sound like features, and how the Internet was supposed to work.

Cheers,
Rob

Re: [uknof] UK IPv6 Council round table meeting, 28th April

[Rob Evans]

Hi,

> The challenge is having meaningful and non-chaotic discussions, which is 
> easier with a smaller sized audience.

With all online events, ‘non-chaotic’ means (IMHO) moderated by
someone other than the speaker (come to think of it, that applies to
in-person events just as much).

Zoom has the ‘raise hand’ function which means the moderator can come
to each statement-disguised-as-a-question in turn.

At the IETF plenary a couple of weeks back people just put ‘+q’ in the
Webex chat box to add themselves to the queue.

If we did get more people than average participating, that would be a
pleasant surprise.

Cheers,
Rob

[uknof] Fwd: Peter Kirstein

[Rob Evans]

All,

There will be those on this list that knew Peter, either first-hand, or 
through hearing him speak at an event.  As the email below says far 
better than I could, he was instrumental in connecting UCL, and 
eventually the UK, to the Internet, and even when I started working in 
R networking his work was still evident.


Unfortunately he passed away at home yesterday morning as a result of a 
brain cancer.


Rob



 Forwarded Message 
Subject: Peter Kirstein
Date: Thu, 9 Jan 2020 08:15:51 +
From: Stephen Hailes 
Reply-To: s.hai...@cs.ucl.ac.uk
To: n...@jiscmail.ac.uk

It is with great sadness that I have to have to announce the death of 
Professor Peter Kirstein CBE FREng DFBCS FIET FInstP, an Internet 
pioneer and the founding head of the Department of Computer Science at 
UCL. Peter died yesterday morning (8th January) as a consequence of the 
brain cancer with which he had been diagnosed in the latter part of last 
year.


Peter has come to be known as the father of the European Internet, both 
because he was instrumental in establishing the first connection to the 
ARPANET outside the US, and because of the role of Peter and his 
research group in developing TCP/IP. Peter continued throughout his life 
to be important in the development of network security protocols, video 
conferencing, multicast, directory services, secure e-mail, certificate 
authorities, and IPv6. He was instrumental in delivering effective 
Internet connectivity to the Caucasus and Central Asia through what was 
state-of-the art satellite technology as project manager of the SILK 
project.


Peter won many plaudits throughout his life – to name but a few he was a 
recipient of the Marconi prize and the SIGCOMM award and was inducted 
into the Internet Hall of Fame as a pioneer as part of its first intake. 
Never one to rest on his laurels, Peter continued to be interested in 
and to work in new areas of networking, developing an interest in IoT 
and being an advocate for the Handle System developed by Bob Kahn as 
late as last year. Peter retired in November 2019, at the age of 86. He 
lived life to the full – he broke his pelvis skiing, only last year. He 
was a gentleman, innately kind and supportive, and someone to whom all 
were worthy of equal consideration, from the most junior of staff to the 
most senior. He retained a passionate interest in the Department of 
Computer Science at UCL to the very end of his life, and will be sorely 
missed by those of us that had the good fortune to know him, work with 
him, and call him friend.


Peter is survived by his wife Gwen, daughters Lynn and Claire and their 
children.


For those that are interested in early Internet developments, there is 
an opportunity to hear Peter speak about these in an interview with Jim 
Boulton filmed last year: https://www.youtube.com/watch?v=CfzbAzGVSyE. 
There is also an obituary in the New York Times 
https://www.nytimes.com/2020/01/08/technology/peter-kirstein-dead.html.




To unsubscribe from the NGN list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN=1

Re: [uknof] Anyone at plymouth.ac.uk or csirt.ja.net can look into this?

[Rob Evans]

Hi,


Over the last year I've sent multiple abuse reports to
ab...@plymouth.ac.uk and not even received an auto-reply. A couple
of weeks ago upon receiving another mail I sent an abuse report to
i...@csirt.ja.net and have again heard nothing.


That surprises me.  There are definitely CSIRT folk on this list, but 
I'll forward internally as well (though their approach will just be to 
Plymouth).


Rob

Re: [uknof] Three hosed. Make it right please!

[Rob Evans]

> Weird, the network status page has me in queue with 3340 folks in front of
> me..

...and when you get to the front it just says "geeks at work" with no
extra information, so don't waste your time...

Cheers,
Rob

Re: [uknof] WHOIS Syntax Fail

[Rob Evans]

Is this not possible within the native whois client?


One reason it’s difficult is that there isn’t a 1:1 mapping between 
ASN and AS-SET.


For example, AS786 uses AS-JANETUS, AS-JANETPLUS, and AS-JANETEURO (the 
names are largely historic, JANETUS is for transit, JANETEURO is for the 
pan-European R network, JANETPLUS is for all other bi-lateral 
peerings).


To get the correct one for our peering with you, you’d need to query 
AS786 and look at the relevant export: line, or talk to the NOC when 
bringing up a peering (although for the bulk of peerings it’s 
AS-JANETPLUS, as documented in Peering DB).


Cheers,
Rob

Re: [uknof] virus in attachment from john.bou...@mobileinternet.com

[Rob Evans]

> Did anyone else get this? And did anyone analyse the attachment?

I did, also in reply to an email from 2015, and I didn't touch the
attachment with the proverbial bargepole.

Cheers,
Rob

Re: [uknof] Example of total DC loss

[Rob Evans]

> As a reminder for the bitrot in the last 16 years...
> 
>   http://www.slimey.org/bbc_ticket_10083.txt

Our version of the same is appended (newest updates at top).

Rob

> Ticket Number: 20010912-2  Ticket Status: UPDATE
> Ticket Type  : Unscheduled Ticket Source: TEN-US NOC
> Ticket Scope : SiteSite/Line: New York
> Ticket Owner : TEN-US NOC  Problem Fixer: Telehouse NY
> Ticket Opened: 20010912 12:08 UTC  Problem Start: 20010911 20:35 UTC
> Ticket Update: 20010918 05:13 UTC
> Ticket Closed: Problem Ends :
> 
> 
> Ticket Summary: Status of 25 Broadway
> 
> Problem Description:
> 
> This ticket is being issued to track the status of the infrastructure
> at the DANTE World Services PoP in New York.  Individual circuits
> will be dealt with separately.  Updates will be in the "actions" section
> below.
> 
> Affected:
> 
> DANTE World Service
> 
> Actions:
> 
> cziarhe   20010918 05:13 UTC
> Load was switched from the Con Ed generator to the critical generator
> as planned.  Unfortunately, after about 45 minutes the generator
> again began to overheat and the load was switched back.  This was
> achieved without interruption to service.  It is now believed this
> could be due to limescale build-up in the radiator.
> 
> This is to be rectified by using an acid wash through the cooling
> system and again running the generator under load at 22:30 UTC
> tonight (Tuesday).
> 
> A plan is also being developed to bring in a new generator should
> the situation with the critical generator persist.
> 
> 
> 
> Time to Fix: (Hours:Mins)
> 
> 
> 
> Fix:
> 
> 
> 
> History:
> 
> cziarhe   20010917 21:53 UTC
> Telehouse NY believe the problems with their "critical" generator
> have been caused by faulty thermostats.  These have now been replaced
> and the generator has been spun up for a basic test.  The next
> step is to try a load test, which will begin at 22:30 UTC.  If
> this is successful, then load from the "essential" generator, which
> supplies the air conditioning will be transferred to the Con Ed
> generator for maintainence to take place on this generator, which
> has also been running overtemperature.
> 
> Assuming all this works successfully, Telehouse plan to run the
> Con Ed generator in conjunction with either the essential (Air
> Con) or critical (equipment) generator to make the best use of
> available fuel.  Further fuel supply problems are not thought to
> be likely as there are 17 tankers in the city, and a further 30
> generators are available.
> 
> The IP NOC will monitor the initial switch to the critical generator
> to ensure equipment remains in operation, and reinstall the workaround
> with KPN should it be needed.
> 
> cziarhe   20010916 14:59 UTC
> The latest update from Telehouse reports that an extra 2000 gallon
> fuel tank is expected to be connected to the Con Ed generator soon
> to allow for longer refuelling intervals.  in addition, Con Ed's
> refuelling process to all buildings in the area has now settled
> down, so it should be as reliable as possible in the circumstances.
> 
> An engineer is currently onsite investigating the problems with
> Telehouse's own generator.
> 
> cziarhe   20010916 12:05 UTC
> Regular fuel deliveries appear to have been secured for the Con
> Ed generator.  There were deliveries at 02:00 UTC and 11:30 UTC,
> and another is scheduled for 21:30 UTC.
> 
> The status of the Telehouse generator is currently unknown.
> 
> cziajom   20010915 20:16 UTC
> Contacted Telehouse NY. Informed that Con Ed generator is now up,
> with enough fuel until Tuesday (18 Sep). Engineers are still working
> on the Telehouse generator. NY Routers are starting to come up.
> 
> cziarhe   20010915 18:25 UTC
> Despite what we were informed of earlier, the Con Ed generator ran
> out of fuel at 16:45 UTC.  Telehouse's generator then started up,
> but overheated again.  There is a fuel truck just outside the cordoned
> area, but it is not being allowed through, and unfortunately we
> have no ETA for the fuel, or time-to-repair for the Telehouse generator.
> 
> cziarhe   20010915 18:15 UTC
> Power was lost again at 17:45 UTC, we are contacting Telehouse for
> information.
> 
> cziarhe   20010915 15:52 UTC
> The current status relayed to us by Telehouse is as follows:
> 
> The Con Ed generator is monitored around the clock by Con Ed personnel,
> who are responsible for refuelling it.  As of 15:00 UTC there was
> approximately 15 hours worth of fuel remaining.
> 
> The water pump on Telehouse's own generator has been replaced and
> the unit has been run for about 30 minutes to test.  Telehouse
> are taking this opportunity to perform some routine maintenance
> (changing oil and filters, pressure washing the radiator) to ensure
> it is ready should it be needed for another extended run.
> 
> Fuel currently available onsite should last until 

Re: [uknof] Example of total DC loss

[Rob Evans]

> As I recall fuzzy though was AC issues caused by dust and they eventually ran 
> out of fuel for the generator as the port authority wouldn't allow tankers 
> onto Manhattan. Might be wrong on that long time ago.

We have an epic ticket from that, I’ll see if I can find a copy.

Rob



signature.asc
Description: Message signed with OpenPGP

Re: [uknof] MTP Single Mode cables - Wanted

[Rob Evans]

> I seem to recall a large academic network having saved over a million pounds 
> by
> using MMF optics purely for links between their packet and optical platforms
> that would typically be in adjacent racks, although that may have been a few
> years ago and suffering early adopter pricing for wanting the highest capacity
> interface on the market at that point :)

This was largely the difference in price between ~112 100GBASE-LR4 CFP 
pluggables and the same number of 100GBASE-SR10 ones and couldn’t support 
10x10MSA.

The price difference is still substantial, but we’re not sticking with SR10s on 
new installs.

Rob

Re: [uknof] UKNOF mailing list migration

[Rob Evans]

> However, it was all a dream. "mail.uknof.net" doesn't have an
>  record. Sorry Nat ... back to the drawing board. :(

lists.uknof.org.uk, however, does.

~ rhe$ host lists.uknof.org.uk
lists.uknof.org.uk has address 46.235.226.246
lists.uknof.org.uk has IPv6 address 2a00:1098::86:1000:37:4:1
lists.uknof.org.uk mail is handled by 5 lists.uknof.org.uk.

Rob

Re: [uknof] Brocade 100G LR4 to Ciena 6500 Interop

[Rob Evans]

> Wait, LR4 <> C-band transponder?
> 
> Having worked a bit with Ciena 6500, there should be a pair of cards
> at either side, theres a "client" card with a matching LR4 optic, and
> the transponder ("line") card that is tunable in the C-band. Wouldnt
> be so sure about hooking an LR4 straight up to the transponder...

Thanks for pointing out what confused me. :)

I think WL3e suggests it is a traditional OCI (client) and OCLD (line) pairing. 
 There is a single-slot OTR with a fixed LR4 client side and the line-side 
optic in the same card, but that's relatively new.

I'd have a look at the PM stats on the Ciena to see if something isn't behaving 
well.  I recall we did have a problem with some Juniper/Ciena interop a couple 
of years back which looked like intermittent circuit drops, but that proved to 
be a Juniper problem rather than a Ciena one.

Cheers,
Rob

Re: [uknof] DNS Issue - Expenential-e / newham.gov.uk

[Rob Evans]

Hmm, I've asked the folk here to check where the typo crept in and do the 
needed.

Cheers,
Rob

Re: [uknof] Belfast

[Rob Evans]

Good venue, good people, good content, good hosting, tasty shortbread biscuits 
and delicious scones (not had scones in a break since Bristol?).  Thanks to all 
involved.

Rob

Re: [uknof] Equipment in customs

[Rob Evans]

 I have tried this on a number of occasions and not been successful but it 
 doesn't hurt to try again I suppose! Even a small sporting event with rings 
 and billions of viewers didn't swing it! 

To heavily paraphrase Dame Edna, “So, HMRC, why didn’t you want to let the 
multi-billion-pound sporting event off a little import duty?” :)

Rob

Re: [uknof] Equipment in customs

[Rob Evans]

 To heavily paraphrase Dame Edna, “So, HMRC, why didn’t you want to let the 
 multi-billion-pound sporting event off a little import duty?” :)

Bah. Mrs Merton, not Dame Edna, natch.

Re: [uknof] First one of these I've received...

[Rob Evans]

 So not that much considering cost of CGN which actually works. 
 
 Even more silly is the fact space is still available from ARIN on normal 
 terms (they're not into their last /8 yet) so it's clearly some form of spam.

Note they're also asking for IPv6 space...

Rob

Re: [uknof] First one of these I've received...

[Rob Evans]

 Most people will still filter on a /24 I believe , although some will filter
 on a /22 (Minimum RIPE Allocation)

I'll also just plug a talk at tomorrow's meeting by Olaf Maennel of 
Loughborough University -- Observing Limited Visibility Prefixes in the Wild. 
 More details on the agenda:


http://indico.uknof.org.uk/conferenceOtherViews.py?view=standardconfId=27

Cheers,
Rob

Re: [uknof] A dual stack London2012?

[Rob Evans]

Then, have the ISP do some magic* to make IPv4 visible.
* I'll leave it as an exercise to those more sober and less tired to
solve that problem. But I guess it'd mean some clever DNS
capture/re-map for all locations which don't have  addresses,
remap them to a local 6 to 4 proxy.


I think you mean DNS64 and NAT64.

http://tools.ietf.org/html/rfc6146
http://en.wikipedia.org/wiki/NAT64

Rob

[uknof] RIPE 63: Call for Presentations

[Rob Evans]

Hi,

Some of you may be interested in this.

The RIPE programme committee is looking for plenary content for the next 
meeting in Vienna during the first week of November.

One of the topics that has been brought up is content delivery and how ISPs in 
the UK especially have dealt with the large amount of streaming traffic that 
services such as the BBC iPlayer have generated.  If you have something to tell 
on this, or any of the topics, please submit a suggestion on the website 
mentioned in the message.

All the best,
Rob


Begin forwarded message:

 From: RIPE NCC Meetings meet...@ripe.net
 Date: 1 September 2011 12:52:48 GMT+01:00
 To: ripe-l...@ripe.net
 Subject: RIPE 63: Call for Presentations
 
 Dear colleagues,
 
 RIPE 63 takes place on 31 October - 4 November 2011 in Vienna, Austria.
 
 The RIPE Programme Committee is now seeking content proposals from the
 RIPE community for the Plenary, BoF and tutorial sessions at RIPE 63
 covering subjects including but not limited to:
 
 • IPv6 deployment
 • Data centre technologies
 • Network and DNS operations
 • Internet governance and regulatory practices
 • Network and routing security
  * Content delivery
  * Internet peering and mobile data exchange
 
 Submissions
 
 Content proposals must be submitted for full consideration no later than
 *18 September* using the online topic submission system at:
 http://meetings.ripe.net/pc/
 
 If you have any questions or requests concerning content submissions,
 please email p...@ripe.net.
 
 For more information about RIPE 63, including how to register, visit:
 http://ripe63.ripe.net/
 
 Kind regards,
 
 The RIPE Programme Committee
 

Re: [uknof] Four recent IPv4 /8 allocations - please update your filters

[Rob Evans]

I came across this (old) article about how some of the unallocated
blocks are unuseable due to pollution, sorry if you've already seen it.

http://labs.ripe.net/Members/franz/content-pollution-18

would be interested to know if the situation's improved since 1/8 was
debogonised.


There was a presentation by George Michaelson of APNIC (the /8 is used 
by APNIC who are now doing most of the studies) at the IEPG attached to 
the IETF this week:


http://www.iepg.org/2010-07-ietf78/index.html

These are similar to things presented at the previous RIPE meeting.

Unfortunately it doesn't plot the effort of any de-bogonising efforts 
over time, but the situation with 1/8 is slightly different as it is 
used in various places, rather than just blocked as a bogon.  The 
current status is that the worst few /16s within the /8 are held back 
from allocation, but other addresses are being assigned.  For those the 
debogonising efforts are likely to be the same as most other /8s 
assigned to an RIR.


Cheers,
Rob