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
 

Case Study: Anycast RP

Designers of large, geographically diverse PIM-SM domains must often wrestle with the dilemma of where to most efficiently place the RPs. PIM-SM allows only a single group-to-RP mapping, which presents several problems in large domains:[4]

  • Possible traffic bottlenecks

  • Lack of scalable register decapsulation (when using shared trees)

  • Slow failover when an active RP fails

  • Possible suboptimal forwarding of multicast packets

  • Dependence on remote RPs

You read in Chapters 5 and 6 about different schemes for alleviating some of these problems, such as the hashing algorithm used with the PIMv2 bootstrap protocol and Auto-RP filtering. None of these tools offer a completely acceptable solution. Anycast RP is a method of allowing the mapping of a single group to multiple RPs. The RPs can be distributed throughout the domain, and all use the same RP address. As a result, a "virtual RP" is created. MSDP is fundamental to the creation of a virtual RP.

NOTE

Generically, anycasting means that packets can be sent to a single address, and one of several devices can respond to the address.


Figure 7-17 shows an example where the same routers from the preceding case study are used, but all four routers are running Auto-RP and are announcing an RP address of 10.100.254.1. Source DRs within the domain know of just the one RP address and register with the closest physical RP. Normally, this causes partitioning of the PIM domain. Using an MSDP mesh group, however, the anycast RPs can exchange source information within the group.

Figure 7-17. The Four Routers Form a Virtual RP, Announcing a Single RP Address of 10.100.254.1, and Using MSDP to Exchange Information About Sources That Have Registered to Each Router

graphics/07fig17.gif

The unicast routing protocol of each anycast RP advertises the common RP address. From the perspective of source and group DRs, there is just a single RP at this address, with several routes to it. A DR chooses the shortest route, which in reality leads to the nearest anycast RP. If the anycast RP fails, the unicast protocol announces the route to the RP as unfeasible. The DR sees only the unfeasible route and chooses the next-best route, which in reality leads to the next-nearest anycast RP. As a result, RP failover is linked to and almost as fast as the unicast reconvergence time.

The MSDP peering takes place as before, between the LO0 interfaces; however, another loopback interface is used to configure the RP address that the routers announce. Normally, MSDP uses the RP address in its SA messages. Because all four routers are announcing the same RP address, MSDP must be configured to use a unique address in its SA messages. The ip msdp originator-id command accomplishes this. Example 7-18 shows the relevant configurations of the four routers, using mesh groups and ip msdp originator-id.

Example 7-18 Configuring Frankenstein, Wolfman, Mummy, and Dracula for Anycast RP


Frankenstein


interface Loopback0


 ip address 10.100.1.1 255.255.255.255


!


interface Loopback5


 ip address 10.100.254.1 255.255.255.255


 ip pim sparse-dense-mode


!


router ospf 1


 router-id 10.100.1.1


 network 0.0.0.0 255.255.255.255 area 0


!


router bgp 6500


 bgp router-id 10.100.1.1


 neighbor Boogeymen peer-group


 neighbor Boogeymen remote-as 6500


 neighbor Boogeymen update-source Loopback0


 neighbor 10.100.1.2 peer-group Boogeymen


 neighbor 10.100.1.3 peer-group Boogeymen


 neighbor 10.100.1.4 peer-group Boogeymen


 !


 address-family ipv4 multicast


 neighbor 10.100.1.2 activate


 neighbor 10.100.1.3 activate


 neighbor 10.100.1.4 activate


 exit-address-family


!


ip pim send-rp-announce Loopback5 scope 20


ip pim send-rp-discovery Loopback5 scope 20


ip msdp peer 10.100.1.3 connect-source Loopback0


ip msdp description 10.100.1.3 to Mummy


ip msdp peer 10.100.1.2 connect-source Loopback0


ip msdp description 10.100.1.2 to Wolfman


ip msdp peer 10.100.1.4 connect-source Loopback0


ip msdp description 10.100.1.4 to Dracula


ip msdp mesh-group Boogeymen 10.100.1.3


ip msdp mesh-group Boogeymen 10.100.1.2


ip msdp mesh-group Boogeymen 10.100.1.4


ip msdp cache-sa-state


ip msdp originator-id Loopback0


_______________________________________________________________________





Wolfman


interface Loopback0


 ip address 10.100.1.2 255.255.255.255


!


interface Loopback5


 ip address 10.100.254.1 255.255.255.255


 ip pim sparse-dense-mode


!


router ospf 1


 router-id 10.100.1.2


 network 0.0.0.0 255.255.255.255 area 0


!


router bgp 6500


 bgp router-id 10.100.1.2


 neighbor Boogeymen peer-group


 neighbor Boogeymen remote-as 6500


 neighbor Boogeymen update-source Loopback0


 neighbor 10.100.1.1 peer-group Boogeymen


 neighbor 10.100.1.3 peer-group Boogeymen


 neighbor 10.100.1.4 peer-group Boogeymen


 !


 address-family ipv4 multicast


 neighbor 10.100.1.1 activate


 neighbor 10.100.1.3 activate


 neighbor 10.100.1.4 activate


 exit-address-family


!


ip pim send-rp-announce Loopback5 scope 20


ip pim send-rp-discovery Loopback5 scope 20


ip msdp peer 10.100.1.1 connect-source Loopback0


ip msdp description 10.100.1.1 to Frankenstein


ip msdp peer 10.100.1.3 connect-source Loopback0


ip msdp description 10.100.1.3 to Mummy


ip msdp peer 10.100.1.4 connect-source Loopback0


ip msdp description 10.100.1.4 to Dracula


ip msdp mesh-group Boogeymen 10.100.1.1


ip msdp mesh-group Boogeymen 10.100.1.3


ip msdp mesh-group Boogeymen 10.100.1.4


ip msdp cache-sa-state


ip msdp originator-id Loopback0


_______________________________________________________________________





Mummy


interface Loopback0


 ip address 10.100.1.3 255.255.255.255


!


interface Loopback5


 ip address 10.100.254.1 255.255.255.255


 ip pim sparse-dense-mode


!


router ospf 1


 router-id 10.100.1.3


 network 0.0.0.0 255.255.255.255 area 0


!


router bgp 6500


 bgp router-id 10.100.1.3


 neighbor Boogeymen peer-group


 neighbor Boogeymen remote-as 6500


 neighbor Boogeymen update-source Loopback0


 neighbor 10.100.1.1 peer-group Boogeymen


 neighbor 10.100.1.2 peer-group Boogeymen


 neighbor 10.100.1.4 peer-group Boogeymen


 !


 address-family ipv4 multicast


 neighbor 10.100.1.1 activate


 neighbor 10.100.1.2 activate


 neighbor 10.100.1.4 activate


 exit-address-family


ip pim send-rp-announce Loopback5 scope 20


ip pim send-rp-discovery Loopback5 scope 20


ip msdp peer 10.100.1.1 connect-source Loopback0


ip msdp description 10.100.1.1 to Frankenstein


ip msdp peer 10.100.1.2 connect-source Loopback0


ip msdp description 10.100.1.2 to Wolfman


ip msdp peer 10.100.1.4 connect-source Loopback0


ip msdp description 10.100.1.4 to Dracula


ip msdp mesh-group Boogeymen 10.100.1.1


ip msdp mesh-group Boogeymen 10.100.1.2


ip msdp mesh-group Boogeymen 10.100.1.4


ip msdp cache-sa-state


ip msdp originator-id Loopback0


_______________________________________________________________________





Dracula


interface Loopback0


 ip address 10.100.1.4 255.255.255.255


!


interface Loopback5


 ip address 10.100.254.1 255.255.255.255


 ip pim sparse-dense-mode


!


router ospf 1


 router-id 10.100.1.4


 network 0.0.0.0 255.255.255.255 area 0


!


router bgp 6500


 bgp router-id 10.100.1.4


 neighbor Boogeymen peer-group


 neighbor Boogeymen remote-as 6500


 neighbor Boogeymen update-source Loopback0


 neighbor 10.100.1.1 peer-group Boogeymen


 neighbor 10.100.1.2 peer-group Boogeymen


 neighbor 10.100.1.3 peer-group Boogeymen


 !


 address-family ipv4 multicast


 neighbor 10.100.1.1 activate


 neighbor 10.100.1.2 activate


 neighbor 10.100.1.3 activate


 exit-address-family


!


ip pim send-rp-announce Loopback5 scope 20


ip pim send-rp-discovery Loopback5 scope 20


ip msdp peer 10.100.1.1 connect-source Loopback0


ip msdp description 10.100.1.1 to Frankenstein


ip msdp peer 10.100.1.2 connect-source Loopback0


ip msdp description 10.100.1.2 to Wolfman


ip msdp peer 10.100.1.3 connect-source Loopback0


ip msdp description 10.100.1.3 to Mummy


ip msdp mesh-group Boogeymen 10.100.1.1


ip msdp mesh-group Boogeymen 10.100.1.2


ip msdp mesh-group Boogeymen 10.100.1.3


ip msdp cache-sa-state


ip msdp originator-id Loopback0


In Example 7-18, each of the four routers is configured as both an Auto-RP candidate RP and a mapping agent. You also can use static mapping or PIMv2 bootstrap with anycast RP. All four routers in this example are configured to cache SA messages.

Interface LO5 is used on each router to configure the virtual RP address, whereas LO0 is the endpoint of the MSDP sessions. Notice in the configurations that the Auto-RP commands reference LO5, whereas the ip msdp originator-id command references LO0. This is vital, because MSDP must have unique IP addresses at the endpoints of its peering sessions.

The OSPF and BGP stanzas are shown for an important reason. Recall that OSPF and BGP use the highest IP address configured on any loopback interface as its router ID. Unfortunately, the IP address on LO5 is higher on each router than the IP address on LO0. As a result, the OSPF and BGP processes on each router would by default use a router ID of 10.100.254.1. One of many undesirable results would be the thrashing of the OSPF databases as each router's LSAs try to override the other routers' LSAs. One solution is to always use a virtual RP address that is numerically lower than any other loopback address, but there are obvious impracticalities in this and some large vulnerabilities to inadvertent configuration mistakes. A better solution, used in this example, is to force each router to use its unique LO0 address with the router-id statement under the OSPF and BGP configurations.

Notice also that the LO0 interfaces are not running PIM. These interfaces are unnecessary to PIM functionality, and serve only to provide router-specific IP addresses for MSDP peering.