- NANOG - lists.nanog.org

RE: Ciena 6200 clue?
by Phil Bedard 03 Jul '13

03 Jul '13

Right that is the "workaround." :) Phil From: Bryan Fields Sent: 7/3/2013 18:15 To: NANOG list Subject: Re: Ciena 6200 clue? On 7/3/13 5:41 PM, Phil Bedard wrote: > The ALU 7750/7450, etc. routers have a separate routing > process/configuration for their OOB mgmt and as of the last time I looked > do not support a default gateway. Well you can set up multiple static routes. The only route you can't set it 0/0. This will work, though I'd suggest only putting the management routes it needs in it. A:Milhouse>bof# static-route 0.0.0.0/0 next-hop 1.0.0.2 MINOR: SYSTEM #1505 Invalid static route destination prefix - cannot configure default route on the management interface A:Milhouse>bof# static-route 0.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# static-route 128.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# show bof =============================================================================== BOF (Memory) =============================================================================== primary-image nope.jpg primary-config Milhouse/config.cfg address 1.0.0.70/24 active primary-dns 1.0.0.2 dns-domain nope.jpg static-route 0.0.0.0/1 next-hop 1.0.0.2 static-route 128.0.0.0/1 next-hop 1.0.0.2 autonegotiate duplex full speed 100 wait 4 persist on no li-local-save no li-separate console-speed 115200 =============================================================================== -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: Ciena 6200 clue?
by Bryan Fields 03 Jul '13

03 Jul '13

On 7/3/13 5:41 PM, Phil Bedard wrote: > The ALU 7750/7450, etc. routers have a separate routing > process/configuration for their OOB mgmt and as of the last time I looked > do not support a default gateway. Well you can set up multiple static routes. The only route you can't set it 0/0. This will work, though I'd suggest only putting the management routes it needs in it. A:Milhouse>bof# static-route 0.0.0.0/0 next-hop 1.0.0.2 MINOR: SYSTEM #1505 Invalid static route destination prefix - cannot configure default route on the management interface A:Milhouse>bof# static-route 0.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# static-route 128.0.0.0/1 next-hop 1.0.0.2 *A:Milhouse>bof# show bof =============================================================================== BOF (Memory) =============================================================================== primary-image nope.jpg primary-config Milhouse/config.cfg address 1.0.0.70/24 active primary-dns 1.0.0.2 dns-domain nope.jpg static-route 0.0.0.0/1 next-hop 1.0.0.2 static-route 128.0.0.0/1 next-hop 1.0.0.2 autonegotiate duplex full speed 100 wait 4 persist on no li-local-save no li-separate console-speed 115200 =============================================================================== -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Leap Second
by Todd S 03 Jul '13

03 Jul '13

We found we got leap seconds added on some systems over the weekend. There were no leap seconds planned ( http://www.usno.navy.mil/USNO/earth-orientation/leap-second-announcement) however some of our systems got one. We run our own s2/s3/s4 system, with only the s2s going to the Internet. We have about 20 servers defined there, but looking through the logs, I can't figure out which one(s) may have been advertising the leap second. I went through all our systems on Friday and Saturday to check for the leap bit, but had nothing, so it must have come out on Sunday. Anyone else run in to this, or have any further intel about servers that advertised the leap second? Cheers, Todd.

8 10

10G Wave from NJ to NY
by Dan Armstrong 03 Jul '13

03 Jul '13

Would anybody out there have a 10G wave for sale on a route between 165 Halsey in Newark and 60 Hudson in New York that crosses the Hudson River at or south of the Holland Tunnel? Possibly in the rail tunnel between World Trade Centre station and Exchange Place? Off list replies are great. Thanks!

1 0

Re: .nyc - here we go...
by Scott Weeks 03 Jul '13

03 Jul '13

--- rubensk(a)gmail.com wrote: From: Rubens Kuhl <rubensk(a)gmail.com> > Thank you for explaining this. Again, probably. <snip> Summary: there are residual risks, but the checks and balances of the process are likely to stop bad actors, at the cost of also stopping some good actors. Error in the side of caution preferred. ----------------------------------------------------------- Thanks for the explanation. I will begin to learn more about this. scott

1 0

RPKI Dashboard
by Thijs Stuurman 03 Jul '13

03 Jul '13

FYI, source information: http://staff.science.uva.nl/~delaat/rp/2012-2013/index.html#Presentations-r… Dashboard: http://academic.slowpoke.nl/ With kind regards, Thijs Stuurman

2 1

Perl router snmp to DNS
by Jensen Tyler 03 Jul '13

03 Jul '13

My Google fu is failing. Can anybody point me to a script that will create DNS entries from router snmp info? Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC

3 2

Re: [cryptography] Google's QUIC
by Eugen Leitl 03 Jul '13

03 Jul '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Wed, 03 Jul 2013 13:24:54 +0300 From: ianG <iang(a)iang.org> To: cryptography(a)randombit.net Subject: Re: [cryptography] Google's QUIC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 On 3/07/13 12:37 PM, Eugen Leitl wrote: > ----- Forwarded message from Saku Ytti <saku(a)ytti.fi> ----- > > Date: Tue, 2 Jul 2013 21:35:58 +0300 > From: Saku Ytti <saku(a)ytti.fi> > To: nanog(a)nanog.org > Subject: Re: Google's QUIC > User-Agent: Mutt/1.5.21 (2010-09-15) > > On (2013-06-29 23:36 +0100), Tony Finch wrote: > >> Reminds me of MinimaLT: http://cr.yp.to/tcpip/minimalt-20130522.pdf > > Now that I read separate 'QUIC Crypto' page. It sounds bit of a deja vu. > > QUIC also uses Curve25519 pubkey and Salsa20 cipher, which is hard to > attribute as chance, considering both are DJB's work, both are used by his > NaCl library and by extension by MinimaLT. Neither is particularly common > algorithm. It's not the choice of algorithm that is "by chance" it is the choice of suite as a design decision that matters. I also would like to use the same ciphersuite, but the reason is that DJB has already done the work to define the entire suite, saving me from doing it. This is quite a saving for me, and hasn't hitherto existed as an external service. Last time it took over a month of hard research and learning to settle on RSA/AES128/CBC/SHA1/HMAC/Encrypt-then-mac. As an added bonus, DJB came up with a shorter, catchier name: curve25519xsalsa20poly1305 In the past, things like TLS, PGP, IPSec and others encouraged you to slice and dice the various algorithms as a sort of alphabet soup mix. Disaster. What we got for that favour was code bloat, insecurity at the edges, continual arguments as to what is good & bad, focus on numbers & acronyms, distraction from user security, entire projects that rate your skills in cryptoscrabble, committeeitus, upgrade nightmares, pontification ... Cryptoplumbing shouldn't be like eating spagetti soup with a toothpick. There should be One Cipher Suite and that should do for everyone, everytime. There should be no way for users to stuff things up by tweaking a dial they read about in some slashdot tweakabit article while on the train to work. > I'm not implying QUIC plagiarizes MinimaLT, there are differences in the > protocol, just choice of the algorithm implies QUIC authors are aware of > MinimaLT. Picking curve25519xsalsa20poly1305 is good enough for that One True CipherSuite motive alone, and doesn't imply any other sort of copying one might have seen. It's an innovation! Adopt it. iang _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Re: .nyc - here we go...
by Larry Sheldon 03 Jul '13

03 Jul '13

On 7/2/2013 11:39 PM, Andrew Sullivan wrote: > On Wed, Jul 3, 2013 at 12:15 AM, Larry Sheldon <LarrySheldon(a)cox.net> > wrote: > >> Makes me wonder if concern for routing table size is worrying about >> the right thing. > > Because obviously, the problems of scaling router memory and scaling > DNS servers are the same kind? I would not say "same" but I would say "similar" and "related" when you think about things like how big the cache will be and how much of the traffic the peerages worry about will be pure overhead, and stuff like that. > Yes, having many many new TLDs introduces new problems. (If you're > not scared enough, I encourage you to go read the output of the > Variant Issues Project. Full disclosure: I had a hand in.) Why are > we talking about this non-news now? We all knew about three years > ago, at the latest, that ICANN was planning to do this. If we > didn't, shame on us. What is going to happen tomorrow is sometimes less interesting that what is happening a while ago. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

Re: .nyc - here we go...
by Scott Weeks 03 Jul '13

03 Jul '13

--- rubensk(a)gmail.com wrote: From: Rubens Kuhl <rubensk(a)gmail.com> > As places like that see $186,000 as small change, I wonder > what other countries (much less the cities within them) > like .nu, .sb or .vu will do? For them this is an > astronomical number. Someone's about to hit a financial > home run reminiscient of the tech-stock bubble... > No countries were obliged to apply. Both country codes and country names were excluded from the new gTLD process. Actually, they couldn't even apply, as they are considered ccTLDs. > I haven't read enough, but what's to stop speculators > paying the $186,000 then charging the tiny countries > mors when they are able to make the purchase? Please > don't suggest arbitration because that only increases > the cost to those countries. ------------------------------------------------------------- Thank you for explaining this. Again, probably. So the cities in those countries could buy them (if they could afford them) but not the countries? So .portvila is available, but not .vanuatu? What about places like Singapore? The city name is the same as the country name. "I haven't read enough, but what's to stop speculators paying the $186,000 then charging the tiny countries mors when they are able to make the purchase?" s/tiny countries/cities in tiny countries/ Does the speculator issue have to go to arbitration? scott

3 6