Re: OpenFlow, please don't start a flame war...
On 12/14/2012 11:11 PM, eric-l...@truenet.com wrote: It's been about 2 years in since I've heard about the concept, and honestly I'm about ready to jump into test environments at my house. My questions are pretty basic, what distro would you recommend for a controller, and should I start by virtualizing in VMWare or HyperV or jump into some cheap Linksys WRT routers. The more I hear about the tech from colleges, Google, BigSwitch, etc is leaning me to really start learning, so any help would appreciated. OpenFlow is a big arena. Do you know what you want to do with it? If you're looking to write your own intelligence, I recommend the OpenFlow tutorial at http://www.openflow.org/wk/index.php/OpenFlow_Tutorial . It helps you get started in a virtual environment, and introduces you to a number of controller platforms. -Dave
Re: Whacky Weekend: Is Internet Access a Human Right?
On 1/5/2012 11:29 AM, Leo Bicknell wrote: In a message written on Thu, Jan 05, 2012 at 11:09:59AM -0500, Jay Ashworth wrote: Didn't *say* broadband. Didn't even say Internet service. Said Internet *access*, in the non-techspeak meaning of those words. For the purposes of my e-mail and this point in time, they are all synonymous. That is, if interenet access is a right, providing someone a 9600bps dial up does not, in my mind, qualify. That might qualify for e-mail access, but you can not use a reasonable fraction of the Internet at that access speed. Similarly, denying someone internet service denies them internet access. The only difference between your terms and mine, is that mine are fixed to this point in time while yours is a general concept that may move in the future. One day 50Mbps broadband may not qualify anymore as internet access due to where the interernet ends up. I think you're still thinking of service, as opposed to access. Public terminals, say at libraries, are also access. Free public wifi is also access. But let's take a specific (famous) example. Kevin Mitnick. From his wikipedia page: During his supervised release, which ended on January 21, 2003, he was initially forbidden to use any communications technology other than a landline telephone. If Internet access (to use your term) had been a human right than his human rights were violated by the government when they banned him from using any communications technology. Do we really want to suggest that banning him from using the computer is the same level of violation as enslaving him, torturing him, or even killing him? Clearly not, at least at this point in history. Internet access is more like access to transportation; the law implicitly requires you to have it (in the form of being able to compel a person to appear at a given place and time), but not only fails to mandate its availability, but includes provisions for explicitly denying access to it in some cases. Internet access becomes a human right only when your other, more basic human rights depend on it. If a person without internet access cannot obtain food, shelter, or basic transportation, then it is a human right. As an aside, your example is flawed, because judicial punishment does involve a loss, or at least a curtailment, of what many people consider to be basic rights. -Dave
Re: incoming smtp from v6 addresses
On 1/4/2012 10:46 AM, Mike Tancsa wrote: I suspect the higher inbound values might be due to tech mailling lists which tend to come from IPv6 enabled hosts ? Yeah, all of my (non-internal) ipv6 mail is from such mailing lists. -Dave
Re: quietly....
On 2/2/2011 10:52 AM, Iljitsch van Beijnum wrote: No, the point is that DNS resolvers in different places all use the same addresses. So at the cyber cafe 3003::3003 is the cyber cafe DNS but at the airport 3003::3003 is the airport DNS. (Or in both cases, if they don't run a DNS server, one operated by their ISP.) I understand people use DHCP for lots of stuff today. But that's mainly because DHCP is there, not because it's the best possible way to get that particular job done. So what if I want to assign different people to different resolvers by policy? What if I want to use non-/64 subnets with a resolver on each one? What if I round-robin amongst more or less resolvers than there are well-known addresses assigned to? What if, in 1/2/5/10/20/50 years, we need to do things differently? Why intentionally burden a protocol with something that screams I am going to be a depreciated legacy problem someday! -Dave
Re: quietly....
On 2/2/2011 5:42 PM, Brian Johnson wrote: I must have missed something. Why would u do NAT in IPv6? 1) To allow yourself to change or maintain multiple upstreams without renumbering. 2) To allow your IPv6-only hosts to reach IPv4 addresses, or vice versa. 3) To give all your outbound sessions a mutual appearance, so as to confound those attempting to build a profile of your activity. 4) To irritate the IPv6 faithful. 5) Because it is funny. 6) Because you have allocated a single address to a machine that later on actually represents n differerent actual network entities, and retrofitting them with their own unique IPv6 subnet presents a problem. 7) Because Iljitch bet you you couldn't, and you don't want to lose a bet. 8) Because chicks/dudes think it's hot. 9) Because you can. 10) Because it is the year 8585, and we're running low on IPv6 addresses.
Re: quietly....
On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 16:21, Jack Bates wrote: I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet. -Dave
Re: quietly....
On 2/1/2011 3:10 PM, Randy Carpenter wrote: - Original Message - On 2/1/2011 2:57 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 16:21, Jack Bates wrote: I still know a LOT of people who have no desire to switch. They are holding out until vendors implement the features they want. NAPTv6, default router in DHCPv6, etc, etc. What's the point of switching to IPv6 if it repeats all the IPv4 mistakes only with bigger addresses? Bigger addresses. People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. Telling them they have to do it your way because their way is stupid is just going to keep them from changing and increases a chance of a NATernet. -Dave So, we should just have no rules or standards at all, and just let people do whatever they want. How well would that work? We should, and do, have rules and standards for how networks communicate with each other. We can, and should, publish advice on how a network can be built to work properly, internally and externally. We should not say, you must run your internals the way we think a network should be run internally. Every network operator's network is their concern, and making it work is their responsibility. If they want to use DHCPv6, or NAT, or Packet over Avian Carrier to achieve that, let them. If using them causes them problems, then they should not use them. It really isn't the community's place to force people not to use tools they find useful because we do not like them. -Dave
Re: quietly....
On 2/1/2011 3:32 PM, Iljitsch van Beijnum wrote: On 1 feb 2011, at 21:03, Dave Israel wrote: People want to engineer their networks they way they want to. Let them. If their way is stupid, then they'll have the stupidly engineered network they wanted. The problem is that their stupidity impacts ME. If I want to talk to Microsoft from behind a 1500 byte MTU link: too bad, not going to happen. They stupidly send packets with DF=1 but filter incoming packet too big messages. So I'm all in favor of the IETF blocking stupidity whenever possible. I completely agree that, when interoperating, you have to follow the rules, and I would (naively) hope that customers cannot reach me because of my configuration choice is sufficient incentive to fix the problem for the majority of network operators. But what I am arguing against was the stance some people take against DHCPv6, or prefix lengths longer than /64, or other internal-to-my-network, why-should-you-care choices I might make. Telling me it is dumb is fine; implementing software/hardware/protocols such that I can't do it simply because you think it is dumb is a problem. -Dave
Re: quietly....
On 2/1/2011 9:33 PM, Owen DeLong wrote: On Feb 1, 2011, at 6:24 PM, Chris Adams wrote: Once upon a time, Owen DeLongo...@delong.com said: On Feb 1, 2011, at 3:41 PM, Karl Auer wrote: Devil's advocate hat on: NAT (in its most common form) also permits internal addressing to be independent of external addressing. Which is a bug, not a feature. That is an opinion (and not a unversally held opinion), not a fact. I tend to agree with you, but you keep stating your opinion as fact. Telling people I'm right, you're wrong over and over again leads to them going away and ignoring IPv6. Using this definition of bug from Wikipedia: A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways. I argue that breaking the end-to-end model which is a documented fundamental tenant of the internet protocol and the internet addressing system is, by definition, within the definition above. Q.E.D. it is, in fact, a bug, not merely my opinion. Others are welcome to consider said bug to be a feature, but, it is, by definition, factually, a bug. I apologize in advance for the strong wording, and will apologize for it in person (with a beer) at some point. But: A NATed client connects to a server, and they speak end to end. A NATed server receives connections directly from clients. It is more or less end to end, communications-wise, and so it is the same or less of a bug, by your definition, than a proxy server, or a web cache, or ipv4 anycast DNS, or inspecting/fixup capable firewalls. And those are all things people want. If you are advocating that IPv6 should not be capable of performing tasks people want it to perform, then you are advocating for IPv6 to follow the path of the OSI protocols as a could have been the new Internet protocol, and you are pushing the world toward the NATernet, and you are actually, unintentionally, one of IPv6's worst enemies. Look back across all the big arguments over the years that had people turning purple and calling each other names and declaring that IPv6 was broken. They are all about features in IPv6 that operators did not want, because directly or indirectly, they either disabled features people use now, or they told people how hey had to build their networks. They were features dreamed up by academics, theoreticians, and purists, and opposed by operators. You can blame sloth, ignorance, and heads in the sand all you want for the long wait for IPv6 adoption, but the insistence by IPv6 evangelists that IPv4-think is necessarily evil and that they are going to force everybody to conform to their perfect paradigm is also a big factor. And this isn't just a perception issue, or rebellion at being told what to do. Part of what made IPv4 so successful was that its simplicity made it inherently flexible, and even operators who are wrong about what things like NAT give them are right to rebel against restricting flexibility to meet certain people's perception of what network purity means today. -Dave
Re: Did your BGP crash today?
On 8/27/2010 3:22 PM, Jared Mauch wrote: When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the missing-2-bytes) vs just getting garbage. Perhaps there should be some way to re-sync when you are having this problem, or a parallel keepalive path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening. I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session. -Dave
Re: the alleged evils of NAT, was Rate of growth on IPv6 not fast enough?
On 4/27/2010 1:36 PM, Andy Davidson wrote: On Tue, Apr 20, 2010 at 11:29:59AM -0400, John R. Levine wrote: Did you use Yahoo IM, AIM, or Skype? Yes, yes, and yes. Works fine. What about every other service/protocol that users use today, and might be invented tomorrow ? Do will they all work with NAT ? Sure, I can invent a service/protocol that doesn't work with NAT. While I am at it, I'll make it not work with IPv4, IPv6, Ethernet, an architectures using less than 256 bits of memory addressing. I bet it'll be popular! Do many others work as well or act reliably through NAT ? Yes, nearly everything that end users use works great through NAT, because end users are often behind NAT and for a service to be popular, it has to be NAT-friendly. Protocols that are not NAT friendly and yet survive are generally LAN applications that are resting on their NAT-unferiendliness and calling it security. Will it stop or hamper the innovation of new services on the internet ? Nope. The answer to these questions isn't a good one for users, so as the community that are best placed to defend service quality and innovation by preserving the end to end principal, it is our responsibility to defend it to the best of our ability. The end to end principle only helps service quality and innovation when the services are built on an end to end model. In a client-server world where addresses only identify groups of endpoints and individual identification is done at higher layers (which is what the ipv4+NAT Internet is looking like), end to endness is an anomaly, not the norm. So get busy - v6 awareness, availability and abundancy are overdue for our end users. Nearly all of the end users don't give a rat's hindquarters about ipv6. It gives them nothing they know that they want. Meanwhile, those who do know they want it are getting used to working around it, using PAT tricks and STUN services. Should people *have* to use those services? No. But there's so many other things that we shouldn't have to do, but we do anyway because that's how it works, that these NAT-circumvention tricks are not a dealbreaker. Meanwhile, the NATification of the Internet continuously increases the contrast between services (with real addresses) and clients (with shared addresses). Over time, this differentiation will increase and become more and more a standard (a de facto one if not an actual codified one.) Clients will have shared, ephemeral addresses, and services will have stable ones. This helps ensure that clients cannot generally communicate without a facilitating service, and every transaction will then have a middleman, somebody you have to pay somehow to get your services. You may pay in cash, by watching commercials, by sacrificing personal information, or by submitting your communciations to analysis by others, but somehow, you will pay. The vast majority of users won't care; they communicate that way now, and it does not bother them much. It's only those few who want to communicate without paying, in time, money, or privacy, or to communicate in ways other than the standard protocols, who will really suffer. And their complaints will have to fight against the voice of those who will say, well, if you make it end to end, then businesses lose money, and people will be able to share files again and violate copyrights, and all these things will cost jobs and tax dollars, etc, etc. If you want to avoid that future, I strongly suggest you deploy ipv6 and pressure others to do the same. But you're going to need to use valid arguments, about privacy and protection from the deprecations of unscrupulous middlemen, instead of insisting that the Internet will break down and die and locusts will descend from the heavens and eat our first born if we don't. -Dave
Re: ARIN IP6 policy for those with legacy IP4 Space
On 4/9/2010 12:30 PM, Owen DeLong wrote: Put differently, you work in this arena too... you've presumably talked to stakeholders. Can you list some of the reasons people have provided for not adopting v6, and are any of them related to the v6 policies regarding address space? Reasons: (many excellent reasons removed) Let me just add on: +Bonus Fear: Because IPv6 deployments are small and vendors are still ironing out software, there's concern that deploying it in a production network could cause issues. (Whether or not this fear is legitimate with vendor x, y, or z isn't the issue. The fear exists.) +Bonus Uncertainty: There is a lack of consensus on how IPv6 is to be deployed. For example, look at the ongoing debates on point to point network sizes and the /64 network boundary in general. There's also no tangible benefit to deploying IPv6 right now, and the tangible danger that your v6 deployment will just have to be redone because there's some flaw in the current v6 protocol or best practices that will be uncovered. +Bonus Doubt: Because we've been told that IPv4 will be dead in 2 years for the last 20 years, and that IPv6 will be deployed and a way of life in 2 years for the past 10, nobody really believes it anymore. There's been an ongoing chant of wolf for so long, many people won't believe it until things are much, much worse. -Dave
Re: IP4 Space
On 3/26/2010 1:31 PM, Owen DeLong wrote: On Mar 26, 2010, at 8:57 AM, Lamar Owen wrote: You should ask your server guy how he plans to talk to your core stakeholders when they can't get IPv4 any more. Then, at that time, both he and his key stakeholders will experience pain while they both deploy IPv6, or more likely, his key stakeholders will add another level of NAT-like indirection to give themselves space to expand with the address pool they have. At the CxO level, it's all about the money. Or the lack therof. How much less money will you have when donors can not reach your website or have a poor user experience doing so? This assumption is incorrect. They can't keep nursing IPv4 forever. Eventually everybody will have to switch to v6. If you don't, you'll be sorry. Just wait and see. That attitude did not force any previous supposed IPv4-killer protocol to be deployed. The fact is, for the foreseeable future, his donors will tend to have a better experience over v4 than v6. He isn't going to be blindsided by the need to deploy v6, and he knows it. By the time an important v4 host is not reachable via the entire internet (and at full speed), v6 will have been everywhere for years. An address space crisis will not result in v6 deployment from repentant network engineers who did not see the light in time. An address space crisis will merely result in more hacks to keep v4 running longer. v6 will be deployed slowly by the curious, encouraged by features v6 has that they want and with the assumption that they will still be able to do everything they can do on v4 (either through translation or dual stacking.) This process can be accelerated by something that v6 can do that v4 can't. So far, there's nothing that fits that description; everything being done over v6 can also be done over v4.
Re: more news from Google
Joe Abley wrote: On 2010-01-13, at 11:31, Anthony Uk wrote: The ability to automatically discern users' political positions from their inbox is not one that any email provider reasonably needs. It's arguably something that gmail users consent to when they give Google rights to index and process their mail, though. Or... Maybe account X is attacked, and it is registered to somebody named Liu Xiaobo, and Liu Xiaobo turns out to be a prominent human rights activist. After some investigation, it turns out accounts belonging to people whose names match known human rights activists were attacked and those that don't, weren't. Sure, assuming Google is being Sinister Santa Claus (brings gifts ostensibly from the goodness of their hearts, but mysteriously knows what you want, knows when you've been sleeping, knows when you're awake, etc) through data mining makes a good story, but it isn't the obvious conclusion.
Re: Revisiting the Aviation Safety vs. Networking discussion
I _do_ create action plans and _do_ quarterback each step and _do_ slap down any attempt to deviate. imagine a network engineering culture where the concept of 'attempt to deviate' just does not occur. Are you trying to suggest that this is something horrible, or that it's the future of network engineering? :) I'm actually serious in asking the question, despite the grin. Possibly, he is trying to hint at a connection with Nazis, so somebody will mention it, invoking Godwin's Law, and bringing a fruitless religious thread to a close. There's a full range of methods, with just do it on one side, deviation is terms for dismissal on the other, and plenty of shades of gray in between. I've seen both extremes result in excessive downtime. (How impromptu engineering can go wrong shouldn't take much imagination; the no deviation rule is especially hysterical when the backout plan doesn't work, but even without that, the one thing didn't work exactly right, back it out and try again in two weeks effect is destructive to both progress and morale.) Working with the dynamic and quality of the team is more important than any change management paradigm. -Dave
Re: small site multi-homing (related to: Small guys with BGP issues)
Clue Store wrote: Well you and the rest of these so called dreamers can help with the purchase of my new routers that don't exist yet to support you wanting to multi-home a /29 and have the rest of the Internet world hold all of these said /29's in their tables. Most folks who get a /29's don't care how they get to and from the internet, they just want to always be able to get there. TE at that granular of a level is not needed. So in other words, you and the rest of the world of these dreamers can keep dreaming, because I doubt any sensible ISP would accept and pass along anyone announcing /29's and then there's V6, which I won't even get started on. Most ISP's are having a hard time holding 300k ipv4 routes as of today, and you want to de-aggregate even farther?? It's clear that you have some impatience with deaggregation, and with cause. However, there are a few flaws in your position. The first is that you contradicted yourself. If most folks who get a /29 don't care how they get to and from the Internet, then there won't be a flood of new /29s. It is the minority who do care how they get to and from the Internet who will be adding routes. Currently, they are doing so by getting more address space than they need assigned, so as to have a block large enough to be heard. If 500 companies are currently announcing /24s to be heard, but could be moved to /29s, then you still have 500 route announcements. You just have a lot less waste. The second is that you said BGP. Mike didn't say BGP. He said he was dreaming of the future. That future coudl easily include a lightweight multihoming protocol, something that informs interested parties of presence on multiple networks, or allows for extremely fast reconvergence, so that a second route need only join the routing table when needed. And he's right; if I want to change my name to Joe, grab a sixpack, build a rack in my kitchen, and pay two providers for service, it isn't unreasonable to want an infrastructure that supports my configuration. We shouldn't dismiss a dreamer's dream because it is hard, or we can't do it right now with what we have. The desire to do what is not currently possible is the source of innovation, and we shouldn't shoot down innovation because it sounds hard and we don't like it. -Dave
Re: small site multi-homing (related to: Small guys with BGP issues)
Clue Store wrote: I think you're missing my point and did not read my post completely. First off, BGP was never mentioned in my post. Oops, you are correct. Somebody else said BGP. You spoke of the existing table, and so I had BGP in my mind, and I muddled the two together. Mea culpa. If I accept a /29 for the minority and pass that prefix along to the next provider, I have to accept it for the majority and pass them along to the next provider. And these 500 company's you speak about, the other blocks given back to insert RIR or LIR here would be hashed back out which WOULD still increase prefixes in the global table as they want to advertise their /29's. I agree that it would save v4 space right now for those who wouldn't announce the remainder /29's, but you're thinking short term as we all know that v4 space has out-welcomed it's stay (thank you NAT). Yes, it will run paraellel for 3, 5, maybe 7 years until enough folks get a clue and make the switch to v6, but in the end, v4 will go away. That assumes that there isn't a solution that requires constant presence in the global table, instead of a tell-me-about-this-prefix-when-I-need-it-and-not-before method. I admit that there hasn't been a good solution to the problem yet, but that doesn't mean there isn't one. I'm not sure it has been seriously researched in recent years. Having all that said, I am not knocking the 'dreamers' out there one bit. I encourage new ideas to help solve issues that we've discussed in this very thread. But at this point, there's more dreaming than solutions and revenue. And de-aggreation is one of the biggest problems with global routing today. Add v6 and the possibility of /48's being permitted into the global table, and most folks with a router from any vendor today couldn't support a full global table. No, but providers having to upgrade software or hardware to support the needs of the network in 3, 5, or 7 years isn't anything new, and neither is router vendors coming up with incremental software or hardware upgrades to make boxes do what they can't do now. -Dave
Re: Fwd: Dan Kaminsky
Paul Vixie wrote: digital security is getting a lot of investor attention right now. i wonder if this will ever consolidate or if pandora's box is just broken for all time. It'll consolidate to the point where probabilities and probably costs can be accurately assessed, at which point it can be insured, and that's where it'll level off.
Re: AH or ESP
Tony Hain wrote: Merike Kaeo wrote: ... ESP-Null came about when folks realized AH could not traverse NATs. Thus the absolute reason why people should promote AH to kill off the 66nat nonsense. Just because you can't use it for IPv4 is no reason to avoid using it for IPv6 now and let its momentum suppress the 66CGN walled garden mindset. That should make for a fascinating discussion. You should use AH. Why? So you can't use NAT. Any other reason? ... No. Great. I'll get right on that. The delusion that network operators can successfully use unhelpful protocols and/or smoke and mirrors to force idealist network design on others needs to end. People use new protocols because they are better. If the benefit of moving to a new protocol does not outweigh the pain of moving to it, people don't use it. That's why the OSI protocols did not kill IP like they were supposed to in the 90s, it is why the largely forgotten mandated move from Windows to secure OSes (ie, Unix) for all government employees never happened, and it is why IPv6 is sputtering. If people want to use NAT, they are going to use NAT. They may stop using it if the widespread adoption of peer to peer protocols means they are missing out on things other people are doing. They are not going to stop using NAT to use a protocol maliciously designed to break it; they will just wait, patiently and nearly always successfully, for somebody to come out with a version that has no such malice. They are certainly not going to stop using NAT because somebody tells them they should use a security protocol that does not secure anything worth securing. BitTorrent is a better anti-NAT tool than AH ever will be. More carrot, less stick. -Dave
Re: switch speed question
Nathan Ward wrote: On 26/02/2009, at 2:48 AM, David Barak wrote: If two hosts are exchanging 1Gbps flows, the traffic across the bus will be 2Gbps, right? You don't get to add transmit and receive together to get 48Gbps. Packets don't go across the backplane once to receive, and then once more to transmit. They go across once, from the receiving port to the transmitting port. (sure, sometimes perhaps packets do go across twice, but not normally) Assuming a crossbar switch, sure. If your ports individually look up the outgoing port for an incoming packet, request backplane to that port, and transmit, then you only need 24Gbps. If your ports need to connect to an intelligent entity on the backplane to do your routing/switching/IGMP snooping/QoS enforcement/etc, then you are indeed going to cross the backplane twice, and need both transmit and receive bandwidth. Since many of us are routing goons with store-and-forward roots, we tend to think along those lines. And it is still wise, even in this day and age, to make sure that backplane bandwidth doesn't include a central switching point, or, if it doesn't, the marketing folks haven't doubled the backplane numbers because they took it out. -Dave
Re: 3/11 (invalid or corrupt AS path)
We're seeing them from AS 48438, coming across to us as an Optional Transitive Attribute which our force-10s are not parsing (but cheerfully passing along to our clients, who are then flapping their peers because of it.) Sample route; 91.210.248.0/23 Ozar wrote: I am starting to see random BGP neighbor messages from multiple neighbors on different boxes. %BGP-3-NOTIFICATION: received from neighbor X.X.X.X 3/11 (invalid or corrupt AS path) 516 bytes I dont see much documentation on this, and we are in the process of opening a TAC case, just curious if anyone else has seen these and may be able to shed some light. Thanks
Re: Sprint v. Cogent, some clarity facts
Rod Beck wrote: And a 'Tier One' nework is a transit-free network that can reach all end points (end user IP addresses) A Tier One is best defined as the ISP the salesman represents. It originally referred to transit-free, settlement-free ISPs, but over time, bigger ISPs began to play with the definition to try to differentiate themselves from the smaller ISPs that did not have the reach they had, and smaller players began glossing over paid peering and similar arrangements and claiming Tier One status. Since there's no formal definition, anybody can claim they are Tier One or that somebody else is not. Don't trust the term.
Re: Force10 Gear - Opinions
Paul Wall wrote: Please realize that the above is list vs. list. Cisco 6500 series hardware is extremely popular in the secondary market, with discounts of 80% or greater on linecards, etc common, furthering the argument that Cisco is the cheaper of the two solutions. Secondary market prices aren't a fair measure, unless you include the corresponding cost for software and support. And the fact is, when we put this out for an RFP, we ended up with Force10 having the lowest price by a fair margin; the closest competitor in price was Foundry, with Cisco a distant third. List prices aren't a good measure o actual price; they're a number for salesmen to compare their discount to to make people feel special. In short: You can get the Force10 cheap.
Re: interger to I P address
Normally, I don't participate in this sort of thing, but I'm a sucker
for a there's more than one way to do it challenge.
Shadow wrote:
Robert D. Scott wrote:
The harder way:
Decimal: 1089055123
Hex (dashes inserted at octals): 40-E9-A9-93
Decimal (of each octet): 64-233-169-147
IP Address: 64.233.169.147
The this could take all day way :
(in bc with scale=0 for integer portions only)
1089055123/(2^24)%(2^8)
64
1089055123/(2^16)%(2^8)
233
1089055123/(2^8)%(2^8)
169
1089055123/(2^0)%(2^8)
147
(Note: 2^0=1 x/1=x so last line could reduce to 1089055123%(2^8).)
-Nicholas
[EMAIL PROTECTED]
The ugly, please adjust according to your endianness, etc way:
int *dec;
unsigned char *oct1, *oct2, *oct3, *oct4;
main(int argc, char **argv) {
dec = malloc(sizeof(int));
*dec = 1089055123;
oct4 = dec;
oct3 = oct4 + sizeof(char);
oct2 = oct3 + sizeof(char);
oct1 = oct2 + sizeof(char);
printf(dec: %lu ip: %hu.%hu.%hu.%hu\n, *dec, *oct1, *oct2, *oct3,
*oct4);
}
