VISIO network diagram tips

VISIO network diagram tips

Understanding Packet Counters in show policy-map interface Output

Cisco IOS, also referred to as the Layer 3 (L3) processor, and the interface driver use the transmit ring when moving packets to the physical media. The two processors collaborate in this way:

• The interface transmits packets in accordance with the interface rate or a shaped rate.
  
• The interface maintains a hardware queue or transmit ring, where it stores the packets that wait for transmission onto the physical wire.
  
• When the hardware queue or transmit ring fills, the interface provides explicit back pressure to the L3 processor system. The interface notifies the L3 processor to stop dequeuing packets to the interface transmit ring because the transmit ring is full. The L3 processor now stores the excess packets in the L3 queues.
  
• When the interface sends the packets on the transmit ring and empties the ring, it once again has sufficient buffers available to store the packets. It releases the back pressure, and the L3 processor dequeues new packets to the interface.
  

The most important aspect of this communication system is that the interface recognizes that its transmit ring is full and throttles the receipt of new packets from the L3 processor system. Thus, when the interface is congested, the drop decision is moved from a random, last-in/first-dropped decision in the transmit ring first in, first out (FIFO) queue to a differentiated decision based on IP-level service policies implemented by the L3 processor.

What Is the Difference Between "Packets" and "Packets Matched"?

Next, you need to understand when your router uses the L3 queues, since service policies apply only to packets stored in the layer-3 queues.
This table illustrates when packets sit in the L3 queue. Locally generated packets are always process-switched and are delivered first to the L3 queue before they are passed on to the interface driver. Fast-switched and Cisco Express Forwarding (CEF)-switched packets are delivered directly to the transmit ring and sit in the L3 queue only when the transmit ring is full.

Packet Type	Congestion	Non-Congestion
Locally-generated packets, which includes Telnet packets and pings	Yes	Yes
Other packets that are process-switched	Yes	Yes
Packets that are CEF- or fast-switched	Yes	No

Without congestion, there is no need to queue any excess packets. With congestion, packets, which includes CEF- and fast-switched packets, may go into the L3 queue. Refer back to how the Cisco IOS configuration guide defines congestion: "If you use congestion management features, packets accumulating at an interface are queued until the interface is free to send them; they are then scheduled according to their assigned priority and the queuing mechanism configured for the interface."
Normally, the "packets" counter is much larger than the "pkts matched" counter. If the values of the two counters are nearly equal, then the interface currently receives a large number of process-switched packets or is heavily congested. Both of these conditions should be investigated to ensure optimal packet forwarding.


Understanding Packet Counters in show policy-map interface Output

DMVPN, NHRP, RRI

Dynamic Multipoint Virtual Private Network (DMVPN)^[1] is a dynamic tunneling form of a virtual private network (VPN) supported on Cisco IOS-based routers based on the standard protocols, GRE, NHRP and IPsec. DMVPN provides the capability for creating a dynamic-mesh VPN network without having to pre-configure (static) all possible tunnel end-point peers, including IPsec (Internet Protocol Security) and ISAKMP (Internet Security Association and Key Management Protocol) peers. DMVPN is initially configured to build out a hub-and-spoke network by statically configuring the hubs (VPN headends) on the spokes, no change in the configuration on the hub is required to accept new spokes. Using this initial hub-and-spoke network, tunnels between spokes can be dynamically built on demand (dynamic-mesh) without additional configuration on the hubs or spokes. This dynamic-mesh capability alleviates the need for and load on the hub to route data between the spoke networks.

Dynamic Multipoint Virtual Private Network
Cisco IOS DMVPN Overview
DMVPN Explained
Dynamic Multipoint VPN (DMVPN)
Configuring Dynamic Multipoint VPN (DMVPN) using GRE over IPSec between Multiple Routers

Next Hop Resolution Protocol (NHRP) is sometimes used to improve the efficiency of routing computer network traffic over Non-Broadcast, Multiple Access (NBMA) Networks. It is defined in IETF RFC 2332, and further described in RFC 2333.
Configuring NHRP

Reverse route injection (RRI) is the ability for static routes to be automatically inserted into the routing process for those networks and hosts protected by a remote tunnel endpoint. These protected hosts and networks are known as remote proxy identities.

Each route is created on the basis of the remote proxy network and mask, with the next hop to this network being the remote tunnel endpoint. By using the remote Virtual Private Network (VPN) router as the next hop, the traffic is forced through the crypto process to be encrypted.

Enhancements to the default behavior of RRI, the addition of a route tag value, and enhancements to how RRI is configured were added to the Reverse Route Injection feature in Cisco IOS Release 12.3(14)T.

An enhancement was added in Cisco IOS Release 12.4(15)T that allows a distance metric to be set for routes that are created by a VPN process so that the dynamically learned route on a router can take precedence over a locally configured static route.

Reverse Route Injection

SSL VPN over DDNS on Cisco 877W

conf t
 ip domain name domain.com
 cry key gen rsa general-keys label SSL_VPN mod 1024
 crypto pki trustpoint SSL
 enrollment selfsigned
 fqdn none
 subject-name CN=domain.com
 revocation-check crl
 rsakeypair SSL_VPN
 cry pki enr SSL

webvpn gateway ssl-gw1
ip interface Dialer0 port 443
hostname webvpn1
ssl trustpoint SSL
inservice
!

webvpn context vpn1
ssl authenticate verify all
!
url-list "eng"
   url-text "wwwin-eng" url-value "http://wwwin-eng.cisco.com"
!
policy group vpn1
   url-list "eng"
!
 port-forward "MGMT"
   local-port 3000 remote-server "192.168.1.110" remote-port 8080 description "MGMT"
 !
 port-forward "SHARE"
   local-port 3001 remote-server "192.168.1.110" remote-port 80 description "SHARE"
 !
default-group-policy vpn1
gateway ssl-gw1
inservice
!

ip http server
ip http secure-server
ip http access-class 6

SSL VPN and Dynamic DNS - ddns on IOS
Cisco IOS SSL VPN Gateways and Contexts
Cisco SSL VPN Configuration
Cisco VPN Client and Thin-Client SSL VPN (WebVPN) in the same 877 router
Downloading and Installing Cisco Router and Security Device Manager

Anycast

http://en.wikipedia.org/wiki/Anycast
Best Practices in DNS Anycast Service-Provision Architecture
Anycast DNS

Site-to-Site and Extranet VPN Business Scenarios

Tunneling

Tunneling provides a way to encapsulate packets inside of a transport protocol. Tunneling is implemented as a virtual interface to provide a simple interface for configuration. The tunnel interface is not tied to specific "passenger" or "transport" protocols, but rather, it is an architecture that is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme. Because tunnels are point-to-point links, you must configure a separate tunnel for each link.

Tunneling has the following three primary components:

•Passenger protocol, which is the protocol you are encapsulating (AppleTalk, Banyan VINES, Connectionless Network Service [CLNS], DECnet, IP, or Internetwork Packet Exchange [IPX]).

•Carrier protocol, such as the generic routing encapsulation (GRE) protocol or IPSec protocol.

•Transport protocol, such as IP, which is the protocol used to carry the encapsulated protocol.

GRE

GRE is capable of handling the transportation of multiprotocol and IP multicast traffic between two sites, which only have IP unicast connectivity. The importance of using tunnels in a VPN environment is based on the fact that IPSec encryption only works on IP unicast frames. Tunneling allows for the encryption and the transportation of multiprotocol traffic across the VPN since the tunneled packets appear to the IP network as an IP unicast frame between the tunnel endpoints. If all connectivity must go through the home Cisco 7200 series router , tunnels also enable the use of private network addressing across a service provider's backbone without the need for running the Network Address Translation (NAT) feature.

Network redundancy (resiliency) is an important consideration in the decision to use GRE tunnels, IPSec tunnels, or tunnels which utilize IPSec over GRE. GRE can be used in conjunction with IPSec to pass routing updates between sites on an IPSec VPN. GRE encapsulates the clear text packet, then IPSec (in transport or tunnel mode) encrypts the packet.This packet flow of IPSec over GRE enables routing updates, which are generally multicast, to be passed over an encrypted link. IPSec alone can not achieve this, because it does not support multicast.

Using redundant GRE tunnels protected by IPSec from a remote router to redundant headquarter routers, routing protocols can be employed to delineate the "primary" and "secondary" headquarter routers. Upon loss of connectivity to the primary router, routing protocols will discover the failure and route to the secondary Cisco 7200 series router, thereby providing network redundancy.

It is important to note that more than one router must be employed at HQ to provide resiliency. For VPN resilience, the remote site should be configured with two GRE tunnels, one to the primary HQ VPN router, and the other to the backup HQ VPN router.

IPSec

IPSec can be configured in tunnel mode or transport mode. IPSec tunnel mode can be used as an alternative to a GRE tunnel, or in conjunction with a GRE tunnel. In IPSec tunnel mode, the entire original IP datagram is encrypted, and it becomes the payload in a new IP packet. This mode allows a network device, such as a router, to act as an IPSec proxy. That is, the router performs encryption on behalf of the hosts. The source router encrypts packets and forwards them along the IPSec tunnel. The destination router decrypts the original IP datagram and forwards it on to the destination system. Tunnel mode protects against traffic analysis; with tunnel mode, an attacker can only determine the tunnel endpoints and not the true source and destination of the packets passing through the tunnel, even if they are the same as the tunnel endpoints.

Site-to-Site and Extranet VPN Business Scenarios
Point-to-Point GRE over IPsec Design Overview

Cisco Portable Product Sheets – Routing Performance

Router Switching Performance in Packets Per Second (PPS)

Portable Product Sheets – Routing Performance

Cisco Parallel eXpress Forwarding (PXF)

Cisco Parallel eXpress Forwarding (PXF) is used to accelerate forwarding performance on the Cisco 7304 router. PXF is available on the NSE-100 and NSE-150 only; the NPE-G100 does not support PXF. 

PXF Information for the Cisco 7304 Router

Cisco Parallel eXpress Forwarding (PXF) is used to accelerate forwarding performance on the Cisco 7304 router. PXF is available on the NSE-100 and the NSE-150; the NPE-G100 does not support PXF.

The Cisco 7304 router processes packets via one of two processing paths, the PXF processing path or the Route Processor (RP) processing path. Packets directed through the PXF processing path are accelerated, although the PXF processing path is reserved for packets utilizing certain features (for a list of features supported in the PXF processing path and when those features were introduced in the PXF processing path, see the "PXF Features" section). All other packets are processed using the RP path. The RP path is also used when PXF processing, which is enabled by default, is disabled.  

PXF Information 

PXF Information for Cisco 7304 Routers 

ITU-T standard and connectors for access network

The major functions and services performed by the physical layer covers:
Providing a standardized interface to physical transmission media, including

• Mechanical specification of electrical connectors and cables, for example maximum cable length
• Electrical specification of transmission line signal level and impedance
• Radio interface, including electromagnetic spectrum frequency allocation and specification of signal strength, analog bandwidth, etc.
• Specifications for IR over optical fiber or a wireless IR communication link

http://en.wikipedia.org/wiki/Layer_1

The ITU-T V-Series Recommendations on Data communication over the telephone network specify the protocols that govern approved modem communication standards and interfaces.^[1]

V.35 is an ITU-T standard located on layer 1 on the OSI model. Max speed is 2 Mbit/s. Withdrawn ITU-T recommendation for 48 kbit/s data transmission over wideband circuits. The physical and electrical characteristics of this interface are now specified in ITU-T recommendation V.11.
http://en.wikipedia.org/wiki/List_of_ITU-T_V-Series_Recommendations

G.703 is an ITU-T standard for transmitting voice or data over digital carriers such as T1 and E1. G.703 provides specifications for pulse code modulation (PCM).
G.703 also specifies E0 (64kbit/s). For information about E0 audio see G.711.
G.703 is either transported over 75 ohm co-axial cable terminated in BNC or Type 43 connectors or 120 ohm twisted pair cables terminated in RJ48C jacks. The choice is carrier and region dependant.
http://en.wikipedia.org/wiki/G.703

X.21 (sometimes referred to as X21) is an interface specification for differential communications introduced in the mid 1970s by the ITU-T. X.21 was first introduced as a means to provide a digital signaling interface for telecommunications between carriers and customers' equipment. This includes specifications for DTE/DCE physical interface elements, alignment of call control characters and error checking, elements of the call control phase for circuit switching services, and test loops.
When X.21 is used with V.11, it provides synchronous data transmission at rates from 600 bit/s to 10 Mbit/s.
http://en.wikipedia.org/wiki/X21

The D-subminiature or D-sub is a common type of electrical connector. They are named for their characteristic D-shaped metal shield. When they were introduced, D-subs were among the smaller connectors used on computer systems.
http://en.wikipedia.org/wiki/D-subminiature#Network_ports

Voice Over IP - Per Call Bandwidth Consumption

Voice Over IP - Per Call Bandwidth Consumption 

VoIP – Per Call Bandwidth

These protocol header assumptions are used for the calculations:

• 40 bytes for IP (20 bytes) / User Datagram Protocol (UDP) (8 bytes) / Real-Time Transport Protocol (RTP) (12 bytes) headers.
  
• Compressed Real-Time Protocol (cRTP) reduces the IP/UDP/RTP headers to 2or 4bytes (cRTP is not available over Ethernet).
  
• 6 bytes for Multilink Point-to-Point Protocol (MP) or Frame Relay Forum (FRF).12 Layer 2 (L2) header.
  
• 1 byte for the end-of-frame flag on MP and Frame Relay frames.
  
• 18 bytes for Ethernet L2 headers, including 4 bytes of Frame Check Sequence (FCS) or Cyclic Redundancy Check (CRC).
  

Note: This table only contains calculations for the default voice payload sizes in Cisco CallManager or Cisco IOS® Software H.323 gateways. For additional calculations, including different voice payload sizes and other protocols, such as Voice over Frame Relay (VoFR) and Voice over ATM (VoATM), use the TAC Voice Bandwidth Codec Calculator ( registered customers only) tool.
Note: 

Codec Information				Bandwidth Calculations
Codec & Bit Rate (Kbps)	Codec Sample Size (Bytes)	Codec Sample Interval (ms)	Mean Opinion Score (MOS)	Voice Payload Size (Bytes)	Voice Payload Size (ms)	Packets Per Second (PPS)	Bandwidth MP or FRF.12 (Kbps)	Bandwidth w/cRTP MP or FRF.12 (Kbps)	Bandwidth Ethernet (Kbps)
G.711 (64 Kbps)	80 Bytes	10 ms	4.1	160 Bytes	20 ms	50	82.8 Kbps	67.6 Kbps	87.2 Kbps
G.729 (8 Kbps)	10 Bytes	10 ms	3.92	20 Bytes	20 ms	50	26.8 Kbps	11.6 Kbps	31.2 Kbps
G.723.1 (6.3 Kbps)	24 Bytes	30 ms	3.9	24 Bytes	30 ms	33.3	18.9 Kbps	8.8 Kbps	21.9 Kbps
G.723.1 (5.3 Kbps)	20 Bytes	30 ms	3.8	20 Bytes	30 ms	33.3	17.9 Kbps	7.7 Kbps	20.8 Kbps
G.726 (32 Kbps)	20 Bytes	5 ms	3.85	80 Bytes	20 ms	50	50.8 Kbps	35.6 Kbps	55.2 Kbps
G.726 (24 Kbps)	15 Bytes	5 ms		60 Bytes	20 ms	50	42.8 Kbps	27.6 Kbps	47.2 Kbps
G.728 (16 Kbps)	10 Bytes	5 ms	3.61	60 Bytes	30 ms	33.3	28.5 Kbps	18.4 Kbps	31.5 Kbps
G722_64k(64 Kbps)	80 Bytes	10 ms	4.13	160 Bytes	20 ms	50	82.8 Kbps	67.6Kbps	87.2 Kbps
ilbc_mode_20(15.2Kbps)	38 Bytes	20 ms	NA	38 Bytes	20 ms	50	34.0Kbps	18.8 Kbps	38.4Kbps
ilbc_mode_30(13.33Kbps)	50 Bytes	30 ms	NA	50 Bytes	30 ms	33.3	25.867 Kbps	15.73Kbps	28.8 Kbps

QoS Policy Propagation through Border Gateway Protocol (QPPB)

QoS Policy Propagation through Border Gateway Protocol (QPPB) allows you to classify packets by IP precedence based on BGP community lists, BGP autonomous system paths, and access control lists (ACLs). After a packet has been classified, you can use other QoS features such as policing and weighted random early detection (WRED) to specify and enforce policies to fit your business model. 

QoS Policy Propagation Through the Border Gateway Protocol 
Prevent DoS attacks on MPLS VPN common services 
QoS Policy Propagation via BGP(QPPB)的应用 

Cisco 880 Series Integrated Services Routers Data Sheet

Cisco 880 Series Integrated Services Routers Data Sheet 

Table 1. Cisco 880 Series Data Models

Models	WAN Interface	LAN Interfaces	802.11g/n Option	Embedded 3G	Integrated ISDN Dial Backup
Cisco 881	10/100-Mbps Fast Ethernet	4-port 10/100-Mbps managed switch	Yes (Cisco 881W)	Yes (Cisco 881G)	-
Cisco 886 VA	Multimode VDSL2/ADSL2/2+ over ISDN	4-port 10/100-Mbps managed switch	Yes (Cisco 886VAW)	Yes (Cisco 886VAG)	Yes
Cisco 887VA	Multimode VDSL2/ADSL2/2+ over basic telephone service	4-port 10/100-Mbps managed switch	Yes (Cisco 887VAW)	Yes (Cisco 887VAG)	No
Cisco 886	ADSL2/2+ over ISDN (Annex B)	4-port 10/100-Mbps managed switch	Yes (Cisco 886W)	Yes (Cisco 886G)	Yes
Cisco 887	ADSL2/2+ over basic telephone service (Annex A)	4-port 10/100-Mbps managed switch	Yes (Cisco 887W)	Yes (Cisco 887G)	Yes
Cisco 887V	VDSL2 over basic telephone service	4-port 10/100-Mbps managed switch	Yes (Cisco 887V)	Yes (Cisco 887VG)	Yes
Cisco 888	G.SHDSL (ATM)	4-port 10/100-Mbps managed switch	Yes (Cisco 888W)	Yes (Cisco 888G)	Yes
Cisco 888E	G.SHDSL (EFM)	4-port 10/100-Mbps managed switch	Yes (Cisco 888W)	Yes (Cisco 888EG)	Yes
Cisco 888EA	Multimode G.SHDSL (EFM/ATM)	4-port 10/100-Mbps managed switch	No	No	No

Cisco Express Forwarding (CEF)

Process Switching

Process switching is the lowest common denominator in switching paths; it is available on every version of IOS, on every platform, and for every type of traffic being switched. Process switching is defined by two essential concepts:

    1. The forwarding decision and information used to rewrite the MAC header on the packet are taken from the routing table (from the routing information base, or RIB) and the Address Resolution Protocol (ARP) cache, or from some other table that contains the MAC header information mapped to the IP address of each host that is directly connected to the router.

    2. The packet is switched by a normal process running within IOS. In other words, the forwarding decision is made by a process scheduled through the IOS scheduler and running as a peer to other processes on the router, such as routing protocols. Processes that normally run on the router are not interrupted to process switch a packet.

Almost all features that effect packet switching, such as Network Address Translation (NAT) and Policy Routing, make their debut in the process switching path. Once they have been proven, and optimized, these features might, or might not, appear in interrupt context switching.

Interrupt Context Switching

Interrupt context switching is the second of the primary switching methods used by Cisco routers. The primary differences between interrupt context switching and process switching are:

    The process currently running on the processor is interrupted to switch the packet. Packets are switched on demand, rather than switched only when the ip_input process can be scheduled.

    The processor uses some form of route cache to find all the information needed to switch the packet.


Cisco Express Forwarding

Cisco Express Forwarding, also uses a 256 way data structure to store forwarding and MAC header rewrite information, but it does not use a tree. Cisco Express Forwarding uses a trie, which means the actual information being searched for is not in the data structure; instead, the data is stored in a separate data structure, and the trie simply points to it. In other words, rather than storing the outbound interface and MAC header rewrite within the tree itself, Cisco Express Forwarding stores this information in a separate data structure called the adjacency table.

Cisco Adjacency Tables

How to Choose the Best Router Switching Path for Your Network
Understanding Cisco Express Forwarding (CEF)

Understand CEF Punts

The term "punt" is defined by Cisco to describe the action by an interface's device driver of sending a packet "down" to the next fastest switching level. This list defines the order of preferred Cisco IOS switching methods (from fastest to slowest).

    Distributed CEF

    CEF

    Fast switching

    Process switching

A punt occurs under these conditions:

    1. The next lower level did not produce a valid path or, in the case of CEF, a valid adjacency. In other words, if the CEF lookup process failed to find a valid entry in the forwarding information base, the packet is punted to the next available switching path or dropped.

    2. A particular feature or Layer 2 encapsulation is not supported at the lowest level. If CEF supports a particular feature, ownership of a packet is passed through a set of software routines in the CEF "feature path."

    3. A feature requires special handling.

A punt adjacency in CEF is installed when some output feature is not supported in CEF. CEF punts all packets that go to such an adjacency to the next best switching mode, in order to switch all the packets.
How to Verify Cisco Express Forwarding Switching

Logging-enabled access control lists (ACLs) provide insight into traffic as it traverses the network or is dropped by network devices. Unfortunately, ACL logging can be CPU intensive and can negatively affect other functions of the network device. There are two primary factors that contribute to the CPU load increase from ACL logging: process switching of packets that match log-enabled access control entries (ACEs) and the generation and transmission of log messages. Using the configuration commands detailed in this document, administrators can strike a balance between traffic visibility and the corresponding impact on device CPU load.
Understanding Access Control List Logging

Gratuitous ARP

Gratuitous_ARP 

Gratuitous ARP could mean both gratuitous ARP request or gratuitous ARP reply. Gratuitous in this case means a request/reply that is not normally needed according to the ARP specification (RFC 826) but could be used in some cases. A gratuitous ARP request is an AddressResolutionProtocol request packet where the source and destination IP are both set to the IP of the machine issuing the packet and the destination MAC is the broadcast address ff:ff:ff:ff:ff:ff. Ordinarily, no reply packet will occur. A gratuitous ARP reply is a reply to which no request has been made.

Gratuitous ARPs are useful for four reasons:

• They can help detect IP conflicts. When a machine receives an ARP request containing a source IP that matches its own, then it knows there is an IP conflict.
• They assist in the updating of other machines' ARP tables. Clustering solutions utilize this when they move an IP from one NIC to another, or from one machine to another. Other machines maintain an ARP table that contains the MAC associated with an IP. When the cluster needs to move the IP to a different NIC, be it on the same machine or a different one, it reconfigures the NICs appropriately then broadcasts a gratuitous ARP reply to inform the neighboring machines about the change in MAC for the IP. Machines receiving the ARP packet then update their ARP tables with the new MAC.
• They inform switches of the MAC address of the machine on a given switch port, so that the switch knows that it should transmit packets sent to that MAC address on that switch port.
• Every time an IP interface or link goes up, the driver for that interface will typically send a gratuitous ARP to preload the ARP tables of all other local hosts. Thus, a gratuitous ARP will tell us that that host just has had a link up event, such as a link bounce, a machine just being rebooted or the user/sysadmin on that host just configuring the interface up. If we see multiple gratuitous ARPs from the same host frequently, it can be an indication of bad Ethernet hardware/cabling resulting in frequent link bounces. 

Proxy Server - SOCKS, HTTP proxy

Types of proxy

Proxy server can be placed in the user's local computer or at various points between the user and the destination servers on the Internet.

• A proxy server that passes requests and responses unmodified is usually called a gateway or sometimes tunneling proxy.
• A forward proxy is an Internet-facing proxy used to retrieve from a wide range of sources (in most cases anywhere on the Internet).
• A reverse proxy is (usually) an Internet-facing proxy used as a front-end to control and protect access to a server on a private network, commonly also performing tasks such as load-balancing, authentication, decryption or caching. 
• Performance Enhancing Proxies (PEPs) are network agents designed to improve the end-to-end performance of some communications protocol. Performance Enhancing Proxies standards are defined in RFC 3135 (Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations) and RFC 3449 (TCP Performance Implications of Network Path Asymmetry).

SOCKet Secure (SOCKS) is an Internet protocol that routes network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server will proxy TCP connections to an arbitrary IP address as well as providing a means for UDP packets to be forwarded.

Comparison

SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make and may be used for any form of TCP or UDP socket connection, whereas an HTTP proxy works for HTTP protocol and HTTP only (and HTTP is usually transported over a TCP connection). HTTP proxies take an HTTP request and forward it to an HTTP server. Though HTTP proxying has a different use-case in mind, the CONNECT^[8] method allows one to forward TCP connections^{[citation needed]}, there is however no mechanism for UDP proxying. The following examples show the difference between the two methods:

SOCKS

Bill wishes to communicate with Jane over the internet, but a firewall exists on his network between them. Bill is not authorized to communicate through it himself. He connects to the SOCKS proxy on his network and sends it information about the connection he wishes to make to Jane. The SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane. For more information on the technical specifics of the SOCKS protocol, see the sections below.

HTTP

Bill wishes to download a web page from Jane, who runs a web server. Bill cannot directly connect to Jane's server, as a firewall has been put in place on his network. In order to communicate with the server, Bill connects to his network's HTTP proxy. His web browser communicates with the proxy in exactly the same way it would with the target server—it sends a standard HTTP request header. The HTTP proxy reads the request and looks for the host header. It then connects to the server specified in the header and transmits any data the server replies with back to Bill.^[9]

Interaction with firewalls

Many company and university network administrators set firewall rules that prevent users from connecting to any internet service apart from webpages. Both the SOCKS and HTTP proxy protocols can be used to pierce these firewalls. SOCKS is usually used to create a raw TCP connection, and the HTTP proxy protocol can do the same with the CONNECT method. In both cases a TCP connection is created from the client to the proxy server, and the IP address and port to which the client requests a connection is communicated over the connection. In both cases the proxy server can grant, reject, redirect and alter connection requests as it likes. HTTP proxies are traditionally more HTTP protocol aware and do more high level filtering (even though that usually only applies to GET and POST methods, not CONNECT). SOCKS proxies can also forward UDP traffic and work in reverse: HTTP proxies cannot.

http://en.wikipedia.org/wiki/SOCKS
HTTP proxying
Performance Enhancing Proxy
rfc2616 - HTTP

Cisco 870 Series ISR comparison

Cisco 870 Series Integrated Services Routers for Small Offices

Table 1. Cisco 870 Series Models

Models	WAN Interface	LAN Interfaces	802.11b/g Option	Integrated ISDN Dial Backup
Cisco 871	10/100 Mbps Fast Ethernet	4-port 10/100 Mbps managed switch	Yes (Cisco 871W)	-
Cisco 876	Asymmetric DSL (ADSL) over ISDN	4-port 10/100 Mbps managed switch	Yes (Cisco 876W)	Yes
Cisco 877	ADSL over POTS	4-port 10/100 Mbps managed switch	Yes (Cisco 877W)	-
Cisco 878	G.SHDSL	4-port 10/100 Mbps managed switch	Yes (Cisco 878W)	-

How to run batch commands using Plink program

How to run batch commands using Plink program in windows enviroment

for /f %i in (devices.txt) do c:\putty\plink.exe cisco@%i -pw
P@55W0rD! -m command.txt >> device_utilization.txt
(if you put this in a batch file, be sure to use "%%i" and not the
"%i" as the batch will strip the single percents)

Reference: Automate Cisco ssh connections with plink in Windows


Very useful Plink tips 

Host wants to forward traffic from local port 1234 to 80.101.152.38:443 via a SSH server 

@echo off
plink.exe -v -x -a -T -C -noagent -ssh -L 127.0.0.1:1234:80.101.152.38:443 <username>@<IP SSH server>

from: Tunneling sessions via Plink

Linux syntax:

Host wants to tunnel from local port 53 to destination port 5900 via a SSH server

ssh -L 53:[destination IP]:5900 [SSH server IP]

SSH Tunneling

Cisco IOS: display open TCP and UDP ports

With the introduction of Control Plane Policing features (available from 12.3(4)T), you can easily inspect all the open ports (servers and clients) on a router with the show control-plane host open-ports command, resulting in a printout very similar to the netstat -a printout on a Unix/Windows workstation.

Display open TCP and UDP ports

QoS Bandwidth Estimation

Feature Overview of QoS Bandwidth Estimation

Allocating adequate bandwidth is key to ensuring the network performance required for applications. However, allocating too much bandwidth can be costly. The QoS Bandwidth Estimation feature in Cisco IOS software uses Corvil Bandwidth technology to allow you, as a network manager, to determine the bandwidth requirements to achieve user-specified quality of service (QoS) targets for networked applications.

Corvil Bandwidth can determine the minimum bandwidth required to deliver traffic within customer-specified QoS targets with statistical reliability. From a network management perspective, an application's QoS requirements are characterized with respect to its sensitivity to delay and packet loss. Corvil Bandwidth provides a way to specify limits for delay and packet loss, and get a tight estimate of the minimum bandwidth essential to achieve desired application performance.

Corvil Bandwidth achieves its results by taking very short timescale (8-millisecond) snapshots of traffic and summarizing them in traffic descriptors that place very low overhead on the router because each descriptor has fewer than 300 bytes. These traffic descriptors record the exceptional events (bursts) and are input to the Corvil Bandwidth algorithm to calculate the minimum bandwidth required to deliver the user-specified QoS target for the observed traffic. (The QoS target is specified in terms of sensitivity to traffic delay and packet loss. For example, voice over IP [VoIP] traffic is very sensitive to both, whereas e-mail file transfer is sensitive to neither.)

As a result, turning on Corvil Bandwidth in the router allows you to obtain bandwidth values that can be used directly to configure the existing Cisco IOS QoS mechanisms on the router to achieve the required application performance as efficiently as possible. 

Prerequisites for QoS Bandwidth Estimation  

• Before using this feature, configure a class map and a policy map using the Modular Quality of Service (QoS) Command-Line Interface (CLI) (MQC), and specify the appropriate match criteria.

•This feature requires the purchase of a Cisco IOS software feature license. The right to use this feature is not included in the base Cisco IOS software license for the software image. 

Restrictions for QoS Bandwidth Estimation

This feature supports policy maps that are attached to interfaces in an output direction only.  

QoS Bandwidth Estimation 

 

Load Balancing Web Applications

All copied from: Load Balancing Web Applications

Why: High availability and Scalability

How:  a) DNS round robin
          b) Hardware load balancers

Advantages of DNS Round Robin
1. Inexpensive
2. Easy to set up

Disadvantages of DNS Round Robin
1. No support for server affinity
2. No support for high availability

Advantages of Hardware Load Balancers
1. Server affinity.
2. High Availability Through Failover

Disadvantages of Hardware Load Balancers
1. Expensive
2. Complicated to setup

Load Balancing HTTPS Requests
1. Web server proxies
2. Hardware SSL decoders

Understand Unknown Protocol Drops

Understand Unknown Protocol Drops
Unknown protocol drops is a counter on the interface. It is caused by protocols that are not understood by
the router/switch.
This example of the show running−config interface command shows the unknown protocol drops on the
Gigabit Ethernet 0/1 interface.
Switch#sh run int Gig 0/1
GigabitEthernet0/1 is up, line protocol is up
Hardware is BCM1125 Internal MAC, address is 0000.0000.0000 (via 0000.0000)
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full−duplex, 1000Mb/s, media type is RJ45
output flow−control is XON, input flow−control is XON
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:05, output 00:00:03, output hang never
Last clearing of "show interface" counters 16:47:42
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
3031 packets input, 488320 bytes, 0 no buffer
Received 3023 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 63107 multicast, 0 pause input
0 input packets with dribble condition detected
7062 packets output, 756368 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
2015 unknown protocol drops
4762 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
Unknown protocol drops are normally dropped because the interface where these packets are received is not
configured for this type of protocol, or it can be any protocol that the router does not recognize.

For example, if you have two routers connected and you disable CDP on one router interface, this results in
unknown protocol drops on that interface. The CDP packets are no longer recognized, and they are dropped.

Cisco - Troubleshooting Switch Port and Interface Problems