Saturday, May 7, 2011

IP Prefix Notes

How a Prefix List Match Works
The matching is similar to that of the access-list—more specifically:
· An empty prefix list permits all prefixes.
· An implicit deny is assumed if a given prefix does not match any entries of a prefix list.
· When multiple entries of a prefix list match a given prefix, the one with the smallest sequence is considered as the “real” match. In short, the first match wins!

Wednesday, May 4, 2011

BGP notes

The BGP Path-Selection Process
1. Ignore paths marked as "not synchronized" in the output of show ip bgp
x.x.x.x. If BGP synchronization is enabled - which is the current default in IOS
Software - there must be a match for the prefix in the IP routing table for an
internal (that is, iBGP) path to be considered a valid path. Most ISPs will want
to disable synchronization using the no synchronization BGP subcommand.
2. Ignore paths for which the NEXT_HOP is inaccessible. This is why it is
important to have an IGP route to the NEXT_HOP associated with the path.
3. Ignore paths from an eBGP neighbor if the local AS appears in the AS path.
Such paths are denied upon ingress into the router and are not even installed
in the BGP RIB. The same applies to any path denied by routing policy
implemented through access, prefix, AS path, or community lists, unless
inbound soft reconfiguration is configured for the neighbor.
4. If bgp bestpath enforce-first-as is enabled and the UPDATE does not
contain the AS of the neighbor as the first AS number in the AS_SEQUENCE,
send a NOTIFICATION and close the session.
5. Ignore paths marked as "(received-only)" in the output of show ip bgp
x.x.x.x. This path has been rejected by policy but has been stored by the
router because soft-reconfiguration inbound has been configured for the
neighbor sending the path.
6. Ignore paths with a next -hop metric marked as inaccessible.

The BGP Best-Path Algorithm for IOS Software
1. Prefer the path with the largest weight. Note that weight is a Cisco specific
parameter, local to the router on which it is configured.
2. Prefer the path with the largest LOCAL_PREF.
3. Prefer the path that was locally originated through a network or aggregate
BGP subcommand or through redistribution from an IGP.
4. Prefer locally sourced network/redistributed paths over locally generated
aggregates.
5. Prefer the path with the shortest AS path.
A. This step is skipped if bgp bestpath as-path ignore is configured.
B. An AS_SET counts as one AS, no matter how many autonomous systems are in the set. The AS_CONFED_SEQUENCE is not included in the AS path length.
6. Prefer the path with the lowest origin type: IGP is lower than EGP, and EGP is
lower than INCOMPLETE.
7. Prefer the path with the lowest MED.
A. This comparison is done only if the first (that is, neighboring) AS is the
same in the two paths; any confederation sub-autonomous systems are ignored. In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same; any preceding AS_CONFED_SEQUENCE is ignored.
B. If bgp always-compare-med is enabled, MEDs are compared for all paths. This knob needs to be enabled over the entire AS. Otherwise, routing loops could occur.
C. If bgp bestpath med confed is enabled, MEDs are compared for all paths that consist only of AS_CONFED_SEQUENCE (that is, paths originated within the local confederation).
D. Paths received with no MED are assigned a MED of 0, unless bgp bestpath missing-is-worst is enabled, in which case they effectively are considered to have (although not actually assigned) a MED of 4,294,967,295. Any route 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.
E. BGP Deterministic MED also can influence this step.
8. Prefer the eBGP over iBGP paths. Note that paths containing AS_CONFED_SEQUENCE are local to the confederation and, therefore, are treated as internal paths. There is no distinction between confederation external and confederation internal.
9. Prefer the path with the lowest IGP metric to the BGP next hop.
10. If maximum-paths N is enabled and there are multiple external/confederation-external paths from the same neighboring AS/sub-AS, then insert up to N most recently received paths in the IP routing table. This allows eBGP multipath load sharing. The maximum value of N is currently 6; the default value, with the knob disabled, is 1. The oldest received path is marked as the best path in the output of show ip bgp x.x.x.x, and the equivalent of next-hop-self is performed before forwarding this best path on to internal peers.
11. Prefer the path that was received first (that is, the oldest one).
A. This step minimizes route flapping because a newer path will not displace an older one, even if it otherwise would be selected on account of the additional decision criteria below. It makes more sense to apply the additional decision steps only below to iBGP paths, to ensure a consistent best-path decision within the network and thereby avoid loops.
B. This step is skipped if bgp bestpath compare-routerid is enabled.
C. This step is skipped if the ROUTER_ID is the same because the routers were received from the same router.
D. This step is skipped if there is no current best path. An example of losing the current best path occurs when the neighbor offering the path goes down.
12. 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 interfaces if one or more are configured. It also can be set manually
through bgp router-id x.x.x.x. Note that if a path contains route reflector attributes, the originator ID is substituted for the router ID in the  path-selection process.
13. If the originator/router ID is the same, prefer the path with the minimum
cluster ID length. This will be present in BGP route-reflector environments
only, and it allows clients to peer with route reflectors/clients in other
clusters. In this scenario, the client must be aware of the route reflector-specific BGP attributes.
14. Prefer the path coming from the lowest neighbor address. This is the IP
address used in the BGP neighbor configuration, and it corresponds to the
address that the remote peer uses in the TCP connection with the local router.

Several limitations existed with BGP peer groups in older IOS Software versions:
· If used for clients of a route reflector, all the clients should be fully meshed.
· If used as an eBGP peer group, transit cannot be provided among the peer group members.
· All the eBGP peer-group members should be from the same subnet to avoid nonconnected next-hop announcements.

A list of peer groups commonly by ISPs follows:
· Normal iBGP peer group-For normal iBGP peers.
· iBGP client peer group- For reflection peers on a route reflector.
· eBGP full routes- For peers to receive full Internet routes.
· eBGP customer routes-For peers to receive routes from direct customers of the ISP only. Some members can be configured with default-origination to receive the default route as well as the customer routes.
· eBGP default routes-For peers to receive the default route and possibly a few other routes.

Two or more iBGP paths are considered candidates for multipath if the following
criteria are met:
· All attributes (weight, localpref, AS-PATH [entire attribute, not just length],
Origin, MED, and IGP distance are the same.
· The next hops are different.

Currently the prefix-list ORF is implemented for IPv4 unicast only. Some points to
note about the implementation are listed here:
· By default, the prefix-list ORF capability is not advertised to any neighbors.
· The capability cannot be advertised to a neighbor that is a peer group member.
· The prefix-list ORF is pushed over to the peer router immediately after the session is established if the local router has received the ORF capability and has configured an inbound prefix-list filter for the neighbor.