More Books
Routing TCP IP Volume II CCIE Professional Development
Routing TCP/IP, Volume II (CCIE Professional Development)
Table of Contents
Copyright
About the Authors
About the Technical Reviewers
Acknowledgments
Introduction
Icons Used in This Book
Command Syntax Conventions
Part I: Exterior Gateway Protocols
Chapter 1. Exterior Gateway Protocol
The Origins of EGP
Operation of EGP
Shortcomings of EGP
Configuring EGP
Troubleshooting EGP
Looking Ahead
Review Questions
Configuration Exercises
Troubleshooting Exercise
End Notes
Chapter 2. Introduction to Border Gateway Protocol 4
Classless Interdomain Routing
Who Needs BGP?
BGP Basics
IBGP and IGP Synchronization
Managing Large-Scale BGP Peering
BGP Message Formats
Looking Ahead
Recommended Reading
Review Questions
End Notes
Chapter 3. Configuring and Troubleshooting Border Gateway Protocol 4
Basic BGP Configuration
Managing BGP Connections
Routing Policies
Large-Scale BGP
Looking Ahead
Recommended Reading
Command Summary
Configuration Exercises
Troubleshooting Exercises
Part II: Advanced IP Routing Issues
Chapter 4. Network Address Translation
Operation of NAT
NAT Issues
Configuring NAT
Troubleshooting NAT
Looking Ahead
Command Summary
Configuration Exercises
Troubleshooting Exercises
End Note
Chapter 5. Introduction to IP Multicast Routing
Requirements for IP Multicast
Multicast Routing Issues
Operation of the Distance Vector Multicast Routing Protocol (DVMRP)
Operation of Multicast OSPF (MOSPF)
Operation of Core-Based Trees (CBT)
Introduction to Protocol Independent Multicast (PIM)
Operation of Protocol Independent Multicast, Dense Mode (PIM-DM)
Operation of Protocol Independent Multicast, Sparse Mode (PIM-SM)
Looking Ahead
Recommended Reading
Command Summary
Review Questions
End Notes
Chapter 6. Configuring and Troubleshooting IP Multicast Routing
Configuring IP Multicast Routing
Troubleshooting IP Multicast Routing
Looking Ahead
Configuration Exercises
Troubleshooting Exercises
Chapter 7. Large-Scale IP Multicast Routing
Multicast Scoping
Case Study: Multicasting Across Non-Multicast Domains
Connecting to DVMRP Networks
Inter-AS Multicasting
Case Study: Configuring MBGP
Case Study: Configuring MSDP
Case Study: MSDP Mesh Groups
Case Study: Anycast RP
Case Study: MSDP Default Peers
Command Summary
Looking Ahead
Review Questions
End Notes
Chapter 8. IP Version 6
Design Goals of IPv6
Current State of IPv6
IPv6 Packet Format
IPv6 Functionality
Transition from IPv4 to IPv6
Looking Ahead
Recommended Reading
Review Questions
Chapter Bibliography
End Notes
Chapter 9. Router Management
Policies and Procedure Definition
Simple Network Management Protocol
RMON
Logging
Syslog
Network Time Protocol
Accounting
Configuration Management
Fault Management
Performance Management
Security Management
Designing Servers to Support Management Processes
Network Robustness
Lab
Recommended Reading
Looking Ahead
Command Summary
Review Questions
Configuration Exercises
Bibliography
End Notes
Part III: Appendixes
Appendix A. The show ip bgp neighbors Display
Appendix B. A Regular-Expression Tutorial
Literals and Metacharacters
Delineation: Matching the Start and End of Lines
Bracketing: Matching a Set of Characters
Negating: Matching Everything Except a Set of Characters
Wildcard: Matching Any Single Character
Alternation: Matching One of a Set of Characters
Optional Characters: Matching a Character That May or May Not Be There
Repetition: Matching a Number of Repeating Characters
Boundaries: Delineating Literals
Putting It All Together: A Complex Example
Recommended Reading
Appendix C. Reserved Multicast Addresses
Internet Multicast Addresses
References
People
Appendix D. Answers to Review Questions
Answers to Chapter 1 Review Questions
Answers to Chapter 2 Review Questions
Answers to Chapter 5 Review Questions
Answers to Chapter 7 Review Questions
Answers to Chapter 8 Review Questions
Answers to Chapter 9 Review Questions
Appendix E. Answers to Configuration Exercises
Answers to Chapter 1 Configuration Exercises
Answers to Chapter 3 Configuration Exercises
Answers to Chapter 4 Configuration Exercises
Answers to Chapter 6 Configuration Exercises
Answers to Chapter 9 Configuration Exercises
Appendix F. Answers to Troubleshooting Exercises
Answer to Chapter 1 Troubleshooting Exercise
Answers to Chapter 3 Troubleshooting Exercises
Answers to Chapter 4 Troubleshooting Exercises
Answers to Chapter 6 Troubleshooting Exercises
Index
index_SYMBOL
index_A
index_B
index_C
index_D
index_E
index_F
index_G
index_H
index_I
index_J
index_K
index_L
index_M
index_N
index_O
index_P
index_Q
index_R
index_S
index_T
index_U
index_V
index_W
 

Managing BGP Connections

Cisco IOS offers several features to help in the management of BGP peer connections. The first is the neighbor description statement. Like the description statement that can be entered under an interface configuration, this statement has no functional impact on the router. Rather, it adds an informational text string to the configuration. You already have encountered many configuration options that apply to a BGP neighbor, and you will encounter several more in the remaining sections of this chapter. When the BGP configuration becomes elaborate, the neighbor description helps provide a reminder of who and where each neighbor is. Example 3-71 demonstrates the use of the neighbor description statement.

Example 3-71 The neighbor description Command Helps Alleviate Confusion with Elaborate BGP Configurations


router bgp 200


 aggregate-address 192.168.192.0 255.255.248.0 as-set summary-only


 neighbor 192.168.1.1 remote-as 500


 neighbor 192.168.1.1 description ******T1 to Sun, Ckt. ID 54.HCGS.123456


 neighbor 192.168.1.237 remote-as 200


 neighbor 192.168.1.237 description ****Ethernet to Diamond, Interface E0


 neighbor 192.168.1.250 remote-as 300


 neighbor 192.168.1.250 description ****T1 to Burke, Ckt. ID 54.HCGS.654321


 neighbor 192.168.1.254 remote-as 100


 neighbor 192.168.1.254 description ****56K to Stowe, Ckt. ID 54.DWDA.987654


The description can contain any useful information you want to add, up to 80 characters. This example includes the link type, the name of the neighboring router, and, where appropriate, the circuit ID.

Two BGP neighbors also can authenticate each other with a password using the neighbor password statement. In the configuration in Example 3-72, the password noT4U2n0 has been entered for the neighbor 192.168.1.253.

Example 3-72 BGP Neighbor Authentication


service password-encryption


!


router bgp 100


 redistribute eigrp 100


 neighbor 192.168.1.253 remote-as 200


 neighbor 192.168.1.253 description ****56K to Sugarbush, Ckt. ID 54.DWDA.987654


 neighbor 192.168.1.253 password 7 14191D3F5831782574


Notice also that the service password-encryption option has been entered into the router's global configuration, causing the password to be encrypted when the configuration is displayed, for added privacy.

The passwords between different neighbor connections can differ, or they can all be the same. You also can apply a common password to a peer group rather than to individual neighbors by specifying the peer group name in place of an IP address. For each BGP connection, however, the two neighbors must have the same password.

The IOS uses MD5 authentication when a BGP neighbor password is configured. MD5 is a one-way message digest or secure hash function produced by RSA Data Security, Inc. It also is occasionally referred to as a cryptographic checksum, because it works in somewhat the same way as an arithmetic checksum. MD5 computes a 128-bit hash value from a plain-text message of arbitrary length (in this case, a BGP message) and a password. This "fingerprint" is transmitted along with the message. The receiver, knowing the same password, calculates its own hash value. If nothing in the message has changed, the receiver's hash value should match the sender's value transmitted with the message. The hash value is impossible to decipher (without a huge amount of computing power) without knowing the password so that an unauthorized router cannot, either maliciously or by accident, peer with a router running neighbor authentication.

Other options available for the neighbor connection are the neighbor advertisement-interval and neighbor version commands. The first command changes the default BGP update interval to a specified interval between 0 and 600 seconds. If a large number of routes must be exchanged across a link, using this command to increase the period between advertisements can reduce the impact on the link's available bandwidth. You should not change the advertisement interval, however, unless you fully understand the consequences, such as possible reduced reconvergence times.

The neighbor version command is useful if a neighbor cannot support the default BGP-4. Rather than have the version 4 router negotiate down to the neighbor's supported version, you can configure the router to speak a specific version to a specific neighbor. As a result, the time necessary to establish a BGP connection is reduced. If both neighbors speak version 4, you gain nothing with this command, and its use is unnecessary.

The BGP decision process implemented in the Cisco IOS takes into consideration the length of the AS_PATH attribute when choosing between multiple routes to the same destination. However, RFC 1771 does not include this step. As a result, a Cisco BGP speaker occasionally is peered with another vendor's router that does not consider the AS_PATH length. If this situation creates the potential for inconsistent routing decisions, you can instruct the Cisco router to ignore the AS_PATH length in its decision process with the command bgp bestpath as-path ignore.

In some policy situations, you might want to limit the number of prefixes a router is allowed to accept from a neighbor. For example, you might know that only a certain number of prefixes should be advertised from a particular AS. Any number above this probably indicates a configuration mistake by that autonomous system's administrator. Or perhaps there is a service agreement in place in which you agree to accept only a finite number of prefixes; to advertise a larger number, the administrator of the neighboring AS must first get your approval. To enforce such a policy, you can use the neighbor maximum-prefix command. Consider the configuration in Example 3-73.

Example 3-73 Limiting the Number of Prefixes That a Router Is Allowed to Accept from a Neighbor


router bgp 100


 redistribute eigrp 100


 neighbor 192.168.1.253 remote-as 200


 neighbor 192.168.1.253 maximum-prefix 300


The router in Example 3-73 is configured to accept a maximum of 300 prefixes from neighbor 192.168.1.253. If the limit is exceeded, the router closes the BGP session with the neighbor, and the session cannot be reestablished until you issue the clear ip bgp 192.168.1.253 command.

Perhaps breaking the peering session might be too severe a consequence for exceeding the maximum prefixes, but you still want to be notified when it happens. The configuration in Example 3-74 does not close the session, but instead causes the router to generate a log message.

Example 3-74 Configuring the Router to Generate a Log Message When a Neighbor Exceeds the Number of Prefixes That Can Be Sent


router bgp 100


 redistribute eigrp 100


 neighbor 192.168.1.253 remote-as 200


 neighbor 192.168.1.253 maximum-prefix 300 warning-only


A log message is generated when the neighbor's advertised prefix exceeds 75 percent of the maximum—in this case, at 225 prefixes. You can change that default percentage. The configuration in Example 3-75 generates a log message when the neighbor's advertised prefixes exceed 90 percent of the maximum.

Example 3-75 Configuring the Router to Generate a Log Message When a Neighbor Exceeds 90 Percent of the Number of Prefixes That Can Be Sent


router bgp 100


 redistribute eigrp 100


 neighbor 192.168.1.253 remote-as 200


 neighbor 192.168.1.253 maximum-prefix 300 90 warning-only


On occasion, you might need to temporarily disconnect a peer but not want to delete its neighbor configuration. The configuration in Example 3-76 uses the neighbor shutdown command to disconnect the neighbor 192.168.1.237.

Example 3-76 Temporarily Disconnecting a Neighbor Connection


aggregate-address 192.168.192.0 255.255.248.0 as-set summary-only


 neighbor 192.168.1.1 remote-as 500


 neighbor 192.168.1.1 description ******T1 to Sun, Ckt. ID 54.HCGS.123456


 neighbor 192.168.1.237 remote-as 200


 neighbor 192.168.1.237 description ****Ethernet to Diamond, Interface E0


 neighbor 192.168.1.237 shutdown


 neighbor 192.168.1.250 remote-as 300


 neighbor 192.168.1.250 description ****T1 to Burke, Ckt. ID 54.HCGS.654321


 neighbor 192.168.1.254 remote-as 100


 neighbor 192.168.1.254 description ****56K to Stowe, Ckt. ID 54.DWDA.987654


The neighbor shutdown command in Example 3-76 closes the TCP port 179 connection to a specified neighbor, similar to the way the shutdown command disables a single interface. When the show ip bgp neighbor command is issued, the neighbor is indicated as administratively shut down.

Finally, you can use the timers bgp command to change the default BGP keepalive and hold time intervals of 60 seconds and 180 seconds. The argument can be made that reducing these intervals speeds the detection of an unreliable neighbor, but the real solution to such a problem is to eliminate the causes of the neighbor's unreliability. A change of the default intervals with this command applies to every neighbor, not just a single neighbor. Even if a neighbor has different default keepalive and hold time intervals, the intervals that are used are dynamically negotiated as part of the peering process. Therefore, under normal circumstances, there should be very few reasons to use this command.