Re: Check this out T-Mobile Launches GoSmart Prepaid Service Nationally on Phone Scoop
If only there were some kind of method for Jay to publish which addresses are actually authorized to send mail on behalf of baylink.com (which could then be leveraged by sc1.nanog.org to turn the recommended soft fail into a hard fail and stop this kind of silliness cold)... Billet:~ rs$ dig +short baylink.com. txt Billet:~ rs$ dig +short baylink.com. spf Billet:~ rs$ -r George Herbert george.herb...@gmail.com writes: All in favor of phonescoop being blacklisted from nanog? Anyone? Anyone? Buehler? On Tue, Feb 19, 2013 at 5:50 PM, Grant Ridder shortdudey...@gmail.com wrote: haha i love the header: Received: (from nobody@localhost) On Tue, Feb 19, 2013 at 7:48 PM, Jay Ashworth j...@baylink.com wrote: Check this out: http://www.phonescoop.com/articles/article.php?a=11946 This email was sent via Phone Scoop (www.phonescoop.com). The sender thought you might be interested in the page linked above. -- -george william herbert george.herb...@gmail.com
Re: Muni fiber: L1 or L2?
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp writes: Robert E. Seastrom wrote: Let's assume 4:1 concentration with PON. Why on earth would we assume that when industry standard is 16 or 32? That is because additional 4:1 concentration is usually at CO, which does not contribute to reduce the number of fibers in a trunk cable. 16 is a safe number. Do you mean a splitter in field should be shared by 16 subscribers? Then, with the otherwise same assumptions of my previous mail, total extra drop cable length for PON will be 204km, four times more than the trunk cable length. Thus, it is so obvious that SS is better than PON. You're confusing fiber architecture with what gets laid on top of it. Where the splitters go is entirely irrelevant. Rule of thumb in the US is that 80% of the costs of a fiber build are in engineering, planning, RoW acquisition, lawyers, etc. Of the remaining 20%, more of it is labor than materials. Price per fiber strand in the bundle is noise in the larger equation. You have to pay for splitters in the PON architecture regardless of where you put them, of course, so just bake that into the port cost side of per-customer-served. OTOH, if concentration is 2:1 or less, it is, again, obvious that SS is better than PON, because of extra complexity of PON. Again, home run central splitter vs. distributed splitter architecture has nothing to do with PON being better or worse than a technology that forces single strand all the way to the endpoint. So, 4:1 is the safe number to obfuscate lack of merit of PON. If you can read Japanese or FTTH is serious business of you worth hiring a translator of your own, you can find average number of subscribers sharing a splitter in field is 3.68, a little less than 4, from: http://itpro.nikkeibp.co.jp/article/COLUMN/20080619/308665/ Having actually been involved in building a business plan surrounding this, I don't need to read Japanese to be able to tell you that the outside plant engineering was clearly assigned to the madogiwazoku if they're only getting a 4:1 split on average. -r
Re: Muni fiber: L1 or L2?
Jason Baugher ja...@thebaughers.com writes: Our main cost is labor. Fiber, fdh, splitters, etc... are marginal. dingdingdingding WE HAVE A WINNER. :-) -r
Re: Muni fiber: L1 or L2?
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp writes: Let's assume 4:1 concentration with PON. Why on earth would we assume that when industry standard is 16 or 32? 16 is a safe number. -r
Re: Will wholesale-only muni actually bring the boys to your yard?
Scott Helms khe...@zcorum.com writes: In that case its even harder. Before you even consider doing open access talk to your FTTx vendor and find out how many they have done using the same architecture you're planning on deploying. Open access in an active Ethernet install is actually fairly straight forward but on a PON system its harder than a DOCSIS network. Categorically untrue. It is all a matter of where the splitters are placed. A home run fiber plant architecture with an enormous patch frame and splitters provided by the open access provider if PON is their technoogy of choice is indistinguishable from an active ethernet install from an open access perspective. -r
Re: Will wholesale-only muni actually bring the boys to your yard?
If you were talking about layer 2 handoffs, your statement is perhaps even more untrue - active ethernet and PON layer 2 handoffs are approximately as easy as each other. -r PS: The word is _conflating_, not _confounding_. Scott Helms khe...@zcorum.com writes: On Wed, Feb 6, 2013 at 9:46 AM, Robert E. Seastrom [[r...@seastrom.com]] wrote: Scott Helms [[khe...@zcorum.com]] writes: In that case its even harder. Before you even consider doing open access talk to your FTTx vendor and find out how many they have done using the same architecture you're planning on deploying. Open access in an active Ethernet install is actually fairly straight forward but on a PON system its harder than a DOCSIS network. Categorically untrue. It is all a matter of where the splitters are placed. You're confounding the layers of the network or perhaps I was being unclear that I was talking about Layer 2 handoffs. A home run fiber plant architecture with an enormous patch frame and splitters provided by the open access provider if PON is their technoogy of choice is indistinguishable from an active ethernet install from an open access perspective. Again, I was speaking about Layer 2 open access. -r -- Scott Helms Vice President of Technology ZCorum (678) 507-5000 [[http://twitter.com/kscotthelms]]
Re: Will wholesale-only muni actually bring the boys to your yard?
Scott Helms khe...@zcorum.com writes: On Wed, Feb 6, 2013 at 10:30 AM, Robert E. Seastrom [[r...@seastrom.com]] wrote: If you were talking about layer 2 handoffs, your statement is perhaps even more untrue - active ethernet and PON layer 2 handoffs are approximately as easy as each other. Perhaps you'd share some specifics? I certainly haven't worked on all of the PON systems that are out there, but the ones I have worked one didn't have (or I didn't find) a good way to separate traffic at layer 2 so that several operators could handle their own Layer 3 provisioning for customers on the same OLT. Every PON OLT that I have touched has supported both vlan-per-customer (has scaling issues) and vlan-per-service configuration abstractions. There are other ways to do it too (double and triple tagging) but to keep it simple if one creates profiles along the lines of: SP1-VOIP SP1-VIDEO SP1-INTARWEBZ and repeats for sp2, sp3, etc... trunk out the top, split off vlans and backhaul as appropriate (choose wisely!) with appropriate QoS if you like, to equal access provider. Provisioning the ONT/ONU and the inter-provider interface to do so (REST XML? JSON? something else?) is left as an exercise to the implementer. Reading this: https://sites.google.com/site/amitsciscozone/home/gpon/gpon-vlans-and-gem-ports may prove informative for the GPON case. -r
Re: Muni network ownership and the Fourth
Jay Ashworth j...@baylink.com writes: Still, the power budget improvements by not going with a single strand active ethernet solution (which were another suggested technology and has actually been deployed by some muni PON folks like Clarkesville, TN) are huge. Imagine a 24 port switch that draws 100 watts. OK, that's 4w per customer. 30k customers from a served location, that's 120kw ($13k power bill if you had 100% efficient UPSes and 0 cost cooling, neither of which is true) just for the edge, not counting any aggregation devices or northbound switch gear. Hmm. the optics don't have auto power control? Auto power control would apply to launch levels for the light; assuming a launch level of -3 dBm and lasers that were only 1 percent efficient (combination of spec max launch power for LX optics and unrealistically crummy efficiency lasers) your total power budget for the laser is only 50 milliwatts out of that 4 watts - wrong place to look for power savings. The rest is taken up by stuff like the ethernet chip and supporting logic in the switch, inefficiencies in the power supply, etc. etc. Back at NN, we discounted this as a technology almost immediately based on energy efficiency alone. Anyway, in summary, for PON deployments the part that matters *is* a greenfield deployment and if the fiber plant is planned and scaled accordingly the cost differential is noise. I assume you mean the cost diff between GPON plant and home-run plant; that's the answer I was hoping for. Close; I meant the cost difference between a home run fiber architecture with centralized splitters for *PON and distributed splitters in the field is minimal, and one gains it back in future-proofing and avoiding forklift upgrades down the road. The question of where one puts the splitters (if any) is coupled to the PON vs. active ethernet question only insofar as AE doesn't need splitters - but assuming: * $10k/month cost differential for power in the scenario above * unity cost for head end equipment (almost certainly wrong) * a 16 way split ratio (worst case; you might get 24 or 32) * $100 apiece splitters (24 or 32 would be marginally more) * today's stupid-low cost of capital break-even point on the decision to go with a PON type of technology is still less than two years. If you have a customer who needs the whole pipe to himself (or next generation optics for 10g or 100g to the couch), with centralized splitters the solution is easy. You re-patch him with an attenuator instead of a splitter (or hook him to the new kit), re-range, and go to town. Of course you lose the power advantages of a PON architecture but those customers are the exception not the rule. -r
Re: Muni network ownership and the Fourth
Leo Bicknell bickn...@ufp.org writes: In a message written on Sat, Feb 02, 2013 at 08:55:34PM -0500, Jay Ashworth wrote: From: Robert E. Seastrom r...@seastrom.com There is no reason whatsoever that one can't have centralized splitters in one's PON plant. The additional costs to do so are pretty much just limited to higher fiber counts in the field, which adds, tops, a couple of percent to the price of the build. Ok, see, this is what Leo, Owen and I all think, and maybe a couple others. But Scott just got done telling me it's *so* much more expensive to home-run than ring or GPON-in-pedestals that it's commercially infeasible. Note, both are right, depending on the starting point and goals. Data point, which makes the rest of this discussion moot: Since telcos are historically myopic and don't build (much) extra fiber into their plant to support future technologies, the only use for existing fiber in the ground in passive optical applications is to connect the COs. There is not enough running out towards the customers to support retrofitting it for PON. Besides, there are regulatory issues with re-purposing existing voice-plant-supporting assets for PON in places such as VZ territory where the ILEC got a pass on legislated equal access applying to PON builds. Some more data that may inform your conceptualization - Split ratios of 128 and 64 only work in the lab. Proper engineering (overlap of dB and bits/sec/customer) will dictate split ratios of 16 or 32 (depending on modulation scheme, and no, going to 10gbit modulation doesn't help; you still have the link budget problem) last time I did the math. Still, the power budget improvements by not going with a single strand active ethernet solution (which were another suggested technology and has actually been deployed by some muni PON folks like Clarkesville, TN) are huge. Imagine a 24 port switch that draws 100 watts. OK, that's 4w per customer. 30k customers from a served location, that's 120kw ($13k power bill if you had 100% efficient UPSes and 0 cost cooling, neither of which is true) just for the edge, not counting any aggregation devices or northbound switch gear. Back at NN, we discounted this as a technology almost immediately based on energy efficiency alone. Anyway, in summary, for PON deployments the part that matters *is* a greenfield deployment and if the fiber plant is planned and scaled accordingly the cost differential is noise. -r Historically teclos have installed (relatively) low count fiber cables, based on a fiber to the pedistal and copper to the prem strategy. If you have one of these existing deployments, the cost of home run fiber (basically starting the fiber build from scratch, since the count is so low) is more expensive, and much greater cost than deploying GPON or similar over the existing plant. However, that GPON equipment will have a lifespan of 7-20 years. In a greenfield scenario where there is no fiber in the ground the cost is in digging the trench. The fiber going into it is only ~5% of the cost, and going from a 64 count fiber to a 864 count fiber only moves that to 7-8%. The fiber has a life of 40-80 years, and thus adding high count is cheaper than doing low count with GPON. Existing builds are optimizing to avoid sending out the backhoe and directional boring machine. New builds, or extreme forward thinking builds are trying to send them out once and never again. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: Muni network ownership and the Fourth
Owen DeLong o...@delong.com writes: On Jan 29, 2013, at 20:30 , Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: On 13-01-29 22:03, Leo Bicknell wrote: The _muni_ should not run any equipment colo of any kind. The muni MMR should be fiber only, and not even require so much as a generator to work. It should not need to be staffed 24x7, have anything that requires PM, etc. This is not possible in a GPON system. The OLT has to be carrier neutral so that different carriers can connect to it. It is the last point of aggregation before reaching homes. Otherwise, you would need to run multiple strands to each splitter box and inside run as many splitters as there are ISPs so that one home an be connect to the splitter used by ISP-1 while the next home's strand is connected to another splitter associated with ISP-2. This gets complicated. Why can't the splitters be in the MMR? (I'm genuinely asking... I confess to a certain level of GPON ignorance). Sorry for being late to the party (real work and all that). There is no reason whatsoever that one can't have centralized splitters in one's PON plant. The additional costs to do so are pretty much just limited to higher fiber counts in the field, which adds, tops, a couple of percent to the price of the build. More than offset by futureproofing and not requiring forklift upgrades to add a new technology for a few customers. Obviously the splitters should be owned by the service provider and upstream of the mega-patch-bay for a muni open access system. Meanwhile, EPON seems to be the technology that's won out on a global basis. Might have something to do with the price - all the hooks to support legacy ATM stuff in GPON's GEM come at a cost. :-) -r PS: Back in the mid-90s, I used to fantasize about being able to say legacy ATM.
Re: Netflix transit preference?
Jeff Kell jeff-k...@utc.edu writes: On 12/27/2012 1:26 PM, Patrick W. Gilmore wrote: On Dec 27, 2012, at 13:19 , randal k na...@data102.com wrote: (We move ~1.4gbps to Netflix, and are thus not a candidate for peering. And they have no POP close.) Why don't you ask Netflix? And why not ask them for kit to put on-net? https://signup.netflix.com/openconnect The last time we asked, their criteria was ~2.0gbps, so he doesn't have enough qualifying traffic. Has anyone looked at a Qwilt? http://www.qwilt.com/ MiM-ing streaming media providers is filed under encourage my competitors to do this. It's likely to make your phone ring. -r
Re: carping about CARP
David Walker davidianwal...@gmail.com writes: [ patent fight recap ] Thanks for posting those. I recall the discussions surrounding the HSRP patents well, but it's been a while and I have proportionally more gray hair (and less overall) now. My problem is not with Theo nor with the IETF. My problem is with a crappy and credulous implementation. When an outage is caused by redundancy software that comes from an organization that prides itself on well-written code, the irony meter goes off the scale. From where I stand, the OpenBSD project has been consistent on insulating itself against future legal issues, no matter how remote, with the idea that your security should not be restrained by anyone other than you. What is security though and what it its aim? To my way of thinking, what happened to me last night wherein a box misbehaved and caused indigestion on an entire broadcast domain was a non-trivial security and availability incident. On the scale of badness, it's somewhat worse than a magic packet causes this box to reboot flaw, but not as bad as a box gets owned, sensitive data gets divulged incident. In my world, at least, security and availability are intimately intertwined. Were they not, one could easily win the security game by the simple expedient of turning the host off. Mission accomplished! I believe that idea has legs regardless of practical considerations and stands on it's own. Besides, I won't discount OpenBSD out of hand for forging ahead, withstanding practical issues, considering the runs they've got on the board and the many facepalm fails we see in the diametrically opposed corporate world. It might be a very good thing they've bothered to take the time on this. The problem here is insufficient paranoia about packets that come flying in over the transom, based on naive contemporaneous belief that a particular protocol number was not in use. I mean, gosh, who would ever send packets on an unused protocol number? And who other than us would get frustrated with the process and decide to forge ahead on their own. Most of us here are familiar with Postel's oft-quoted RFC793 robustness principle (be conservative in what you do, be liberal in what you accept from others). Yet, when one is engaging in an off-label use of any protocol, identifier, etc. it is incumbent on the protocol designer to mark their traffic in a particular way so that it is easy to identify, both for themselves and for others. Sure, one could argue that this is merely abstracting away the semantics of the protocol number field (hopefully to a field with more data space) but the whole point is to not accidentally interoperate with something with which you are not prepared to interoperate. Stated another way, nothing is keeping me from using udp/139 for something else so long as my packets aren't misinterpreted by SMB servers out there as being SMB, and so long as I don't accidentally eat someone else's SMB and do something stupid. Would you eat food that someone left on your doorstep with no note and no hint as to who it came from? Obviously from your mom, right? I mean who else would leave food on your doorstep? How about Halloween candy with open wrappers? The comparisons in the messages you cited to a four year old may not be that far off. -r
Re: carping about CARP
Henning Brauer hb-na...@bsws.de writes: * Robert E. Seastrom r...@seastrom.com [2012-11-30 13:46]: My problem is not with Theo nor with the IETF. My problem is with a crappy and credulous implementation. When an outage is caused by redundancy software that comes from an organization that prides itself on well-written code, the irony meter goes off the scale. vrrp and carp share the vhid space. you have to use unique vhids per network segment, that's about it. the openbsd box was nice enough to tell you about the mac address conflict, the other's didn't. pfSense is FreeBSD, but who's counting? The problem is magnified when ill-behaved software ends up in appliances. Good thing we were able to get a shell on the box. if you looked at the carp boxes you had seen that carp had continued to work just fine. the mac address (which is basically fixed prefix + vhid) conflict is your outage. there's nothing we could do about that. and re IANA, they made it clear they would not give us a proto number no matter what; we didn't have a choice but to ignore that industry-money-driven committee. Between choosing an Ethernet OUI which was assigned to IANA by IEEE (another industry-money-driven committee) and choosing protocol 112 (odds of coincidence 1 in what, 120 or so at the time?), ignore is not the word I would have chosen here. -r
Re: carping about CARP
Jussi Peltola pe...@pelzi.net writes: The amount of detail in the original posting is rather disappointing, with absolutely no hope of anyone being able to reproduce the problem with the data given. It was not intended as a bug report, instead merely an expression of disappointment and an advsory to fellow travelers to watch their backs. Sometimes a report of muggings in a locale is useful, even without a detailed description of the attacker. Did the vhid and vrrp group overlap? Were there duplicate IP addresses? Yes, vrrp 1 turned out to be a bad plan here. Turned off vrrp on the router and went with HSRP. There is enough documentation on HSRP vs VRRP around (heck, even Wikipedia) to surmise that something that interacted poorly with VRRP would likely not do the same to HSRP. Docs on CARP are thin on the ground. Never even an I-D. Didn't have time to read the source code when the network was acting up. -r
Re: carping about CARP
Stuart Henderson s...@spacehopper.org writes: I don't see anything here indicating that it's to do with CARP believing things sent over the wire, I suspect the problem would still occur if CARP were disabled on the pfSense box. (Do people really run CARP in the wild without authentication anyway?) 1) it did not. 2) standard, out of the box pfSense distribution. Haven't run that codebase lately myself, and not sufficiently interested this morning to dig through the code. Just watch your back, that's all. :) -r
carping about CARP
I can't seem to recall anyone griping about this here on our august little list but google finds that I'm by no means the first to have been burned by an unholy interaction between VRRP and CARP. Let's skip the protocol discussions (same protocol number and uses multicast) [*] and go straight to the behavioral observations. I turned on VRRP this evening on a pair of routers. All of a sudden a CARP instance between a pair of pfSense boxes in the rack (which I didn't even know was there) invited itself to the party and started flailing all over the place and causing oscillating packet loss for anything that was going off-segment. Note that the Ciscos didn't exhibit any untoward behavior, and there were passwords on the VRRP sessions too. Meanwhile, the pfSense box spazzed out and filled its dmesg logs with stuff like: arp: 192.0.2.1 moved from 00:00:0c:xx:xx:01 to 00:00:5e:xx:xx:01 on em1 arp: 192.0.2.1 moved from 00:00:5e:xx:xx:01 to 00:00:0c:xx:xx:01 on em1 (no other hosts on the segment were logging such activity) Looks like CARP is a bit loose about believing stuff coming in over the wire. Seems a bit out of character for OpenBSD, but maybe these days it's considered all good so long as such a malfunction only causes an outage, not a core dump. Anyway, word to the wise, CARP and VRRP is a bit of a dangerous mixture. -r [*] The OpenBSD side of the story can be read at http://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol#No_official_Internet_protocol_number Seems that there is a lesson to be learned here: o hai, we wrote this software but can not be bothered to follow your process or formally write up the protocol, plz to be giving us a protocol number ain't gonna fly.
Re: NTP Issues Today
Blake Dunlap iki...@gmail.com writes: That's what happens when you just follow vendor recommendations blindly. If you do follow that on vm's (which can actually be a good practice), make sure they pull from your own time infrastructure, and not just the world at large, and that those servers behave in a sane fashion with regard to time jumps. Emphatically disagree on the pull from your own infrastructure point. You probably don't have the budget even in a big company for sufficient diversity of sources [*] for your NTP server and even if you do the NTP servers will probably be run by the same person/organization. Mills has called the latter practice out as bad in the past. As Leo pointed out, the key is having a large diverse set so that if a couple of them go nuts they can be voted off the island. If you have a requirement for super low jitter or holdover if you lose network, you're looking at on-site devices with OCXO or Rb frequency standards in them. That doesn't mean you shouldn't be talking to the rest of the world too though. What if your on-site sources go nuts? This happens periodically, say every 10 years or so, because of crappy implementations and worst-current-practices. A re-read of https://groups.google.com/forum/?fromgroups=#!search/mills$20ntp$20byzantine/comp.protocols.time.ntp/TryjqtAd1XM/R0zzzE13Tl8J may prove instructive. (reading list also includes http://www.amazon.com/dp/1439814635/ ) In my experience NTP beats out even DNS for blatantly wrong configs in the wild that nevertheless seem to work well enough that dilettante tech folks don't notice. I might have replied to this thread yesterday but I was blissfully unaware of any problems: rs@bifrost [8] % ntpq -c peers | egrep -v '(===|remote)' | wc -l 11 rs@bifrost [9] % -r [*] particularly due to shortsighted US federal government choices on LORAN, GOES, WWVB time format, etc
Ethernet NID plus POE+ (802.3at)... or POE+ injector with OAM...
Hi everyone, I'm looking for a gigabit ethernet media converter to go from SFP plugable optics to 802.3at POE+. The application involves wireless access points some distance from a central switch for a venue. Difficulty: in my old age, I've become allergic to installing completely unmanaged bump-in-the-wire devices that can't be monitored in some way. They make for a big nuisance when it comes time to debug the installation. The metro ethernet folks have brought us 802.1ag, 802.3ah, and Y.1731. Even the simplest of these - .1ag L2 ping (LBM/LBR) - is sufficient for my purposes of making sure that we're bidirectionally passing traffic. I'm aware of pluggable optics that do OAM (OEsolution Smart SFP) as well as some piggyback devices from other sources. I'd like to find a single box though that will do my media conversion, POE+ injection, and response to OAM packets all in one convenient tiny enclosure. Bonus points for well-thought-out details such as DIN rail mounting capability and cable retention tricks. Anyone got any pointers? -f
Re: Another LTE network turns up as IPv4-only
Subscription only, $199/year (special introductory offer, normally $499!). Try it free for two weeks but only if you cough up info. How about a summary for those of us who are disinclined to do either? -r bmann...@vacation.karoshi.com writes: https://intelligence.businessinsider.com/facebook-is-adding-over-25000-mobile-users-an-hour-2012-10 dream big /bill On Thu, Oct 11, 2012 at 08:31:44AM +0200, Tore Anderson wrote: * Cameron Byrne FYI http://www.dslreports.com/forum/r27324698-LTE-access-early- So much for next generation technology ... Yesterday, Telenor launched LTE. So. With a green-field deployment, in their home market (supposed to be the first of their tree-digit million subscribers world-wide to get all the cool new tech), built on 3GPP specs that fully supports IPv6, already proven to work by other pioneers (^5 VzW), for which there are plenty of compatible devices (again, ^5 VzW), and plenty of compatible content (^5 ISOC, et al.), four months after World IPv6 Launch (in which they participated), and one month after their RIR ran out of IPv4 addresses...launching without IPv6 support was a perfectly natural and sensible thing for them to do, it seems. *sigh* -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
Re: IPv4 address length technical design
Chris Campbell ch...@ctcampbell.com writes: Is anyone aware of any historical documentation relating to the choice of 32 bits for an IPv4 address? Cheers. 8 bit host identifiers had proven to be too short... :) -r
Re: IPv6 Ignorance
Seth Mattinen se...@rollernet.us writes: I came across these threads today; the blind ignorance towards IPv6 from some of the posters is kind of shocking. There are actually a few good points mixed in there, like the guy who observes that dual stacking is of limited utility if there are no v4 addresses to be had. I keep performing this vendor monologue. It goes something like: What do I mean when I say it must support IPv6? I mean two things. First, full feature parity with IPv4. Everything that works under IPv4 must work under IPv6. If you have exceptions, you'd better document them and have a remediation plan (or work-around if it is a deficiency baked into the standard; there are a few of which I'm aware). Second, the device must function perfectly in an IPv6-only environment, with not a hint of IPv4 addressing around. Dual-stack capability is nice, but should be an easy thing to provide if you can handle the first two requirements. Furious scribbling in the 'ol Moleskine invariably ensues. I am not sure what it is about this set of requirements (which seems so plain to see that I felt as if I was belaboring the obvious the first time I brought it up) that seems like a revelation to people in the vendor space, but apparently it does. Are *you* doing *your* part? Taken your shoe off and banged it on the conference room table Khrushchev-style lately? -r
Re: Google / Gmail SSL write errors
Paul Kelly :: Blacknight p...@blacknight.com writes: Are any of you (that use Exim as their MTA) having SSL write errors in your exim logs when delivering e-mail to Gmail or Google addresses? Don't see anything from here. More details when you post to exim-users couldn't hurt. root@valhalla [8] # grep 1TBmIa-0004lH-UH mainlog 2012-09-12 08:44:08 1TBmIa-0004lH-UH = r...@seastrom.com U=rs P=local S=549 id=86vcfjl8br@seastrom.com 2012-09-12 08:44:10 1TBmIa-0004lH-UH = ...@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [2607:f8b0:400d:c01::1a] X=TLSv1:RC4-SHA:128 2012-09-12 08:44:10 1TBmIa-0004lH-UH Completed root@valhalla [9] # -r
Re: Are people still building SONET networks from scratch?
Will Orton w...@loopfree.net writes: I've considered using J's PE-4CHOC3-CE-SFP (OC3 emulated SAToP), then I could do it all with gig-e underneath. Does anyone make a cheaper OC3 circuit emulation module or box? Most likely the customer wouldn't believe such a thing is possible and we'd have to put something in the contract allowing them SLA credit if their OC3 suffers too many timing slips or something. And so you find yourself at the intersection of two timeless maxims: 1) The customer is always right, but not everyone needs to be our customer. 2) Don't say no to the customer, let the customer say no thanks. Time to model the cost/benefit/profit margin of having these folks as a customer at all (I'd imagine that this circuit is not the only thing that they buy from you or you'd be running away even today). What are your engineering costs for this trick? Are you passing that on to the customer? You may find it advantageous to do a pricing model where you do circuit emulation on a hope-for-the-best basis and count on a maximum SLA payout every month (and still make money). Then if you fail to pay SLA credits from time to time, that's pure gravy. -r
Re: NANOG Website Redesign Project
Randy Bush ra...@psg.com writes: NANOG is in the process of completely redeveloping its website (http://www.nanog.org) and is looking for feedback from the community and NANOG members. i have been exceedingly impressed by the current web site's serious feature set implemented without a whole bunch of web glorp. i use it as an example when folk want to start barfing java and all that crap at me. I am not a fan of fsmenu.js, which persists on nanog.org even when one clicks on the text site link, which to my way of thinking ought to be free of such stuff. I'm not an accessibility expert, but animated menus don't smell accessible to me unless input devices and screen readers have gotten a whole lot better while I was not paying attention. There are various accessibility standards - BS 8878:2010 (UK), Section 508 (US, a bit of a period piece) to name a couple. Which one gets chosen is not as important as choosing one and then subjecting the site to a periodic audit to make sure it is clean. In my limited experience, conformance to such standards tends to make the site load more quickly and feel more snappy (which benefits everyone) though the difference may be fairly small on today's fast links. A clear statement of the goals of the redesign may inform the direction one's efforts take. My $0.02... -r
Re: Fair Use Policy
Hi Shahab, You can find out how much bandwidth they're using by having that reported periodically via RADIUS (or at least when the session ends, worst case). Store in database. SELECT sum(blah) from foo where id=bar. Next question is what do you want to do to them once they exceed their bandwidth? Drop them into a walled garden (different Virtual-Template / address pool)? Turn their service off? Rate shape the heck out of them so they feel like it's 1993? -r Shahab Vahabzadeh sh.vahabza...@gmail.com writes: Dear Owen, Would you please describe this some how more in my bussiness plan? I have both limited and unlimited users. For example I have these services in my package: 512Kb-5GB-1Month 256Kb-Unlimit-1Month And like this. Thanks On Thu, Aug 23, 2012 at 12:02 AM, Owen DeLong o...@delong.com wrote: Right... more specific aspect of the same coin. If you have adequate facilities, you don't need to shape users. If you have users that are overconsuming for your pricing model, there are two good solutions: 1. Raise the prices enough for everyone that you can absorb these users. 2. Implement usage-based charges (or usage based charges above a certain usage tier) that cause these users to either self-regulate or pay for the necessary upgrades to your infrastructure. Claiming to deliver unlimited service and then shaping it is, IMHO, a questionable business practice at best. Owen On Aug 22, 2012, at 12:06 , Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: What I am talking mostly is some services like COA, in which you can change users shape time-base and periodically without disconnecting them. On Wed, Aug 22, 2012 at 11:33 PM, Owen DeLong o...@delong.com wrote: If you want to control usage that way, sell a metered product. Bill the heavy users more for their usage. Otherwise, price your services such that you can build adequate upstream capacity to serve your users. I'm not a fan of using rateshaping (which is what you are describing) to cover for inadequate facilities. Owen On Aug 22, 2012, at 11:57 , Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: Dear Owen, As you know in pick time of internet usage like midnight in which we have free-access times too, some users which really want to use internet for their daily usage and not downloading or using peer-to-peer services unfairly affecting this problem. Some companies are using some polices for users to solve this problem. Do you have any Idea? Thanks On Wed, Aug 22, 2012 at 11:22 PM, Owen DeLong o...@delong.com wrote: I think the first step would be to define what you mean by fair use. Are you talking in the DMCA sense of the term, the legal sense of the term as applies to IP in other areas, or something else? Owen On Aug 22, 2012, at 11:40 , Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: Hello Everybody, Has any body any good and easy setup idea for Fair Use Policy service for my xdsl customers?! Can do this in the BRAS side and nothing done with accounting and radius? Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
Re: Comcast vs. Verizon for repair methodologies
You're lucky. Verizon did a great job installing mine (ONT on the backboard I put in the basement for them, handoff on ethernet rather than MOCA, etc) but somehow never managed to get around to dispatching anyone to actually install the permanent fiber drop (despite multiple calls). Fast-forward four months. I'd narrowly avoided messing up the temporary fiber with the lawnmower (going so far as to put orange paint on the lawn myself), but no such luck when they harvested the corn next door. Yes, my fiber got cut by a combine. You can't make this stuff up. Second time around, they did in fact manage to get the fiber buried, where I wanted it even. Had to meet with the construction survey guy, who was more than happy to put the white paint where I wanted it. -r Thomas Nadeau tnad...@lucidvision.com writes: My VZ FioS install was similarly fantastic. Those guys have figured out that spending a little more time, effort and cable (cat6 in the case of VZ) goes a long, long way in keeping customers happy. --Tom On Aug 20, 2012:7:43 PM, at 7:43 PM, Randy Bush ra...@psg.com wrote: on bainbridge, i replaced centurystink dsl (756k/256k for $65/mo) with comcast (20m/4m for $50/mo). the installer was a knarly old dog, and damned competent. he cleaned up old cable on the pole and where it went underground to the house. he cleaned up the box and replaced in-house junctions. then he accidentally left 8m of coax to get from the in-wall cable outlet to my 'puter area, and rode off in his white van into the sunset. now if i could get that kind of professionalism from twt in hawaii ... randy
NANOG poll: favorite cable labeler?
Hey everyone, Many moons ago I worked in a place where we had a Brady LS2000 wire labeler. So long as the supplies were fresh it was great. In the storage unit I have a Brady TLS2200. Supplies are expensive, but it works reasonably well. Unfortunately the battery is shot (gotta replace that). It seems to me that as cheap as the Brother P-Touch type labelers have gotten that there might be some product by (Brady|Dymo|Brother|etc) that everyone uses and recommends these days which is (a) cheap enough that they can be deployed en masse rather than treated as a scarce resource, (b) hopefully runs on standard (such as AAA) battery types, and (c) has reasonably priced supplies. Labeling cables is mostly what I'm interested in. The el-cheapo p-touch seems adequate to putting hostnames on machines. Thoughts? -r
Re:
George Herbert george.herb...@gmail.com writes: On Tue, Aug 21, 2012 at 4:06 PM, goe...@anime.net wrote: On Tue, 21 Aug 2012, George Herbert wrote: On Tue, Aug 21, 2012 at 3:25 PM, valdis.kletni...@vt.edu wrote: On Tue, 21 Aug 2012 17:11:49 -0500, Grant Ridder said: I love spam from Honduras. I am hoping that someone is going to kick this email from the members list. I'm hoping for something a tad more drastic. The bozo has an upstream, and this is NANOG. :) Back when I was at Berkeley, we used to punish offenders by routing their packets out to Finland and back (before Finland's net admins figured out what we were doing and quite rightly complained). Does anyone have a very lightly used, long long low bandwidth link they can dedicate to The Cause? I'm thinking wire cutters would be more effective. -Dan No, no, no no. The objective is to maximize wasted spammer time. The trick is to not just disconnect them - that happens every day, they just move on. It's to make their life irritating, painful, and less productive, to the point where time they'd be spending getting new business and working on new anti-filtering technology is spent corresponding with net providers and doing network quality checks, wondering if they should or have to bail out of a now flaky network. With just the right mixture, you can waste five, ten, twenty times more of their time with a carefully engineered glitch than you can just chopping them off. They've already factored wire cutters in; raise the bar. per-packet load-balancing between default route and null0 could accomplish that goal. -r
Re: Comcast 1, Verizon 0 [was: Comcast vs. Verizon for repair methodologies]
Perhaps this time they can afford to run you some real, honest-to-god Helvetica cable rather than Arial cable as you noted below. http://en.wikipedia.org/wiki/Arial#Criticism You're definitely a bigger geek than I am though for griping about the font they used for the writing on your drop cable. Just sayin. -r Patrick W. Gilmore patr...@ianai.net writes: Comcast has already contacted me to fix this up. -- TTFN, patrick On Aug 20, 2012, at 16:12 , Patrick W. Gilmore patr...@ianai.net wrote: Given the recent VZ thread, I thought I'd show why my new house has crap Internet. The story: A piece of underground cable went bad. The techs didn't pull new underground cable. They decided it was better to do it arial (if you can call 2 feet arial). They took apart the two pedestals on either side of the break and ran a new strand of RG6 (yes, the same stuff you use inside your home, not the outside-plant rated stuff) tied to trees with rope. http://ianai.smugmug.com/BostonPix/2012/Comcast-Atherton-Street These pedestals have looked like this for months apparently. I called the 800 # and complained, they rolled a truck. The guy didn't even come in my house, just gave me his supervisor's number and said that he's a home tech, the outside plant guys are the problem and he can't fix it. A second guy rolled up while we were chatting and told me he had a call around the block for the same thing. They've been taking complaints about this for months and are as tired of it as we are. I assured them I was more tired of it, given he was getting paid while I was paying, but I understood their situation. Of course, since the other broadband option at my house is 1 Mbps Verizon DSL, I don't have much leverage. :( -- TTFN, patrick P.S. Worst part is ATT sux there too, so I have a picocell - which runs over the Comcast cable mode
IRR-clueful person at 3356?
Hi folks, Sorry for the extremely broad email but I'm trying to sort out an IRR issue regarding automatic filter generation at Level(3) on behalf of a friend. The telemetry I'm getting (thirdhand and believed to originate from first line support) suggests that both Level(3)'s direct customer and any downstreams of that customer need to be in the same IRR component. If true this would be a rather startling shortcoming of their filter generation software and at odds with the whole point of having multiple components to the IRR system. Anyone got any pointers or help? Email to r...@level3.net has not gotten us anywhere, but I was not the one who sent it and can't guarantee that the right questions were asked. Thanks, -r
Re: IRR-clueful person at 3356?
Thanks to all who reached out to me in private email and on IRC. Here's the thumbnail explanation of how to do it (so some future searcher doesn't curse me for not summarizing to the list). By default Level(3) only searches one IRR component for you. I can understand why one would want to scope things this way but it sure was confusing. It's possible to have one's searchpath set to look in multiple IRR components explicitly (or * if you want more standard behavior) - these parameters are hinted at in the output from whois -h filtergen.level3.net help but you need someone in tech support to set this up for you in 3Scape; don't expect the first line guys to be able to help you beyond telling you that your update failed. There's another way though - Level(3) uses an extension to RPSL that allows one to explicitly state sources in the as-set like so: remarks: is normally just a remark and not evaluated, BUT... remarks: Level3 members: is a magic construct that will cause the rest of the line to be evaluated by Level(3) as one or more IRRCOMPONENT::AS-OR-AS-SET pairs. Apparently unqualified AS-OR-AS-SET values are allowed too, presumably to default to either whatever your normal pull-from IRR component is or from LEVEL3, but it looks as if one can't go wrong by explicitly stating each pair. Comcast and Yipes both have very nice as-sets that can be used as cheat sheets for how the grammar works: whois -h rr.level3.net as-cbc whois -h rr.level3.net as-yipes (careful with as-yipes - you get two objects back, one with a source of LEVEL3 and one with a source of RADB - it's the LEVEL3 one that you are interested in). Disclaimer: I haven't tested this all the way yet. The origin AS expands right and the friend's upstream has been updated and we're just waiting for mirroring to happen. If there's nothing further from me in this thread in a couple of days then it worked. :-) -r
Re: Does anyone use anycast DHCP service?
An anycast solution that doesn't involve a way to promptly yank the route when the service is unhappy is not really a full anycast solution. You could probably use http://code.google.com/p/dhquery/ for health checking, wrap in a script with something to talk to bgpctl (if you're running openbgpd) or something similar if you're talking to bird or quagga or whatever, loop once a second... you get the idea. Don't forget to have a hook in your script so you can send it a signal to yank the route and take the box offline without killing the service. Having the dhcp server boxes themselves speak BGP or your favorite IGP (I'm in favor of BGP for this because of policy knobs) may or may not be tenable in your organization. The optimal org chart for this sort of setup is one wherein the routing people and the systems people are the same folks. I'll go out on a limb and guess that in an organization where you're thinking of this scale of dhcp server, you're probably reporting to different VPs. So the SLB might be necessary for layer 9 reasons - something that the network guys trust to speak a routing protocol to. If you don't have transaction load problems or layer 9 problems to solve with the load balancer then I'm not sure what value it brings - assuring server availability in an anycast environment is just not that valuable (so long as the anycast environment is designed properly - see above). hope this helps! -r Joe sj_h...@hotmail.com writes: hi, We are considering setup reduant DHCP server clusers by using anycast. In our situation customer get IP address with DHCP, DHCP server authenticate customer by radius.Authentication information is carried by option60 and option82. does anybody has some suggestion on this ? if anycast is suitable for our situation, does it possible to introduce load balancer in anycast node ? that is, DHCP service availabilty is guaranteed by multiple anycast nodes, inside anycast node dhcp service availability is guaranteed by server farm behind load balancer? Joe
Re: using reserved IPv6 space
Actually, that's one of the most insightful meta-points I've seen on NANOG in a long time. There is a HUGE difference between IPv4 and IPv6 thinking. We've all been living in an austerity regime for so long that we've completely forgotten how to leave parsimony behind. Even those of us who worked at companies that were summarily handed a Class B when we mumbled something about internal subnetting have a really hard time remembering how to act when we suddenly don't have to answer for every single host address and can design a network to conserve other things (like our brain cells). -r -Hammer- bhmc...@gmail.com writes: bashes head against wall Thank you all. It's not the protocol that hurts. It's rethinking the culture/philosophy around it. -Hammer- On 7/14/12 3:20 PM, Owen DeLong o...@delong.com wrote: They're a bad thing in IPv6. The only place for security through obscurity IMHO is a small round container that sits next to my desk. Besides, if you don't advertise it, a GUA prefix is just as obscure as a ULA prefix and provides a larger search space in which one has to hunt for it... Think /3 instead of /8. Owen On Jul 14, 2012, at 1:14 PM, -Hammer- wrote: Guys, The whole purpose of this is that they do NOT need to be global. Security thru obscurity. It actually has a place in some worlds. Does that make sense? Or are such V4-centric approaches a bad thing in v6? On 7/13/12 8:41 PM, Brandon Ross br...@pobox.com wrote: On Fri, 13 Jul 2012, Owen DeLong wrote: On Jul 13, 2012, at 4:24 PM, Randy Bush wrote: keep life simple. use global ipv6 space. randy Though it is rare, this is one time when I absolutely agree with Randy. It's even more rare for me to agree with Randy AND Owen at the same time. -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://tungle.me/bross Skype: brandonross
Re: job screening question
Diogo Montagner diogo.montag...@gmail.com writes: For screening questions (for 1st level filtering), IMO, the questions has to be straight to the point, for example: 1) What is the LSA number for an external route in OSPF? This can have two answer: 5 or 7. So, I will accept if the candidate answer 5, 7 or 5 and 7. Later on (the next level of the interview), a techinical interviewer will chech if the candidate understand the differences of LSA 5 and 7. Frankly, this feels a bit like asking what the 9th byte in an IP header is used for (it's TTL, but who's, uh, counting?) -- That's why God gave us packet analyzers should be counted as an acceptable answer. If not, you'll find yourself skipping over plenty of extremely well qualified candidates in favor of those who have crammed recently for some sort of exam in hopes of compensating for their short CV. -r
Re: F-ckin Leap Seconds, how do they work?
Tyler Haske tyler.ha...@gmail.com writes: Someone running an NTP Server connected to a cesium clock could run the leap-second time code. Since its *their job* to have the correct time, they can do all the fancy rarely used things that make parts of the Internet die every couple of years. Ah, Tyler, I see the problem here. An NTP server is not like an XML-spitting web server which one consults each and every time one wants to know a piece of data (for instance a stock quote, the weather, or in this case, what time it is). NTP assumes a local clock, and the results of periodic queries to higher-than-or-equal-to-local-stratum servers are used to _discipline_ the local clock, steering it to have minimal error. Local clocks have to be consulted much too frequently (logging, timestamping, etc) for just put it in the cloud to work. You might want to read up on NTP (wikipedia provides a reasonable introduction). cheers, -r
Re: strat-1 gps
Word around the campfire is that the 18x is jittery compared to the 18. Maybe it only matters if you are super-anal. Majdi, do you have any current info on this? -r Ryan Malayter malay...@gmail.com writes: +1 on the freesd-or-linux. with say a Garmin GPS-18x or whatever timing puck. Have an intern or junior tech tackle it as a learning exercise. The time geeks on comp.protocols.time.ntp seem to favor low-power Soekris hardware (http://soekris.com/) for stratum-1s. You need RS232 serial to get decent PPS; USB introduces tons of jitter. If you have to have something pre-integrated and soon, I'd look at Meinberg: http://www.meinberg.de/english/products/index.htm#network_sync -- RPM
Re: pbx recco
Randy Bush ra...@psg.com writes: have a friend who is a penguinista and wants to run a simple soft pbx. support of soft phones, 7960s, connect to a commercial sip gate, ... reccos for a packaged solution. While Asterisk's configuration files are horrible (and written by people who didn't understand what a tokenizer is) it's really a case of the more clueful you are the worse off you'll find it. You just have to take a megadose of stupid pills in order to be happy with Asterisk's configuration. I've been using Astlinux, which allows access to the underlying files (in fact you edit them through a web interface) successfully with voip.ms (wholesale voip provider for cheap) for almost three years now. My experience fooling around with stuff like Trixbox, Askozia, and FreePBX is that there are plenty of cute GUI wrappers out there for configuring stuff, but at the end of the day as painful as handling the files directly is, it's a lot less painful than trying to work around the GUI's lossage whenever you want to do something that the designers didn't anticipate, which is pretty much all the time. Making Cisco 7940/7960 phones with SIP loads talk to Asterisk is well-documented, and their lossage modes are well-understood. Back to Astlinux, it's a pre-baked distro with click-here upgradability that will run nicely from CF on an embedded box like a PCEngines ALIX 2d3 (~15 simultaneous calls if you're not transcoding). 6 watts of power. Not a bad deal. i run a raw asterisk and would not wish it on my worst enemy. Sure you would, you'd encourage your competitors to use it. :) -r
Re: Squeezing IPs out of ARIN
Andy Susag asu...@ifncom.net writes: Seems kind of counterproductive to ARIN though. I wouldn't think they'd like a database full of fudged SWIP info, but I guess they're OK with it... They require an officer attestation. SWIP info that is made up out of whole cloth sounds suspiciously like fraud to me, but I'm neither a lawyer nor your CxO. Choose wisely. -r
Re: Cheap Juniper Gear for Lab
sth...@nethelp.no writes:
Anyway, not the best devices for an edge router that is for sure.
Which is too bad... for very small DC edge applications, the J6350
was a pretty cool router in earlier versions of JunOS that didn't
decide to re-engineer your network and transit for you.
We have 3 J2320s in the lab, all running 9.3R3.8. That's the last
*real* JunOS (no session/flow tracking) for these boxes.
They'll stay in the lab, and they'll never be upgraded to anything
newer. Which is too bad, I had great hopes for the J series.
Got a pair of J2350s in the previous job to run as part of a command
and control network. Had the same I just want this stuff to route!
experience that others have mentioned and griped about.
We tried running on 9.3 but - surprise - 9.3 won't do 32 bit ASNs.
That came in 10.1 or something. As a member of the ARIN Advisory
Council, I felt compelled to eat the same dog food that I was selling,
and we found ourselves at an impasse.
We ended up putting the CC network in VRFs on a couple of MX80s that
were already there. With a few contemptuous comments on the side we
sent the 2350s back to the VAR.
I think my successors ended up undoing the VRFs and putting Cisco
2951s in their place.
I've heard it hypothesized that this change was related to the costs
of maintaining two different packet forwarding paths (remember that
the J series used, in 9.3 and before, an emulation of the ASIC in the
hardware based routers) and that, having decided to cancel one, they
decided to cancel the less featureful one. This is a reasonable
decision to make even if we don't like it as techies.
None of the difficulties we had, however, would have gotten in the way
of the OP's apparent goal of getting comfortable typing things like
show chassis environment, request system software add, show
config | display set, and show version and haiku.
Unlike Owen I'm not going to say useless due to security { ... },
I'm going to say useful with caveats, and you might want to think
twice about what you're trying to do before moving it out of the lab.
-r
Re: Question about peering
Actually, Suresh, I disagree. It depends on the facility/country/continent, the cost of joining the local IX fabric at a reasonable bandwidth, your cost model, and your transit costs. In short, it's not 1999 anymore, and peering is not automatically the right answer from a purely fiscal perspective (though it may be from a technical perspective; see below). At certain IXes that have a perfect storm of high priced ports and a good assortment of carriers with sufficiently high quality service and aggressive pricing, a good negotiator can fairly easily find himself in a position where the actual cost per megabit of traffic moved on peered bandwidth exceeds the cost of traffic moved on transit _by an order of magnitude_. That's without even factoring in the (low) maintenance cost of having a bunch of BGP sessions around or upgraded routers or whatever. Sometimes making the AS path as short as possible makes a lot of sense (e.g. when trying to get an anycast network to do the right thing), but assumptions that peering results in lower costs are less true every day. -r Suresh Ramasubramanian ops.li...@gmail.com writes: what does it cost you to peer, versus what does it cost you to not peer? if you are at the same ix the costs of peering are very low indeed On Saturday, April 7, 2012, Anurag Bhatia wrote: Hello everyone I am curious to know how small ISPs plan peering with other interested parties. E.g if ISP A is connected to ISP C via big backbone ISP B, and say A and C both have open peering policy and assuming the exist in same exchange or nearby. Now at this point is there is any minimum bandwidth considerations? Say if A and C have 1Gbps + of flowing traffic - very likely peering would be good idea to save transit costs to B. But if A and C have very low levels - does it still makes sense? Does peering costs anything if ISPs are in same exchange? Does at low traffic level it makes more sense to keep on reaching other ISPs via big transit provider? Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia https://twitter.com/#!/anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Question about peering
Luke S. Crawford l...@prgmr.com writes: On Sat, Apr 07, 2012 at 06:16:30PM -0400, Robert E. Seastrom wrote: Sometimes making the AS path as short as possible makes a lot of sense (e.g. when trying to get an anycast network to do the right thing), but assumptions that peering results in lower costs are less true every day. I keep reading people say that. But wouldn't the same forces that push down the per-megabit cost of transit also push down the per-megabit cost of peering? Generally the costs of transit are pushed down by competition. As a vendor your costs for bandwidth/transport/port*bw may drop but you are unlikely to drop your prices to your customers merely because your costs have gone down unless prompted to by a competitor. In any given IX, cross-connect fibers and peering switch ports are often a monopoly. While not unheard-of for there to be two competing IX switch fabrics available in a single facility, the cross-connects to those competing exchanges are not free, and I'm not aware of any sizeabe facilities that are still run your own XC and don't pay anyone for it (of course, as soon as I say that I'll get private email or an IRC message pointing out the corner case). Consider the case of a peering n00b network (the target of this discussion after all) in hypothetical facility that charges $1000/month for a gigabit ethernet port on the peering fabric. You turn up a connection to this port and discover that (without buying people drinks / sushi dinners / etc at a conference) you can bring up enough peering with other networks to move 150 Mbit/sec on it. That's pretty optimistic for a small player, but still... now you're paying $6.66/mbit for that transit. If you can move 150 Mbit/sec to low-hanging-fruit transit you're probably between 1 and 2gbps total. How's that compare with what you're paying for transit with that level of commit? -r
Re: Question about peering
Luke S. Crawford l...@prgmr.com writes: On Sat, Apr 07, 2012 at 07:25:24PM -0400, Robert E. Seastrom wrote: Generally the costs of transit are pushed down by competition. As a vendor your costs for bandwidth/transport/port*bw may drop but you are unlikely to drop your prices to your customers merely because your costs have gone down unless prompted to by a competitor. ah, so it's not the cost of production that is the problem, it is the 'natural monopoly' state of an IX that is the problem. It seems like that problem could be overcome by making the IX a cooperative owned by the members, maybe? The whole datacenter? Consider the case of a peering n00b network (the target of this discussion after all) in hypothetical facility that charges $1000/month for a gigabit ethernet port on the peering fabric. You I am in almost that exact position (A peering n00b network) - Of couse, I'm fairly certain I'm paying sucker prices, but I can get a gigE to any2 at 55 s market for less than a third the price you quote. just a data point. You might want to analyze peering opportunities there: https://www.peeringdb.com/private/facility_view.php?id=20peerParticipantsPrivatesPage=1 and get some netflow data out of your own network to see just how much traffic you're sending there. Fairly easy to do with only 34 participants. Excel Will Tell You What To Do (tm vgill) -r
Re: SIP Carrier Consolidation
SIP trunking consolidation is buzzword heavy and context-light. What problem are you trying to solve and at what scale? Do you have a requirement to have the provider be a traditional TDM-based organization or is an aggregator sufficient? How price-sensitive are you? At fairly small scale (10 DIDs including some 877 numbers, feeding to Asterisk) I've had fine luck with http://voip.ms/ But your requirements may vary... -r Elijah Savage esav...@digitalrage.org writes: Anyone here that have gone through the process of SIP trunking consolidation care to comment offline on Whom do you utilize? What has been your experience operationally? What was your experience during transition/implementation? Thank you ahead of time.
Re: Verizon, FiOS, and CLEC/UNE orders (was ATT diversity)
Jimmy Hess mysi...@gmail.com writes: Seems like a waste for VZ not to reclaim it so it can be recycled/put to good use. To put some numbers with this statement (which I agree with btw): OSP cable is commonly available composed of 19 AWG, 22 AWG, 24 AWG, and 26 AWG pairs. 19 and 26 are outliers; 19 is for low pair count cables going extra long distances and 26 is only good for quite short distances (CO/SLC to customer) but Superior Essex makes a 3000 pair cable in #26 (22 and 24 max out at 900 and 1800 pair, at least on the spec sheet I have handy). Most of the cable out there is 22 or 24. Solid #22 and #24 (uninsulated) copper wire weighs 1.95 and 1.23 pounds per 1000 feet respectively. That's without the insulation, and only one wire, not a pair. I found scrap pricing for telco (obviously the contaminant ratios out there are different for different types of copper) at $1.20/pound, which may or may not be current, but if you figure a single pair of #24 is probably around 4 pounds per 1000 feet scrap weight... if an average loop is, say, 5000 feet, you can see where there is substantial incentive to recycle all the 600 pair that you have lying around. -r
Re: Verizon, FiOS, and CLEC/UNE orders (was ATT diversity)
William Herrin b...@herrin.us writes: That depends on the cost of recovering it. We're not talking about salvage operators pulling cable, we're talking about highly trained [sic] Verizon installers. The last 4 pairs in use on that 3000 count cable will tend to linger a long, long time before you can go remove it. Mostly you'll recover short runs of low-count cable like the fifty-foot two and six pair cables from the street to the house: maybe $3 in scrap. How many dollars worth of time will the installer bill Verizon for recovering it? I bet there is some kind of creative accounting that they can use that makes this totally worthwhile window dressing on their 10-Qs. -r
Re: shared address space... a reality!
More like wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want. not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours? -r George Herbert george.herb...@gmail.com writes: What, senior network people testing out new test/transitional space at home before they test it at work is bad? On Thu, Mar 15, 2012 at 6:26 AM, Jérôme Nicolle jer...@ceriz.fr wrote: Le 15/03/12 07:59, Randy Bush a écrit : and i have configured two home LANs to use it So wrong... -- Jérôme Nicolle -- -george william herbert george.herb...@gmail.com
Re: shared address space... a reality!
George Herbert george.herb...@gmail.com writes: On Thu, Mar 15, 2012 at 1:57 PM, Robert E. Seastrom r...@seastrom.com wrote: More like wasting no time in fulfilling the prophesy that people will treat it like just another rfc1918 space and deploy it wherever they want. not that randy is likely to get bitten because he's not behind a cgn nor is he planning to be, but still, that took all of what, 72 hours? -r I think this is people reading their preconceived notions onto the situation. I understand the policy disagreement about having the space in the first place. That said... Your and Jerome's reactions seem to amount to Not only should you never have done this, actually testing it in the normal informal operational area once it's here and approved is a further insult. My counterargument is - if you are suggesting people should be less professional about testing out the new space than they are for any other new thing, then you're being political and not operational. Operationally this is exactly the right thing to have Randy do. He certainly didn't need to do this because he's exhausted 1918 space at home (well, I hope not... 8-). In the unlikely but not impossible event that Randy is on 1918 space at home and has the external address of his consumer home gateway configured into this space, and thence to a CGN appliance or blade in the Big Router at his perimeter where he gets NATted into a globally unique address (i.e., the meat in a NAT444 sandwich), or something similar, then I certainly stand corrected. I encourage this sort of testing. I'm not reading my preconceived notions of anything other than Randy's personality and very vocal assertions of what people would do with this space if it got assigned into my assessment of what's going on here. Inasmuch as I am pretty sure I'm in Randy's .procmailrc, y'all will have to ask him directly; don't expect him to chime in replying to my mail. -r
Re: Verizon FiOS - is BGP an option?
Faisal Imtiaz fai...@snappydsl.net writes: I am not familiar with VZ's FIOS network... however I suspect that if they are using a Redback at the Headend, it would allow you to have a 'bridge' network with secure arp settings. (it's a feature that we have seen on Redback's...) AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. A cursory survey of two (older, BPON, Tellabs) builds found ethernet OUI 00:90:1a, i.e. Juniper ERX. -r
Re: Verizon FiOS - is BGP an option?
Christopher Morrow morrowc.li...@gmail.com writes: On Wed, Mar 14, 2012 at 8:14 PM, Robert E. Seastrom r...@seastrom.com wrote: Faisal Imtiaz fai...@snappydsl.net writes: I am not familiar with VZ's FIOS network... however I suspect that if they are using a Redback at the Headend, it would allow you to have a 'bridge' network with secure arp settings. (it's a feature that we have seen on Redback's...) AFAIK Verizon does not use Redback/Ericsson stuff for FIOS and never has. A cursory survey of two (older, BPON, Tellabs) builds found ethernet OUI 00:90:1a, i.e. Juniper ERX. yes, all edge boxes for FIOS are ERX... better support for CALEA there was one of the major drivers. So it was _one_ of the drivers, but was it a more major driver than for the love of God, not Redback!? :) -r
Re: Shim6, was: Re: filtering /48 is going to be necessary
Doug Barton do...@dougbarton.us writes: On 3/11/2012 3:15 PM, Iljitsch van Beijnum wrote: But ARIN's action meant it never had a chance. I really don't get why they felt the need to start allowing IPv6 PI after a decade Because as far back as 2003 ARIN members (and members from all the other RIRs for that matter) were saying in very clear terms that PI space was a requirement for moving to v6. No one wanted to lose the provider independence that they had gained with v4. Without that, v6 was a total non-starter. ARIN was simply listening to its members. It didn't help that there was initially no implementation of shim6 whatsoever. That later turned into a single prototype implementation of shim6 for linux. As much as I tried to keep an open mind about shim6, eventually it became clear that this was a Gedankenexperiment in protocol design. Somewhere along the line I started publicly referring to it as sham6. I'm sure I'm not the only person who came to that conclusion. Grass-roots, bottom-up policy process + Need for multihoming + Got tired of waiting = IPv6 PI -r
Re: Shim6, was: Re: filtering /48 is going to be necessary
Ryan Malayter malay...@gmail.com writes: On Mar 12, 10:07 am, Robert E. Seastrom r...@seastrom.com wrote: It didn't help that there was initially no implementation of shim6 whatsoever. That later turned into a single prototype implementation of shim6 for linux. As much as I tried to keep an open mind about shim6, eventually it became clear that this was a Gedankenexperiment in protocol design. Somewhere along the line I started publicly referring to it as sham6. I'm sure I'm not the only person who came to that conclusion. I thought the IETF required two inter-operable implementations for protocols. Or was that just for standards-track stuff? Rough consensus and working code is soo 1993. -r
Re: BGP MD5 at IXP
Andy Davidson a...@nosignal.org writes: Because TCP MD5 packets touch a router's CPU, using MD5 introduces a new attack vector - see nanogii passim (e.g. http://www.nanog.org/meetings/nanog39/presentations/Scholl.pdf). Don't do it. :-) Tom's slide deck is often misinterpreted - the salient parts are on pages 13 and 16. The big problem is that random packets can hit the control plane - AT ALL. One can kill it just as easily with a synflood on some other tcp port (perhaps ssh or even one that it isn't listening on?). Hopefully your modern exchange point router has some sort of control plane policing. Indeed, hopefully your backbone routers have some sort of control plane policing mechanism and you have turned it on and subjected your policy to some scrutiny. Blowing up un-password-protected BGP sessions by spoofing has not turned out to be a big problem in recent years. It probably helps that the dangers of highly predictable ISNs have become well-known (and hopefully acted upon by router vendors but history has shown that making blanket statements about that sort of thing on NANOG is unwise). A read of http://tools.ietf.org/html/rfc6528 may prove instructional. Turning on or off md5 makes minimal difference in CPU loading either during an attack or not, but it is another thing to get wrong - operational complexity without significant reward. I agree with Andy's conclusion. Don't do it unless whoever you're peering with demands it. It's not worth the complexity to set it up in the first place, and it's not worth your time to argue against it if someone is quite convinced that enabling md5 on your bgp session will save the world. -r
Re: Concern about gTLD servers in India
Anurag Bhatia m...@anuragbhatia.com writes: Can someone share if there's huge difference in . root servers Vs gTLD servers? I understand that root only hold all TLD's - cc and gTLD delegation that would be few hundred TLDs delegation while gTLDs hold lot of domain names but if one country has root, what prevents having gTLD also? Certainly bit more hardware, storage and processing power but such facilities are available mostly say in India South Africa which have significant number of big telcos. There's a huge difference in operational complexity (and capex) between running root nameservers and gtld nameservers (to further confuse things, there are four gtlds, only two of which are run gtld-servers.net infrastructure, which means that Verisign is the operator). Root zone = a few thousand records with changes gated by people with a high degree of DNS clue, that come at a slow pace (once or twice a day typically). The roots eat a fair amount of bogus traffic (mitigated somewhat by things like the as112 project) due to poorly configured libraries and people's mistyping. It is trivial to run a shadow root locally by just secondarying . on your cacheing nameservers. In fact, recent versions of FreeBSD have had a config like this to replace the named.root hints file - you just have to comment out the hints section and uncomment the secondary section in /etc/namedb/named.conf. You can do this on something as small as a wall-wart firewall device assuming it's running something like BIND. Obviously something that is exposed to the Internet as an anycast node will be built on much more capable hardware. A typical gtld zone will have anywhere from a few million to high tens of millions of records in it. Everyone and his brother has a vanity domain and together the update load and expectations of the customers are that changes will be committed instantaneously and visible across all nameservers for the gTLD within a few minutes at the outside. This update rate is a huge pain in operational practice and the sheer number of records eats a pretty decent sized memory footprint too. To answer your question, to get TLD anycast stacks in any given location, there will need to be a discussion with the TLD operator; in the case of the GTLDs that would be Verisign (.com and .net) and Afilias (.org and .info). In the case of sTLDs, GeoTLDs, and CCTLDs, the cast of actors expands considerably. No such thing a a one-stop shop. There is also an issue of cost/benefit. In the current economic climate assuming that organizations have unlimited resources to commit to the public good (regardles of how noble their intentions might be) is probably unwise. Does this help? -r (no longer an employee of a TLD op)
Re: Switch designed for mirroring tap ports
A. Pishdadi apishd...@gmail.com writes: We are looking for a switch or a device that we can use for mirroring tap ports. For example , take a mirror port off of a core router say a 6509, connect it to a port on said device, say port 1. I would like then to be able to mirror port 1 on said device to multiple ports, like port 2 , 3, 4. We have the need to analyze traffic from one port on multiple devices. Seems most switches are limited to mirroring to a max of 1 or 2 ports. http://www.netoptics.com/products/regeneration-taps Been reasonably happy with these on 100m and gigabit links in the past, can't imagine that their 10g products don't work just as well. -r
Re: Programmers with network engineering skills
Is clearance the problem, or the ability to obtain clearance due to something in their background? If your work requires it, you should have some recourse for applicants to obtain the required clearance, no? My understanding is that while primary and subcontractor companies can put people in the sponsoring organization's clearance granting queue, it takes so long to get someone through the queue that for high-level positions they essentially make having the clearance already a prerequisite. Things have gotten a lot better than they used to be. My understanding is that these days a DoD collateral TS is routinely completed in 6 months. -r
Re: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
Randy Bush ra...@psg.com writes: well, not exactly. to quote myself from the other week in another forum [ 30 lines deleted ] Sorry to drone on, but these three really need to be differentiated. The truly wonderful thing about the evolution of BGP security is its elegant simplicity. It is good to know that the barriers to entry for the IRR system (templates, objects, Dear Colleague emails from the auto-dbm robot, etc) have been eradicated in favor of simple, easy-to-understand and maintain maintain digital certificate chains. I predict epic uptake the likes of which we haven't seen since I filed my last NACR. -r
Re: US DOJ victim letter
bmann...@vacation.karoshi.com writes: I missed the part where ARIN turned over its address database w/ associatedd registration information to the Fed ... I mean I've always advocated for LEO access, but ther has been significant pushback fromm the community on unfettered access to that data. As I recall, there are even policies and processes to limit/restrict external queries to prevent a DDos of the whois servers. And some fairly strict policies on who gets dumps of the address space. As far as I know (not very far) bundling the address database -and- the registration data are not available to mere mortals. So - just how DID the Fed get the data w/o violating ARIN policy? Hi Bill, In case you're not trolling here (occam's razor says I'm giving you too much credit), a few points: 1) There has been substantial involvement by Federal LE at ARIN PPMs in terms of pushing for policy that makes WHOIS data more accurate... including one person who served on the ARIN AC after he went to work in the private sector. 2) LE can type show ip bgp too and only needs to hit a whois server once per ASN. 3) There is a bulk whois policy. Whether hi, we now have the reins of a compromised botnet or whatever and want to reach out to let people know that they're pwn3d falls under the rubric of Internet operational or technical research purposes pertaining to Internet operations is left as an exercise to the reader. Section 3.1 of the NRPM says that Bulk Whois ... point of contact information will not include data marked as private. As I outlined in #2 above, a full or partial dump is not really something that's necessary. https://www.arin.net/resources/agreements/bulkwhois.pdf I'm pretty confident there were no policy violations here. -r
This network is too good...
Hi all, Any thoughts on products that screw up networks in deterministic (and realistic found-in-the-wild) ways? I'm thinking of stuff like PacketStorm, Dummynet, etc. Dial up jitter, latency, tail drop, RED, whatever... (I know someone's gonna say Just buy a Brand Z FubarSwitch 3k, they will screw up your whole network and you don't even have to configure it to do so!) I'm all-ears like Ross Perot. Thanks, -r
Re: using ULA for 'hidden' v6 devices?
Tim Chown t...@ecs.soton.ac.uk writes: On 26 Jan 2012, at 16:53, Owen DeLong wrote: On Jan 26, 2012, at 8:14 AM, Ray Soucy wrote: Does this mean we're also looking at residential allocations larger than a /64 as the norm? We certainly should be. I still think that /48s for residential is the right answer. My /48 is working quite nicely in my house. There seems to be a lot of discussion happening around a /60 or /56. I wouldn't assume a /48 for residential networks, or a static prefix. The big question is what constitutes an end site and do we want/need to have multiple classes of end site in the interests of conserving IPv6 space, or do we want to have only a single class in the interests of conserving technical person brain cells? Food for thought: There are approximately 7 billion people in the world right now. US billion, 10^9. If we defined an end site as an Internet provider access device that could allow subsidiary devices to connect downstream... AND Every human on the face of the earth was Avi Freedman or Vijay Gill and had ten cell phones that would act as APs, each of which with its own /48... THEN... We would be using between 2^36 and 2^37 end site allocations (70 billion). OR between a /11 and a /12 OR right around 0.03% of the space, assuming 100% utilization efficiency. If the goal in putting small chunks of space at residences is to conserve space in order to fit within the RIR's policies, then it is the policies that ought to change. Stewardship is not the same as parsimony. -r
Re: VZ FiOS DNS issues:
Christopher Morrow morrowc.li...@gmail.com writes: On Sun, Jan 22, 2012 at 11:29 AM, Brandon Kim brandon@brandontek.com wrote: I have FIOS and I have no issues. However I do know awhile back they had issues and I was affected by the outage Maybe it hasn't made its way to me yet there have been instances over the time i've been a fios customer that 'upgrades' to devices in the field have caused this problem (last was ~2wks ago? in the washington, dc area). Could be you are seeing this problem affecting you :( I'm a FIOS customer (LATA 246 not 236 like Chris), and haven't had any issues with the network. On the other hand, between my location and the fact that I'm on an old BPON build, perhaps the software upgrades haven't affected me. To further complicate things, ever suspicious of ISP nameservers that don't do DNSSEC validation and monetize rcode 3, and not a fan of the Actiontec boxes that Verizon hands out I run my own cacheing nameserver (hand-built openbsd+pf on embedded hardware with latest bind or unbound and isc dhcpd). Do things magically start working for you if you hard-code 8.8.8.8 or 4.2.2.1 or one of the other usual suspects? That would seem to be a quick way of narrowing it down a bit. -r
Re: VZ FiOS DNS issues:
Jamie Bowden ja...@photon.com writes:
I don't care for the Actiontec boxes either, but the STB program
guides and other features don't work without it, so I have mine
forward all IP traffic unmolested to my own as the DMZ host
Actually this can be worked around. My config has SA, er, Cisco STBs
and a Netgear MCAB1001 MOCA to Ethernet bridge. This configuration is
very unsupported, which is why I keep a completely unmolested
Actiontec around to plug in if I have to have the guys at Verizon take
a look at it.
A little magic in dhcpd.conf:
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1 ;
option domain-name-servers 71.252.0.12 ;
default-lease-time 86400 ;
max-lease-time 172800 ;
host stb100 { hardware ethernet 0:23:be:xx:xx:xx ; fixed-address
192.168.1.100 ; }
host stb101 { hardware ethernet 0:21:be:xx:xx:xx ; fixed-address
192.168.1.101 ; }
host stb102 { hardware ethernet 0:25:2e:xx:xx:xx ; fixed-address
192.168.1.102 ; }
host stb103 { hardware ethernet 0:21:be:xx:xx:xx ; fixed-address
192.168.1.103 ; }
}
and then some appropriate holes in the firewall (/etc/pf.conf):
# for STBs
pass in quick on $extif inet proto tcp from any to ($extif) port 35000 rdr-to
192.168.1.100 port 7547
pass in quick on $extif inet proto tcp from any to ($extif) port 35001 rdr-to
192.168.1.101 port 7547
pass in quick on $extif inet proto udp from any to ($extif) port 63145 rdr-to
192.168.1.100 port 63145
(I only have one DVR and one STB - the definitions for extra STBs came
out of the Actiontek. Not sure what I'll end up needing to do if I
get another DVR or STB in order to get them properly provisioned...)
Guide and VOD work fine. I don't feel like playing stuff from a PC on
the STBs badly enough to be willing to cram my whole life into a flat
192.168.1/24, so I give those up.
I've often wondered whether the boxes care about double-hopped NAT.
Perhaps one of these days I'll try putting the Actiontek and some new
pf.conf rules in place of the Netgear and give that a try.
(thus
the dual layer of [P|N]AT you see). It's just UDP/TCP 53 traffic
that's not flowing for whatever reason; it's every device in the
house phones, tablets, computers, you name it, so I'm not inclined
to attribute it to malware. My neighbor was also seeing it (and
like last time, it seems to have magically resolved itself after
~1.5h). I'm just wondering what Verizon is DOING that they are
screwing up their own DNS traffic. If they were capturing my
queries and sending them to their own servers (I actually have
Google's public facing servers at the top of the list handed out by
DHCP) that would be one thing (irritating to be sure, but they
aren't, so it's not), but when I'm explicitly hitting a name server
down the street in Reston that VZ run and it's failing the same way?
It makes me wonder.
No idea, just a datapoint that we're Not Seeing That Here... but if
it is failing on google's public dns servers that's troubling to say
the least.
-r
Re: enterprise 802.11
Jay Ashworth j...@baylink.com writes: - Original Message - From: Jared Mauch ja...@puck.nether.net network side. I'm personally not convinced of the value of very short lease times (less than an hour) Less than an hour, perhaps not. On small residential networks, though -- generally, anything where the router (which will need to get rebooted occasionally) *is* the DHCP server -- I tend to set the timeout to 30-60 minutes, to reduce the race window between when a router is rebooted, and when a new device shows up and conflicts because it's given an IP another device still thinks it owns. Another thing that works (in environments where you can get away with it) is an enormous dhcp pool and super long leases with walking-the-whole-space behavior and persistent-across-reboots behavior on the part of the DHCP server. The built-in server on the Mikrotik platforms will do this. Configuring a /16 worth of 1918 space with a 3 week lease for a campground that typically hosts 1 week long events has handily dodged the issue for me. Admittedly this is a corner case... -r
Re: De-bogon not possible via arin policy.
What do you mean by de-bogon? Do you mean that your customers' addresses are listed in various RBLs for previous misbehavior? That they are using addresses that were never properly allocated to them? Something different? You don't own IPv4 addresses; they are assigned or allocated to you in response to demonstrated need. ARIN takes into account your history of needing IP address space when evaluating your request for more address space to be assigned or allocated to you. If you have not been back to ARIN for address space recently (or ever, if these are legacy addresses), you may find yourself subject to slow start just like a newly established entity. It does not sound as if ARIN rejected you for an IPv4 allocation. From your statement below, it sounds as if ARIN approved you for a /18, which is reasonable and in accordance with current policies. If you walked in to ARIN and asked them for 10 million IPv4 addresses (which is on the order of 1/8 of the total that ARIN has on hand, for everyone), it is unsurprising that they declined. If you can clarify the problem, it's possible the community may be able to offer assistance. -r PS: I'm on the ARIN Advisory Council, which means that I help with policy creation. Neither I nor my 14 colleagues on the AC are employees; staff won't discuss particular cases, etc. So if you want us to know something, you'll have to state it here or in private email or something. Cameron Byrne cb.li...@gmail.com writes: Fyi, I just was rejected from arin for an ipv4 allocation. I demonstrated I own ~100k ipv4 addresses today. My customers use over 10 million bogon / squat space ip addresses today, and I have good attested data on that. But all I can qualify for is a /18, and then in 3 months maybe a /17. This is called slow start ? For an established business? Just fyi, de-bogoning , or private rfc 1918 is not really an option even with strong and consistent demonstrate load. Any suggestions on how to navigate this policy ?
Re: IP addresses are now assets
valdis.kletni...@vt.edu writes: Would it be correct to summarize the ARIN position as It's murkier than Cerner makes it out to be, and some lawyers are gonna get stinking filthy rich litigating this one? :) In any litigation, Counsel always wins. I often remind myself that there's still time to go to law school. :-) -r
Re: Network device command line interfaces
Doug Barton do...@dougbarton.us writes: On 11/24/2011 11:58, Jonathon Exley wrote: That's the problem - as a propellorhead I don't make the purchasing decisions. I can recommend products but low cost speaks more loudly than this gear is a dog to work with. That's where you get a chance to impress the business folks by using terms like total cost of ownership. You make the case that while product X may have a higher capex, that's a one-time expense that can be amortized and/or depreciated. Whereas the opex for product Y is going to be higher for the life of the thing. Make sure to tart up your estimate by including the developer costs of the tools you will need to verify that changes are correct and/or disaster recovery because everyone is human, and the horrible UI magnifies the likelihood of an innocent fat-finger mistake turning into a complete meltdown (or worse, a security hole that no one sees until it's too late). What Doug said. Also, don't forget the value of letting the decision makers know the worst-case. It's not really FUD if you're just opening their eyes to the consequences of their buying decisions. For instance, if you can't back the config of the device up in a human-readable/mergeable format (or worse yet, can't back it up _at all_), consider the cost per hour of downtime on a 24 port switch with a bunch of random office workers connected whose fully loaded hourly cost (including cost of office space, health insurance, employer part of FICA, etc) is, um, let's be cheap and say $40/hour. Funny how this puts the cost of both CLI-based stuff *and on-site spares* in perspective. We can't buy it if I can't back it up with RANCID because of the negative impact it has on our business continuity is a good way to put this into terms that the folks who hold the purse strings can understand. -r
Re: OT: Traffic Light Control (was Re: First real-world SCADA attack in US)
Mark Radabaugh m...@amplex.net writes: On 11/23/11 11:23 AM, valdis.kletni...@vt.edu wrote: On Wed, 23 Nov 2011 11:14:34 EST, Bryan Fields said: So really all a hacker needs is a pair of dykes, some electrical tape, and an all black jumpsuit. Actually, you want a really dark blue jumpsuit. All-black creates a sillouette in all but the very darkest conditions. White service truck, orange cone, jeans, heavy cotton shirt and an orange vest in the middle of the day is far less noticeable. Don't forget the hard hat. Aluminum forms clipboard and Nextel phone complete the outfit but are optional. -r
Re: Any recommended router. They are reliable and have good support.
Leigh Porter leigh.por...@ukbroadband.com writes: Has anybody had experience of mikrotik support? Is it any good? Any thoughts about the time to fix bugs? I have dealt with Mikrotik support. They were easily comparable to [CJ]TAC. Which is to say guy was pleasant and courteous, I could tell through the language barrier that he wasn't really interested in addressing my problems or understanding them, and eventually I got exasperated and figured out a work-around. That said, it's easy to exceed expectations when you've spent something like $70 on a router that does five ports of gigabit ethernet. Several dot releases after that little ordeal, at least one of my laundry list of problems (ssh connections blew up if you are using application layer keepalives) seems to have gotten fixed, at least in 5.8, with nary a mention in the release notes so I assume it was a matter of syncing the codebase to whatever they run for an ssh server. Still no fix for the your CLI only partially implements Emacs key binds, please try libcli.a which is LGPL instead, which is annoying since this shortcoming is really up in your grill whenever you're logged into the router. Still can't traceroute to an IPv6 host by name, only by number. Dunno if they figured out what the G in GRE stands for yet and started allowing protocols other than IPv4 (and ethertypes other than 0x0800) in a GRE tunnel - can't be bothered to test it out since I managed to get 6in4 tunneling working instead. There are more random gripes, but you get the idea - routeros definitely shows a certain lack of polish but can get the job done for low-end stuff at a very acceptably low-end price. All in all, despite the gripes it's worth your time to check out. Don't let the folks who sing their praises get your hopes up too much but hey, for pocket change invested? Pretty decent. There are some good surprises in there too, like putative support for 32 bit ASNs (haven't tested that myself) and scriptability that will allow you to send TSIG-signed dns update messages periodically for when you have customers to support that are on the far end of a non-sticky DHCP. -r
Re: Fwd: Welcome to the Marketing mailing list
To echo what Betty said and address an unspoken concern: market...@nanog.org is the mailing list (and external interface?) for the folks who make sure that there are good cookies and other break goodies, beer-n-gear sponsors, meeting hosts, etc. It is most assuredly not a spamming list, which I suppose is probably what went through folks' minds when they got that email. I know that's what I would be wondering if I randomly got that kind of mail with no background info. If you've ever been unfortunate enough to manage Mailman, you're probably as astonished as I am that this sort of pilot error doesn't happen more often. :-) Now that that's out of the way, if you think you might have something to contribute to the community (marketing or otherwise) they're always looking for volunteers... so maybe you *want* to be on that mailing list - the community will be grateful. -R (former Board, fomrer MLC) Betty Burke be...@nanog.org be...@newnog.org writes: Everyone: This was truly just a honest mistake on my part. You are all right, should not have happened and I apologize. market...@nanog.org is a list used in connection with Sponsorship inquiries/activity. refer to http://www.nanog.org/sponsors/ Membership of market...@nanog.or is the Development Committee and NANOG Staff. As I indicated, I was planning to update the members@nanog,org list, and just happened to be in the wrong interface. All best. Betty On Thu, Nov 17, 2011 at 1:15 PM, Richard Golodner rgolod...@infratection.com wrote: On Thu, 2011-11-17 at 09:35 -0800, Owen DeLong wrote: Can someone explain this one to me? 1. Why was such a list created? 2. Why was I automatically subscribed to it? 3. Why was this done without notice to the community? Thanks, This has a lot of us wondering the same as Owen. This is also not typical of how NANOG does things. Hopefully as the day progresses we will get some insight. Richard Golodner -- Betty Burke NewNOG/NANOG Executive Director Office (810) 214-1218 Direct (510) 492-4030
Re: economic value of low AS numbers
Jeffrey Ollie j...@ocjtech.us writes: On Thu, Nov 17, 2011 at 2:52 PM, Jay Ashworth j...@baylink.com wrote: The real question is whether it was issued after HHGTTG. HHGTTG first appeared on the BBC in 1978. Thinking Machines Corporation was formed in 1982. As far as I can tell the first BGP RFC is 1105 and was published in 1989. http://tools.ietf.org/html/rfc827 -r
Re: NANOG Board Announcement
Steven Feldman feld...@nanog.org writes: I am sad to announce that Robert Seastrom has resigned from the NewNOG Board of Directors, effective yesterday. Accordingly, the board has selected Michael K. Smith to fill the vacant position between now and the October Election. Just wanted to follow up on this. It's been an honor to be able to serve the community in this way, but lately my personal commitments (work and family) have made it impossible to live up to the SLA which I feel I owe NANOG, so I felt it was my duty to make room for someone who has the bandwidth to contribute in the way that I wish I could. I'm really excited to see Michael stepping into this new role; his record with the Communications Committee speaks for itself and I think he's absolutely the right guy for the job. Hats off to Michael. See you in San Diego! [*] -r [*] I won't be at the October meeting. My fiancee has made it clear that a NANOG and ARIN honeymoon is not on her top 10 list, and declined a suggestion that we submit our wedding vows to the ARIN AC on a policy template.
Re: ICANN to allow commercial gTLDs
Randy Bush ra...@psg.com writes: what's new? how about the operational technical effects, like data from modeling various resolvers' responses to a large root zone? I think the proper model is popular TLDs, perhaps the traditional gTLDs. As any (even former) decent sized TLD operator can tell you, both BIND and NSD are both quite functional for this, and there are also some proprietary authoritative nameservers out there that have excellet performance. Getting north of 100k queries/second answered authoritatively [*] from a single nameserver process on a single box (large zone, millions of records) is almost something one can do with an out of the box config. Things can get hairy with high update rates, so I'd encourage ICANN to dig in its heels about the 2x per day update rate, though even if they did it on demand, the $185k fee is probably sufficient to keep the number of delegations, and thus updates, down to a dull roar. An interesting question is what the load effects will be on the root. Inasmuch as the root operators (who can provide more detailed data themselves) send NXDOMAIN, REFUSED, or some SOL-semantically-similar response to 99%+ of the queries they get already, even a two order of magnitude lift on the number of legit queries will result in only a 2x lift in load on the roots. The operative question is is two orders of magnitude a safe guess?. I don't have a good answer for that. The team over at ICANN has already likely thought this through in insane detail and I'm not saying anything new (to them anyway). Maybe they can speak to it. -r [*] to be pedantic, the AA flag is not set on the response to an NS query to a delegating nameserver. We'll call it authoritative anyway, since it is for the zone in which the delegation lives. :-P
Re: ICANN to allow commercial gTLDs
Matthew Palmer mpal...@hezmatt.org writes:
And it only gets better from there... how many places have various cutesy
naming schemes that might include one or more trademarks (or whatever) that
someone might want as a TLD?
As it happens, I have a set of routers that are named { craftsman,
makita, dewalt, black-and-decker, jet } etc. A couple of notably
small ones are named dremel and proxxon. Likewise, our VM hosting
machines are named after container shipping lines. Trademarks and
candidates for dropping $185k on a TLD all.
In my experience this sort of naming scheme is the rule rather than
the exception.
-r
Re: What vexes VoIP users? - Bufferbloat
Jim Gettys j...@freedesktop.org writes: Now that I have mitigated the bufferbloat disaster in my home cable service via bandwidth shaping, Skype works sooo much better for me. This is what devices such as Ooma are doing. Unfortunately, it means you have to defeat features such as Comcast's PowerBoost. Actually not... if your queueing scheme is smart enough to stay one step ahead of PowerBoost it works fine. https://calomel.org/pf_hfsc.html I run flashrd/OpenBSD 4.8 on an ALIX 2D3. Love it. -r
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Mark Andrews ma...@isc.org writes: It's not usable as general purpose unicast. Both those drafts attempt to do that. http://tools.ietf.org/html/draft-wilson-class-e-00 does not. Recommend you re-read. It would be possible to use it as restricted purpose unicast, i.e. to connect from a cpe border router to a 6rd and/or LSN with the cpe border router signaling that it support the use of class E addresses when it requests a address from upstream. The upsteam only returns a class E address when it is sure that the network between the LSN/6rd supports class E traffic. The contemporary discussions we had on this subject centered around management infrastructure for MSOs, not 6rd (which was still a twinkle in the Bad Idea Fairy's eye at the time). Not speaking for Paul here, but it was not our intention to box in possible use of this space, only to mark it as sufficiently toxic that end users and normal enterprises would stay away. Would be great for 6rd if that's what folks wanted to use it for and could get the CPE vendors to cooperate. -r
Re: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer...
Owen DeLong o...@delong.com writes: The DoD does not seem particularly anxious to announce or explain their usage of those blocks to the rest of the community. They have much larger quantities of significantly more sophisticated armaments than ARIN. I agree it would be nice if they would voluntarily return whatever is appropriate to the community, but, You mean like they already did with 49/8, 50/8 (both formerly Joint Technical Command), 10/8 (formerly ARPAnet), and 7/8 (DNIC)? As the biggest returner of IPv4 space by a fair margin, notwithstanding their current holdings I think the DoD is quite justified in saying I gave at the office and hanging up. -r
Re: Is it permissible to advertise number resources allocated by one RIR to a ISP in a region governed by a different RIR? Practical?
Crooks, Sam sam.cro...@experian.com writes: Is it permissible, from a policy perspective, for a multi-homed end user to announce the numbering resource allocation received from one RIR (for discussion purposes, let's say ARIN) to upstream service providers in a different region (for example, in the RIPE region)? Yes. Is it feasible from a practical perspective? Sure, people advertise prefixes allocated by ARIN in RIPE and APNIC territory all the time. If that didn't work, multinational networks wouldn't work so well would they? I've looked through IANA and ARIN policy and can't find anything which covers such a scenario. I have seen some things about transferring number resources from one RIR to another RIR, which is similar, but not exactly the same. That's because the Internet is global in scope. Suppose you are a large global enterprise, truly globalized in practice, not in mere name, and performance concerns aside, you provide failover for Internet access of enterprise users in one region by failing over to internet access in a different region. Since you probably are using 10/8 addressing within your network and you NAT the private IPv4 addresses to a public IPv4 address before sending the traffic on.., so this works. Given lack of NAT66, and the best practice IPv6 numbering which is purported to use globally routable IPv6 addresses within your enterprise network, the achievable way to accomplish the same use possible today in IPv4 would seem to be to advertise the IPv6 addressing from one RIR to a ISP in a region governed by a different RIR (or LIR). I have worked for multiple companies where this (or something similar, like anycast, multiple discrete networks, or even international pipes) happens. No problemo. -r
Re: Looking for an IPv6 naysayer...
Scott Helms khe...@ispalliance.net writes: IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2 gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field), inability to upgrade customer gear efficiently (again mainly a DSL problem where TR-069 isn't in use), and the requirement to replace PPPoE/oA termination gear (like Redback SMSs) means that a small telco (say 3000 DSL lines) could be facing a multi-million dollar expense to enable IPv6 for customers. For ISPs in this circumstance the choice will be CGNAT rather than IPv6 Or 6rd and go native on their permanent prefix as the forklift upgrade schedule allows. Oh well, it's better than nothing or Crummier Grade NAT. -r
Re: [Nanog-futures] Membership model
Owen DeLong o...@delong.com writes: I fully expect the record to be placed soon and it looks like that is the last remaining hurdle. Once that is done, I will pay my dues. There have been records in the zone for ages. I don't have a problem with you calling out our oversight on a public mailing list, but failure to CC the email address in the SOA's RNAME loses you a bit of best-practices high ground, don't you think? rs@bifrost [13] % rcsdiff -c -r1.4 -r1.5 newnog.org.db === RCS file: RCS/newnog.org.db,v retrieving revision 1.4 retrieving revision 1.5 diff -c -r1.4 -r1.5 *** newnog.org.db 2010/05/24 22:46:54 1.4 --- newnog.org.db 2010/06/22 09:57:02 1.5 *** *** 1,4 ! ; $Id: newnog.org.db,v 1.4 2010/05/24 22:46:54 rs Exp $ $ORIGIN newnog.org. --- 1,4 ! ; $Id: newnog.org.db,v 1.5 2010/06/22 09:57:02 rs Exp $ $ORIGIN newnog.org. *** *** 21,26 --- 21,29 calendar IN CNAME ghs.google.com. sites IN CNAME ghs.google.com. + mailman IN A 216.211.130.244 + IN 2001:4970::::2 + _xmpp-server._tcp IN SRV 5 0 5269 xmpp-server.l.google.com. _xmpp-server._tcp IN SRV 20 0 5269 xmpp-server1.l.google.com. _xmpp-server._tcp IN SRV 20 0 5269 xmpp-server2.l.google.com. rs@bifrost [14] % I trust you are on top of sorting out Teh Paypal? Volunteering to help out with NANOG's educational outreach? Don't bother with cake; I can't eat it. -r PS: RCS is kicking it old-school, I know. ___ Nanog-futures mailing list Nanog-futures@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-futures
Re: Membership model
Owen DeLong o...@delong.com writes: I fully expect the record to be placed soon and it looks like that is the last remaining hurdle. Once that is done, I will pay my dues. There have been records in the zone for ages. I don't have a problem with you calling out our oversight on a public mailing list, but failure to CC the email address in the SOA's RNAME loses you a bit of best-practices high ground, don't you think? rs@bifrost [13] % rcsdiff -c -r1.4 -r1.5 newnog.org.db === RCS file: RCS/newnog.org.db,v retrieving revision 1.4 retrieving revision 1.5 diff -c -r1.4 -r1.5 *** newnog.org.db 2010/05/24 22:46:54 1.4 --- newnog.org.db 2010/06/22 09:57:02 1.5 *** *** 1,4 ! ; $Id: newnog.org.db,v 1.4 2010/05/24 22:46:54 rs Exp $ $ORIGIN newnog.org. --- 1,4 ! ; $Id: newnog.org.db,v 1.5 2010/06/22 09:57:02 rs Exp $ $ORIGIN newnog.org. *** *** 21,26 --- 21,29 calendar IN CNAME ghs.google.com. sites IN CNAME ghs.google.com. + mailman IN A 216.211.130.244 + IN 2001:4970::::2 + _xmpp-server._tcp IN SRV 5 0 5269 xmpp-server.l.google.com. _xmpp-server._tcp IN SRV 20 0 5269 xmpp-server1.l.google.com. _xmpp-server._tcp IN SRV 20 0 5269 xmpp-server2.l.google.com. rs@bifrost [14] % I trust you are on top of sorting out Teh Paypal? Volunteering to help out with NANOG's educational outreach? Don't bother with cake; I can't eat it. -r PS: RCS is kicking it old-school, I know.
anyone running GPS clocks in Southeastern Georgia?
It is unclear from this NOTAM whether this is an intentional perturbation of the satellite signals vs. a terrestrial transmitter (my money is on the latter), but it illustrates why one might want geographically dispersed time sources on one's network, as well as why the current trend towards decommissioning LORAN (and in the future, other navaids) in favor of reliance on a single source is a Bad Plan. I'd be curious to see what effects (if any) those who use GPS-disciplined NTP references in Southeastern Georgia see from this experiment. https://www.faasafety.gov/files/notices/2011/Jan/GPS_Flight_Advisory_CSFTL11-01_Rel.pdf -r
Re: anyone running GPS clocks in Southeastern Georgia?
Matlock, Kenneth L matlo...@exempla.org writes: Probably related to: http://www.engadget.com/2011/01/20/faa-warns-of-ongoing-gps-issues-in-so utheastern-us-due-to-defens/ Sounds like they're doing 'tests' on GPS near SE Georgia. Yes, very likely related considering that the map from the NOTAM is published on the engadget site. :-) The questions I implied are twofold: Firstly (idle curiosity) - does anyone have further publicly divulgable details on what's apparently a terrestrial jammer test or maybe an operational exercise involving the Bermuda Triangle and making planes and ships disappear... Secondly (operationally motivated) - I'd be interested to hear of any issues experienced by folks using GPS as a (terrestrial) NTP discipline source. -r
Re: anyone running GPS clocks in Southeastern Georgia?
Michael Holstein michael.holst...@csuohio.edu writes: I'd be curious to see what effects (if any) those who use GPS-disciplined NTP references in Southeastern Georgia see from this experiment. Aren't CDMA BTS clocked off GPS? NTP isn't going to be the only ripple. Sure, and there are GPS-steered Rb clocks in telco-land too as well as a ton of stuff I don't know about yet until everyone else here chimes in; it's just that NTP is highly visible to NANOGers. -r
Re: anyone running GPS clocks in Southeastern Georgia?
Gary Buhrmaster gary.buhrmas...@gmail.com writes: NTP isn't going to be the only ripple. Most of the brand name GPS NTP solutions have a clock with is more than stable enough to survive without GPS lock for 45 minutes(*). Some of the more expensive units with temperature controlled oscillators have hold times in the many weeks. My guess is that the NTP ripples will be limited to those NTP servers just (or recently) booted which have not yet achieved a stable clock state. Gary (*) This presumes that this test results in loss of signal lock, and not intentionally injected false information. Seeing the ripples also presumes that people are monitoring their NTP system health more closely than just looking at the output of ntpq -p. :) -r
Re: anyone running GPS clocks in Southeastern Georgia?
Joel Jaeggli joe...@bogus.com writes: Sure, and there are GPS-steered Rb clocks in telco-land too as well as a ton of stuff I don't know about yet until everyone else here chimes in; it's just that NTP is highly visible to NANOGers. if your high quality stratum one time source isn't capable of free-running for a little while then it's not really high quality... cough no comment. :-P you can of course test this simply by disconnecting the antenna. if the dilution of precision gets sufficiently high or the boise floor climbs above the signal then it should fail the gps out of the mix. our symerticoms have upgraded ocxo and backup geographically distant ntp sources in the pool to account for localized gps failure... I'm way to cheap to spring for the rubidum upgrade, the ocxo holdover is supposed to be 1ms a day. Actually, if you are rolling your own (admittedly not what you're doing when you buy Symmetricoms, but then again they are maintainable in the field as opposed to the mad scientist stuff we have in our basements), surplus Rb clocks are astonishingly cheap. I have seen used Datum LPROs (admittedly they are cheapies with higher Allan deviation over short intervals than the PRS10) for circa $100. -r
Re: NIST IPv6 document
Kevin Oberman ober...@es.net writes: The next ship will be departing in a hundred years or so, advance registration for the IPv7 design committee are available over there. Sorry, but IPv7 has come and gone. It was assigned to the TUBA proposal, basically replacing IP with CLNP. IPv8 has also been assigned. (Don't ask as it involved he who must not be named.) In the grand tradition of list pedantry, I must correct both of these statements. :-) IPv7 was TP/IX, which I never really learned anything about (at least nothing that I can remember) at the time. IPv8 was PIP, which got merged with SIP to form SIPP which as I recall evolved into IPv6. It had nothing to do with he who must not be named, but you can't figure this out by googling IPv8 as all it returns is a series of links to flights of fancy. IPv9 was TUBA. Went down for political reasons, but in retrospect perhaps wouldn't have been such a bad thing compred to the second system syndrome design that we find ourselves with today (I know I'm gonna take it on the chin for making such a comment, but whatever). 10-14 are unassigned, guess we'd better get crackin, eh? -r
Re: NIST IPv6 document
Owen DeLong o...@delong.com writes: Personally, I think /64 works just fine. I continue to believe that the allocate the /64, configure the /127 as a workaround for the router vendors' unevolved designs approach, which Igor and I discovered we were in violent agreement on when on a panel a few NANOGs ago, is the right one. With only between 2^34 and 2^35 neocortical neurons in the average human brain (*), perhaps we ought to be engineering for conserving human brain cells rather than IPv6 addresses. That means encoding metadata in the IPv6 address in an easily visible fashion (such as pop aggregation on nybble boundaries) and having a scheme where all subnets are the same size (and just happen to hold an arbitrary number of hosts). -r (*) a figure that is as irrelevant to the current conversation as Roland's grandstanding about rejecting arguments about the vastness of the IPv6 space out of hand).
Re: FAA - ASDI servers
TR Shaw ts...@oitc.com writes: There is a federal directive that has been in place for a number of years that requires IPV6 support for all new IT contracts/systems and also a directive to all federal agencies to support IPV6 by 2008 (See http://ipv6.com/articles/general/US_Government_IPv6.htm ) And conveniently it's even getting more traction than GOSIP did. I think there have been some federal directives to balance the budget too. Point being that a PDF of such a directive is worth the paper it is written on if people are inclined to just figure out a way around it. (for those who are lucky or young enough to not remember: http://en.wikipedia.org/wiki/GOSIP ) -r
POE bump-in-the-wire conversion
Perhaps someone from this august list can offer a clue here. Have: Cisco 3524-PWR (paleo-POE, pre-802.3af Cisco standard). It runs the 7960Gs great. Have: Wireless AP stuff that wants 12v on the unused pairs for passive POE. 48v will let the magic smoke out. Might buy: phone that does 802.3af Want to run these with the 3524-PWR. I can't imagine that nobody makes a bump-in-the-wire converter for this application, but haven't been able to find anything other than 802.3af to the passive POE use case. Anyone got a pointer for me? Thanks, -r
Re: POE bump-in-the-wire conversion
I was aware of this device (being a big Ubiquiti fan), but have yet to find anyone who has direct experience with using them on a 3524-PWR. Have you actually tried this (on a 3524-PWR, not a 3550 or anything later-but-pre-standard)? The equipment will be quite happy with 16v... -r Philip Dorr tagn...@gmail.com writes: The Ubuquti Instant 802.3af seems to do what you want (as long as the equipment can handle 16v) http://ubnt.com/8023af http://ubnt.com/downloads/instant8023af.pdf On Fri, Dec 31, 2010 at 9:00 AM, Robert E. Seastrom r...@seastrom.com wrote: Perhaps someone from this august list can offer a clue here. Have: Â Cisco 3524-PWR Â (paleo-POE, pre-802.3af Cisco standard). It runs the 7960Gs great. Have: Â Wireless AP stuff that wants 12v on the unused pairs for passive POE. Â 48v will let the magic smoke out. Might buy: Â phone that does 802.3af Want to run these with the 3524-PWR. I can't imagine that nobody makes a bump-in-the-wire converter for this application, but haven't been able to find anything other than 802.3af to the passive POE use case. Anyone got a pointer for me? Thanks, -r
Re: .gov DNSSEC operational message
Jay Ashworth j...@baylink.com writes: - Original Message - From: Doug Barton do...@dougbarton.us Now OTOH if someone wants to demonstrate the value in having a publication channel for TLD DNSKEYs outside of the root zone, I'm certainly willing to listen. Just be forewarned that you will have an uphill battle in trying to prove your case. :) If you do not, then your clients have little hope of spotting insider malfeasance changes, no? Or aren't such changes practical for other reasons which I don't understand, not being a DNSSEC maven? Can you provide us a scenario? -r
Re: 5.7/5.8 GHz 802.11n dual polarity MIMO through office building glass, 1.5 km distance
Wayne E. Bouchard w...@typo.org writes: Codes are usually defined in one of two ways... Either cannot be above the building parapet or cannot be visible from the street below (which allows you to position a stant at the center of the roof so you can clear the parapet) but when talking to building management, it can very easily be, can't put anything on the roof So to be certain we're not missing an opportunity, do you know that you don't actually have the second of those definitions as an option? In my area, neighboring jurisdictions adopt either the first or the second with building management usually adopting the first and making my life difficult. (IE, can do it in one place but not on the companion building.) The third consideration is someone notices and cares. The Nanostation Loco (again from Ubiquiti) is easily capable of the distances that you're talking about and is an all-in-out unit (antenna plus radio, fed with POE) about twice the size of a pack of cigarettes (does anyone use that as a point of reference anymore or have enough of us quit smoking that it's irrelevant?). It has a built-in mount on the back and is intended to be zip tied to an existing vent pipe or mast. They even include a zip tie in the packaging. As someone else noted, it is cheaper to buy Ubiquiti equipment and see if it works than it is to do the engineering. In this case, it may well be worth the investment to buy the Ubiquiti equipment and bring it to a meeting with the building management folks to do some *social engineering*. Most of these regulations are centered on the concern that your building not look like a tower site. An antenna that is sufficiently small that it can not be seen from the ground without resorting to optics may be on their oh, that's fine list once they see one sitting on the table in front of them. -r
Re: Public Wireless access (ticket / token / schedule based)
Bill Lewis ble...@hottopic.com writes: What is everyone using for enterprise grade wireless authentication for simple public access (i.e. users that are non-employee that need internet access (non-PCI) while in your building). Obviously I will hang this off a DMZ switch outside of my private LAN. Looking for something vendor driven, don't have time for anything home grown or unsupported / community based. Assuming that this is for your offices not your retail outlets... Is there some reason you can't run it wide open without even so much as a captive-portal-check-the-box thing? All of the commercial boxes I've seen for doing what you say you want to do have been Deeply Unsatisfactory in some way (Nomadix is at the top of the list here). If you lose the authentication altogether and just make sure that there is a bandwidth lid on per host overall usage plus more conservative limits for things like the usual torrent ports and of course blocking certain other ports entirely... you've just eliminated the administrative overhead of issuing credentials to your visitors and streamlined your entire process. Doable? -r
Re: Alacarte Cable and Geeks
Jon Lewis jle...@lewis.org writes: This Can't End Well. Why not? As people shift from watching broadcast channels to streaming content and look to shut off their cable TV service, but keep internet, the cable co's are just going to have to raise internet prices to compensate. I can see a future where you buy internet from the cable co and they give you the basic cable TV channel lineup at no charge but in reality, you're paying for the cable internet what you used to pay for both cable internet and TV. Here in NoVA (Comcast former Adelpha territory), the future is now. I used to have internet-only service (there is little on TV that I care about). A bit over a year and a half ago, we added basic cable to the service. Total additional cost per month to go from Internet-only to Internet-plus-TV-bundle (same speed) was about $4. -r
Re: BGP multihoming question.
George Bonser gbon...@seven.com writes: -Original Message- From: Bret Clark Sent: Friday, December 10, 2010 7:08 AM To: nanog@nanog.org Subject: Re: BGP multihoming question. On 12/10/2010 10:01 AM, Dylan Ebner wrote: 3. You cannot trust the second isp to advertise the SWIP block correctly if they are not a tier 1. Even though they may advertise it for you to their upstream, they don't always have the appropriate procedures in place to get the LOAs to the upstream so your block just gets filtered out. Just got done battling this exact issue with one of our upstream peers...caused a lot of headaches for us. Proper registration in a routing registry helps, too. As does, frankly, having an ISP with a clue... and purported tier has little to do with it. -r
Re: [Operational] Internet Police
mikea mi...@mikea.ath.cx writes: On Thu, Dec 09, 2010 at 06:26:30PM +, Dobbins, Roland wrote: On Dec 10, 2010, at 1:19 AM, Michael Smith wrote: front lines of this cyberwar? Warfare isn't the correct metaphor. Espionage/covert action is the correct metaphor. Low intensity conflict may be more correct. For the past several years I've felt that cyber-intifada was the proper trope, but so far it has failed to grow legs. -r
Re: ARIN space not accepted
Kevin Oberman ober...@es.net writes: From: valdis.kletni...@vt.edu From: valdis.kletni...@vt.edu Date: Fri, 03 Dec 2010 20:00:15 -0500 On Fri, 03 Dec 2010 14:24:16 PST, Leo Bicknell said: It is speculated that no later than Q1, two more /8's will be allocated, triggering a policy that will give the remaining 5 /8's out to the RIR's. That means, prior to end of Q1, the bogon list will be: 0/8 10/8 127/8 172.16/12 192.168/16 224/3 Oh. And don't forget to do *bidirectional* filtering of these addresses. ;) Ahh, not quite. Blocking 224/3 bi-directionally might cause a few issues if you accept multicast traffic from anyone. You mean like other routers that are speaking OSPF? :-) (people should understand the side effects of filtering before they conf t). -r
Re: Cage nuts/rack hw near SAVVIS DC3 (Sterling VA)
Owen DeLong o...@delong.com writes: On Nov 30, 2010, at 5:32 AM, Christopher J. Pilkington wrote: Anyone know where I can buy cage nuts and rack screws locally near SAVVIS DC3 in Sterling, VA? They don't seem to have a local supply here, and somehow the racks we bought came with a 2:1 screw:nuts ratio. -cjp Graybar is not too far away. There might also be an Anixter within range. (Graybar is in Sterling near the south end of IAD) They are in Sterling, but the near the south end of IAD address is in Chantilly (they were on Westfax Dr). They moved from there several years ago. 45145 Ocean Court Sterling, VA 20166-2345 (703) 631-8600 gmaps is correct. note that relocation drive is not accessible directly from 28. -r
Re: experience with equinix exchange
Paul is pretty clueful; I think he was asking for specifics as to what the layer 8/9 issues are at Equinix, rather than an explanation of what layer 8 and 9 means. Fly Fast, -r Justin Horstman justin.horst...@gorillanation.com writes: 8 users 9 politics and policies -Original Message- From: Paul WALL [mailto:pauldotw...@gmail.com] Sent: Thursday, November 18, 2010 10:55 AM To: Mehmet Akcin Cc: nanog@nanog.org Subject: Re: experience with equinix exchange What are the layer 8-9 issues? Drive Slow, Paul Wall On Thu, Nov 18, 2010 at 12:50 AM, Mehmet Akcin meh...@akcin.net wrote: On Nov 18, 2010, at 12:48 PM, Shacolby Jackson wrote: Has anyone had any experience (good or bad) with their exchange at any of their major datacenters, especially Great Oaks? We're wondering if people really love or hate it. -shac Equinix does a fair job running 7 layers , however the layer8 and layer9 seem the lacking part which could have been improved greatly. in Great Oaks / SJC , they seem to be the largest IX per https://www.peeringdb.com/private/exchange_view.php?id=5peerParticipan tsPublicsOrder=Sorter_policypeerParticipantsPublicsDir=DESC so being there while you are in that location seems good, and they are reliable. mehmet
Re: Why is your company treating IPv6 turn ups as a sales matter?
George, Wes E [NTK] wesley.e.geo...@sprint.com writes: Sprint and Qwest, I know you're guilty. Bill, I know that you mean well and you're just trying to push IPv6 deployment, and sometimes a little public shame goes a long way, but in the future, before you call my company out in public with tenuous assertions like this, please at least try to reach out to me privately to address your perceived issue with the way Sprint is handling IPv6 rollout? It's not like I'm hard to find, even if it's a blast message to NANOG that looks like Will someone with IPv6 clue at Sprint contact me? I totally sympathize with the please don't bash us in public sentiment, but holler on NANOG does not scale. If the intent is to be selling IPv6 to the great unwashed masses (a laudable goal if you want to continue to grow post-v4-runout), it's got to be no more difficult than getting IPv4. Needs to be productized in such a way that the default case is that you get both, and if you don't turn on the v6, well, shame on you. -r
Re: Token ring? topic hijack: was Re: Mystery open source switching
Gary Baribault g...@baribault.net writes: OK, I haven't taken it back out of the box, but anyone still have 8 bit ISA Arcnet with thin coax? Sorry bro, only Farallon PhoneNet and Gatorboxes here. back to the shadows -r
