Sometimes you need to know the MTU of a path across a network, the MTU commonly changes for things like Q in Q or GRE tunnelling so its important to accurately know it to prevent undue fragmentation.

The middle bit in the 3 bit fragmentation flags field in the IP header is the Don’t Fragment (DF) flag, if it set to 1 the packet will not be fragmented, therefore if the packet exceeds the MTU of a link it will generate a ICMP type 3 code 4 error message and be dropped.

Using the extended commands in the ping we can manually determine the specific MTU across a path, there are a couple of pointers on doing this;

1. Change the repeat count to 1 or it will sweep the entire range a default of 5 times which is usually unnecessary
2. Don’t sweep the default range, it defaults to an MTU of between 36 to 18024 bytes, considering it sends 1 packer per byte of the MTU that’s 17,988 packets. That a hell of a lot of default 2 second time outs to wait for… so try a smaller range like 10 or so bytes
3. Remember to set the DF bit in the IP header or the ICMP packets will fragment and you actually be testing the MTU
4. Use the verbose option to see the results of each packet
5. Change the sweep interval to 1, again there is little point in sweeping the range multiple times

Router#ping
Protocol [ip]:
Target IP address: 201.14.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: Verbose
Loose, Strict, Record, Timestamp, Verbose[V]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1495
Sweep max size [18024]: 1505
Sweep interval [1]:
Type escape sequence to abort.
Sending 11, [1495..1505]-byte ICMP Echos to 201.14.1.1, timeout is 2 seconds:
Packet sent with the DF bit set
Reply to request 0 (4 ms) (size 1495)
Reply to request 1 (4 ms) (size 1496)
Reply to request 2 (4 ms) (size 1497)
Reply to request 3 (4 ms) (size 1498)
Reply to request 4 (4 ms) (size 1499)
Reply to request 5 (8 ms) (size 1500)
Request 6 timed out (size 1501)
Request 7 timed out (size 1502)
Request 8 timed out (size 1503)
Request 9 timed out (size 1504)
Request 10 timed out (size 1505)
Success rate is 54 percent (6/11), round-trip min/avg/max = 4/4/8 ms
Router#

As shown in the example above it indicates that the maximum MTU along the path is 1500 bytes.

Quite often when you are trying to verify that tasks are working  as expected you use the #debug ip packet command which works great… except if there is any other traffic on the router and you can quickly become swamped with the debug output. Luckily the #debug ip packet command can also take an ACL so if you wanted to verify traffic was going to the host 10.10.10.1 and only to that host you can do this by;

• - Creating an ACL for 10.10.10.1

• Router#Access-list 101 permit ip any host 10.10.10.1

• - Applying that ACL to the debug command

• Router#Debug ip packet detail 101

• - Bob’s your uncle

Because the #debug ip packet detail takes an ACL you can change the ACL to whatever you like, so if you just wanted to see ICMP its simple just change it to the following and reapply your Debug ip packet detail 101.

Router#Access-list 101 permit ip any any icmp

Another handy way is that if you accidently perform a debug command which causes a backlog on your console connection that you could not perform an un all due to so much output on the console, you should be able to telnet into the router and issue the usual undebug all immediately

The debugging will instantly disappear from the Console session as well, this is as debugging wont be sent to vty lines without the following command issuing the command terminal monitor, so you can stop debugging without having to wait to get your command across the Console if you have filled it up with debugging.

This can save valuable minutes or even a reload just remember to setup remote access before getting into a pickle

Just found out that at CCIE Flyer is giving away Narbik’s Soup to Nuts, the link is on his post at http://ccieflyer.com/2009-October-toc.php. I purchased the book a while ago and it is a great resource for getting to grips with the key technologies but there are a few errors. It is aimed at v3 of the R&S track but the topics in v3 and v4 are very similar and its free so take a look!

I also highly recommend Packet Life’s “cheat sheets”, they are brilliantly made quick reference guides, I print a couple of them off and keep them in my desk, so that the next time that I am unsure if that annoying fibre is really an ST, SC, or LC I can rest easy http://packetlife.net/library/cheat-sheets/

Also its a couple of old links but both IP Expert and Internetwork Expert have some free lectures to tempt you into their products at;
https://www.ipexpert.com/index.cfm/product/sku/ccie_lab_vlecture_series
http://www.internetworkexpert.com/free_ccie_vseminar.htm

Frame Relay Local Management Interface (LMI) is a set of enchantments to frame relay, originally agreed upon in 1990 by a consortium consisting of Cisco, Digital Equipment Corporation (DEC), Northern Telecom, and StrataCom. Eventually ANSI and CCITT came along created standard versions but most vendors support both standard version alongside the one defined by the consortium.

There are very few differences between them, mainly Cisco LMI type use the DLCI of 1023 and also DLCI number between 16 and 1007 for usable DLCI number and the ANSI & ITU(q933a) standard use a DLCI of 0 and usable DLCI numbers between 16 and 976. The LMI type can be changed on the frame relay enabled interface with the command;

Router(config-if)#frame-relay lmi-type ?
  cisco
  ansi
  q933a

The LMI messages messages sent between Routers and Frame Relay switches provide the the following additional features;
- Inverse ARP – to find out the layer 3 address of device on the other end of the DLCI so you dont need to static map it or similar
- Signalling of Virtual Circuit status messages, therefore if a PVC becomes unreachable all nodes along its path can be aware of this failure so data can be prevented from being sent to indirect failures.
- Multicasting – This extension allows multicast groups to be used over frame relay networks, the higher DLCI numbers reserved by the LMI type are used for this
- Globally signficiant DLCIs – Brilliant!
- Retro flow control with XON/XOFF if the applications using the Frame Relay network know understand FECNs and BECNs

By default LMI messages are sent every 10 seconds, and every sixth message a full status message will be sent which contains more detailed information about each VC, the interface will fail if the interfaces does not receive an LMI message 3 times the hello time, so 30 seconds. You cant actually turn off LMI but you can disable the keepalives with the highly ambiguous command;

Router(config-if)#frame-relay lmi-n391dte ?
  <1-255>  event

Finally you can check the status of LMI with the command;

Router#sh frame lmi

LMI Statistics for interface Serial1/0 (Frame Relay DTE) LMI TYPE = CISCO
  Invalid Unnumbered info 0             Invalid Prot Disc 0
  Invalid dummy Call Ref 0              Invalid Msg Type 0
  Invalid Status Message 0              Invalid Lock Shift 0
  Invalid Information ID 0              Invalid Report IE Len 0
  Invalid Report Request 0              Invalid Keep IE Len 0
  Num Status Enq. Sent 18               Num Status msgs Rcvd 0
  Num Update Status Rcvd 0              Num Status Timeouts 18
  Last Full Status Req 00:00:03         Last Full Status Rcvd never

Finally pretty much every command on the interface beings with frame-relay;

Router(config-if)#frame-relay ?
  accounting             Special accounting instruction
  address-reg            ELMI address registration
  broadcast-queue        Define a broadcast queue and transmit rate
  class                  Define a map class on the interface
  congestion-management  Enable Frame Relay congestion management
  de-group               Associate a DE group with a DLCI
  fragment               Enable end-to-end fragmentation for all PVCs
  fragmentation          Adaptive fragmentation

UPDATE: On some versions of IOS it forces you to set set a LMI hello of between 1 and 255 thereby the above method of using frame relay encapsulation on a P2P link by turning off LMI does not work, in these cases your going to have to use a different encapsulation type or a frame relay switch.

R5(config-if)#frame-relay lmi-n391dte
% Incomplete command.

Recently I have been playing around with RSA SecurID which is commonly used to authenticate VPN users using 2 part authentication, which is great. Although I am way more concerned about using 2 part authentication on admins logging into network devices, luckily its really easy to setup.

The RSA authentication is managed by an RSA application called the RSA Authentication Manager which is currently on version 7.1, this handles replication between servers in a primary to replica’s fashion. Each Authentication Manager can have the RSA “Steel Belted RADIUS” server installed which allows RADIUS clients to authenticate against it. If you are using 2 part authentication you really need to have build in redundancy as if the devices are at a remote site from the RADIUS server they will not be able to perform 2 part authentication in the case of a network or server failure, but we all know that single points of failure are a bad idea?

Authentication Manager Configuration

I wont go to much into how to install and manage the RSA Authentication Manager as there is loads of documentation from RSA on that matter, but there is not much on getting it to authenticate console or vty line users, but luckily its really simple. For each Cisco device that you wish to authenticate users on add it as a RADIUS client in the Authentication Manager, with the model set to “IOS11.1 or later” and then add an associated RSA agent. After this you will need to remember to force replicate the information to the replica RADIUS servers as it does not do this automatically (authentication on the replicas will fail if you don’t do this!)

IOS Configuration

As like most AAA things make sure the aaa new-model is on

aaa new-model

Next we should have sure we have a local user name and password on the system, if the RADIUS servers does not send back a response then we can login using this account. If the response from the RADIUS server comes back as failed from the RADIUS server it will NOT check the local username and password, so this will only be used if the system receive an invalid or no response form the RADIUS server.

username cisco privilege 15 password 0 cisco

Now to enable the RADIUS servers group to be used for the authenticating users on login.

aaa authentication login default group radius line enable local

Now to configure the RADIUS servers, add a separate line for each additional server. It defaults to the standard ports 1645 for authorisation and 1646 for accounting. If there are multiple RADIUS servers it will do a full set of timeouts and retransmits to each one before moving onto the next server.

radius-server host 10.0.0.10 auth-port 1645 acct-port 1646 key password

As I mentioned if anything goes wrong with the RADIUS servers it will fail back to using the locally set username and password, using the default time outs, as waiting for the default timemouts this feels like an eternity so we should change them.

radius-server retransmit 3
radius-server timeout 10

Now give it a test, it even happily support next tokencode mode (see the image), this is where the Authentication Manager can ask you to enter your next token if it thinks your token is starting to drift time abit or it just wants to make sure you actually have the token.

Troubleshooting
#show radius statistics is a good show command to check the response times and make sure everything is singing along well

DistSwitch#show radius statistics
       Maximum inQ length: 1
     Maximum waitQ length: 1
     Maximum doneQ length: 1
     Total responses seen: 53
   Packets with responses: 53
Packets without responses: 17
   Average response delay: 3336 ms
   Maximum response delay: 35048 ms
Number of Radius timeouts: 73
     Duplicate ID detects: 0

  Elapsed time since counters last cleared: 1w2d6h22m

Troubleshooting is pretty simple with #debug radius

User Access Verification

Username: exampleuser
Password:

1w1d: RADIUS: ustruct sharecount=1
1w1d: RADIUS: Initial Transmit tty0 id 45 10.10.0.10:1645, Access-Request, len 66
1w1d:         Attribute 4 6 0A0A34A0
1w1d:         Attribute 5 6 00000000
1w1d:         Attribute 61 6 00000000
1w1d:         Attribute 1 10 62722164
1w1d:         Attribute 2 18 DC6BDD95
DistSwitch>
1w1d: RADIUS: Received from id 45 10.10.20.158:1645, Access-Accept, len 80
1w1d:         Attribute 25 60 53425232
1w1d: RADIUS: saved authorization data for user 80E96540 at 80E95D30
DistSwitch>
DistSwitch>ena
DistSwitch#

If that’s not enough information and your getting alot of timeouts try using Wireshark with a port filter on UDP 1645 will allow you to see the RADIUS rejects, accepts, and challenges.

If the server appears to be rejecting some requests using the real time authentication activity monitor on the RSA Authentication Manager will provide much more detailed information of the reason for the reject or accept.