I keep running into similar issues as far as stack validation goes. (And
by stack I mean all the way up not just L2/L3).
I know that my processor has an ethernet port it can't keep up with in all
circumstances. Flooding it with more packets than it can handle isn't
useful, other than to
I really really wish there were a couple of well-known and globally
respected communities which you could set to say either "this is a route of
last resort" or "this is my preferred route".
I feel like it would avoid many of us doing exactly what you're about to do
which is pollute the routing
On Mon, Jan 15, 2024, 3:08 PM Abraham Y. Chen wrote:
> 1)Re: Ur. Pt. 1):The initial deployment of EzIP overlay is only
> applying 240/4 to existing (IPv4 based) CG-NAT facility to become the
> overlaying RAN, plus upgrading RG-NATs (Routing / Residential NATs) to
> OpenWrt. So that none
On Mon, Jan 15, 2024, 1:21 PM Abraham Y. Chen wrote:
> If I subscribe to IPv6, can I contact another similar subscriber to
> communicate (voice and data) directly between two homes in private like the
> dial-up modem operations in the PSTN? If so, is it available anywhere right
> now?
>
If 50٪ of the servers and 50% of the clients can do IPv6, the amount of
IPv6 traffic will be around 25% since both ends have to do IPv6.
If you're running an IPv6 enabled server you'll see 50% of your traffic as
IPv6 in the above scenario. Likewise, if you are on an IPv6 connected
client, then
me, I'll be one of those old
> fogey's keeping an IPv4 service alive as an example of "the old Internet"
> for those young whippersnappers to be amazed by.
>
> Regards,
>Brett
>
>
>
> On Sat, Jan 13, 2024 at 7:31 PM Forrest Christian (List Account) <
> li...@packetf
es
> of planning and nearly two decades of deployment. Its future growth rate is
> set by its own performance merits. No one can force its rate by persuasion
> tactic of any kind. Hoping so is wishful thinking which contributes to
> wasteful activities. So, we need realistic planning.
&
rrent CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64
> fold bigger. And, various capabilities become available.
>
> Regards,
>
> Abe (2024-01-11 22:35)
>
>
>
> On 2024-01-11 02:02, Forrest Christian (List Account) wrote:
>
> I shouldn't probably go d
I shouldn't probably go down this path... as I know this has been discussed
but I'm hoping that this might make a difference.
Abraham,
Even if 240/4 is "fixed", your EzIP scheme will require some sort of NAT
box between the 240/4 addressed devices and the non-EzIP internet. That
NAT box will
I don't think any of us really understand what you're hoping to find. I
sure don't.I think that this might be a result of a disconnect between
your understanding of how these should be monitored and how they are
monitored.
Specifically, of your two statements below, one is true and one is
Replying to two posts at once...
One can definitely get inexpensive and high-quality rubidiums for dirt
cheap on the second-hand market. I've specifically ignored those when
discussing price as options as one can never be sure about their accuracy
or long-term reliability, and I try to filter
e other machinations are pointless while GPS
> is working, because GPS gives you by far the best accuracy and security for
> the buck. Like I said, spend $400 on a commercial GPS time server and
> timing problems are solved. Or use facility-provided GPS if you can’t get
> an antenna up.
&
I've responded in bits and pieces to this thread and haven't done an
excellent job expressing my overall opinion. This is probably because my
initial goal was to point out that GPS-transmitted time is no less subject
to being attacked than your garden variety NTP-transmitted time. Since this
age -
> > From: "Forrest Christian (List Account)"
>
> > Let me address your points:
> [ ... ]
> > Let's assume you have a typical GPS-derived NTP server using a typical
> > commercially available timing GNSS module. To convince that receiver
> that
> &
o...@necom830.hpcl.titech.ac.jp> wrote:
> Forrest Christian (List Account) wrote:
>
> > The recommendation tends to be the following:
> >
> > 1) Run your GPS-derived NTP appliances, but DO NOT point end-user
> > clients at it. 2) Run a set of internal NTPd servers
on your site
> that makes a conscious test and decision to fail over to regular NTP
>
> -mel via cell
>
> > On Aug 9, 2023, at 5:01 PM, Seth Mattinen via NANOG
> wrote:
> >
> > On 8/9/23 3:25 PM, Forrest Christian (List Account) wrote:
> >> Note that
Let me address your points:
First, the spoofing does mess with the timing stream. To not mess with the
timing stream, the entity doing the spoofing would have to have
high-quality NTP-synchronized clocks and somehow generate the GPS I-Q data
such that it was perfectly synchronized with
/ftp/pub/tai/annual-reports/bipm-annual-report/TIMESERVICES/timeservices.pdf
.
On Wed, Aug 9, 2023, 10:30 AM Seth Mattinen via NANOG
wrote:
> On 8/9/23 2:39 AM, Forrest Christian (List Account) wrote:
> > When GPS is working, time transmission with accuracies of under 1
> > micros
When GPS is working, time transmission with accuracies of under 1
microsecond is common. This is especially true if the GPS integrates some
sort of disciplined oscillator. Note that this is in excess of what NTPd
running on a typical OS can reliably retransmit.
BUT.. if I was to choose only
at an additional cost.
On Mon, Aug 7, 2023, 11:02 PM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> Forrest Christian (List Account) wrote:
>
> > In the middle tends to be a more moderate solution which involves a mix
> of
> > time transmission methods from
-mel
>
> On Aug 7, 2023, at 1:39 AM, Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
>
>
> The problem with relying exclusively on GPS to do time distribution is the
> ease with which one can spoof the GPS signals.
>
> With a budget of around $1K
to be affected by the same outage and/or attack is good robust
design.
On Mon, Aug 7, 2023 at 2:39 AM Forrest Christian (List Account) <
li...@packetflux.com> wrote:
> The problem with relying exclusively on GPS to do time distribution is the
> ease with which one can spoof the
The problem with relying exclusively on GPS to do time distribution is the
ease with which one can spoof the GPS signals.
With a budget of around $1K, not including a laptop, anyone with decent
technical skills could convince a typical GPS receiver it was at any
position and was at any time in
On Sat, May 6, 2023, 3:05 PM Jim wrote:
> This is important in order to
> provide accurate NOC / Technical and Abuse contact to the community for
> the purposes Of validating legitimate
> technical contacts for a variety of reasons, contacting users about
> connectivity issues, and being able
e
that? Or threaten to change providers at the earliest possible moment?
On Fri, May 5, 2023, 11:05 AM Lyndon Nerenberg (VE7TFX/VE6BBM) <
lyn...@orthanc.ca> wrote:
> Forrest Christian (List Account) writes:
>
> > I can't speak for aptum, but I'm curious as to why this is important t
:09 PM, Forrest Christian (List Account) wrote:
>
> I can't speak for aptum, but I'm curious as to why this is important to
> you?
>
>
> SWIP'ing or delegating address space is a requirement of the contract
> signed with ARIN when the addresses were granted. If you route a
; which tech was helping them get it. I went back to the office that
> afternoon and sanitized our rDNS to put a stop to that.
>
>
>
> -richey
>
>
>
> *From: *NANOG on
> behalf of Forrest Christian (List Account)
> *Date: *Thursday, May 4, 2023 at 10:09 PM
>
I can't speak for aptum, but I'm curious as to why this is important to
you? I'm not trying to discount this at all, just curious why this
matters in the internet of 2023.
I went through a couple years back and removed all of our mostly outdated
SWIP data and replaced it with generic
We actually manually list our customer ranges in pbl, or at least used to.
Probably something else that I need to check on.
On Fri, Apr 21, 2023, 8:04 AM Lukas Tribus wrote:
> Hello,
>
>
> without PTRs you will probably get your prefixes listed in things like
> Spamhouse PBL. So adding the
I have a feeling that I might be stepping into a can of worms by asking
this, but..
What's the current thinking around reverse DNS on IPs used by typical
residential/ small business customers.
Way way back in the day I used to generate "filler" reverse dns for all of
these ranges .. that is,
The cost to build physical layer in much of the suburban and somewhat rural
US is low enough anymore that lots of smaller, independent, ISPs are
overbuilding the incumbent with fiber and taking a big chunk of their
customer base because they are local and care. And making money while
doing it.
I have two thoughts in relation to this:
1) It's amazing how many threads end up ending in the (correct) summary
that making an even minor global change to the way the internet works
and/or is configured to enable some potentially useful feature isn't likely
to happen.
2) I'd really like to be
provide 1.24Gpbs or more using LCRD as a relay with the two
> ground stations, one in HI, and one in CA.
>
> DoD/NRO have been working on this for some time now, but any information
> is in the top secret blackhole.
>
> -J
>
>
> -Jorge
>
> On Jan 23, 2023, at 1:54 AM, F
I think the thing they're calling revolutionary is the idea of those links
being directional lasers.
It makes some sense... if you can basically emit the same signal you'd
shoot down a strand of single mode but aim it through the mostly vacuum of
space in the exact direction of your neighbor
Having wanted something similar recently, let me clarify what my desire
was.
I had a 1M FIB device I needed to get some additional life out of, running
ipv4 and ipv6. It also was running short on memory. This particular
device had 3 connections to the rest of the net which were running BGP, one
But that traffic was likely requested by and for the benefit of the person
the traffic is being sent to.
I've always found the argument that the quantity of traffic is the
indicator of who should pay to be questionable.
If I'm an end user on an eyeball user and request a big download or
wrote:
> >> > General press loses its *mind*:
>
> No more than usual. They're just rewriting this Facebook blog post:
>
>
> https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-leave-the-leap-second-in-the-past/
>
> It appears that Forrest
Personally I'd like to see the UTC timescale be fixed to the TAI timescale
with a fixed offset determined by whatever the offset is when they make the
change.
Or stated as a different solution with the same result: quit
adding/removing seconds from the TAI to UTC offset.
At the same time, those
I think the key difference here is that I really just wanted HE to treat my
routes no differently no matter how they learned them. I wanted them to
apply normal BGP routing rules to them.. that is, pick the path with the
shortest AS path.
>From a strictly technical basis, its silly to prefer a
ould go a long way. Same for geographic scope of routes, only use these on
> same continent. Makes using a provider if you do something like anycast
> hard if they haul you long distance.
>
> - Jared
>
> Sent via RFC1925 compliant device
>
> On Jul 25, 2022, at 6:49 AM, Forrest C
I wish they'd add one more that turns off their "prefer routes learned from
a customer" rule. I'm having to split my blocks in half and announce them
that way to get them to send my traffic directly to me through our IX
peering session as opposed to one of my transit providers.
I'd rather they
The underlying problem is silicon Fab capacity. It has nothing to do with
the actual manufacturing of the products once all the components arrive.
If you don't have components for your product, a new order for components
will take a year to arrive just because the factories that turn raw
I've seen recently a trend where code is optimized for run time and memory
consumption is a distant second consideration. I think this is a
side-effect of the growth of big data, where you really do have to worry
about your run time. Unfortunately this seems to have creeped into a lot
of other
Correction... shadowserver.org
They scan the entire ipv4 internet daily for select potential
vulnerabilities.
On Sun, Jun 19, 2022, 11:43 AM Forrest Christian (List Account) <
li...@packetflux.com> wrote:
> See shadowserver.net
>
> On Sun, Jun 19, 2022, 4:13 AM Ronald F. Gui
See shadowserver.net
On Sun, Jun 19, 2022, 4:13 AM Ronald F. Guilmette
wrote:
> I would like to solicit the opinions of network operators on the practice
> of scanning all of, or large chunks of the internet for known
> vulnerabilities.
>
> In earlier times, this was generally viewed as being
These people are fictional at this point.
Starlink has changed the equation such that there are basically no places
in the continental US that can't get service which is usable for most
internet needs. I have starlink for backup purposes and don't notice any
meaningful practical difference
of the inspector.
On Wed, Sep 1, 2021, 10:13 PM Peter Beckman wrote:
> On Tue, 31 Aug 2021, Forrest Christian (List Account) wrote:
>
> > I just wish the electrical code would permit or require certain low cost
> > things which make temporary generator connections more
.
It's silly that you are prohibited by code from installing a dedicated plug
and socket for these.
On Tue, Aug 31, 2021, 3:19 AM Mark Tinka wrote:
>
>
> On 8/31/21 11:11, Forrest Christian (List Account) wrote:
>
> > I just wish the electrical code would permit or require ce
I just wish the electrical code would permit or require certain low cost
things which make temporary generator connections more likely to be safe.
For example, code requires most furnaces to be hardwired. But a furnace is
one of the first things you want on a generator in an extended winter
On Thu, Jun 3, 2021 at 4:04 PM Baldur Norddahl
wrote:
> 66/34 is 2:1 or exactly the same as GPON (2.4 down, 1.2 up). We sell 1000
> symmetrical on that GPON and the customers are happy. You would have much
> less oversubscription with 100/100 on a 1.2 Gbps wireless with 66:34
> down/up ratio,
On Thu, Jun 3, 2021 at 10:21 AM Baldur Norddahl
wrote:
> But isn't that just proving my point? If you can do 2,4 Gbps per
> frequency, why are the WISPs whining about a 100 Mbps requirement?!
>
The problem is this, in the US: If the government decides anything under
100Mb/s second isn't
I think you're really out of touch with what is going on in the WISP space.
See the following product as an example:
https://www.cambiumnetworks.com/products/pmp-450/5-ghz-pmp-450m-fixed-wireless-access-point/
14x14 beam-steering Massive Multi-User MIMO. This is able to talk, in the
same
Having dealt with this personally, I can guarantee that CAF/RDOF require
phone service to be provided as an option (and no, pointing a customer
toward a third-party voip service doesn't count) to both have an area
counted as "served" (so that you're not overbuilt) and providing phone
service is a
So, I couldn't find a good email to reply to to add my 0.02... this seems
as good as any.
My general problem with each increase of the broadband standard in the US
is that typically this is used as an excuse to start the whole 'subsidize
companies to build out broadband' process over.
Each
Back a little bit ago when the thread about running out of RFC-1918 space
was going on, I was going to make a suggestion about repurposing the Class
E space in the case where one ran out of space, assuming one could get the
vendors on your network to support this address range.
I sort of
Maybe this will help:
I use vultr. I have also brought my own address space and am announcing
it to them from one of their instances (vm's) with BGP. They are set up
such that you can use a private AS if you don't have your own and are ok
with them announcing this from their AS (after they
go interface cards at both
> ends.
>
>
>
>
>
>
> On Tue, Oct 13, 2020 at 11:12 PM Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
>
>> Generally one would order a circuit (aka wave) between your location and
>> the IX fabric at
Generally one would order a circuit (aka wave) between your location and
the IX fabric at the interchange if you're not at the site you're wanting
to peer at.
For instance, the network I am the network engineer for has a circuit which
terminates into the Seattle IX (SIX) fabric. We don't have
;> set policy-options prefix-list BGP_PEERS_DYNAMIC apply-path "protocols
>> bgp group <*> neighbor <*.*>"
>>
>> # In this second statement we use wildcards surrounding a : as this is
>> the format of an IPv6 address.
>> set policy-options prefix
After nearly 30 years of being a cisco shop, I'm working on configuring our
first pair of Juniper MX204's to replace our current provider-edge cisco.
I've worked through enough of the Juniper documentation/books to have a
fairly good handle on how to configure these, but I wanted to check with
We just got a MX204 quote and it was close to 2.5x the price you're
quoting, with apparently the minimum license needed for full tables, and
Next Day replacement. So if it's really $11K, please shoot me an email
off list. Or if someone has a better place to get a decent quote for a
MX204, or
Sorry I can't resist...
If you're going for accuracy, does 24x365 mean you close one day this
year? Or should you actually be saying 24x365.25, or even more accurately
24x365.2425 (but still not exact).
Oh wait, we missed the leap seconds in there, which there isn't any real
way to average out
Replying on list...as others may be seeing something similar.
We had a problem which started over the weekend involving Allstream. One
of their customers were announcing our prefixes, resulting in broken
connectivity.
I ended up calling the Zayo NOC, since Allstream seems to be part of zayo.
I
So to add my two stories:
I provided the Idea and a whole bunch of time/labor/etc to start a dialup
ISP in our hometown back in 1994. I remember having a big debate on
whether to bring in a single 56K leased line or 128K fractional T1. We
went with the Fractional T1 just because it could be
I hate composing email on my phone. I always seems to mangle something.
Clarification: On the RackInjector, you can power cycle the GNSS receiver
using a button on the GNSS status page.
On Mon, Jan 6, 2020, 9:00 AM Forrest Christian (List Account) <
li...@packetflux.com> wrote:
Over the weekend, tests confirmed that all of these issues are related to a
end of the year GLONASS day rollover bug in the GNSS receiver. A power
cycle seems to correct it until the next rollover in 2024.
If you're still seeing these issues then power cycle the device using a
method
One of my hats is to design/manufacture/sell GPS third party timing
receivers for Cambium Radios.It seems like something happened around
2PM MST today which caused (at a minimum) certain Globaltop/Sierra Wireless
GPS modules to quit receiving signals from the GPS constellations.
Because these
I've been ignoring this discussion because I feel this ship sailed many
years ago, and IPv6, like it or hate it, is the best way forward we have.
But, assuming you're expanding the address space, the simplest solution is
to add the additional bits addresses at the end.
I.E. every existing /32
I'll inject two of my own questions here...
Assuming one can find a used mx204, what is the official juniper licensing
policy?
It looks like I'm going to be replacing our core cisco in the not
too distant future due to running out of fib entries, and am looking at
options. Am I reading the
A couple of thoughts here:
1) I know at some sites there is an external, shared, GPS antenna which is
run through a distribution amplifier to clients. Worth checking into just
in case it exists and they forgot to offer it to you.
2) Do you have any specs on what you need for the TDM clock?
clocks. For instance, the NIST and USNO ntp servers, along with
others around the world in various standards organizations. It might
pay to include some of these in your mix as well.
On Mon, Jun 24, 2019 at 8:36 PM Chris Adams wrote:
>
> Once upon a time, Forrest Christian (List A
I would submit that the proper use of a GPS receiver is for alignment
of the start of the second to a more precise value than can be
distributed across an asymmetric network like the Internet. The
actual 'time label' for that second doesn't necessarily need to come
from GPS at all. For security
Cacti and Nagios generally poll via SNMP. This means the traffic is
generally NAT'able. If I really needed multiple polling SNMP servers
at the same address, I'd just throw them behind some sort of NAT
device.
On Wed, Apr 10, 2019 at 8:13 AM Dovid Bender wrote:
>
> Hi,
>
> A bit off topic.
oops, I guess I was wrong, missed the drama somehow. Ignore my previous
comment.
On Sat, Apr 6, 2019, 6:17 AM Forrest Christian (List Account) <
li...@packetflux.com> wrote:
> Still being maintained. .. https://www.apneaboard.com/sleepyhead/
>
> On Sat, Apr 6, 2019, 5:30 AM Jar
Still being maintained. .. https://www.apneaboard.com/sleepyhead/
On Sat, Apr 6, 2019, 5:30 AM Jared Mauch wrote:
> I keep mine in airplane mode and use SleepyHead to read the SD card. (I
> see it was shut down by the developer, but it should still work for you).
>
> - jared
>
> > On Apr 5,
On Wed, Mar 27, 2019 at 2:05 PM Bryan Fields wrote:
> Looking at the typical equipment used (64 QAM, 20 MHz channel), you're going
> to have a raw bitrate of around 80 mbit/s. Couple this with overhead and some
> inevitable interference and an access point will have about 50 mbit's of large
>
Another idea...
Have you tried reaching out to some of the blocked sites? They likely have
better contact information than is available publicly, especially a larger
one like indeed.
On Thu, Mar 21, 2019, 3:41 PM John Alcock wrote:
> Still looking for anyone from softlayer.com
>
> It has been
On Wed, Feb 20, 2019 at 1:24 PM Matthew Black wrote:
> Have you ever created a sendmail.cf without using M4?
I still believe that sendmail is Alien technology. How else can one
explain sendmail.cf?And although I can't say for sure that I
created a sendmail.cf from scratch without using the
I'm personally aware of dozens and dozens of OSPF deployments, but not
aware of a single IS-IS deployment. This is among smaller consumer ISPs,
with typically up to around 10K customers.
I'm sure a big reason for this is that IS-IS support isn't all that common
in the lower end routing gear
79 matches
Mail list logo
