Actually, pps (packets per second) is a quite common if not misleading statistic spewed by networking equipment vendors, and has been for years. Packets-per-second doesn't really tell you the characteristics of the packets being sent. One interpretation might be the following: The minimum ICMP packet size with Ethernet II encapsulation is 46 bytes. The minimum TCP packet size with Ethernet II encapsulation is 54 bytes. So, 1000000pps of 46 byte ICMP is 368 megabits/sec. And, 1000000pps of 54 byte TCP is 432 megabits/sec. Both of these figures seem realistic to me.
Now, the maximum length of an Ethernet II packet, regardless of any upper layer protocols is 1514 bytes. 1000000pps of 1514 bytes is 12.1 gigabits/sec. Obviously, that packet size isn't what they were referencing.
In respect to the link speed, a 1000Mbit or a Gigabit Ethernet link is quite common these days and the above minimum packet size stats aren't out of line.
Actually, on both OS's with a larger packet size, and thus a lower amount of packets-per-second, a decent machine with 66mhz PCI Gigabit NICs can easily route 500mb/sec through the box.
The PSP got me a Sony Vaio Laptop exchanged for a brand new (at the time) HP Pavillion laptop with twice the specs in many cases because the Sony was in for repairs 3 times regarding the system board. This was a huge hassle, but they honored their lemon policy.
Also the PSP fixed my wife's 100-disc CD changer at least 3 times whenever she moved and it would stop working.
And most recently, my panasonic cordless phone system was totally replaced when it failed a about 2 years after purchasing it. That was a steal because the PSP only cost around $12.00.
Now, I have bot a ton of other stuff that I never got the PSP with, but with being picky about what you get the PSP with, you can end up on top.
The Cisco PIX OS 6+ and recent Cisco IOS code revs support stateful failover. We already do this and it works just fine. If you are looking at several interfaces and need to run at DS3 speeds, a PIX515E Unrestricted Licensed PIX and a PIX515E Failover licensed PIX will do the trick. True, they aren't price comparable to commodity x86 hardware (even though they are based on that architecture), if you have 3000+ users, you can most likely afford these.
While it's nice to see that there is an option, this seems like an empty gesture. Not to knock the FreeDOS project, kudos to you, there are SO many better offerings out there that could be packaged. What are businesses or home users going to do with FreeDOS? If anything this comes across like a message that says, "Here's your other choice, it's not really an option at all, is it?"
You can go wireless if you get your hands on the broadband adapter and buy one of the new wireless game adapters which are nothing more than a 10Base-T to 802.11b/g bridge.
What extra steps are you talking about? To install a port, go to the directory for the port and:
1. make install clean
After you do that, it finds the source, the source of all dependencies, compiles everything and installs everything. That's it. The ports system is pretty great about making it almost dead simple about getting software onto your machine.
It does implement reliability
on
HyperSCSI Examined
·
· Score: 4, Informative
If you look go to the MCSA site and look at the HyperSCSI FAQ, it does implement reliability and flow control, just not in the same manner as TCP.
The only technical negative side I can (at this time) is that because the implementation isn't over IP, you can't traverse a router. This usually isn't a problem but could cause some inflexibility in larger deployments.
I have been burned so many times about software purchases that I always read several reviews about a game/piece of software before I purchase it. If the game is brand new, I wait for others to post their views to forums or discussion groups. While I can't remember the last time I played a copied game, or allowed someone to copy one of mine, I understand why retailers don't allow returns on opened merchandise. However, no matter how crappy a game is, you can always recover "some" of your loss on eBay or Half.com. What about buying your games/software via those venues? You don't invest as much in the game and you can judge the game by how much it is worth on those markets...
This works out to an average inbound utilization of somewhere around 184 kbit/sec, albeit sustained. So, in a sense, they are saying, they are only willing to support an average sustained download of this speed. Anything greater results in you using your allocated bandwidth quicker and you will reach your cap sooner.
It is possible I could easily reach my daily limit by doing nothing wrong...
Some days, I visit Yahoo! Games on Demand and play 2 new games. This could easily take up 800MB or more. Download latest single disk ISO image of linux/xBSD or whatever, now I am up to 1.4G. Fireup Xbox live and play an hour of games or so, another 100MB transferred. Oh yeah, do I get penalized for the 20MB of daily scanning against my firewall? In this scenario I am over 1.5GB in the course of a few hours and I am not file sharing or downloading illegal or questionable content. That certainly wouldn't happen every day, but I can see how it would be frustrating to get cut off because you used the bandwidth you were supposedly paying for.
If you can't see the keyboard, you will have to force yourself to touch type. In addition, you can't cheat! Unfortunately, I am serious. I forced myself a few years ago to learn to touch type over the course of a few weeks by being too lazy to change a light bulb.
We use Netviz. It is data-driven and all the data for the diagrams can be stored in a database. Create one instance of a router, and that instance can appear in any of your diagrams with all of the properties, links and any number of user-defined attributes. Diagrams can be constructed in a hierarchy with drill-down-to-detail capability. Obviously, this is only one component of many you will need in the design process. It doesn't contain all the device specific config-checking tools that some other vendor-specifc tools have, but who needs those anyway?
Also, another set of tools that you might find useful is Opnet IT guru. If you need to model a proof of concept involving a complex network and application interaction, this can do it.
If you run a very Cisco-centric network (or totally Cisco) you can use IPAT Plus from WANDL. It takes Cisco router configs and builds a network model that can be used for reachability proof and various what-if scenarios.
Cisco used to sell Catalyst 3548XL switches that were listed as having a MTBF of 120,000+ hours. Their current replacement for that line (3550)comes in at 163,000+ hours. We had 7 of 24 3548XL switches fail in the first year we had them. They had poor air flow from a tiny fan, no heatsinks and tons of hot chips. The newer model has the same issue, though they did stuff a cheap foam baffle in the case to get air to flow closer to the chips, none of which have heatsinks. I have no idea how they tested them and got a MTBF of 13 years.
Not quite. Let's say you compromise a host on the 10/8 network. If it attempts to make an outbound TCP connection to an IRC server, the IRC server will not be able to respond back to the 10/8 host because RFC1918 routes are going to be filtered at some point back to the client and the TCP 3-way handshake won't even complete. UDP attacks in one direction from the client to the public would be possible, but the RFC1918 source address would most likely be caught by an ingress filter at the remote end.
Now, most likely, that 10/8 host gets NAT'd to a public address through a firewall. In this case, the IRC scenario is not only possible, but a real tactic used to get past firewalls. Some, firewalls such as the Cisco PIX make it easy to not care about your outbound traffic, so a client making outbound connections to IRC servers isn't necessary going to even be noticed. This is why you have to implement egress filtering on your firewalls and/or routers to block what your users have access to should they ever get trojaned.
Because the Internet is a global network, authors of these worms come from all over the world, and thus there is no consitency on how they are dealt with according to local laws or lack thereof. The ramifications of such worms are not well understood by local law makers and law enforcement officials. It's quite possible that some worms could be authored by individuals or groups outside the US in which there is almost no law or order. I doubt we can justify bombing a country because of prolific worm propogation.
So, while some sit pondering on how to prosecute the authors of such worms, doesn't it make more sense to focus efforts on preventing the problems that worms cause by eliminating the well known, published ways that the past 4 or 5 recent worms have propogated? How many email worms need to take place before people realize that the worm authors are only half guilty? End users need education. Applications (read Outlook) need to provide better ability for users to limit functionality to core functions unless otherwise needed.
Catching the new virus writers and discovering their techniques is and always will be a game of "whack-a-mole". You slam the hammer down, only to find another one pops up in a "security-hole" somewhere else.
Digital cable infrastructure is hardly ready to support mass rollouts of VoD. Providers will need to fork out a lot of cash in order to address the following constraints:
1. VoD streams, by nature, are not multicast. They are unicast streams sent to a particular subscriber. This consumes an ever increasing amount of bandwidth per subscriber that is using the service. For example, being able to deliver 10,000 1mb/sec streams to a 100,000 user subscriber base isn't realistic. That is 10 gigabit/sec. The current infrastructure to support this level of concurrent VoD streams doesn't exist in many places, if anywhere. The equipment to build dozens of 10Gb/sec transport networks in a metro area is very expensive, and in low production volume. The initial capital to build such a network is what will prohibit many providers from rolling this out as a mass service offering. I see limited roll out beyond what is out there today for the next 18-24 months.
2. A possibile solution to the above problem is to decrease bitrate of the stream to increase the amount of concurrent users. Several techniques exist that would enable providers to do this, but looking at the existing digital decoder hardware that is out there, the providers are limited unless they put forth the capital to upgrade their digital cable boxes. Also, providers may provide flexibility at a price. For example, a VoD program may be viewed at low quality for X dollars, while a high quality stream is available at Z dollars. What ever they choose to do, the initial subscribers are going to have to pay a pretty penny for quality.
3. The cable industry really wants to see this happen because it is likely to become one of the key benefits to remaining a cable subscriber. However, satellite TV providers such as DirecTV have many more hurdles to overcome to be able to deliver such a service. As such, the cable industry as a whole is most likely not willing to spend the mega-dollars needed to beef up their infrastructure to support mass rollouts of this technology until the economy strengthens and user demand is high. They know they won't be losing any users to satellite because it has VoD.
In the interim, I think we are likely to see something that resembles a TiVO like device that is part of your cable receiver. You select what you would like to order. The content is then sent to this storage device at a speed and at a time when the network permits. The content can then be viewed at the viewers discretion until the content expires. This gets around the TiVO limitation of working around broadcast schedules, but isn't as glorius as immediate gratification. In theory, this could be delivered less exensively than VoD and whet the appetite for the future VoD consumer base.
Ok, so at the router level you blocked inbound port 40000-42000 to clients. Was this with an access-list on the router? Unless your routers are stateful inspection firewalls, then you have inevitably broken connections that would otherwise be allowed by your policy. It would be rather silly to think that no client application uses any source port in the 40000-42000 range. Access-lists don't care about the direction of the connection, just Dest IP/Dest Port, Source IP/Source Port. If you really have done this, then you have broken your users because of a misunderstanding on how TCP/IP works.
Also, by allowing SSH, you assume that nobody who uses SSH is capable of setting up SSH Tunnel VPN's. When you block all VPN clients do you also block SSL on port 443 because that could also be used as a VPN? Ever heard of SOCKS? Do you block IPSEC?
Also, when you block incoming connections to your users, how do you handle UDP applications such as DNS? Again, without a stateful inspection firewall, there is no concept of being able to distinguish between a new inbound UDP connection, and an inbound UDP packet that is a reponse to one initiated by the client. Just wondering how you supposedly did all of this without losing all of your customers.
Slashdot Mirror
Actually, pps (packets per second) is a quite common if not misleading statistic spewed by networking equipment vendors, and has been for years. Packets-per-second doesn't really tell you the characteristics of the packets being sent. One interpretation might be the following:
The minimum ICMP packet size with Ethernet II encapsulation is 46 bytes. The minimum TCP packet size with Ethernet II encapsulation is 54 bytes. So, 1000000pps of 46 byte ICMP is 368 megabits/sec. And, 1000000pps of 54 byte TCP is 432 megabits/sec. Both of these figures seem realistic to me.
Now, the maximum length of an Ethernet II packet, regardless of any upper layer protocols is 1514 bytes. 1000000pps of 1514 bytes is 12.1 gigabits/sec. Obviously, that packet size isn't what they were referencing.
In respect to the link speed, a 1000Mbit or a Gigabit Ethernet link is quite common these days and the above minimum packet size stats aren't out of line.
Actually, on both OS's with a larger packet size, and thus a lower amount of packets-per-second, a decent machine with 66mhz PCI Gigabit NICs can easily route 500mb/sec through the box.
The PSP got me a Sony Vaio Laptop exchanged for a brand new (at the time) HP Pavillion laptop with twice the specs in many cases because the Sony was in for repairs 3 times regarding the system board. This was a huge hassle, but they honored their lemon policy.
Also the PSP fixed my wife's 100-disc CD changer at least 3 times whenever she moved and it would stop working.
And most recently, my panasonic cordless phone system was totally replaced when it failed a about 2 years after purchasing it. That was a steal because the PSP only cost around $12.00.
Now, I have bot a ton of other stuff that I never got the PSP with, but with being picky about what you get the PSP with, you can end up on top.
We are in Ohio and received both of ours in May.
The Cisco PIX OS 6+ and recent Cisco IOS code revs support stateful failover. We already do this and it works just fine. If you are looking at several interfaces and need to run at DS3 speeds, a PIX515E Unrestricted Licensed PIX and a PIX515E Failover licensed PIX will do the trick. True, they aren't price comparable to commodity x86 hardware (even though they are based on that architecture), if you have 3000+ users, you can most likely afford these.
for Gleemonex?
While it's nice to see that there is an option, this seems like an empty gesture. Not to knock the FreeDOS project, kudos to you, there are SO many better offerings out there that could be packaged. What are businesses or home users going to do with FreeDOS? If anything this comes across like a message that says, "Here's your other choice, it's not really an option at all, is it?"
You can go wireless if you get your hands on the broadband adapter and buy one of the new wireless game adapters which are nothing more than a 10Base-T to 802.11b/g bridge.
What extra steps are you talking about? To install a port, go to the directory for the port and:
1. make install clean
After you do that, it finds the source, the source of all dependencies, compiles everything and installs everything. That's it. The ports system is pretty great about making it almost dead simple about getting software onto your machine.
If you look go to the MCSA site and look at the HyperSCSI FAQ, it does implement reliability and flow control, just not in the same manner as TCP.
The only technical negative side I can (at this time) is that because the implementation isn't over IP, you can't traverse a router. This usually isn't a problem but could cause some inflexibility in larger deployments.
I have been burned so many times about software purchases that I always read several reviews about a game/piece of software before I purchase it. If the game is brand new, I wait for others to post their views to forums or discussion groups. While I can't remember the last time I played a copied game, or allowed someone to copy one of mine, I understand why retailers don't allow returns on opened merchandise. However, no matter how crappy a game is, you can always recover "some" of your loss on eBay or Half.com. What about buying your games/software via those venues? You don't invest as much in the game and you can judge the game by how much it is worth on those markets...
This works out to an average inbound utilization of somewhere around 184 kbit/sec, albeit sustained. So, in a sense, they are saying, they are only willing to support an average sustained download of this speed. Anything greater results in you using your allocated bandwidth quicker and you will reach your cap sooner.
It is possible I could easily reach my daily limit by doing nothing wrong...
Some days, I visit Yahoo! Games on Demand and play 2 new games. This could easily take up 800MB or more. Download latest single disk ISO image of linux/xBSD or whatever, now I am up to 1.4G. Fireup Xbox live and play an hour of games or so, another 100MB transferred. Oh yeah, do I get penalized for the 20MB of daily scanning against my firewall? In this scenario I am over 1.5GB in the course of a few hours and I am not file sharing or downloading illegal or questionable content. That certainly wouldn't happen every day, but I can see how it would be frustrating to get cut off because you used the bandwidth you were supposedly paying for.
If you can't see the keyboard, you will have to force yourself to touch type. In addition, you can't cheat! Unfortunately, I am serious. I forced myself a few years ago to learn to touch type over the course of a few weeks by being too lazy to change a light bulb.
We use Netviz. It is data-driven and all the data for the diagrams can be stored in a database. Create one instance of a router, and that instance can appear in any of your diagrams with all of the properties, links and any number of user-defined attributes. Diagrams can be constructed in a hierarchy with drill-down-to-detail capability. Obviously, this is only one component of many you will need in the design process. It doesn't contain all the device specific config-checking tools that some other vendor-specifc tools have, but who needs those anyway?
Also, another set of tools that you might find useful is Opnet IT guru. If you need to model a proof of concept involving a complex network and application interaction, this can do it.
If you run a very Cisco-centric network (or totally Cisco) you can use IPAT Plus from WANDL. It takes Cisco router configs and builds a network model that can be used for reachability proof and various what-if scenarios.
Cisco used to sell Catalyst 3548XL switches that were listed as having a MTBF of 120,000+ hours. Their current replacement for that line (3550)comes in at 163,000+ hours. We had 7 of 24 3548XL switches fail in the first year we had them. They had poor air flow from a tiny fan, no heatsinks and tons of hot chips. The newer model has the same issue, though they did stuff a cheap foam baffle in the case to get air to flow closer to the chips, none of which have heatsinks. I have no idea how they tested them and got a MTBF of 13 years.
Today microsoft is putting forth AsmL1.5. It's reasonable to assume they will evnetually release AsmL8.
Not quite. Let's say you compromise a host on the 10/8 network. If it attempts to make an outbound TCP connection to an IRC server, the IRC server will not be able to respond back to the 10/8 host because RFC1918 routes are going to be filtered at some point back to the client and the TCP 3-way handshake won't even complete. UDP attacks in one direction from the client to the public would be possible, but the RFC1918 source address would most likely be caught by an ingress filter at the remote end.
Now, most likely, that 10/8 host gets NAT'd to a public address through a firewall. In this case, the IRC scenario is not only possible, but a real tactic used to get past firewalls. Some, firewalls such as the Cisco PIX make it easy to not care about your outbound traffic, so a client making outbound connections to IRC servers isn't necessary going to even be noticed. This is why you have to implement egress filtering on your firewalls and/or routers to block what your users have access to should they ever get trojaned.
Because the Internet is a global network, authors of these worms come from all over the world, and thus there is no consitency on how they are dealt with according to local laws or lack thereof. The ramifications of such worms are not well understood by local law makers and law enforcement officials. It's quite possible that some worms could be authored by individuals or groups outside the US in which there is almost no law or order. I doubt we can justify bombing a country because of prolific worm propogation.
So, while some sit pondering on how to prosecute the authors of such worms, doesn't it make more sense to focus efforts on preventing the problems that worms cause by eliminating the well known, published ways that the past 4 or 5 recent worms have propogated? How many email worms need to take place before people realize that the worm authors are only half guilty? End users need education. Applications (read Outlook) need to provide better ability for users to limit functionality to core functions unless otherwise needed.
Catching the new virus writers and discovering their techniques is and always will be a game of "whack-a-mole". You slam the hammer down, only to find another one pops up in a "security-hole" somewhere else.
Digital cable infrastructure is hardly ready to support mass rollouts of VoD. Providers will need to fork out a lot of cash in order to address the following constraints:
1. VoD streams, by nature, are not multicast. They are unicast streams sent to a particular subscriber. This consumes an ever increasing amount of bandwidth per subscriber that is using the service. For example, being able to deliver 10,000 1mb/sec streams to a 100,000 user subscriber base isn't realistic. That is 10 gigabit/sec. The current infrastructure to support this level of concurrent VoD streams doesn't exist in many places, if anywhere. The equipment to build dozens of 10Gb/sec transport networks in a metro area is very expensive, and in low production volume. The initial capital to build such a network is what will prohibit many providers from rolling this out as a mass service offering. I see limited roll out beyond what is out there today for the next 18-24 months.
2. A possibile solution to the above problem is to decrease bitrate of the stream to increase the amount of concurrent users. Several techniques exist that would enable providers to do this, but looking at the existing digital decoder hardware that is out there, the providers are limited unless they put forth the capital to upgrade their digital cable boxes. Also, providers may provide flexibility at a price. For example, a VoD program may be viewed at low quality for X dollars, while a high quality stream is available at Z dollars. What ever they choose to do, the initial subscribers are going to have to pay a pretty penny for quality.
3. The cable industry really wants to see this happen because it is likely to become one of the key benefits to remaining a cable subscriber. However, satellite TV providers such as DirecTV have many more hurdles to overcome to be able to deliver such a service. As such, the cable industry as a whole is most likely not willing to spend the mega-dollars needed to beef up their infrastructure to support mass rollouts of this technology until the economy strengthens and user demand is high. They know they won't be losing any users to satellite because it has VoD.
In the interim, I think we are likely to see something that resembles a TiVO like device that is part of your cable receiver. You select what you would like to order. The content is then sent to this storage device at a speed and at a time when the network permits. The content can then be viewed at the viewers discretion until the content expires. This gets around the TiVO limitation of working around broadcast schedules, but isn't as glorius as immediate gratification. In theory, this could be delivered less exensively than VoD and whet the appetite for the future VoD consumer base.
Ok, so at the router level you blocked inbound port 40000-42000 to clients. Was this with an access-list on the router? Unless your routers are stateful inspection firewalls, then you have inevitably broken connections that would otherwise be allowed by your policy. It would be rather silly to think that no client application uses any source port in the 40000-42000 range. Access-lists don't care about the direction of the connection, just Dest IP/Dest Port, Source IP/Source Port. If you really have done this, then you have broken your users because of a misunderstanding on how TCP/IP works.
Also, by allowing SSH, you assume that nobody who uses SSH is capable of setting up SSH Tunnel VPN's. When you block all VPN clients do you also block SSL on port 443 because that could also be used as a VPN? Ever heard of SOCKS? Do you block IPSEC?
Also, when you block incoming connections to your users, how do you handle UDP applications such as DNS? Again, without a stateful inspection firewall, there is no concept of being able to distinguish between a new inbound UDP connection, and an inbound UDP packet that is a reponse to one initiated by the client. Just wondering how you supposedly did all of this without losing all of your customers.