Super-Networking Blog

Hey do you need to get rid of NetBios on your network interface but when you try to do it through network properties your server crashes?

Then do it through the registry:

HKLM\System\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_AdapterID}\NetbiosOptions

NetBIOSOptions = 0 | 1 | 2

0 - Uses NetBIOS setting from the DHCP server.

1 - Enables NetBIOS over TCP/IP.

2 - Disables NetBIOS over TCP/IP.

Reboot to make your settings take affect.

The well designed and well run network should basically run itself. Every hour of everyday the network should just hum along. People shouldn’t even realize that it is there. Users should be able to plug-in to a jack or hook-up to wifi without have to contact the IT dept. A well run network should handle spikes in traffic and growth in servers.

A well run network should allow your network administrators to watch what is traversing the network and not waste time watching the status of the network. There are things the come up now and then but if your network requires people to full time manage every aspect of the network just to keep it running you might want to rethink it.

This is not to say that there aren’t thinks to keep up like hardening your security procedures, updating code, updating acls, managing serverfarms, etc… You might have some sort of NAC product that will quarantine some users when they plug in but for the most part the network team should be transparent to 99% of users.

Also it is my belief that simplicity is the best design, the more complex you make your network architecture the harder it is going to be to secure and the harder it will be to maintain. KISS should your networks mantra.

So this is a follow-up post to Latency Vs. Bandwidth where I gave a good link to an explanation on the differences between the problem of Latency and Bandwidth on the Internet. The same blogger had a follow-up post that explained a few ways for you to help improve high latencies.

This is another good article that goes over some of the things you can do to mitigate latency problems. I am going to go through a couple of things on this topic myself:

“Tweaking the host TCP settings” was one of his things to try and I agree that if you do it right this can help a great deal but if you tweak it wrong it can make things a whole lot worse. Be sure to test it in a lab before doing anything in production. Also another FYI on this method is that Windows Vista auto tunes your network setting so you are better off just letting it make the changes unless you have major problems.

Another method that he brings up is to move mission critical Internet web pages or downloads to a CDN network. This is a great idea but be wary of the price that this can cost you. There are a lot of them out that and some are cost effective and some are not. I did a mini review of some of the choices here.

Another thing you can do that should help is if you have an application that needs to stay in your datacenter and you need to get it cross county under a maximum latency is work with your ISP. Most of the time your traffic will switch through multiple ISPs between your datacenter and theirs if it is a long distance away. This can cause major increases in your latency.

A couple of ways to mitigate this is to possibly switch your ISP to the same ISP as the business you need to work with. If it is a lower bandwidth need you could get a point to point link, or if it needs to be a higher bandwidth connection you should look at the possibility of getting a MPLS tunnel from end to end through your ISP.

One more tip which doesn’t really relate to Latency but will help if you are wondering why your transfers are so slow over a large pipe. Use parallel transfers, if you have large amounts of data to transfer over long distances either program it in or find a programs that running multiple streams at the same time. You will find a huge increase in throughput.

There are a thousand ways to look at this but hopefully between the post from the EdgeBlog and my posts you can get a lot of options.

I ran across a pretty good read today that explains the problem with latency on WAN networks. The first part starts out saying that a lot of IT managers do not understand that just throughing more bandwidth at a problem won’t solve all your problems. This might be true of IT manager’s but all Network Administrators/Engineers better know this. This is a simple concept and it one of the reasons why Sattelite Internet hasn’t taken off, latency is a killer.

Check out the article here

Cisco confirms the memory exhaustion vulnerability as per the advisory published by CERT/CC and confirms this vulnerability impacts the PIX and ASA appliance for system software 7.2 only. Exploitation of the vulnerability may lead to a Denial of Service condition against the appliance.

The Firewall Services Module (FWSM) is not affected by this vulnerability.

PSIRT would like to thank Grant Deffenbaugh and Lisa Sittler from the CERT/CC for reporting this vulnerability to Cisco.

We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in security vulnerability reports against Cisco products.

Full Article

Promqry

Kind of a sweet little tool my buddy sent me. I installed it and ran it, doesn’t do you much good if you aren’t an Administrator of the boxes you are scanning but it is an easy to use tool. Good program to have in your toolbelt if you are paranoid like me.

There are pricing changes coming to Amazon’s S3 service. I know most of the time you think price change, oh no I guess they are going up. Not in this case.

Current bandwidth price (through May 31, 2007) $0.20 / GB - uploaded $0.20 / GB - downloaded New bandwidth price (effective June 1, 2007) $0.10 per GB - all data uploaded

$0.18 per GB - first 10 TB / month data downloaded

$0.16 per GB - next 40 TB / month data downloaded

$0.13 per GB - data downloaded / month over 50 TB Data transferred between Amazon S3 and Amazon EC2 will remain free of charge New request-based price (effective June 1, 2007)

$0.01 per 1,000 PUT or LIST requests

$0.01 per 10,000 GET and all other requests*

* No charge for delete requests

Storage will continue to be charged at $0.15 / GB-month used.

The end result is an overall price reduction for the vast majority of our customers. If this new pricing had been applied to customers� March 2007 usage, 75% of Amazon S3 customers would have seen their bill decrease, while an additional 11% would have seen an increase of less than 10%. Only 14% of customers would have experienced an increase of greater than 10%.

Thanks to Jeff for the info.

Here is an older post of mine on Amazon S3’s service.