(1 votes, average: 5.00 out of 5)
Loading ...
Print This PostIn previous articles, I have explained how to setup automated Cisco backup processes – however all the previous examples used existing software. There are other scenarios where a custom programming solution could be required. Writing your own software gives you the most control over the program and the process. However, this usually requires more effort and understanding in order to obtain this level of control and/or functionality. This article will go through the process of compiling an entire program that accomplishes logging into a Cisco IOS device via telnet and displays the running configuration.
First off, most of the credit for the following code goes to a contributor on Codeproject, which is where the source came from to build the telnet component of this program. We will code the remainder of the program that utilizes the telnet code obtained from codeproject.
The code contained in this article can be compiled using the Microsoft 2.0 framework that is most likely already installed on your computer. We will compile this with the command line compiler that comes with the .Net runtime. By using this method, it not only provides a very simple process to compile the program, it also prevents having to download Microsoft Visual Studio Express. I would suggest, however, that if you plan to extend this program – you can benefit greatly from having a full blown IDE to write the code in.
First, let’s look at the telnet component, which is the majority of the program. This portion of the code is compiled as a library (.dll) under the name scottp.Net.Comm.dll and will be a dependency for the ConfigSafe project. This code could have just as easily been put in the executable, which would have kept the program to a single file. However, in bigger programs, this type of code would go into a library anyway – so there is no time like the present to begin following standard practices.
(3 votes, average: 3.67 out of 5)In the first article, we went over some very basic MPLS terms and explanations. That article ended with a basic network using four 7206 routers – two in each datacenter. At this point, we have no routing protocols or MPLS configuration. All we can do presently is ping directly connected interfaces of neighboring devices. The first thing that we want to establish, is the routing protocol used by the MPLS aware devices to determine how to reach the other core devices.
The routing protocol distributes topology information through the network so that the route of a Label Switched Path (LSP) can be calculated. An interior gateway protocol, such as OSPF or IS-IS, is normally used, as MPLS networks typically cover a single administrative domain. Let’s configure OSPF on the P/Core devices so that we can ping every interface on all four routers.
hostname r1 ! interface Loopback1 ip address 10.254.1.1 255.255.255.255 ! interface FastEthernet1/0 description r2 f1/0 ip address 10.1.1.1 255.255.255.252 ! interface FastEthernet1/1 description r3 f1/1 ip address 10.1.1.5 255.255.255.252 ! router ospf 1 log-adjacency-changes network 10.1.1.0 0.0.0.3 area 0 network 10.1.1.4 0.0.0.3 area 0 network 10.254.1.1 0.0.0.0 area 0
hostname r2 ! interface Loopback1 ip address 10.254.1.2 255.255.255.255 ! interface FastEthernet1/0 description r1 f1/0 ip address 10.1.1.2 255.255.255.252 ! interface FastEthernet1/1 description r4 f1/1 ip address 10.1.1.13 255.255.255.252 ! router ospf 1 log-adjacency-changes network 10.1.1.0 0.0.0.3 area 0 network 10.1.1.12 0.0.0.3 area 0 network 10.254.1.2 0.0.0.0 area 0
In these articles, I would like to present how to build a basic MPLS network. Whether you just wondered how your service providers network was built or if your considering an internal MPLS network inside your company, this information should help out. As far as why you would want to build an MPLS network, I won’t go into much detail as this is more intended to show how to build and not why to build. However, I will say the big reason to build an internal MPLS network is so that you can use MPLS based VPN’s using Virtual Route Forwarders or VRF. That’s all I’ll mention on that, lets starting building a network.
I’ll be working with Cisco 7200 routers, since dynamips is being used as the platform. We could just as easily use some of the other emulated hardware, but out of all the options available in dynamips – a 7200 is probably the closest to what you might see in the core of an MPLS network. There are three terms that describe the type of MPLS device:
P – which is for Provider equipment
PE – which stands for Provider Edge
CE – which as you have probably already guessed, stands for customer edge.
When working with IP addresses it is very handy to have a cheat sheet available in order to quickly calculate netmasks and for converting to/from CIDR notation. So here is a quick chart that is printable for wall hanging.
Here is some explanation on how the chart is presented:
There are several general configuration items that should be configured on all Cisco devices running standard IOS. Some layer2 only switches will ignore a few of the commands in this article that are layer3 specific.
The first place to start is with the service commands
service password-encryption
Explanation:
The router administrator will ensure passwords are not viewable when displaying the router configuration. Type 5 encryption must be used for the enable mode password.
no service udp-small-servers no service tcp-small-servers
Explanation:
All IOS versions above 12.0 has small-servers disabled by default. However, it is good to make sure these services didn’t get enabled somewhere along the way. The commands above won’t show up in the configuration, since they are off by default. Cisco IOS provides these “small services” which include echo, chargen, and discard. These services are completely unnecessary to run on Cisco devices.
In corporate environments, I.T. professionals are constantly trying to adhere to the latest guidelines that apply to the line of business they are a part of. Most organizations are guided by one or more of the following: HIPPA (Healthcare), PCI (Credit Card Industry), and SOX among others. These guidelines definitely overlap with each other in areas. If your privileged enough to have to satisfy more than one of these governing bodies, many times an issue addressed in one will also address the same issue in another. The overlap exists largely because all of these guidelines are based on ‘best practices’. When you have a list of these best practices available to audit against, it allows you to score yourself before the formal audits happen that are required by the various governing bodies. It is also wise to be aware of the best practices before implementing a new system, in order to prevent having to go back and revisit after the implementation.
The good news is there are resources available to anyone and are provided by Defense Information Systems Agency (DISA) which is a government agency that is part of the Department of Defense (DoD). These guides are separated into two different types: One set is called Security Technical Informational Guides (STIG) and the other is called Security Checklists. These guides are developed to provide guidance for people who build and manage DoD networks. They are also used in audits performed within Department of Defense networks.
None of the DoD offered materials has anything to do with HIPPA, PCI, SOX, etc. on the surface, but the thing they do have in common is they are focused on security best practices. In my experience dealing with HIPPA, PCI, SOX, and DoD networks, using these guides as a reference to secure a network or platform will cover 90+% of anything that would come up in a HIPPA, PCI, or SOX audit.
Finally, an update (well, sort of) to the Cisco TACACS server for Windows that was provided here. The first version provided on this site was compiled from the original 4.0.4 Cisco version of tac_plus.
This version is actually based on 4.03, but has many added features that doesn’t exist in the 4.0.4 Cisco release. The version given to this particular code distribution is F4.0.3.alpha-9a.
It runs just like the other version, (yes, with all the same qwerks as well) with additional options available to you.
When designing a robust network, the requirement that should make the top of the list is redundancy. Most of the time, this is pretty easy. When linking switches together, connect multiple links. When connecting servers to the network, using multiple network adapters with teaming is the norm. Connecting more than one interface on a router for redundancy is usually a little different. Most of the time, you would take two interfaces on a router and assign an IP network to each and use a routing protocol for interacting with other connected routers for link selection. However, there are some devices that are router types that don’t perform routing functions.
IOS devices functioning as some type of gateway comes to mind as a type of device that won’t route traffic – however network redundancy to the device is still desired. In this example, a Cisco VG224 is used in a network to provide dial tone to analog devices over an IP network. The VG224 gateway has multiple interfaces and does have the ability to run a routing protocol for reachability, but would be considered a bloated solution just to provide redundant network connections to the device.
In this example, we will accomplish network link redundancy by using a feature called Integrated routing and bridging or IRB for short. In an IRB configuration, multiple physical interfaces are assigned to a common bridge group. The two interfaces then form a bridge what communicates with a bridge virtual interface. The device IP address then gets assigned to the virtual interface.
Cisco IOS Software Modularity is available for the two newest Supervisor modules, the Sup720 and Sup32, which go into the Cisco 6500 series platform. Basically, by using the modular IOS, the switch runs more efficiently. This is accomplished by splitting up major components inside the IOS into separate subsystems, which will run in different processes. The modularity also allows the patching of portions of the IOS, without having to install an entirely new IOS. Think about this: How many times have you installed a new IOS image to fix a specific bug, but the new software caused a problem in another area that was previously not broken? Now, fixing issues by only patching the part of the software with a problem helps insure the rest of the device’s operation will continue to operate as it did in the past.
A new feature that comes along with the modular image is the inclusion of Cisco Embedded Event Manager (EEM). This feature allows the EEM process to ‘catch’ a defined event and then spawn an action from that raised event. For example, the device can generate and send an email when the CPU goes over a certain percentage for a period that is longer than a defined threshold. The engine behind this functionality is controlled using the Python scripting language. Using Python to write these embedded event handlers provides some powerful capabilities at your fingertips.
Read more…
In the previous article, Running commands on a Cisco device from the Windows command line , I wrote on how to run commands from the Windows command line against a Cisco device. The article was based on using the Unix utility rsh aka Remote Shell. The biggest downfall of using rsh is the security issues around the protocol. How about another method of doing the same thing, but with using a more secure process?
Putty has a sister program that is called plink. Like putty, plink is a standalone executable that is capable of accessing remote devices using telnet or ssh. Plink is basically used in place of putty when you want the input/output of the program to use STDIN/STDOUT. So, for example you can open a command prompt, invoke plink and connect to a device. The interaction with the session will look just as if it would when using the telnet.exe from the XP/Vista command line. One of the features of plink is that it can share the saved sessions created in Putty. By default, putty will use the Windows registry to store saved connection information. However, the configuration can be changed to store the sessions in the local file system.
In this initial example, lets configure a router to accept an incoming ssh connection with a locally defined username/password combination. The basic IOS configuration to accomplish this task will look like the following:
Read more…
