Virtual Routing and Forwarding

Virtual routing and forwarding (VRF) is a technology included in IP
(Internet Protocol) network routers that allows multiple instances of a
routing table to exist in a router and work simultaneously. This
increases functionality by allowing network paths to be segmented
without using multiple devices. Because traffic is automatically
segregated, VRF also increases network security and can eliminate the
need for encryption and authentication. Internet service providers
(ISPs) often take advantage of VRF to create separate virtual private
networks (VPNs) for customers; thus the technology is also referred to
as VPN routing and forwarding.

VRF acts like a logical router, but while a logical router may include
many routing tables, a VRF instance uses only a single routing table.
In addition, VRF requires a forwarding table that designates the next
hop for each data packet, a list of devices that may be called upon to
forward the packet, and a set of rules and routing protocols that
govern how the packet is forwarded. These tables prevent traffic from
being forwarded outside a specific VRF path and also keep out traffic
that should remain outside the VRF path.

Using the Capture command on a PIX firewall

A vital tool to use when troubleshooting computer networking problems and monitoring computer networks is a packet sniffer. That being said, one of the best methods to use when troubleshooting connection problems or monitoring suspicious network activity in a Cisco Systems PIX firewall is by using the capture command. Many times Cisco TAC will request captures from a PIX in PCAP format for open problem tickets associated with unusual problems or activity associated with the PIX and the network.

The capture command was first introduced to the PIX OS in version 6.2 and has the ability to capture all data that passes through the PIX device. You can use access-lists to specify the type of traffic that you wish to capture, along with the source and destination addresses and ports. Multiple capture statements can be used to attach the capture command to multiple interfaces. You can even copy the raw header and hexadecimal data in PCAP format to a tftp server and open it with TCPDUMP or Ethereal.

• NOTE: You must be in privileged mode to invoke the capture command.

Below is the command usage and syntax description per Cisco's PIX OS 7.0 documentation:

To enable packet capture capabilities for packet sniffing and network fault isolation, use the capture command. To disable packet capture capabilities, use the no form of this command (see the "Usage Guidelines" section for additional information about the no form of this command).

capture capture_name [access-list access_list_name] [buffer buf_size] [ethernet-type type] [interface interface_name] [packet-length bytes] [circular-buffer]

capture capture_name type asp-drop [drop-code] [buffer buf_size] [circular-buffer] [packet-length bytes]

capture capture_name type isakmp [access-list access_list_name] [buffer buf_size] [circular-buffer] [interfacepacket-length bytes] interface_name] [

capture capture_name type raw-data [access-list access_list_name] [buffer buf_size] [circular-buffer] [ethernet-type type] [interface interface_name] [packet-length bytes]

capture capture_name type webvpn user webvpn-user [url url]

no capture capture_name

 Syntax Description:

access-list access_list_name	(Optional) Selects packets based on IP or higher fields for a specific access list identification.
buffer buf_size	(Optional) Defines the buffer size used to store the packet in bytes.
capture_name	Specifies the name of the packet capture.
circular-buffer	(Optional) Overwrites the buffer, starting from the beginning, when the buffer is full.
ethernet-type type	(Optional) Selects an Ethernet type to capture.
interface interface_name	(Optional) Specifies the interface on which to use packet capture, where interface_name is the name assigned to the interface by the nameif command.
packet-length bytes	(Optional) Sets the maximum number of bytes of each packet to store in the capture buffer.
type asp-drop drop-code	(Optional) Captures packets dropped for a reason. You can specify a particular reason by using the drop-code argument. Valid values for the drop-code argument are listed in the "Usage Guidelines" section, below.
type isakamp	(Optional) Captures encrypted and decrypted ISAKMP payloads.
type raw-data	(Optional) Captures inbound and outbound packets on one or more interfaces. This is the default.
type webvpn	(Optional) Captures WebVPN data for a specific WebVPN connection.
url url	(Optional) Specifies a URL for a WebVPN connection capture.
user webvpn-user	(Optional) Specifies a username for a WebVPN capture.

 The Capture command defaults are as follows:

• The capture type is raw data.
• The buffer size is 512 KB.
• All the Ethernet types are accepted.
• All the IP packets are matched.
• The packet-length is 68 bytes.

 Since the documentation above is not very easy to interpret for a beginner, I will be providing a simple monitoring situation and example below to help familiarize you with the commands associated with running a packet capture on a Cisco Secure Pix Firewall.

EXAMPLE:  (NOTE: The following scenario is made up, the domain and IP addresses are invalid and purely for example.) You are wanting to monitor traffic between any users and a questionable Internet website from the inside to the outside via TCP port 80 for an internal security auditor needing proof of the transaction. The website www.madeupsite.com resolves with the IP address 192.168.1.1. In this example, the internal (Local) IP address is 10.1.1.1 and the external (Global) NAT IP Address is 192.168.2.2 and the PIX firewall is running 7.X code. To accomplish this first we will write an extended access-list to apply to the capture that will allow us to capture any TCP traffic from any source address or port to the destination address 192.168.1.1 port 80 and vice versa. Next we will apply a capture to both the inside and outside interfaces of the firewall such that we can capture all the data specified in the access-list. Then we will then copy the raw captures in PCAP format to a TFTP server on the inside network with the IP address 10.1.1.100 such that the files can be viewed with TCPDUMP or Ethereal. Finally we will remove the captures and access-list from the PIX firewall.

 Start: Secure Shell connection to the PIX:

 ! Go into global config mode and configure an extended access-list permitting any tcp traffic from any source host/port to destination host 192.168.1.1/port 80 and any tcp traffic from source host 192.168.1.1/port 80 to any destination host/port.

PIX# config t

PIX(config)# access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq 80

PIX(config)# access-list webcap line 2 extended permit tcp host 192.168.1.1 eq 80 any

PIX(config)# exit

 ! Exit from global config mode and verify your access-list using the show access-list command.

PIX# show access-list webcap

access-list webcap; 2 elements

access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq www (hitcnt=0)

access-list webcap line 2 extended permit tcp host 192.168.1.1 eq www any (hitcnt=0)

 ! From privileged mode configure two raw-data captures based on the access-list requirements configured above and apply one to the outside interface and one to the inside interface of the PIX firewall.

PIX# capture webcapinside type raw-data access-list webcap interface inside

PIX# capture webcapoutside type raw-data access-list webcap interface outside

 ! Verify your captures using the show capture command.

PIX# show capture

capture webcapinside type raw-data access-list webcap interface inside

capture webcapoutside type raw-data access-list webcap interface outside

 ! In this example we will assume that the captures were on long enough to capture the data below. This data consists of a TCP connection from 10.1.1.1 (Local) / 192.168.2.2 (Global) to 192.168.1.1 over port 80. The capture data is displayed in the PIX console by using the show capture command.

• NOTE: The data captured on the outside interface shows the source as the global IP.

PIX# show capture webcapoutside

17 packets captured

1: 09:03:02.244906 192.168.2.2.2536 > 192.168.1.1.80: S 39829922:39829922(0) win 65535 <mss 1260,nop,nop,sackOK>

2: 09:03:02.275620 192.168.1.1.80 > 192.168.2.2.2536: S 1295066193:1295066193(0) ack 39829923 win 5840 <mss 1380>

3: 09:03:02.275940 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295066194 win 65535

4: 09:03:02.282303 192.168.2.2.2536 > 192.168.1.1.80: P 39829923:39830620(697) ack 1295066194 win 65535

5: 09:03:02.314864 192.168.1.1.80 > 192.168.2.2.2536: . ack 39830620 win 6970

6: 09:03:05.029722 192.168.1.1.80 > 192.168.2.2.2536: . 1295066194:1295067454(1260) ack 39830620 win 6970

7: 09:03:05.030805 192.168.1.1.80 > 192.168.2.2.2536: . 1295067454:1295068714(1260) ack 39830620 win 6970

8: 09:03:05.031309 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295068714 win 65535

9: 09:03:05.064129 192.168.1.1.80 > 192.168.2.2.2536: . 1295068714:1295069974(1260) ack 39830620 win 6970

10: 09:03:05.065182 192.168.1.1.80 > 192.168.2.2.2536: . 1295069974:1295071234(1260) ack 39830620 win 6970

11: 09:03:05.065700 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295071234 win 65535

12: 09:03:05.066296 192.168.1.1.80 > 192.168.2.2.2536: . 1295071234:1295072494(1260) ack 39830620 win 6970

13: 09:03:05.098597 192.168.1.1.80 > 192.168.2.2.2536: . 1295072494:1295073754(1260) ack 39830620 win 6970

14: 09:03:05.099146 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295073754 win 65535

15: 09:03:05.099588 192.168.1.1.80 > 192.168.2.2.2536: . 1295073754:1295075014(1260) ack 39830620 win 6970

16: 09:03:05.100168 192.168.1.1.80 > 192.168.2.2.2536: P 1295075014:1295075958(944) ack 39830620 win 6970

17: 09:03:05.100595 192.168.2.2.2536 > 192.168.1.1.80: . ack 1295075958 win 65535

17 packets shown

 

• NOTE: The data captured on the intside interface shows the source as the local IP.

PIX# show capture webcapinside

17 packets captured

1: 09:03:02.244784 10.1.1.1.2536 > 192.168.1.1.80: S 4015780382:4015780382(0) win 65535 <mss 1260,nop,nop,sackOK>

2: 09:03:02.275651 192.168.1.1.80 > 10.1.1.1.2536: S 2468538302:2468538302(0) ack 4015780383 win 5840 <mss 1380>

3: 09:03:02.275895 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468538303 win 65535

4: 09:03:02.282288 10.1.1.1.2536 > 192.168.1.1.80: P 4015780383:4015781080(697) ack 2468538303 win 65535

5: 09:03:02.314894 192.168.1.1.80 > 10.1.1.1.2536: . ack 4015781080 win 6970

6: 09:03:05.029753 192.168.1.1.80 > 10.1.1.1.2536: . 2468538303:2468539563(1260) ack 4015781080 win 6970

7: 09:03:05.030821 192.168.1.1.80 > 10.1.1.1.2536: . 2468539563:2468540823(1260) ack 4015781080 win 6970

8: 09:03:05.031278 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468540823 win 65535

9: 09:03:05.064144 192.168.1.1.80 > 10.1.1.1.2536: . 2468540823:2468542083(1260) ack 4015781080 win 6970

10: 09:03:05.065197 192.168.1.1.80 > 10.1.1.1.2536: . 2468542083:2468543343(1260) ack 4015781080 win 6970

11: 09:03:05.065670 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468543343 win 65535

12: 09:03:05.066311 192.168.1.1.80 > 10.1.1.1.2536: . 2468543343:2468544603(1260) ack 4015781080 win 6970

13: 09:03:05.098612 192.168.1.1.80 > 10.1.1.1.2536: . 2468544603:2468545863(1260) ack 4015781080 win 6970

14: 09:03:05.099131 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468545863 win 65535

15: 09:03:05.099619 192.168.1.1.80 > 10.1.1.1.2536: . 2468545863:2468547123(1260) ack 4015781080 win 6970

16: 09:03:05.100199 192.168.1.1.80 > 10.1.1.1.2536: P 2468547123:2468548067(944) ack 4015781080 win 6970

17: 09:03:05.100580 10.1.1.1.2536 > 192.168.1.1.80: . ack 2468548067 win 65535

17 packets shown

 ! Now we will copy the raw data that we captured to a tftp server on the inside network with the IP address of 10.1.1.100 in PCAP format using the copy /pcap command.

• ! NOTE: The !!!!! indicates successful transfer of data.

PIX# copy /pcap capture:webcapinside tftp:

Source capture name [webcapinside]? <enter>

Address or name of remote host []? 10.1.1.100

Destination filename [webcapinside]? <enter> ! NOTE: The filename could be changed here.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 NOTE: The !!!!! indicates successful transfer of data.

PIX# copy /pcap capture:webcapoutside tftp:

Source capture name [webcapoutside]? <enter>

Address or name of remote host []? 10.1.1.100

Destination filename [webcapoutside]? <enter> ! NOTE: The filename could be changed here.

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 ! Now we will remove the captures from the PIX firewall using the no form of the capture command.

PIX# no capture webcapinside type raw-data access-list webcap interface inside.

PIX# no capture webcapoutside type raw-data access-list webcap interface outside

 ! Finally we will remove the access-list entries from the PIX firewall using the no form of the access-list command.

PIX# config t

PIX(config)# access-list webcap line 1 extended permit tcp any host 192.168.1.1 eq 80

PIX(config)# access-list webcap line 2 extended permit tcp host 192.168.1.1 eq 80 any

PIX(config)# exit

PIX#

 Now we have accomplished our task and the captures wanted by the auditor can be opened with TCPDUMP or Ethereal from the TFTP server. I hope you've enjoyed this simple tutorial on using the capture command in the PIX firewall. This command can be very powerful and very useful if configured properly.

---------------------------------------------------------------------------------

Article courtesy of www.ComputerNetworkingHelp.com

Cisco Express Forwarding - (CEF)

CEF is mainly used to increase packet switching speed, reducing the overhead and delays introduced by other routing techniques, increasing overall performance. CEF consists of two key components: The Forwarding Information Base (FIB) and adjacencies.

The FIB is similar to the routing table generated by multiple routing protocols, maintaining only the next-hop address for a particular IP-route.

The adjacency maintains layer 2 or switching information linked to a particular FIB entry, avoiding the need for an ARP request for each table lookup. There are five types of adjacencies:

• Null adjacency: Handles packets destined to a NULL interface. Packets with FIB entries pointing to NULL adjacencies will normally be dropped.
• Punt adjacency: Deals with packets that require special handling or can not be switched by CEF. Such packets are forwarded to the next switching layer (generally fast switching) where they can be forwarded correctly.
• Glean adjacency: Handles packets destined for currently attached hosts, but without layer 2 information.
• Discard adjacency: FIB entries pointing to this type of adjacency will be discarded.
• Drop adjacency: Packets pointing to this entry are dropped, but the prefix will be checked.

In order to take full advantage of CEF, it is recommended to use distributed CEF (dCEF), where there is a FIB table on each of the line cards. This avoids the need for querying the main processor or routing table in order to get the next-hop information, performing the fast switching on the line card itself.

CEF currently supports Ethernet, Frame Relay, ATM, PPP, FDDI, Tunnels and HDLC.

Function

#sh ip cef ?

#sh ip cef [source ip] [dest ip] - this cmd will display the next hop information required to get from source to destination.