Table Of Contents
Cisco IOS IPsec Accounting
with Cisco IOS NetFlowCisco IOS IPsec Network Security
IPsec Network Security Operation
Enabling Cisco IOS NetFlow on Interface
Test 1—Cisco IOS NetFlow on FastEthernet 1/0 interface of Cisco7200-2 (tunnel head) Series Router
Test 2—Cisco IOS NetFlow on FastEthernet 2/0 Interface of Cisco 7200-2 (tunnel head) Series Router
Appendix A Cisco IOS SAA configurations
Appendix C—Router Versions and Configurations
White Paper
Cisco IOS IPsec Accounting
with Cisco IOS NetFlow
Introduction
Cisco IOS® NetFlow is the primary denial of service (DoS) identification, accounting, and analysis technology for IP networks at Cisco and in the networking industry. Cisco IOS NetFlow provides valuable information about network users, applications usage, timing, and traffic direction on the network. Cisco is a leader in IP traffic flow technology and invented Cisco IOS NetFlow.
Cisco IOS IPsec Network Security
Cisco IOS IPsec provides security for transmission of sensitive information over unprotected networks (ie: Internet). IPsec acts as the network layer by protecting and authenticating IP packets between participating IPsec devices ("peers"), such as Cisco routers.
This document will discuss how Cisco IOS NetFlow can be leveraged to provide accounting information in an IPsec tunneling network topology.
For more information please visit:
•
Cisco IOS NetFlow:
http://www.cisco.com/go/netflow
•
Cisco IOS NetFlow Operation
Cisco IOS NetFlow provides a detailed record of the traffic on a network. Traffic records are produced in a summarized and concise form. The flow information can be used for a variety of purposes including accounting, billing, network planning, traffic engineering, and user/application monitoring.
Cisco IOS NetFlow keeps a continuous track of packets and categorizes them by IP flows. Each time Cisco IOS NetFlow detects a packet belonging to a new IP flow it creates a new entry in the Cisco IOS NetFlow cache and starts a timer for the following events:
•
•
If a flow does not have packets appearing for a preconfigured amount of time, then it has "expired". The default expiration time is fifteen seconds. As flows "expire" on the router, they are removed from the live Cisco IOS NetFlow cache and exported in the Cisco IOS NetFlow User Datagram Protocol (UDP) export packets to the collector, which then files, filters, and aggregates the data per the customers' specifications.
Cisco IOS NetFlow classifies packets by the way of flows. Traditionally, and for the purposes of this document, Cisco IOS NetFlow flow is defined by seven key fields:
•
•
•
•
•
•
•
If two packets have the same entries for all seven fields, then they belong to the same flow.
The router maintains a live Cisco IOS NetFlow cache to track the current flows. Once those current flows expire, the flows are removed from the Cisco IOS NetFlow cache to be exported to the collector. The collector is an application that runs on a UNIX, Linux, Window NT, or HP-UX server for the purposes of storing, filtering, aggregating, and compressing the Cisco IOS NetFlow flow records.
Figure 1 shows the output of Cisco IOS NetFlow, which was produced by the "show ip cache flow" command:
Figure 1
Sample Cisco IOS NetFlow Output
The first portion of output lines, one through five, is the packet size distribution, which provides information about what percentage of packets of each size has passed through this router. This information can be very useful for network troubleshooting, traffic engineering, and capacity planning.
Lines six through eight describe the parameters assigned to Cisco IOS NetFlow itself. The default number of flows that can be cached by Cisco IOS NetFlow is 65536. In this case, two of these cache entries were in use, and only 65534 cache entries were available for new flows.
Lines nine through eleven show how long a particular flow will stay in the cache. In this example, if there has been no activity on a flow for fifteen seconds, the entry would be purged from the cache. Additionally, if an entry has been in the cache for thirty minutes, and at least one packet per fifteen seconds was there, then it is purged and a new flow entry is created. Connection-oriented entries, such as telnet or File Transfer Protocol (FTP), are purged as soon as the session is closed, which is based on a RST or FIN TCP Flag.
Lines twelve through sixteen provide a breakdown of flows by protocol. This is an ideal tool for the network administrator, because it provides traffic distribution by type. This information can be used very effectively in application monitoring.
Lines seventeen through nineteen show the actual Cisco IOS NetFlow cache entries. This portion of the Cisco IOS NetFlow output will be referred as the `flow information table' and will be the focus of the subsequent sections later in this document.
The field titles have the following definitions:
•
•
•
•
•
•
•
•
For purposes of clarity and brevity, only selected portions of router configurations and router console output will be displayed in the remainder of this document. For complete configurations and console output please refer to the appendices.
For the purposes of this document, any data will not be exported outside of the router; therefore, flow information will be examined prior to expiration of the router's Cisco IOS NetFlow live cache.
IPsec Network Security Operation
IPsec combines the aforementioned security technologies into a complete system that provides confidentiality, integrity, and authenticity of IP datagrams. IPsec refers to several related protocols as defined in the new Request for Comments (RFC) 2401-2411 and 2451.The original IPsec RFCs 1825-1829 are now obsolete. These standards include:
•
–
–
•
–
–
–
–
IPsec Encapsulation
IPsec has two methods of encapsulation:
•
•
Each differs in their application and in the amount of overhead added to the passenger packet.
IPsec Tunnel Mode
IPsec Tunnel Mode encapsulates and protects an entire IP packet. Because IPsec tunnel mode encapsulates or hides the IP header of the packet, a new IP header must be added for the packet to be successfully forwarded. The encrypting routers themselves own the IP addresses used in these new headers. Tunnel mode may be employed with Encapsulating Security Payload (ESP) and/or Authentication Header. Using tunnel mode results in additional packet expansion of approximately 20 bytes associated with the new IP header. Tunnel mode expansion of the IP packet is depicted in Figure 2.
Figure 2
IPsec Tunnel Mode Encapsulation
GRE Transport Mode
GRE Transport mode is recommended to be used only when deploying GRE tunnel for the Virtual Private Network (VPN) traffic. GRE Transport mode inserts an IPsec header between the IP header and the GRE Header. In this case, transport mode saves an additional IP header, which results in less packet expansion. Transport mode can be deployed with ESP and/or Authentication Header. Specifying transport mode allows the router to negotiate with the remote peer whether to use transport or tunnel mode. Transport mode expansion of the IP packet with GRE encapsulation is depicted in Figure 3.
Figure 3
IPsec Using GRE Tunnel Mode Encapsulation
IPsec is using one type of IPsec encapsulation modes: IPsec Tunnel mode or GRE transport mode. The IPsec Header encapsulates the outer header, so the type of encapsulation is not visible from Cisco IOS NetFlow perspective.
IPsec Headers
IPsec defines a new set of headers to be added to IP datagrams. These new headers are placed after the outer IP header and provide information for securing the payload of the IP packet as follows:
•
•
IPsec Header may be employed with ESP and/or Authentication Header. While Authentication Header and ESP can be used either independently or together, one of them will suffice for most applications.
Topology
Figure 4 shows the topology used in this configuration. In the following tests an IPsec tunnel between Cisco 3600-4 and 7200-2 Series Routers has been configured. Then Cisco IOS Software Service Assurance Agent (SAA) has been used to generate packets from the Cisco 7200-3 Series Router to the Cisco 3600-6 Series Multiservice Hardware. As mentioned earlier, only the live Cisco IOS NetFlow cache will be examined, records on the collector will not be examined. By default Cisco IOS NetFlow has aging timers of fifteen seconds. The flow has `expired' and is removed from the live Cisco IOS NetFlow cache if it has a period of fifteen or more seconds when no packets belonging to it are received. Therefore, the Cisco IOS SAA packets generated for this document will have a frequency of greater than fifteen seconds to ensure that there is a constant flow record in the live Cisco IOS NetFlow cache to look at via command-line interface (CLI). For details on the Cisco IOS SAA configuration, please check Appendix A. For this document, all the routers are running Cisco IOS Software Release 12.3.
Figure 4
Test Bed Topology
This test and document were based on the Cisco IOS Software based hardware Cisco 2600, 3600, and 7200 Series Routers. The same results would be received if Cisco IOS NetFlow is run on any other Cisco IOS Software based hardware, such as the Cisco 800, 1600, 2500, 7300 (non-PxF based processors), and 7400 Series Routers, Cisco 3700 Series Multiservice Access Router, and Cisco Catalyst®4500 Series Switch. Interface type does not change Cisco IOS NetFlow behavior on this hardware. The results that were received on the FastEthernet, POS, and Ethernet interfaces were used and can substitute any of the other interfaces available on that hardware.
Test Bed Analysis
The topology in Figure 4 shows three different test points on the network along the path of the IPsec traffic:
•
•
•
For the purposes of this test Cisco IOS NetFlow will be studied at the Edge interface, the Encryption interface, and a network interface that is forwarding the IPsec traffic.
Enabling Cisco IOS NetFlow on Interface
To enable Cisco IOS NetFlow on an interface (ie: FastEthernet 2/0 on Cisco 7200-2 Series Router), the following steps can be used:
7200-2# show running-config!interface FastEthernet 2/0ip route-cache flow!With the exception of specific egress Cisco IOS NetFlow features, Cisco IOS NetFlow is an ingress technology. Since standard ingress Cisco IOS NetFlow has been enabled on the interface, the flows tracked in the cache are going to be from packets traveling inbound to this interface only.
The Tests
To understand the Cisco IOS NetFlow data collection of an IPsec traffic, Cisco IOS NetFlow will be examined on each of the edges and encrypted on network interfaces of an IPsec path (as shown in the topology in Figure 4).The tests are:
Test 1: POS 4/0 interface of Cisco 7200-2 (tunnel head) Series Router
Test 2: FastEthernet 2/0 interface of Cisco 7200-2 (tunnel head) Series Router
Test 3: FastEthernet 1/0 interface of Cisco3600-4 (tunnel midpoint) Series Multiservice Hardware
Test 1—Cisco IOS NetFlow on FastEthernet 1/0 interface of Cisco7200-2 (tunnel head) Series Router
At this interface the traffic is sent and received unencrypted. Cisco IOS NetFlow enabled on this interface counts for inbound traffic on interface POS 4/0. The following results on the Cisco 7200-2 Series Router show traffic received from the Cisco 7200-3 Series Router, which is sending Cisco IOS SAA packets.
Note:
The verbose command elaborates on the last part of Cisco IOS NetFlow cache displaying valuable additional flow information:
All of the fields that display the flows are wrapped to two lines. ToS byte (in Hex) is included in this output. If type of service (ToS) byte is added, the summarized output will look like this:
Since Cisco IOS NetFlow is an ingress technology, only the flows coming into interface POS 4/0 will be studied.
The last two flows on the bottom represent the two Cisco IOS SAA operations configured.
The middle flow reflect Enhanced EIGRP packets and the destination IP of 224.0.0.10, which is a multicast address used by EIGRP to distribute routing information. The "Null" destination interface will be seen for all those packets that are to be dropped by something like an access-list or multicast traffic in this case. Note that Cisco IOS NetFlow now has a multicast support feature via Cisco IOS NetFlow version 9.
The first two flows represent the control messages for the two Cisco IOS SAA operations configured. By design Cisco IOS SAA sends an initial control message to notify the destination of the upcoming Cisco IOS SAA operation traffic and the appropriate port number. Cisco IOS SAA control messages are always sent on port 1967 (07AF in Hexadecimal).
For understanding the debug messages on this Cisco 7200-2 Series Router, check Appendix B.
Enabling Cisco IOS NetFlow on the non-IPsec interface of an IPsec enabled router will allow seeing all the packets coming into the router via that interface prior to encryption.
Test 2—Cisco IOS NetFlow on FastEthernet 2/0 Interface of Cisco 7200-2 (tunnel head) Series Router
With Cisco IOS NetFlow enabled on interface FastEthernet 2/0, Cisco IOS NetFlow counts traffic entering that interface. The following is the output of the Cisco IOS NetFlow cache information on the router:
The first, second, forth, and fifth flows are the Cisco IOS SAA control messages and operations. These Cisco IOS SAA packets, which are being accounted for, are on their return journey However, note, that the destination, source numbers for IP address and port numbers have been reversed compare to the flows in Test 1.
The third flow with the Null destination interface reflects the EIGRP update packets with an IP protocol of 88 (58 in Hexadecimal).
The IPsec configuration on Cisco 7200-2 Series Router, shown in appendix C, utilizes esp-3des encapsulation. The final flow with protocol 50 (32 Hexadecimal) accounts for the ESP Header, which encapsulate the IPsec packets. To get the packet count for Ipsec tunnel (75),count the packet for the Cisco IOS SAA packets in the first, second, third, and forth flows (9 + 10 + 36 + 20).This means that network traffic, in this case Cisco IOS SAA traffic, in the IPsec tunnel has been accounted for and broken out into separate flows outside of the tunnel.
The protocol 17 is for UDP (11 in Hexadecimal) with port 500 (01F4 in Hexadecimal) for Internet Key Exchange protocol received from the remote IPsec peer. The IKE traffic is sent less frequently between the IPsec peers; therefore, the show command on the router may or may not show a count. Despite of this the Cisco IOS NetFlow information in regards to the IKE activities is reported to the collector. There is another alternative to see this exchange in the live Cisco IOS NetFlow cache: via the "show ip cache flow". To do this the default timeout value for Cisco IOS NetFlow needed to be increased.
Using verbose command for the ToS byte:
Adding the ToS byte and B/Pk (Bytes per packet) and changing the hex entries to decimal:
The non-encrypted Cisco IOS SAA flows have a total of seventy five packets and 4,044 bytes, which makes for an average of ~54 bytes per packet. In contrast, the encrypted flows also have seventy five packets with an average of ninety three bytes per packet. These additional bytes in each packet account for the New IP header and IPsec header, as shown in the earlier diagram.
To verify the IPsec tunnel configuration and packet forwarding use the following command:
7200-2#show crypto ipsec sainterface: FastEthernet2/0Crypto map tag: arsenal, local addr. 90.0.0.2protected vrf:local ident (addr/mask/prot/port): (20.0.10.0/255.255.255.0/0/0)remote ident (addr/mask/prot/port): (120.0.40.0/255.255.255.0/0/0)current_peer: 180.0.0.6:500PERMIT, flags={origin_is_acl,}#pkts encaps: 3248, #pkts encrypt: 3248, #pkts digest 0#pkts decaps: 3248, #pkts decrypt: 3248, #pkts verify 0#pkts compressed: 0, #pkts decompressed: 0#pkts not compressed: 0, #pkts compr. failed: 0#pkts not decompressed: 0, #pkts decompress failed: 0#send errors 2, #recv errors 0From this command the total number of only encrypted packets can be seen.
In summary, enabling Cisco IOS NetFlow on the encrypting interface provides with additional flow information not only the packets in the IPsec tunnel, but also the packets broken up into separate flows outside of the tunnel.
Test 3—Cisco IOS NetFlow on FastEthernet 1/0 Interface of Cisco 3600-4 (tunnel midpoint) Series Multiservice Hardware
The following can be seen from the Cisco IOS NetFlow cache on the tunnel midpoint:
The previous command shows the Cisco IOS NetFlow cache on output of the middle router. The first protocol 88 (58 in Hexadecimal) is for EIGRP protocol. Protocol 50 (32 in Hexadecimal) is for the actual IPsec tunnel traffic. The UDP protocol 17 (11 in Hexadecimal), with port 500 (01F4 in Hexadecimal) in both directions, is for the Internet Key Exchange (IKE) protocol traffic between the IPsec peers. As mentioned earlier, the IKE traffic is sent less frequently between the IPsec peers, so the show command on the router may or may not show a count. In any case, the Cisco IOS NetFlow information in regards to the IKE activities is reported to the collector.
To add the ToS byte information verbose is used:
By adding the ToS byte and translating the protocol, ports, and ToS byte from Hex to decimal the following can be received:
SrcIf
SrcIP
DstIf
DstIP
Prot
SrcP
DstP
ToS
Pkts
Fa1/0
90.0.0.2
Null
224.0.0.10
88
0000
0000
192
139
Fa1/0
90.0.0.2
Fa1/1
180.0.0.6
50
12901
47049
00
59
The last flow is the IPsec tunnel. Notice that, as expected, the IPsec packets protocol, port numbers, and ToS byte have changed from the Cisco IOS SAA packets enclosed in the payloads. The destination IP address is the end of IPsec tunnel.
The top flow represents the incoming EIGRP updates from the neighboring Cisco 7200-2 Series Router. These EIGRP updates are underlined in the debug below:
Warning: use a "debug ip packet detail" command only when the traffic on the router is low, otherwise this command can crash the router.
Cisco IOS NetFlow accounts for the tunneled packets, while the debug does not pick them up. However, the packets are accounted for encapsulated packets; and therefore, have different packet header fields (ie: protocol, port numbers, ToS byte, and destination interface) than the original Cisco IOS SAA packets, which are encapsulated in the packet payloads.
Conclusion
Figure 5
Summary of NetFlow in IPsec Topology
The test has determined following conditions with Cisco IOS NetFlow enabled at these points:
•
•
•
In conclusion, enabling the Cisco IOS NetFlow on the inside facing, head and tail tunnel encrypted interfaces (Test 2) gave the most detailed information. If the user is looking for the most detailed flow information, then the head and tail interfaces are the best positions to leverage the Cisco IOS NetFlow.
Appendix A Cisco IOS SAA configurations
To bring up the tunnel Cisco IOS Service Assurance Agent (SAA) generation of traffic would be ideal. Configure the destination (responder) first:
2600-5# show running-config | include responderrtr responder
Two Cisco IOS SAA operations are configured:
7200-3# show running-config!rtr 1type jitter dest-ipaddr 120.0.40.5 dest-port 65051 source-ipaddr 20.0.10.3 source-port 65003 num-packets 2tos 128frequency 10rtr schedule 1 start-time 19:04:59 Feb 14rtr 2type jitter dest-ipaddr 120.0.40.5 dest-port 65052 source-ipaddr 20.0.10.3 source-port 65003 num-packets 4tos 64frequency 10rtr schedule 2 start-time 19:05:00 Feb 14!This Cisco IOS SAA configuration will generate the following test packets:
1.
•
•
•
•
•
2.
•
•
•
•
•
The ToS byte and destination port are different only in numbers of packets being sent. In addition, each operation sends a control message prior to the Cisco IOS SAA operation packets. Each control message sends one packet to the responder to establish the port number that the operation packets will be sent to.
This Cisco IOS SAA configuration causes the Cisco IOS SAA sender to send the following traffic:
The top two flows are the Cisco IOS SAA control messages that are sent to the responder prior to each Cisco IOS SAA operation begins. This tells the responder that Cisco IOS SAA packets are about to be sent to the router and to pass the port number, etc... The Cisco IOS SAA control messages are sent to port 1967, but the other six key Cisco IOS NetFlow fields (ie:SrcIf, SrcIP, DstIP, Prot, SrcP, and ToS) remain the same as the Cisco IOS SAA operation packets that are about to follow. Those proceeding Cisco IOS SAA operation packets have a different destination port; and therefore, create different flows. By pairing up the two Cisco IOS SAA operations the following can be get:
The control message is sent first:
SrcIf
SrcIP
DstIf
DstIP
Prot
SrcP
DstP
ToS
Pkts
PO4/0
20.0.10.3
Fa2/0
120.0.40.5
17
65003
1967
64
12
Followed by the Cisco IOS SAA operation packets:
For the other Cisco IOS SAA operation the control message is sent:
SrcIf
SrcIP
DstIf
DstIP
Prot
SrcP
DstP
ToS
Pkts
PO4/0
20.0.10.3
Fa2/0
120.0.40.5
17
65003
1967
128
14
Correspondingly followed by the operation packets:
Appendix B Debugs
From debug on Cisco 7200-2 Series Router the following output can be received:
Note: enable this "debug ip packet detail" command only on a router with a little packet activity otherwise it can crash the router.
In summary the following packets are being shown:
Every 4-5 seconds EIGRP updates incoming via POS 4/0 (these packets are being seen as one flow in the Cisco IOS NetFlow cache):
The packets from this flow have been underlined in the debug output above.
Every 5 seconds EIGRP updates outgoing via POS 4/0:
Feb 18 18:10:43: IP: s=20.0.10.2 (local), d=224.0.0.10 (POS4/0), len 60, sending broad/multicast, proto=88
Every 4-5 seconds EIGRP updates incoming via Fast 2/0:
Every 5 seconds EIGRP updates outgoing via Fast 2/0:
Feb 18 18:10:40: IP: s=90.0.0.2 (local), d=224.0.0.10 (FastEthernet2/0), len 60, sending broad/multicast, proto=88
NTP request and reply:
The debug does not reflect the tunneled packets, so all the packets associated with encryption are not shown. However, Cisco IOS NetFlow picks up and accounts for them.
Appendix C—Router Versions and Configurations
Cisco 7200-3 Series Router
7200-3# show version
Cisco IOS Software, 7200 Software (C7200-JS-M), Version 12.3(4)T2, RELEASE SOFT
WARE (fc1)
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2003 by Cisco Systems, Inc.
Compiled Thu 18-Dec-03 17:39 by dchih
ROM: System Bootstrap, Version 12.1(20000824:081033) [dbeazley-cosmos_e_LATEST 1
01], DEVELOPMENT SOFTWARE
BOOTLDR: 7200 Software (C7200-BOOT-M), Version 12.0(13)S, EARLY DEPLOYMENT RELEA
SE SOFTWARE (fc1)
7200-3 uptime is 1 week, 4 days, 20 minutes
System returned to ROM by reload at 23:45:13 PDT Thu Apr 15 1993
System restarted at 17:16:28 PST Tue Feb 3 2004
System image file is "sup-slot0:/c7200-js-mz.123-4.T2.bin"
Cisco 7206VXR (NPE300) processor (revision D) with 155648K/40960K bytes of memory.
Processor board ID 21302317
R7000 CPU at 262Mhz, Implementation 39, Rev 2.1, 256KB L2, 2048KB L3 Cache
6 slot VXR midplane, Version 2.1
Last reset from power-on
PCI bus mb0_mb1 has 700 bandwidth points
PCI bus mb2 has 600 bandwidth points
WARNING: PCI bus mb0_mb1 Exceeds 600 bandwidth points
3 FastEthernet interfaces
1 Gigabit Ethernet interface
1 Packet over SONET interface
125K bytes of NVRAM.
107520K bytes of ATA PCMCIA card at slot 0 (Sector size 512 bytes).
125952K bytes of ATA PCMCIA card at slot 1 (Sector size 512 bytes).
4096K bytes of Flash internal SIMM (Sector size 256K).
Configuration register is 0x2102
7200-3# show running-config
Building configuration...
Current configuration : 2987 bytes
!
! Last configuration change at 10:03:47 PST Wed Feb 18 2004
! NVRAM config last updated at 22:19:18 PST Tue Feb 17 2004
!
version 12.3
no service pad
service timestamps debug datetime
service timestamps log datetime
no service password-encryption
service udp-small-servers
!
hostname 7200-3
!
boot-start-marker
boot system flash disk0:c7200-js-mz.123-4.T2.bin
boot system flash disk0:c7200-p-mz.122-14.S1.bin
boot-end-marker
!
logging snmp-authfail
logging queue-limit 100
enable password lab
!
clock timezone PST -8
clock summer-time PDT recurring
clock calendar-valid
no aaa new-model
ip subnet-zero
!
!
no ip domain lookup
ip name-server 172.19.192.254
!
!
ip vrf red
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip cef
!
!
interface Loopback0
ip address 20.0.0.3 255.255.255.0
no ip route-cache
no ip mroute-cache
!
interface Loopback2
ip address 10.10.10.10 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface Loopback100
ip address 1.1.1.1 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface FastEthernet0/0
ip address 10.0.227.3 255.255.255.0
no ip route-cache
no ip mroute-cache
duplex full
!
interface POS1/0
ip address 20.0.10.3 255.255.255.0
no ip route-cache
no ip mroute-cache
clock source internal
!
interface FastEthernet2/0
ip address 90.0.0.3 255.255.255.0
no ip route-cache
no ip mroute-cache
duplex full
!
interface FastEthernet3/0
ip address 172.19.193.117 255.255.255.0
no ip route-cache
no ip mroute-cache
duplex full
!
interface GigabitEthernet6/0
no ip address
no ip route-cache
no ip mroute-cache
shutdown
negotiation auto
!
router eigrp 1
network 20.0.10.0 0.0.0.255
auto-summary
!
ip classless
ip route 128.107.0.0 255.255.0.0 172.19.193.1
ip route 172.19.192.0 255.255.255.0 172.19.193.1
no ip http server
!
!
!
snmp-server community public RO
snmp-server community private RW
snmp-server enable traps tty
!
snmp mib persist circuit
snmp mib persist event
!
tftp-server bootflash:c7200-boot-mz.120-13.S
!
!
control-plane
!
!
dial-peer cor custom
!
!
gatekeeper
shutdown
!
rtr responder
rtr 1
type jitter dest-ipaddr 120.0.40.5 dest-port 65051 source-ipaddr 20.0.10.3 sour
ce-port 65003 num-packets 2
tos 128
frequency 10
rtr schedule 1 start-time 10:08:00 Feb 18
rtr 2
type jitter dest-ipaddr 120.0.40.5 dest-port 65052 source-ipaddr 20.0.10.3 sour
ce-port 65003 num-packets 4
tos 64
frequency 10
rtr schedule 2 start-time 10:08:05 Feb 18
banner motd ^CC NetFlow Lab testing equipment. Please see Paul Kohler x31939. Th
anks! ^C
!
line con 0
exec-timeout 0 0
logging synchronous
transport preferred all
transport output all
stopbits 1
line aux 0
transport preferred all
transport output all
stopbits 1
line vty 0 4
password lab
login
transport preferred all
transport input all
transport output all
!
ntp clock-period 17179950
ntp update-calendar
ntp server 10.0.227.4
!
!
end
7200-3#
Cisco 7200-2 Series Router
This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to export@cisco.com.
Cisco 3600-4 Series Multiservice Hardware
This product contains cryptographic features and is subject to United States and local country laws governing import, export, transfer and use. Delivery of Cisco cryptographic products does not imply third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for compliance with U.S. and local country laws. By using this product you agree to comply with applicable laws and regulations. If you are unable to comply with U.S. and local laws, return this product immediately.
A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html
If you require further assistance please contact us by sending email to export@cisco.com.
