IP Multicast

A multicast is a single data stream sent from one source to a group of recipients. Examples might be a stock ticker or live video feed. Figure 7-3 shows an example multicast topology, as contrasted to unicast and broadcast.

Multicast Topolgy
Unicast Topolgy
In contrast, a unicast is traffic from one source to one destination (see Figure 7-2).


Broadcasting
A broadcast is traffic from one source to all destinations (see Figure 7-3). Broadcasts are not routed!Some features of multicast traffic are:

• Multicast uses UDP, so reliability must be handled by the end host.
• The sending host does not know the identity of the receiving hosts; it knows just a group IP addresses.
• Group membership is dynamic. Hosts join a group, notify their upstream router, and the router begins forwarding data to them.
• Hosts can belong to more than one group.
• Hosts in a group can be located in many different places.

Configuring BGP

Table 6-1 lists the basic BGP configuration commands and their functions.


The BGP Network Command
In most IGPs, the network command starts the routing process on an interface. In BGP, the command tells the router to originate an advertisement for that network. The network does not have to be connected to the router; it just has to be in the routing table. In theory, it could even be a network in a different autonomous system (not usually recommended).

When advertising a network, BGP assumes you are using the default classful subnet mask. If you want to advertise a subnet, you must use the optional keyword mask and specify the subnet mask to use. Note that this is a subnet mask, not the inverse mask used by OSPF and EIGRP network statements. The routing table must contain an exact match (prefix and subnet mask) to the network listed in the network statement before BGP will advertise the route.


BGP Peering
BGP assumes that external neighbors are directly connected and that they are peering with the IP address of the directly connected interface of their neighbor. If not, you must tell BGP to look more than one hop away for its neighbor, with the neighbor ip-address ebgp-multihop number-of-hops command. You might use this command if you are peering with loopback interface IP addresses, for instance. BGP assumes that internal neighbors might not be directly connected, so this command is not needed with IBGP.

BGP Peering States
The command show ip bgp neighbors shows a list of peers, and the status of their peering session. This status can include the following states:

• Idle—No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been administratively shut down.
• Connect—TCP handshake completed.
• OpenSent, or Active—An open message was sent to try to establish the peering.
• OpenConfirm—Router has received a reply to the open message.
• Established—Routers have a BGP peering session. This is the desired state.

You can troubleshoot session establishment with debug commands. Use debug ip bgp events or debug ip bgp ipv4 unicast (in IOS versions 12.4 and up) to see where the process fails. Some common failure causes include AS number misconfiguration, neighbor IP address misconfiguration, neighbor with no neighbor statement for your router, and neighbor with no route to the source address of your router’s BGP messages.


BGP Path Selection
IGP, such as EIGRP or OSPF, choose routes based on lowest metric. They attempt to find the shortest, fastest way to get traffic to its destination. BGP, however, has a very different way of route selection. It assigns various attributes to each path; these attributes can be administratively manipulated in order to control the path that is selected. It then examines the value of these attributes in an ordered fashion until it is able to narrow all the possible routes down to one path.


BGP Attributes
BGP chooses a route to network based on the attributes of its path. Four categories of attributes exist:

• Well-known mandatory—Must be recognized by all BGP routers, present in all BGP updates, and passed on to other BGP routers. For example, AS path, origin, and next hop.
  

• Well-known discretionary—Must be recognized by all BGP routers and passed on to other BGP routers, but need not be present in an update. For example, local preference.
  

• Optional transitive—Might or might not be recognized by a BGP router, but is passed on to other BGP routers. If not recognized, it is marked as partial. For example, aggregator, community.
  

• Optional nontransitive—Might or might not be recognized by a BGP router and is not passed on to other routers. For example, Multi-Exit Discriminator (MED), originator ID.

Table 6-2 lists common BGP attributes, their meanings, and their category.


Influencing BGP Path Selection
BGP was not created to be a fast protocol; it was created to allow as much administrative control over route path selection as possible. Path selection is controlled by manipulating BGP attributes, usually using route maps. You can set a default local preference by using the command bgp default local-preference and a default MED for redistributed routes with the default-metric command under the BGP routing process. But by using route maps, you can change attributes for certain neighbors only or for certain routes only. This is higher than the default local preference of 120, so routers within the AS are more likely to prefer that path than others.

Route maps can also be applied to routes sent to or received from a neighbor. The following example shows a simple route map that sets MED on all routes advertised out to an EBGP neighbor:

route-map MED permit 10
set metric 50
!
router bgp 65001
neighbor 10.1.1.1 route-map MED out

When attributes are changed, you must tell BGP to apply the changes. Either clear the BGP session (clear ip bgp * ) or do a soft reset (clear ip bgp * soft in | out). Routers using recent IOS versions will do a route refresh when the session in cleared inbound.


BGP Path Selection Criteria
BGP tries to narrow its path selection down to one best path; it does not load balance by default. To do so, it examines the path attributes of any loop-free, synchronized (if synchronization is enabled) routes with a reachable next-hop in the following order:

1. Choose the route with the highest weight.
2. If weight is not set, choose the route with the highest local preference.
3. Choose routes that you advertise.
4. Choose the path with the shortest autonomous system path.
5. Choose the path with the lowest origin code (i is lowest, e is next, ? is last).
6. Choose the route with the lowest MED, if the same autonomous system advertises the possible routes.
7. Choose an eBGP route over an iBGP route.
8. Choose the route through the nearest IGP neighbor.
9. Choose the oldest route.
10. Choose a path through the neighbor with the lowest router ID.
11. Choose a path through the neighbor with the lowest IP address.

To enable BGP to load balance over more than one path, you must enter the command maximum-paths number-of-paths. BGP can load balance over a maximum of six paths.

BGP

• BGP stands for Border Gateway Protocol.
• BGP uses the concept of autonomous systems. An autonomous system is a group of networks under a common administration.
• Autonomous systems run Interior Gateway Protocols (IGP) within the system. They run an Exterior Gateway Protocol (EGP) between them.
• BGP version 4 is the only EGP currently in use.
• BGP neighbors are called peers and must be statically configured.
• BGP uses TCP port 179.
• BGP is a path-vector protocol. Its route to a network consists of a list of autonomous systems on the path to that network.
• BGP’s loop prevention mechanism is autonomous system number.

When an update about a network leaves an autonomous system, that autonomous system’s number is prepended to the list of autonomous systems that have handled that update. When an autonomous system receives an update, it examines the autonomous system list. If it finds its own autonomous system number in that list, the update is discarded.

In Figure 6-1, BGP routers in AS 65100 see network 10.1.1.0 as having an autonomous system path of 65200 65300 65400.

Multihoming
Multihoming means connecting to more than one ISP at the same time. It is done for redundancy and backup in case one ISP fails and for better performance if one ISP provides a better path to often used networks. Three ways exist to receive routes from each ISP:

• Default routes from each provider—This results in low use of bandwidth and router resources. The internal network’s IGP metric determines the exit router for all traffic bound outside the autonomous system.
• Default routes plus some more specific routes—This results in medium use of bandwidth and router resources. This allows you to manipulate the exit path for specific routes using BGP, but the IGP metric chooses the exit path for default routes.
• All routes from all providers—This requires the highest use of bandwidth and router resources. It is typically done by large enterprises and ISPs. Path selection for all external routes can be controlled via BGP policy routing tools.

BGP Databases
BGP uses three databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:

• Neighbor database—This is a list of all configured BGP neighbors. To view it, use the show ip bgp summary command.
• BGP database, or RIB (Routing Information Base)—This is a list of networks known by BGP, along with their paths and attributes. To view it, use the show ip bgp command.
• Routing table—This is a list of the paths to each network used by the router, and the next hop for each network. To view it, use the show ip route command.

BGP Message Types
BGP has four types of messages:

• Open—After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor. Includes information such as autonomous system number, router ID, and hold time.
• Update—Message used to transfer routing information between peers.
• Keepalive—BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session active.
• Notification—When a problem occurs that causes a router to end the BGP peering session, a notification message is sent to the BGP neighbor and the connection is closed.

Internal and External BGP
Internal BGP (IBGP) is BGP peering relationship between routers in the same autonomous system. External BGP (EBGP) is BGP peering relationship between routers in different autonomous systems. BGP treats updates from internal peers differently than updates from external peers.

In Figure 6-2, routers A and B are EBGP peers. Routers B, C, and D are IBGP peers.
BGP Next Hop Selection
The next hop for a route received from an EBGP neighbor is the IP address of the neighbor that sent the update.

When a BGP router receives an update from an EBGP neighbor, it must pass that update to its IBGP neighbors without changing the nexthop attribute. The next-hop IP address is the IP address of an edge router belonging to the next-hop autonomous system. Therefore, IBGP routers must have a route to the network connecting their autonomous
system to that edge router. For example, in Figure 6-3, RtrA sends an update to RtrB, listing a next hop of 10.2.2.1, its serial interface. When RtrB forwards that update to RtrC, the next-hop IP address will still be 10.2.2.1. RtrC needs to have a route to the 10.2.2.0 network in order to have a valid next hop.

To change this behavior, use the neighbor [ip address] next-hop-self command in BGP configuration mode. In Figure 6-3, this configuration goes on RtrB. After you give this command, RtrB will advertise its IP address to RtrC as the next hop for networks from AS 65100, rather than the address of RtrA. Thus, RtrC does not have to know about the
external network between RtrA and RtrB (network 10.2.2.0).


BGP Next Hop on a Multiaccess Network
On a multi-access network, BGP can adjust the next-hop attribute to avoid an extra hop. In Figure 6-3, RtrC and RtrD are EBGP peers, and RtrC is an IBGP peer with RtrB. When C sends an update to D about network 10.2.2.0, it normally gives its interface IP address as the next hop for D to use. But because B, C, and D are all on the same multiaccess network, it is inefficient for D to send traffic to C, and C to then send it on to B. This process unnecessarily adds an extra hop to the path. So, by default, RtrC advertises a next hop of 10.3.3.3 (RtrB’s interface) for the 10.2.2.0 network. This behavior can also be adjusted with the neighbor [ip address] next-hop-self command.


BGP Synchronization Rule
The BGP synchronization rule requires that when a BGP router receives information about a network from an IBGP neighbor, it does not use that information until a matching route is learned via an IGP or static route. It also does not advertise that route to an EBGP neighbor unless a matching route is in the routing table. In Figure 6-3, if RtrB advertises a route to RtrC, then RtrC does not submit it to the routing table or advertise it to RtrD unless it also learns the route from some other IGP source.

Recent IOS versions have synchronization disabled by default. It is usually safe to turn off synchronization when all routers in the autonomous system run BGP. To turn it off in earlier IOS versions, use the command no synchronization under BGP router configuration mode.

DHCP

DHCP automates the assignment of IP addresses to network hosts. DHCP addresses can be allocated:

• Manually—A specific IP address is assigned to a MAC address.
• Automatic—An IP address is permanently assigned to a host.
• Dynamic—The IP address is assigned for a limited amount of time or until the client releases it.

The process of acquiring an IP address from a DHCP server has four
steps:

Step 1. The host broadcasts a DHCPDISCOVER message.
Step 2. The server responds with a DHCPOFFER message containing IP address and optionally other settings.
Step 3. The client broadcasts a DHCPREQUEST message, requesting the offered IP address.
Step 4. The server sends a DHCPACK confirming the address assignment.


Configuring DHCP
Cisco routers can be DHCP clients, servers, or relay agents. To configure an IOS device as a DHCP client, use the ip address dhcp command on the interface that needs to obtain the DHCP address. To configure a router as a DHCP server, you must create an IP address pool and assign a network or subnet to that pool. You can optionally add information, such as default gateway, DNS server, lease duration, or options such as Option 150 for Cisco IP phones. Exclude any static IP addresses within the pool, such as the router’s address. You may also want to identify an external server to hold the DHCP database of IP address bindings.

Cisco routers have an auto-configuration feature that allows the downloading of some DHCP information from a central server. This saves the trouble of configuring every router with complete DHCP information. To do this, one interface on the router must have a DHCP address.

The following example shows a router configured as a DHCP server that imports its domain name, DNS servers, and other information from another DHCP server off interface Gi0/0. The IP address range of 10.6.3.1–10.6.3.5 is excluded from the pool.

Router(config)#ip dhcp excluded-address 10.6.3.1 10.6.3.5
!
Router(config)#ip dhcp pool Gator
Router(dhcp-config)#network 10.6.3.0 /24
Router(dhcp-config)#default-router 10.6.3.1
Router(dhcp-config)#import all
!
Router(config)#int gi 0/0
Router(config-if)#ip address dhcp


DHCP Relay Agent
Hosts discover their DHCP server by sending broadcasts. If that server is on a different subnet, those broadcasts must be routed to the server as unicasts. You can configure a router to relay DHCP messages with the ip helper-address interface command. It is important to understand that this command must be given on the interface that receives the host broadcasts. A Cisco DHCP relay agent functions as follows:

Step 1. A client broadcasts a DHCP request, which is seen by the IOS device (a router, for instance).
Step 2. The router changes the destination address of the packet to the unicast address of the server. It optionally adds option 82 (relay agent option) information.
Step 3. The router sends the unicast packet to the server.
Step 4. The server responds with the IP address and other parameters, such as the default gateway assigned to the client.
Step 5. The router gets the packet from the server, removes any option 82 information, and forwards it to the client.

The ip helper-address command enables the relaying of UDP broadcasts only. By default, eight broadcast types are enabled:

• Time, port 37
• TACACS, port 49
  
• DNS, port 53
  
• BOOTP/DHCP server, port 67
  
• BOOTP/DHCP client, port 68
  
• TFTP, port 69
  
• NetBIOS name service, port 137
• NetBIOS datagram service, port 138

To disable the forwarding any of these protocols, use the interface command no ip forward-protocol udp port-number. To add UDP protocols to be relayed, use the interface command ip forward-protocol udp port-number.

Verify your DHCP configuration with the commands show ip dhcp database, show ip dhcp server statistics, and show ip dhcp binding. Delete address assignments with the clear ip dhcp binding {address | *} command.

Tools for Controlling/Preventing Routing Updates

Cisco IOS provides several ways to control routing updates. They include:

• Passive interface
• Default and/or static routes
• Distribute list
• Route map
• Change administrative distance

Passive Interface
The passive-interface command prevents routing updates from being sent out an interface that runs the routing protocol. RIP and IGRP do not send updates out an interface. It prevents other routing protocols from sending hellos out of an interface; thus, they don’t discover neighbors or form an adjacency out that interface. To disable the protocol on one interface, use the command passive-interface interface. To turn off the protocol on all interfaces, use passive-interface default. You can then use no passive-interface interface for the ones that should run the protocol, as shown:

Router(config)#router eigrp 7
Router(config-router)#passive-interface default
Router(config-router)#no passive-interface s0/0/0


Distribute Lists
A distribute list allows you to filter routing updates and also routes being redistributed through an access list. Configure an access list that permits the routes to be advertised or redistributed, and then link that access list to the routing process with the distribute-list command, given under router configuration mode. This command has two options:

• distribute-list access-list in—Filters updates as they come in an interface. For OSPF, this controls routes placed in the routing table but not the database. For other protocols, this controls the routes the protocol knows about.
• distribute-list access-list out—Filters updates going out of an interface and also updates being redistributed out of another routing protocol into this one.

Route Maps
Route maps are a bit like programs that use a “if/then/else” decisionmaking capability. They match traffic against certain conditions, and then set specified options for that traffic. Each statement has a sequence number, statements are read from the lowest number to highest, and the router stops reading when it gets a match. The sequence number can be used to insert or delete statements. Like an access list, there is an implicit “deny” at the end of each route map; any traffic not matched with a route map statement is denied. Some uses for route maps include:

• Filtering redistributed routes—Use the route-map keyword in the redistribute command.
• Policy-based routing—To specify which traffic should be policy routed, based on very granular controls.
• BGP policy—To control routing updates and to manipulate path attributes.

Route Map Syntax
Route maps are created with the global command:

Router(config)#route-map {tag} permit | deny [sequence_number]

Each statement in a route map begins this same way, with the same route map name but different sequence numbers, and with match and/or set conditions below it. Permit means that any traffic matching the match conditions is used. Deny means that any traffic matching the match conditions is not used.


Match and Set Conditions
Each route map statement can have from none to multiple match and set conditions. If no match condition exists, the statement matches anything, similar to a “permit any” in an access list. If there is no set condition, the matching traffic is either permitted or denied, with no other conditions being set.

Multiple match conditions on the same line use a logical OR. For example, the router interprets match a b c as “match a or b or c.” Multiple match conditions on different lines use a logical AND. For example, the router interprets the following route map
statement as “match a and b and c:”

route-map Logical-AND permit 10
match a
match b
match c

In route redistribution, some common conditions to match include:

• ip address—Refers the router to an access list that permits or denies networks.
• ip next-hop—Refers the router to an access list that permits or denies next-hop IP addresses.
• ip route-source—Refers the router to an access list that permits or denies advertising router IP addresses.
• metric—Permits or denies routes with the specified metric from being redistributed.
• route-type—Permits or denies redistribution of the route type listed, such as internal or external.
• tag—Routes can be labeled (tagged) with a number, and route maps can look for that number.

In route redistribution, some common conditions to set are:

• metric—Sets the metric for redistributed routes.
• metric-type—Sets the type, such as E1 for OSPF.
• tag—Tags a route with a number that can be matched on later by other route maps.
• level—For IS-IS, sets the IS level for this route.

The following configuration example shows a route map named BGPLP with three statements that are used to control which routes will be redistributed from OSPF into BGP. The router has already been configured with two access lists, numbered 23 and 103 (not shown.) The first route map statement, with sequence number 10, is a permit statement. The match condition tells it to use access list 23. Any traffic permitted by access list 23 matches this statement and will be redistributed into BGP. Any traffic explicitly denied by access list 23 will not be redistributed into BGP. The set condition tells it to set a BGP local preference for all traffic that matches statement 10. Traffic not matching access list 23 will be checked against the second route map statement.

The second route map statement, sequence number 20, is a deny statement that matches access list 103. Any traffic permitted by access list 103 will be denied by this statement, and thus will not be redistributed. Any traffic explicitly denied by access list 103 will be ignored by this statement, and checked against the next route map statement. This route map statement has no set conditions. Traffic not matching route map statements 10 or 20 will be checked against statement 30.

The third route map statement, sequence number 30, is a permit statement with no match or set conditions. This statement matches everything and sets nothing, thus permitting all other traffic without changing it. Without this statement, all other traffic would be denied.

Lastly, the route map is applied to the redistribution command, to filter routes redistributed from OSPF into BGP.

Router(config)#route-map BGP-LP permit 10
Router(config-route-map)#match ip address 23
Router(config-route-map)#set local-preference 200
Router(config-route-map)#!
Router(config-route-map)#route-map BGP-LP deny 20
Router(config-route-map)#match ip address 103
Router(config-route-map)#!
Router(config-route-map)#route-map BGP-LP permit 30
!
Router(config)#router bgp 65001
Router(config-router)#redistribute ospf 1 route-map BGP-LP


Manipulating Administrative Distance
When a router receives routes to the same destination network from more than one routing process, it decides which to put in the routing table by looking at the administrative distance (AD) value assigned to the routing process. The route with the lowest AD is chosen. Table 5-2 shows administrative distance values.


AD can be changed for all routes of a process or only for specific routes within a process. The command for all IGPs except EIGRP is:

Router(config-router)#distance administrative_distance {address wildcard-mask} [access-list-number | name]

Using the address/mask keywords in the command changes the AD of routes learned from the neighbor with that IP address. An entry of 0.0.0.0 255.255.255.255 changes the AD of all routes. Specifying an access list number or name changes the AD only on networks permitted in the ACL.

EIGRP and BGP have different AD values for internal and external routes, so you have to list those separately when using the command with those protocols. BGP also allows you to change the AD for locally generated routes. For these protocols, the commands are:

Router(config-router)#distance eigrp internal-distance externaldistance
Router(config-router)#distance bgp external-distance internaldistance local-distance

Route redistribution can cause suboptimal routing; one way to correct this is to adjust AD. Figure 5-1 shows a network with two routing domains: RIP and OSPF.

R2 redistributes its RIP routes into OSPF. These routes inherit OSPF’s AD when they are advertised to R4. R4 then advertises them to R3 as OSPF routes.

R3 now knows about the 10.1.1.0 network from two routing processes: RIP, with an AD of 120, and OSPF, with an AD of 110. The shortest path is the RIP route through R1. The OSPF path goes through R4 and R2, and then to R1—a much longer path. But, based on AD, R3 puts the OSPF path in its routing table.

To prevent this, increase the AD of the redistributed RIP routes when OSPF advertises them. Note that this doesn’t change all OSPF routes, just the ones learned from RIP. The commands given on R2 (the router doing the initial redistribution) are shown in the
following:

Router(config)#access-list 10 permit 10.1.1.0
!
Router(config)#router ospf 1
Router(config-router)#redistribute rip subnets
Router(config-router)#distance 125 0.0.0.0 255.255.255.255 10


The AD is increased to 125 for routes from all neighbors, if they match the network permitted in access list 10. Now R3 hears about the 10.1.1.0 network from RIP with an AD of 120, and from OSPF with an AD of 125. The RIP route is put into the routing table based on its lower AD.

Optimizing Routing

There are times when you need to go beyond just turning on a routing protocol in your network. You may need to use multiple protocols, control exactly which routes are advertised or redistributed, or which paths are chosen. Most networks use DHCP; your router may need to be a DHCP server, or relay DHCP broadcasts.

Using Multiple Routing Protocols
There are several reasons you may need to run multiple routing protocols in your network. Some include:

• Migrating from one routing protocol to another, where both protocols will run in the network temporarily
• Applications that run under certain routing protocols but not others
• Areas of the network under different administrative control (“layer 8” issues)
• A multi-vendor environment in which some parts of the network require a standards-based protocol

Configuring Route Redistribution
If routing information must be exchanged among the different protocols or routing domains, redistribution can be used. Only routes that are in the routing table and learned via the specified protocol are redistributed. Each protocol has some unique characteristics when redistributing, as shown in Table 5-1.


You can redistribute only between protocols that use the same protocol stack, such as IP protocols, which cannot advertise IPX routes. To configure redistribution, issue this command under the routing process that is to receive the new routes:

Router(config-router)#redistribute {route-source} [metric metric] [route-map tag]


Seed Metric
Redistribution involves configuring a routing protocol to advertise routes learned by another routing process. Normally, protocols base their metric on an interface value, such as bandwidth, but no interface for a redistributed route exists. Protocols use incompatible metrics, so the redistributed routes must be assigned a new metric compatible with the new protocol.

A route’s starting metric is called its seed metric. Set the seed metric for all redistributed routes with the default-metric [metric] command under the routing process. To set the metric for specific routes, either use the metric keyword when redistributing or use the route-map keyword to link a route map to the redistribution. After the seed metric is specified, it increments normally as the route is advertised through the network (except for certain OSPF routes).

IS-IS

Intermediate System-to-Intermediate System (IS-IS) is a link state routing protocol that is part of the OSI family of protocols. Like OSPF, it uses Dijkstra’s SPF algorithm to choose routes. IS-IS is a classless interior gateway protocol that uses router resources efficiently and scales to large networks, such as large Internet service providers (ISP). The following table lists some IS-IS terms, acronyms, and their meanings.


IS-IS Overview
Integrated IS-IS can carry IP network information, but does not use IP as its transport protocol. It uses OSI protocols CLNS and CLNP to deliver its updates. IS-IS sends its messages in PDUs. There are four IS-IS PDU types: Hello, LSP, PSNP, and CSNP.

Types of IS-IS Routers
Figure 4-1 shows an IS-IS network divided into areas. The IS-IS backbone is not a specific area, as in OSPF, but an unbroken chain of routers doing Level 2 routing. R3, R6, and R4 are the backbone in the following figure.

Within an area, routers can be one of three types:

Level 1 (L1) router
R1, R2, and R5 in the figure. Routes to networks only within the local area (intra-area routing). Uses a default route to the nearest Level 2 router for traffic bound outside
the area. Keeps one LSDB for the local area. When routing, compares the area of the destination to its area. If they are the same, routes based on system ID. If not, sends traffic to Level 1-2 router.

Level 2 (L2) router
R6 in the figure. Routes to networks in other areas (interarea routing). The routing is based on area ID. Keeps one LSDB for routing to other areas.

Level 1-2 (L1-2) router
R3 and R4 in this figure. Acts as a gateway into and out of an area. Does Level 1 routing within the area and Level 2 routing between areas. Keeps two LSDB: one for the local area and one for interarea routing.


NSAP Address Structure
In the Cisco implementation of integrated IS-IS, NSAP addresses have three parts: the area ID, the system ID, and the NSEL. They are written in hexadecimal and have a maximum size of 20 bytes.

Area IDs vary from 1 to 13 bytes. Those that begin with 49 designate private area addressing.
The Cisco system ID must be exactly six bytes. MAC addresses or IP addresses padded with 0s are often used as system IDs.
The NSEL is exactly one byte in size. A router always has a NSEL of 00.

Adjacency Formation in IS-IS
IS-IS routers form adjacencies based on the level of IS routing they are doing and their area number. This is a CLNS adjacency and can be formed even if IP addresses don’t match.

Level 1 routers form adjacencies only with L1 and L1-2 devices in their own area. (In Figure 4-1, R1 becomes adjacent with R2 and R3.)

Level 2 routers form adjacencies only with Level 2-capable devices (either L2 or L1-2 routers). These can be in the local area or in other areas. (In Figure 4-1, R6 becomes adjacent with R3 and R4.)

Level 1-2 routers form Level 1 adjacencies with L1 routers in their own area, and Level 2 adjacencies with routers in other areas. (In Figure 4-1, R4 has a L1 adjacency with R5 and a L2 adjacency with R6.)