More often I have to change critical configuration options in live environments, but sometimes I don’t no the effect of these changes on the network. So I would like to build a test network where I can check the impact of the configuration changes. A good network simulator would definitely help in this situation.
Cisco switches use IOS software and software always contains bugs. A new release can contain bug fixes, but also new features. It could be useful to test these new features in a test environment. Unfortunately we and our customers don’t have a lot of routers and switches in spare. So I need a network simulator, which can simulate real Cisco IOS software.
First I used the tool Dynamips / Dynagen. This text Cisco router emulator emulates a couple of Cisco routers. The tool helps by loading different images on your own laptop. The hard part of Dynamips is the configuration of a test environment. All configuration is done in text files, with a lot of different options.
Luckily I found a graphical user interface for Dynamips. It is called GNS3. I really love this tool, because designing a network environment is dragging and dropping some routers, define the desired modules and connect them together. Next start the emulator and you are ready to go. The new version of GNS3 doesn’t only emulate routers, but also the Cisco PIX firewall with software version 8.x. Of course it is no Cisco ASA, but better something then nothing.
I really recommend this tool to everybody involved with network infrastructures and especially Cisco environments. The tool can help you by testing features like routing protocols and QoS tools. GNS3 is also very useful when studying for a Cisco Exam, even for the CCIE certification.
eSafe Gateway can be used for scanning incoming and outgoing SMTP connections for virusses and SPAM. Normally eSafe Gateway doesn’t check incoming mail addresses against a directory like Active Directory or Novell Directory Services.
This means that all mail addresses for a trusted domain are forwarded to the internal mail server. In the most ideal situation unknown mail addresses should be blocked at the eSafe Gateway. This feature will take away load from the internal mail server, because this mail server doesn’t have to generate NDR (Non-Delivery Reports) messages. Beside that, the eSafe Gateway also doesn’t have to process the NDR’s. LDAP (Lightweight Directory Access Protocol) provides this functionality.
With LDAP configured, the eSafe Gateway will synchronize all known mail objects from the directory services with the eSafe Gateway. By this, the eSafe Gateway knows all valid mail objects and can block invalid mail objects. There are some issues when configuring a LDAP query with Active Directory. By default Active Directory only allows 1000 objects in one query. Some customers have more mail object, so this settings needs to be added. Inside Active Directory, you should edit the LDAP Policy setting MaxPageSize. Look here for more information about editing the MaxPageSize variable.
Some organizations use PublicFolders in conjunction with Microsoft. These PublicFolders can be mail-enabled and should be added in the LDAP filter configuration inside eSafe Gateway. This is done by changing the default filter
This results in adding the mail object PublicFolder to the LDAP query.
Voice over IP is, as you know for sure, very time-sensitive traffic. That is why VoIP signaling and payload traffic should receive enough bandwidth and as less jitter and delay as possible.
QoS is an important tool to assign VoIP traffic more preference over “normal” traffic. Important for QoS tools to function correctly is placing different kinds of traffic in different queues. To place traffic in different queues, traffic should be classified. All VoIP traffic should be classified and placed in the same queue or given the same priority. I usually use the following ACL’s to match VoIP signaling and payload traffic.
ip access-list extended VOIP-SIGNALING
permit tcp any any eq 1720
permit tcp any any range 11000 11999
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any range 2000 2002
permit udp any any eq 1719
permit udp any any eq 5060
ip access-list extended VOIP-PAYLOAD
permit udp any any range 16384 32767
The following table gives some basic explanations for the different permit statements:
|H.323 / H.225
|H.323 / H.245
|Media Gateway Control Protocol (MGCP)
||UDP/2427 and TCP/2428
|Skinny Client Control Protocol (SCCP)
|Simple Gateway Control Protocol (SGCP)
|H.323 / H.225 RAS
|Session Initiation Protocol
|Real-Time Transport Protocol (RTP)
||UDP/16384-32767, even ports only
|Real-Time Control Protocol (RTCP)
||UDP/16384-32767, odd ports only
A decent management server is very important in a network, at least that is my opinion. The most important aspect of a management server is its user friendliness. Our customers are most of the time busy with their own problems and the problems of end users, which include all kind of (silly) problems. So the most of them don’t have a lot of time to spend on configuring a management server.
That is why I like Cacti and especially CactiEZ. CactiEZ is a software appliance, which is up and running in half an hour. After that you just add some devices and you can generate some nice bandwidth statistics with the help of RRDTool. I have also seen a lot of other management servers, like Nagios, HP OpenView and Cisco Works, but the most of them are hard to configure and end up as mp3 player…..
When I configure a management server only for network components like switches, routers and/or firewalls, I always use CactiEZ. It is easy to install and gives me all the things I need. The most important options of Cacti for me are: bandwidth statistics, syslog messages, flow view, mac tracking, reporting and so one. Especially if you combine Cacti(EZ) with SwitchMap, you have a nice, easy to use and robust management server for your network.
I have had different discussions with different customers about the load-balancing algorithms between a Cisco switch, configured with a port-channel and a VMware ESX server using multiple NICs. Our VMware consultants always choose Route based on IP hashes as load-balancing algorithm. This means that load-balancing happens on layer 3 of the OSI model (source-destination-IP).
In my opinion, the switch should be configured the same way. Depending on the model switch, you can have different default load-balancing algoritmhs. For example, the Cisco Catalyst 3750 uses src-mac load-balancing and the Cisco Catalyst 6500 use src-dst-ip load-balancing. You can check the configured load-balancing algorithm with the following command:
show etherchannel load-balancing
If you would like you change the load-balancing algorithm you can use the global configuration command:
port-channel load-balancing <option>
Be aware that this is a global configuration command, so it affects all the configured port-channels on the switch.
To check the load-balancing between the different NICs, you should have a tool to look at real-time bandwidth statistics. I normally use the tool SNMP Traffic Grapher to monitor the different switch ports. On the ESX console you can check the load-balancing with the commands:
- esxtop [enter]
- s2 (schedule interval of 2 seconds) [enter]
- n [network]
The load should be spread fairly even across the different switch ports en vmnics.