Shell Scripting: Convert Uppercase to Lowercase

vName=$(echo $1 | tr "[:upper:]" "[:lower:]" | sed 's/\.$//')
echo $vName
wtyang@jump0.nmbeijing:~$ ./test.scr AABBCCDDEE.
aabbccddee

Ref: http://www.cyberciti.biz/faq/linux-unix-shell-programming-converting-lowercase-uppercase/
http://ss64.com/bash/tr.html

Test download speed from a Cisco router

Customer_router(config)#ip route 87.51.34.132 255.255.255.255 150.200.1.253
Customer_router(config)#ip host ftp.freebsd.org 87.51.34.132
Customer_router(config)#ip ftp source-interface vlan 1
Customer_router#copy ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-RC2/doc.txz flash:
Destination filename [doc.txz]?
Accessing ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.0-RC2/doc.txz...
Loading pub/FreeBSD/releases/i386/i386/9.0-RC2/doc.txz !!!!!!
[OK - 1443296/4096 bytes]

1443296 bytes copied in 29.136 secs (49537 bytes/sec)
Customer_router00_ITASS#

ip flow-top-talkers

In the following example, a maximum of four top talkers is configured. The sort criterion is configured to sort the list of top talkers by the total number of bytes for each top talker.

Router(config)# ip flow-top-talkers

Router(config-flow-top-talkers)# top 4

Router(config-flow-top-talkers)# sort-by bytes 

Reference:Cisco site 

ADSL firmware upgrade on 887/877/857 router

I cannot find instructions on how to use the latest 4.0.18 ADSL firmware on an 887 router.

I've downloaded adsl_alc_20190_4.0.018.bin from the website and copied it to flash, but cannot find any instructions on applying the firmware. Tried rebooting but made no difference.

What commands, etc, am I meant to use to make use of this ADSL firmware release ?

Thank you in advance.

Roger. 

Correct Answer by kmccourt  on May 18, 2010 11:40 AM

Assuming the 887 behaves like the 877/857, the file has to be renamed to:

adsl_alc_20190.bin

and then you reboot.

Ref: https://supportforums.cisco.com/thread/2017655

Problem with ICMP filtering and PMTU-D

Say the customer PC sends a 1500-byte packet, with DF set (which is the default for everything these days).  It’s fine on the switch, it’s fine on our router.  Somewhere between us and the server, it finds a link that only has an MTU of 1400.  The router attached to that link can’t fragment (DF is set), so it sends an ICMP error message back explaining that the packet is too big, and that the originating host must send smaller packets.  That ICMP packet is not part of the data flow, so the firewall will drop it unless configure to pass it.  If the PC never sees the error message, all it knows is that it never got a reply, so it keeps re-transmitting the 1500-byte packet until it eventually times out.

Now, to the problem with ICMP filtering and PMTU-D

In this case, if the ICMP can't fragment errors can not get back to the source host due to a filter, the host will never know that the packets it is sending are too large. This means it will keep trying to send the same large packet, and it will keep being dropped--silently dropped from the view of any system on the other side of the filter. While a small handful of systems that implement PMTU-D also implement a way to detect such situations, most don't and even for those that do it has a negative impact on performance and the network.
If this is happening, typical symptoms include the ability for small packets (eg. request a very small web page) to get through, but larger ones (eg. a large web page) will simply hang. This situation can be confusing to the novice administrator because they obviously have some connectivity to the host, but it just stops working for no obvious reason on certain transfers.
There is one solution, and several workarounds, for this problem. They include:

http://www.znep.com/~marcs/mtu/ 
Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC

VPN VRF import map /export map

import map /export map are usually used for selectively import or export prefixes [by adding / filtering the RT values] , which makes inter-vrf communications more flexible.

Whereas route-target export / route-target import will unconditionally import or export

BGP Community Lists

There are two types of community list. One is standard community list and another is expanded community list. Standard community list defines communities attribute. Expanded community list defines communities attribute string with regular expression. Standard community list is compiled into binary format when user define it. Standard community list will be directly compared to BGP communities attribute in BGP updates. Therefore the comparison is faster than expanded community list.

http://www.quagga.net/docs/docs-multi/BGP-Community-Lists.html
http://www.quagga.net/docs/docs-multi/BGP-Extended-Community-Lists.html
http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_s1gt.html
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gtnextcl.html#wp1050903

Queueing

Hardware queue, software queue
https://learningnetwork.cisco.com/thread/4326

Hardware queue
http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml
http://wiki.nil.com/Queuing_Principles_in_Cisco_IOS/FIFO

Cisco switching options
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00800a7306.shtml

BGP only send out prefixes which have been already in the routing table.

BGP only send out prefixes which have been already in the routing table.

MTU of ipsec GRE

MTU from http://www.faqs.org/rfcs/rfc1122.html

The maximum transmission unit, i.e., the size of the
              largest packet that can be transmitted.

         The terms frame, packet, datagram, message, and segment are
         illustrated by the following schematic diagrams:

         A. Transmission on connected network:
           _______________________________________________
          | LL hdr | IP hdr |         (data)              |
          |________|________|_____________________________|

           <---------- Frame ----------------------------->
                    <----------Packet -------------------->

         B. Before IP fragmentation or after IP reassembly:
                    ______________________________________
                   | IP hdr | transport| Application Data |
                   |________|____hdr___|__________________|

                    <--------  Datagram ------------------>
                             <-------- Message ----------->
           or, for TCP:
                    ______________________________________
                   | IP hdr |  TCP hdr | Application Data |
                   |________|__________|__________________|

                    <--------  Datagram ------------------>
                             <-------- Segment ----------->

MTU explaination copy from http://packetlife.net/blog/2008/nov/5/mtu-manipulation/

Overhead calculation of GRE over IPSec (assume ESP-DES & ESP-MD5-HMAC):

ESP overhead (with authentication) : 31 ~ 38 bytes

GRE header: 24 bytes

IP header: 20 byes

 GRE over IPSec with tunnel mode introduces ~75 bytes overhead, GRE over IPSec with transport mode introduces ~55 bytes overhead


http://ieoc.com/forums/t/10365.aspx
http://packetlife.net/blog/2008/nov/5/mtu-manipulation/
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

Solutions for the ipsec over GRE:

1. tunnel path-mtu-discovery on the tunnel interface
2. Use the ip tcp adjust-mss command on the tunnel interfaces
3. Use policy routing on the ingress interface of the router and configure a route map to clear the DF bit in the data IP header before it gets to the GRE tunnel interface.

route-map CLEAR-DF permit 10
 set ip df 0
!
interface <LAN>
 ip policy route-map CLEAR-DF
!

4. Increase the "ip mtu" on the GRE tunnel interface to be equal to the outbound interface MTU. This will allow the data IP packet to be GRE encapsulated without fragmenting it first. The GRE packet will then be IPsec encrypted and then fragmented to go out the physical outbound interface. In this case you would not configure tunnel path-mtu-discovery command on the GRE tunnel interface. This can dramatically reduce the throughput because IP packet reassembly on the IPsec peer is done in process-switching mode.   

Troubleshooting BGP peer flapping issue

Enable “bgp log-neighbor-changes” so you get a log message when a peer flaps

%BGP-5-ADJCHANGE: neighbor 1.1.1.1 Down BGP Notification sent
%BGP-3-NOTIFICATION: sent to neighbor 1.1.1.1 4/0 (hold time expired) 0 bytes
R2#show ip bgp neighbor 1.1.1.1 | include Last reset
Last reset 00:01:02, due to BGP Notification sent, hold time expired

• We are not receiving keepalives from the other side!

Let’s take a look at our peer!

• Hellos are stuck in OutQ behind update packets!
• Notice that the MsgSent counter has not moved

Possible causes
Remote router is not healthy (OutQ)
Lower layer problems (IP)

Things to check
MTU values
Traffic shaping
Rate-limiting parameters

• Looks like a Layer 2 problem
• At this point we have verified that BGP is not at fault
• Next step is to troubleshoot layer 2…

Ref: http://meetings.ripe.net/ripe-44/presentations/ripe44-eof-bgp.pdf
http://docstore.mik.ua/cisco/pdf/routing/Cisco%20Networkers%20-%20Troubleshooting%20Bgp%20In%20Large%20Ip%20Networks.pdf

Match VoIP ports

ip access-list extended REAL-TIME-CLASSIFY
    remark VOIP (H323/SIP/IAX/IAX2)
    permit udp any any eq 4569
    permit udp any eq 4569 any
    permit udp any any eq 5036
    permit udp any eq 5036 any
    permit udp any any eq 5060
    permit tcp any any eq 5060
    permit udp any eq 5060 any
    permit tcp any eq 5060 any
    permit udp any any eq 1719
    permit udp any eq 1719 any
    remark VOIP (RTP) traffic
    permit udp any any range 16384 32767
    permit udp any range 16384 32767 any

Ref: http://www.voip-info.org/wiki/view/QoS+Cisco

VoIP packet size

 Very good notes from learningnetwork.cisco.com


The best explanation is in chapter 5 of the Authorized Self-Study Guide for Cisco Voice over IP (CVoice) Second Edition by Kevin Wallace.  Basically, the formula is Bytes_per_sample = Sample_Size * CODEC_Bandwidth / 8 plus overhead.
So, if your sample size is 20 ms (.02 seconds)  and you are using the G.711 CODEC, then your basic voice information requires
.02 * 64000 / 8 = 160 bytes per sample.  To that, you must add the overhead, which would be 20 bytes for the IP header,
8 bytes for the UDP header, and 12 bytes for the RTP header (to make sure your packets are in the correct order at the receiving end).
So, each voice packet will require 200 bytes.  Then, you need to add your Layer 2 overhead (at least 18 bytes for Ethernet). 
So, each frame will require at least 218 bytes.  And you may also have trunk or tunneling overhead to consider.

Yes, voice packets are small, but you need a lot of them to carry voice.  That's why we use compression techniques.
cRTP compresses the IP/UDP/RTP header to either 2 or 4 bytes (4 if you implement check sum).  This significantly reduces the overhead.

In addition, you can use a CODEC that requires lower bandwidth.  The G.729 CODEC only requires 8000 bits per second, so if you used
G.729 and RTP header compression you would get
.02 * 8000 / 8 = 20 bytes of voice information plus 4 bytes for IP/UDP/RTP for an IP packet size of 24 bytes.  Then, you can add your
Layer 2 overhead, whatever it is.

Chapter 1 of the CCNP ONT Official Exam Certification Guide by Amir Ranjbar also contains a lot of good information.

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml
https://learningnetwork.cisco.com/thread/11162

Next Hop Resolution Protocol (NHRP)

References:
http://en.wikipedia.org/wiki/Next_Hop_Resolution_Protocol
http://www.cisco.com/en/US/docs/ios/12_4/ip_addr/configuration/guide/hadnhrp.html#wp1054887
http://www.netcraftsmen.net/resources/archived-articles/433.html
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_white_paper09186a008018983e.shtml

show derived-config

Usage Guidelines

Configuration commands can be applied to an interface from sources such as static templates, dynamic templates bound by resource pooling, dialer interfaces, AAA per-user attributes and the configuration of the physical interface. The show derived-config command displays all the commands that apply to an interface.

The output for the show derived-config command is nearly identical to that of the show running-config command. It differs when the configuration for an interface is derived from a template, a dialer interface, or some per-user configuration. In those cases, the commands derived from the template, dialer interface, and so on, will be displayed for the affected interface.

If the same command is configured differently in two different sources that apply to the same interface, the command coming from the source that has the highest precedence will appear in the display.

Examples

The following examples show sample output for the show running-config and show derived-config commands for serial interface 0:23 and dialer interface 0. The output of the show running-config and show derived-config commands is the same for dialer interface 0 because none of the commands that apply to that interface are derived from any sources other than the configuration of the dialer interface. The output for the show running-config and show derived-config commands for serial interface 0:23 differs because some of the commands that apply to serial interface 0:23 come from dialer interface 0.

Router# show running-config interface Serial0:23 

Ref: http://www.cisco.com/en/US/docs/ios/12_1/configfun/command/reference/frd2002.html#wp1019868