Why Routers Ignore Paths

If you assume that all received paths for a particular prefix are arranged in a list, similar to the output of the show ip bgp longer-prefixes command, then some paths received by the router aren’t considered as candidates for the best path. Such paths typically don’t have the valid flag in the output of the show ip bgp longer-prefixes command. The following is a list of reasons that cause routers to ignore paths.

• Paths marked as “not synchronized” in the show ip bgp longer-prefixes output. If BGP synchronization is enabled, which it is by default in Cisco IOS® Software, there must be a match for the prefix in the IP routing table in order for an internal (iBGP) path to be considered a valid path. If the matching route is learned from an OSPF neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor. Most users prefer to disable synchronization using the no synchronizationBGP subcommand. See the Synchronization section in Using the Border Gateway Protocol for Interdomain Routingfor more information.Note: Synchronization is disabled by default in Cisco IOS Software version 12.2(8)T and later.
• Paths for which the NEXT_HOP is inaccessible. This is why it’s important to have an IGP route to the NEXT_HOP associated with the path.
• Paths from an external (eBGP) neighbor if the local autonomous system (AS) appears in the AS_PATH. Such paths are denied upon ingress into the router, and are not even installed in the BGP routing-information base (RIB). The same applies to any path denied by routing policy implemented via access, prefix, AS_PATH, or community lists, unless you’ve configured soft-reconfiguration inbound for the neighbor.
• If you enabled bgp enforce-first-as and the UPDATE doesn’t contain the AS of the neighbor as the first AS number in the AS_SEQUENCE, the router sends a notification and closes the session.
• Paths marked as “(received-only)” in the show ip bgp longer-prefixes output. These paths have been rejected by policy, but have been stored by the router because soft-reconfiguration inbound has been configured for the neighbor sending the path.

How the Best Path Algorithm Works

BGP assigns the first valid path as the current best path. It then compares the best path with the next path in list, until it reaches the end of the list of valid paths. The following is a list of rules used to determine the best path.

1. Prefer the path with the highest WEIGHT.Note: WEIGHT is a Cisco-specific parameter, local to the router on which it’s configured.
2. Prefer the path with the highest LOCAL_PREF. Note the following:
   • Path without LOCAL_PREF is considered as having the value set with the bgp default local-preference command, or 100 by default.
3. Prefer the path that was locally originated via a network or aggregate BGP subcommand, or through redistribution from an IGP. Local paths sourced by network or redistribute commands are preferred over local aggregates sourced by the aggregate-address command.
4. Prefer the path with the shortest AS_PATH. Note the following:
   • This step is skipped if bgp bestpath as-path ignore is configured.
   • An AS_SET counts as 1, no matter how many ASs are in the set.
   • The AS_CONFED_SEQUENCE and AS_CONFED_SET are not included in the AS_PATH length.
5. Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is lower than INCOMPLETE.
6. Prefer the path with the lowest multi-exit discriminator (MED). Note the following:
   • This comparison is only done if the first (neighboring) AS is the same in the two paths; any confederation sub-ASs are ignored. In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.
   • If bgp always-compare-med is enabled, MEDs are compared for all paths. This option needs to be enabled over the entire AS, otherwise routing loops can occur.
   • If bgp bestpath med-confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE (paths originated within the local confederation).
   • Paths received from a neighbor with a MED of 4,294,967,295 will have the MED changed to 4,294,967,294 before insertion into the BGP table.
   • Paths received with no MED are assigned a MED of 0, unless bgp bestpath missing-as-worst is enabled, in which case they are assigned a MED of 4,294,967,294.
   • The bgp deterministic med command can also influence this step as demonstrated in the How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection.
7. Prefer external (eBGP) over internal (iBGP) paths. If bestpath is selected, go to Step 9 (multipath).Note: Paths containing AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation, and therefore treated as internal paths. There is no distinction between Confederation External and Confederation Internal.
8. Prefer the path with the lowest IGP metric to the BGP next hop. Continue, even if bestpath is already selected.
9. Check if multiple paths need to be installed in the routing table for BGP Multipath. Continue, if bestpath is not selected yet.
10. When both paths are external, prefer the path that was received first (the oldest one). This step minimizes route-flap, since a newer path will not displace an older one, even if it would be the preferred route based on the next decision criteria (Steps 11, 12, and 13).Skip this step if any of the following is true:
    • The bgp best path compare-routeridcommand is enabled.Note: This command was introduced in Cisco IOS® Software Releases 12.0.11S, 12.0.11SC, 12.0.11S3, 12.1.3, 12.1.3AA, 12.1.3.T, and 12.1.3.E.
    • The router ID is the same for multiple paths, since the routes were received from the same router.
    • There is no current best path. An example of losing the current best path occurs when the neighbor offering the path goes down.
11. Prefer the route coming from the BGP router with the lowest router ID. The router ID is the highest IP address on the router, with preference given to loopback addresses. It can also be set manually using the bgp router-idcommand.Note: If a path contains route-reflector (RR) attributes, the originator ID is substituted for the router ID in the path selection process.
12. If the originator or router ID is the same for multiple paths, prefer the path with the minimum cluster list length. This will only be present in BGP route-reflector environments. It allows clients to peer with RRs or clients in other clusters. In this scenario, the client must be aware of the RR-specific BGP attribute.
13. Prefer the path coming from the lowest neighbor address. This is the IP address used in the BGP neighbor configuration, and corresponds to the remote peer used in the TCP connection with the local router.

Customizing Path Selection Process

The extended community attribute, called BGP Cost Community, provides a way to customize the best path selection process. With this, the additional step of comparing Cost Communities can be inserted after the required step (Point of Insertion) of the aforementioned algorithm. The path with the lowest cost value is preferred. Note the following:

• This step is skipped if the bgp bestpath cost-community ignore command is configured.
• All the Cost Communities for a specific Point of Insertion are considered, starting with the one with the lowest Community-ID. Paths that do not contain the Cost Community (for the Point of Insertion and Comminuty-ID being considered), are presumed to have the default Cost value 2,147,483,647 (half of the maximum 4,294,967,295). If Costs are equal, Cost Community comparison proceeds to the next lowest Community-ID for this Point of Insertion.
• Currently, only IGP_COST Point of Insertion is implemented, that means that only Cost Communities with IGP_COST point of insertion will be considered after Step 8 of the aforementioned algorithm.

BGP Multipath

BGP Multipath allows multiple BGP paths to the same destination to be installed in the IP routing table together with the best path for load-sharing. BGP Multipath does not affect bestpath selection, for example, a router will still designate one of the paths as the best path, according to the algorithm, and advertise this best path to its neighbors.

BGP Multipath features are the following:

• eBGP Multipath: maximum-paths n
• iBGP Multipath: maximum-paths ibgp n
• eiBGP Multipath: maximum-paths eibgp n

To be candidates for multipath, paths to the same destination need to have the following characteristics equal to the best path’s characteristics:

• Weight
• Local-Preference
• AS-PATH length
• Origin
• MED
• One of the following:
  • Neighboring AS or sub-AS (before the eiBGP Multipath feature was added)
  • AS-PATH (after the eiBGP Multipath feature was added)

Some BGP Multipath features put additional requirements on multipath candidates.

Additional requirements for eBGP multipath are the following:

• The path should be learned from an external or confederation-external neighbor (eBGP).
• The IGP metric to the BGP next hop should be equal to the best path’s IGP metric.

Additional requirements for iBGP multipath are the following:

• The path should be learned from an internal neighbor (iBGP).
• The IGP metric to the BGP next hop should be equal to the best path’s IGP metric, unless the router is configured for unequal-cost iBGP multipath.

BGP inserts up to n most recently received paths from multipath candidates in the IP routing table. The maximum value of n is currently 6 and the default value, when multipath is disabled, is 1.

For unequal cost load balancing, you can also use BGP Link Bandwidth.

Note: The equivalent next-hop-self is performed on the best path selected among eBGP multipaths, before forwarding it to internal peers.

R1:

aaa new-model               —enable AAA

!

aaa authentication ppp R1 local-case                —Use keyword local-case(case-sensitive)

!

username CathsyachoolR2 password 0 CISCO             —-the username should be the same as R2 hostname

!

interface Serial1/0

ppp authentication chap R1

R2:                                                —hostname for R2 should be CathayschoolR2

interface Serial0/1

ppp chap password 0 CISCO

How WCCP works

1.A Web browser makes a request, which goes to a router.
2.The router intercepts the request.
3.The router redirects the request to a new location inside a generic routing encapsulation (GRE) frame to prevent any modifications to the original packet.
4.The new device — typically a Web appliance of some type — can choose to masquerade as the real server or send it somewhere else. Assuming it accepts the packet, the new device can provide a response.

 Configure WCCP

interface FastEthernet0/1

ip wccp 61 redirect in

 ip wccp 62 redirect out

access-list 110 permit ip any any 

ip wccp web-cache redirect-list 110