First encounter with IP Fragmentation and MTU problems

About a week ago, I was called to  a client to investigate issues they were having as it pertains to browsing the internet. To my surprise when I arrived on site and tested the sites they were having issues with, I was able to browse these sites just fine. At first I was told that there were only 2 users having the problem so I decided to check these two laptops to ascertain whether there was some virus on the system that was causing the problem. This of course proved to not be the case, as both laptops were fully protected and virus definitions were up to date. I did some further investigations on the systems, only to discover that all users on the network were experiencing the problem. This puzzled me even more. To prove whether is was a problem with the internet connection, one of the users informed me that he had connected to a near by wifi connection and was able to browse these same sites just fine. This meant that the problem had to lie within the network.

Upon doing some initial research off site on what possible causes for the problem could be, I was advised that it could be a problem with MTU. Given that I never experienced this issue before, I had to dig deeper to get further details. The customer was using Cisco equipment for their switching infrastructure and Juniper for their firewall. I proceeded to take a ASA 5505 on my next visit to the client and swapped out the juniper to test. The tests were successful. All users were able to browse the websites they were having issues with. At this stage I figured we must have had a defective Junos box on our hands so I swapped it out for a replacement that was already on site. Alright, so now we’ve got a brand new spare Juniper SRX in to replace the old one. All should be fine now, right? Wrong! Users began to experience the same issue again. This of course boggled my mind even further. I mean, the internet worked fine with the ASA. I swapped out the old Junos for a replacement, and we’re back with the same problem? What could be the cause?

Back at the office, I was digging deeper, trying to learn as much as I can about the symptoms that can arise whenever you experience MTU issues. Cisco had a great article about this, which totally went in depth  about the causes and possible solutions to the problem. If you’d like to read it for  yourself, you can have a look here. I am by no means familiar with Juniper configurations and the Junos box was managed by another team in Holland. Given how technology works, and how all vendors have basically their own way of achieving the same results, I knew that Juniper must have had an option similar to Cisco’s “ip tcp adjust-mss” command and after some research, I came across this Knowlege Base article about how to achieve the same result in Junos. Working along with the team in Holland, I instructed them of the changes to make and also provided the link to the KB. Users were able to browse all sites just fine once again after the changes were made to the Junos box.

For those of you who are wondering how I was able to browse just fine on the network before the Junos box was configured  and other users weren’t; my laptop had the Cisco VPN Client software installed. This application usually reduces your MTU to 1300. By default Windows uses a MTU of 1500, so if somewhere along the path to the destination, a device was configured for a smaller mtu you could experience the problems as mentioned above.

BGP Route Reflectors and Confederations

June 18, 2011 7 comments

The Border gateway protocol (BGP) is used to exchange network layer reachability information (NLRI) between Autonomous Systems. Like most routing protocols, BGP also has methods of preventing routing loops within networks. iBGP in particular uses the Split Horizon rule to prevent routing loops. The iBGP Split Horizon rule basically states that an iBGP router will not forward any prefixes learned via iBGP to other iBGP speakers because it assumes a full mesh topology. This means that if you have four routers, R1, R2, R3, R4 connected in a daisy chain. R1 being in AS 100 and R2, R3, R4 being in AS 200, any routes learned by R2 via its eBGP peering to R1 wouldn’t be advertised to R4.

To combat this problem, BGP uses two technologies with the goal of allowing your iBGP routers to still receive all routing updates and not require a full mesh topology.

  • BGP Route-Reflectors
    • Route-reflectors allow iBGP speakers to have a partial mesh topology while still propagating all iBGP learned routes to all iBGP speakers
    • Route-reflectors consist of route-reflector servers and route-reflector clients
    • eBGP routes learned by route-reflector servers are advertised to other eBGP neighbors, route-reflector clients and non-clients.
    • iBGP routes learned from non-clients are advertised to eBGP neighbors and route-reflector clients
    • iBGP routes learned from route-reflector clients are advertised to other clients, non-clients and eBGP neighbors.
  • BGP Confederation
    • Confederations achieve the same goal as Route-reflectors
    • This is done by dividing the main AS into several smaller sub-autonomous systems.
    • Typically  the private range used for these sub ASs are in the range 6451-65535
    • Neighbors in each sub-as must still be fully meshed
    • Confederation iBGP/eBGP peers act the same way as BGP iBGP/eBGP peers.

Let’s first take a look at how we would configure route-reflectors followed by confederations. We’ll be using the topology consisting of 4 routers, R1-R4 as shown below.



Base Configuration for R1

R1#sh run | s router bgp
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 network 1.1.1.1 mask 255.255.255.255
 network 2.2.2.2 mask 255.255.255.255
 network 3.3.3.3 mask 255.255.255.255
 network 4.4.4.4 mask 255.255.255.255
 network 192.168.1.0
 neighbor 192.168.1.2 remote-as 200
 no auto-summary

Base Configuration for R2

R2#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.1.0
network 192.168.2.0
neighbor 192.168.1.1 remote-as 100
neighbor 192.168.2.3 remote-as 200
no auto-summary

Base Configuration for R3

R3#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.2.0
network 192.168.3.0
neighbor 192.168.2.2 remote-as 200
neighbor 192.168.3.4 remote-as 200
no auto-summary

Base Configuration for R4

R4#sh run | s router bgp
router bgp 200
no synchronization
bgp log-neighbor-changes
network 192.168.3.0
neighbor 192.168.3.3 remote-as 200
no auto-summary


Now let’s take a look at the output of the “show ip bpg” command.

Notice that R2 has learned about the loopbacks that are configured on R1 via it’s eBGP relationship with R1.

R2#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0             0 100 i
*> 2.2.2.2/32       192.168.1.1              0             0 100 i
*> 3.3.3.3/32       192.168.1.1              0             0 100 i
*> 4.4.4.4/32       192.168.1.1              0             0 100 i
*  192.168.1.0      192.168.1.1              0             0 100 i
*>                  0.0.0.0                  0         32768 i
* i192.168.2.0      192.168.2.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i
*>i192.168.3.0      192.168.2.3              0    100      0 i

Notice R3 also learns of R1’s loopbacks but this time via iBGP as indicated by the “i” in front of the networks.

R3#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       192.168.1.1              0    100      0 100 i
*>i2.2.2.2/32       192.168.1.1              0    100      0 100 i
*>i3.3.3.3/32       192.168.1.1              0    100      0 100 i
*>i4.4.4.4/32       192.168.1.1              0    100      0 100 i
*>i192.168.1.0      192.168.2.2              0    100      0 i
* i192.168.2.0      192.168.2.2              0    100      0 i
*>                  0.0.0.0                  0         32768 i
* i192.168.3.0      192.168.3.4              0    100      0 i
*>                  0.0.0.0                  0         32768 i

Here on R4 we see the iBGP split horizon rule in effect.

R4#sh ip bgp

   Network          Next Hop            Metric LocPrf Weight Path
*>i192.168.2.0      192.168.3.3              0    100      0 i
* i192.168.3.0      192.168.3.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i

R4 doesn’t learn of R1’s loopback interfaces because R3 isn’t passing the routes on. To correct this problem we’re going to use the first solution available to us, by making R3 a route-reflector server and R4 a route-reflector client. This will then allow R3 to advertise R1’s loopback interfaces to R4. The configuration to make all this happen only needs to be configured on the route-reflector server which is R3 in this case.

Route-reflector configuration for R3

R3(config)#router bgp 200
R3(config-router)#neighbor 192.168.3.4 route-reflector-client

Now let’s take another look at the output of the “show ip bgp” command on R4 to see if it did indeed learn those routes.

R4#sh ip bgp 

   Network          Next Hop            Metric LocPrf Weight Path
*>i1.1.1.1/32       192.168.1.1              0    100      0 100 i
*>i2.2.2.2/32       192.168.1.1              0    100      0 100 i
*>i3.3.3.3/32       192.168.1.1              0    100      0 100 i
*>i4.4.4.4/32       192.168.1.1              0    100      0 100 i
*>i192.168.1.0      192.168.2.2              0    100      0 i
*>i192.168.2.0      192.168.3.3              0    100      0 i
* i192.168.3.0      192.168.3.3              0    100      0 i
*>                  0.0.0.0                  0         32768 i
R4#
R4#ping 4.4.4.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms

Success!!! We see that R4 is indeed now learning the routes via it’s iBGP neighbor R3 and we also have reachability.

Moving onto BGP Confederations. For this example we’re going to use the same topology however we’re going to sub-divide AS200 into As6500 and AS6501

One thing to note about Confederation configurations is that we first create the sub AS and then identify what our actual AS is within BGP sub configuration mode. I personally don’ t know why Cisco decided to implement Confederations in this way but this wouldn’t be the first time we’ve all scratched our heads at how Cisco chooses to implement stuff. Configurations for R1 will remain exactly the same, however for all other routers in AS200 (Confed AS 6500 and AD6501), we’re going to have to first remove the “router bgp 200” configs then proceed with the configurations. R2 and R3 are going to be placed into sub AS 6500 while R4 will be placed in sub AS6501.

The reason for us placing R4 into a separate sub AS to R2 and R3 is because Confederation iBGP/eBGP peers act exactly the same way as iBGP/eBGP peers. This means that a full mesh would still be required for all routers within the same sub AS. Had we placed R4 into the same sub AS as R2 and R3 the split horizon rule would have prevented R3 from advertising the networks on R1, to R4.

Confederations config on R2

R2#sh run | s router bgp
router bgp 6500
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6501
 network 192.168.1.0
 network 192.168.2.0
 neighbor 192.168.1.1 remote-as 100
 neighbor 192.168.2.3 remote-as 6500
 no auto-summary

Confederations config on R3

R3#sh run | s router bgp
router bgp 6500
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6501
 network 192.168.2.0
 network 192.168.3.0
 neighbor 192.168.2.2 remote-as 6500
 neighbor 192.168.3.4 remote-as 6501
 no auto-summary

Confederations config on R4

R4#sh run | s router bgp
router bgp 6501
 no synchronization
 bgp log-neighbor-changes
 bgp confederation identifier 200
 bgp confederation peers 6500
 network 192.168.3.0
 neighbor 192.168.3.3 remote-as 6500
 no auto-summary

Output of “show ip bgp” on R4

R4#sh ip bgp 

   Network          Next Hop            Metric LocPrf Weight Path
*> 1.1.1.1/32       192.168.1.1              0    100      0 (6500) 100 i
*> 2.2.2.2/32       192.168.1.1              0    100      0 (6500) 100 i
*> 3.3.3.3/32       192.168.1.1              0    100      0 (6500) 100 i
*> 4.4.4.4/32       192.168.1.1              0    100      0 (6500) 100 i
*> 192.168.1.0      192.168.2.2              0    100      0 (6500) i
*> 192.168.2.0      192.168.3.3              0    100      0 (6500) i
*  192.168.3.0      192.168.3.3              0    100      0 (6500) i
*>                  0.0.0.0                  0         32768 i

Success!!! R4 learns of R1’s networks via it’s Confederation eBGP relationship with R3. Notice that the networks do not list the “i” in front of them to indicate it as being learnt via iBGP. This shows clearly how similar Confederation eBGP peers and normal eBGP peers are in terms of their neighbor relationships.

As we’ve seen throughout this post, both Route-Reflectors and Confederations can be used to solve the iBGP Split Horizon problem without the need for a full mesh topology within your BGP networks. I personally don’t have any production experience dealing with these technologies but if I had to choose one, I’d go with route-reflector just because the configuration is a lot simpler :-). Also one other advantage that came up during my group  study session with @aconaway was that you would need to plan ahead if you ever wanted to implement Confederations. Reason for this is because the way in which BGP Confederations are configured in IOS. Let’s say we had some eBGP peers early in our network when it was a lot smaller but now your network has grown to a size that requires Confederations. You would need to remove the “router bgp AS” command thereby removing all BGP configurations on that router, then proceed with your Confederation configs where as with route-reflectors you simply need to place the “neighbor x.x.x.x route-reflector-client” command to achieve the same result.

Disclaimer

This post was mainly written to aid me with my studies. The views expressed are based on my understanding and research of the technologies. Because this is a learning process mistakes may be committed to which I would greatly appreciate it if you would point those out via the comments section.

MCITP EA Completed! What’s Next?

October 14, 2010 Leave a comment

So, I finally managed to complete the final two exams remaining to achieve my MCITP Enterprise Administrator.

These were:

  • TS: Windows Server 2008 Applications Infrastructure, Configuring (Exam 70-643)
  • Pro: Windows Server 2008, Enterprise Administrator (Exam 70-647)

No doubt, these two were definitely tougher than the previous exams taken to achieve MCTIP SA. I think this was mainly because of the new technologies that were covered.

The 70-643 exam focused more on being able to prepare your network environment for the different applications/technologies being deployed in today’s enterprise. Virtualization and Remote Desktop Services played a big part in this. Microsoft really has implemented a lot of improvements into the Remote Desktop Service role, formerly Terminal Services. One such improvement that I am very impressed with is that of the Remote Desktop Gateway. Before, the only way of allowing remote desktop access to internal terminal servers/client desktops, would have been to open port 3389 on your company’s firewall and forward that port to the particular system or you would need to install a third party software like Logmein. With Remote Desktop Gateway, we now have the option of using port 443, which is already open on many corporate firewalls, to allow remote desktop access to internal client desktops. Topics covered also included:

  • Deploying Servers
  • Configuring Remote Desktop Services
  • Configuring a Web Services Infrastructure
  • Configuring Network Application Services

Windows Server 2008 Enterprise Administrator is the professional exam required to complete the MCITP EA. This exam is focused more on the design aspects rather than exact configuration steps required for a particular scenario. This was definitely the most difficult of all the exams I took for the MCITP SA/EA. Some of the topics covered were:

  • Planning network and application services
  • Designing core identity and access management components
  • Designing support identity and access management components
  • Designing for business continuity and data availability

So now that I’ve completed this, you may be wondering what’s next. I’m going to be going after the MCTIP Enterprise Messaging Administrator 2010. I’ll go into further details in a later post describing why I chose this as my next cert and what training materials I’ll be using. For now, I just wanted to give you a short update on my studies.

Categories: Uncategorized

MCITP SA Completed!

September 25, 2010 Leave a comment

The Microsoft Certified IT Professional Server Administrator is just one of the available specialties within the MCITP certification program. At first when I heard about the revamping of Microsoft’s certification program, I was confused somewhat as to how this will all be integrated into the current IT infrastructure. Before, we were accustomed to being called a MCSE/MCSA and now we were going to be called MCITP blah blah. As with most humans’ initial response to change, I really wasn’t feeling this move. However, I must say that after getting more familiar with how the new program was designed to address professional’s knowledge and skill set, I’m absolutely in love with it. There is a plethora of specialty certs to choose from with this new program. I’m not going to go into further details on those. I’m just going to focus on what I’m currently studying for and why I chose these.

So where was I?  Ah! MCITP SA. I guess you can compare the MCITP SA to the MCSA of the old certification program. To attain the MCITP SA status, one would need to pass three exams.

These are:

  • TS: Windows Server 2008 Active Directory, Configuring (Exam 70-640)
  • TS: Windows Server 2008 Network Infrastructure, Configuring (Exam 70-642)
  • Pro: Windows Server 2008, Server Administrator (Exam 70-646)

Unlike the old MCSA which required a “client and a specialty exam”, the MCITP SA doesn’t require these. Instead you have the MCTS certification program which has sub sections which further describe which particular Microsoft technology you’re proficient in, hence the name Microsoft Certified Technology Specialist. 🙂  Also, if you already are certified in MCSA (like me), then you have the option of just taking two exams.

These are:

  • TS: Upgrading from Windows Server 2003 MCSA to, Windows Server 2008, Technology Specializations (Exam 70-648)
  • Pro: Windows Server 2008, Server Administrator (Exam 70-646)

Passing the 70-648 upgrade exam gains you MCTS on both Active Directory and Network Infrastructure, basically killing two birds with one stone. This was the path I chose in order to upgrade my MCSA to MCITP SA. I had completed the 70-646 exam a couple months back, but never took the time to push through and finish up the 70-648. I was too busy studying for other certs and learning other technologies, mainly CCNA Voice, MCTS on MOSS 2007 and also CCIE R&S written.

As is the pattern with MS upgrade paths, there are a number of options available to you. I decided to go with the Windows 7 Configuration for my Client exam, as I’m working with Windows 7 everyday, have a really solid understanding of it and also the fact that I really, LOVE Vista! No really! I loathe Windows Vista so much that I decided to skip it and go with Windows 7. I’m sorry, did I just say loathe? I meant love. 😀 Well, you get the picture. Anyways back to what I was saying. I was able to complete the Windows 7 exam today (70-680). So currently I have 2 more exams to complete before I’m fully upgraded to MCTIP EA. As usual, I will keep you guys posted as to my progress.

CCNA Voice Cleared!

August 15, 2010 Leave a comment

Hey guys! I just wanted to update you on my study progress. I passed the CCNA Voice exam last week, which now means I have 5 exams left to get my CCVP. I’ve started to read the CVoice book for the second time and I must say, it’s been a whole lot smoother thus far. I’m really happy with my decision to have done the CCNA Voice first before going straight into the CCVP. This really gave me a good foundation on the Voice technologies. CVoice is a really tough course, packed with a LOT of theory, so having a good foundation in my opinion is essential to helping you understand the many topics that are covered.

I’m also continuing with my CCIE written preparations. I’ve completed reading the book once thus far and I’m currently going through the INE Advanced Technologies COD. I’m still deciding on whether to read more books or whether to just reread the study guide a number of times and also do in depth research on the Cisco Doccd. I’ll let you guys know through my blog what I’ve decided.

Well that’s all for now. Hoping to have a very successful week of studies and hope you guys have the same. J

Categories: Uncategorized

Resuming My CCIE R&S Studies

Well it’s been couple months since I passed my last exam to become a Cisco Certified Network Professional. After that my director told me that I needed to get started on my CCVP studies. I must say, Cisco Voice was something I was hoping to not have to deal with at this point in my career. I really have no interest what so ever in it. But director’s orders are director’s orders. After all, he signs my cheque at the end of the month: P. So anyways I started studying for the first CCVP exam, CVoice. It’s been a pain, a drag and very depressing at times. All that coupled with not having a mentor for it, well, that was before my buddy on twitter @james_key started helping me with stuff. Since then, it’s been a lot better and even though I’m still way behind on my voice studies, I’m beginning to make progress. J So you might be reading this and wondering why on earth I called this post “Resuming my CCIE Studies”, right? Well, truth is, R&S is where my heart is at, at the moment. And even though I’m studying for my CCVP (which I MUST get this year) I can’t help but long for the chance to get back into the R&S studies. So with that, I’ve decided to begin back my CCIE reading. Right now I’m at Chapter 11 – BGP Routing Polices in the CCIE R&S Official Study Guide. I spent some of my free time at the office today reading this chapter and also began watching the INE Routing & Switching Advanced Technologies BGP section, to get a better understand of what I’ve been reading so far. It’s coming along pretty ok and I hope to retain most of what I’ve learnt thus far.

Well, that’s all for now. I hope to update this blog more often so that you guys can follow my progress in my Quest to get my CCIE #. J

Categories: Uncategorized

Why and how to configure Secure Shell (SSH) on a Cisco router

January 17, 2010 Leave a comment

This was taken from one of my posts I did for TrainSignal. From time to time you’ll see me post articles here that I wrote for TraingSignal.

Security continues to dominate the IT industry and is one of the most important factors to consider when designing and deploying networks. It is, therefore, imperative that we are able to ascertain and prevent most, if not all, vulnerabilities that may exist. One such weakness is Telnet to which SSH is the alternative. We will be taking a deeper look at how you would enable and configure your Cisco Router to use SSH and why we should always use SSH where possible as opposed to using Telnet.

We all know that when it comes to security within the networking universe, Cisco is one of the biggest players. However, just having a Cisco device doesn’t mean that you are secured. The onus is on you to ensure that you’ve configured that device properly to prevent most, if not all, loopholes.

Secure Shell (SSH)

Secure Shell (SSH) improves network security by providing a means of establishing secure connections to networking devices for management, thereby preventing hackers gaining access. Using Digital Certificates, in a Public/Private Key Cryptography,
SSH is able to authenticate clients or servers, thereby ensuring that the device or server you are about to connect to is exactly who they claim to be.

Ok, so now that we have a very brief idea of how SSH secures network traffic, the next step is figuring out where to get this thing we call a digital certificate. Do we have to go into a store to purchase it? Digital Certificates can be acquired in generally three different ways. The most secure (and expensive), requesting it from a trusted company called a CA – Certificate Authorities. An example of one such company is VeriSign, which is highly popular within the CA Industry for their role in providing worldwide trusted certificates; these certificates can cost quite a bit. There are two other ways of requesting a certificate. One is by using an internally trusted CA (trusted within a company) also called an enterprise CA or by generating a self sign certificate on the device itself. The last one is the lease secure form but provides more than enough security to lock down your average network device. This self signed certificate can be generated using the built in commands on your Cisco router.

Like SSH, Telnet can also be used to connect to your router but, the main disadvantage of using Telnet is that it does not encrypt its connections. This means that if a hacker is able to capture packets from a Telnet session, he or she would be able to view information contained within those packets, such as a client’s username and password, and can, therefore, gain access to your router. The diagram below will give you an idea of how this works.

Router Configuration

Now that we’ve gotten an understanding of how SSH works and why we should use SSH as opposed to using Telnet, the next step is actually getting down to configuring the device, which is always my favorite part.

For this exercise I will be using a Cisco 871 series SOHO router with IOS ver. 12.4 software. Depending on whether your router is brand new or currently in a production environment, you’re going to have to either connect via a Console session or through a Telnet session. Have a look at my article on “Configuring a Cisco router to use RADIUS for authentication –
INSERT LINK http://www.trainsignaltraining.com/using-radius-for-authentication/2009-08-20″ for the steps needed to connect via a Console session or you can check this article on Cisco’s website “INSERT LINK http://www-tss.cisco.com/eservice/compass/common/tasks/task_console_port_connect.htm.”

  1. Configure a hostname for the router using these commands.

     

    yourname#configure terminal
    Enter configuration commands, one per line. End with CNTL/Z.

    yourname (config)#hostname LabRouter

    LabRouter(config)#

 

  1. Configure a domain name with the ip domain-name command followed by whatever you would like your domain name to be. I used CiscoLab.com.

     

    LabRouter(config)#ip domain-name CiscoLab.com

 

  1. We generate a certificate that will be used to encrypt the SSH packets using the crypto key generate rsa command. Take note of the message that is displayed right after we enter this command. “The name for the keys will be: LabRouter.CiscoLab.com”. It combines the hostname of the router along with the domain name we configured to get the name of the encryption key generated; this is why it was important for us to, first of all, configure a hostname then a domain name before we generated the keys. Notice also that it asks us to choose a size of modulus for the key we’re about to generate. The higher the modulus, the stronger the encryption of the key. For our example, we’ll use a modulus of 1024.

     

 

  1. Now that we’ve generated the key, our next step would be to configure our vty lines for SSH access and specify which database we are going to use to provide authentication to the device. The local database on the router will do just fine for this example.

     

    LabRouter(config)#line vty 0 4

    LabRouter(config-line)#login local

    LabRouter(config-line)#transport input ssh

  2. You will need to create an account on the local router’s database to be used for authenticating to the device. This can be accomplished with these commands.

     

    LabRouter(config)#username XXXX privilege 15
    secret XXXX

 

Fine Tuning your Configuration.

We’ve pretty much completed all the steps needed to configure and use SSH on your router; however, there are some other configurations that can be made to further secure your device. For one, I would highly recommend you enabling an exec time-out on your router to prevent anyone from gaining access to the device in cases where you forgot to logout or got distracted because of an emergency. This way, the router will automatically log you out after the session has been idle for a set time. You must configure this command on the line interface as depicted below.

LabRouter(config)#line vty 0 4

LabRouter(config-line)#
exec-timeout 5

 

This means that if the session has been idle for 5 minutes, the router will automatically disconnect the session.

 

Use Access Control Lists (ACL) as an added layer of security; this will ensure that only devices with certain IP address are able to connect to the router. Let’s say the IP Subnet for your LAN is 192.168.100.0/24, you would create an acl to permit only traffic from that subnet and apply this acl to the vty lines.

LabRouter(config)#access-list 1 permit 192.168.100.0 0.0.0.255

LabRouter(config)#line vty 0 4

LabRouter(config-line)#access-class 1 in

 

Another crucial point to note is the use of SSH2 as opposed to using SSH1. SSH2 improves on a lot of the weaknesses that existed within SSH1 and for this reason I recommend always using SSH2 where possible. Enable SSH version 2 with this command:

LabRouter(config)#line vty 0 4

LabRouter(config)#ip ssh versopn 2

 

Detailed reading on SSH can be done at RFC 4251 “INSERT LINK
http://www.ietf.org/rfc/rfc4251.txt

Categories: Cisco Tags: , , ,