MPLS VPN - 3

MPLS LDP

LDP works similar to distance-vector protocols; it broadcasts all local prefixes with their respective labels. As soon as a local router learns the labels used by its neighbors for the same prefixes, it will program the LFIB with respective label values: incoming label (which has been locally generated) replaced with an outgoing label (used by the neighbor routers).

To enable MPLS switching on an interface and start LDP on the same interface, you must enter the interface-level command mpls ip . If you have too many interfaces to enable MPLS on, you may use MPLS LDP auto configuration, which is available when you run OSPF as your IGP protocol. Under the OSPF process, enter the command mpls ldp autoconfig. mpls ldp neighbor <IP> password <password>
By default, LDP will generate and advertise labels for every prefix found in the local routing table. Use mpls ldp advertise-labels for 10 command.

MP-BGP VPNv4

By default, when you create a new BGP neighbor using the command neighbor <IP> remote-as <NR> , the default IPv4 unicast address-family is activated for this neighbor. If for some reason you don’t want this behavior and only need the VPNv4 prefixes to be sent, you may disable the default behavior via the command no bgp default ipv4-unicast.

The VPN label is generated by the BGP process on the advertising router and directly corresponds to the local VRF route. The /32 restriction is needed to guarantee that the transport LSP terminates on the particular PE router, and not some shared network segment Check the MPLS labels (VPN labels) assigned to the VPN prefixes at the PE routers. There are two labels in the stack; one is the VPN label and the other is the transport label. You may find the VPN label in the BGP table, and the transport label can be found by looking up the VPNv4 BGP next-hop in the MPLS forwarding table.

MP-BGP Prefix Filtering

The special export route-map associated with the VRF could match the prefixes based on the prefix-lists, access-lists, or extendedcommunities. All routes not permitted in an export route-map are not exported into the BGP process. The export route-map may also be used to set the extendedcommunity attribute selectively, using the command set extcommunity rt.

PE-CE Routing with RIP

When you need to redistribute the MP-BGP routes into RIP, use the command redistribute bgp <N> metric [X|transparent] under the respective address family. Here, N is the BGP process number (AS#) and X is the metric assigned to the RIP routes. If you are using the keyword transparent , the RIP metrics will be recovered from the BGP MED attribute, which in turn is copied from RIP metrics learned at the remote site. This allows for transparent preservation of RIPv2 metric values across the VPN and better path selection in case of backdoor links.

PE-CE Routing with OSPF

All OSPF routes redistributed into MP-BGP are treated pretty much like Type 3 summary LSAs, because they enter the super-backbone from other areas. When
injected into BGP, OSPF prefixes have two extended-community attributes attached to them. One of the attributes is known as domain-id, which is equal to the OSPF
process numbers on the local router OR explicitly configured using the command domain-id under the OSPF process. The purpose of this attribute is to identify
OSPF processes belonging to different VPNs. It is assumed that you configured all OSPF processes within the same VPN using the same domain-id (such as the same
process number). If for some reason you exchange routes between two different VPNs using different domain-ids, the OSPF process will interpret all such prefixes
as if they are Type-5 External LSAs, effectively external routes. The other extended community attribute is known as the OSPF route-type, which
has three significant fields: source area, route-type, and option. They are usually depicted as triple X:Y:Z. Here, Y=2 for intra-area learned prefix, Y=3 for inter-area routes, Y=5 for external prefixes.

Notice that all routes redistributed from BGP into OSPF appear like inter-area routes even if they belong to the same area number at different sites. This effect occurs because the LSAs cross the super-backbone and essentially are inter-area routes. The last BGP attribute used to carry OSPF information is MED or metric, which copies the original route’s metric from the routing table. The route-type attribute is needed to allow for proper OSPF best-path calculation when routes are inserted into the OSPF database based on redistribution from BGP. Notice that the routes traveling the MP-BGP cloud do not increment their metric unless you manually change the MED attribute for incoming BGP prefixes.

OSPF implements some basic loop prevention rules. First, all summary LSAs generated from the routes redistributed from BGP have a special “Down” bit set in the LSA headers. If a router receives a summary-LSA with the down bit set on an interface that belongs to a VRF, it simply drops this LSA. This is to prevent the case of routing loops for multi-homed sites, when a summary LSA is flooded across the CE site and delivered back to another PE. However, this feature may have an undesirable effect when you have a CE router configured with multiple VRFs. In this case, you may want to enter the OSPF process command capability vrf-lite on the CE router. This will disable the default loop-prevention capability. Be advised that some IOS versions do not support this feature (such as older IOSs or some Catalyst IOS revisions). If you have such a router configured for multi-VRF and experience route black holing, configure the PE routers with different
domain-IDs; this will force all redistributed routes to become external and bypass the down-bit check. Note that in newer IOS versions, such as the one used in this example, the down bit is also included in Type-5 LSAs. capability vrf-lite would be needed.

The other feature is based on the route tagging. All routes redistributed via a particular PE will carry the OSPF route tag with the BGP AS number encoded
inside. The receiving router that has VRFs enabled will compare the AS number in the tag with the local BGP AS number. If they match, this could mean the LSA has
looped back to another PE connecting the same site to the MPLS backbone. If for some reason you encounter this issue and need to get rid of it, simply apply a
proper tag to the redistributed routes.

OSPF Sham-Link

If the link is in the same area as the PE/CE routers, the PE routers will prefer the path across the back-door link, because OSPF treats all paths across it
as intra-area, and the prefixes received via MP-BGP are interpreted as inter-area.
OSPF sham-link is a special tunnel similar to a virtual-link connecting two PE routers and configured in the same area as the PE routers. When the routes are being installed in the respective VRF RIB, the forwarding information is based on looking up the MP-BGP learned routes based on exact prefix-match. The corresponding VPN and transport labels are then used for actual packet forwarding across the MPLS core. Therefore, the information loaded across the sham-link is used only for SPF calculations and best-path selection; the actual forwarding is being done based on the information learned via MP-BGP.

Sham-links are sourced off actual interfaces configured in the respective VRF. Commonly, these are Loopback interfaces used as endpoints for the shamlink
tunnel. Notice that the IP addresses for these interfaces should be advertised into the VRF routing table by means other than OSPF, most commonly via BGP.
The sham-link’s endpoints should not be advertised into OSPF.

PE-CE Routing with EIGRP

One issue with transporting EIGRP routes over MP-BGP is preserving the original metric values, the route type, the source AS#, and the remote Router ID. These all are encoded using special BGP extended-community attributes that allow the remote site to properly decode the incoming routing update information.

Of course, the local EIGRP process will treat all prefixes originated in different remote AS# as external, per the normal EIGRP rules. Therefore, the AS# and the Router-ID information could be crucial to resolve potential routing loops in scenarios with backdoor links between the VPN sites. Another special attribute used with EIGRP prefixes redistributed into MP-BGP is known as the “cost attribute.” Although this attribute was designed to have pretty wide use, the main idea is to change the BGP best-path selection process. The problem with MPLS VPN route redistribution is that the same route may enter the PE’s BGP table using redistribution (learned from a CE router) and via a BGP update (learned from a remote site). Per the BGP best-path selection process, locally redistributed prefixes have a BGP weight of 32768, which make them always win the best-path selection process. Therefore, BGP will always choose the locally received update even if the remote site has better a EIGRP metric to reach the destination.

To resolve this issue, EIGRP prefixes redistributed into MP-BGP will have the Cost attribute value set to their composite metric. The BGP process will honor the Cost attribute value before ANY other best-path selection option if the attribute is present. The prefix with the lowest cost will immediately win the best-path selection and will be redistributed into the local EIGRP process. This process happens automatically and does not require any additional configuration. Notice that the Cost attribute is NOT needed with OSPF because the prefixes received via MP-BGP are treated as inter-area and are always less preferred compared to the same prefixes learned as intra-area from a CE device. When RIP is used for PE-CE routing, Cisco IOS does not implement the Cost attribute at all, so the locally redistributed prefixes will always get preferred over MP-BGP learned prefixes, preventing effective RIP deployment in scenarios with backdoor links.

When configuring EIGRP for MPLS VPNs, the same process is shared among multiple VRFs. An address family must be configured per VRF under the routing
process, and for every address-family you must configure an AS number using the command autonomous-system N . This command is mandatory to enable EIGRP for
that particular VRF.

EIGRP Site-of-Origin

With multi-homed scenarios similar to the ones we are using, BGP and EIGRP perform mutual redistribution at PE routers. This may potentially result in transient
routing loops, when a prefix is withdrawn in MP-BGP at one PE router and it is not timely propagated into EIGRP. EIGRP could then feed the invalid information back to BGP at another PE router, keeping the false information circulating between the PE routers until it’s eliminated by counting to infinity. The core of this problem is the mutual redistribution that allows the information learned from BGP at one site to reenter BGP at another site.

Cisco IOS implements a special feature known as EIGRP Site-of-Origin (SoO), which uses an extended community appended to BGP and EIGRP routing updates. All BGP prefixes redistributed into EIGRP and sent over the interface with the SoO set will have this extended community appended, but only if the community is not already present. If the update to be sent already has the same extended community value set, it is discarded as being redistributed back to the same site. The next thing that this feature does is apply the same extended community to all EIGRP routes received on the interface and redistributed into BGP. All these actions are performed by IOS automatically; you need only apply the route-map to the relevant interfaces.

-If you need to preserve the path across the MPLS core network, you should use different SoO values at every PE router of a multi-homed site. However, this means that the MP-BGP information injected into EIGRP at one PE router will reach the other PEs without being blocked. To prevent this effect, an additional SoO interface should be configured on the CE routers with the backdoor link.

BGP - 2 - BGP Routing Policies

Route Filtering and Route Summarization

Four popular tools used to filter BGP routes:

1. Distribution lists
2. Prefix lists
3. AS_PATH filter lists
4. Route maps

Additionally, the aggregate-address.

The four main tools have the following features in common:

• All can filter incoming and outgoing Updates, per neighbor or per peer group.
• Peer group configurations require Cisco IOS Software to process the routing policy against the Update only once, rather than once per neighbor.
• The filters cannot be applied to a single neighbor that is configured as part of a peer group.
• Each tool’s matching logic examines the contents of the BGP Update message, which includes the BGP PAs and network layer reachability information (NLRI).
• If a filter’s configuration is changed, a clear command is required for the changed filter to take effect.
• The clear command can use the soft reconfiguration option.

Filtering BGP Updates Based on NLRI

One difference between BGP distribute lists and IGP distribute lists is that a BGP distribute list can use an extended ACL to match against both the prefix and the prefix length. When used with IGP filtering tools, ACLs called from distribute lists cannot match against the prefix length.

The prefix list matches the exact prefixes and prefix lengths; the omission of any ge or le parameter means each line matches only that exact prefix.

Both the route map and any referenced ACL or prefix list have deny and permit actions configured. The route-map command’s action—either deny or permit —defines whether an NLRI is filtered ( deny ) or allowed to pass ( permit ). The permit or deny action in an ACL or prefix list implies

whether an NLRI matches the route map clause ( permit by the ACL/prefix list) or does not match ( deny in the ACL/prefix list).

To support soft reconfiguration, BGP must remember the actual sent and received BGP Update information for each neighbor. The neighbor neighbor-id soft-reconfiguration inbound command causes the router to keep a copy of the received Updates from the specified neighbor. (IOS keeps a copy of sent Updates automatically.) 

For configuration changes that impact the local injection of routes into the BGP table, soft reconfiguration does not help. The reason is that soft

reconfiguration simply reprocesses Updates, and features that inject routes into BGP through the redistribute or network commands are not injected based on Update messages.

Comparing BGP Prefix Lists, Distribute Lists, and Route Maps

If the desired policy is only to filter routes based on matching prefixes/lengths, a route map does not provide any additional function over using a distribute list or prefix list directly. Similarly, if the goal of the policy is to filter routes just based on matching with an AS_PATH filter, the route map does not provide any additional function as compared to calling an AS_PATH filter directly using the neighbor filter-list command. However, only route maps can provide the following two functions for BGP routing policy configurations:

• Matching logic that combines multiples of the following: prefix/length, AS_PATH, or other BGP PAs.
• The setting of BGP PAs for the purpose of manipulating BGP’s choice of which route to use

Filtering Subnets of a Summary Using the aggregate-address Command

The filtering options on the aggregate-address command are as follows:

• Filtering all component subnets of the summary from being advertised, by using the summary-only keyword
• Advertising all the component subnets of the summary, by omitting the summaryonly keyword
• Advertising some and filtering other component subnets of the summary, by omitting the summary-only keyword and referring to a route map using the suppressmap keyword.

Filtering BGP Updates by Matching the AS_PATH PA

To filter routes by matching the AS_PATH PA, Cisco IOS uses AS_PATH filters.

The main two steps are as follows:

1. Configure the AS_PATH filter using the ip as-path access-list number { permit | deny } regex command.
2. Enable the AS_PATH filter using the neighbor neighbor-id filter-list as-path-filter-number { in | out } command.

Because the most recently added ASN is the first ASN in the AS_SEQUENCE segment, the process of adding the ASN before advertising routes to external BGP (eBGP) peers is called AS_PATH prepending. 

Including the as-set keyword, R4 creates an AS_SET segment in the AS_PATH of the aggregate route. Note that the AS_SET segment is shown in brackets, and it is listed in no particular order. These facts are all important to the process of AS_PATH filtering.

Confederation ASNs are used to prevent loops inside the confederation. Because these ASNs will be removed before advertising the route outside the full AS, the confederation ASNs are kept inside a different segment—the AS_CONFED_SEQ segment. Finally, if a route is aggregated inside a confederation, the AS_CONFED_SET segment holds the confederation ASNs with the same logic as used by the AS_SET segment type, but keeps them separate for easy removal before advertising the routes outside the confederation.

The show ip as-path-access-list command shows the contents of the list.

The show ip bgp neighbor neighbor-id advertised-routes command displays the routes actually sent—in other words, this command reflects the effects of the filtering by omitting the filtered routes from the output.

The show ip bgp neighbor neighbor-id received-routes command displays the routes actually received from a neighbor, never omitting routes from the output, even if the router locally filters the routes on input.

Output filter lists are applied before the router adds its own ASN to the AS_PATH.

A couple of ways to test regex without changing the routing policy.

show ip bgp neighbor 10.1.34.4 received-routes | include 4_1_.*_.*_.*_44

This command parses the entire command output using the regex after the include keyword.

The other method to test a regex is to use the show ip bgp regexp expression command. This command parses the AS_PATH variables in a router’s BGP table, including all special characters. However, the regexp option of the show ip bgp command is not allowed with the received-routes or advertised- routes option.

Note that the "(" must be matched by enclosing it in square brackets, as ! the "(" itself and the ")" are metacharacters, and would otherwise be interpreted as a metacharacter. Without the "[(]" to begin the regex, the ! AS_PATH filter would not match. Because the "{" and "}" are not metacharacters, they can simply be typed directly into the regex.

BGP Path Attributes and the BGP Decision Process

Each BGP PA can be described as either a well-known or optional PA. 

Well-known PAs are either one of the following:

• Mandatory: The PA must be in every BGP Update.
•  Discretionary: The PA is not required in every BGP Update.

The BGP Decision Process

1. Is the NEXT_HOP reachable?
2. Highest administrative weight
3. Highest LOCAL_PREF PA
4. Locally injected routes
5. Shortest AS_PATH length: The length calculation ignores both AS_CONFED_SET and AS_CONFED_SEQ, and treats an AS_SET as one ASN, regardless of the number of ASNs in the AS_SET. It counts each ASN in the AS_SEQUENCE as one. (This step is ignored if the bgp bestpath as-path ignore command is configured.)
6. ORIGIN PA
7. Smallest Multi-Exit Discriminator (MED) PA: The smaller the value, the better the route.
8. Neighbor Type: Prefer external BGP (eBGP) routes over internal BGP (iBGP).
9. IGP metric for reaching the NEXT_HOP.

If a step determines the best route for an NLRI, BGP does not bother with the remaining steps.

When overlapping NLRIs exist—for example, 130.1.0.0/16, 130.2.0.0/16, and 130.0.0.0/12—BGP attempts to find the best route for each specific prefix/prefix length.
First and last of the nine items relate to NEXT_HOP.

Configuring BGP Policies

The show ip bgp <network> command lists the advertising router’s RID and neighbor ID.

The "from z.z.z.z" phrases identify the neighbor ID that advertised the route. The "(y.y.y.y)" output that follows lists the RID of that same router.

Step 1: NEXT_HOP Reachable

Step 2: Administrative Weight

Default 0 for learned routes, 32,768 for locally injected routes

The neighbor route-map command creates an implied filtering decision. Any route matched by a permit clause in the route map is implied to be allowed through, and routes matched by a deny clause will be filtered. Route maps use an implied deny all at the end of the route map for any unmatched routes. By including a final clause with just a permit keyword, the route map changes to use permit all logic, thereby passing all routes.

Step 3: Highest Local Preference (LOCAL_PREF)

Changing the default Using the bgp default local-preference <0-4294967295> BGP subcommand

Step 4: Choose Between Locally Injected Routes Based on ORIGIN PA

When the same NLRI is locally injected into BGP from multiple methods, pick the route with the better ORIGIN PA.

Step 5: Shortest AS_PATH

bgp bestpath as-path ignore command - Removes the AS_PATH length step from the decision tree for the local router.

Removing Private ASNs - 

 Private ASNs can be removed only at the point of sending an eBGP Update.

 If the current AS_SEQ contains both private and public ASNs, the private ASNs will not be removed.

 If the ASN of the eBGP peer is in the current AS_PATH, the private ASNs will not be removed, either.

The aggregate-address command with the as-set option can lengthen the AS_PATH length calculation as well.

The BGP AS_PATH length calculation counts the entire AS_SET as 1, regardless of the actual length.

Step 6: Best ORIGIN PA

The well-known mandatory BGP ORIGIN PA characterizes a route based on how it was injected into BGP. 

If the set of routes to reach a single NLRI includes only one route of ORIGIN code IGP (i), and all the others as incomplete (?), the route with ORIGIN i is the best route. BGP routing policies can set the ORIGIN code explicitly by using the set origin route

map subcommand, although the earlier steps in the BGP decision process are typically better choices.

Step 7: Smallest Multi-Exit Discriminator

Scope - Advertised by one AS into another, propagated inside the AS but not sent to any other ASs. Smaller is better.

The purpose of the MED (or MULTI_EXIT_DISC) is to allow routers in one AS to tell routers in a neighboring AS how good a particular route is. A default setting is 0. MED. A better default for MED can be set by using the bgp bestpath med missing-as-worst BGP subcommand, which resets a router’s default MED to the largest possible MED value, instead of the lowest.

Configuring MED: Multiple Adjacent Autonomous Systems

By default, a Cisco router ignores MED when the multiple routes to a single NLRI list different neighboring ASNs. This default action makes sense—normally you would not expect two different neighboring ISPs to have chosen to work together to set MEDs. To override this default and consider the MED in all cases, a router needs to configure the bgp always-compare-med BGP subcommand. If used on one router, all routers inside the

same AS should also use the bgp always-compare-med command, or routing loops can result.

After reaching the other AS, the MED is advertised inside the AS, but not outside the AS.

MED can also be set through inbound route maps, although that is not the intended design with which to use MED.

Step 8: Prefer Neighbor Type eBGP over iBGP

BGP uses this decision point frequently when two or more enterprise routers connect to the same ISP.

Each enterprise border router knows of one eBGP route to reach each prefix, and one or more iBGP routes to the same prefix learned from that enterprise’s other border routers. With no routing policies configured, the routes tie on all decision points up to this one, including AS_PATH length, because all the prefixes were learned from the same neighboring ISP. The decision process reaches this step, at which point the one eBGP route is picked as the best route.

Step 9: Smallest IGP Metric to the NEXT_HOP

Step 10: Lowest BGP Router ID of Advertising Router

Step 11: Lowest Neighbor ID

The BGP maximum-paths Command

BGP defaults the maximum-paths command to a setting of 1. However, BGP will consider adding multiple entries to the IP routing table, for the same NLRI, under certain conditions—conditions that differ based on whether the best route is an eBGP route or an iBGP route.

The following rules determine if and when a router will add multiple eBGP routes to the IP routing table for a single NLRI:

1. BGP must have had to use a tiebreaker (Step 10 or 11) to determine the best route.
2. The maximum-paths number command must be configured to something larger than the default of 1.
3. Only eBGP routes whose adjacent ASNs are the same ASN as the best route are considered as candidates.
4. If more candidates exist than that called for with the maximum-paths command, the tiebreakers of Steps 10 and 11 determine the ones to use.

The rules for iBGP have some similarities with eBGP, and a few differences, as follows:

1. Same rule as eBGP rule 1.
2. The maximum-paths ibgp number command defines the number of possible IP routes, instead of the maximum-paths number command used for eBGP.
3. Only iBGP routes with differing NEXT_HOP settings are considered as candidates.
4. Same rule as eBGP rule 4.

BGP Communities

The BGP COMMUNITY PA provides a mechanism by which to group routes so that routing policies can be applied to all the routes with the same community. 

BGP communities are powerful in that they allow routers in one AS to communicate policy information to routers that are one or more autonomous systems distant. In fact, because the COMMUNITY PA is an optional transitive PA, it can pass through autonomous systems that do not even understand the COMMUNITY PA and then still be useful at another downstream AS.

The only way to match the COMMUNITY is to refer to an ip community-list , which then has the matching parameters.

The set community 10 20 30 additive command would add the values to the existing COMMUNITY string.

The show ip bgp community-list list-number command is then used to show whether a match would be made. This command lists the entries of the BGP table that match the associated COMMUNITY PA, much like the show ip bgp regex command examines the AS_PATH PA.

The set community none command in a route-map clause, and all routes matched by that clause will have their COMMUNITY PA removed. A route map can also remove individual COMMUNITY strings by using the set commlist community-list-number delete command.

Filtering NLRIs Using Special COMMUNITY Values

A route with COMMUNITY NO_EXPORT is not advertised outside an AS. This value can be used to prevent an AS from being a transit AS for a set of prefixes. 

Finally, routes with these settings can be seen with commands like show ip bgp community noexport, with similar options NO_ADVERT and LOCAL_AS.

Fast Convergence Enhancements

BGP only provides updates to its neighbors periodically using an interval based on the peering type: iBGP peers receive updates every 5 seconds, whereas eBGP peers are updated only every 30 seconds. BGP will only verify next-hop reachability every 60 seconds.

Fast External Neighbor Loss Detection

The eBGP session between directly connected eBGP neighbors will be torn down the moment that the connected subnet between the peers is lost. This will result in the immediate flushing of BGP routes, and BGP will immediately begin looking at alternate routes. 

Internal Neighbor Loss Detection

With the neighbor fall-over command, the moment that the IP address of the BGP peer is removed from the routing table, the BGP session with the peer will be torn down, thus resulting in immediate convergence. 

EBGP Fast Session Deactivation

Use it to quickly detect failures of eBGP sessions established between loopback interfaces of eBGP peers or to detect eBGP neighbor loss when you disable fast external fall-over.

Summary

network ip-address backdoor 

- BGP mode; identifies a network as a backdoor route, considering it to have the same administrative distance as iBGP routes

BGP - 1 - Foundation

BGP does not use a metric to select the best route among alternate routes to the same destination. Instead, BGP uses several BGP path attributes (PA). BGP uses the BGP autonomous system path (AS_PATH) PA as its default metric mechanism when none of the other PAs has been overly set and configured.

After the TCP connection is established, BGP begins with BGP Open messages. After a pair of BGP Open messages has been exchanged, the neighbors have reached the established state, which is the stable state of two working BGP peers. At this point, BGP Update messages can be exchanged.

Peer-group allows fewer configuration commands, and improves processing efficiency by having to prepare only one set of outbound Update packets for the peer group. BGP builds one set of Update messages for the peer group, applying routing policies for the entire group—rather than one router at a time—thereby reducing some BGP processing and memory overhead.

For eBGP connections, Cisco IOS defaults the IP packet’s TTL field to a value of 1, based on the assumption that the interface IP addresses will be used for peering.

Checks Before Becoming BGP Neighbors
1. The router must receive a TCP connection request with a source address that the router finds in a BGP neighbor command.
2. A router’s ASN (on the router bgp asn command) must match the neighboring router’s reference to that ASN with its neighbor remote-as asn command. (This requirement is not true of confederation configurations.)
3. The BGP RIDs of the two routers must not be the same.
4. If configured, MD5 authentication must pass.

BGP uses a keepalive timer to define how often that router sends BGP keepalive messages, and a Hold timer to define how long a router will wait without receiving a keepalive message before resetting a neighbor connection. The Open message includes each router’s stated keepalive timer. If they do not match, each router uses the lower of the values for each of the two timers, respectively. Mismatched settings do not prevent the routers from becoming neighbors.

BGP Messages and Neighbor States

The desired state for BGP neighbors is the established state in which the routers have formed a TCP connection, and they have exchanged Open messages, with the parameter checks having passed. At this point, topology information can be exchanged using Update messages. If the IP addresses mismatch, the neighbors settle into an active state.

Building the BGP Table

The BGP topology table , also called the BGP Routing Information Base (RIB) , holds the network layer reachability information (NLRI) learned by BGP, as well as the associated PAs. Technically, BGP does not advertise routes; rather, it advertises PAs plus a set of NLRI that shares the same PA values. However, most people simply refer to NLRI as BGP prefixes or BGP routes.

The BGP network command instructs that router’s BGP process to do the following:

• Look for a route in the router’s current IP routing table that exactly matches the parameters of the network command; if the IP route exists, put the equivalent NLRI into the local BGP table.
• With this logic, connected routes, static routes, or IGP routes could be taken from the IP routing table and placed into the BGP table for later advertisement. When the router removes that route from its IP routing table, BGP then removes the NLRI from the BGP table, and notifies neighbors that the route has been withdrawn.

Impact of Auto-Summary on Redistributed Routes and the network Command

As it does with IGPs, the BGP auto-summary command causes a classful summary route to be created if any component subnet of that summary exists. However, unlike IGPs, the BGP auto-summary router subcommand causes BGP to summarize only those routes injected because of redistribution on that router. It simply looks for routes injected into the BGP because of the redistribute and network commands on that same router.

The logic differs slightly based on whether the route is injected with the redistribute command or the network command. The logic for the two commands is summarized as follows:

redistribute: If any subnets of a classful network would be redistributed, do not redistribute, but instead redistribute a route for the classful network.

network: If a network command lists a classful network number, with the classful default mask or no mask, and any subnets of the classful network exist, inject a route for the classful network.

For redistribution, the auto-summary command causes the redistribution process to inject only classful networks into the local BGP table, and no subnets. The network command, with auto-summary configured, still injects subnets based on the same logic. In addition to that logic, if a network command matches the classful network number, BGP injects the classful network, as long as at least any one subnet of that classful network exists in the IP routing table.

Manual Summaries and the AS_PATH Path Attribute

BGP manual summarization with the aggregate-address command can summarize based on any routes in the BGP table, creating a summary of any prefix length. It does not always suppress the advertisement of the component subnets, although it can be configured to do so. The aggregate route must include the AS_PATH PA, just like it is required for every other NLRI in the BGP table.

The AS_PATH PA consists of up to four different components, called segments , as follows:

• AS_SEQ (short for AS Sequence)
• AS_SET
• AS_CONFED_SEQ (short for AS Confederation Sequence)
• AS_CONFED_SET

When the component subnets of the summary route have differing AS_SEQ values, the router simply can’t create an accurate representation of AS_SEQ, so it uses a null AS_SEQ. However, this action introduces the possibility of creating routing loops. 

The AS_PATH AS_SET segment solves the problem when the summary route has a null AS_SEQ. The AS_SET segment holds an unordered list of all the ASNs in all the component subnets’ AS_SEQ segments.

"atomic-aggregate" refers to the fact that the ATOMIC_AGGREGATE PA has also been set; this PA simply states that this NLRI is a summary.

The following list summarizes the actions taken by the aggregate-address command when it creates a summary route:

• It does not create the summary if the BGP table does not currently have any routes for NLRI inside the summary.
• If all the component subnets are withdrawn from the aggregating router’s BGP table, it also then withdraws the aggregate. (In other words, the router tells its neighbors that the aggregate route is no longer valid.)
• It sets the NEXT_HOP address of the summary, as listed in the local BGP table, as 0.0.0.0.
• It sets the NEXT_HOP address of the summary route, as advertised to neighbors, to the router’s update source IP address for each neighbor, respectively.
• If the AS_SEQ of the component subnets differs in any way, it sets the AS_SEQ of the new summary route to null.
• When the as-set option has been configured, the router creates an AS_SET segment for the aggregate route, but only if the summary route’s AS_SEQ is null.
• It suppresses the advertisement of all component subnets if the summary-only keyword is used, advertises all of them if the summary-only keyword is omitted, or advertises a subset if the suppress-map option is configured.

Adding Default Routes to BGP

Default routes can be injected into BGP in one of three ways:

• By injecting the default using the network command
• By injecting the default using the redistribute command
• By injecting a default route into BGP using the neighbor neighbor-id defaultoriginate [ route-map route-map-name ] BGP subcommand

   When you inject a default route into BGP using the network command, a route to 0.0.0.0/0 must exist in the local routing table, and the network 0.0.0.0 command is required.

   Injecting a default route through redistribution requires an additional configuration command—default-information originate . The default route must first exist in the IP routing table.

   Injecting a default route into BGP by using the neighbor neighbor-id default-originate [ route-map route-map-name ] BGP subcommand does not add a default route to the local BGP table; instead, it causes the advertisement of a default to the specified neighbor. In fact, this method does not even check for the existence of a default route in the IP routing table by default, but it can.

ORIGIN Path Attribute

The ORIGIN PA provides a general descriptor as to how a particular NLRI was first injected into a router’s BGP table. Routes redistributed into BGP from an IGP actually have an ORIGIN code of incomplete.

BGP Update Message

If a router needs to advertise a set of NLRIs, and each NLRI has a different setting for at least one PA, separate Update messages will be required for each

NLRI. However, when many routes share the same PAs—typical of prefixes owned by a particular ISP, for example—multiple NLRIs are included in a single Update. This reduces router CPU load and uses less link bandwidth.

For a route to be a candidate to be considered best, the NEXT_HOP must be either

• 0.0.0.0, as the result of the route being injected on the local router.
• Reachable according to that router’s current IP routing table. In other words, the NEXT_HOP IP address must match a route in the routing table.

Note that the NEXT_HOP PA cannot be set through a route map. 

For the received-routes option to work, the router on which the command is used must have the neighbor neighbor-id soft-reconfiguration inbound BGP subcommand configured for the other neighbor.

These show ip bgp neighbor commands with the advertised-routes option list the BGP table entries that will be advertised to that neighbor. However, note that any changes to the PAs inside each entry are not shown in the command output.

Summary of Rules for Routes Advertised in BGP Updates

The following list summarizes the rules dictating which routes a BGP router sends in its update messages:

• Send only the best route listed in the BGP table.
• To iBGP neighbors, do not advertise paths learned from other iBGP neighbors.
• Do not advertise suppressed or dampened routes.
• Do not advertise routes filtered through configuration.

Adding eBGP Routes to the IP Routing Table

Cisco IOS Software uses simple logic when determining which eBGP routes to add to the IP routing table. 

• The eBGP route in the BGP table is considered to be a “best” route.
• If the same prefix has been learned through another IGP or through static routes, the AD for BGP external routes must be lower than the ADs for other routing source(s).

BGP sets the AD differently for eBGP routes, iBGP routes, and for local (locally injected) routes—with defaults of 20, 200, and 200, respectively.

The actual IP route added to the IP routing table contains the exact same prefix, prefix length, and next-hop IP address as listed in the BGP table—even if the NEXT_HOP PA is an IP address that is not in a connected network. As a result, the IP forwarding process might require a recursive route lookup.

Backdoor Routes(network backdoor) will use the local AD (default 200) for the eBGP-learned route to network. 

Adding iBGP Routes to the IP Routing Table

Cisco IOS has the same two requirements for adding iBGP routes to the IP routing table as it does for eBGP routes:

• The route must be the best BGP route.
• The route must be the best route (according to the AD) in comparison with other routing sources.

Additionally, for iBGP-learned routes, IOS considers the concept of BGP synchronization. 

The key to understanding BGP sync is to know that redistribution solves the routing

black-hole problem, and sync solves the problem of advertising a black-hole route to

another AS. 

The BGP sync logic controls that decision as follows: Do not consider an iBGP route in the BGP table as “best” unless the exact prefix was learned through an IGP and is currently in the routing table. The route must be IGP-learned not via own's static route.

Sync includes an additional odd requirement when OSPF is used as the IGP. If the OSPF RID of the router advertising the prefix is a different number than the BGP router advertising that same prefix, sync still does not allow BGP to consider the route to be the best route.

Disabling Sync and Using BGP on All Routers in an AS

A second method to overcome the black-hole issue is to simply use BGP to advertise all the BGP-learned prefixes to all routers in the AS. BGP needs the full mesh of iBGP peers inside an AS because BGP does not advertise iBGP routes (routes learned from one iBGP peer) to another iBGP peer. BGP offers two tools (confederations and route reflectors) that reduce the number of peer connections inside an AS, prevent loops, and allow all routers to learn about all prefixes.

Confederations

Peers inside the same sub-AS are considered to be confederation iBGP peers , and routers in different subautonomous systems are considered to be confederation eBGP peers. Confederation eBGP peer connections act like true eBGP peers in some respects. In a single sub-AS, the confederation iBGP peers must be fully meshed, because they act exactly like normal iBGP peers. 

Confederations prevent loops inside a confederation AS by using the AS_PATH PA. BGP routers in a confederation add the subautonomous systems into the AS_PATH as part of an AS_PATH segment called the AS_CONFED _SEQ. (The AS_PATH consists of up to four different components, called segments—AS_SEQ, AS_SET, AS_CONFED_ SEQ, and AS_CONFED_SET.

The following list summarizes the key topics regarding confederations:

• Inside a sub-AS, full mesh is required, because full iBGP rules are in effect.
• The confederation eBGP connections act like normal eBGP connections in that iBGProutes are advertised—as long as the AS_PATH implies that such an advertisement would not cause a loop.
• Confederation eBGP connections also act like normal eBGP connections regarding Time to Live (TTL), because all packets use a TTL of 1 by default. (TTL can be changed with the neighbor ebgp-multihop command.)
• Confederation eBGP connections act like iBGP connections in every other regard—for example, the NEXT_HOP is not changed by default.
• Confederation ASNs are not considered part of the length of the AS_PATH when a router chooses the best routes based on the shortest AS_PATH. 
• Confederation routers remove the confederation ASNs from the AS_PATH in Updates sent outside the confederation; therefore, other routers do not know that a confederation was used

Route Reflectors

In an iBGP design using RRs, a partial mesh of iBGP peers is defined. Some routers are configured as RR servers; these servers are allowed to learn iBGP routes from their clients and then advertise them to other iBGP peers. Note that only the RR server itself uses different logic, with clients and nonclients acting as normal iBGP peers.

One of the main motivations for using RRs is to allow sync to be disabled.
RR feature uses several tools to prevent loops, as follows:
CLUSTER_LIST: RRs add their cluster ID into a BGP PA called the CLUSTER_LIST before sending an Update. When receiving a BGP Update, RRs discard received
prefixes for which their cluster ID already appears. As with AS_PATH for confederations, this prevents RRs from looping advertisements between clusters.
ORIGINATOR_ID: This PA lists the RID of the first iBGP peer to advertise the route into the AS. If a router sees its own BGP ID as the ORIGINATOR_ID in a received route, it does not use or propagate the route.
Only advertise the best routes: RRs reflect routes only if the RR considers the route to be a “best” route in its own BGP table. This further limits the routes reflected by the RR. (It also has a positive effect compared with confederations in that an average router sees fewer, typically useless, redundant routes.)

Multiprotocol BGP 

Some of these configurations carry VPN-IPv4 routes, some only IPv4 routes, and others carry VPN-IPv4 and IPv4 routes. The type of BGP session and the specification of which routes the peering sessions will carry are controlled through the use of the address families.

Configure a BGP address family for each Virtual Routing and Forwarding (VRF) configured on the PE router and a separate address family to carry no IPv4 routes between PE routers. The initial BGP process, the portion of the configuration that cites no address family specifications, becomes the default address family. This default context becomes the “catch all” where any non-VRF-based or IPv4-specific sessions can be configured. Any prefixes learned or advertised in this default address family will be injected into the global routing table. The configuration of these BGP sessions is exactly the same as the standard BGP configuration with the exception that the session needs to be activated.

R1(config-router)# address-family vpnv4
R1(config-router)# neighbor 194.22.15.3 activate

The configuration of the VPNv4 address family also adds a further command to the BGP configuration to support the MP-BGP-specific extended community attributes. This command will be added by the IOS by default and is necessary because it instructs BGP to advertise the extended community attributes.

The default behavior is to send only the extended community attribute. If the network design requires the standard community attribute to be attached to these non-IPv4 prefixes, this behavior can be changed through the neighbor 194.22.15.3 send-community both command.

Note that MP-iBGP communicates these routes across the MP-iBGP sessions running between PE routers. To this end, the routing context must be configured under the BGP process to communicate to BGP which VRF prefixes it needs to advertise.

Summary

address-family vpnv4 

- BGP mode; allows the creation of the MP-BGP session necessary to form the VPNv4 session between PE devices

bgp client-to-client reflection

- BGP mode; on by default, tells an RR server to reflect routes learned from a client to other clients

default-information originate 

- BGP mode; required to allow a static default route to be redistributed into BGP

distance bgp external-distance internal distance local-distance 

- BGP mode; defines the administrative distance for eBGP, iBGP, and locally injected BGP routes

neighbor { ip-address | peer-group-name } default-originate [ route-map map-name ]

- BGP mode; tells the router to add a default route to the BGP Update sent to this neighbor, under the conditions set in the optional route map

show ip bgp injected-paths

- Exec mode; lists routes locally injected into BGP

IS-IS Routing Protocol - Part 2

IS-IS Operation over Different Network Types

IS-IS natively supports only broadcast and point-to-point network types. IS-IS has no special provisions to correctly operate over partially meshed data link layer technologies such as hub-and-spoke Frame Relay. Recommended practice dictates that you configure such networks using point-to-point subinterfaces and run IS-IS over these point-to-point links.  It is noteworthy to mention that what IS-IS calls broadcast links should much better be
called multiaccess links.

In IS-IS, there are only three possible adjacency states:
  -Down: The initial state. No IIHs have been received from the neighbor.
  -Initializing: IIHs have been received from the neighbor, but it is not certain that the neighbor is properly receiving this router’s IIHs.
  -Up: IIHs have been received from the neighbor, and it is certain that the neighbor is properly receiving this router’s IIHs.

IS-IS Operation over Point-to-Point Links  

In OSI addressing, each router assigns a locally significant single octet number to each interface, and this number is called the Local Circuit ID.
The three-way-handshake method is based on each router on a point-to-point link advertising an adjacency state TLV in its IIH packets that contains the following fields:
  -Adjacency Three Way State: This is the state of adjacency as seen by the sending router.
  -Extended Local Circuit ID: This is the ID of the sending router’s interface.
  -Neighbor System ID: This value is set to the ID of the neighboring router whose IIHs have been successfully received.
  -Neighbor Extended Local Circuit ID: This value is set to the Extended Local Circuit ID field value from the neighbor’s IIH packets.  

The logic of the three-way handshake (Early Cisco Implementation)
  1. If Router A receives an IIH from Router B with the Adjacency Three Way State set to Down, it is clear that Router A can hear Router B. It is not certain, though, whether Router B can hear Router A. Router A will start sending its IIH with the Adjacency Three Way State set to Initializing to tell Router B it can hear it.
  2. When Router B receives an IIH from Router A with the Adjacency Three Way State set to Initializing, it knows that these IIHs are effectively sent in response to its own IIH, and that Router A is in fact telling Router B it can hear it. Router B is now certain that bidirectional communication is possible. Therefore, it starts sending its IIH with the Adjacency Three Way State set to Up.
  3. When Router A receives an IIH from Router B with the Adjacency Three Way State set to Up, it knows Router B can hear it. Router A is now also certain that bidirectional communication is possible and starts sending its IIH with the Adjacency Three Way State set to Up, concluding the three-way handshake.  

(IETF Implementation) The adjacency state TLV was augmented with the Extended Local Circuit ID, neighbor System ID, and Neighbor Extended Local Circuit ID fields to carry additional information about the neighbor’s identity and interface.
With these fields in place, an IIH that carries a three-way adjacency state TLV is accepted only if one of the following conditions is met:
  -The Neighbor System ID and Neighbor Extended Local Circuit ID are not present (typical at the beginning of the adjacency buildup, or the neighbor implements only the early version of the three-way handshake).
  -The Neighbor System ID matches the receiving router’s System ID and the Neighbor Extended Local Circuit ID matches the receiving interface’s ID.
If these conditions are not met, the incoming IIH is silently dropped. Hence, these rules form an IIH acceptance check.
Therefore, the three-way handshake logic as described in the three previous steps changes simply by replacing all occurrences of “ receives IIH ” with “ receives and accepts IIH .”

After the adjacency is declared as Up, routers will attempt to synchronize their link-state databases. Both routers will mark all their LSPs for flooding over the point-to-point link; plus they send CSNP(Complete Sequence Number Packet) packets to each other. If a router learns from the received CSNP that its neighbor already has an LSP that is scheduled to be sent, the router will  unmark  the LSP, removing it from the set of LSPs to be flooded. This way, only the LSPs missing from the neighbor’s database will be sent to it. In addition, if a router learns from the received CSNP that the neighbor has LSPs that are newer or unknown, it will request them using a PSNP packet. Note that neither of these is necessary, as both routers nonetheless initially set up all their LSPs to be flooded across the link, without the aid of CSNP or PSNP packets. The  initial  sending of CSNPs to compare the link-state databases and PSNPs  to request missing or updated entries increases the resiliency of the synchronization process but is not strictly necessary.  Importantly, though, every LSP sent over a point-to-point link, whether during the initial database synchronization or anytime later when it is updated or purged, must be acknowledged, and this is done using PSNP or CSNP packets.

IS-IS Operation over Broadcast Links  

Detecting neighbors is again performed by IIH packets. In a fashion similar to OSPF, an IS-IS router lists the MAC addresses (or better said, SNPAs) of all neighboring routers it hears on a broadcast interface in its IIH packet sent through that interface. If a router receives an IIH from a neighbor and finds its own SNPA indicated in the IIH, it knows that the routers can see each other, and can move the adjacency to the Up state. If not, the adjacency is kept in the Initializing state. OSPF performs a similar operation, but it lists Router IDs of heard routers in its Hello packets.

IS-IS also elects one Designated IS for each broadcast network but it has no concept of a backup DIS. A DIS is elected based on these criteria:   

  -The router with the highest interface priority.  

  -In case of a tie, the router with the highest SNPA.   

  -In case the SNPAs are not comparable, the router with the highest System ID. This rule is used on Frame Relay and ATM physical interfaces and multipoint subinterfaces, which are treated as broadcast interfaces by IS-IS.

The interface priority is configurable using a perinterface isis priority priority [level] command. DIS elections in IS-IS are preemptive: Whenever a router is connected that has a higher priority than the current DIS, the same priority and higher SNPA, it will take over the DIS role.

In IS-IS, all routers on a common broadcast segment become fully adjacent, regardless of which is the DIS. This is different from OSPF. In IS-IS, 

every router can send  an LSP on the broadcast link and all others are allowed to accept it.A DIS is responsible for two important operations: 1) Helping routers on a broadcast segment to synchronize; 2) Representing the broadcast segment in the link-state database as a standalone object—the Pseudonode. 

Synchronization of IS-IS routers on a broadcast network is surprisingly simple. The DIS creates and sends a CSNP packet in regular intervals (10 seconds by default) on the segment. This CSNP packet lists all LSPs present in the DIS’s link-state database. Other routers on the segment receive this CSNP and compare it to the index of their own link-state database.

The DIS is not a relay of LSPs; rather, it is a reference point of comparison. If a router misses an LSP known by the DIS, or if the LSP is older than the one known by the DIS, the router will request the newer LSP through PSNP and the DIS will flood it. If the PSNP or the LSP gets lost during transmission, the process will simply repeat itself. Conversely, if a router knows about a newer LSP than the one known by the DIS, or if the DIS seems to miss it  completely, the router will simply flood the LSP onto the network. No explicit acknowledgment by the DIS is sent. If the LSP has arrived, the DIS will advertise it in its next periodic CSNP, and this CSNP serves as an implicit acknowledgment.. PSNPs are used on broadcast networks only to request LSPs, not to acknowledge them.  Another responsibility of the DIS is to represent the broadcast network in the link-state database so that the topological model of the network is simpler.

With a pseudonode, the broadcast network itself is represented as a node—more specifically, a pseudo node—in the topology. To exist as a pseudonode in a link-state database, a broadcast network must have its own LSP. It is the responsibility of the DIS to originate and flood the Pseudonode LSP on behalf of the broadcast network. Recall that each LSP is identified by a triplet of System 

ID, Pseudonode ID, and LSP Fragment Number. ID. In case of router LSPs, the System ID carries the ID of the router and the Pseudonode ID is set to 0. In case of network LSPs (that is, Pseudonode LSPs), the System ID is the ID of the DIS, and the Pseudonode ID is set to the Local Circuit ID of the DIS’s interface in the network. 

The show isis hostname  is used to check the mapping of hostnames to System IDs. To verify IS-IS neighbor adjacencies, show isis neighbors is useful. show isis neighbors detail would also show information about each router's SNPA and configured priority. The show isis database lists Pseudonode LSP that is recognizable by its Pseudonode ID being non-zero. To see the contents of LSPs, show isis database detail can be used. 

The router acting as a DIS shortens its own Hello and Hold time to just one-third of the configured values. This is done to allow other routers to detect its failure more rapidly. If a DIS fails, another router will be elected in its place, but because there is no additional adjacency buildup necessary (all routers on the segment are already fully adjacent), a DIS switchover is merely related to replacing the old Pseudonode LSP originated by the previous DIS with a new LSP from the newly elected DIS and remaining routers updating their LSPs to point toward the new Pseudonode LSP.

Areas in IS-IS

Because only a single NSAP address is assigned to a node, and the NSAP address contains the domain and area identifier, the entire node with all its interfaces belongs only to a single area. Because routers are also usually assigned a single NSAP address, they also belong to a single area only. It is in fact possible to configure up to three different NSAP addresses on an IS-IS router in a single IS-IS instance, provided that the System ID in all NSAP addresses is identical and the NSAP addresses differ only in their Area ID.
Multiple NSAP addresses on an IS-IS instance are nonetheless used only during network changes, and in stable operation, there should be only a single NSAP address configured per IS-IS process. IS-IS uses the entire high-order part of the NSAP address up to the start of System ID as the area identifier. Nodes in a single area must obviously be addressed using the same NSAP format, the same initial domain identifier, and the same internal area number(high-order domain specific part). Any difference in these octets would signify that the addressing format is different (and hence incomparable to any other), or the domain(that is, the autonomous system) is different, or the internal area numbering differs.

L1 routing is a process of intra-area routing. If OSI protocols such as CLNP were in use, routers would collect NSAP addresses of their directly attached end hosts and advertise them in their routing updates simply as other adjacencies. With IP protocols, each L1 router advertises its directly connected IP networks in its L1 LSP. A very important fact is that two interconnected neighboring L1 routers configured with different areas will never establish an adjacency.

L2 routing is a process of inter-area routing, that is, delivering packets between stations located in different areas. If OSI protocols were in use, routers would not collect nor advertise end host NSAP addresses. Instead, routers would only advertise their area IDs in their L2 LSPs. L2 routers therefore form a backbone of a multiarea domain, and for this backbone to operate correctly, it must be contiguous and  pervade all areas within the domain. Sometimes, the backbone as the set of L2 routers is also called an L2 subdomain. With IP protocols, IP addresses do not carry embedded area information like NSAP addresses. Each L2 router advertises its  directly connected IP networks  to achieve contiguous IP connectivity in the backbone,  plus all other L1 routes from its own area with appropriate metrics , to advertise IP networks present in particular areas. Thus, while LSPs are never leaked between L1 and L2 link-state databases, on L2 routers, IP  routing information computed from the router’s L1 link-state database is injected into its L2 LSP.  No IP networks are injected from L2 into L1 unless specifically configured.

L1 routers in an area have no L2 link-state database and therefore have no information about other areas that is carried by L2 routers. From this viewpoint, L1 routers in an area have a visibility identical to routers in an OSPF Totally Stubby Area—they see their own area but nothing more. Yet, a L1 router can still perform redistribution from external sources, and these redistributed networks will be visible both in that area and uptaken by L2 routers into the backbone. Therefore, L1 routers in an area behave more as if they were in an OSPF Not So Stubby-Totally Stubby (NSSA-TS) area.

L2 routers disrespect area boundaries when it comes to creating adjacencies and flooding link-state database contents. They create adjacencies with other L2 routers regardless of the area ID, and share all information present in their L2 link-state databases. Therefore, the entire L2 subdomain across all areas in the entire domain can be likened to a single OSPF backbone area.

IS-IS on Cisco routers defaults to L1L2 operation. Note the default administrative distance of 115 for all IS-IS-learned routes.

In show isis database  output, where three flags, ATT, P, and OL, are called ATTached, Partition repair, and Overload flags. The ATT flag is especially relevant to inter-area routing. When an L1L2 router performs its L2 SPF calculation and determines that it can reach other areas besides its own (note that LSPs also carry the area ID of their originating routers), it sets the ATT flag in its L1 LSP. L1-only routers in the area can use any router whose ATT bit is set in its L1 LSP to reach other areas. Because no IP addressing information flows down from L2 into L1, L1-only routers have no knowledge about prefixes in other areas. They automatically install a default route toward their nearest L1L2 router whose ATT bit is set into their routing table. The Partition repair bit indicates whether the router is capable of an optional feature that allows healing a partitioned area over the L2 subdomain—functionality similar to an OSPF virtual link. The Partition repair function was never widely implemented, and Cisco routers do not support it; hence they always set the P bit to 0.

Finally, the Overload bit was originally intended to signal that the router is, for whatever reason, unable to store all LSPs in its memory, and that its link-state database is overloaded. Therefore, if a router’s LSP has the O bit set, the SPF computation on other routers will ignore this router when computing shortest paths to other routers and their networks. However, the SPF will still take the directly attached  networks of this router into account because these continue to be reachable.

The O bit can also be used when a router needs to be taken out of service for maintenance without causing major disruption to the network. Instead of simply shutting the router down, setting the O bit first will make other routers immediately recalculate their routing tables, computing alternate paths (if such paths exist) that do not traverse this router. The network converges on alternate paths much sooner than it would take if the  router was simply taken offline and other routers needed to wait for its Hold timer to expire. Also, the O bit is very useful if a new router is to be attached to a network. Yet another important application of the O bit is to allow the router to settle its adjacencies  after reboot and wait for some time to stabilize while already running IS-IS and populating its routing table, before becoming a transit router. This feature is especially important with BGP that can converge significantly slower than IS-IS.

To see the contents of L2 database, the show isis database l2 detail command is used. Each the L2 LSP of each router contains both its directly connected networks along with all L1 networks in that router's area.
Identical L2 link-state database contents would be displayed on any L2-enabled router in this network. Looking at any L2 LSP in isolation, you do not even know which prefix is directly connected to the router and which one is an L1 prefix “uptaken” into L2—they are both advertised in the same manner.

Regarding redistribution, external networks are  by default injected into L2 but can be configured to be injected into L1 or both L1 and L2 on a router. If an external route is redistributed to L1, all other routers in the same area will see the route as an L1 IS-IS route. When “uptaking” L1 routes into L2 on backbone routers, they do not discriminate between internal L1 networks and external networks in the area that have been redistributed as L1 routes. Multiple areas in a domain are nowadays created primarily for the purpose of address summarization. In IS-IS, area summarization should be configured on each L1L2 router in the area using summary-address command inside the router isis section,

Authentication in IS-IS

IIH packets are authenticated independently of LSP, CSNP, and PSNP packets. In particular with LSPs, for L1 LSPs, all routers within the area must use the same  area password —the  level-1 authentication password , while for L2 LSPs, all  L2-enabled routers within the L2 subdomain must use the same  domain password —the  level-2 authentication password , to authenticate LSPs. If a single area or domain password was used to authenticate all packets, however, all routers in the area or in the backbone would be using the same password, which can be considered a security drawback. Therefore, to authenticate adjacencies themselves, IS-IS allows you to separately authenticate IIH packets.

Authentication in IS-IS can be activated independently for IIH and independently for non-IIH (LSP, CSNP, PSNP) packets. IIH authentication is configured on interfaces and applies only to IIH packets exchanged with directly connected neighbors. Therefore, different interfaces of a router can use different IIH passwords. The same type of authentication and the same password must be configured on all routers in an area if L1 non-IIH authentication is used, or on all L2 routers in the domain if L2 non-IIH authentication is used.

If IIH packets fail authentication, the routers will be completely prevented from communicating in IS-IS even if the non-IIH packets themselves passed the authentication or did not require the authentication. If IIH packets pass the authentication but the non-IIH packets fail it, the routers will be in the Up adjacency state but they will not be able to synchronize their link-state databases.

IPv6 Support in IS-IS  

IS-IS is a true multiprotocol routing protocol in the sense that it does not require any particular Layer 3 protocol to carry its packets, and in a single instance, it can carry information about destinations described by different address families. It is not necessary to start an additional IS-IS process to carry IPv6 routes along with IPv4. Instead, the existing IS-IS process is simply instructed to advertise IPv6 routes along with other information it is already advertising.

Configuring IS-IS    

Interfaces are added to IS-IS directly by configuring them with the ip router isis command. IS-IS has no network command. There is no network command in IS-IS.

If the network from the interface shall be advertised but the interface should remain passive, simply referring to it by the passive-interface  command is signal enough to IS-IS to know that the interface’s network should be advertised even though the interface itself should disallow creating any adjacencies over it. And finally, if the interface is intended to operate as an active interface, it shall be configured with the ip router isis  command.

If a router is configured for L1L2 operation, it will by default try to establish both L1 and L2 adjacencies over all active IS-IS interfaces. If it is known that an interface should be used to establish only L1 or only L2 adjacencies, it is possible to limit its operation only to the selected  level. That will prevent the router from sending and processing packets of a different routing level over that interface.

The per-interface isis authentication and per-process authentication commands support optional level-1 and  level-2 keywords to specify the desired level for which the authentication should be activated. If not specified, both levels are authenticated.

Note that unlike other IGP protocols, IS-IS does not use a separate process configuration section for its IPv6 operation. The  router isis  section is universal for all address families supported by IS-IS.

The show clns command shows a brief but useful information about this router's NET and mode of Integrated IS-IS operation

IS-IS Routing Protocol - Part 1

IS-IS is a link-state routing protocol. IS-IS does not run over any network layer protocol; instead, it encapsulates its messages directly into data-link frames. Adjacency and addressing information in IS-IS messages is encoded as Type-Length-Value (TLV) records, thereby providing excellent flexibility and extendability.

OSI Network Layer and Addressing 

The term  End System (ES) is used for a host, and the term  Intermediate System (IS) is used for a router. An end-to-end communication between two End Systems(hosts) in a Domain (autonomous system) involves zero or more Intermediate Systems (routers) interconnected by Circuits(interfaces).

Two basic services: connection-less-mode and connection-mode network layer communication. The connectionless mode of operation is identical to the way that IP operates, as a pure datagram service without any prior session establishments. In OSI networks, the Layer 3 network protocol that provides a connectionless communication between ES entities is called ConnectionLess-mode Network Protocol(CLNP). The CLNP protocol is to OSI networks what IPv4/IPv6  are to TCP/IP networks. The set of services provided by CLNP is called ConnectionLess Network Services, or simply CLNS. For connection-oriented mode in OSI networks, an adaptation of the X.25 protocol is used. There is no analogous connection-oriented network layer protocol in TCP/IP networks.

The addressing used in OSI networks, both in connectionless and connection-oriented mode, is called NSAP addressing , with the acronym standing for Network Service Access Point representing an address of a particular network service on a particular network node in the network.

NSAP addressing bears many differences to addressing in TCP/IP networks. An NSAP address is assigned to the  entire network node , not to its individual interfaces. A single node requires only one NSAP address in a common setup, regardless of how many network interfaces it uses. As a result, NSAP addressing does not have the notion of per-interface subnets similar to IP subnets.

An NSAP address consists of two parts: The Initial Domain Part(IDP) and the Domain Specific Part(DSP). The internal format and length of these two parts are variable to a large extent and depend on the actual application in which the NSAP addressing is used.  The IDP itself consists of two fields: the Authority and Format Identifier (AFI) and the Initial Domain Identifier (IDI). The AFI value  indicates the format of the remaining address fields.The IDI field has a variable length depending on the address format indicated by AFI and might even be omitted. Together, the AFI and IDI indicate the routing domain (the autonomous system) in which the node is located.  

The DSP consists of a variable-length High-Order Domain Specific Part (HO-DSP) that identifies the part (or an  area) of the domain in which the node is located. The System ID is the unique identifier of the node itself. SEL field, also called an NSAP  Selector or NSEL, is a 1-octet-long field that identifies the particular service in or above the network layer on the destination node that should process the datagram. A rough analogy in the IP world would be the particular protocol above IP, or the transport port. 

In typical IS-IS deployments, the addressing uses the AFI of 49 in which the length and meaning of the HO-DSP field are entirely up to the administrator. If the value of the SEL octet is 0, no particular service is being addressed, and the entire NSAP address simply identifies the destination node itself without referring to any particular service on that node. An NSAP address in which  the SEL octet is set to 0 is called a Network Entity Title (NET), and this is the address that is configured on the node. Configuration of NETs will be a mandatory part of IS-IS configuration. To summarize, NSAP addresses can be thought to contain, in a single instance, information about the destination’s autonomous system, area, unique identifier, and even the requested upper-layer service. 

The written format of NSAP addresses uses hexadecimal digits separated into groups of one or more octets by a dot. 

For example, in 49.0001.1234.5678.3333.00, the AFI is 49, signifying a local address; the 0001 is the area number; the 1234.5678.3333 is the System ID of the node; and the trailing 00 is the SEL value, making this NSAP address also a NET. An NSAP address is often easier to read from right to left. In the NSAP address

49.0001.1234.5678.3333.00, the rightmost octet is the SEL value(00), the following six octets are the System ID (1234.5678.3333), followed by other HO-DSP octets(0001), IDI(not present in this NSAP) and ending with the leftmost octet, the AFI(49).  

As there is no concept of a subnet, routing between the two networks is accomplished by each IS assembling a list of all attached ES nodes and advertising it to its neighbors.  

Individual interfaces are not assigned their own addresses at the network layer. However, their Layer 2 addresses are used in the same way as TCP/IP networks use them. In OSI networks, a Layer 2 address of an interface is called a Sub Network Point of Attachment(SNPA). For purposes of distinguishing between interfaces of the same node, an IS enumerates its interfaces by a locally significant 1-octet number called the Local Circuit ID, which increments by 1 with every interface added to the IS-IS instance beginning with 0 on Cisco routers.   

Levels of Routing in OSI Networks 

Four levels of routing

  -Level 0 routing:  Routing between two ES nodes on the same link, or between an ES node and its nearest IS   

  -Level 1 routing:  Routing between ES nodes in a single area of a domain   

  -Level 2 routing:  Routing between ES nodes in different areas of a domain   

  -Level 3 routing:  Routing between ES nodes in different domains    

Level 0 routing is concerned with the way that an ES (end node) discovers its nearest IS(gateway), and conversely, how an IS knows which ES nodes are connected to it. This is accomplished by both ES and IS sending a periodic Hello message advertising their existence. Hellos sent by ES nodes are called ES Hello(ESH), while Hellos sent by IS nodes are called IS Hello(ISH). Level 0 routing is also referred to as ES-IS routing.

Level 1 routing is concerned with intra-area routing, that is, routing between ES nodes that are members of the same area. IS nodes in an area will have a detailed and complete visibility of the entire area’s topology. On Level 1, IS nodes collect lists of all ES nodes directly attached to them, and advertise these lists to each other to learn the placement of all ES nodes. Level 2 routing is concerned with inter-area routing within the same domain, that is, routing between ES nodes that reside in different areas of the same domain. On Level 2, IS nodes exchange area prefixes to learn how to reach particular areas. Hence, Level 1 routing can be described as routing by System ID, while Level 2 routing can be described as routing by area prefix. Level 2 routing constitutes the backbone of a domain, providing communication between individual areas of the domain. Level 3 routing is concerned with interdomain routing. In a TCP/IP world, this is a fairly direct analogy of inter-autonomous system routing provided by BGP.

IS-IS Metrics, Levels, and Adjacencies  

IS-IS metrics are assigned to individual interfaces (links). Four types of metrics:   

  -Default: Required to be supported by all IS-IS implementations; usually relates to the bandwidth of the link(higher value represents a slower link)   

  -Delay: Relates to the transit delay on the link   

  -Expense: Relates to the monetary cost of carrying data through the link   

  -Error: Relates to the residual bit error rate of the link    

Most IS-IS implementations today support only the default metric. Cisco IS-IS implementation assigns all interfaces the default metric of 10, regardless of their bandwidth. 

The original IS-IS specification and RFC 1195 define any single interface (link) and attached network metric to be 6 bits wide, resulting in the range of 1–63, and the complete path metric as 10 bits wide in the range of 1–1023. Today’s requirements, however, call for a much wider range of metrics. Wide metrics  were introduced, allowing for a 24-bit width for the interface metric and a 32-bit width for the entire path metric. It is ecommended to use wide metrics whenever available and supported; however, all routers in an area must use the same type of metrics.

IS-IS routers operate on each routing level independently. For each routing level, be it Level 1 or Level 2, an IS-IS router establishes separate adjacencies with its neighbors running on the same level, and maintains a separate link-state database. Two neighboring routers configured for both Level  1 and Level 2 routing will create two independent adjacencies, one for each level.

For each enabled level, a router originates and floods a Link State PDU(LSP). An LSP is similar to an OSPF Link State Update packet with one or more Link State Advertisements. IS-IS routers use Level 1 and Level 2 LSPs to describe their adjacencies on that particular level. Contents of a Level 1 link-state database are exchanged only over Level 1 adjacencies, and Level 2 link-state database contents are exchanged over Level 2 adjacencies only. 

IS-IS Packet Types  

Four types - Hello packet, Link State PDU, Complete Sequence Numbers PDU, Partial Sequence Numbers PDU.

Hello packets, also denoted as IIH (IS-IS Hello), are used to perform the usual task of detecting neighboring routers (and also their loss), verifying bidirectional visibility, establishing and maintaining adjacencies, and electing a Designated IS(DIS—similar to a Designated Router in OSPF). 10 seconds by default. The Hold time is 3 times hello time(30 sec by default). As opposed to OSPF, timers do not need to match on neighboring routers. On a DIS, the individual timers are  always  one-third of the configured timers (with default settings)—a DIS sends Hellos every 10/3=3.333 seconds, and the Hold interval is 30/3=10 seconds. This is done to detect a DIS or its outage more readily. There are three types of Hello: Level 1 Hello, Level 2 Hello (both used on broadcast networks), and L1L2 Hello (used on point-to-point interfaces).

Link State PDUs  

A Link State Protocol Data Unit (LSP) is used to advertise the routing information. An LSP is vaguely similar to an OSPF Link State Update packet containing one or more Link State Advertisements. There are, however, notable differences between OSPF LSU/LSA and IS-IS LSP. In OSPF, the smallest standalone element of the link-state database is an LSA (note that LSA is not a packet itself). In IS-IS, the smallest standalone element of the link-state database is an entire LSP. There are no different types of LSPs to describe different network objects; instead, these are described by distinct Type-Length-Value(TLV) records inside an LSP’s variably sized payload.

Similar to OSPF LSAs that are uniquely identified by their type and Link-State ID, IS-IS LSPs are also uniquely identified by a number that consists of three parts:  

  -System ID  of the router that originated this LSP (6 octets; taken from the router’s NET address)   

  -Pseudonode ID  that differentiates between the LSP describing the router itself and the LSPs for multiaccess networks in which the router is a Designated IS (1 octet) 

  -LSP Number  denoting the fragment number of this LSP (1 octet). The LSP Number is also called simply the Fragment Number or Fragment for short.  

We will denote this triplet of System ID + Pseudonode ID + LSP Number as LSPID. For LSPs that describe routers themselves, the Pseudonode ID is always set to 0. Separate LSPs are originated for Level 1 and for Level 2, depending on what levels the router operates at. To distinguish between various versions of the same LSP, each LSP has a sequence number—a 32-bit unsigned integer starting at 0x00000001 and ending at 0xFFFFFFFF. Each modification to an LSP is accompanied by incrementing its sequence number.

Each LSP has a Remaining Lifetime value associated with it. When originated, the Remaining Lifetime is set to 1200 seconds (20 minutes), and is decreased. IS-IS routers refresh their self-originated LSPs every 15 minutes. If the LSP’s Remaining Lifetime decreases to 0, the router will delete the LSP’s body from the link-state database, keep only its header, and advertise the empty LSP with the Remaining Lifetime set to 0. Flooding an empty LSP with the Remaining Lifetime set to 0 is called an  LSP purge . The expired LSP can be purged from the link-state database after an additional time called ZeroAgeLifetime set to 60 seconds. This is done to ensure that the LSP’s header is retained until the purged LSP has been safely propagated to all neighbors. 

Because IS-IS messages are encapsulated directly into Layer 2 frames whose maximum payload size—the Maximum Transmission Unit (MTU)—is limited, IS-IS must implement its own fragmentation functions for LSPs whose size exceeds the MTU. Each LSP consists of a fixed-size header and a variable-size body that contains one or more TLV records that carry the actual addressing and topological information. If putting all TLV records into a single LSP would cause it to exceed the MTU, the router will simply create multiple LSPs.  These LSPs are identified with the same System and Pseudonode ID, and with an increasing LSP Number as the fragment number, starting from 0. An important fact is that this fragmentation is performed only by the router that originates the LSP. After the LSP is flooded, it must not be modified by any other router, and also not be defragmented and/or refragmented. A consequence of this rule is that across the entire flooding scope of the LSP (an area for a Level 1 LSP, or all Level 2 routers and their interconnections for a Level 2 LSP), the MTU on interfaces must be identical. If this requirement cannot be met, IS-IS routers must be manually configured to keep each LSP not bigger than the smallest MTU.  

The show isis hostname on R1 displays the numerical System ID and the related hostname of the router with that ID. The show isis database shows the contents of the link-state database. 

In IS-IS, a router on a particular routing level generates only a single (although possibly fragmented) LSP containing all relevant information related to that router in one place:  

  -Adjacencies to neighboring routers or networks (similar to type 1 LSAs)   

  -Intra-area and inter-area prefixes(similar to prefix information collected from type 1, 2, and 3 LSAs)   

  -External prefixes(similar to type 5/7 LSAs)    

Type 2 LSA in OSPF carries two vital pieces of information: the address and netmask of a multiaccess network (address information) and a list of connected routers to this network(topological information). In IS-IS, the address information about all networks, both point-to-point and multiaccess, is contained in the LSP of each router connected to that network. The topological information about the network itself and the list of connected routers are contained in a so-called Pseudonode LSP generated by the DIS on the multiaccess network. 

An LSP has a unique identifier as a whole, and can only be flooded, requested, acknowledged, refreshed, aged, and flushed as a whole. Therefore, with any topological or addressing change, affected routers regenerate their entire LSPs and flood them. each IS-IS router originates only a single LSP (plus Pseudonode  LSPs if it is a DIS), and has therefore only a single or a few self-originated LSPs to age and refresh. 

Another difference between LSUs/LSAs and LSPs concerns their internal format with particular regard to extensibility. IS-IS encodes all topological and addressing information in Type-Length-Value records. While slightly less efficient in terms of memory and processing, this approach allows extensibility from day zero: A router will process those TLV  records it recognizes and ignore the records it does not support.

Note: LSP packets are used to carry topological and addressing information in IS-IS. An LSP describes its originator, its adjacencies to neighboring network objects, and related addressing. Each LSP is uniquely identified by the SystemID.PseudonodeID-LSPNumber. Each LSP has a sequence number, starting at 0x00000001 and ending at 0xFFFFFFFF. The lifespan of an LSP is limited by its Remaining Lifetime timer set to 1200 seconds and decreasing. After this timer expires, a router is required to wait at least another ZeroAgeLifetime (60 seconds) before flushing the LSP. LSPs are refreshed by default every 900 seconds. Separate LSPs are originated for Level 1 and Level 2.

Complete and Partial Sequence Numbers PDUs 

Complete Sequence Numbers PDU (CSNP) and Partial Sequence Numbers PDU(PSNP) packets are used to synchronize link-state databases. CSNP packets are very similar in their function to OSPF Database Description Packets. The purpose of CSNP packets is to advertise a complete list of LSPs in the sender’s link-state database. Receivers of CSNP packets can compare their link-state database contents to the list of LSPs in the CSNP and perform appropriate action. Note that CSNPs list only LSPIDs, but they do not contain LSP bodies.

On point-to-point links, CSNP packets are exchanged usually only during initial adjacency buildup; on broadcast networks, CSNP packets are originated periodically by the DIS. PSNP packets are functionally similar to OSPF Link State Request and Link State Acknowledgment packets. Using PSNP, a router can either request a particular LSP or acknowledge its arrival. A single PSNP can request or acknowledge multiple LSPs.