Flow Accounting and Traffic Engineering

Distance-dependent charging schemes also exist. As with telephone calls, to determine the cost of each byte, it is necessary to know where each byte originates and its destination. The origin issue seems obvious: the traffic enters the network on an interface associated with a particular customer. To determine the destination, you must perform flow accounting; this is where Netflow comes in.

It is generally recommended that you deploy Netflow as a perimeter technology—that is, enable Netflow on distribution/aggregation routers rather than on core routers. If you assume that Netflow accounting is performed at all customer ingress points (referring back to Table 15-2) you can see that you know the destination for all traffic in the network. Furthermore, if you couple this with knowledge about route configuration within the network, you can perform flow analysis and optimize routes.

Chapter 3, "Network Topologies, discussed various backbone topologies and introduced the concept of evolving the backbone from a ring through a partial to a full mesh.

Refer to Figure 15-5. You can detect that the links between San Francisco and Seattle, and between Seattle and New York, are congested, so you turn to your database of collected flow data. Analyzing data collected from routers D1 and D2, you can surmise that 20 percent of traffic leaving the distribution network in San Francisco is for destinations to New York and Washington.

From the route costing, you know that the core routers in San Francisco use the link via Seattle to reach both New York and Washington. You also know that the link from San Francisco to Florida reaches a peak utilization of 90 percent and therefore has little spare capacity. Price quotes tell you that the incremental cost of increasing the bandwidth of existing links between San Francisco/Seattle/New York or San Francisco/Florida/Washington is about the same as putting a direct link between San Francisco and New York. Because the latter solution provides greater redundancy and shorter round-trip times, you should opt for that. You know from your flow analysis the required bandwidth for the link.

In performing the previous process, you can see that three databases are needed:

• The raw flow data, showing the destination of all traffic from the distribution network in San Francisco

• A database that groups destination addresses into distribution networks

• A database that shows how traffic from each distribution network is routed across the backbone to other distribution networks

A similar process may also be used for calculating the size of interprovider traffic flows. In this case, you could use the destination AS rather than the IP address to size the flows. You also would need to maintain a list of all ASs serviced by your own network because traffic to these would not constitute interprovider traffic.

You can collect the destination IP address and AS for all ingress traffic from customers, and then compare this with the following:

• The database listing network addresses associated with each distribution network

• The database listing all ASs serviced by the network

You now have the basis for a three-tiered, distance-dependent charging scheme: local traffic, nationwide traffic, and interprovider/international traffic. Note, however, that unlike the simple byte-volume charging scheme, distance-dependent charging can involve significant postprocessing of accounting data.

Summary: Network Management Checklist for Large Networks

In this chapter, you read about the overall network management task. This task was divided into the functional areas defined by ISO. The chapter examined the use of SNMP and MIBs, Netflow, NTP, Syslog, DNS, and TACACs in overall network management. It also looked at the importance of maintaining network integrity through the use of route filtering and registries, and enabling or disabling forwarding services that may assist or threaten this policy.

This was a lot of ground to cover, so by way of summary, the following network management checklist can be used to help in the design or maintenance of your network:

1. Think about the five areas: fault, configuration, security, accounting, and performance. Are you addressing each of these issues?

2. Does your network require a distributed management framework, or will a centralized facility suffice? If you opt for a centralized facility, can you painlessly upgrade to a distributed architecture?

3. Have you enabled SNMP access on all routers, and are you controlling access through an access list? Is the access read-only?

4. Do you have a graphical representation of the network that is easily monitored by operations staff? Are you polling for sysUptime, ifOperStatus, and ifAdminStatus? Are other MIB variables more applicable to your network?

5. Do you have tools to enable operations staff to monitor log and snmp trap output from routers? Have you enabled logging and/or SNMP trap reporting on all critical routers? If so, at what level of messages (debug through emergencies )?

6. Is all logging and trap information archived?

7. Can you perform general SNMP queries of all supported Cisco MIBs? Do you have an MIB compiler?

8. Do you have an NTP architecture, including your own stratum 1 server? Will you offer NTP services to customers? If so, how?

9. Have you configured critical routers or those involved in testing to core-dump in the event of failure?

10. What is your naming plan for router interfaces? Do traceroutes through your network aid the troubleshooting process?

11. Are you making use of descriptive commands available in IOS to help self-document the configurations?

12. Do you have a document describing the overall network architecture, including its routing, policy, and failure modes?

13. Are your IOS configurations under revision control? What is your engineering policy for modifying router configurations?

14. Are you using the AAA architecture so you can control, track, and log access to routers? Is router access protected by both an AAA protocol and access lists? Do you have a procedure for updating the authentication database as network operations and engineering staff come and go? Are you using strong encryption for the enable password, and have you enabled Nagle congestion control and configured login banners?

15. Have you configured authentication for all routing protocols, using MD5 where available?

16. Are you maintaining a routing registry? Is the policy in this registry automatically and regularly translated into router configuration updates?

17. Have you enabled CEF RPF to prevent packet spoofing? Have you disabled IP redirects, directed broadcast, and proxy ARP? What about finger, pad, TCP services, UDP services, and bootp?

18. What is your plan for staging both major configuration changes and IOS version upgrades?

19. How do you monitor the ongoing performance of the network? Are you collecting and/or applying alarm thresholds to link utilization, errors, queue drops, and discards? Are there any other MIB variables that may tell you when your bandwidth, route processing, or switching capability is being exceeded?

20. What statistics are you collecting to perform capacity planning and traffic engineering? Have you considered enabling Netflow at the perimeter of the network and archiving ifInOctets and ifOutOctets for all router interfaces? Are you regularly analyzing flows in your network and optimizing routers accordingly?

21. What is your billing model, and what additional statistics do you need to collect to support it?

22. Do you recognize all the features in the following configuration and understand the motive for enabling or disabling each?

version 12.0 service nagle no service pad service timestamps debug datetime service timestamps log datetime service password-encryption !

hostname distl.sfo !

no logging console aaa new-model aaa authentication login default tacacs+ enable aaa authentication login console none aaa authentication enable default tacacs+ enable aaa accounting exec default start-stop tacacs+

aaa accounting commands 15 default start-stop tacacs+

enable secret 5 $1$/edy$.CyBGklbRBghZehOaj7jI/ !

ip subnet-zero ip cef distributed ip cef accounting per-prefix non-recursive no ip finger ip tcp window-size 65535

ip tcp path-mtu-discovery ip tftp source-interface LoopbackO

ip ftp source-interface LoopbackO

ip ftp username devtest ip ftp password 7 0202014D1F031C3501

no ip bootp server ip host tftps 172.21.27.83

ip domain-name isp.net ip name-server 16.60.0.254

ip name-server 16.60.20.254

ip multicast-routing distributed clock timezone PST -8

clock summer-time PDT recurring ! i interface LoopbackO ip address 16.0.0.1 255.255.255.255 no ip directed-broadcast no ip route-cache no ip mroute-cache interface FastEthernet0/0/0 description Server LAN, 100 Mbit/s, Infrastructure bandwidth 100000

ip address 16.60.10.1 255.255.0.0 ip verify unicast reverse-path no ip redirects no ip directed-broadcast ip route-cache distributed no cdp enable ip classless ip tacacs source-interface Loopback0 ip bgp-community new-format logging history size 100 logging history debugging logging 16.60.0.254

access-list 16 permit 16.60.0.0 0.0.255.255

snmp snmp snmp snmp snmp snmp snmp snmp snmp snmp snmp snmp snmp snmp snmp !

tacac tacac banne C

server community testcomm RO 7 server trap-source Loopback0 server location San Francisco server contact [email protected] server enable traps snmp server enable traps channel server enable traps isdn call-information server enable traps config server enable traps entity server enable traps envmon server enable traps bgp server enable traps frame-relay server enable traps rtr server host 16.60.0.254 traps snmpcomm server tftp-server-list 16

s-server host 16.60.0.254 s-server key labkey r login

This system is the property of isp.net

Access to this system is monitored Unauthorized access is prohibited

Contact [email protected] or call +1 555 555 5555 with inquiries line con 0 exec-timeout 0 0 login authentication console transport input none line aux 0 line vty 0 4 access-class 16 in exec-timeout 0 0 password 7 002B012D0D5F transport input telnet

exception core-file 75k1.sfo exception protocol ftp exception dump 16.60.0.254

ntp authenticate ntp trusted-key 1

ntp clock-period 17182332

ntp source Loopback0

ntp update-calendar ntp server 16.60.0.254 prefer end

Review Questions

1: Why aren't some of the features of security or scaling problems disabled by default?

3: What are the storage requirements for Netflow?

4: What are the storage requirements for SNMP and logging?

5: Could NTP be provided as a service to customers?

6: Are there routing protocols that dynamically route around points of congestion in the network?

Answers:

1: Why aren't some of the features of security or scaling problems disabled by default?

A: Security and ease-of-use are often contradicting requirements. Some of the features make life easier if they are enabled. Having said that, increasingly the emphasis is on scalability—and particularly security. Some of the features recommended for disabling or enabling in this chapter have already become defaults in version 12 of IOS. More changes are sure to follow as other scaling issues and security vulnerabilities are discovered.

A: Vendors use "turn-key" NMS to refer to a system that you power on and that instantly manages your network. Although such systems may be a reasonable match for small networks, they generally require considerable tailoring for very large networks. In some cases, the auto-discovery mechanisms of such systems can be quite disruptive because they probe the network, requesting large volumes of data in the process of discovering topology and devices. Designing and deploying your NMS must be done with as much care and planning as any other part of the network infrastructure. Indeed, the NMS is one of the most critical parts of the infrastructure.

3: What are the storage requirements for Netflow?

A: For a large network, even with only a few hundred routers, Netflow export can quickly result in large volumes of data. Your Netflow collection agent should attempt to parse the export data in real-time, performing aggregation of data and discarding any data in which you are not interested.

4: What are the storage requirements for SNMP and logging?

A: Again, large amounts of data can quickly accumulate. You should carefully plan which data to keep and how to archive the data from expensive hard drives to cheaper media, such as CD-ROMs.

5: Could NTP be provided as a service to customers?

A: If you have your network well-synchronized, there is no reason why this benefit should not be passed on to customers. However, you should clearly set customer expectations about the accuracy of the time—possibly in terms of the NTP stratum. Nevertheless, even clocks at higher stratum numbers, such as 4 or above, can still be within a second or less of a stratum 1 source; for many applications, this is more than good enough.

6: Are there routing protocols that dynamically route around points of congestion in the network?

A: Yes. As far back as the ARPANET, such protocols were investigated. However, avoiding route-oscillation in dynamic congestion-based routing for connectionless environments such as IP is a tricky problem that continues to be the subject of much endeavor in research and commercial environments, as well as the IETF.

Leinwand, A. and K. F. Conroy. Network Management: A Practical Perspective. Reading, MA: Addison-Wesley, 1998.

RFC 1155. Structure and Identification of Management Information for TCP/IP-based Internets. 1990.

RFC 1157. A Simple Network Management Protocol. 1990.

RFC 1213. Management Information Base for Network Management of TCP/IP-based Internets: MIB-II. 1991.

RFC 1305. Network Time Protocol. 1992.

RFC 1901. Introduction to Community-based SNMPv2. 1996.

RFC 1902. Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996.

RFC 1903. Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996.

RFC 1904. Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996.

RFC 1905. Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996.

RFC 1906. Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996.

RFC 1907. Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). 1996.

RFC 190B. Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. 1996.

RFC 2271. An Architecture for Describing SNMP Management Frameworks. 199B.

RFC 2272. Message Processing and Dispatching for the Simple Network Management Protocol (SNMP). 199B.

RFC 2273. SNMPv3 Application. 199B.

RFC 2274. User-based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3). 199B.

RFC 2275. View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP). 199B.

Rose, M. The Simple Book: An Introduction to Management of TCP/IP-based Internets, Second Edition. Upper Saddle River, NJ: Prentice-Hall, 1993.

Stallings, W. SNMP, SNMPv2, and CMIP: The Practical Guide to Network Management. Reading, MA: Addison-Wesley, 1993.

Terplan, K. Communications Network Management, Second Edition. Upper Saddle River, NJ: Prentice-Hall, 1992.

Was this article helpful?

0 0

Post a comment