act...@nanog.org seems to no longer exist. how should i be whining
about the following?
From: Electric Forest Festival
Subject: Forest HQ Has Received Your Message: Re: Hi-Rise Building Fiber
Suggestions
To: ra...@psg.com
Date: Wed, 26 Feb 2020 16:15:25 +
Electric Forest 2020 will take p
> What is more important to us is that the optics are multi-rate. And
> even more important now, is that our 3rd party optics suppliers can
> allow us to code and re-code optics to our heart's content.
i wish flexoptix did 400g DACs. we have two boxes from the same ODM
with interfaces whose sole
since we're at this layer, should i worry about going 3m with dacs at
low speed, i.e. 10g? may need to do runs to neighbor rack.
randy
>> What is an "ebony phone"? (Google results for that phrase are mostly porn.)
>
> https://www.ebay.com/itm/1950S-WESTERN-ELECTRIC-EBONY-BLACK-ROTARY-DIAL-DESK-TELEPHONE-/333465026527
at least the swedes knew basic arithmetic
https://www.ebay.com/itm/C-Late-40s-early-50s-Vintage-Swedish-Rotary-D
Prefix Send failed ! 103.199.169.0/24 bgp_rt_trace_too_big_message:1209
path attribute too big. Cannot build update.
lovely
randy
it has "Places Tracking the Data" but needs "Places Tracking You"
considering the javascript i had to enable in the scratch vm i spun up
to read it, i suspect this would be on that list.
randy
> It failed to scale for some of the exact same reasons QoS failed to
> scale - what works inside one administrative domain doesn't work once
> it crosses domain boundaries.
>
> Plus, there's a lot more state to keep - if you think spanning tree
> gets ugly if the tree gets too big, think about wh
> He's a network operator. From North America, on the North American Network
> Operators mailing list. Something you are not, so please stop spouting your
> drivel on a list that has nothing to do with you.
this is not how we should act in under pressure
> And like this short message about South Africa was highly useful for
> my country of residence, Lebanon, too. We are under full, quite severe
> lock-down, with fines, checkpoints and etc.
> Several ISPs here who kept NOC support (single person) near server
> room, in office - got fined too, as us
some of us still do uucp, over tcp and over pots. archaic, but still
the right tool for some tasks.
randy
ok, if IS-IS is kinda working on FRR, at least enough to get loopbacks
and external interfaces around a pop, i gotta ask.
anyone running a ubiquity edgerouter infinity with frr, is-is, and four
or so full bgp feeds?
randy
> from {
> source-address {
> 10.0.0.0/8;
> 100.64.0.0/10;
> 127.0.0.0/8;
> 169.254.0.0/16;
> 172.16.0.0/12;
> 192.0.2.0/24;
> 192.42.172.0/24;
> 192.168.0.0/16;
> 198.18.0.0/15;
> Just encode the router loopback IPv4 address in the system identifier bytes
> and call it a day.
i think asp wrote this up back in the early '90s. anyone have a cite?
randy
Apr 12 17:57:42 r0.iad rpd[1752]: Prefix Send failed ! 103.148.41.0/24
bgp_rt_trace_too_big_message:1209 path attribute too big. Cannot build update.
so some idiot is barfing out a ridiculous as_path. dear lazynet, is
there an easy way to get attribution for this stupidity? i.e. the
as_path.
e
> In y'all's opinion, do you prefer/recommend using base-10 digits or
> hex in your NSAP addresses?
it's the decimal representation of the octets
lo0 {
description "main loopback";
unit 0 {
family inet {
address 127.0.0.1/32;
address
> I’m using CAIDA’s bgpreader and this one looks like it might be an
> example of what you want.
>
> R|R|1586714402.00|routeviews|route-views.eqix|||2914|206.126.236.12|103.148.41.0/24|206.126.236.12|2914
> 58717 134371 134371 134371 134371 140076 140076 140076 140076 140076 140076
> 140076
> From a practical standpoint, this doesn't actually tell the whole truth
indeed. route origin validation, while a good thing, does not make
bgp safe from attack. this marketing fantasy is being propagated;
but is BS.
origin validation was designed to reduce the massive number of problems
cause
> Anyhow I think some people think about RPKI in a way too binary manner
> 'because it is not secure, it is not useful'. Yes, AS_PATH
> authenticity is an open problem, but this doesn't mean RPKI is
> useless. Most of our BGP outages are not malicious, RPKI helps a lot
> there and RPKI creates a hi
>> essentially agree. my pedantic quibble is that i would like to
>> differentiate between the RPKI, which is a database, and ROV, which
>> uses it.
>
> And I think that is a very important distinction to be clear about.
> Right now, it's not completely arrest-worthy to use RPKI and ROV
> interch
> I think you just need to let scripts run in your browser for
> nanog.org.
sad. http://nanog.org used to be the brilliant example of a fully
featured web site sans javascript, flash, ...
randy
>> Another member of the illegal anonymous organization "The Spamhaus Project".
> wait, what?
be proud. i like spamhaus. solid, responsive, and responsible.
randy
> I tend to read email with EMACS/VM.
fwiw, i moved from VM to Wanderlust a dozen years ago; if i remember
aright, for better imap support. both have kill thread in current
messages. neither remembers the kill order for newly received msgs a
la nn et alia.
randy
< note that i am wearing arrcus hat >
> I'll be honest, none of our customers ever asked us to deploy RPKI and
> ROV. Will they benefit from it, sure? Is it about to become part of an
> RFP requirements document? Probably not.
we have rov in rfps received from paying customers
randy
chris at the ever fantastic six has done a stunning bit of work to let
six members see rpki/irr announcement issues
https://www.seattleix.net/rs-drops
randy
>> we have rov in rfps received from paying customers
> I hope this becomes the norm, globally.
charlie lynn wrote the first rpki draft in 1999. the steves
shanghaied me in 2000. considering it took eight years for the
ietf to change a constant of 4k to 64k, rpki/rov is moving right
along at a swi
>> when Google got people worried about dropping routes.
> That may have an impact down the road, but I doubt that really had
> that much impact on current deployments.
i suspect different folk moved for various reasons. i appreciate the
motion.
while things are moving, the problem is that techn
> Do you remember the old BSD paradigm? ... "less is more"
s/bsd/mies/ credit where due.
> We are now in a time where a *smaller* routing table entry list count
> is preferable to a 'full' table, because the fullest table is likely
> to also include problematic BGP routing information.
do yo
>> Do you remember the old BSD paradigm? ... "less is more"
> s/bsd/mies/ credit where due.
recant. it was well before mies. i was just raised by and architect,
and had uni roomies who were in the architecture school mies founded.
so my own narrow vision. sorry.
randy
> Maybe this is fundamental and unavoidable, maybe some systematic bias
> in human thinking drives us towards simple software and complex
> hardware.
how has software progressed in the last 50-70 years as compared to
hardware?
my watch has how many orders of magnitude of compute vs the computer
w
> MPLS was since day one proposed as enabler for services originally
> L3VPNs and RSVP-TE.
MPLS day one was mike o'dell wanting to move his city/city traffic
matrix from ATM to tag switching and open cascade's hold on tags.
randy
< ranting of a curmudgeonly old privileged white male >
>>> MPLS was since day one proposed as enabler for services originally
>>> L3VPNs and RSVP-TE.
>> MPLS day one was mike o'dell wanting to move his city/city traffic
>> matrix from ATM to tag switching and open cascade's hold on tags.
> And II
>> The requirement from the E2E principle is that routers should be
>> dumb and hosts should be clever or the entire system do not.
>> scale reliably.
>
> And yet in the PTT world, it was the other way around. Clever switching
> and dumb telephone boxes.
how did that work out for the ptts? :)
> Perhaps BGP Alerter is a solution for you:
> https://github.com/nttgin/BGPalerter
yes! very happy user here. i run it into the slack api.
randy
> If you don't use some kind of device to connect to Netflix, if you
> have a reasonably modern TV that supports a native Netflix app as
> well as IPv6, you'd be good to go.
think of the burden on the netflix customer support of HE's IPv6
tunnels.
randy
>> I find there's a strong INVERSE correlation between the quantity of
>> certificates on an applicant's resume and their ability to do the
>> job.
>
> Never got a certificate, don't want one either :)
but now you can get an ncc certificate, certifying that you can actually
use their product. ho
> I’m leaning toward DS-lite and NAT444
a great path. fork lift all cpe and cgn in the core. the vendors'
dream
randy
> OK Randy. How about a suggestion that is useful.
>>> I’m leaning toward DS-lite and NAT444
>> a great path. fork lift all cpe and cgn in the core. the vendors'
>> dream
$subject. map-e. ... the list is long. ds-lite is close to the bottom
of it, except if you are a vendor salesperson.
rand
i backup using arq on macos catalina. on two macs, i need maybe 3-4tb
max. google seems to be $100/mo for 20tb (big jump from $100/yr for
2tb). backblaze b2 looks more like $20/mo for 4tb ($0.005/gb/mo).
anyone else done a similar analysis?
randy
well, i was once given a tee shirt which said
"i may have helped build the information
superhighway, but i can not drive a car" :)
after work, a time which rarely occurs, we're all
end users. and if you're not concerned about
backup, ...
randy
> Just out of curiosity, do you folks encrypt the data prior to upload
> to the cloud
uh, ja
so i was trying to ensure i had a current set of TALs and was directed to
https://www.ripe.net/manage-ips-and-asns/resource-management/certification/ripe-ncc-rpki-trust-anchor-structure
the supposed TAL at the bottom of the page is pretty creative. anyone
know what to do there?
i kinda hac
> i kinda hacked with emacs and get
>
> rsync://rpki.ripe.net/ta/ripe-ncc-ta.cerpublic.key.info
>
>
> MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2myBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV2pFBFeQAvoH/WK83HwA26V2siwm/MY2nKZ+Olw+wlpzlZ1p3Ipj2eNcKrmit8BwBC8xImzuCGaV0
> why is it so hard that all RIRs make their TAL files available under
> the same URL path but different hosts, e.g., https://ripe.net/rpki/tal,
> https://arin.net/rpki/tal ?
no, you are supposed to get TRUST material from alex's secret stash.
sigh.
it should be a dnssec lookup of ripe.net, t
> I dunno, 'straightforward' to me would mean the ARIN TA is installed by
> default when you install a RPKI Cache Validator implementation
uh, i want a trustable downlad of trust anchors. and it ain't from
vendors.
but yes, arin's legal dos it typical arin. but, if i ignore the bumph,
i can con
> I know that a shortage of IPv4 addresses has been anticipated for
> quite some time (literally decades), however, is there a shortage
> *right now*?
yes, ipv4 space is tight
> our per IPv4 address price to $2.00 per IP.
open market is O($20) per host address. that is 'buying' it. and then
yo
> https://tal.rpki.ripe.net/ripe-ncc.tal (preferred)
looks great visually. stuffed in a dragon validator, just for qa.
thanks!
randy
> We've also simplified our webpage:
> https://afrinic.net/rpki/tal
>
> And the URL to the TAL:
> https://rpki.afrinic.net/tal/afrinic.tal
thanks! wfm
randy
> To John and the others that have responded thanks for all the
> explanations. It makes things a lot clearer now.
ripe/ncc and isoc/manrs have some gl!tzich webinarz etc on all this
randy
> Some might suggest that a lot of time was spent debating how to do it
> with little actual progress or experimentation done.
this is the internet. some have suggested pretty much anything.
for the historians in the audience, the first s-bgp, what we would now
call testathon i guess, was held a
the RFO is making the rounds
http://seele.lamehost.it/~marco/blind/Network_Event_Formal_RFO_Multiple_Markets_19543671_19544042_30_August.pdf
it kinda explains the flowspec issue but completely ignores the stuck
routes, which imiho was the more damaging problem.
randy
creative engineers can conjecturbate for days on how some turtle in the
pond might write code what did not withdraw for a month, or other
delightful reasons CL might have had this really really bad behavior.
the point is that the actual symptoms and cause really really should be
in the RFO
randy
> we don't form disaster response plans by saying "well, we could think
> about what *could* happen for days, but we'll just wait for something
> to occur".
from an old talk of mine, if it was part of the “plan” it’s an “event,”
if it is not then it’s a “disaster.”
would folk familiar with the north american RIR and IRR registries be
kind enough to suggest how this might adapt? thanks.
A new version of I-D, draft-ymbk-opsawg-finding-geofeeds-02.txt
has been successfully submitted by Randy Bush and posted to the
IETF repository.
Name: draft-ymbk
hi camron
sad to say, the days of faxing around number assigments have passed.
the kiddie googlers who wrote the geofeeds rfc probably have not even
seen a fax machine. they just did not like having a hundred gnomes in
the basement dealing with everybody's formats. given silicon valley
housing c
yang,
> Why not publish RFC8805 Geofeed directly in inetnum remarks section?
for some flat fan out last kilometer providers that could be the
inetnum: object from hell. there are global providers which segment
large prefixes over diverse areas. etc.
i doubt the rpsl providers would like multi-
hi ca
> I gave your I-D a try in the real world, and it does not work with a
> major player.
i.e. arin and radb, your region, which does not do rpsl as others do.
we know this, which is why the OP $subjest was
"how would draft-ymbk-opsawg-finding-geofeeds work in noam?"
> I thought you might
>> we are not expecting these lookups to be done frequently. i agree that
>> would hammer servers, both rpsl and geofeed. do you have stronger words
>> to suggest than
>>
>>5. Operational Considerations
>>...
>>An entity fetching geofeed data through these mechanisms MUST NOT do
>>
i get 50 times as many emails bitching about cogent spam as i get cogent
spam. and my spam filter is trained to take care of the latter.
randy
the edit buffer, yet to be published, has
Currently, the registry data published by ARIN is not RPSL;
therefore, when fetching from ARIN whois, the "NetRange" attribute/
key must be treated as "inetnum" and the "Comment" attribute must be
treated as "remarks".
comments appreciated
ra
[ am i going to regret cross-posting? ]
a friend raised in private the question of whether the dns could be used
instead of rpsl.
essentially, dns does not search down-tree for you. it only answers
exact specific queries. for some reason lost in time, well at least
lost in my mind, rpsl servers
>> the edit buffer, yet to be published, has
>>
>>Currently, the registry data published by ARIN is not RPSL;
>>therefore, when fetching from ARIN whois, the "NetRange" attribute/
>>key must be treated as "inetnum" and the "Comment" attribute must be
>>treated as "remarks".
>>
>> co
> Would your arin approach of netrange work in all regions?
no. to the best of my knowledge, other regional registries and
independent irr registries use rpsl; i.e. inetnum: and remarks:.
randy
> Radb only supports
again, north america is a special snowflake. radb is a routing
registry, not an allocation registry. inetnum: and NetRange: are
allocation objects.
if you get your address space from arin, you have to use their
webby stuff to add the Comments: to the allocation object.
> I'm still learning, but, It does seem interesting that the IP layer
> (v6) can now support vpn's without mpls.
as the packet payload is nekkid cleartext, where is the P in vpn?
> GRE, VXLAN or any other tunneling encap of the day.
> As long as next-hop could be resolved behind remote end
i was not aware that GRE, VXLAN (without CN103618596A), and other tunnel
encaps encrypted the payload. learn something new every day. thanks!
>>> I'm still learning, but, It does seem
perchance is RDAP implemented by all RIRs?
randy
> You might be on to something, but I'm unsure... are you suggesting that it's
> any less private over SRv6 than it was over MPLS ?
neither srv6, srmpls, mpls, gre, ... provide privacy. they all
transport the payload in nekkid cleartext.
Dance like no one's watching. Encrypt like everyone is.
> So, I was searching on how to solve that and I found a draft (8th release)
> with the intention to solve that...
> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
>
> If understood correctly, the effective implementation of it will depend on
> new code on any BGP engine that will want to do
> Privacy != encryption.
cleartext == privacy * 0
cleartext * complexity == privacy * 0
randy
>>> So, I was searching on how to solve that and I found a draft (8th release)
>>> with the intention to solve that...
>>> https://tools.ietf.org/html/draft-ietf-idr-rs-bfd-08
>>>
>>> If understood correctly, the effective implementation of it will depend on
>>> new code on any BGP engine that will
> It depends on the definition of VPN.
in my definition, the P stands for privacy not plaintext
> In terms of services like MPLS-based VPNs, it refers to the extension
> of a Private network over a shared infrastructure, allowing entities
> using the shared infrastructure to have their own privat
$ubject changed as it is now where to put the pointer
[ we have email suggesting putting the geoloc pointer in dns, routing
databases, ... no one has suggested bgp yet, but i assume it is
coming ]
> I assume that someone (entity) publishes a geo-feed
> I assume that location of this feed (a
> a) Check if there is anything hindering the evolution of this draft to
> an RFC.
was i unclear?
> the draft passed wglc in 1948. it is awaiting two
> implementations, as is the wont of the idr wg.
randy
> Information can be in plaintext and private
Three can keep a secret, if two of them are dead. -- franklin
i know you truely believe the tunnel k00laid. the security
community does not.
randy
> One thing that is true: not all present or historical definitions
> (or acceptable uses) of the word "private" strictly imply or infer
> privacy.
newspeak -- 1984
> I already taught my SpamAssasin and then deleted them
:0
* ^From:.*@csvwebsupport.com
| /usr/bin/mail -s 'Screw You' dating.supp...@csvwebsupport.com <
~/screw-you.txt
james,
> I'm not sure what you're saying here, I never said MPLS VPNs are
> secure, only private. I hope others recognise that they are
> different concepts.
yes, privacy is one aspect of security. and, as mpls vns are not
private sans encryption, they are not secure.
randy
have folk looked at https://github.com/nttgin/BGPalerter
randy
> Does anyone have a quick answer as to what public data sources are
> used? I tried looking at the main github page for the project but I
> either missed it or it isn't there.
>
>> have folk looked at https://github.com/nttgin/BGPalerter
ripe/ncc bgp stream
> Marco Marzetti (PCCW) wrote an even faster compression tool!
> https://github.com/lamehost/aggregate-prefixes
>
> Both these python implementations are meant as replacements for ISC's
> vintage 'aggregate' Unix utility, with the notable difference that they
> also support IPv6.
ok, i gotta ask.
>> ok, i gotta ask. has someone tested to see if they all produce the
>> same result givem the same input? i do not mean to imply they do
>> not. i just have to wonder.
>
> Yes, of course. Marco and I collaborated on the tool's regression
> testing.
>
> job@bench $ aggregate6 < dfz_ipv4
> Is it fair to say that an NGFW *must* decrypt SSL traffic in order to
> fully categorize for IPS/IDS prevention?
well, not really. aside from damage, it will not 'protect' you against
more modern transports, such as quic, which were designed to keep the
net open.
randy
we all, in true nanog tradition, sure do talk a lot. but, to repeat,
i put my money where my mouth is. you should too.
https://www.tespok.co.ke/?page_id=14001
randy
again, do not be distracted by the rather obvious DoS on this list. our
administrative infra is being attacked. defend it by putting your money
where your mouth is.
https://www.tespok.co.ke/?page_id=14001
i did and will again.
randy
this amazing thread is so new, fresh, and enlightening. why has no one
brought these facts and ideas up before? just wow!
randy
to control inbound traffic, how do bgp optimizers decide how to tune
what they announce? slfow? exploration? ouija board?
randy
>> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
>> whichever it is, then they'd of course have to start moving too,
>> because no upstream.
>
> And they would fight it tooth and nail, just like they do now
you speak as if it was religion or they are bad people. neither is
> Edicts never work. More carrot, less stick.
but the ipv6 stick has worked so well over the last 25 years
> I doubt many vendors were chomping at the bit to support CGNAT
definitely. they hate to sell big expensive boxes.
randy
< rant >
ipv6 was designed at a time where the internet futurists/idealists had
disdain for operators and vendors, and thought we were evil money
grabbers who had to be brought under control.
the specs as originally RFCed by the ietf is very telling. for your
amusement, take a look at rfc 2450.
> it's easy to be critical of design decisions with 25y of hindsight
there was a good number of senior implementors and ops who screamed
loudly at the time. to no avail.
randy
and 8+8, variable length, ... just didn't happen, eh?
the nice thing about revisionist history is that anybody can play.
randy
> I wasn't there at actual meetings at the time
but your opinion was?
> but I find the notion that operators were ignored pretty preposterous
> too
so did we, the ops who were there at the time
randy
> Just because I didn't attend IETF meetings doesn't mean that I didn't
> read drafts, etc. Lurkers are a thing and lurkers are allowed opinions
> too.
i missed the rfc where the chair of the v6 wg said the ops did not
understand the h ratio because we did not understand logarithms.
randy
your memory of the procedural details is better than mine. you have my
sympathies. i was focused on the technical disater that has cost us
decades. but folk who i still consider friends were willing to throw
dren at the wall hoping it would stick so the ietf/iana was not taking
crap in the press
> Heh, NAT is not that evil after all. Do you expect that all the home
> people will get routable public IPs for all they toys inside house?
in ipv6 they can. and it can have consequences, see
NATting Else Matters: Evaluating IPv6 Access Control Policies in
Residential Networks;
Kar
>> the ietf did not give guidance to cpe vendors to protect toys inside
>> your LAN
> guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is
> likely to impact all of our security 'requirements'. :(
that point was made in the paper i cited
> I also thought 'homenet' (https://da
do folk use uPRF strict mode? i always worried about the multi-homed
customer sending packets out the other way which loop back to me; see
RFC 8704 §2.2
do vendors implement the complexity of 8704; and, if so, do operators
use it?
clue bat please
randy
> https://datatracker.ietf.org/doc/html/rfc6092
good stuff. thanks.
> A partial table with no default is perfectly fine for a peering router.
>
> As long as your peering router knows how to get to your prefixes and
> those of your customers, as well as the prefixes of the networks you
> peer with, you're good to go.
in fact, this seems to be the modern conservati
101 - 200 of 2197 matches
Mail list logo
