On Sun, 18 Feb 2024, 05:29 Owen DeLong via NANOG, wrote:
> Most firewalls are default deny. Routers are default allow unless you put
> a filter on the interface.
>
This is not relevant though. NAT when doing port overloading, as is the
case for most CPE, is not default-deny or default-allow. The
On Sat, 7 Jan 2023, 20:52 Masataka Ohta,
wrote:
> Matthew Walster wrote:
>
> > No... It's action based. You can send it a different route, you can
> > replicate it, you can drop it, you can mutate it...
>
> Replication is a poor alternative for multicast.
>
You
On Sat, 7 Jan 2023, 03:17 Masataka Ohta,
wrote:
> Matthew Walster wrote:
>
> > it's just one aspect of it. Some use it for
> > classifying guest traffic etc.
>
> If special path is provided for guest or otherwise
> prioritized traffic, that's QoS routing.
>
On Fri, 6 Jan 2023, 18:38 Mike Hammett, wrote:
> I suspect it always will have value, whether it's peering routers, POP
> routers, multi-homed customer routers, etc.
>
Indeed. It's not "clean" but it is an acceptable tradeoff if you know what
you're doing, and how traffic sloshes around etc.
I
On Fri, 6 Jan 2023, 11:25 Forrest Christian (List Account), <
li...@packetflux.com> wrote:
> In the end though, I do expect that the hassle of setting up and managing
> a solution like this is likely to result in most people deciding that it
> isn't worth the extra complexity just to avoid upgrad
On Fri, 6 Jan 2023, 17:07 Masataka Ohta,
wrote:
> Christopher Morrow wrote:
>
> > Some of the reasoning behind 'i need/want to do SDN things' is 'low fib
> > device' sort of reasonings.
>
> What?
>
> SDN is a poor alternative for those who can't construct a
> network with fully automated QoS guar
On Fri, 24 Jun 2022, 22:34 Mikhail Grishin, wrote:
>
>
> Arnold Nipper пишет 24.06.2022 12:32:
> > On 23.06.2022 23:41, Douglas Fischer wrote:
> >> Sincerely, what caught my attention was the "Auth: none" part.
> >> On a room with more than thousand persons, confirm if the voice you
> >> rear is
No worries! You may want your client to follow redirects, but choosing the
FQDN is probably the right choice :)
Cheers!
Matthew Walster
On Tue, 14 Jun 2022, 21:50 Marshall Mahachi,
wrote:
> Hi Matthew
>
> Yeah; that was it.
>
> Was being redirected to "https://www.peeri
Marshall,
>From the headers, can you tell where you are being redirected to?
Matthew Walster
On Tue, 14 Jun 2022, 16:40 Marshall Mahachi,
wrote:
> Hi pdb-tech list
>
> I am trying to update a Network ("net" type object) using the API :
> https://peeringdb.com/api/net/
The setup of the TCP session is handled by the kernel, hence the higher
TTL. Once TCP is established, (e)BGP tends to use a TTL of 1 unless it's a
multihop session.l, or you're using GTSM.
It's expected, and is partly due to the limitations of how sockets are
implemented in Linux.
M
On Fri, 1 Ap
On Thu, 10 Mar 2022, 19:41 Dave Taht, wrote:
> I am deeply concerned by the onrushing move to udp for QUIC,
>
IMO, it's a fad that will die away.
IMHO, QUIC should also one day become its own protocol number also,
>
If that was feasible, we would likely be using SCTP by now. TCP, UDP, and
ICMP
On Thu, 10 Mar 2022, 11:22 Masataka Ohta,
wrote:
> Saku Ytti wrote:
>
> > Same. And if we don't voluntarily agree to do something to it, it'll
> > be the same in 2042, we fucked up and those who come after us pay the
> > price of the insane amount of work and cost dual stack causes.
>
> Indeed, w
On Thu, 10 Mar 2022 at 15:20, Tom Beecher wrote:
> You appear to run a residential ISP. There are essentially 3 things you
> would have to do to deploy IPv6.
> [...]
>
Putting aside the 'zero value' idea, if you were to decide to take steps
> today , what are your blockers?
>
I'm going to turn t
On Wed, 9 Feb 2022 at 23:36, E Z wrote:
> I noticed a phenomenon while maintaining my golang application, the local
> timezone of the application always keep the value when it starts, the local
> timezone will not change even though I change the system timezone. It looks
> like the golang time pa
On Wed, 9 Feb 2022, 07:42 Stephane Bortzmeyer, wrote:
> The only problem is the less friendly IP address (although this will
> be less and less a problem with IPv6, since 2001:4860:4860:: is
> not really friendly).
Au contraire, I find 2600:: easy to remember :P
This can be partially mitig
On Wed, 9 Feb 2022, 04:45 Mark Tinka via Outages,
wrote:
> If we want to stop this behaviour, we'll have to do something about it,
> specifically, offering an alternative to Internet users that is regarded
> as official, e.g., like we do with other public services such as NTP.
>
Do a DNS query.
(as posted to outages)
On Wed, 9 Feb 2022, 04:53 Mark Tinka, wrote:
> It is clear that a number of Internet users find pinging "reliable" IP
> addresses useful, regardless of whether it actually is or isn't, or
> whether it's ethical or not.
>
> Like we have done with other public services such
On Tue, 8 Feb 2022 at 19:49, Stephane Bortzmeyer via Outages <
outages@outages.org> wrote:
> Replying to ICMP echoes is not part of the service Google Public DNS
> officially does, so it is possible that they sometimes filter and/or
> rate-limit ICMP echo. It's not an outage.
>
https://peering.go
Whoops, yes, there is a feature flag there I missed "supportsAES" etc. It
appears to be gated on that instruction being present, at which time the
operation becomes roughly constant time.
M
On Fri, 3 Dec 2021, 08:53 Matthew Walster, wrote:
> Sure, it's enabled in
Sure, it's enabled in a build constraint:
https://cs.opensource.google/go/go/+/refs/tags/go1.17.3:src/crypto/aes/cipher_asm.go
It's not an exact science, there's no testing for the instruction afaict,
it's just that anything running the amd64 architecture has the aesni
instructions. I assume like
Gavin,
On Wed, 24 Nov 2021 at 21:20, Gavin Henry wrote:
> Working on the API and web UI next, then the p2p part of it. Feel free
> to submit any feature requests or have a play :-)
>
P2P sounds ripe for abuse by bad actors... A few scenarios:
1. You only get the list if you provide a list of y
On Thu, 18 Nov 2021 at 15:04, Leo Vegoda wrote:
> On Thu, Nov 18, 2021 at 6:05 AM Tim Chown wrote:
> > Personally, I’d say just get on with IPv6.
> This gets my vote.
>
So... This is tricky. IPv4 isn't going away for residential and most SME
connectivity -- it's just too difficult to live witho
On Sat, 20 Nov 2021 at 17:18, Leo Vegoda wrote:
> On Sat, Nov 20, 2021 at 9:08 AM Matthew Walster
> wrote:
> > I'm just saying that screaming "IPv6 is the answer, deploy it" is
> actually forgetting that it doesn't actually reduce IPv4 usage in and of
>
On Sat, 20 Nov 2021 at 16:31, Leo Vegoda wrote:
> On Sat, Nov 20, 2021 at 8:06 AM Matthew Walster
> wrote:
> > On Thu, 18 Nov 2021 at 15:04, Leo Vegoda wrote:
> >>
> >> On Thu, Nov 18, 2021 at 6:05 AM Tim Chown wrote:
> >> > Personally, I’d say jus
On Sat, 20 Nov 2021 at 22:35, Owen DeLong wrote:
> On Nov 20, 2021, at 03:16 , Matthew Walster wrote:
> On Sat, 20 Nov 2021, 09:21 Måns Nilsson,
> wrote:
>
>> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov
>> 20, 2021 at 10:26:33AM +0900 Quoti
On Sat, 20 Nov 2021 at 22:14, Måns Nilsson
wrote:
> Subject: Re: Class D addresses? was: Redploying most of 127/8 as unicast
> public Date: Sat, Nov 20, 2021 at 11:51:24AM -0800 Quoting William Herrin (
> b...@herrin.us):
> All the heavy lifting in video production via IP is done over
> multicast
On Sat, 20 Nov 2021 at 13:47, Måns Nilsson
wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 11:16:59AM + Quoting Matthew Walster (matt...@walster.org):
> > 3. IPv6 "port forwarding" isn't really an easy thing -- people
On Sat, 20 Nov 2021, 09:21 Måns Nilsson, wrote:
> Subject: Re: Redploying most of 127/8 as unicast public Date: Sat, Nov 20,
> 2021 at 10:26:33AM +0900 Quoting Masataka Ohta (
> mo...@necom830.hpcl.titech.ac.jp):
>
> > > We cope,
> > > because a lot of technical debt is amassed in corporate and I
On Fri, 29 Oct 2021, 15:55 A Crisan, wrote:
> Hi Matthew,
> I was reading the above exchange, and I do have a question linked to your
> last affirmation. To give you some context, the last 2021 ENISA report seem
> to suggest that internet traffic is "casually registered" by X actors to
> apply po
to the list after few days (of collecting responses,
> if any).
>
I would strongly encourage engaging with the IETF (
https://datatracker.ietf.org/wg/sidrops/about/ et al) who are much more
likely to be able to point you in the right direction.
Matthew Walster
On Fri, 22 Oct 2021, 13:03 Jens Link, wrote:
> I ran into this some time ago with deb.debian.org on an IPv6 only Debian
> VM with a locally installed resolver. I opened a ticket which was closed
> in record time: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961296
>
> After some ranting and
On Thu, 21 Oct 2021, 19:28 Fred Baker, wrote:
> I’m not sure I disagree, but let throw in a point of consideration.
> Historically, as you note, the caller pays the toll. However, the caller
> also CHOSE to call, even though the called party might find the call
> irritating. With a CDN, the netwo
On Thu, 21 Oct 2021 at 17:43, Owen DeLong wrote:
> > On Oct 21, 2021, at 06:30 , Allen McKinley Kitchen (gmail) <
> allenmckinleykitc...@gmail.com> wrote:
> > I totally agree that this is not a perfect analogy. But I have some
> sympathy for both parties in this debate.
>
> Close enough on the an
On Wed, 20 Oct 2021 at 19:53, Jared Brown wrote:
> “When the rules were created 25 years ago I don’t think anyone would have
> envisioned four or five companies would be driving 80% of the traffic on
> the world’s internet. They aren’t making a contribution to the services
> they are being carrie
On Tue, 12 Oct 2021, 02:24 Owen DeLong, wrote:
>
> A 4K 2 hour movie is about 40GB. Most modern smart TVs around 32GB of RAM
> and can probably devote about 20GB of that to buffering a stream, so yeah,
> that should actually be doable.
>
Most users are not streaming 4K, it's a very small fractio
On Mon, 11 Oct 2021 at 21:05, Matthew Petach wrote:
> I think it would be absolutely *stunning* for content providers
> to turn the model on its head; use a bittorrent like model for
> caching and serving content out of subscribers homes at
> recalcitrant ISPs, so that data doesn't come from outs
ifying your
upstreams etc) in comparison that requires frequent updates, whereas router
signing keys will be dwarfed by ROAs etc, there being far more prefixes
than there are border routers.
Or have I missed something here? (I'm not trolling, I genuinely want to
understand if I'm overlooking some major part).
Matthew Walster
On Mon, 11 Oct 2021 at 11:52, Tim Bruijnzeels wrote:
> > On 11 Oct 2021, at 12:45, Matthew Walster wrote:
> >
> > I genuinely don't understand the reason for obstruction here, what am I
> missing?
>
> Perhaps this sentence could have made clear that I am not &
't consider important. Customers won't consider BGPsec
important unless it's either easy to do.
Literally all that is being suggested here is that router signing keys be
made possible to upload into the RPKI dashboard. It is a small amount of
effort that allows BGPsec to be trivial to try out. I genuinely don't
understand the reason for obstruction here, what am I missing?
Matthew Walster
emselves. There is no appreciable downside
here.
I would like to see router signing key publishing support in the RPKI
dashboard.
Matthew Walster
(Now you see why I'm called waffle...)
>
something
that extensively happens between networks in LATAM outside of public IXPs
for example, which is why that statement above indicates it also
facilitates the interconnection of networks outside of IXPs. Whether that
is desirable or not is a topic for another day.
Matthew Walster
ter certain networks, right?
> It is most certainly not a single source of truth.
>
Would you care to expand on this?
Matthew Walster
>
er can
understand... He's really good at that, and has done a great job with this!
Matthew Walster
ut some hideous regex? Is that something
that's possible with the template package that I haven't discovered?
Matthew Walster
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving
m open to suggestions for alternative ways of preventing that connection
from being DoSed.
Matthew Walster
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, sen
t; generates it inside the proto's directory with a directory structure like:
>
Have you tried using an option like: --go_opt=paths=source_relative
Matthew Walster
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscri
e the TCP AO (RFC5925) instead, but
considering that GRPC (via MTLS) gives me all the authentication I need for
the data, that seems overkill and prone to opaque issues. I'm essentially
only worried about spoofed packets coming in trying to reset the TCP
connection.
Open to any suggestions, many than
On Tue, 7 Jan 2020, 21:16 Mark Tinka, wrote:
>
>
> On 7/Jan/20 12:01, Martijn Schmidt via NANOG wrote:
> > So while the IP space is registered to Cogent and allocated to its
> > customer, the AS-path might be something like ^174_456$ but it's
> > entirely possible that ARIN would observe it as ^1
On Tue, 25 Jun 2019, 14:31 Patrick W. Gilmore, wrote:
> I must be old. All I can think is Kids These Days, and maybe Get Off My
> BGP, er Lawn.
>
Maybe they ought to [puts on shades] mind their MANRS.
M (scuttling away)
>
On Wed, 13 Feb 2019 at 00:24, Job Snijders wrote:
> On Tue, Feb 12, 2019 at 7:30 PM Matthew Walster
> wrote:
> > As it stands today, RPKI is only useful to prevent fat-fingering of ebgp
> routing policies, where routes are leaked from a point of "legitimate"
>
On Tue, 12 Feb 2019 at 16:05, Nick Hilliard wrote:
> Matthew Walster wrote on 12/02/2019 14:50:
> > For initial deployment, this can seem attractive, but remember that one
> > of the benefits an ROA gives is specifying the maximum prefix length.
> > This means that someo
On Tue, 12 Feb 2019, 01:52 Jay Borkenhagen ... but there is one place where I disagree with Niels. He advised
> against lowering the local-pref of invalid routes. I agree that this
> should not be anyone's target policy, but it is a useful step along
> the way.
>
For initial deployment, this ca
On Wed, 6 Feb 2019, 20:28 Robert J. Hansen
> It's a lack of community consensus on what a redesign should look like.
>
And, might I add, the desire for our efforts not to be ruined by others
"proving a point" rather than actors actually seeking malicious intent.
I've abandoned my keyserver, and
On Mon, 4 Feb 2019, 01:26 Christian Nilsson
> in EFI mode the file:// protocol is supported which allow you to load
> for example scripts from local filesystem.
> to do this you have to do ifopen, and then chain file://
> That script could than have the ip configuration.
> However there is no supp
On Sat, 2 Feb 2019, 16:29 shouldbe q931
> So, asking the dumb question, if you are not chainloading from PXE
> using DHCP, what are you booting iPXE from ? a USB stick ? physical
> optical media? virtual ISO ? burnt into ROM ?
>
Today, I'm not, but the proposed intention is to either burn into RO
Let's try again, from the subscribed email address this time...
On Sat, 2 Feb 2019, 00:57 brent s.
>
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
I have a scenario where iPXE would be perfect for loading / upgrading the
operating system on remotely deployed hardware, but I've come across a
hurdle regarding the lack of DHCP at the remote site, and I was wondering
if anyone else has solved this in an interesting way?
You can embed a boot scri
On Fri, 16 Nov 2018, 09:01 Mike If i had the skill set needed to submit patches i would, but i don't.
> But i do have a voice and that can be used to spur on change.
>
Good lord, Kristian, you have to deal with these people on a regular basis?
I haven't been part of the pool in quite a while n
On Fri, 16 Nov 2018, 08:36 Mike Your welcome to blame others for the servers issues.
>
> I and others have pointed out many times over the issues and no one has
> fixed them.
> Rather than blame me, take responsibility for the servers failings, for
> the developers failings.
>
You are more than w
On Fri, 16 Nov 2018, 08:09 Mike This has Been Kristians approach to previous issues like this, and this
> has led to now. where the servers have not changed, that neglect now ruins
> it for everyone else and even puts the admins at risk of financial and
> legal damage, as you mentioned most cant a
have chosen
to take my keyserver down. I have not deleted the key data for now, but I
do not see myself rejoining the pool anytime soon.
I'll remain on the mailing list for the time being, but will eventually
unsubscribe.
Many thanks for a fun exp
This is why we can't have nice things.
M
On Fri, 13 Jul 2018, 19:20 Phil Pennock,
wrote:
> Heads-up:
>
>
> https://medium.com/@mdrahony/are-pgp-key-servers-breaking-the-law-under-the-gdpr-a81ddd709d3e
> https://github.com/yakamok/keyserver-fs
> https://lobste.rs/s/sle0o4/are_pgp_key_servers_b
seems broken also:
https://sks-keyservers.net/status/
Is there some kind of mass breakage occurring with people's sks installs at
the moment?
Matthew Walster
(sysop: keyserver.waffle.sexy)
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.
Probably to block TCP on the recon port for that direction?
M
On Sun, 17 Jun 2018, 11:41 Hendrik Visage, wrote:
>
> I’m considering setting up some test environments for the “researchers” to
> test the SKS keyservers, but I was wondering about one way replication, ie.
> one server that will onl
On Tue, 5 Jun 2018 at 21:04, Rae Ho (ITSC) wrote:
> Seems the problem is domain name?
>
No, I think either you've got a firewall (iptables etc) running and
blocking tcp/179, or you haven't put "listen bgp" into your configuration,
so bird is not listening on tcp/179.
What is the output of "net
On 8 May 2018 at 18:58, wrote:
> Can anyone recommend wave providers on the Hong Kong area? I need to reach
> between two colo facilities there. Feel free to ping me off-list.
>
Hong Kong island (e.g. REACH near Admiralty or Mega i-advantage near Chai
Wan) or in the Tsuen Wan area (e.g. Equini
e the originator and cluster attributes set) to R1.
Does that make sense?
Matthew Walster
On 2 November 2017 at 11:30, 曾小小 wrote:
> about the bgp route reflector problem?
> Why does the reflector client receive EBGP routing entries without
> attributes??
>
>
> my
MRT table dump
> code that i forgot to review and merge to the master branch. I will do
> that ASAP.
Can I quietly bump, please =)
Matthew Walster
Harish,
On 22 August 2017 at 09:24, Harish Shetty wrote:
> I am using bird-1.4.5-1.el6,
>
That release is more than 3 years old at this point, bird-1.6.3 was
released 2016-12-22 and is probably your best bet to try that first and see
if the problem is fixed.
M
Hello,
I've just spent a while trying to debug a BGP session not coming up with
bird, it turns out I had mistakenly set the multihop setting to "1" instead
of "2" -- my fault.
However, the reason it took me so long to realise this error was because
the TCP session is established, with default con
s networks, you would do very well to at the very least
implement a prefix-limit on the BGP session, that stays "hard down" if it
is tripped.
Matthew Walster
On 10 July 2017 at 13:49, Phil Bartlett
wrote:
> I was wondering if there was any UK standards or professional body
> regulations for setting a minimum distance between a primary site and a DR
> site? Or is it left up to the company involved to make the best decision
> for
> their business?
>
I
are that it will be more susceptible
to small-packet attacks due to the lower packet-per-second throughput
compared to routers you may be used to.
Hope that helps!
Matthew Walster
On 19 January 2017 at 13:14, Ondrej Zajicek wrote:
> There is no direct way to import MRT data to BIRD. You could use some
> script
> to parse MRT data and convert it to static route definitions.
>
In the past, when seeking to do this I've used bgpdump[0], bgpsimple[1],
and/or imported it into
On 5 December 2016 at 14:50, Graham Johnston
wrote:
> Are there others? What is your preferred one and why?
>
Generally I don't bother with speed testers unless I'm wanting a quick
guesstimate -- I wouldn't recommend using them as a measure of how "fast"
an internet connection is because there'
On 5 November 2016 at 10:42, Job Snijders wrote:
>
>
>
Awww, I like a good hat.
> I recommend you remove the 'cheap gimmick' parts and make it look more
> like a boring business tool with appropiate domain name and
> documentation style. That will help bring the actual novel and
> intriguing
On 5 November 2016 at 03:54, Rawdon, Ryan
wrote:
> +1 for turning this into something running on/inside of PDB, since it is
> already the hub of peering matchmaking today… just without the actual
> matchmaking (well, Peering Coordinator Communication State Machine).
>
To be 100% clear on my int
hat requires the IX run IXP-Manager.
It also presumes that the network peers in only one location. With 10+
possible shared locations, that's a lot of forms to fill out versus just
one request with a bunch of exchanges specified on it.
*Matthew Walster *| Network Engineer
fastly.com | @fastly
Excellent, most appreciated!
*Matthew Walster *| Network Engineer
fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn
<http://www.linkedin.com/company/fastly>
On 3 November 2016 at 03:08, Matt Griswold wrote:
> Top posting since I just skimmed it (but had already
" to store this
project, is this likely to gain any traction anytime soon? Do we need
volunteers to help implement it? Is this even something that can be
considered a separate module that perhaps we want to have Open Source from
Day One?
Anyway, enou
On 20 Sep 2016 9:14 am, "George Skorup" wrote:
>
> Now lets move the Windows 10 updates. A 'buried in the sticks' customer
on Canopy 900 FSK. 1.5Mbps/384k. Multiple streams from Microsoft and LLNW
at the same time. LLNW alone had maybe 10 streams going and was sending at
over 15Mbps on average a
whether this is just something that isn't
anywhere near the front of mind for developers/users yet?
I realise this is not the current intended use cases, but I'm interested in
people's opinions, and whether anyone implements such a schem
On 25 May 2016 at 15:39, Michael Brown wrote:
> Should now be fixed:
>
> http://git.ipxe.org/ipxe.git/commitdiff/f42b258
>
>
Marvellous, thank you -- seems to have fixed my issue anyway!
M
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https
this at
some point -- it's still an issue in HEAD.
Matthew Walster
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
On 27 April 2016 at 20:42, Anthony Rodriguez <
anthony.rodrig...@netwolves.com> wrote:
> Hi,
>
> I have set up a test capturing NF into a postgresql 8.4 DB. It seems to
> work OK but the writing to the DB seems
> to get far behind. I had one writer take 1.5 hours to sync. Any hints
> would be appr
Source: gnupg2
Version: 2.1.11-6
Severity: important
Tags: upstream
Dear Maintainer,
Using gpg v1.x, updating my trustdb took a few seconds. In gpg v2.1,
which I have just upgraded all my keyrings to, this process takes
several minutes. It remains busy at 100% CPU (single process) until the
activ
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:1
On 16 December 2015 at 20:54, Gavin Henry wrote:
> Hi all,
>
> This is really very good (in case anyone missed it):
>
> http://www.ssi.gouv.fr/uploads/2013/10/BGP_configuration_best_practices.pdf
>
>
WOW. I would not use this, nor would I advise anyone to use it as a basis
for their configurati
thew,
>
> thanks for sharing. have you considered taking this through the BCOP track?
>
> cheers
> /joshua
>
> On Wed, Oct 14, 2015 at 7:01 AM, Matthew Walster
> wrote:
> > Would there be benefit in pimping http://peering.readthedocs.org/ again?
> >
> > I&
Would there be benefit in pimping http://peering.readthedocs.org/ again?
I'd like to try and get it to a state where there's a simple and easy to
follow guide to getting prefix lists across all peering fabrics. Not enough
people do this today.
M
On 14 October 2015 at 09:47, remco van mook wrote
On 29 September 2015 at 17:13, Bob Evans
wrote:
> Neils, do you actually work at in a NOC operation with BGP operations and
> policies you can change - a backbone with customers?
"lolz" as the kids say.
> SayAn email/ text might work well or even better than SIP - if we had
> an APP th
On 14 September 2015 at 19:17, Matthew Walster wrote:
>
>
> On 1 September 2015 at 17:02, Matthew Walster wrote:
>>
>> I'll then be generating a signing sheet and distributing it via the UKNOF
>> website for people to either print out or store for the signing
On 1 September 2015 at 17:02, Matthew Walster wrote:
>
> I'll then be generating a signing sheet and distributing it via the UKNOF
> website for people to either print out or store for the signing during the
> event.
>
The keyring and the signing sheet (now with all new stat
t and distributing it via the UKNOF
website for people to either print out or store for the signing during the
event.
Looking forward to seeing you all again, and hopefully get some more UKNOF
visitors into the strong set!
Kind regards,
Matthew Walster
TM_CHANGE or similar in Linux,
so the DELROUTE will seemingly cause a tree to either be pruned or
re-branched, followed by the NEWROUTE causing a full rebalance run --
whereas a CHANGE would (could) hopefully just over-write the value.
Many thanks in advance,
Matthew Walster
chat about how this is useful, please do come
and grab me throughout UKNOF. You "can't miss me" =)
That's about it, looking forward to a quick, productive keysigning!
Matthew Walster
bortive, not all git users are aware of the distinction.
Additionally, is the renameLimit something that could potentially be
something dynamic (i.e. it inspects how much free RAM is available and
increases the buffer if appropriate) or is that a conscious decision not to
give the process "free rei
I find nuttcp very useful in those situations.
Be sure to use one of the recent betas, I have been using 7.2.1 for UDP
with excellent results (decent loss stats and jitter calc)
http://nuttcp.net/nuttcp/beta/nuttcp-7.2.1.c
As I understand it, it's still developed, 7.3.2 is now out.
M
On 7 Dec 2
On 26 November 2014 at 21:52, R.I.Pienaar wrote:
> puppet apply -e '$FooBar="1" notice($FooBar)' --parser=future
> Error: Illegal variable name, The given name 'FooBar' does not conform to
> the naming rule /^((::)?[a-z]w*)*((::)?[a-z_]w*)$/ at line 1:1
>
> Which is weird because 'fooBar' also do
CheeseCurds: NO
CHEESECURDS: NO
Would someone like to enlighten me as to which is correct?
Many thanks in advance,
Matthew Walster
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails f
1 - 100 of 271 matches
Mail list logo
