Fw: new message
Hey! New message, please read <http://internetmarketing.onnet.com.vn/knowing.php?ljhy> Sam Stickland
Re: Fwd: Interesting problems with using IPv6
Slightly off topic, but has there ever been a proposed protocol where hosts can register their L2/L3 binding with their connected switch (which could then propagate the binding to other switches in the Layer 2 domain)? Further discovery requests (e.g. ARP, ND) from other attached hosts could then all be directly replied, eliminating broadcast gratuitous arps. If the switches don't support the protocol they would default to flooding the discovery requests. It seems to me that so many network are caused because of the inability to change the host mechanisms. Sam On Mon, Sep 8, 2014 at 7:30 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Mon, Sep 8, 2014 at 1:28 PM, Barry Shein b...@world.std.com wrote: Reading the article what occurs to me is: IPv4 requires a certain amount of administrative personnel overhead. It's relatively low which is certainly one reason for the success of IPv4. People are expensive so any new, pervasive technology will be judged at least in part on its personnel requirements. I'd go so far as to say that administering large IPv4 networks grows in personnel roughly as the log of the number of nodes. surely this depends a LOT on the quality of the folk doing this job and their foresight in automating as much as possible, no? (probably this point isn't for debate, but the point is any network can be run badly) If what this is telling us, or warning us, is that IPv6 networks require higher personnel costs then that could become a big issue. is this a reflection of 'new technology' to the users (network folk) in question? What in ipv6 networking is inherently 'more people required' than ipv4 networking? Particularly among management where they've become used to a few to several people in a team running the heart of quite large networks. What if IPv6 deployment doubles or triples that personnel requirement for the same quality of administration? this sounds, to me, like: People need training or comfort with : instead of . in 'ip address' stuff... (and other similar differences between how v4 and v6 operate at scale) Does anyone know of any studies along these lines? My guess is that there isn't enough data yet. that sounds reasonable.
A spoof film about networking
Apologies for the off-topic post, but I thought some of you might get enjoyment out of this... After four and a half years and around 5,000 man hours we finally finished our feature film comedy about networking. If nothing else I think this must be the only film in existence that has eight CCIEs in the cast! I'll keep this brief. There's a two minute trailer here: http://www.youtube.com/watch?v=9t3B3hBXKCc And the full film (one hour long) is here: http://www.youtube.com/watch?v=07H0ci7-OMw We now return to your regular scheduled programming... Sam
Re: Post-Exhaustion-phase punishment for early adopters
On 9 Feb 2011, at 02:43, R. Benjamin Kessler ben.kess...@zenetra.com wrote: From: George Herbert [mailto:george.herb...@gmail.com] Let's just grab 2/8, it's not routed on the Internet... +1 I was consulting for a financial services firm in the late '90s that was acquired by a large east-coast bank; the bank's brilliant scheme was to renumber all new acquisitions *out* of RFC1918 space and into (at the time) bogon space. If I recall, some of the arguments were they were too big to fit into RFC1918 space and by having all of their divisions in non-RFC1918 space it would make it easier for them to acquire new companies who used RFC1918 space internally. You don't have to trawl back to the late 90's to find this, I know of at least 3 or 4 large enterprises using large chunks of public address (multiple /8's) that aren't their's /today/. This works because 1) the Internet is only accessed through proxies, 2) devices that require direct Internet access are addressed out of registered address space (or NATed to registered address space), and 3) third party connections to others enterprises are usually src/dst NATTed to the enterprise's own ranges (with the added benefit that this NAT at 3rd party boundaries helps ensure symmetric traffic flow through firewalls). And I've only worked at 3 or 4 large enterprises so it's probably safe to assume there's more! With my SP background I was shocked and I'm not trying to defend this practice, but in the enterprise land it seems accepted. Sam
Re: IPv6 addressing for core network
On 9 Feb 2011, at 09:48, sth...@nethelp.no wrote: Is there a NANOG FAQ we can add this to? 1- Use Public Ipv6 with /122 and do not advertise to Internet 2- Use Public Ipv6 with /127 and do not advertise to Internet The all zeros address is the all routers anycast address so on most non-Cisco routers you can't use it, ruling out /127. The top 128 addresses in any subnet are also reserved anycast addresses although they don't do much in practice. So the longest prefix length you should use is /120 and only use addresses 1 - 127. A /127 mask is still the best way to handle real point-to-point links like SDH/SONET today, to avoid the ping-pong problem. Works fine with Cisco and Juniper, not tried with other vendors. Can you elaborate on this? What's the ping-pong problem? Sam (who's experience is pretty much mostly ethernet)
Re: Post-Exhaustion-phase punishment for early adopters
I've worked in plenty of places where registered address was used on private interconnections between organisations to avoid overlaps, but never announced globally. S On 8 Feb 2011, at 14:35, gb10hkzo-na...@yahoo.co.uk wrote: Hint: even IPs not pingable from the Internet are being used. Not everyone is an ISP/Webhoster ... with public services. I thought that was why we have RFC1918 ?
Re: IPv6 - real vs theoretical problems
On Sat, Jan 8, 2011 at 2:00 AM, Dobbins, Roland rdobb...@arbor.net wrote: If it's inappropriately placed in front of servers, where's there's no state to inspect and were the stateful nature of the device in and of itself forms a DoS vector, it has negative security value; i.e., it makes things far worse. Roland, I'm missing something here. Why do you say there is zero state at the server, but the not at the client? (Because of all the servers TCP/UDP ports are well known perhaps?) Sam
Re: TCP congestion control and large router buffers
On 21 Dec 2010, at 07:18, Mikael Abrahamsson swm...@swm.pp.se wrote: On Mon, 20 Dec 2010, Jim Gettys wrote: Common knowledge among whom? I'm hardly a naive Internet user. Anyone actually looking into the matter. The Cisco fair-queue command was introduced in IOS 11.0 according to http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd1.html#wp1098249 to somewhat handle the problem. I have no idea when this was in time, but I guess early 90:ties? 200ms is good; but it is often up to multiple *seconds*. Resulting latencies on broadband gears are often horrific: see the netalyzr plots that I posted in my blog. See: I know of the problem, it's no news to me. You don't have to convince me. I've been using Cisco routers as a CPE because of this for a long time. Interestingly I've just tried to enable WRED on a Cisco 877 (advsecurity 15.1) and the random-detect commands are missing. Cisco's feature navigator says it's supported though. Weird. Also, there doesn't appear to be a way to enable fair-queue on the wireless interface. Is fair-queue seen as a bad strategy for wireless and it's varying throughput/goodput rates? And finally it doesn't support inbound shaping so I can't experience with trying to build the queues on it rather than the DSLAM. I'm a little nonplussed to be honest. However, I did notice the output queue on the dialler interface defaults to 1000 packets. (Perhaps that's a hangover from when it had to queue packets whilst dialling? I've come too late to networking to know). Reducing that number to 10 (~60ms @ 1500 bytes @ 8Mbps) has noticeably increased the latency response and fairness of the connection under load. Sam
Re: Usage-Based Billing for DIA
Jon Lewis wrote: On Thu, 5 Mar 2009, Rodriguez, Mauricio wrote: Looking at possibilities for an implementation of usage-based billing, it seems that the same techniques and tools always come up. I'm looking for some feedback from the list on experiences with these tools and techniques as well as alternatives that may not be listed here. +Techniques --Flow data (Netflow, SFlow, etc) analysis to determine 95th percentile traffic levels --SNMP polling of interface counters to determine 95th percentile traffic levels I need to look into this in the near future as well. The problems I'm aware of are: 1) we have customers on policed ports, and the interface snmp counters count packets before service-policy. It doesn't seem right to bill for packets we dropped :)...so this isn't useful data for billing purposes. Torrus (www.torrus.org) can use the Cisco MIBs to graph pre and post-policy packets. http://www.torrus.org/plugins/tp-cisco-cbqos.pod.html Sam
SNMP and syslog forwarders
Hi, It's looking like running all of our traps and syslog through a couple of relay devices (and then onwards to the various NMS's) would be quite a win for us. These relay devices just need to be dumb forwarders (we don't require any filtering or storing, just reflection), but we need an HA pair (across two sites) without creating duplicates. I have the coding skills to make this myself, but as coding skills come and go in our network team, we are looking for a commerical product so it will continnue to work after I get: hit by a bus / amnesia / visions of grandeur. Any recommendations / experience? This needs to scale to ~1,500 devices. Thanks, Sam
Re: can I ask mtu question
Ricky Beam wrote: On Fri, 30 Jan 2009 17:00:00 -0500, Saku Ytti saku+na...@ytti.fi wrote: Which standard are you referring to? AFAIK, nothing above 1500 is standardised None that have ever been accepted. From a quick google for manufacturer support, 9216 looks like the most popular number. But, as I said, it boils down to the largest frame *every* device on the LAN will accept. If there is a single device that only supports 9000, then that's your limit. And if there's a single non-JF device in the LAN, it throws a wrench into the whole thing. (This appears to be one of the sticking points as to why IEEE won't accept the addition of JF to any specs.) --Ricky PS: The topic pops up again with super-jumbo frames in 10G networks. For what it's worth, TCP will negiogate MSS and will work with mismatched MTU in a single LAN segment. Other protocols (e.g. UDP) will be borked though. S
Re: can I ask mtu question
Niels Bakker wrote: * sam_mailingli...@spacething.org (Sam Stickland) [Tue 03 Feb 2009, 13:04 CET]: For what it's worth, TCP will negiogate MSS and will work with mismatched MTU in a single LAN segment. No Machine 1 -- switch with 1500 byte MTU -- switch with smaller MTU -- switch with 1500 byte MTU -- machine 2 Same situation as when you have IP routers with smaller MTUs in the path that also do not send ICMP Fragmentation Needed errors (or those are dropped on the way to you) If you configure one of those machines with an MTU equal to or smaller than the smallest MTU in the path then yes TCP (assuming MSS option is used) won't send packets that happen to be too big, but again, same story as for routers vs on a LAN. The problem isn't that machine 1 and 2 in the above example disagree on MTU, the problem is that equipment in the path disagrees on the MTU and cannot (in the case of switches) send notifications of such, or those will not arrive (in the case of stupid firewall admins in control of networks). Sorry, I should had clarified. I meant mismatched host MTUs within a jumbo MTU supporting L2 domain. Sam
Re: Cisco uRPF failures
Jo Rhett wrote: That's the surprising thing -- no scenario. Very basic configuration. Enabling uRPF and then hitting it with a few gig of non-routable packets consistently caused the sup module to stop talking on the console, and various other problems to persist throughout the unit, ie no arp response. We were able to simulate this with two 2 pc's direction connected to a 6500 in a lab. If I remember right, we had to enable CEF to see the problem, but since CEF is a kitchen sink that dozens of other features require you simply couldn't disable it. Definately sounds like it could be a problem - I'd like to try and replicate this. What do you mean by non-routable traffic - traffic whose destination has no route (I assume you are running defaultless), or traffic that fails the uRPF check? And correct me if I'm wrong but I thought you can't disable CEF on the 6500 platform? hs-6513-1#conf t Enter configuration commands, one per line. End with CNTL/Z. hs-6513-1(config)#no ip cef % Incomplete command. hs-6513-1(config)#no ip cef ? accounting Enable CEF accounting distributed Distributed Cisco Express Forwarding event-log CEF event log commands interface CEF linecard commands linecardCEF linecard commands load-sharingLoad sharing nsf Set CEF non-stop forwarding (NSF) characteristics table Set CEF forwarding table characteristics traffic-statistics Enable collection of traffic statistics hs-6513-1(config)#no ip cef distributed %Cannot disable CEF on this platform hs-6513-1(config)#exit hs-6513-1#sh version | inc IOS IOS (tm) s72033_rp Software (s72033_rp-ADVENTERPRISEK9_WAN-M), Version 12.2(18)SXF11, RELEASE SOFTWARE (fc1) Sam
Re: Revealed: The Internet's well known BGP behavior
Jon Lewis wrote: Do you utilize the IRR, have an as-set, and put all customer AS/CIDR's into the IRR? I've honestly never heard from LVL3 about our advertisements. Other providers have varied from just needing a web form, email, phone call, or those combined with faxed LOAs. The latter gets very annoying...but maybe it is the way it should be. Level3 pull information from a number of sources, including RIPE where we register our routes. One of the nice things about their setup is you can query a whois interface to check the filter generation: e.g. (to pick someone else's AS-MACRO at random) whois -h filtergen.level3.net RIPE::AS-DEMON Sam
Re: It's Ars Tech's turn to bang the IPv4 exhaustion drum
Randy Bush wrote: and consider matsuzaki-san's dos vulnerability on a /64 p2p link. the prudent operational advice today is to use a /127. randy Can you provide some more information on this vulnerability? My google-fu appears to be weak. Sam
Re: IP Fragmentation
Iljitsch van Beijnum wrote: On 20 aug 2008, at 20:04, [EMAIL PROTECTED] wrote: Hypothetically true. Unfortunately, enough places do bozo firewalling and drop the ICMP Frag Needed packets to severely limit the utility of PMTU Discovery. Yet all OSes have it enabled and there is no fallback to fragmentation in PMTUD: if your system doesn't get the ICMP messages, your session is dead in the water. Windows Vista/2007 has black hole detection enabled by default. It's not massively elegant, but it will keep sessions up (falls back to 536 byte MTU). http://support.microsoft.com/kb/925280 Sam
Re: Is it time to abandon bogon prefix filters?
Skywing wrote: Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) Use a prefix list of existing bogons against the Team Cymru BGP feed. If they are hacked this limits the possible attacks to the following bounds: 1) They advertise no address space, and you end up with no bogon filtering. 2) They advertise all of the IPv4 address space, but your prefix list limits this to (an admittedly out-of-date) list of bogons. Sam
Re: Hardware capture platforms
Lynda wrote: Warren Kumari wrote: What I am looking for is: Small enough to live in my notebook bag (e.g.: 4 port with a wall wart.) Cheap Simple 10/100/1000Mbps I don't believe that such a thing ever existed. Hubs that did 10/100, certainly, but I've never ever seen a hub that did gig speeds. Depends what you mean by 'hub' I guess. I thought the term referred to a device that was half-duplex only, and had no address learning. GE has never supported half-duplex. Sam
Re: Analysing traces for performance bottlenecks
Matt Cable wrote: Kevin Oberman oberman at es.net writes tcptrace is old and pretty basic, but it can provide a LOT if information. Combined with xplot, the graphs often point to the exact nature of a TCP problem, but you need a really good understanding of TCP to figure anything out. Wireshark also provides tcptrace-like graphs (Statistics - TCP Stream Graph - Time Sequence Graph (tcptrace)). They're not quite as pretty, but are just as effective at tracking down all sorts of TCP problems, provided, as Kevin said, you have a really good understanding of how TCP behaves Thanks for all the replies so far. While the TCP graphs are useful they are very difficult to read in Wireshark - they really need to be displayed in xplot, but this requires an X11 setup? I've found NDT: http://e2epi.internet2.edu/ndt/ This uses a java applet hosted on a web100 patched linux server to record network diagnostics from connecting clients. A typical report might look like this: Web100 reports the Round trip time = 122.15 msec; the Packet size = 1260 Bytes; and No packet loss was observed. C2S throughput test: Packet queuing detected: 1.09% S2C throughput test: Packet queuing detected: 1.32% This connection is receiver limited 84.33% of the time. Increasing the the client's receive buffer (63.0 KB) will improve performance This connection is sender limited 1.70% of the time. Increasing the NDT server's send buffer (127.0 KB) will improve performance This connection is network limited 13.96% of the time. The theoretical network limit is 7869.69 Mbps The NDT server has a 127.0 KByte buffer which limits the throughput to 16.37 Mbps Your PC/Workstation has a 63.0 KByte buffer which limits the throughput to 4.09 Mbps The network based flow control limits the throughput to 8.73 Mbps Client Data reports link is 'OC-48', Client Acks report link is 'OC-12' Server Data reports link is 'OC-48', Server Acks report link is 'T3' Something that could provide a similar, automated analysis of a TCP stream capture is what I'm after, although I doubt a standard packet capture will be able to provided as many metric as web100 stack can. Sam
Analysing traces for performance bottlenecks
Hi, Are there any packages (or Wireshark options that I've missed) that can follow a TCP stream and determine the limiting factor on throughput. E.g Latency, packet loss, out of sequence packets, window size, or even just the senders rate onto the wire. I know how to analyse a trace by hand for performance issues, but it's relatively time consuming. Googling for variations on Analyse TCP stream limit throughput didn't find anything. Sam
Re: Analysing traces for performance bottlenecks
A bit more googling has found the Web100 projects NDT (http://e2epi.internet2.edu/ndt/). I'm currently making a Linux VM that can run it. It's useful, but I'm still really after something that can do it's type of analysis from a packet capture. Sam Sam Stickland wrote: Hi, Are there any packages (or Wireshark options that I've missed) that can follow a TCP stream and determine the limiting factor on throughput. E.g Latency, packet loss, out of sequence packets, window size, or even just the senders rate onto the wire. I know how to analyse a trace by hand for performance issues, but it's relatively time consuming. Googling for variations on Analyse TCP stream limit throughput didn't find anything. Sam
Re: [Nanog-futures] Announce list: Re: Hughes Network
Joe Abley wrote: On 22 May 2008, at 23:16, James R. Cutler wrote: The announcement was made to nanog-announce, but not to nanog. I would expect that there are scads more readers of nanog than of nanog announce. When I was sending things to nanog-announce, it was the case that mail to nanog-announce was sent to people who had specifically subscribed to that list, plus anybody who hadn't but who was subscribed to nanog (in other words, it was sent to the union of both lists). That might have changed since the transition to mailman. It seemed like a useful approach, though. Kinda makes you wonder what the purpose on the announce list is though. Are there actually people subscribed to nanog-annouce that aren't subscribed to nanog? Sam
Re: 24x7 Support Strategies
All, Thanks for the replies that have started rolling in. They've made me realise I should have added an additional question for clarity. Does anyone have any CCIE (or equivalent technical ability) staff on a 24x7 shift? What about CCIE level staff on an on-call rota with a garanteed response time? How about CCNP? If people could also give an identication of the size of their organisation/network it would be useful. Sam Sam Stickland wrote: Hi, I'm wondering how different organisations structure their 24x7 network operations? We are undergoing some restructuring here and it would be interesting for us to know how other large enterprises and service providers arrange this. We are particulary interested in service providers. (Currently we have an enterprise that is slowly morphing into more of a service provider setup). I'll summarise back to the list, after removing any identifying details. These questions specifically refer to network staff, as opposed to any general Ops team. Do you have 24x7 staff on site? What level of technical ability do the on-site staff have? What shift patterns do the 24x7 staff use? Do you have a response time for on-call staff, by which time they must be VPN'ed into the network? What level of techincal ability do the first line on-call staff have? Do you have an official escalation system if the first-line on-call staff do not have the required techincal ability? Do the staff on on-call escalation have a required response time, by which time they must be VPN'ed into the network? Do the staff on on-call escalation rota the on-call responsibilities? Do the on-call staff receive additional benefits or compensation for being on-call?
Re: 24x7 Support Strategies
Joe Abley wrote: On 14-Jun-2007, at 02:32, Sam Stickland wrote: Does anyone have any CCIE (or equivalent technical ability) staff on a 24x7 shift? What about CCIE level staff on an on-call rota with a garanteed response time? How about CCNP? Does anybody actually put any stock in the presence or absence of vendor certifications on a resume when judging the capabilities of an engineer? There's no correlation between certification and capability, in my experience. I fully agree with you Joe, but I needed to quantify the level of technical expertise somehow. I think most people have some kind of a feel for what level we are talking about if we say equivalent techincal ability to CCIE, even if there are CCIEs out there who are useless ;) S
Re: 24x7 Support Strategies
People are asking me to port a summary back to the list, but as I'm still getting replies coming in I'm going to leave this until tomorrow. S Sam Stickland wrote: All, Thanks for the replies that have started rolling in. They've made me realise I should have added an additional question for clarity. Does anyone have any CCIE (or equivalent technical ability) staff on a 24x7 shift? What about CCIE level staff on an on-call rota with a garanteed response time? How about CCNP? If people could also give an identication of the size of their organisation/network it would be useful. Sam Sam Stickland wrote: Hi, I'm wondering how different organisations structure their 24x7 network operations? We are undergoing some restructuring here and it would be interesting for us to know how other large enterprises and service providers arrange this. We are particulary interested in service providers. (Currently we have an enterprise that is slowly morphing into more of a service provider setup). I'll summarise back to the list, after removing any identifying details. These questions specifically refer to network staff, as opposed to any general Ops team. Do you have 24x7 staff on site? What level of technical ability do the on-site staff have? What shift patterns do the 24x7 staff use? Do you have a response time for on-call staff, by which time they must be VPN'ed into the network? What level of techincal ability do the first line on-call staff have? Do you have an official escalation system if the first-line on-call staff do not have the required techincal ability? Do the staff on on-call escalation have a required response time, by which time they must be VPN'ed into the network? Do the staff on on-call escalation rota the on-call responsibilities? Do the on-call staff receive additional benefits or compensation for being on-call?
24x7 Support Strategies
Hi, I'm wondering how different organisations structure their 24x7 network operations? We are undergoing some restructuring here and it would be interesting for us to know how other large enterprises and service providers arrange this. We are particulary interested in service providers. (Currently we have an enterprise that is slowly morphing into more of a service provider setup). I'll summarise back to the list, after removing any identifying details. These questions specifically refer to network staff, as opposed to any general Ops team. Do you have 24x7 staff on site? What level of technical ability do the on-site staff have? What shift patterns do the 24x7 staff use? Do you have a response time for on-call staff, by which time they must be VPN'ed into the network? What level of techincal ability do the first line on-call staff have? Do you have an official escalation system if the first-line on-call staff do not have the required techincal ability? Do the staff on on-call escalation have a required response time, by which time they must be VPN'ed into the network? Do the staff on on-call escalation rota the on-call responsibilities? Do the on-call staff receive additional benefits or compensation for being on-call?
Re: Security gain from NAT (was: Re: Cool IPv6 Stuff)
Nathan Ward wrote: On 5/06/2007, at 9:29 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I posit that a screen door does not provide any security. Any is too strong a word. For people living in an area with malaria-carrying mosquitoes, that screen door may be more important for security than a solid steel door with a deadbolt. It all depends on what the risks are, what you are protecting, and where your priorities are. It is rather odd to see this discussion just a few weeks after the IETF issued RFC 4864 to address just this misconception of NAT. How many of the participants have read the RFC? Assuming vendors of cheap consumer IPv6 gateway boxes implement all the LNP (Local Network Protection) features of RFC 4864, is there any reason for these boxes to also support NAT? As far as I can see the only good reason to put NAT in an IPv6 gateway is because uneducated consumers demand it as a checklist feature. In that case, let's hope that it is off by default and that disabling the NAT does not disrupt any of the other LNP features. That way, when the customer calls the support desk to complain that they are not getting SIP calls from Mom, you can tell them to turn off the NAT and try again. Precisely. I don't think anyone is suggesting that you should put NAPT in an IPv6 gateway. A few days ago it was suggested by Sam Stickland that a blocker to moving to IPv6 was the lack of NAPT, and the security features that are an integral part of it's functionality. This thread has been done to death now, but what I originally said was that the use of NAT in IPv4 means that many enterprises don't feel any pressure to move to IPv6, and that furthermore there are many myths and weird design tactics in use that make people (incorrectly) think they need NAT for reasons above and beyond public address conversation. I also expressed a concerned that because of this some nefarious vendors will start selling IPv6 NAT boxes (again, not a good thing!). Time will tell, but I think it's time the thread I seem to have spawned dies ;) S S
Re: Security gain from NAT
Joe Abley wrote: On 4-Jun-2007, at 14:32, Jim Shankland wrote: Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box? Perhaps you should run a corresponding experiment whereby you set up a linux box with a globally-unique address, put it behind a firewall which blocks all incoming traffic to that box, and issue a similar invitation. Do you think the results will be different? I fear a somewhat more cynical person could interpret the results of such an experiment to mean that NAT is as good as a firewall ;) S
