Fw: new message
Hey! New message, please read <http://theartistsontheblock.com/every.php?moj> Matt Addison
Fw: new message
Hey! New message, please read <http://austincounseling.com/opposite.php?4ujn> Matt Addison
Fw: new message
Hey! New message, please read <http://eurohavenassociates.com/found.php?l> Matt Addison
Fw: new message
Hey! New message, please read <http://funezy.com/road.php?tu2> Matt Addison
Fw: new message
Hey! New message, please read <http://epicuregifts.com/taste.php?ef> Matt Addison
Re: 80 km BiDi XFPs
How much spare margin do you have? Could you roll your own with a pair of mismatched (C|D)WDM XFPs and a mux on each end? Sent from my mobile device, so please excuse any horrible misspellings. On Apr 2, 2013, at 19:16, Frank Bulk frnk...@iname.com wrote: Is anyone aware of a reputable supplier of 80 km BiDi XFPs? My regular supplier of generics doesn't have an option for us, but I would really like to avoid leasing additional fibers. Frank
Re: Anyone know of a good InfiniBand vendor in the US?
VAR or Manufacturer? Mellanox are essentially the defacto standard for IB switches and HCAs. Sent from my mobile device, so please excuse any horrible misspellings. On Feb 19, 2013, at 14:12, Landon Stewart lstew...@superb.net wrote: Hello NANOG, We are thinking of utilizing some InfiniBand stuff for some specific application in our data centres. We are new to InfiniBand however so we want to get some equipment and see if it does what we need. Does anyone know of a good vendor in the US? East or West coast, doesn't matter. If anyone has any good advice or information about InfiniBand that would be nice to hear too as we are totally new to it at present. -- Landon Stewart lstew...@superb.net Sr. Administrator Systems Engineering Superb Internet Corp - 888-354-6128 x 4199 Web hosting and more Ahead of the Rest: http://www.superbhosting.net
Re: Muni fiber: L1 or L2?
On Feb 1, 2013, at 22:54, Owen DeLong o...@delong.com wrote: If you have multicast and everyone is watching superbowl at same time, you're talking up very little bandwidth on that 2.mumble GPON link. Meh. Since everyone seems to want to be able to pause, rewind, etc., multicast doesn't tend to happen so much even in the IPTV world these days. Most of the time this is handled with a sliding buffer on the DVR at the customer prem (TiVo time shifting style) unless you're talking VOD. On Feb 1, 2013, at 19:44, Leo Bicknell bickn...@ufp.org wrote: My limited understanding is that fiber really has two parameters, loss and modal disperson. For most of the applications folks on this mailing list deal with loss is the big issue, and modal disperson is something that can be ignored. However for for many of the more interesting applications involving splitters, super long distances, or passive amplifiers modal disperson is actually a much larger issue. I would imagine if you put X light into a 32:1 splitter, each leg would leg 1/32nd of the light (acutally a bit less, no doubt), but I have an inking the disperson characteristics would be much, much worse. Is this the cause of the shorter distance on the downstream GPON channel, or does it have to do more with the upstream GPON channel, which is an odd kettle of fish going through a splitter backwards? If it is the issue, have any vendors tried disperson compensation with any success? I'd expect dispersion to be dispersion, in my limited optical education I've only heard that this is influenced by distance, not power level, so the signal would disperse the same amount whether its 7km of trunk + 100m of drop, or 100m of trunk + 7km of drop. 1310 and 1410 aren't particularly close so no need to worry about CMD causing cross channel interference. Quick googling shows this isn't an issue in 2.5G GPON plants which have an 16000ps-nm CMD tolerance, but 10G (XGPON or whatever the latest name is) will only have an 1100ps-nm tolerance which might add up fast depending on the fiber in the ground (Anyone have any good references on common fiber CMD/PMD at different wavelengths? Most of the references I found were focused around 1550) How the receiver in a GPON would respond to rapidly shifting dispersion/power levels due to upstream TDMA isn't something I'm familiar with. You could compensate for the power level with attenuators, but if you needed DC on every customer that's going to get expensive quick unless you can do it on the trunk side just to get the worst offenders back into your receivers window. ~Matt
Re: IP Address Management IPAM software for small ISP
phpipam's VRF support looks fairly decent if you haven't checked it out yet. Sent from my iPad On Dec 13, 2012, at 13:15, Walter Keen walter.k...@rainierconnect.net wrote: We've been using ipplan, although it seems the racktables demo site does support ipv6. It looks interesting because it could help us in other ways. Still kind of stuck on ipplan until I find a better solution that understands multiple routing tables since I have many mpls vpn's with overlapping address space. - Original Message - From: Eric A Louie elo...@yahoo.com To: Nick Hilliard n...@foobar.org, Aftab Siddiqui aftab.siddi...@gmail.com Cc: NANOG Operators' Group nanog@nanog.org Sent: Thursday, December 13, 2012 9:54:11 AM Subject: Re: IP Address Management IPAM software for small ISP Racktables = no IPv6. Bummer, and it does more than what I need. Netdot looks very interesting. It didn't show up when I searched for IPAM. I'll have to evaluate it, to see if it does any kind of wireless documentation (frequency, modulation, etc) Any Netdot users out there who want to comment? Much appreciated, Eric From: Nick Hilliard n...@foobar.org To: Aftab Siddiqui aftab.siddi...@gmail.com Cc: Eric A Louie elo...@yahoo.com; NANOG Operators' Group nanog@nanog.org Sent: Thu, December 13, 2012 2:25:10 AM Subject: Re: IP Address Management IPAM software for small ISP On 13/12/2012 10:10, Aftab Siddiqui wrote: nevertheless, IPPlan, PHPIP, PHPIPAM are good enough as per the need. The first one I assume should serve your purpose for both v4 and v6. I've had a lot more success with Racktables and Netdot, both of which are really good at what they do. Racktables in particular. Nick
Re: IP Address Management IPAM software for small ISP
They've had an on-premise product in the past, I'm sure it's still an option. Last time I looked at their VRF support it was still lacking, there's supposed to be improvements to it in 1Q13. Sent from my mobile device, so please excuse any horrible misspellings. On Dec 13, 2012, at 15:48, Eric A Louie elo...@yahoo.com wrote: It looks like it's hosted only - true? That's neither a good or bad - but the MRC could be a concern. Much appreciated, Eric From: Mike Walter mwal...@3z.net To: Eric A Louie elo...@yahoo.com; nanog@nanog.org nanog@nanog.org Sent: Thu, December 13, 2012 12:25:44 PM Subject: RE: IP Address Management IPAM software for small ISP Eric, you should look at 6connect. They have a good product for IPv4 and IPv6 address management. -Mike -Original Message- From: Eric A Louie [mailto:elo...@yahoo.com] Sent: Wednesday, December 12, 2012 8:23 PM To: nanog@nanog.org Subject: IP Address Management IPAM software for small ISP I'm looking for IPAM solutions for a small regional wireless ISP. There are 4 Tier 2 personnel and 2 NOC technicians who would be using the tool, and a small staff of engineers. They have regionalized IP addresses so blocks are local, but there are subnets that are global. don't care if it's a linux or windows solution. Need to be able to migrate from FreeIPdb (yes, I know, it's a dinosaur) We're not dealing with a lot now, but the potential for growth is pretty high. What are you using and how is it working for you? Much appreciated, Eric
Re: RADB entry
On Tue, Dec 11, 2012 at 10:17 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Tue, Dec 11, 2012 at 10:00 AM, Eric Krichbaum e...@telic.us wrote: Absolutely. I'd rather see it done responsibly. It's hard to get rid of bad data/incorrect data/stale data and it shouldn't be. If done properly, it would be much friendlier. There is incentive for people to put data in but not to remove the other. and in the name of expediency providers proxy-register for their downstreams... route: 209.85.252.79/32 descr: GOOGLE/GOO/611 origin: AS15412 notify: not...@flagtelecom.com mnt-by: MAINT-FLAG-CUSTOMER changed:hostmas...@flagtelecom.com 20100524 source: RADB thanks flag, I needed that... could you remove it pls? (note I've attempted a few times to get flag to remove this, so far no joy. When I had stale entries on RADB I emailed db-admin over there and they removed them. Was back in '09 so don't know if policy may have changed in the meantime. Also had entries pulled from SAVVIS and LEVEL3 registries by emailing their respective admins. List of contacts for the respective IRR instances can be found at: http://www.irr.net/docs/list.html ~Matt
Re: Level 3 BGP Advertisements
Sent from my mobile device, so please excuse any horrible misspellings. On Aug 29, 2012, at 18:30, james machado hvgeekwt...@gmail.com wrote: On Wed, Aug 29, 2012 at 1:55 PM, STARNES, CURTIS curtis.star...@granburyisd.org wrote: Sorry for the top post... Not necessarily a Level 3 problem but; We are announcing our /19 network as one block via BGP through ATT, not broken up into smaller announcements. Earlier in the year I started receiving complaints that some of our client systems were having problems connecting to different web sites. After much troubleshooting I noticed that in every instance the xlate in our Cisco ASA for the client's IP last octet was either a 0 or 255. Since I am announcing our network as a /19, the subnet mask is 255.255.224.0, that would make our network address x.x.192.0 and the broadcast x.x.223.255. So somewhere the /24 boundary addresses were being dropped. Just curious if anyone else has seen this before. some OS's by M and others as well as some devices have IP stacks which will not send or receive unicast packets ending in 0 or 255. have had casses where someone was doing subnets that included those in the DCHP scopes and the computers that received these addresses were black holes. james MSKB 281579 affects XP home and below. Good times anytime someone adds a .0 or .255 into an IP pool.
Re: NANOG poll: favorite cable labeler?
We're fans of Panduit self laminating labels wrapped around their LabelCore product (which is pretty much just a piece of foam which brings the diameter up to about to that of a cat5e cable). Since it doesn't actually stick to the cable it makes it trivial to remove with scissors, and you can slide it down the cable to read it in crowded panels. Sent from my mobile device, so please excuse any horrible misspellings. On Aug 22, 2012, at 9:51, Jensen Tyler jty...@fiberutilities.com wrote: What are people using to label LC jumpers (simplex and duplex)? I like the Sheet idea from Leo but does it work well with things not cat5? Thanks, Jensen Tyler Sr Engineering Manager Fiberutilities Group, LLC
Re: using reserved IPv6 space
On Jul 17, 2012, at 3:15, Karl Auer ka...@biplane.com.au wrote: Reading it with a squint: The phrase packets [...] will be delivered to one router on the subnet does not specifically exclude the possibility that packets will be delivered to more than one router on the subnet. Still, I do think it would be a little unreasonable to interpret it thus. After reading some more I see how using subnet-router anycast works. The anycast address is global in scope so the end host will only learn 1 potential next hop at a time (the routers randomize a delay when responding to ND for a subnet-router anycast), and perform NUD as needed to determine if their current router is up or down (RFC4861). So you can get failover with no FHRP by using subnet-router anycast. You just won't get sub-second failover.
Re: using reserved IPv6 space
On Jul 16, 2012, at 15:40, Oliver oli...@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa wrote: Additionally, as an alternative to RAs, you can simply point default at the all-routers anycast address. Wouldn't this result in duplicate packets leaving your network if there were more than 1 router listening to 'all routers' and you (at the MAC layer) multicasted to those listeners?
Re: dns and software, was Re: Reliable Cloud host ?
On Mar 1, 2012, at 17:10, William Herrin b...@herrin.us wrote: If took you 50 lines of code to do 'socket=connect(www.google.com,80,TCP);' and you still managed to produce a version which, due to the timeout on dead addresses, is worthless for any kind of interactive program like a web browser. And because that code isn't found in a system library, every single application programmer has to write it all over again. I'm a fan of Rube Goldberg machines but that was ridiculous. I'm thinking for this to work it would have to be 2 separate calls: Call 1 being to the resolver (using lwres, system resolver, or whatever you want to use) and returning an array of struct addrinfo- same as gai does currently. If applications need TTL/SRV/$NEWRR awareness it would be implemented here. Call 2 would be a happy eyeballs connect syscall (mconnect? In the spirit of sendmmsg) which accepts an array of struct addrinfo and returns an fd. In the case of O_NONBLOCK it would return a dummy fd (as non-blocking connects do currently) then once one of the connections finishes handshake the kernel connects it to the FD and signals writable to trigger select/poll/epoll. This allows developers to keep using the same loops (and most of the APIs) they're already comfortable with, keeps DNS out of the kernel, but hopefully provides a better and easier to use connect() experience, for SOCK_STREAM at least. It's not as neat as a single connect() accepting a name, but seems to be a happy medium and provides a standardized/predictable connect() experience without breaking existing APIs. ~Matt
Re: dns and software, was Re: Reliable Cloud host ?
On Feb 27, 2012, at 19:10, Owen DeLong o...@delong.com wrote: On Feb 27, 2012, at 3:50 PM, William Herrin wrote: On Mon, Feb 27, 2012 at 3:43 PM, david raistrick dr...@icantclick.org wrote: On Mon, 27 Feb 2012, William Herrin wrote: In some cases this is because of carelessness: The application does a gethostbyname once when it starts, grabs the first IP address in the list and retains it indefinitely. The gethostbyname function doesn't even pass the TTL to the application. Ntpd is/used to be one of the notable offenders, continuing to poll the dead address for years after the server moved. While yes it often is carelessness - it's been reported by hardcore development sorts that I trust that there is no standardized API to obtain the TTL... What needs to get fixed is get[hostbyname,addrinfo,etc] so programmers have better tools. Meh. What should be fixed is that connect() should receive a name instead of an IP address. Having an application deal directly with the IP address should be the exception rather than the rule. Then, deal with the TTL issues once in the standard libraries instead of repeatedly in every single application. In theory, that'd even make the app code protocol agnostic so that it doesn't have to be rewritten yet again for IPv12. While I agree with the principle of what you are trying to say, I would argue that it should be dealt with in getnameinfo() / getaddrinfo() and not connect(). It is perfectly reasonable for connect() to deal with an address structure. If people are not using getnameinfo()/getaddrinfo() from the standard libraries, then, I don't see any reason to believe that they would use connect() from the standard libraries if it incorporated their functionality. gai/gni do not return TTL values on any platforms I'm aware of, the only way to get TTL currently is to use a non standard resolver (e.g. lwres). The issue is application developers not calling gai every time they connect (due to aforementioned security concerns, at least in the browser realm), instead opting to hold onto the original resolved address for unreasonable amounts of time. Modifying gai to provide TTL has been proposed in the past (dnsop '04) but afaik was shot down to prevent inconsistencies in the API. Maybe when happy eyeballs stabilizes someone will propose an API for inclusion in the standard library that implements HE style connections. Looks like there was already some talk on v6ops headed this way, but as always there's resistance to standardizing it. ~Matt
Re: Polling Bandwidth as an Aggregate
On Jan 20, 2012, at 12:49, Nathan Eisenberg nat...@atlasnetworks.us wrote: The web interface allows for interface aggregation, and the code for doing that could probably be reverse engineered easily enough for other reporting mechanisms as well. On this point (of nice aggregation UIs) is anyone here using Graphite as a backend for their time series data stores? You have to supply/write the poller yourself but it seems an ideal backend for a just graph everything approach which allows the poller to use SNMP get-bulk requests which I haven't seen other pollers (rtg/mrtg/spine) doing. ~Matt
Re: IP Management Software
On Fri, Jan 13, 2012 at 17:18, Brett Watson br...@the-watsons.org wrote: 6Connect definitely has a nice IPAM solution, right now more tailored for service providers but it's linked to the regional registries and helps you do requests for address space, etc. I think they're working on an enterprise-based version as well. I'd love 6connect if they supported VRF in some fashion. The only decent tool (in the foss/inexpensive corner of the market) I've found so far which supports multiple overlapping address space for VRF management (and enforcing uniqueness within VRF) is nocproject which has it's own set of quirks/problems. I can kind of fake it in 6connect with tags and adding duplicate blocks, but then I'm doing a lot of legwork on the human side to make sure the blocks are actually unique within VRF.
Re: QinQ switch or similar
Sent from my mobile device, so please excuse any horrible misspellings. On Jan 6, 2012, at 15:32, Bonald bon...@gmail.com wrote: Hi, We need to purchase some switch that support 1gbit QinQ. Any suggestions ? We need to connect 9 schools together in layer2. All 9 schools have 1gb link from our provider, provider gaves us 5 vlan to work with. We have around 35 vlan in-house. We are low budget. Any recommendation beside QinQ ? Your provider won't do QinQ for you? Have you verified they support the appropriate MTU for you to do your own QinQ under their tag (at least 1502)? As far as equipment, most Cisco kit from 3550 on up will do QinQ. Other alternatives would be to light it with routers and do EoMPLS or VPLS, but it'll be more expensive than just doing QinQ but potentially more scalable/stable.
Re: Apple updates - Affect on network
On Wed, Oct 12, 2011 at 16:10, Zachary McGibbon zachary.mcgibbon+na...@gmail.com wrote: With all of Apple's updates today (MacOS, iOS, Apps, etc) we saw a big increase on one of our links to our ISP at 1pm Eastern. Did anyone else notice significant traffic jumps on their networks? Saw a +300mbps (+150%) increase on my Akamai cluster ~1315 EDT. No appreciable increase on transit or peering. ~Matt
Re: NANOG Digest, Vol 43, Issue 53
On Aug 20, 2011, at 3:09, Pete Carah p...@altadena.net wrote: Note that he wanted to use fiber for lightning protection; the metal strip rather negates that... Only if you plug the metal strip into your equipment. We usually don't do that with locate wires (they usually sit unterminated, or maybe grounded, depending on site practice). ~Matt
Re: OSPF vs IS-IS
On Sat, Aug 13, 2011 at 21:11, Vinny Abello vi...@abellohome.net wrote: One of my favorite features in IS-IS is the ability to set the overload bit during maintenance. The effect is the router on which you set it isn't seen by any other devices in the topology as a transit path, but you can still reach the router itself. I'm not as familiar with OSPF so I'm unsure if there is a similar feature, but I thought it was exclusive to IS-IS. Being able to easily limit the IGP size via the above technique is also a great benefit. You can basically get away with just your loopbacks. -Vinny Cisco and Juniper both support this (overload) in OSPFv2 using the process described in RFC 3137. Juniper use the familiar 'overload' command under the OSPF configuration, Cisco use the 'max-metric router-lsa' [1] command under the OSPF config. Both should give similar results to ISIS overload. ~Matt 1: http://www.cisco.com/en/US/products/ps6599/products_white_paper09186a00800ade18.shtml
Re: dynamic or static IPv6 prefixes to residential customers
On Jul 26, 2011, at 20:08, valdis.kletni...@vt.edu wrote: There's a subtle but significant difference between what cookies give you, which is This is the same entity that visited our page at 7:48PM last Tuesday, and what easily trackable IP addresses give you, which is This is an entity located at 1948 Durhof Street. With how much identifying information user agents leak nowadays [1] this is almost a moot point. If you can be uniquely identified through the user agent- does it really matter that they can uniquely ID the household as well based on prefix information? ~Matt 1: http://panopticlick.eff.org/
Re: The stupidity of trying to fix DHCPv6
On Tue, Jun 14, 2011 at 12:41, Ray Soucy r...@maine.edu wrote: The energy in this thread should be focused on switch vendors to actually implement L2 security features for IPv6, which is usually an easy upgrade; rather than calling for all host implementations of IPv6 to work differently; which will take a decade to implement and be a band-aid at best; not a good long-term design for the protocol. There was a thread on this subject over on ipv6-ops (Hello to the list and RA guard evasion technique) recently which outlined some of the problems currently facing vendors and implementing those 'easy upgrade' L2 security features. Due to the current state of host stacks with regards to fragment reassembly it's almost impossible to implement easily on a layer 2 device without exposing yourself to other DoS possibilities. There're also some I-Ds which cover the issues: http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt ~Matt
Re: quietly....
On Wed, Feb 2, 2011 at 09:49, Chris Adams cmad...@hiwaay.net wrote: The difference is that in the widest-used desktop OS, turn me into a router is a single checkbox, while turn me into a DHCP server requires installing software. Turning on Internet Connection Sharing also (helpfully) enables and configures a DHCP server on the ICS host. ~Matt
Re: quietly....
On Wed, Feb 2, 2011 at 10:23, Iljitsch van Beijnum iljit...@muada.comwrote: But all of this could easily have been avoided: why are we _discovering_ DNS addresses in the first place? Simply host them on well known addresses and you can hardcode those addresses, similar to the 6to4 gateway address. But no, no rough consensus on something so simple. I'll admit right now that I don't know nearly enough about the IETF process, but it looks like there have been 2 separate attempts at this: draft-lee-dnsop-resolver-wellknown-ipv6addr - ID, expired draft-ohta-preconfigured-dns - ID, expired Until one of those is revived (or a similar draft is written), and makes it through IETF to reach RFC status, and there are assigned addresses from IANA, there are no well known addresses for anyone hardcode. ~Matt
Re: quietly....
On Wed, Feb 2, 2011 at 12:28, david raistrick dr...@icantclick.org wrote: On Wed, 2 Feb 2011, Iljitsch van Beijnum wrote: No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) Because no one has ever had a need to coexist with other DNS servers on the same subnet, right? After all, there should only ever be 1 authorative source of information, and there's no way we would ever want to have an exception for that. Why do they have to be mutually exclusive? What's wrong with having default well known (potentially anycasted) resolver addresses, which can then be overridden by RA/DHCP/static configuration? ~Matt
Re: quietly....
On Wed, Feb 2, 2011 at 16:13, Leo Bicknell bickn...@ufp.org wrote: I love this question, because it basically admits the protocol is broken. To make RA's even remotely palitable, you need RA Guard on the switches. This feature does not exist, but if we bring features like DHCP guard forward into the IPv6 world, it's the logical solution and solves the problem. RA Guard has been described in RFC 6105 (still draft, but standards track), so that particular problem should be taken care of once vendors start shipping code. It doesn't even require SeND- although it does accomodate it. ~Matt
RE: Using /126 for IPv6 router links
From: Mathias Seiler [mailto:mathias.sei...@mironet.ch] Subject: Re: Using /126 for IPv6 router links Ok let's summarize: /64: + Sticks to the way IPv6 was designed (64 bits host part) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary You can give your peers funny names, like 2001:db8::dead:beef ;) - Prone to attacks (scans, router CPU load) - Waste of addresses - Peer address needs to be known, impossible to guess with 2^64 addresses /126 + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks - Not on a bit boundary, so more complicated for ACLs and ... - ... rDNS - Perhaps need to renumber into /64 some time. - No 64 bits for hosts You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for each PtP link, but only configure the first /126 (or whatever /126 you need to get an amusing peer address) on the link. + Sticks to the way IPv6 was designed (64 bits host part- even if it isn't all configured) + Probability of renumbering very low + simpler for ACLs and the like + rDNS on a bit boundary + Only 4 addresses possible (memorable, not so error-prone at configuration-time and while debugging) + Not prone to scan-like attacks + Easy to renumber into a /64 if you need to - Waste of addresses Seems to be a fairly good compromise, unless there's something I missed. ~Matt
