Re: GeoIP database issues and the real world consequences
On Mon, Apr 11, 2016 at 3:09 PM, Owen DeLongwrote: > So really, what is needed is two additional fields for the lat/lon of > laterr/lonerr so that, for example, instead of just 38.0/-97.0, you would > get 38.0±2/-97.0±10 or something like that. > It does seem needed to the geo location companies too, at least several of them provide this - and it's been this way for a long time. I didn't remember if Maxmind does or not, so I just checked. From some of their documentation, the field "accuracy_radius" is returned which is "The radius in kilometers around the specified location where the IP address is likely to be." See http://dev.maxmind.com/geoip/geoip2/web-services/#location . I don't think it's in their free stuff (you get what you pay for, it seems). It doesn't show up on their web interface to "try" the service nor does it give a warning that these things can be wrong, but IMHO probably wouldn't be a bad idea to say "Don't go show up at this address - it might not be right!"
Re: Internet Exchanges supporting jumbo frames?
On Wed, Mar 9, 2016 at 9:27 AM, joel jaeggliwrote: > PMTU blackhole detection implemented in all hosts. IPv4 is lost cause in > > my opinion (although it's strange how many hosts that seem to get away > > with 1492 (or is it 1496) MTU because they're using PPPoE). > > if your adv_mss is set accordingly you can get away with > a lot. > At least for TCP. EDNS with sizes > 14xx bytes just plain doesn't universally work across the internet, yet it's the default everywhere.
Static IPs
A helpful hint from a local broadband provider (I'm trying to wade through broadband options at home): "If your business is online, then you should have an IP address." I do find that helps. (in fairness, they are talking about static IPs, but it kind of fits with the rest of their marketing which says their highest speed plans include the advantage of "most reliable Wifi" when compared to their lower speed plans)
Re: Extraneous "legal" babble--and my reaction to it.
Postel's Law seems relevant to this issue. Sorry for contributing to the noise.
Re: RES: Exploits start against flaw that could hamstring huge swaths of
On Tue, Aug 4, 2015 at 4:53 PM, Randy Bush ra...@psg.com wrote: i love the devops movement; operators discover that those computers can be programmed. wowzers! Maybe we can give them a new title. I'm thinking, System Programmer.
Re: Android (lack of) support for DHCPv6
Agreed - apparently the solution is to implement SLAAC + DNS advertisements *AND* DHCPv6. Because you need SLAAC + DNS advertisements for Android, and you need DHCPv6 for Windows. Am I the only one that thinks this situation is stupid? On Tue, Jun 9, 2015 at 1:17 PM, Randy Bush ra...@psg.com wrote: i love this discussion. another enterprise wants to use ipv4 with minimal change from ipv4, has problems, and the usual suspects tell them to drink koolaid. and we wonder at the pitiful ipv6 deployment. randy
Re: Android (lack of) support for DHCPv6
Most APs don't support bridging, not enough addresses in the protocol (without enabling WDS or whatever modern versions of that are). On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, valdis.kletni...@vt.edu valdis.kletni...@vt.edu said: On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT? How does the device ask for a *second* DHCPv6'ed address for tethering or whatever? It's called bridging. Let whatever is being tethered ask directly for its own address. -- Chris Adams c...@cmadams.net
Re: Android (lack of) support for DHCPv6
Of course I've been up too long, ignore the idiot (me). :) On Tue, Jun 9, 2015 at 9:37 PM, Joel Maslak jmas...@antelope.net wrote: Most APs don't support bridging, not enough addresses in the protocol (without enabling WDS or whatever modern versions of that are). On Tue, Jun 9, 2015 at 9:14 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, valdis.kletni...@vt.edu valdis.kletni...@vt.edu said: On Wed, 10 Jun 2015 12:59:47 +1000, Karl Auer said: Hope the question doesn't make me look like an idiot, but why does using stateful DHCPv6 mean having to go back to NAT? How does the device ask for a *second* DHCPv6'ed address for tethering or whatever? It's called bridging. Let whatever is being tethered ask directly for its own address. -- Chris Adams c...@cmadams.net
Re: gmail security is a joke
I also suspect not every telco validates number porting requests against social engineering properly. A telephone number isn't something you have, it is something your provider has. On Wednesday, May 27, 2015, Saku Ytti s...@ytti.fi wrote: On (2015-05-27 14:19 +0200), Owen DeLong wrote: Hey, If someone has the ability to hijack your BGP, then you???ve got bigger problems than having them take over your Gmail account. This is second reply to this notion. I don't understand what is attempted to communicate. I'm sure no one on nanog thinks BGP hijacks are rare, difficult or yield to consequences when called out. That???s interesting??? Why do you choose to give access to your personal SMS messages to so many of your coworkers? I don't, but they can provision my number to any SIM they want to. -- ++ytti
Re: Rasberry pi - high density
Rather then guessing on power consumption, I measured it. I took a Pi (Model B - but I suspect B+ and the new version is relatively similar in power draw with the same peripherials), hooked it up to a lab power supply, and took a current measurement. My pi has a Sandisk SD card and a Sandisk USB stick plugged into it, so, if anything, it will be a bit high in power draw. I then fired off a tight code loop and a ping -f from another host towards it, to busy up the processor and the network/USB on the Pi. I don't have a way of making the video do anything, so if you were using that, your draw would be up. I also measured idle usage (sitting at a command prompt). Power draw was 2.3W under load, 2.0W at idle. If it was my project, I'd build a backplane board with USB-to-ethernet and ethernet switch chips, along with sockets for Pi compute modules (or something similar). I'd want one power cable and one network cable per backplane board if my requirements allowed it. Stick it all in a nice card cage and you're done. As for performance per watt, I'd be surprised if this beat a modern video processor for the right workload. On Mon, May 11, 2015 at 5:16 PM, Rafael Possamai raf...@gav.ufsc.br wrote: Maybe I messed up the math in my head, my line of thought was one pi is estimated to use 1.2 watts, whereas the nuc is at around 65 watts. 10 pi's = 12 watts. My comparison was 65watts/12watts = 5.4 times more power than 10 pi's put together. This is really a rough estimate because I got the NUC's power consumption from the AC/DC converter that comes with it, which has a maximum output of 65 watts. I could be wrong (up to 5 times) and still the pi would use less power. Now that I think about it, the best way to simplify this is to calculate benchmark points per watt, so rasp pi is at around 406/1.2 which equals 338. The NUC, roughly estimated to be at 3857/65 which equals 60. Let's be very skeptical and say that at maximum consumption the pi is using 5 watts, then 406/5 is around 81. At this point the rasp pi still scores better. Only problem we are comparing ARM to x86 which isn't necessarily fair (i am not an expert in computer architectures) On Mon, May 11, 2015 at 5:24 PM, Hugo Slabbert h...@slabnet.com wrote: Did I miss anything? Just a quick comparison. If those numbers are accurate, then it leans towards the NUC rather than the Pi, no? Perf: 1x i5 NUC = 10x Pi $$: 1x i5 NUC = 10x Pi Power: 1x i5 NUC = 5x Pi So...if a single NUC gives you the performance of 10x Pis at the capital cost of 10x Pis but uses half the power of 10x Pis and only a single Ethernet port, how does the Pi win? -- Hugo On Mon 2015-May-11 17:08:43 -0500, Rafael Possamai raf...@gav.ufsc.br wrote: Interesting! Knowing a pi costs approximately $35, then you need approximately $350 to get near an i5.. The smallest and cheapest desktop you can get that would have similar power is the Intel NUC with an i5 that goes for approximately $350. Power consumption of a NUC is about 5x that of the raspberry pi, but the number of ethernet ports required is 10x less. Usually in a datacenter you care much more about power than switch ports, so in this case if the overhead of controlling 10x the number of nodes is worth it, I'd still consider the raspberry pi. Did I miss anything? Just a quick comparison. On Mon, May 11, 2015 at 4:40 PM, Michael Thomas m...@mtcc.com wrote: As it turns out, I've been playing around benchmarking things lately using the tried and true UnixBench suite and here are a few numbers that might put this in some perspective: 1) My new Rapsberry pi (4 cores, arm): 406 2) My home i5-like thing (asus 4 cores, 16gb's from last year): 3857 3) AWS c4.xlarge (4 cores, ~8gb's): 3666 So you'd need to, uh, wedge about 10 pi's to get one half way modern x86. Mike On 5/11/15 1:37 PM, Clay Fiske wrote: On May 8, 2015, at 10:24 PM, char...@thefnf.org wrote: Pi dimensions: 3.37 l (5 front to back) 2.21 w (6 wide) 0.83 h 25 per U (rounding down for Ethernet cable space etc) = 825 pi Cable management and heat would probably kill this before it ever reached completion, but lol… This feels like it should be a Friday thread. :) If you’re really going for density: - At 0.83 inches high you could go 2x per U (depends on your mounting system and how much space it burns) - I’d expect you could get at least 7 wide if not 8 with the right micro-USB power connector - In most datacenter racks I’ve seen you could get at least 8 deep even with cable breathing room So somewhere between 7x8x2 = 112 and 8x8x2 = 128 per U. And if you get truly creative about how you stack them you could probably beat that without too much effort. This doesn’t solve for cooling, but I think even at these numbers you could probably make it work with nice, tight cabling.
Re: Network Segmentation Approaches
I'd certainly forget anything with service provider in the name. Different problem, different architecture. Last time I built this, I built a core network (WAN links, routers, etc) that enforced anti-spoofing rules, so I knew if I saw an internal IP address (either public assigned to me or RFC1918) on a given device inside this core, it came from the network segment it claimed to have come from. Then I built building-specific firewalls using proper firewalls. These might have anywhere from two interfaces (branch office) to thousands of interfaces (datacenters) with lots of VLANs. Checkpoint is a good product for this. The firewalls' job was to protect the building/segments behind it, not to protect things upstream (towards the core) of it. There was obviously an edge firewall. Users were segmented by job role. Workstations were typically considered to be *MORE* secure from a network perspective. AD servers need to be contacted by everything in your Windows domain. Most workstations don't. And your Windows domain, nowadays, probably includes cloud services over the internet. So it's hard to say AD servers are secure from a purely how many open network ports are there? standpoint. Servers were likewise segmented. I'd consider putting department file servers on the same LAN as the users, but only if performance required it - otherwise I'd put them on their own segments too. The benefit of this in a large organization is that a subdivision could put a firewall behind one of my anti-spoofing interfaces (so I validate packets come from them) and run it themselves without ruining everyone else's security. I second the thoughts about embedded management stacks. As for management, I put workstations used by IT management on their own segment (and give them a Stand up the infected workstation you're working on LAN separate from that segment). I put servers used for management on yet another segment. I've never had a problem with giving those workstations and servers access to management segments in the wild, but I trusted my skilled admins I worked with. Think mesh of connections, not tiers or levels or DMZs. Because you'll find that super-secure accounting server needs access from some random vendor across the internet, and stuff like that, such that everything eventually ends up in the DMZ anyhow (except MAYBE workstations). You can use separate firewalls for particularly sensitive segments - for instance, your management stuff might not be behind your main firewall - that way when Joe User gets a virus and fills the connection table on his firewall(s), you can still manage things. One more thing: Guest network access. When it was needed, I built a virtual network on top of the real Corporate LAN that tunneled this around. I terminated it on a DSL modem (which was sufficient for my needs). Just about every building with a conference room these days will need a guest network. It also helps if your employees can use their cell phones for checking work email and such - do you really want them on your main LAN? On Tue, May 5, 2015 at 7:01 AM, Keith Medcalf kmedc...@dessus.com wrote: It is called the Purdue Enterprise Reference Architecture ... -Original Message- From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of nan...@roadrunner.com Sent: Monday, 4 May, 2015 20:56 To: nanog@nanog.org Subject: Network Segmentation Approaches Possibly a bit off-topic, but curious how all of you out there segment your networks. Corporate/business users, dependent services, etc. from critical data and/or processes with remote locations thrown in the mix which could be mini-versions of your primary network. There's quite a bit of literature out there on this, so have been considering an approach with zones based on the types of data or processes within them. General thoughts: - Business Zone - This would be where workstations live, web browsing occurs, VoIP and authentication services live too. Probably consider this a somewhat dirty zone, but I should generally be OK letting anything in this zone talk fairly unfettered to anything else in this zone (for example a business network at my HQ location should be able to talk unfettered to an equivalent network at a remote site). I'd probably have VoIP media servers in this zone, AD, DNS, etc. - Some sort of management zone(z) - Maybe accessible only via jump host -- this zone gives control access into key resources (most likely IT resouces like network devices, storage devices, etc.). Should have sound logging/auditing here to establish access patterns outsid the norm and perhaps multi-factor authentication (and of course FW's). - Secure Zone(s) - Important data sets or services can be isolated from untrusted zones here. May need separate services (DNS, AD, etc.) - I should think carefully about where I stick stateful FW's -- especially on
Re: BCOP appeals numbering scheme -- feedback requested
You'll get more comments about the numbering scheme than any actual BCOP... On Thu, Mar 12, 2015 at 1:01 PM, Yardiel D. Fuentes yard...@gmail.com wrote: Hello NANOGers, The NANOG BCOP committee is currently considering strategies on how to best create a numbering scheme for the BCOP appeals. As we all know, most public technical references (IETF, etc) have numbers to clarify references. The goal is for NANOG BCOPs to follow some sort of same style. The BCOP committee is looking for feedback and comments on this topic. Currently, the below numbering scheme is being considered: A proposed numbering scheme can be based on how the appeals appeals in the BCOP topics are presented as shown below: http://bcop.nanog.org/index.php/Appeals In the above page, the idea is to introduce a 100-th range for each category and as the BCOPs. This way a 100th number range generally identifies each of the categories we currently have. An example is: BCP Range Area of Practice 100 - 199 EBGPs 200 - 299 IGPs 300 - 399 Ethernet 400 - 499 Class of Service 500 - 599 Network Information Processing 600 - 699 Security 700 - 799 MPLS 800 - 899 Generalized An arguable objection could be that the range is limited...but a counter-argument is that considering more than 100 BCOPs would be either a great success or just a sign of failure for the NANOG community ... Comments or Thoughts ? Yardiel Fuentes
Re: Checkpoint IPS
On Thu, Feb 5, 2015 at 10:47 AM, Roland Dobbins rdobb...@arbor.net wrote: On 6 Feb 2015, at 0:38, Raymond Burkholder wrote: There must some sort of value in that? No - patch the servers. Patching servers protects against 0 Day attacks only. This does not protect against 0 day attacks, unless you know of an OS vendor that writes good code without security holes. What type of device needed depends on risk, what you are protecting, what attacks are important, etc. It's not a simple matter of firewall bad or firewall good. I won't even get into the stateless-vs-stateful debate, because it's more complex than stateful bad (*cough* SIP *cough*). Nor will I mention that it depends on what your protecting to figure out how much of each of availability or confidentiality or integrity you need - you might need lots of integrity but little availability, for instance.
Re: DDOS solution recommendation
On Sun, Jan 11, 2015 at 6:46 AM, Mike Hammett na...@ics-il.net wrote: You hit my honeypot IPs, blackholed for 30 days. You do a DNS request to my non-DNS servers, blackholed for 30 days. Same goes for NTP, mail, web, etc. You have more than say 5 bad login attempts to my mail server in 5 minutes, blackholed for 30 days. You're trying to access various web pages known for home router or Wordpress exploitation, blackholed for 30 days. I urge caution in building automatic systems to respond to network abuse, lest you have unanticipated consequences. How are you tracing the source for DNS UDP, NTP UDP, etc, requests? Or TCP SYNs? If you say source address in the packet, you might not be doing what you think you're doing. Or for that matter HTTP accesses. Without giving too much discussion, let me point out: 1) You can forge a victim's IP and send packets to a honeypot (or indeed the entire IPv4 internet if you want). You may not want to assume I see a packet with this claimed source being sent to X, so it must be a bad guy and I should block it. 2) Web crawlers will follow links from Bad Guy's Site to your website, even if these links might match an IDS signature on your end. You may not want to block some search engine crawlers. 3) Legitimate recursive DNS servers can be made to connect to any IP address a bad guy wants them to connect to. You may not want to block some ISP's recursive DNS servers. There are good things to do automatically, but make sure you think them through. I used to do click fraud detection 15 years ago - when that was still a new field and we all were inventing our own ways of doing it. I was amazed at the number of ways a bad guy could do an HTTP request from millions of source IPs (hint: they weren't spoofed). I suspect it hasn't gotten better. The internet isn't able to be broken because the people building and running it are idiots. It's able to be broken because breaking things has always been far easier than building them. It takes much more intelligence, skill, and expertise to build a glass window than to throw a brick through one.
Re: Cisco CCNA Training
You might look at your local community college's offerings. Probably better bang for the buck than many other offerings. On Sun, Nov 2, 2014 at 10:02 AM, Colton Conor colton.co...@gmail.com wrote: We have a couple of techs that want to learn cisco and networking in general. What do you recommend for learning and getting certified on Cisco? There seems to be a million different training courses, books, etc out there.
Re: L6-20P - L6-30R
You probably should ask your facility operator or electrician what the requirements are (who, unlike most network engineers, is qualified to decide what to do), but it sounds like replacing the PDU is simple and easy, and unquestionably not a bad thing to do. Alternatively, you can replace the 30A circuit with a 20A one. I'm not an electrician, but I'll bet it's not much more complex or expensive than replacing a breaker and a receptacle, and I'd be shocked if it took more than an hour of a qualified person's time, and I suspect it would cost about the same for parts as building some sort of adaptor cord (and less if you the electrician has spare parts - he gets a 30A breaker and 30A socket in exchange for a 20A breaker and 20A socket). The added benefit of 20A, assuming your equipment power usage is low enough to use 20A, is that it's usually cheaper (sometimes significantly) if you're paying someone else for the power circuit each month.
Re: valley free routing?
I have worked for the middle network when I was responsible for a government network - typically we were the middle network. Logic was it was good for citizens for us to essentially act like a peering exchange for certain types of entity (who also typically were government affiliated). One I can think of was to allow a full mesh of video education between various institutions - it was the right thing to do for all entities involved and I facilitated it through the network I was affiliated with. You might also think about the circumstance of two government subcontractors working on a common project or interfacing with each other's systems on behalf of a common customer. The middle network is paying each end to connect to the middle but is providing reverse transit between them (I.E. the end entities are paid to transit the middle!), although the contracts aren't exactly phrased to say that! A lot of time, this may be done with static routes, but it could easily be done with BGP and the end effect is the same. I have never heard the term valley free. Where does it come from? On Mar 5, 2014 1:25 PM, William Herrin b...@herrin.us wrote: Hi folks, Can anyone tell me about a situation in which a route which was not valley free was not a result of a misconfiguration or a bad actor? For those who don't recall the terminology, a network path is valley free if it crosses exactly zero or one free peering links when traveling between the two endpoints. Thanks, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: home network monitoring and shaping
I've had great luck with Cisco's fair-queue option (and similar techniques). Using RED, small queues (think on the order of 10-20 packets), and creating a choke point in and out of the network, I've implemented similar behavior on plenty of DSL lines on the CPE-side. My most successful was sharing one 7mbps line with 120 technical employees - before the implementation of improved queuing, web pages took 60 seconds or more to load during peak usage. After implementation, people didn't know they were on a shared DSL unless they tried streaming video (fortunately not a business requirement) or a bulk download (it worked fine, it just would be slow if there were several others going on at the same time). I suspect I could have even made a VoIP call across the line with a MOS in the high 3's easily. A second issue is poor wireless retransmission and buffering implementations in consumer wireless. For my home, to make VoIP work with low-end gear, I had to break most HTTP sessions and switch to a delay-based congestion control algorithm inside my network - due to the 5+ second buffers on the wifi gear. That would probably have been enough, but turning on WMM really took the rest of the pain out of wifi-VoIP. I don't know how to fix the home wifi problems (WMM helps with some applications, certainly, but it's not a full solution if you still have 5 second buffers in the default traffic class). But for the other problems, it would be nice if my provider didn't give me huge buffers and no RED on the output queue (I have no idea if they are doing the best they can with the gear they have or not, so there may not be any option here). But, even without that, home routers can do better than they do now. My router knows what speed it's connected at. It can create an internal bottleneck slightly slower, prioritize small packets, implement RED, and use reasonably-sized buffers (fast downloads should not increase ping times by hundreds of ms). I shouldn't need to hang a Linux box between it and my home network. Large buffers have broken the average home internet. I can't tell you how many people are astonished when I say one of your family members downloading a huge Microsoft ISO image (via TCP or other congestion-aware algorithm) shouldn't even be noticed by another family member doing web browsing. If it is noticed, the network is broke. Even if it's at the end of a slow DSL line.
Re: Issues encountered with assigning all ones IPv6 /64 address? (Was Re: Issues encountered with assigning .0 and .255 as usable addresses?)
On Tue, Oct 23, 2012 at 9:18 AM, Mike Jones m...@mikejones.in wrote: IPv4 addresses ending in .0 and .255 can't be used either because the top and bottom addresses of a subnet are unusable. Why would hetzner be making such assumptions about what is and is not a valid address on a remote network? if you have a route to it then it is a valid address that you should be able to exchange packets with, any assumptions beyond that are almost certainly going to be wrong somewhere. As to why: I suspect they don't know either. I wouldn't be surprised if it was someone's misguided attempt years ago to stop smurf amplification attacks, long since forgotten. I'm not saying it's a good idea (it's not), just why I suspect someone would do this.
Centurylink Contact
Does anyone have a good contact to report outside plant issues in the Denver, CO area? Some construction equipment in my neighborhood snagged and snapped a messenger cable between poles, and probably stretched some copper. I'd like to make sure that CL actually gets notified and gets it fixed. My line is fine, so their automated residential customer service line wasn't helping me at all.
Re: Color vision for network techs
On Aug 31, 2012, at 12:27 PM, JC Dill jcdill.li...@gmail.com wrote: So if you DO decide to test for color vision, make sure you know your rights and responsibilities for handling any employee or applicant who fails the test. IANAL - if you have any questions be sure to get advice from an attorney - preferably one who specializes in employment law. Agreed. It's also a good idea to check with JAN if you're in the US, to see what accommodations they might suggest. I'd also add that it's the decent thing to do - if someone is qualified for the job, except for not being able to do one small part of the job the way you would imagine it being done, the right response is to find solutions, not immediately dismiss the qualified applicant. I had some involvement in the past with employees with vision disabilities. Many are trivial to accommodate. Tools I've personally seen used are the Seekey and colored pieces of plastic (overlays). The overlays are very cheap, not sure how much a Seekey costs. I'd also suggest asking the employee, since they have a vested interest in finding a solution. These would also work for terminating twisted pair cables. I've also seen an electronic pen-like device that was used by blind people, to determine if an LED was lit. We used this for a phone receptionist who needed to scan busy lights on a telephone while handling calls (I'd probably look at a softphone type solution today, but the phone system we used was definitely not softphone capable!). I don't know if it can tell the difference between red or green, nor do I remember what the thing was called. (also note that, depending on environment, reasonable accommodation might also mean asking a coworker what color the light is)
Re: DDoS using port 0 and 53 (DNS)
On Wed, Jul 25, 2012 at 8:43 AM, John Kristoff j...@cymru.com wrote: Some UDP applications will use zero as a source port when they do not expect a response, which is how many one-way UDP-based apps operate, though not all. This behavior is spelled out in the IETF RFC 768: That would only be applicable if the box was expecting to receive UDP and not send a response. I'm not sure I can think of anything but specialized, vertical applications that would have that behavior with port zero (syslog and SNMP traps send without expecting a response, but they don't use port zero in any implementation I've seen, and neither is generally allowed to be received from the internet at large). In addition to the fragments, these packets might also be non-TCP/UDP (ICMP, GRE, 6to4 and other IP-IP, etc). If the host doesn't expect to receive large UDP packets, you can block UDP fragments. Note that recursive DNS servers would need UDP fragments (well, if you want to do large DNS packets - if you set the right options, you can turn that off). But if you aren't generally providing UDP services, blocking UDP packets, especially to stop an attack, wouldn't hurt (you can also block anything with the MF bit set). If you block these fragments at your provider's router, and it is a DNS amplification attack, you're problems are probably solved until the hacker figures it out. Just make sure you think of things like recursive DNS and other applications that may be using UDP fragments.
Re: technical contact at ATT Wireless
On Thu, Jun 28, 2012 at 1:35 PM, PC paul4...@gmail.com wrote: While you're at it, I've been also trying to complain about them using RFC1918 (172.16.) address space for the DNS servers they assign to their datacard subscribers. Causes all sorts of problems with people trying to VPN in as the same IP range is used by me. Which is why enterprises generally shouldn't use RFC1918 IPs for servers when clients are located on networks not controlled by the same entity. Servers that serve multiple administration domains (such as VPN users on ATT - or on some random home Linksys box) probably shouldn't be addressed using addresses that conceivably could be used at the other end. But I'm probably fighting a losing battle saying that... It's why at my last enterprise net admin jobs, I refused to establish a site-to-site VPN session with organizations using RFC1918 space as part of the tunnel definition (it's amazing how few organizations wanted to use global IPs for inter-domain routing, but most came around, although I had to loan IP addresses to several so they could static NAT their servers behind them). It's simple: If I wouldn't accept IPs in that range over a public BGP peering, I didn't want it over a private static route either. I couldn't control what you did for RFC1918, nor could you control what I did - so I exposed public IPs, and expected you to do the same. :) RFC1918 and VPN becomes non-scalable fast when you connect to lots of different organizations - it doesn't take long before two organizations you connect to both want to use 172.16.0.x/24 or 10.0.0.x/24 or 192.168.0.0/24, or similar). The same logic goes for VPN clients - if one end is potentially using RFC1918, the other end better not use it. Since you can usually only control one end of the VPN for road-warrior VPN, it's best to make that end not use RFC1918. Otherwise you may find you need to route 192.168.x.y, but that just so happens to be the user's default gateway, name server, printer, or other key device. Of course having another set of NAT addresses for CGN will solve everything (yes, that's sarcastic, but I can predict how they'll be used to solve this type of problem). Just because it usually works doesn't mean using RFC1918 addresses for left and/or right subnets in a VPN is a good idea.
Re: CVV numbers
On Jun 9, 2012, at 1:06 AM, Hal Murray hmur...@megapathdsl.net wrote: Should I really take them seriously? Your call. That said, the purpose of CVV is to stop *one* type of fraud - it's to stop a skimmer from being able to do mail-order/internet-order with your card number. The CVV is not on the magnetic strip, so a skimmer installed at the ATM or gas pump won't be able to capture it. There's a similar value on the magnetic strip that keeps the internet site you gave your card number and CVV to from being able to print cards and use them at the gas pump. Certainly they don't stop all fraud. They stop one type of fraud.
Re: IPv6 day and tunnels
On Jun 4, 2012, at 1:01 AM, Owen DeLong o...@delong.com wrote: Any firewall/security device manufacturer that says it is will not get any business from me (or anyone else who considers their requirements properly before purchasing). Unfortunately many technology people seem to have the idea, If I don't understand it, it's a hacker when it comes to network traffic. And often they don't understand ICMP (or at least PMTU). So anything not understood gets blocked. Then there is the Law of HTTP... The Law of HTTP is pretty simple: Anything that isn't required for *ALL* HTTP connections on day one of protocol implementation will never be able to be used universally. This includes, sadly, PMTU. If reaching all possible endpoints is important to your application, you better do it via HTTP and better not require PMTU. It's also why protocols typically can't be extended today at any layer other than the HTTP layer. As for the IETF trying to not have people reset DF...good luck with that one...besides, I think there is more broken ICMP handling than there are paths that would allow a segment to bounce around for 120 seconds...
Re: IPv6 day and tunnels
On Jun 3, 2012, at 7:38 PM, Joe Maimon jmai...@ttec.com wrote: www.arin.net works and worked for years. www.facebook.com stopped June 1. So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly? It doesn't fix the fragmentation issues. It assumes working PMTU. For what it's worth, I also use a tunnel without issue to reach www.facebook.com via IPv6, with an MTU of 1476 (since it's running over a 1492 byte IPv4 PPoE tunnel...).
Re: Comcast Paid Peer Pricing
On Jun 2, 2012, at 3:08 PM, Nabil Sharma nabilsha...@hotmail.com wrote: Dear NANOG: I seek pricing on Comcast AS7922 paid peer at following commit level: 1G 10G 100G Please reply in private and I will sum up on list. Sincerely, Nabil I'd suggest contact Comcast sales.
Re: Outdoor Wireless Access Point
On Apr 1, 2012, at 3:44 PM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: With 802.11, you can connect to an AP and, if the AP fails, you may be connected to another AP, but the transition takes considerable amount of time not tolerable for voice communication, which is why it is not called mobility. True under basic 802.11, at least with WPA2 + EAP, for some clients. Not all clients wait until they lose connectivity to start looking for another AP - it depends on how the client was built. However, even without needing to lose connectivity to learn what other APs are nearby, there still is a substantial associatiation delay with EAP. That's why 802.11r + 802.11k exist. I'm sure the big name vendors support this and also support their proprietary alternatives that may or may not be better. If you want mobility, have different SSIDs for APs in the same frequency band (or, let terminals have multiple sets of radio interfaces) and let terminals connect to multiple APs simultaneously. That's one way of doing it, provided you have a way to manage all the end devices when you add new APs. It has the disadvantage of not being a COTS solution AFAIK. Another way to do it is Meru's one frequency, one MAC approach. As for locating other access points, even without 802.11k, most solutions I have seen go into power save mode for long enough to do a quick scan every once in a while, taking into account the size of the phone's jitter buffer. That causes the AP to hold packets until the scan finishes. So one channel is not required for fast roaming. I've seen solutions cope without 802.11r + 802.11k by using a WEP-only SSID on each AP (typically the same SSID for all APs) and throwing that into a VOIP-only VLAN. But with smartphones capable of running VoIP clients, I'd be less inclined to do it that way even if I thought WEP was secure-enough for voice calls. The other solution that I've seen some things support is to use WDS on the VoIP device. I'm also not a fan of that personally, but others may be. WDS would require one frequency throughout the network however. Though you only have to modify software on terminals, AFAIK, there is no such commercial products. There are plenty of commercial products that support VoIP handoff without issues. Some are proprietary, some are open standards. Many support multi-channel networks. It starts to get expensive to do this though, as most (all?) of the cheap vendors don't do what is required on the AP side. That said, I'd love to hear I'm wrong on this - I'm looking for new APs for home. So, if I was buying an enterprise 802.11 solution and needed to support seamless VoIP roaming, I'd look at either a one-vendor solution (I'm sure Cisco phones + Cisco APs + Cisco Controller + Cisco PBX would do this just fine, for instance; you can substitute a few other big vendors for Cisco, no doubt, although not likely cheap ones; you'll be spending 10x or more per AP in many cases than if you could have used the cheap ones) or someone that complies with 802.11r + 802.11k (both for handses and APs). Obviously your network better support DSCP and/or VLAN priority marking and WMM as well. Supporting VoIP handoff is much more complex (and, at least from what I've seen, expensive) than supporting web browsing handoff. It's also what seperates different pricing tiers of wireless equipment.
Re: Outdoor Wireless Access Point
On Mar 31, 2012, at 3:38 AM, Shahab Vahabzadeh sh.vahabza...@gmail.com wrote: As I look for maps we need at least 3 or 4 outdoor radio, I think in these networks the best solution is to have only one SSID in whole network to give mobility for the network, is this called ad-hoc? or it has an other name? No, it's still infrastructure mode, not ad-hoc. Ad-hoc means no access point. All you need to do is set the APs up to use the same SSID and authentication methods, keys, etc. It's pretty simple and can even be done with consumer gear (with less stable performance of course). If you don't put the APs all on the same layer 3 LAN (same subnet), you'll need some sort of controller-based solutions so that a user's IP address still makes sense to their computer when they move from one AP to another. If you can keep all the APs on one subnet, you won't need that. It gets a bit more complex if you are using radio to link buildings together and/or backhaul to the access point. There's plenty of good references on the internet. Note that the wireless handoffs aren't perfect on basic 802.11 gear. Your laptop might not pick the best AP if it can hear multiple APs. And you might lose a few packets when you hand-off between APs, but it's typically no big deal. Your ssh session would stay connected across those hand-offs just fine. If you plan on doing VoIP on the wireless, it gets more complex yet - you have to worry about the time it takes handoffs and that can be more complex. You have to implement WMM and DSCP. You need to worry about low-speed users (1mbps, 2mbps, etc) on the same link. It's a lot harder to build a VoIP wireless solution than a web browsing wireless solution, but still plentty possible to do without expensive equipment. In summary: you probably should find a guide on how to build wireless networks, preferably a vendor agnostic one. You will either be the hero of your organization or the enemy, depending on how well your network works.
Regex validation, was Re: Programmers with network engineering skills
On Mon, Mar 12, 2012 at 9:18 PM, Mark Andrews ma...@isc.org wrote: Only if you don't properly quote/escape the arguments you are passing. You're using your OS wrong if you are quoting/escaping the arguments. You do not need a shell involved to use fork() + exec() + wait(), as the shell is not involved (assuming Unix; I also suspect libc has a nice packaged function for this that is not insecure like system(), but it's not all that hard to roll your own). In Perl, use the multi-argument form of system(), not the single argument version(). In both cases you should clear the environment as well prior to the exec()/system() unless you know nobody can play with LD_PRELOAD, IFS, etc. This is one of my pet peeves about programming - programmers calling out to insecure functions when secure alternatives are available. The same goes for SQL statements - if you need to quote things to prevent SQL injection, you're using your SQL database wrong. Look up prepared statements. Generally, it's very bad practice to dynamically build SQL strings. It's also very common practice, hence why so many applications have SQL injection vulnerabilities. It's the Perl/PHP equivalent of the buffer overflow that simply wouldn't exist if developers, instead of trying to figure out how to quote everything, simply used prepared statements and placeholders. As for checking for bogus email addresses, read the RFC and code it right. That's not with a too-simple regex, nor is it with a complex regex. You need a parser, which is the right tool for the job. Regex is not. But there is value in not passing utter garbage to another program (it has a tendency to clog mail queues, if for no other reason) - just make sure you do it right. I might add that the same goes for names. People don't just have a first name and a last name - some people just have one name, some people have three or four names, some people have surnames with spaces, hypens, or apostrophes (remember what I said about SQL?!), etc. Yet most systems I see assume people have two names with no spaces, apostrophies, hyphens, etc. Big mistake. And don't get me started on addresses, which might have one address line, two address lines, even 5 address lines, to say nothing that international addresses may or may not put the street part first. It's certainly not easily regex-able. Okay, I'll step off the soap box and let the next person holler about how I was wrong about all this!
Re: VLAN Troubles
I've never had problems setting up multiple VLANs on a link between Cisco, HP, Dell switches, IBM mainframes, VMWare servers, 3COM/Nortel, Polycom Phones, Linux servers, etc. If both ends supported 802.1q, it just worked, if the admin read the manual for both pieces of gear and knew how to troubleshoot problems. Sure, one vendor can be nice a lot of the time - even cheaper once support costs are factored in. But making VLANs work between different vendor's equipment is a pretty basic networking skill. So I'm kind of astonished at the sell what you have and buy new from one vendor responses. I've not used the specific Dell switches mentioned, but I've used others and have plenty of opinions on the management interface of them. But for a wiring closet or top of rack switch, I can't say that I would suggest to replace them with something new just because I wanted a different management interface (that said, I very well might write some scripts to manage the uglier interfaces).
Re: Please help our simple bgp
On Mon, Jan 30, 2012 at 7:27 PM, Ann Kwok annkwo...@gmail.com wrote: We discover the routes is going to ISP A only even the bandwidth 100M is full There are several ways to handle this is, if you have at least two /24s of space. Let's say you just have two /24s, both part of the same /23. Option 1: Announce m.m.m.m/24 with no path prefixing on ISP A. Announce m.m.m.m/24 prefixed with your own ASN one or two times on ISP B. Announce n.n.n.n/24 with no path prefixing on ISP B Announce n.n.n.n/24 prefixed with your own ASN one or two times on ISP A. Most of the internet would probably prefer A for m.m.m.m/24, and prefer B for n.n.n.n/24. But if either A or B went down, there would still be a reachable route. Option 2: Announce m.m.m.m/23 on both ISP A and B Announce m.m.m.m/24 on ISP A Announce n.n.n.n/24 on ISP B The n.n.n.n/24 which is part of m.m.m.m/23 would use ISP B for inbound traffic, while ISP A would be used for m.m.m.m/24. If either A or B, the less specific /23 would provide a backup path. Can we set the weight to change to ISP B to use ISP B as preference routes? Not really. You may be able to set a community that controls how ISP B advertises the routes or preferences your traffic. Weights generally aren't used for path selection.
Re: bgp question
On Thu, Jan 19, 2012 at 6:27 AM, Deric Kwok deric.kwok2...@gmail.com wrote: We are planning to have 3 x 1G bgp connections (full tables) eg: Path A, B, C Can I say that we have 3G output totally? Sure. From my understanding, the bgp chooses the best path to route automatically It doesn't. It typically chooses the path with the least number of autonomous systems for a given destination. That can actually result in longer physical paths in many cases. Let's say provider C buys bandwidth from A and B (and nobody else). If that's the case, you will only use C for things directly connected to C's network (typically only things that pay C), but every other internet destination would use A or B. (unless you adjust things to not do this). If the path A is best route and that path 1G bandwidth is used up, will bgp try to use path B and path C automatically? No, with one caveat. If you fill up the pipe enough that routing messages don't get through, those routes will eventually time out and the path won't be used at all. How can I use up those 3G? You will need to manually adjust routes, preferences, etc. You'll still have one path that is hotter than the others (although hopefully not too much hotter). Are you worried about incoming or outgoing bandwidth, or both? For incoming, you will need to do things like: 1) Announce all of your prefixes aggregated out all 3 links 2) Announce parts of your prefixes out ONLY ONE link. So announce /24 #1 out A, /24 #2 out B, /24 #3 out C. This means you're forcing incoming traffic to generally come in one link per /24. The problem with this is that a really active /24 will get more traffic still. It also requires you to have at least 3 /24s (you can't route longer prefixes, which means you can't route PART of a /24). For outbound, the easy and obvious way would be for your providers to just announce 0/0 to you and for you to do some sort of flow-based load balancing. But if one provider had reachability problems, you'd go down. So without that, you'll have to adjust the preferences of incoming routes. Alternatively use BGP multipath and buy from one provider (and connect to the same router on the provider side). Bandwidth from one provider isn't necessarily a horrible thing, if you pick a good one provider. Even with multiple BGP feeds, unless you are really, really careful (and, most likely, spend tons of money for things like fiber redundancy so the different fibers don't all end up on one pole or going into the same telco building) you'll still have single points of failure.
Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
On Dec 29, 2011, at 7:00 PM, Jeff Kell jeff-k...@utc.edu wrote: The real-world case for host routing (IMHO) is a server with a public interface, an administrative interface, and possibly a third path for data backups (maybe four if it's VMware/VMotion too). Unless the non-public interfaces are flat subnets, you need some statics (today). It can be a challenge to get SysAdmins in a co-operative mindset to route that correctly (and repetitively if you have a server farm). What I've done in that case as a sysadmin was a default out the internet interface and some sort of ospf daemon to handle the rest. If I want a host to learn routing, I put a routing daemon on it. Otherwise I just use a default route. I don't see why this changes with IPv6.
Re: Speed Test Results
On Fri, Dec 23, 2011 at 10:13 AM, Livingood, Jason jason_living...@cable.comcast.com wrote: If you want to understand the issue in detail, check out the report from MIT this year, written by Steve Bauer and available at http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_Broadband_Speed_Measurem ents.pdf. They should have put a date on their paper, including when the measurements were done. It appears to me to have been done sometime after or around June of 2010.
Re: subnet prefix length 64 breaks IPv6?
On Dec 27, 2011, at 4:28 PM, Glen Kent glen.k...@gmail.com wrote: I had assumed that nodes derive their link local address from the Route Advertisements. They derive their least significant 64 bytes from their MACs and the most significant 64 from the prefix announced in the RAs. No, link local addresses are not derived from RAs. Even a system not connected to a router will have a link local address on each ethernet (I couldn't tell you how link local works on PPP, ATM, etc, without looking it up - but it doesn't require /64 networks).
Re: Speed Test Results
On Fri, Dec 23, 2011 at 2:18 AM, jacob miller mmzi...@yahoo.com wrote: Am having a debate on the results of speed tests sites. Am interested in knowing the thoughts of different individuals in regards to this. It's one data point of many. Depending on the speed test site, the protocols it uses, where the test is located, any local networking gear (I've seen transparent proxies get great speedtest ratings!), etc, they can be useful, particularly in verifying that a provider's off-net interconnects and partners are doing well. However, they are susceptible to things like wireless network issues, TCP limitations (one stream vs. many streams), and misconfiguration of devices at the customer location. And the speed test box isn't necessarily configured/speced correctly either. I second the thoughts on NDT and I like the ICSI Netalyzer. But I wouldn't necessarily put either tool in most end users' hands (I think they are too complex for most end users to interpret the results properly).
Re: Recent DNS attacks from China?
Other than being non-compliant, is an ANY query used by any major software? Could someone rate limit ANY responses to mitigate this particular issue? On Fri, Dec 2, 2011 at 8:17 AM, Leland Vandervort lel...@taranta.discpro.org wrote: Yup.. they're all ANY requests. The varying TTLs indicates that they're most likely spoofed. We are also now seeing similar traffic from RFC1918 source addresses trying to ingress our network (but being stopped by our border filters). Looks like the kiddies are playing On 2 Dec 2011, at 16:02, Ryan Rawdon wrote: On Nov 30, 2011, at 3:12 PM, Drew Weaver wrote: -Original Message- From: rob.vercoute...@kpn.com [mailto:rob.vercoute...@kpn.com] Sent: Wednesday, November 30, 2011 3:05 PM To: matlo...@exempla.org; richard.bar...@gmail.com; andrew.wall...@rocketmail.com Cc: nanog@nanog.org; lel...@taranta.discpro.org Subject: RE: Recent DNS attacks from China? Yes it is, but the problem is that our servers are attacking the so called source address. All the answers are going back to the source. It is huge amplification attacks. (some sort of smurf if you want) The ip addresses are spoofed (We did a capture and saw all different ttl's so coming from behind different hops) And yes we saw the ANY queries for all the domains. I still wonder how it is still possible that ip addresses can be spoofed nowadays We're a smaller shop and started receiving these queries last night, roughly 1000 queries per minute or less. We're seeing that the source (victim) addresses are changing every few minutes, the TTLs vary within a given source address, and while most of the source/victim addresses have been Chinese we are seeing a few which are not, such as 74.125.90.83 (Google). The queries are coming in to ns1.traffiq.com (perhaps ns2 also, I haven't checked) and are for traffiq.com/ANY which unfortunately gives a 492 byte response. = Rob, Transit providers can bill for the denial of service traffic and they claim it's too expensive to run URPF because of the extra lookup. -Drew
Re: Network device command line interfaces
On Fri, Nov 25, 2011 at 12:01 AM, Robert Bonomi bon...@mail.r-bonomi.comwrote: The trick to deailing with this as a propellorhead[sic] is to include a *monetized* estimate of the increased manpower OPEX of using the 'dog to work with' box. And a TCOS figure over the projected lifetime of the units. No need to 'fight' with management about it, just understand 'how' they make the decisions, and give them the informatin they need to make the decision come out 'your way'. I'd say that the ethical thing to do is to give them the information they need to make a decision, not to get it your way. I see, for instance, people buying local closet switches from brand A when brand B is much, much cheaper (but lacks the prestige of brand A), had a perfectly workable management interface, and will perform identically, with similar support offered by both vendors. But they are an ACNA or whatever, or they've just heard of (insert brand here), so they buy it. Because it's easy and familiar. It's also possible that a web managed switch (which I despise) might actually be the right choice for a business - because factors other than a technologist's distaste might be important. Part of being ethical (and NOT like the business people we might all despise!) is to be honest. So we don't compare brand A to brand B unfairly. We don't inflate the cost of brand B by adding brand B's management infrastructure to the cost when we darn well know we just will need a minor tweak to our scripts that can already manage brand A. That sort of thing. I generally agree with what Robert said: It's about what makes sense to the business. If operating expenses will increase (Well have to grow headcount by 3 to support this), then bring that up. A caution though: Takes less effort to run doesn't equate to dollars (the question a former manager would ask me when I tried that line was, So who do you think we should lay off then to get the dollar savings? Fortunately he was a good manager who wasn't serious, but was rather trying to get me to think about what I'm saying). I like paychecks, which is why I work for a living - it's about the dollars. So it's not unreasonable for my management to also care about the money (since it's a key motivation for myself, after all!). Yes, I'm fortunate to do a job I love and get paid for it at the same time. I can say, for a CUI interface, operations over low-speed links (wireless VPN when I'm away from the office and in a bad cell zone, for instance) is likely important. So is ability to script common tasks to allow people like the help desk to do their jobs at low risk. Flexibility is also important - when I'm stuck with this piece of gear (which is shiny today) in 5-7 years, when it's not so shiny, is it going to have flexibility to last a bit longer if the business needs to conserve cash - or will a minor change in how we do business make this thing functionally obsolete? Relating to the discussion on the tier 1 mentor thread, someone who wants to go far in networking won't be married to a particular vendor or way of doing things. They'll excel and find ways to overcome challenges, including less than perfect equipment, that they might have to deal with. They'll do so in a way that makes the customer and their own management happy. A highly paid network engineer who complains about work being difficult probably won't do that. One that finds a $500 replacement for a $5000 router probably will stick around, provided they can actually deliver what they promised (the guy that puts the $500 replacement in only to have to replace it in a year with a $5000 router again won't go far, so be careful! And you better have figured in the real costs of running a network with $500 routers, not just the cost of the router).
Re: Dynamic (changing) IPv6 prefix delegation
On Nov 22, 2011, at 8:05 AM, Ray Soucy r...@maine.edu wrote: As long as a static allocation can be billed as a premium service, most providers will unfortunately do it. Exactly. ISPs are in business to make as much money as they can - go figure. For myself, having a static IP is the least of my concerns - even on my inside network. Everything I have (printers, media boxes, etc) does some sort of lookup protocol so I have no problem connecting (and thus they get assigned dynamic addresses by my router). I'm personally much more concerned about other things: 1) Not having IPv6 at all. I expect to get it on my DSL in about 10 years or so when the equipment my line on is old enough to be replaced under a 15 or 20 year replacement cycle. 2) Bandwidth caps probably affect people a lot more than changing IPs. I don't have one on my landline, but I expect to get it when the DSL aggregation devices are replaced (I suspect I don't have it now because the equipment doesn't do it well). 3) If you write an application using anything other than UDP or TCP, it won't work on most networks (with some minor exceptions for PPTP and IPSEC, which work sometimes). 4) What would happen if someone wrote a popular app that used IP options? I don't want to know that answer even though I already know it. Break the internet is about how I'd phrase it. 5) I have a server in a datacenter that provides IPv6. They even assign me a /48. They assigned the /48 to my subnet. I guess they thought I'd run out of addresses in a /64 and heard that you are supposed to assign /48's. The only problem is that a subnet /48 means I can't route /64s elsewhere, nor does autoconfiguration work (maybe that is a feature?). 6) The same server can't receive IP fragments, except for the first one. For security. Never mind what this does to DNS with DNSSEC and IPv6 (IPv6 will cause longer answers). Yes, I know I can turn off large UDP responses on my resolver. I bet more than a few people don't know that though. 7) Even UDP and TCP aren't going to work everywhere. Hense why everything seems to tunnel over HTTP or HTTPS even when that's an inappropriate method (such as when reliable ordered packet delivery is a hinderence). 8) Don't use the wrong ToS on your packets. It'll be eaten by some random provider. So if you use any ToS internally, you need a middlebox to unset your ToS bits. I'd gladly give up a static IP address just to have an internet that delivered my packets from my home or server to the remote destination.
Re: Strange static route
On Sep 25, 2011, at 3:37 AM, Tom Storey t...@snnap.net wrote: I found I had to do this many years ago on some Cisco routers to get them to load balance (per packet) across two links. Adding 0.0.0.0/0 routes across both links just resulted in traffic routing across one link. Broke it into two /1's per link and it worked perfectly. Two other reasons for this too: 1) Something won't redistribute 0.0.0.0/0 on the network. Either because the person doesn't know the command to tell the router to do it, or because the router simply won't redistribute a default route. 2) Could also be failover. One router might be advertising 0.0.0.0/0 on one end of the network. A different router on a different part of the network might be advertising the two /1's. The /1's would be used unless they became unreachable.
Re: Strange static route
Protection against learning a bad default route through whatever routing protocol they are learning, since these two routes would be more specific than any typical default route. They probably got burned learning a default route. On Sep 23, 2011, at 7:12 PM, Glen Kent glen.k...@gmail.com wrote: Hi, I have seen a few operators adding static routes like: 0.0.0.0/1 some next-hop and 128.0.0.0/1 some next-hop. Why would anyone want to add such static routes? What does 0.0.0.0/1 mean. Note that the netmask is 1 and not 0. Thanks, Glen
Re: OT: Given what you know now, if you were 21 again...
On Wed, Jul 13, 2011 at 3:08 PM, Larry Stites nc...@sbcglobal.net wrote: Given what you know now, if you were 21 and just starting into networking / communications industry which areas of study or specialty would you prioritize? Make sure you are always learning. You can't stop learning in this industry. Study the academic side of computers, not just how to use specific systems. Know that systems other than the all-or-nothing superuser-based security model exist, what a functional programming language is, basic computational complexity, etc. Unix or Cisco aren't always the best choices, but if you don't know about the others you won't know that (FWIW, Cisco and Unix are often excellent choices). Learn to program reasonably well in at least a script language. Learn TCP/IP. It's going to be around for a while. Focus on IPv4, but expose yourself to IPv6. This is probably the only specific protocol/technology I'll mention. Don't limit yourself to layer 3. Learn about things like how to terminate fiber optic cables and how application acceleration works. Make sure you can write and speak well. Learn when to shut up. (I probably still haven't learned that one) Learn how to get along with people, even ones that aren't as brilliant as yourself. Learn how to appropriately show accomplishment. You don't want to be arrogant, but you also don't want to be laid off because nobody knew that you did great things. Learn that people almost always have a reason for doing things the wrong way, and it's best to find out what it is before you fix it! This is probably controversial...Don't specialize religiously. What I mean about this is don't become a Cisco guy. Sure, you might become a Cisco expert, and that's fine. But don't lock yourself to a vendor or system type. Don't turn down a dream job that uses a different kind of router, server, workstation, etc, just because you like Cisco (or whoever) better. You won't want to use today's technology in a few years anyhow, so why make long-term decisions based on hardware/software used today? In the computer field, even giants have fallen. Learn that there is always someone smarter than you out there. Learn from them. You have to start somewhere. If you don't have good experience, you aren't going to start at a (insert nice salary here) senior position, no matter how much you know or what degree you have. You might have to start on the night shift of a NOC, making barely enough to eat, doing basic tasks. Even in a position like that, you can show you can learn - don't waste time while working in these jobs, spend your free time learning, not playing computer games or watching TV. You'll get noticed. Don't do illegal stuff. It'll limit your options. Pay your bills, don't do drugs, don't get picked up for drunk driving, don't beat your significant other. These are the things that disqualify people with even basic background checks - and many, many senior network jobs require a background check. Take opportunities. Consider jobs where you'll have to learn a bit to be effective - you might be the best person that applied. But don't expect to get jobs you aren't qualified for, and be honest about your abilities (but confident). Right now is a difficult time to get a job, even if you have terrific qualifications.
Re: best practices for management nets in IPv6
Public IPs. At some point you will have to manage something outside your current world or your organization will need to merge/partner/outsource/contract/etc with someone else's network and they might not be keen to route to your ULA space (and might not be more trustworthy than the internet at large anyhow). Think about things like VPN endpoints, video devices, telephones, etc, that may end up on a public network, maybe behind a device you manage. You may just manage routers today, but who knows about tomorrow. Put behind a firewall and use good ingress filtering throughout your network, separating trust zones with distinct subnets. If you are worried about forgetting to enable a firewall, put in a network management system to verify connectivity stays blocked combined with a monitored IDS.
Re: ICANN to allow commercial gTLDs
I wonder what sort of money .wpad would be worth...
Re: Question about migrating to IPv6 with multiple upstreams.
On Mon, Jun 13, 2011 at 6:59 PM, Randy Carpenter rcar...@network1.netwrote: This is precisely what we are doing on the main network. We just want to keep the general browsing traffic separated. If you're worried about browsing traffic and not worried about occasional other things slipping through, set up Squid and WPAD on your network. Direct all general internet stuff (via WPAD) out the cheap connection, the business-critical traffic through the other traffic. Now things that don't listen to the WPAD configuration (basically anything but PC and Mac browsers) will go out your expensive connection. But it sounds like a little bit of leakage wouldn't be a huge problem. You could get a bit fancier and run DNS on the proxy server, so that the proxy uses itself for DNS resolution rather than the corporate DNS. That would let you do basic browsing while the corporate WAN is down. The proxy would be the only box on the cable modem segment. It would also need an interface on some internal LAN segment. Default route on it would be via the cable modem, with routes to everything internal on the internal interface. Make sure you set the cable modem IP as Squid's outbound IP, and make sure your WPAD file doesn't use this proxy for anything internal. Everything else inside the network would have a default route pointing at the corporate WAN and wouldn't know anything about the cable segment. The nice thing about this setup is that you don't have any address translation going on and only one IP per host. You can replace Squid with the proxy of your choice, doing as much or as little caching as you want to do (and other things if desired, like virus scanning, deep packet inspection, or content filtering - if your policy requires it). Make sure you talk to your legal and/or HR about what logs should be kept or removed from the proxy. You may also want to repress X-Forwarded-For headers to keep your internal network addressing hidden while browsing. Also remember to make sure the proxy is secure enough to trust as a firewall for your corporation - or put it behind a firewall that is secure enough.
Re: user-relative names - was:[Re: Yahoo and IPv6]
On Tue, May 17, 2011 at 9:37 PM, valdis.kletni...@vt.edu wrote: Unless you end up behind a fascist firewall that actually checks that the EUI-64 half of the SLAAC address actually matches your MAC address - but we all know that firewalls are weak at IPv6 support, so probably nobody's actually doing that checking. :) Nevermind you can change your MAC address easily on most networks, since most don't provide any reasonable way of verifying that L2 packets are from where they claim to be. FWIW, Windows Vista and 7 default to using privacy addresses with SLAAC. Even without that, today, in the IPv4 NAT world, it's pretty much possible to uniquely identify a user nearly almost all of the time anyhow - at least for web access. This is thanks to browser fingerprinting - see https://panopticlick.eff.org/browser-uniqueness.pdf There's a lot of FUD about IPv6. Yes, the addresses are longer. But which is easier - remembering all the intermediate layers of network translation (likely two boxes for nearly every residential and small business user) or an IPv6 address that is the same, regardless of whether you are another customer on the same ISP, a public internet user, or an internal corporate user? Nevermind what it is like to debug IPSEC/PPTP/L2TP, SIP, or P2P protocols with just one NAT involved. Imagine doing that with two NAT devices (CGN + home NAT). If you haven't had that unfortunate pleasure, than I envy you! There's also no reason we should have to remember our IPv6 addresses. Seriously. There are about 50 protocols to name things on networks, many of which are scope aware. Among other things, it's why we don't typically have to remember MAC addresses - ARP works and it works well. Just because bad design forced us to remember IPv4 addresses doesn't mean our IPv6 networks should carry over that brokenness. IPv6 is also already in widespread use (I would guess all 500 of the Fortune 500 have it somewhere on their network, albeit quite likely not intentionally). I use it almost daily for my Apple MobileMe account (albeit typically tunneled over IPv4, all behind-the-scenes). I also use it when I stream music around my house (Bonjour will utilize IPv6, AirTunes typically uses it). Windows admins might be using it too (DirectAccess; MS Remote Assistance if firewalls block connectivity then Windows will set up a direct IPv6 link, tunneling through your firewalls and NAT...). And Grandma very well may be using it today (Windows Home Groups use IPv6). I would guess half of the family members of NANOG list subscribers are using IPv6 on a daily basis - TODAY. The danger is in ignoring what is already on your networks. Sure, you can't get to most websites via IPv6. But it's being used for plenty of useful work today, although mostly as a way around firewalls and as isolated islands (not connected to the global IPv6 network).
Re: Clearing DF bits...
On May 13, 2011, at 6:02 PM, Warren Kumari war...@kumari.net wrote: Years This was done both to deal with multiple encapsulations and for the folk that block all ICMP for security reasons. I did it as recently as last month, for the same reasons.
Re: IPv6 foot-dragging
Who sees the most AS's?
Re: Yahoo and IPv6
On Mon, May 9, 2011 at 3:57 PM, Jeff Wheeler j...@inconcepts.biz wrote: I do take issue with your suggestion that /64 LANs are in any way smart in the datacenter. They are not. I have some slides on this topic: http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf There are ways of mitigating this (the easiest is to use ACLs or firewalls to limit traffic into a subnet from untrusted sources so that only legitimate traffic is allowed). As for IPv6 in general, for other posters, I have a lot more concern about things like missing routes in routing tables, lack of residential IPv6 (one place where it would be *very* useful - think VoIP, P2P, etc), and lack of any good tunnel broker options. I've also had plenty of trouble getting IPv6 in data centers (4 different providers of caged data center space, none of which provided it, including one Tier 1 who advertised that all their business customers got free IPv6 with IPv4 transit from them; I guess they didn't think someone renting caged space and redundant ethernet in one of their data centers was a business customer, but I digress...) I'd settle for a good tunnel at this point. What do I mean by good tunnel option? The following: 1) Provider treats it like production, not as a tool for business leverage or a service only used for testing 2) Provider that has full routing table. A provider couldn't stay in business in the IPv4 world if they lacked connectivity to one or more default free networks. Yet in IPv6, it's the norm. 3) Provider that provides support for it - first through top level 4) Provider has redundancy at all levels 5) Provider makes it quick and simple to sign up, with rates posted on their website based on bandwidth desired (for residential and small business customers). I don't want to talk to a sales guy if I'm just setting up a tunnel for a DSL site! 6) Provider has an access location somewhere within, say, 1000 miles of my location. Ideally at a major exchange point in the metro. 7) Provider's network doesn't route me through Tokyo or Frankfurt to get from Denver to Chicago - regardless of who's network in Chicago I'm trying to connect to. This doesn't exist - it's wishful thinking. So this leaves native connectivity. Of course native connectivity is problematic, as it doesn't always come with full routing tables, isn't necessarily available on the circuit you have, and doesn't really give you all that much. That's assuming you can find it at all. After all, it's only been around for most of the time of the web.
Re: riverbed steelhead
On Thu, Apr 21, 2011 at 12:49 PM, harbor235 harbor...@gmail.com wrote: Anyone out there have experience with Riverbed Steelhead products? Do they improve TCP performance over WAN links? is it worth the price? I'll let others answer the specific question about Riverbed. I've heard plenty of good things about them though. (forgive me if this is extremely basic) If the problem is that someone downloading a big file slows the whole office down, there may be cheaper ways of solving this. Assuming your WAN links are private connections (not VPN over internet), I'd also suggest before spending money that you ensure you are doing some sort of fair queuing with RED/WRED enabled. This will ensure with on a network dominated by typical business TCP that one user can't monopolize a circuit. I'd also ensure that you are not sending bits faster than your provider will allow (beyond your burstable bit rate) by ensuring your bandwidth selections on your interfaces are set correctly. You might be able to fix your users' concerns/complaints just by a few lines of router config (and if you're using anything beyond home routers, your routers probably already support these things). In my experience, the problem isn't that the line is too small for the workload, but rather that bulk transfers keep everyone from doing work over it - that's where fair queuing and WRED come in. If you've already done this, than please ignore this suggestion. :) -- Joel Maslak