if I've been compiling -RELEASE from source, but making absolutely no local patches, is it safe to switch to binary updating?
I've done it. The handbook and forums say not to, but I've never had a problem.
hmm, so not only did the singapore pm write some code, but he published it under MIT license.
up_the_irons: so when are you switching to bhyve for virtualisation? :) keepin' it 0day
LOL
has anyone properly tried bhyve yet?
hrm Cogent is not seeing the ARP Networks announce yet
could be route filters.
somehow i'm not surprised
fwiw i can see your route fine from nz :)
but it's going via any2ix..
hmm ntt goes somewehre completely different.
to europe?
is your old host in europe?
https://www.us.ntt.net/support/looking-glass/
hmm that gives a ssl warning
ok ntt is showing "import suspect"
Origin-AS validity: not-found
i wonder if that's IRR related
hmm
yeah it will be
how does NTT check that?
it's also learning it from AS3257
my IRR entries should be correct for 192.67.222.0/24
you have to register records of as origin, it's a protection mechanism.
and i think NTT may not have updated their filters yet for 192.67.222.0/24; i get the diffs only like once a day
forgot if i saw that block in there yet
hmm
i wonder if level3 is working
yeah level3 is working, except it keepson saying AS3257
level3 is learning it from trit too
up_the_irons: the v6 peering endpoint is the gateway as well right?
yeah static
hrm getting Connection refused on that one
weird
i have too many shells open hah
c shells
% ps uaxw | grep zsh | wc -l
190
it's like a beach!
i need to fix up my shell naming
i misplace tabs and have to go through so many
i think it's upstream of cogent it's being stopped.
as much as it's nice to blame cogent
probably yeah
there was some delay when i first did bgp from memory
mercutio: you think adding a aut-num object into the IRR will help?
NTTCOM updates filters daily at 0000 UTC. Route objects submitted prior to 0000 UTC are included in this daily ACL build and are usually active on the network around 0600 UTC.
:o
i dunno if it was by 0000 UTC or not
i'm thinking it probably was
hmmmm
whois -h whois.bgpmon.net 192.67.222.0
i found this and seen by #peers is /way/ lower than looking up other ip's
like arp is 232 number of peers you're #15
bgpmon probably takes a while to update
yeah maybe
it's a hgue diff though, most are saying like 230
first seen 7th May, which is still today
+/- 10
true
hmm there's roa validation
nothing else has had that yet :)
ntt doesn't see many route objects
but it doesn't for arp either
i dunno how this route object stuff works :/
like my ip address shows 7 records on rr.ntt.net
staticsafe: adding the aut-num may help
it seems common to have it
you can just do an open one like arp has?
import:        from AS-ANY   accept ANY
export:        to AS-ANY   announce AS-ARPNET
transport:      near AS-ANY whisper ANY
mercutio: added one
oh hey it's working now static
from dallas
where it wasn't before
may have been timing related.
but that's ntt route working
haha, what
then another ntt host isn't working :/
bitly is automatically adding their affiliate codes
to shortened urls
lmao
ok hangon nlayer is working not ntt
hazard: hahahahahah
that's uhh tinet
mercutio: where are you testing from?
static: vultr dallas
which uses gtt
gtt=tinet=nlayer=mzima
buut gtt/tinet seem to be tied heavier  than tinet/gtt<->nlayer
14  orochi-sov-interconnect.mythic-beasts.com (93.93.133.42)  98.887 ms  98.691 ms *
15  192.67.222.1 (192.67.222.1)  99.743 ms  99.704 ms  99.270 ms
liquidweb > cogent
yeah cogent is still bad
it's cogent for ipv6 and not working
and ntt is still bad too.
oh i may have level3 test site
the larger the network, the longer bgp takes to propagate?
level3 is going via trit but working
well ntt say they do their updates at 6 am utc
which is about two hours from now
so level3 and ntt aren't propogating directly yet
i've been testing from Ramnode's LGs as well - http://lg.la.ramnode.com/
there may be a double issue with cogent routes being shorter via the other path.
who do they uuse?
mercutio: oh man it gets better, apparently if you shorten an affiliate link, it'll get rewritten with bitly's affiliate id too
and you have to mnaulaly email them and ask to opt out that shortlink
hazardous: damn.
i hate url shortening
that's just over the top hilarious and sad
i think it's kind of nifty myself
i'd like to be bit.ly in this situation :)
also link rot if any shortener dies
i think people should just stop having 200+ character urls.
it's insane.
static: do you have a tunnel from old to new block?
s/block/advertisement/
<mercutio> static: do you have a tunnel from old to new advertisement?
hm? no tunnels are in place atm, im announcing at both because im experimenting with some ghetto anycast stuff
oh right
so you plan to keep advertising at both?
most likely yeah, i may be adding another location shortly
cool
i like anycast
it's hard to find cheap locations to do it thouugh
indeed
do you know where most of your audience is?
i was planning on using it for one of my authoritative nameservers, I get queries from all over the world but mostly NA; though i haven't taken a look at query sources in a while
cool
mercutio: what do you mean by "properly" trying bhyve? I've been running all my staging vm's in it for half a year
jbergstroem: err properly uusing it
so it's stable and works well?
i was trying to distinguish by just starting a vm to try it and seeing it seemed to work
mercutio: yep. i've had a few ups n downs, mainly because im on freebsd-current
but i'd say that the state in current is much improved from 10.1-release