This section gives some examples of the revised CLI. They have been taken from real, live running configurations working in networks today.
The first example shows how BGP supporting IPv6 is configured. This router is a part of the 6BONE, the IPv6 experimental backbone:
!
neighbor UPSTREAMS peer-group neighbor iBGP-peers peer-group
neighbor 2001:200:0:1805::2 remote-as 2500 neighbor 3FFE:800::FFF9:0:0:9 remote-as 4554 neighbor 3FFE:C00:E:11::1 remote-as 109
neighbor 3FFE:C00:800F:FFFF::2 remote-as 4608 !
address-family ipv6 ! set up IPv6 addr-family
neighbor UPSTREAMS activate ! define UPSTREAMS neighbor UPSTREAMS send-community
neighbor UPSTREAMS prefix-list block-my-sla in neighbor UPSTREAMS prefix-list announce-my-sla out
neighbor iBGP-peers activate ! define iBGP peers neighbor iBGP-peers next-hop-self
neighbor iBGP-peers send-community
neighbor 2001:200:0:1805::2 peer-group UPSTREAMS neighbor 3FFE:800::FFF9:0:0:9 peer-group UPSTREAMS neighbor 3FFE:C00:E:11::1 peer-group UPSTREAMS
neighbor 3FFE:C00:800F:FFFF::2 peer-group iBGP-peers network 3FFE:C00:800F::/48
exit-address-family
!
Notice how the configuration is separated into distinct parts. This router could support IPv4 BGP peering as well if the organization chose to do this. All that is configured here is IPv6 support, so the IPv6-specific commands are included under the IPv6 address family. Note the activate directive—this is needed to activate any peering inside an address family.
The second example is a simple MPLS/VPN example taken from the Cisco Systems’
ISP Workshop program. Two VPNs have been set up across the ISP backbone; the ISP backbone is made up of three P routers and three PE routers. The P routers form the ISP core, and the PE routers deal with the VPN. This configuration is from one of the PE routers at the edge of the ISP network (PE stands for “provider edge”). The two BGP peerings are with the other two PE routers configured in this network. The P routers take no part in the iBGP configuration required for the VPN.
!
router bgp 100 no synchronization
neighbor 200.200.0.12 remote-as 100
neighbor 200.200.0.12 update-source Loopback0 neighbor 200.200.0.13 remote-as 100
neighbor 200.200.0.13 update-source Loopback0 no auto-summary
network 172.16.1.0 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.252 exit-address-family
network 172.16.1.0 mask 255.255.255.0 network 172.16.2.0 mask 255.255.255.252 exit-address-family
!
address-family vpnv4 ! now set up the VPN address-fam
neighbor 200.200.0.12 activate
neighbor 200.200.0.12 send-community extended neighbor 200.200.0.13 activate
neighbor 200.200.0.13 send-community extended no auto-summary
exit-address-family
!
Notice again how the configuration is neatly separated, making it much easier to read and understand. With the old-style CLI, it would have been very hard to configure this.
Summary
This chapter covered the major routing protocol features that ISPs need to consider for their backbone networks. It discussed general routing features that the router requires, covered the basic background for using IGPs and BGP, and showed the good design practices for implementing IGPs. The chapter then considered the ISP-friendly features of BGP in considerable detail. Most of these features are new or recent additions to IOS Software and warrant in-depth discussion. The chapter also looked at the policy features available for BGP in IOS Software and a mechanism for doing IP traffic accounting using BGP attributes. The chapter finished by looking at the new CLI available for BGP, designed to support multiple address families.
Endnotes
1. This section originally was written by Mark Turner ([email protected]) and can be found on Cisco.com at http://www.cisco.com/warp/public/459/25.shtml.
2. Private autonomous systems are those AS numbers between 64512 and 65534. AS 65535 is reserved by IANA.
3. Thanks to Enke Chen for providing most of the text describing BGP peer groups.
4. The core of this section is by Bruce R. Babcock ([email protected]) and Enke Chen.
5. This section is based on the address family release notes originally written by Srihari Ramachandra.
Chapter 4. Security
This chapter on Cisco IOS Software security features assumes that the ISP engineer has a working grasp of the fundamentals of system security. If not, the materials listed in the reference section should be reviewed first to help gain an understanding of some of the fundamentals. It is also important to note that the following sections are intended to supplement, not replace, Cisco documentation. It is assumed that the ISP engineer will read such documentation in parallel with this chapter.
This chapter describes tools that all ISPs should consider for their overall security architectures. Most of these tools are passive tools. When configured, they will help prevent security problems from happening and make it more difficult to cause mischief on an ISP’s network.
The chapter is split into several sections. These cover ISP security in general, the process of securing the router, the routing protocol, and the network. After this, the chapter looks in more detail at how to implement the unicast reverse path
forwarding (RPF) check and how to use Committed Access Rate (CAR) to deal with attacks in progress. The chapter concludes with a brief discussion on how to
approach ISP security and how to react to incidents underway. The various sections are titled as follows:
• Securing the Router
• Securing the Routing Protocol
• Securing the Network
• Unicast RPF
• Using CAR to Counter DoS Attacks
• Reacting to Security Incidents
Subdividing the text in this way supports the formation of a clear strategy for an ISP to work on to minimize the effects of a security incident.
Securing an enterprise network from Internet threats is easy when compared with the problems of security facing an ISP. When an enterprise network connects to the Internet, there is essentially one Internet security problem—protecting your network from outside intrusion. To achieve Internet security objectives, an enterprise must balance trade-offs with connectivity, accessibility, performance, and security.
An ISP’s security concerns are much broader. The ISP business is all about transparent, cost-effective, and high-performance Internet connectivity. Security measures will affect the ISP’s network operation, yet security threats are real and need to be protected against. ISPs are very visible targets for malicious, vindictive, and criminal attacks, so they must protect themselves, help protect their customers, and minimize the risk of their customers becoming problems to others on the
Internet (see Figure 4-1).
Figure 4-1. An ISP’s Security Threats Come from All Directions
NOTE
No network is ever fully secure or protected. There is always a risk factor, especially for ISPs whose job it is to move other people’s packets across their networks (other people’s packets are customers’ packets). What ISPs can expect to have are tools to build resistance. ISPs need to resist attacks and intrusion attempts to their networks, resisting long enough for internal security-reaction procedures to be activated to track the incident and apply countermeasures. The tools described in this chapter help to build resistance and security.