Calin | IPNET - Part 12

Cisco Menu for Console Server

Let’s say that you have a Cisco router that you use as console server to connect to your devices in the CCIE testing rack. If you want to allow other people to access your rack for training and don’t want to mess explaining how to connect to different device from the console router, then you need a menu for easy access.

We will define a menu on your console server. We’ll start by going to configure terminal mode and hit the command menu ?:

Console-Server(config)#menu ?
  WORD  Name of this menu

Looks like we need to define a name for your menu, so I’ll name it “CS” menu and hit another ? mark:

Console-Server(config)#menu CS ?
  clear-screen  Use termcap database to clear screen
  command       Set menu command
  default       Item number to use for RETURN
  line-mode     require <enter> after typing selection
  options       Set per-item options
  prompt        Set prompt string
  single-space  single-space menu entries on display
  status-line   Display user status at top of screen
  text          Set text of menu line
  title         Set menu title

This command will output your options for the menu configuration. I will start by cleaning the screen after entering the menu CS:

Console-Server(config)#menu CS clear-screen

Next, I want to know where people are connecting and what’s the purpose of this console server, so I will add a title to my menu:

Console-Server(config)#menu CS title ^
Enter TEXT message.  End with the character '^'.
Welcome to FirstDigest.com CCIE Rack
^

We have now a menu with a title, but let’s tell users how to use this menu:

Console-Server(config)#menu CS prompt ^
Enter TEXT message.  End with the character '^'.
Choose and option and press Enter:
^

To really need your user to press Enter, you need to specify this option in your menu:

Console-Server(config)#menu CS line-mode

If you don’t add the above option, the picked options from menu it’s automatically run without waiting for the key Enter.
We have the menu defined and the necessary information in place. Let’s add some functionality to this menu.
First I want to give user the option to see the IP address where he’s connected:

Console-Server(config)#menu CS command 1 sh ip int brief | e una
Console-Server(config)#menu CS text 1 Check the Console Server IP Address  
Console-Server(config)#menu CS option 1 pause

What I did above? Well, I added the necessary command to check the IP Address. This command can be modified to meet your requirements. For me this is enough since I have only one interface with IP address. This command is invisible to the connected user. I mean if you press the key 1 and then Enter, you get the output. Still, we don’t want our users to guess what they have to do, so we’ll add some text.

The visibile choice for your user is added with the “text” option and my phrase is “Check the Console Sever IP Address”. Of course this can be customized as you need.

Last option is the “pause” option. If you don’t add the “pause” then your user will see no output,as the command will be run in the background and will return to prompt.

You have to notice that the item 1 (in my case) is the parameter that bound together all options for this specific part of the menu. It will be display of course for key 1 on your keyboard.

Next, we’ll give the user the option to disconnect from the console server:

Console-Server(config)#menu CS command 2 exit
Console-Server(config)#menu CS text 2 Disconnect from Console Server

Let’s add some connections to our Cisco devices in the rack. I will add only a couple of connection, as an example. You can extended and customize this commands as you want:

Console-Server(config)#menu CS command 3 telnet 10.1.1.1 2001
Console-Server(config)#menu CS text 3 Connect to R1
Console-Server(config)#menu CS command 4 telnet 10.1.1.1 2002
Console-Server(config)#menu CS text 4 Connect to R2          
Console-Server(config)#menu CS command 5 telnet 10.1.1.1 2003
Console-Server(config)#menu CS text 5 Connect to R3
.
.
.
.

We have the menu configured now. To check what we did configure, I usually do:

Console-Server#sh run | i menu

The menu section is completed, but we need to add this menu to a user and force this user to use our menu. I will create a user which will run the menu CS as soon as he or she is connected to the console router. My user has a privilege 15 level. If you are concerned with security, you can set another privilege level, but be sure to configure that level to support the commands that you have in your menu. Also I will configure another user, for my usage, or in case that something goes wrong to be able to connect remotely and fix the issue. This “Admin” user will not run automatically the menu we just create.

Console-Server(config)#username Tester privilege 15 password tester2012
Console-Server(config)#username Tester autocommand menu CS
Console-Server(config)#username Admin password cisco2012
! I will enable also telnet to test from remote host
Console-Server(config)#line vty 0 4
Console-Server(config-line)#login local

I will simulate a remote connection to check if everything is working fine:

R2#telnet 10.1.1.1
Trying 10.1.1.1 ... Open
 
 
User Access Verification
 
Username: Tester
Password: 
 
Welcome to FirstDigest.com CCIE Rack
 
 
    1          Check the Console Server IP Address
 
    2          Disconnect from Console Server
 
    3          Connect to R1
 
    4          Connect to R2
 
    5          Connect to R3
 
 
Choose and option and press Enter:

The menu is there. I will try some options to see if it’s working properly:

Choose and option and press Enter:
1
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.1.1.1        YES manual up                    up

Choose and option and press Enter:
2
 
[Connection to 10.1.1.1 closed by foreign host]

I recommend that you verify the menu functionality before you go “live”. You can check the menu directly on the Console Server:

Console-Server#menu CS

I hope this short tutorial will help you. If you have questions or something is not clear from my explanation please use the comments and I will try to help you.

IP Prefix-List tricky question

A few days ago I did encounter a task in one of these preparation workbooks for CCIE R&S Lab which was very tricky. This task is not a hard one and does not require extensive knowledge (it can be a CCNP level question as well), but the way the question is formulated can create confusion.I would appreciate your comments on this topic.

The task states that I have a number of subnets from which the followings are important for
our issue:

10.4.1.4/30
10.4.2.8/29
10.4.3.16/28
10.4.4.32/27
10.4.5.64/26
10.4.6.128/25

The other present subnets are something like 10.7.x.x. I add this here just to see that it does not affect the result of this task.

The request is to configure a prefix-list following these rules:

– allow all subnets in 10.4.0.0
– as specific as possible, I should not allow other prefixes
– minimum number of prefix-lists

Considering the above one I did consider the following to be the correct answer:

ip prefix-list ONE permit 10.4.0.0/21 ge 25 le 30

However the proposed solution was:

ip prefix-list ONE seq 5 permit 10.4.0.0/22 ge 23 le 30
ip prefix-list ONE seq 10 permit 10.4.4.0/22 ge 23 le 28

Both solutions are working, nevertheless which one would be the correct one in the exam?

I asked this question on the GroupStudy List, and Maarten Vervoorn came up with a new proposal:

ip prefix-list ONE seq 5 permit 10.4.0.0/22 ge 28 le 30
ip prefix-list ONE seq 10 permit 10.4.4.0/22 ge 25 le 27

Also a good solution, but is the best solution? Hard to say. The advice that I got is that if you have such task in the lab exam to describe the issue to your proctor, explain all possible solution so he or she can see that you fully understand the multiple solutions and base on the answer pickup the best solution. I think this is the only way to solve this kind of questions. If you have other ideas, I would like to hear them.

Packet header graphic representation

I was surfing the Internet in search of some good drawing representing packet header and I come across five excellent diagrams large enough ( 1050px wide ) to use digital but also for printing. The person behind these excellent drawings is Matt Baxter, but his site (fatpipe.org) is not accessible anymore. I found these documents on the Internet and I thought to add them here together.

You will find a link at the bottom of this post where you can download them all together.

Disclaimer: These drawings are not mine and I don’t claim any rights on them. My thanks and all copyrights go to Matt Baxter.
Matt, if you come across this blog and you find sharing to be inappropriate, please contact me.

IPv4 Header

IPv6 Header

TCP Header

UDP Header

ICMP Header

Download all drawings here:

Packet header representation

Selective BGP Dampening and parameters tuning

Some time ago, I wrote about BGP Dampening and how this feature can improve the stability of the network. A lot happened since then and during my experience with different service providers I have seen that BGP dampening can help in the same measure at it can harm your network. An endless discussion can be started on this topic, but this is not what I want to do here.

One thing that I did learn is that fine tuning of any feature can help a lot in some cases making the difference between stable network and a total disaster. In regard to BGP dampening, I have the following scenario. Imagine that you would like to use BGP dampening, but only for some networks, which are proven to be more stable than others. I will base my example on the following scenario:

Task

Router 1 in the above scenario has three networks that are advertised into BGP:
L0 – 1.1.1.0 /24
L1 – 11.11.11.0 /24
L2 – 111.111.111.0 /24
Imagine this are being remote networks and that 11.11.11.0 /24 is very unstable. To simulate an unstable network that triggers BGP, shut / no shut multiple times.

On Router 2, we want to use the BGP Dampening feature, but only for this network. We know already that we can do something like:

conf t
router bgp 200
bgp dampening

This will enable the BGP dampening feature. We can even fine tune some parameters like:

conf t
router bgp 200
bgp dampening 15 750 5000 30

In this way we increase the limit at which a route will be dampened (5000) and decrease the maximum dampening time to 30 minutes. Unfortunately this parameters are applied globally and all routes (stable and unstable) will play by this rules.

Solution

Going back to the idea of this post, use of selective BGP Dampening, we can configure Router 2 like this:

conf t
access-list 11 permit 11.11.11.0 0.0.0.255
!
route-map DAM permit 10
match ip address 11
set dampening 15 750 2000 60
!
route-map DAM deny 1000

What we just did is to match the unstable prefix in an ACL. Use the ACL in a route-map with permit policy. Mandatory set the dampening parameters. They can be the same as original values, but if you don’t set anything here, you will meet the following error when trying to apply the BGP dampening.

%BGP-3-BADROUTEMAP: Bad parameters in the route-map DAM applied for Dampening

At the end we have a deny policy in the same route-map to avoid matching any other prefixes. We can not apply it to BGP:

conf t
router bgp 200
bgp dampening route-map DAM

We want to check that BGP Dampening feature is activated:

R2#sh ip bgp dampening parameters
 dampening 15 750 2000 60 (route-map DAM 10)
  Half-life time      : 15 mins       Decay Time       : 2320 secs
  Max suppress penalty: 12000         Max suppress time: 60 mins
  Suppress penalty    :  2000         Reuse penalty    : 750

By the way, if you check the output immediately after applying the BGP dampening feature, you might see the following error:

% dampening reconfiguration in progress for IPv4 Unicast

Verification

Let us see if there are any flaps on going:

R2#sh ip bgp dampening flap-statistics 
 
R2#

Now we can shut / no shut L1 interface on R1 to create an instability of this network. After doing so couple of times we can see that the BGP dampening is active:

R2#sh ip bgp dampening flap-statistics | b Net
   Network          From            Flaps Duration Reuse    Path
 h 11.11.11.0/24    10.1.12.1       1     00:00:22          100

If we continue to play with shut / no shut, soon we will see that 11.11.11.0 /24 is marked as dampened:

R2#sh ip bgp dampening dampened-paths | b Net
   Network          From             Reuse    Path
*d 11.11.11.0/24    10.1.12.1        00:06:29 100 i

Now I want to prove that the same BGP dampening policies does NOT apply to other networks like 111.111.111.0 /24. I will try to play the same shut / no shut game with L2 on R1. After 5 minutes of this game I can see the following:

R2#sh ip bgp dampening dampened-paths | b Net
   Network          From             Reuse    Path
*d 11.11.11.0/24    10.1.12.1        00:02:09 100 i
 
R2#sh ip bgp dampening flap-statistics | b Net
   Network          From            Flaps Duration Reuse    Path
*d 11.11.11.0/24    10.1.12.1       3     00:07:51 00:01:49 100 
 
R2#sh ip bgp | b Net  
   Network          Next Hop            Metric LocPrf Weight Path
*> 2.2.2.0/24       0.0.0.0                  0         32768 i
*> 3.3.3.0/24       10.1.23.3                0             0 300 i
*d 11.11.11.0/24    10.1.12.1                0             0 100 i
*> 111.111.111.0/24 10.1.12.1                0             0 100 i

You can see that 111.111.111.0 /24 does not appear in any dampening report.

I tried this in multiple scenarios and every time I got the expected result. If you test this and get different results, please let me know in comments and we can discuss.

Fiber Optic basics

I think all network engineers touched, if not used / patched, as least one time a fiber optic patch cord. As a network engineer you might not necessarily need to understand HOW fiber optic is working. It’s there and it’s working. You just need to plug the patch cord and that that’s it.

Anyway, for interested network engineers (or geeks) like me, to understand how fiber optic works might be a fun way to spend 10 minutes of my life. Of course, to have in-deep knowledge of FO, at the level which allow you to design applications for this transport medium, you need to read a little bit more than the video above.

Disclaimer: This video is not mine and I don’t claim any rights on it. My thanks go to Jimmy Ray Purse, TechWiseTV, Networking 101 Show, Cisco and last but not least to YouTube for hosting it and let us embed this video.