- Test - lists.nanog.org

Re: Undefined terms overload
by Larry Sheldon 11 Nov '14

11 Nov '14

On 11/10/2014 22:23, Christopher Morrow wrote: Thanks--I've received several useful offers of help. >> What does "bikeshedding" mean here? > > en.wikipedia.org/wiki/Parkinson's_law_of_triviality I'd forgotten the Parkinson's discussion and the term didn't stir anything up. I have current experience with the concept. >> And, what does "OOB" mean here--the decodes with which I am familiar do not > > 'out of band' - ideally: "Access the console of my equipment without > having to use the network my equipment is supporting" From another helpful message I was able to connect to the old telephone term that had the same functional definition in a different physical implementation. Thanks, all. -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

1 0

Undefined terms overload
by Larry Sheldon 11 Nov '14

11 Nov '14

I was able to ignore it for a while, but now I have run into one in two unrelated threads. What does "bikeshedding" mean here? And, what does "OOB" mean here--the decodes with which I am familiar do not seem to fit: Out of Bounds, Out Of Body, Out of Bed, Out of Business, Open Of Business (used to see this one many times daily), Out Of Bullets, Out Of Band (also familiar from telephone days). -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn from their mistakes. Quis custodiet ipsos custodes

2 1

Re: Kind of sad
by Scott Weeks 11 Nov '14

11 Nov '14

--- jmkeller(a)houseofzen.org wrote: From: James Michael Keller <jmkeller(a)houseofzen.org> On 11/10/2014 06:34 PM, Joe wrote: > Kind of sad that the state govs don't curtail telnet,,, > > [root@bighughness ~]# telnet 167.240.254.155 623 > Trying 167.240.254.155... > Connected to external-dns1.state.mi.us (167.240.254.155). > Escape character is '^]'. > Username:root > Password: > Hopefully a honeypot / synthetic response from an IPS unit.... -------------------------------------------------- State gov't. I doubt it. I've seen the horrors that happen in those places... :-) scott

1 0

Contact at internode / iiNet (AS4739)?
by Paul S. 11 Nov '14

11 Nov '14

Hey, If anyone from the routing / peering team of Internode / iiNet happens to frequent this list, could you reach me off-list? I've been having routing problems with my peering session to you for a few months already, and haven't been able to get a response off the helpdesk. Thanks, and sorry for the noise.

1 0

Hosted IP telephony
by A Mekkaoui 10 Nov '14

10 Nov '14

Hi, We are an Internet and IP telephony provider in Canada and looking for options to reduce our costs. We are exploring hosted IP telephony option to see how it can help us reducing cost and operational headaches. We have few hundred of phone adapters to register and this number increases from day to day. If you provide this type of solutions or know providers of this type of solutions please contact me. Your help will be appreciated. Thank you Karim

1 0

RE: Cisco CCNA Training
by scottie mac 10 Nov '14

10 Nov '14

Holy molly, thankyou!! I just enrolled. On 08/11/14 23:00, nanog-request(a)nanog.org wrote: > From: "Wakefield, Thad M." <twakefield(a)stcloudstate.edu> To: > "nanog(a)nanog.org" <nanog(a)nanog.org> Subject: RE: Cisco CCNA Training > Message-ID: > <B3093724FB4D2747AE895C89420A1EDC0133AD775E(a)SCSU83A.campus.stcloudstate.edu> > Content-Type: text/plain; charset="utf-8" Until midnight Monday this > course is on sale for $24: > https://www.udemy.com/collection/thankyou-400-24deal >> >-----Original Message----- >> >From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of scottie mac >> >Sent: Tuesday, November 04, 2014 6:02 PM >> >To:nanog@nanog.org >> >Subject: Re: Cisco CCNA Training >> > >> >This course has 25 hours of video, I haven't started it yet but I've watched >> >many of Laz's videos on Youtube, and he explains stuff very well. >> >It is $399 though. >> >They could share the Udemy account, and watch them in their free time. >> >*I'm not affiliated with Udemy* >> > >> >https://www.udemy.com/the-complete-ccna-200-120-course

2 1

Problem reaching AS794 (Oracle) Through Level3 (Stockholm / Sweden).
by Jay Ess 10 Nov '14

10 Nov '14

I have had problems reaching www.mysql.com (AS794 Oracle) from AS39651 (Comhem Stockholm Sweden) for about a week now. Looking glass from Level3 and Telia shows me error as well. Can give login to a linux shell for troubleshooting. Traceroute : Host Loss% Snt Last Avg Best Wrst StDev 1. om-doc-1-bu30.comhem.se 0.0% 16 6.5 9.7 6.5 19.5 4.0 2. 213.200.164.203 0.0% 16 8.1 9.9 7.1 17.7 3.2 3. 213.200.163.81 0.0% 16 9.0 10.1 7.3 18.3 2.8 4. s-b5-link.telia.net 0.0% 16 9.1 11.7 7.9 20.5 4.9 5. s-bb4-link.telia.net 0.0% 16 9.0 12.8 8.2 30.3 6.2 6. s-b6-link.telia.net 0.0% 16 8.9 12.5 8.2 23.4 4.8 7. level3-ic-155475-s-b2.c.telia.net 25.0% 16 9.3 8.6 7.4 9.6 0.8 8. ae-4-90.edge5.Dallas3.Level3.net 12.5% 16 159.6 164.1 157.1 210.7 13.9 9. ae-4-90.edge5.Dallas3.Level3.net 12.5% 16 158.7 163.9 157.5 181.7 7.6 10. ???

1 0

Contact @ harvard.edu?
by Staudinger, Malcolm 10 Nov '14

10 Nov '14

If anyone from Harvard IT (preferably network/netsec, but I'll take anyone at this point) is on this list, please drop me a line regarding a DoS from your network. I haven't had any luck getting past your student help desk/ticket system. Malcolm Staudinger Information Security Analyst II | EIS EarthLink<http://www.earthlink.com/> E: mstaudinger(a)elnk.com M: 360-936-5957 [http://www.earthlinkmarketingservices.com/email_logo_sm.png]

1 1

Re: I am about to inherit 26 miles of dark fiber. What do I do with it?
by Scott Weeks 10 Nov '14

10 Nov '14

--- fkittred(a)gwi.net wrote: From: Fletcher Kittredge <fkittred(a)gwi.net> The below is a really sad story. Condolences on the coming trainwreck. I hope you get someone on staff or on consult that understands outside plant architecture, because it is much more important and complex topic than you seem to realize. ----------------------------------------- Help guide and build knowledge instead of publicly beat down. scott

2 1

Fwd: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01)
by Jeroen Massar 10 Nov '14

10 Nov '14

Forwarding this so that everybody can comment on this nasty proposal ;) Forcing replies to v6ops(a)ietf.org where they likely should be taking place as that is where recently the mentioned draft was accepted as a WG item. Greets, Jeroen -------- Forwarded Message -------- Subject: [v6ops] IPv6 MTU Flow-label.... (related to draft-v6ops-pmtud-ecmp-problem-01) Date: Mon, 10 Nov 2014 11:31:52 +0100 From: Jeroen Massar <jeroen(a)massar.ch> Organization: Massar To: ipv6(a)ietf.org, v6ops(a)ietf.org Hola folks (and folks in BCC ;), With the recent Google and Akamai outages (latter still ongoing afaik), it came to light that the cause is likely the model and problem described here: https://tools.ietf.org/html/draft-v6ops-pmtud-ecmp-problem-01 which previously was: https://tools.ietf.org/html/draft-v6ops-jaeggli-pmtud-ecmp-problem-01 Or shortly described: terminating an IP address at different hosts and having the balancer box not knowing where to deliver the ICMP PTBs that get send for large packets. One of the suggestions there is to lower the MSS for every connection by forcing it (either on the loadbalancer or on the final host) to a value that "works everywhere": the one for an MTU of 1280. MSS only applies to TCP, and people like Google are coming out with QUIC and other schemes. As we really do not want an Internet at an MTU of 1280, why don't we indicate in the packet what the MTU is when it is diverting from the norm? What if we instead let a router that sources a packet from a link or is going to transmit a packet over a link < 1500 indicate with that packet that that packet came from/is going to is a link with a MTU < 1500. We can't use an additional extension header, as adding anything would mean we might hit the MTU of the packet and we have other issues. As our least-known-used field is the FlowLabel field, we could abuse that and have enough bits there to stuff our data. What if we define that when the first 4 bits are set to 0xF (all one) that the rest (16bits) defines the MTU of the link (MTU 0 - 65k)? (We could even use a 'base of 1280' and thus 0xf0000 = 1280 MTU, but possibly it is better to state "value of < 0xf0500 is invalid") Thus allowing when the first 4 bits are not set to all-1 that the flowlabel field is a "normal flowlabel" field ala RFC6437. We could even state "Only set this MTU option when the FlowLabel field == 0" to avoid incompatibility (though I do not expect any as I rarely see packets with the field non-0...) Thus given a network like: [H1] 2001:db8:1500::1/64 | mtu = 1500 2001:db8:1500::a/64 [RA] 2001:db8:1501::a/64 | mtu = 1500 2001:db8:1501::b/64 [RB] 2001:db8:1480::b/64 | mtu = 1480 2001:db8:1480::c/64 [RC] 2001:db8:1280::c/64 | mtu = 1280 2001:db8:1280::d/64 [RD] 2001:db8:9000::d/64 | mtu = 9000 2001:db8:9000::2/64 [H2] RA receives packet, src+dst interface are MTU=1500, thus does nothing RB receives packet, src = 1500, dst = 1480, thus sets FL = 0xf05c8 RC receives packet, src = 1480, dst = 1280, thus sets FL = 0xf0500 RD receives packet, src = 1280, dst = 9000, thus sets FL = 0xf0500 (again, just set is quicker than checking) Now even if H2 is a loadbalancer, if the flow is just forwarded (without TTL change btw...) the destination receives it correctly. The disadvantage is of course that you lose the ability to balance based on the FlowLabel, but if we go with "only change when not 0 then there was one anyway. Also you got src+dst which is 256bits, which should be pretty good already and optionally next-header + the contents of the header if you want that. Note that as we have no checksum in IPv6, there is little overhead to do this kind of forwarding, HopLimit already needs updating, this is just another field to update. In another model from the above, we could even just let every hop set the known lowest MTU. In that case, H1 would set 0xf05dc in the packet, and then it gets lowered automatically. Which would also mean that a pure 9000 path would nicely work suddenly as everybody knows that 9000 will fit :) Greets, Jeroen _______________________________________________ v6ops mailing list v6ops(a)ietf.org https://www.ietf.org/mailman/listinfo/v6ops

1 0