Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations
John, Alex, Romeo,
Fri, Mar 17, 2017 at 12:31:06PM +0100, John Curran wrote:
> We are aware there’s an issue and working on it presently with RIPE.
> Expect additional updates shortly.
Fri, Mar 17, 2017 at 12:50:48PM +0100, Alex Band wrote:
> You can find a detailed announcement from the RIPE NCC here:
> https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
> <https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html>
Fri, Mar 17, 2017 at 12:52:10PM +0100, Romeo Zwart wrote:
> RIPE NCC have issued a statement about the issue here:
>
> https://www.ripe.net/ripe/mail/archives/dns-wg/2017-March/003394.html
>
> Our apologies for the inconvenience caused.
Thanks for your work: the issue seem to be fixed. I am trying to
verify if everything works as expected, there are some neats,
{{{
206.144.in-addr.arpa. 172800 IN NS ns1.rrcki.ru.
206.144.in-addr.arpa. 172800 IN NS ns.kiae.ru.
206.144.in-addr.arpa. 172800 IN NS ns3.rrcki.ru.
206.144.in-addr.arpa. 172800 IN NS ns2.grid.kiae.ru.
206.144.in-addr.arpa. 172800 IN NS ns.grid.kiae.ru.
206.144.in-addr.arpa. 10800 IN NSEC207.144.in-addr.arpa. NS RRSIG
NSEC
206.144.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20170331110430
20170317100430 33345 144.in-addr.arpa. vbFwaKdRa7Jd70aAbJ
5mC37BsTzMg3nWVI5gqQLLOqSaCZfH0XUez+Uk
MbTNvepziCRzH+HgSLabuvRSo4nIUP1SjOd2WX0wySSdb/blqhfmjw3l
n8laqOxy/lj8TDiIuxOdw2JhM1v5x/DH4aDnwdGFfUEOdgzCU5k8LdAT oyA=
;; Received 373 bytes from 199.180.180.63#53(r.arin.net) in 198 ms
;; Question section mismatch: got 206.144.0.0.in-addr.arpa/PTR/IN
;; Question section mismatch: got 206.144.0.0.in-addr.arpa/PTR/IN
206.144.in-addr.arpa. 3600IN SOA ns.kiae.ru. noc.rrcki.ru.
2017020803 10800 3600 180 3600
;; Received 105 bytes from 144.206.239.1#53(ns.grid.kiae.ru) in 0 ms
}}}
about question mismatch, though my guts feel that this is the local
issue at rrcki.ru.
Thanks again! And for a nicely-written summary -- too.
--
Eygene Ryabinkin, National Research Centre "Kurchatov Institute"
Always code as if the guy who ends up maintaining your code will be
a violent psychopath who knows where you live.
Re: [NOC] ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations
Job, good day.
Fri, Mar 17, 2017 at 09:55:56AM +, Job Snijders wrote:
> 171 also seems affected.
Not the whole one, it seems:
{{{
$ dig +trace -t soa 1.171.in-addr.arpa
; <<>> DiG 9.10.4-P6 <<>> +trace -t soa 1.171.in-addr.arpa
;; global options: +cmd
. 202634 IN NS m.root-servers.net.
. 202634 IN NS i.root-servers.net.
. 202634 IN NS k.root-servers.net.
. 202634 IN NS c.root-servers.net.
. 202634 IN NS a.root-servers.net.
. 202634 IN NS d.root-servers.net.
. 202634 IN NS l.root-servers.net.
. 202634 IN NS e.root-servers.net.
. 202634 IN NS g.root-servers.net.
. 202634 IN NS b.root-servers.net.
. 202634 IN NS j.root-servers.net.
. 202634 IN NS h.root-servers.net.
. 202634 IN NS f.root-servers.net.
. 511016 IN RRSIG NS 8 0 518400 2017032917
2017031616 61045 . OjsjoA6WCcThV3BqhAyMaXI3bU1m228Gl8nvaR074qBtem/RjaFJh1Oe
r7LPI6W15jgbRGuCY7/GUNgDex4ZM43yvx2iY+2GpSk9b2/pKGbDaDIp
X1Hd8418206eow1P/SgPqtT+2LzjM+lz/HKUvCyPoN4uX5/7GDExn8ir
2Q/vw81Za2nJ4Ji6oeGAmE8g6V3RJfTI0El/CP9Vl2/r0jWDZZ+wtYRA
uwqvQYj+7VZc5+UJDJ3/Gne1LBnzXKnZRwnfJtZenhfZ7X20D9PiXvfJ
M2s1ryqZvg8K5RqYt/r8pIiq1Udd1KWQBgdN7Q629+jNSngZQtH19R9H fM7h1w==
;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 47054 8 2
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN DS 53696 8 2
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 63982 8 2
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 2017033000
2017031623 33786 arpa.
gqNN6MmLVxFtSG0oxdyoYVSXZlp6vY9yxpnJW89TYCHfTkv+ZmklM76O
IHdTznEhLHXbyr4BaxjFCshsC3WacdH/YZYa/SZynJ9Q1N6/bogrIUTn
qs61Y/YD4Sk5lI7YvUxVnPrF3lk1pY8dpoTkprTLZngoeQEsm552inqG ypU=
;; Received 731 bytes from 193.0.14.129#53(k.root-servers.net) in 41 ms
171.in-addr.arpa. 86400 IN NS ns1.apnic.net.
171.in-addr.arpa. 86400 IN NS ns2.lacnic.net.
171.in-addr.arpa. 86400 IN NS ns3.apnic.net.
171.in-addr.arpa. 86400 IN NS ns4.apnic.net.
171.in-addr.arpa. 86400 IN NS apnic.authdns.ripe.net.
171.in-addr.arpa. 86400 IN NS apnic1.dnsnode.net.
171.in-addr.arpa. 86400 IN NS tinnie.arin.net.
171.in-addr.arpa. 86400 IN DS 49699 5 1
0240801C96480900CC6D93130AF45CFE86EDE940
171.in-addr.arpa. 86400 IN DS 49699 5 2
6E0BA96F05B4D39C1668979731E040213BB6130DE33E86E063B5F7F7 5C465C88
171.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20170330042932
20170309125911 4341 in-addr.arpa.
RKcPZJdG1MBrwpfa1mIK7ikIU585i1Jv+UkEBHxuM3BxxAbD+ht0W04C
ljboyXJfYK8ly/YTDqNUkWKZLwDHlkq/rgNwTG63sPT8iK8qya+2qUVB
iTXVsD2HaV1V/KwgJjlWHRNnlwkK0YZ5Q7tevXaq4yyLT2Q2mu5dkhFC evNQOyI=
;; Received 482 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 69 ms
171.in-addr.arpa. 0 IN SOA ns1.apnic.net.
read-txt-record-of-zone-first-dns-admin.apnic.net. 5276 7200 1800 604800 172800
171.in-addr.arpa. 0 IN RRSIG SOA 5 3 172800 20170416100102
20170317090102 7858 171.in-addr.arpa.
dH+uuGq9pgMc9TEMkTwrf9NGMj5zFnbZt3kjlNSF0kPzGk3WUr5g84jv
0SN88Y26eP/Op4Vv8JewyVu2IT1POnmiNpDYELkJxrTWnPPc6CJ2wugR
TrFLOq6eIsqtrCcWbatQ7XSXXj1UglqVVydlX1ExoIh9MdP+1eBneD1I 4OU=
171.in-addr.arpa. 172800 IN NSEC10.171.in-addr.arpa. NS SOA TXT
RRSIG NSEC DNSKEY
171.in-addr.arpa. 172800 IN RRSIG NSEC 5 3 172800 20170416100102
20170317090102 7858 171.in-addr.arpa.
QieHZ0W7jx3QCgLuvqtKtFoLPYkxn5R9nRO1oMbSSXkdF+S4iQQkVlX7
DyQvoL69hKA+S9idfernf6DwNTQgeWFfCdjUyOjMCa3Ag/S8ARZs7K4F
N9DxB/cBCZm7KTzwAzXFe3cJ/d1Wo45Tx9jf6Drx551oqOw1gmDIL4y6 +k4=
;; Received 530 bytes from 202.12.31.140#53(ns4.apnic.net) in 347 ms
}}}
since it is APNIC who respond to queries about it. Any more specific
reverse records that are cross ARIN and die there from 171.x.y.z?
--
Eygene Ryabinkin, National Research
ARIN contact needed: something bad happens with legacy IPv4 block's reverse delegations
ed too (at least). ARIN tickets are engaged, but I am seeking some live person: having the whole reverse zone being unavailable isn't the stuff that is to be handled in 5x8 or alike. If anybody knows what happened, can point me to my errors in assertions or give an e-mail/phone of 24x7-like person or service at ARIN -- will be tremendous. Thanks! -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey
Sun, Sep 25, 2016 at 05:57:42PM -0400, Patrick W. Gilmore wrote: > Remember University of Wisconsin vs. D-Link and their hard-coded > NTP server address? UW vs Netgear and Poul-Henning Kamp vs D-Link, both on NTP stuff? -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Strange Problem with 16 byte packets
Thu, Jun 16, 2016 at 03:06:24PM +0530, Glen Kent wrote: > Thanks i will. However, the doubt is that what does introducing a 16 byte > data into the steam does that causes the session to time out. I added > instrumentation to push some dummy data so that instead of 16 bytes, we > push 1 MB of data. In that case i saw no issues. Any idea if there is a > firewall setting that could be coming into play here? Collect TCP dumps from both sides, come back and show that (or analyze yourself ;) -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: IPv6 is better than ipv4
Rubens, good day. Thu, Jun 02, 2016 at 01:32:29PM -0300, Rubens Kuhl wrote: > On Thu, Jun 2, 2016 at 11:47 AM, Ca By <cb.li...@gmail.com> wrote: > > > > > https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html > > > > Wherein akamai explains a detailed study showing ipv6 is "well > > over 10%" faster than ipv4 on mobile, and they reference corroborating > > studies from Linkedin and Facebook. > > > > Says the company that consistently refused to dual-stack its customers by > default... What's your point? Does their technical reasoning or proving grounds for it lacking the needed expertise/experience due to the problems you're describing? Any other thigs you can say about the actual study? -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: LACP Frames / Level3 Transport
Tue, May 24, 2016 at 12:39:03PM +, Nevin Gonsalves wrote: > I just had to sit and trace all the cables to make sure the tx/rx > lined up for the right circuits as well as hitting the right patch > panel ports. Once all that got aligned nicely things started working > magically. Yep, ports in an "up" state, but LACP not working is the sign of bad cabling: had been hit by this overnight once when I was preparing to leave the facilities next day for conference, but ought to make 10G for the new servers working. Took around 1/2 hour to sense what happened at that time (tx was going to, say, port A and rx -- to port B, but overall all ports were receiving tx and rx) and 3 hours for rewiring and swearing: probably I am more skilled in the former than in the latter ;) Thought that you had checked this in the first place; my bad. Thanks for sharing! -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: LACP Frames / Level3 Transport
Nevin, good day. Sun, May 22, 2016 at 07:55:31PM +, Nevin Gonsalves via NANOG wrote: > Hoping someone may have come across a similar issue. Has anyone ever > seen a situation where maybe like a Level3 transport system could be > possibly dropping LACP frames..? > End point A - tx and rx counts incrementing for LACP > LACP info: Role System System Port Port Port > priority identifier priority number > key et-0/0/0.0 Actor 127 5c:45:27:6d:2a:c0 127 > 56 16 et-0/0/0.0 Partner 1 00:00:00:00:00:00 127 > 56 16 LACP Statistics: LACP Rx LACP Tx Unknown Rx > Illegal Rx et-0/0/0.0 6925 6922 0 > 0 > End Point B - no RX, partner macs are 0s.. > LACP info: Role System System Port Port > Port priority identifier priority > number key et-9/1/0.0 Actor 127 5c:45:27:77:d6:c4 > 127 68 16 et-9/1/0.0 Partner 1 00:00:00:00:00:00 > 1 68 16 LACP Statistics: LACP Rx LACP Tx Unknown > Rx Illegal Rx et-9/1/0.0 0 6752 0 > 0 > Link works fine otherwise outside the aggregate and w/o LACP. Any > inputs will be greatly appreciated. Cisco Q-in-Q implementation in some configurations (details are blurry, since our provider turned to X-connect quite fast). Also VPLS implementation in (older) EXOS releases (Extreme Networks), https://gtacknowledge.extremenetworks.com/articles/Solution/Layer-2-Control-packets-like-STP-LACP-EDP-etc-are-not-passing-through-VPLS -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: NIST NTP servers
Wed, May 11, 2016 at 05:20:28PM -0700, Scott Weeks wrote: > --- m...@beckman.org wrote: >> From: Mel Beckman <m...@beckman.org> >> >> Accurate time to the millisecond is pretty much >> essential for any network troubleshooting. Say >> you want to diagnose a SIP problem. You collect >> transaction logs from both phones, the VoIP >> gateway, and the PBX. Now you try to merge them >> to derive the sequence of events. You NEED >> millisecond accuracy. >> > > If all logs are sent to a unix server that does > syslogd the log entries would go into the file > in order no matter what timestamp is on them. Modulo latencies and jitter from different machines to the log server. Millisecond precision can be harmed by this, easily. Especially by jitter and order of millisecond here isn't something non-existent in a long-distant networks. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: NIST NTP servers
Tue, May 10, 2016 at 04:59:02PM +0200, Stephane Bortzmeyer wrote: > On Tue, May 10, 2016 at 10:52:28AM -0400, > valdis.kletni...@vt.edu <valdis.kletni...@vt.edu> wrote > a message of 37 lines which said: > > > Note that they *do* have motivation to keep it working, simply > > because so much of their *own* gear (from gear for individual > > soldiers all the way to strategic bombers and aircraft carriers) > > wants a working GPS signal... > > Yes, but they may switch it off for civilian use (by going encrypted, > for instance) at any time, if it is better for *their* operations. Civilian signals are already degraded in terms of accuracy (without assisted GPS) and military ones are encrypted (but see [1]). The primary reason for encryption is, by the way, to address spoofing issues for the mil people themselves, but it is also good not to arm the potential enemy with the precise coordinates or to be able to do spoofing for them. And since many civilian, but nonetheless, vital orgs are using civilian parts, it could be hard to shut it off without affecting some parts of the infrastructure. Not that nobody wants that, but it will give an unneeded resonance and could lead to the terrible mess. [1] http://www.gps.gov/technical/codeless/ -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: sub $500-750 CPE firewall for voip-centric application
Fri, May 06, 2016 at 09:51:15PM +0200, Mark Tinka wrote: > On 6/May/16 21:40, Josh Reynolds wrote: > > I've been very happy with the 2.3 release. Modularizing everything and the > > new bootstrap GUI is very nice. Updated BSD code base is a godsend. > > I was just about to ask the experienced coders whether the new GUI in > 2.3 fixes a lot of problems of the past... > > And yes, 2.3 is running FreeBSD 10.3. Just use FreeBSD without pfSense stuff -- it is easier ;)) Modulo the absence of the network-based installation for FreeBSD via PXE [1] out of the box (well, it is doable, but I'd prefer to have an easier way and Linuxen have that), so large-scale stuff is a bit tough. Was discussed several times in FBSD lists, big players have their own homegrown stuff from the early days of the universe, others are either not doing that or relying on the existing recipes. And there are not sufficient others of the big $SCALE :( [1] Something I'm trying to find the time for the past 5-6 years, should finally do that. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Latency, TCP ACKs and upload needs
Wed, Apr 20, 2016 at 07:27:53AM -0700, Leo Bicknell wrote: > 90%+ of the stacks deployed will be too small. Modern Unix generally > has "autotuning" TCP stacks, but I don't think Windows or OS X has > those features yet OS X since ~10.5 has autotuning, here are some hints from ESnet https://fasterdata.es.net/host-tuning/osx/ Personally never tried this on the sat-type RTT. As explained, scaling factor of 3 is a limiting one for high-performance transfers. For sat links may limit the things too, since 64K * 2^3 / 0.9 ms RTT * 8 ~ 4.5 Mbit/sec, but one's mileage may vary. And, of course, packet loss can turn down this BDP-derived speed drastically. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. signature.asc Description: PGP signature
Re: DataCenter color-coding cabling schema
Sun, Mar 13, 2016 at 05:10:26PM -0700, Owen DeLong wrote: > Whatever you do, please do not use Flag labels on cables… I HATE > THEM. They are a constant source of entanglement and snags. They > often get knocked off as a result or mangled beyond recognition, > rendering them useless. Hadn't seen that for ages, using Brother P-touch printers for small amounts of work and Avery Zweckform paper + laser printing for large cable installations. This stuff (Avery paper), http://computing.kiae.ru/~rea/wiring-porn-2.jpeg lives already for 5+ years and outlived many replacements of spine modules (that's InfiniBand fabric) and other operations without labels being ruined in any way. -- Eygene Ryabinkin, National Research Centre "Kurchatov Institute" Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Broken SSL cert caused by router?
Thu, Mar 26, 2015 at 03:38:55PM -0700, Mike wrote: I have a customer however that uses our web mail system now secured with ssl. I myself and many others use it and get the green lock. But, whenever any station at the customer tries using it, they get a broken lock and 'your connection is not private'. The actual error displayed below is 'cert_authority_invalid' and it's Go Daddy Secure Certificate Authority - G2. And it gets worse - whenever I go to the location and use my own laptop, the very one that 'works' when at my office, I ALSO get the error. AND EVEN WORSE - when I connect to my cell phone provided hotspot, the error goes away! As weird as this all sounds, I got it nailed down to one device - they have a Cisco/Meraki MX64W as their internet gateway - and when I remove that device from the chain and go 'straight' out to the internet, suddenly, the certificate problem goes away entirely. How is this possible? Can anyone comment on these devices and tell me what might be going on here? Sounds like deep packet inspection (DPI) with SSL MITM. Reading https://meraki.cisco.com/lib/pdf/meraki_datasheet_mx.pdf makes me believe that this device can do that. Look for it's configuration, DPI for HTTPS must be active. -- Eygene Ryabinkin, National Research Centre Kurchatov Institute Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Frontier: Blocking port 22 because of illegal files?
Wed, Mar 25, 2015 at 07:31:35PM -0700, Aaron C. de Bruyn wrote: Just a friendly heads-up to anyone from Frontier who might be listening, I have a few additional ports you may wish to block: 80 - Allows users to use Google to search for illegal files 443 - Allows users to use Google to search for illegal files in a secure manner 69 - Allows users to trivially transfer illegal files 3389 - Allows users to connect to unlicensed Windows machines 179 - Allows users to exchange routes to illegal file shares 53 - Allows people to look up illegal names Can't help to add that there are - port 21 that allow users to give commands to examine the existence and initiate transfers of illegal files; - ports 1025 - 65535 that allow users to create data streams to actually transfer illegal files in an (oh my) passive mode. ;) -- Eygene Ryabinkin, National Research Centre Kurchatov Institute Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Low BW between Mountain View and OR -- why?
Tue, Feb 17, 2015 at 11:47:04AM +0530, Glen Kent wrote: I have a server in Mountain View and i am doing a speedtest with a server in Oregon. I see that the upload/download BW that i am getting is low -- around 10.0Mbps and 5.0Mbps. gkent@ubuntu:~/ics$ speedtest-cli --server 4082 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Eastern Oregon Net, Inc. (La Grande, OR) [913.33 km]: 120.959 ms Testing download speed Download: 5.08 Mbits/s Testing upload speed.. Upload: 10.89 Mbits/s When i check my connectivity with a server in NYC, its much better, though the server is much further away. gkent@ubuntu:~/ics$ speedtest-cli --server 2947 Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Comcast Cable (50.250.251.210)... Hosted by Atlantic Metro (New York City, NY) [4129.02 km]: 307.568 ms Testing download speed Download: 38.52 Mbits/s Testing upload speed.. Upload: 10.62 Mbits/s I am trying to understand why this is so? I would wager that NYC being further away would give me a worse throughput than OR, but the speedtest tells me otherwise. Packet loss or just congestion on the path (resulting in packet loss again) that makes your TCP windows to shrink and not letting you to get close to either your allocated BW on the channel to OR or your maximal throughput per TCP stream that is governed by the maximal size of the TCP buffer? There could be some shaping as well, but this might be not your case, since it fluctuates. However, many interesting things could happen. iperf in UDP mode should give you fairly good overview of what't happening with bandwidth and packet loss. And iperf in TCP mode with varying number of streams (and obtained scaling of throughput or lack of it) should give you some hints on what's possibly going on. I also assume that you're talking about TCP and your bandwidth-delay product is used to tune TCP buffer sizes. If not, I'd recommend checking http://www.psc.edu/index.php/networking/641-tcp-tune The 2nd and more puzzling observation is that while OR is giving a download of around 5.08Mbps, it will improve and become much better later in the day. There are times when i see it going up as high as 48Mbps. Sometimes while a transfer is in progress i see that my download suddenly goes down from 48Mbps to 2Mbps. Varying routing during the day, fluctuating congestion and many other things could happen. Probably here something like smokeping will give you an overview of the RTT (if it varies) and loss on the ICMP. ICMP loss isn't neccessarily coupled to UDP/TCP due to the QoS and other stuff that can happen on WAN, so it will provide just additional hints, not the complete answer. Can somebody here tell me why such a drastic fluctuation is seen? No answers here, sorry, just some hints and possibilities. -- Eygene Ryabinkin, National Research Centre Kurchatov Institute Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: Interesting BFD discussion on reddit
Mon, Feb 16, 2015 at 08:55:17AM +0530, Glen Kent wrote: I wonder if Trio, EZChip and friends could do SHA in NPU, my guess is yes they could, but perhaps there is even more appropriate hash for this use-case. I'm not entirely convinced doing hash for each BFD packet is impractical. [0] http://www.ietf.org/id/draft-mahesh-bfd-authentication-00.txt You might want to take a look at: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-9.pdf Look at the slides 11 onwards. Were these people doing some real implementation in-hardware or were just theoretizing? I see prediction label for the number of authenticated sessions -- do you have an idea what that means? And on slide 14 you have smaller session limit numbers for BFD fully implemented in hardware than for hw-assisted case (slide 12). It makes me think that this presentation should either be supplemented with talking people or there are some errors in it. Or I am completely missing some fine point here. Doing HMAC calculation for each packet adversely affects the number of concurrent sessions that can be supported. Without mentioning the scope (which hardware and software) this assertion is either trivial or useless, sorry. TSO, frame checksums and other stuff hadn't been implemented in-hardware for ages, but now it is here and there all the time. And /me is interested why can't BFD be done on the interface chip level: it is point-to-point on L2 for the majority of cases. -- Eygene Ryabinkin, National Research Centre Kurchatov Institute Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Re: US patent 5473599
Constantine, Tue, May 06, 2014 at 06:11:04PM -0700, Constantine A. Murenin wrote: On 6 May 2014 15:17, David Conrad d...@virtualized.org wrote: Except it wasn't useless: it was, in fact, in use by VRRP. Further, the OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet been allocated. If the OpenBSD developers were so concerned about making the best choice, it seems odd they chose an allocated number for one protocol and an unallocated number for another protocol. Can you explain why exactly do you find this odd? VRRP/HSRP have had only one protocol number allocated to it; it's not like it had two, so, another one had to come out of somewhere else. VRRP/HSRP comes from Cisco (well, VRRP is RFC'ed for some time, but its origin is Cisco too), so there is a straight route for agreeing on the protocol versioning within the same protocol ID. And _I_ find this odd is because you'll probably find me very odd if I'll come into your house, find currently unused room and will say oh, I'll live here; no one will be confused or troubled, the room is unused. Seriously, do you think that we used same protocol number, but version field tells you what's going on is a really good excuse? Had you ever run tcpdump on the CARP traffic to see that it thinks it to be VRRP and discover that you need '-T carp'? Do you think that in-hardware or in-software implementations really need to check an extra field in the packet's contents to judge if this is VRRP (or CARP) instead of just testing protocol number and leave packets for unsupported protocol out of the path? Do you think that extra coordination with Cisco for not to reuse VRRP/HSRP protocol version that was at that time unused (and picked by CARP) really worth that? Tue, May 06, 2014 at 07:43:11PM -0700, Constantine A. Murenin wrote: On 6 May 2014 18:51, Jared Mauch ja...@puck.nether.net wrote: On May 6, 2014, at 9:11 PM, Constantine A. Murenin muren...@gmail.com wrote: So, then the only problem, perhaps, is that noone has apparently bothered to explicitly document that both VRRP and CARP use 00:00:5e:00:01:xx MAC addresses, and that the xx part comes from the Virtual Router IDentifier (VRID) in VRRP and virtual host ID (VHID) in CARP, providing a colliding namespace, so, one cannot run both with the same Virtual ID on the same network segment. Or that CARP didn't get their OUI, ask for help from one of the vendors that supports *BSD for use of their space or something else. Politics. Again, this is a non-issue for most users -- there's a very easy, straightforward and complete workaround. If you hadn't seen the cases when same VRIDs in the same network were used for both VRRP and CARP doesn't mean that they aren't occurring in the real world. We use CARP and VRRP quite extensively and when we first were hit by this issue, it was not that funny. And our Cisco folks had no knowledge about CARP, because they are just Cisco-heads (and because there is no CARP specification of any kind). Becides, such clever choice of OUI limits total number of CARP + HSRP/VRRP instances in the same L2 network to 256 instead of being 256 + 256. When you're running many CARP and VRRP-based clusters, especially with ARP load-balancing (multiple VRIDs for the single IP), this somewhat pushes VRID space close to its limits. One may say that (all that I had seen in the real-world conversations) a. people who use CARP and VRRP should know what they are both and avoid having same VRIDs; b. no sane person will use CARP load-balancing; c. the probability of having same VRIDs (and, thus, MACs) is small, but choosing OUI from the VRRP space (hijacking that space) was clearly the poor design choice. Fullstop. You may rant about Google, SPDY and other stuff, but making examples of people doing more cruel things doesn't help to alleviate the problem we're talking about. That's just the polite way of saying CARP developers were right, piss off. Getting the same protocol ID and reusing OUI assignment is a potential point of confusion and errors. It manifests itself in the real world. Such potential points of breakage tend to strike at the worst possible time and current networks are complicated enough even without this mess; I think if you had worked in a complex network environments, you know what I am talking about. If not, well, just think of OSPF, BGP, BFD, VRRP, MPLS, LACP, PAgP, ESRP, xSTP and other protocols that are running today in any kinda matured network (not saying about other fancy stuff like TRILL, SDN and other ones that tend to show up and be even neccessary for some cases, but not very broadly deployed just now). Does anyone wants to have other problem-originators here? You appear to believe that it isn't an issue; well, that's your mindset. Other people think that there is some level of controversy in all this. Having the same protocol ID and OUI, but bumping the protocol version
