Monday, November 22, 2010

Misc 50

Today I'm in the mood for some protocol analysis. We'll take a look at the TCP protocol. I'm not going to tell you again that TCP stands for Transmission Control Protocol and it is connection-oriented and reliable, but I just did.
You're probably familiar by now with how a TCP connection initiates. The first three packet of a connection is used to synchronize the sequence numbers. This is also known as the Three-Way Handshake. The Three-Way Handshake goes like this:
Client                              Server
|                 ISNc=500, SYN --> |
| <-- ack="" acks="501," br="" isns="2000," syn="">|                ACKc=2001, ACK --> |

This is all we know, don't we? What happens after that? Now, here's where I fill you in. From this point onwards, all packets will have the ACK bit set. The initiator usually begins sending data now. For example, if we're connecting to a web server, than the initiator would be sending a GET request as the first packet.

This is how TCP works: Whenever TCP receives a packet, it does not immediately send it to the application. TCP actually buffers and reassembles the data while waiting for a packet with the PSH bit. The PSH bit, which stands for Push, actually tells the protocol to send the assembled data to the upper layers (which in this case, only means the application).

A GET request is pretty small, so a single TCP segment would suffice. Therefore, you would notice that the first GET request is actually flagged as ACK and PSH at the same time.
SEQ: 1
ACK: 1
Total Size (including headers): 958 Bytes

After a PSH, the receiving end would send a blank ACK to signal that it has successfully received and reassembled the entire sequence.
SEQ: 1
ACK: 959
Data: None
Total Size (including headers): 0 Bytes

Now, as a website cannot fit into a single TCP segment, here is where things get interesting. The data is actually sent by chunks, with the last chunk flagged with PSH:
SEQ: 1
ACK: 959
Data: None
Total Size (including headers): 1430 Bytes
SEQ: 1431
ACK: 959
Data: None
Total Size (including headers): 1430 Bytes
SEQ: 2861
ACK: 959
Data: None
Total Size (including headers): 1008 Bytes

The last three packets actually represent the returned web page in gzip compressed format! Notice that the ACK number is the same through the three packet as the client hasn't communicated with the server. Guess what's the next packet? Well, if you said a blank ACK, you're right! And if you guessed that the ACK number is 3869 (2861+1008), you'd also be right!
SEQ: 3869
ACK: 959
Data: None
Total Size (including headers): 0 Bytes

Now if you're wondering why it isn't 3870 instead, it is because the first byte sent is the 2861th byte, so the 1008th byte would be the 3868th byte sent, therefore the next sequence would be 3869.

When a server sends a packet with TCP Sequence 1 with a payload of 3 bytes, the first byte is the first sequence, so the third byte is third sequence, therefore the Acknowledgment would be 4. Therefore, Next ACK = Sequence + Payload Size in Bytes.

The volley continues in the same manner:
-ACKc Data
-ACKc Data
-ACKc Data
-ACKc PSHc Data
-ACKs Data
-ACKs Data
-ACKs PSHs Data

TCP connections are terminated one way. This means that even if one side sends a FIN, the other side can continue to send data and the finished side can still receive until the sending side sends a FIN as well.

If one side has finished, while the other side has not, it is considered a half-open connection as well. Termination can be completed with a Four-Way Handshake:
1) FIN
2) ACK
3) FIN
4) ACK

Or, it can be completed with a Three-Way Handshake:
1) FIN
3) ACK

Sunday, November 14, 2010


We learned that Multicast allows one to send one data stream to multiple hosts. However, how a router handles such traffic is a mystery to us all. Recall that in IPv4, there are three ways to send data:-Unicast - One to One
-Broadcast - One to All
-Multicast - One to Selected Group

An example of a Multicast application is Norton Ghost. In a normal Fast Ethernet switched network comprising of 20 computers, imaging each computer with Unicast would result in a gross bandwidth of 100Mbps/20=5Mbps for each system. For each computer, a unique traffic stream is required, so 20 identical streams would be sent out if one used Unicast.

Broadcast is much better when it comes to this. When imaging with Broadcast, a single stream is sent out which is received by all computers in the network. All computers would have a gross bandwidth of 100Mbps. However, even computers that didn't need the imaging would have their links clogged.

The good thing about Multicast is that it's the best of both worlds. It allows a single stream to be split into multiple streams destined for only selected hosts. In IPv6, there no longer is Broadcast. Multicast has completely replaced it.

All Multicast communication uses UDP. Multicast addresses lie in the Class D range ( to Systems would need to subscribe to a Multicast server before it can receive the streaming data. This is analogously similar to a user tuning their radio to receive sound from a particular frequency.

The entire range is reserved by IANA. A list of current Multicast addresses can be viewed here. Here are a few well-known Multicast addresses:
- All Multicast-capable hosts in subnet (Replacement for Broadcast)
- All Multicast-capable routers in subnet
- RIPv2 Routers

Multicast Global range is from to It is originally designed for the MBone (Multicast Backbone). MBone, however, is a dead concept. Global addresses are always assigned dynamically.

The Private Multicast range goes from to It is designed for private use within an organization and can be statically assigned.

We'll first talk about IGMP. There are three major versions of IGMP and IGMPv2 is the most popular. When a client wants to look for a Multicast server, it sends an IGMP message to the router. It's then the router's job to search for the best path to the server, then subscribe to it.

In IGMPv1, servers would occasionally send Query messages to clients to check if they are still listening to the stream. Once the clients stop responding to Query messages, it would send a Stop message to the upstream routers and so on. In IGMPv2, the clients have the ability to stop the stream if they no longer need it without waiting for the Query message to time the stream out. IGMPv3 allows the clients to choose the source of the stream with the Unicast address (e.g. I want from

By default, switches treat Multicast messages the same as Broadcast. Cisco uses the proprietary CGMP (Cisco Group Management Protocol) on their routers and switches. As the stream returns from the internet, it is accompanied with a CGMP message. The CGMP message tells the switch of the Multicast MAC address of the client. This is Cisco's way of making a switch Multicast-aware without being a full Layer 3 device.

The second method is IGMP snooping which allows the switch to interpret passing IGMP messages. This adds a processing load on the switch. IGMP snooping can only be enabled on a Layer 3 Switch.

Normal routing protocols do not work for Multicast. Multicast routing, however, is heavily reliant on the Unicast table. Multicast is routed with two types of protocols: Source Trees and Shared Trees. For Multicast, we're more concerned about the source than the destination.

There is a Loop prevention mechanism known as RPF (Reverse Path Forwarding). The router simply chooses the best interface to reach the server. Any multicast packets coming in from interfaces other than the RPF-tagged interface would be dropped.

In the source tree system, every router tracks every Multicast source. Every Multicast source is mapped with a Unicast address. Every single router along the path to the clients would map it like this. Every client would also be mapped. The routers would then be able to route the packets around according to the Unicast table.

Source tree configuration is very easy to set up, but becomes extremely large if it's used in the Internet.

In the Shared tree world, one router would be elected as the RP (Rendezvous Point). The servers would all stream towards the RP, and clients would all request the stream from the RP. The Shared tree design is efficient because not all routers need to keep track of every single Multicast source, but because of the RP location some hosts may not get the best path.

The two main Multicast routing protocols in use are: PIM Dense Mode, PIM Sparse Mode. Dense Mode uses a Source Tree algorithm, while Sparse Mode uses the Shared Tree algorithm. Dense Mode is like RIP: You simply turn it on and it works.

In Dense Mode, whenever a server starts streaming, the router would flood the entire stream through the network. The routers would then send back Prune messages towards the source if there are no clients in need of the stream. Typically only a few packets get flooded, so it's not as inefficient as one might think.

PIM Sparse Mode requires setting of a Rendezvous Point. There is a mechanism known as Auto-RP to automatically propagate the RP address.

To enable Multicasting on a router, we'll need to type:
ip multicast-routing

By default, Multicast packets are dropped. You'll need to turn it on before the packets get through. We'll now need to turn on Multicast routing under specific interfaces. Here I'll use Dense Mode:
in f0/0
ip pim dense

At the "ip pim" menu, you'll be able to also run Sparse-Dense-Mode which runs both modes (e.g. Bush out AND set RP).

If you're running Sparse Mode, we'll need to go back to Global Configuration and type:
ip pim rp-address ADDRESS

You can also automatically announce that the router is RP by using:
ip pim send-rp-announce

On other routers, you'll need to type:
ip pim send-rp-discovery scope 10

Thursday, November 11, 2010


I'm going to go through BGP Attributes with the topology we used in the previous article:

I redrew the topology diagram to look a little neater. I also replaced all Serial links with straight lines so that it looks neater, but they're all still Serial links. Finally I've included the point-to-point subnet addresses for the various Serial links. The lower router number will get the first address of each point-to-point subnet. R4 and R6 are not neighbors so that you'll get two separate links. R2 and R3 are also not neighbors for the same reason.

We'll start from full configuration between AS 2, 3, and 4. R2 and R3 also has EBGP relationships with R3 and R6.

We'll begin configuration of the local Autonomous System (AS 1). Since the local AS only runs IBGP, you'll have to turn off Synchronization for all R1, R2 and R3:
no sync
clear ip bgp *

On all routers, we'll create a peer group as shown:
neighbor AS1 peer-group
neighbor AS1 remote-as 1
neighbor AS1 next-hop-self

On R1, we'll add R2 and R3 as neighbors:
neighbor peer-group AS1
neighbor peer-group AS1

We'll add R1 on R2:
neighbor peer-group AS1

And finally, we'll add R1 on R3:
neighbor peer-group AS1

You would have 8 routes, with 4 going to 30.0.x.0/24 and 4 going to 40.0.x.0/24.

At this point, the 30.0.x.0/24 networks would preferably be going through:
AS 2 3 4 ?
>AS 2 3 ?

The route to 40.0.x.0/24 would then be going through:
AS 2 4 3 i
>AS 2 4 i

Now we'll begin the first tuning of the BGP attributes. The first thing we can set is the Cisco proprietary Weight attribute. Weight is local to the router. Higher Weight routes are preferred, and the default Weight is 0.

To set the weight, we'll use:
neighbor weight 500
clear ip bgp *

What the above command does is to prefer routes coming from R2. If you check the topology table (with "show ip bgp"), you'd see that the routes coming from R2 are now preferred with the > symbol.

The preferred path to the 40.0.x.0/24 networks is now:
AS 2 3 4 i

We'll now remove the Weight command:
no neighbor weight 500
clear ip bgp *

Now, if we wish to temporarily disable a neighbor, we do not have to remove all the neighbor statements. We can simply type:
neighbor shutdown

This would restrict the neighbor relationship but will still retain the configurations so that it can be quickly brought back up using:
no neighbor shutdown

The origin is where a route came from. You can check the origin of a route using:
show ip bgp

Routes originated with the "network" command will be marked with "i". Routes originated with the "redistribute" command will be marked with "?".

We'll now talk about Local Preference. Local Preference is the industry standard method to modify route preferences in the AS. Local Preference is similar to Weight, but it's transitive within the AS.

If we wish all routes from R2 to be preferred Locally, we'll simply go into R2. From the BGP context, we'll type:
bgp default local-preference 101
clear ip bgp *

If we check back on R1, we'll see that the local preference for R2's routes are marked as 101 and the routes would be preferred.

You can change Local Preference for specific routes only. To do this, we'll need route-maps. We'll make R2 the preferred router for the 40.0.x.0/24 network and R3 the preferred router for the 30.0.x.0/24 network.

On R2, we'll make an access-list matching the 40.0.x.0/24 network:
ip access-l standard AS4
permit ip

We'll then create one for AS3's routes as well:
ip access-l standard AS3
permit ip

Now we'll make a route-map:
route-map LOCAL_PREFERENCE permit 10
match ip address AS4
set local-preference 101
route-map LOCAL_PREFERENCE permit 20
match ip address AS3
set local-preference 99
route-map LOCAL_PREFERENCE permit 30

We'll now apply the route-map on R2:
neighbor route-map LOCAL_PREFERENCE in is the IP of R4. At this point, R2 will automatically be preferred for 40.0.x.0/24 networks, while R3 will be the router for 30.0.x.0/24.

Now, notice that I made the incoming routes from R4 a higher local preference rather than outgoing routes to R1. This is so that R2 itself would be affected as well. If we actually change only the outgoing routes to R1, then R2's local preferences for those routes would still be default.

The Multi-Exit Discriminator or MED is also known as "Metric" in BGP. MED is used for "suggesting" which Exit to use if there are multiple entrances/exits into the same organization. The lowest MED is preferred. The way to remember this is to remember MED as a metric in a normal routing protocol, where lower is better.

The MED can be set with two methods as well. The first method is to go to the BGP context and type:
default-metric 100

This actually makes it less preferred than default. We'll also be able to set the MED for specific routes using route-maps just like how we did for Local Preference. For example, we can do a "match ip address ACCESS-LIST", then use a "set metric 100".

Don't you just love BGP?


Now we're finally going to talk about BGP Attributes. BGP is the biggest protocol in the world and BGP Attributes is how it finds its way around. BGP Attributes represents the mother of all metrics and it is very complicated.
BGP Attributes are ways you can "label" prefixes learned from BGP. You can modify both incoming and outgoing prefix attributes.

Some attributes are well-known, while some others are optional. Well-known means that every vendor must support it. Attributes can also be mandatory or discretionary. Mandatory attributes are well-known attributes that are compulsory. Finally, some attributes can be transitive while others are non-transitive. Transitive attributes are attributes that can travel through the routers distributing the prefixes.

The Major Well-Known Attributes (all vendors must support them) are:
-Autonomous System Path (AS-PATH) (Mandatory)
-Next Hop Address (Mandatory)
-Origin (Mandatory)
-Local Preference
-Atomic Aggregate

Cisco's Optional Attributes are:
-Multi-Exit Discriminator (MED)

The Autonomous System Path is the attribute that contains a list of all the Autonomous Systems the particular prefix traversed. The lowest AS_PATH is preferred. As such, this behaves like Hop Counts.

The Next Hop Address is the "gateway" to get to the prefix. This qualifies or disqualifies a route depending on whether the Next Hop Address is reachable or not. (Recall that the routes are ignored when IBGP didn't change the next-hop to itself in the previous articles).

Origin is the Autonomous System where the prefix came from. Local Preference is how preferred the route is within the local Autonomous System.

Now, that's just 7 out of the countless Attributes a prefix can have. The BGP process actually decides on which route to keep based on the following:
0. Ignore routes with an inaccessible next hop address
1. Prefer the path with the highest WEIGHT.
2. Prefer the path with the highest LOCAL_PREF.
3. Prefer the path that is local to the router (via a "network", "redistribute" or "aggregate" command).
4. Prefer the path with the shortest AS_PATH.
5. Prefer the path with the lowest origin type.
6. Prefer the path with the lowest multi-exit discriminator.
7. Prefer eBGP over iBGP paths.
8. Prefer the path with the lowest IGP metric to the next hop address.
9. Determine if multiple paths require installation in the routing table for BGP Multipath.
11. Prefer the route that comes from the BGP router with the lowest router ID.
12. Prefer the path with minimum cluster list length if the originator is the same for multiple paths.
13. Prefer the path that comes from the lowest neighbor address.

WEIGHT is a Cisco proprietary attribute that is local to a router. Yes, it does not leave the router at all, so it can be seen as a ROUTER_PREFERENCE instead.

LOCAL_PREF is a Well-Known Mandatory attribute that is advertised to routers in the same AS. LOCAL_PREF and WEIGHT are tied by default so it must be set by an Administrator for it to work.

The BSCI examination focuses on the first 4 steps in the Best Path Selection Algorithm.

Lets begin a more detailed study of the BGP process using the following topology:

We'll be focusing on the prefix as received on R1. After the network stabilizes, R1 will eventually receive two different paths to the network. We can see this information using:
show ip bgp

Path 1 goes to R2 then to AS 2 3 4 i
Path 2 goes to R3 then to AS 3 4 i

Both paths have the Next Hop set to the respective routers due to the "next-hop-self" command. By default, Metric (0), LocPrf (100) and Weight (0) are all set to default so the path with the shortest AS_PATH gets selected. In this case, Path 2 is marked with the > symbol which means it's preferred.

All routers in the BGP process typically have the same routing table when it comes to routing to external routes. In this case, traffic originating from R1, R2 and R3 destined for the network would always cross the link to R6.

As this would result in a full-blown discussion, I'll elaborate more on this topology in the next article where we'll play around with the attributes.

Wednesday, November 10, 2010

Java 03

In this article, I'm going to talk about Power Management Event. Power Management Event is a PCI 2.2 standard that allows network cards to receive Wake-on-LAN packets without the need for a WOL cable.
NICs can receive these PME packets from any of the computer sleepstates. Recall that a computer can be in one of five main powered states, of which three are of interest:
S3 - Suspend to RAM. This refers to "Sleep"
S4 - Suspend to Harddisk. This refers to "Hibernate"
S5 - Soft Off. This refers to "Shut Down"

S5 is referred to as Soft Off because although most of the components are turned off, some components can still be powered to receive signal to turn it on. There is another similar mode known as G3 mode in which a power is Mechanically Off, leaving only the RTC powered by an onboard battery.

When the computer is fully turned on, it is said to be in S0 mode.

In all states, with the exception of G3, compliant NIC cards are capable of receiving Magic Packets. A Magic Packet is simply a formatted UDP packet that causes a computer to switch to S0 mode. Magic Packets are typically received on UDP ports 0, 7 or 9.

For a computer to successfully perform WOL, the following conditions must be satisfied:
-Computer in a non-G3 state
-BIOS configured for PME/WOL
-Routing/Switching equipment must forward to correct interface
-Payload must follow proper format

We'll first talk about configuring the BIOS for WOL. During bootup, you can access your BIOS with the DEL key on most motherboards. Once you're the BIOS configuration, you would have to go under the Power Management section. Make sure that WOL is turned on and allowed. Note that on certain motherboards like Gigabyte P55A-UD3, it is referred to as PME instead.

A typical home router is actually a router with one routed and multiple switched interfaces. This essentially makes it a layer 3 switch. For a switch to forward the packet to the correct interface, it must already learn the MAC of the host.

Typically people forward port 9 to the IP address of the WOL host. However, before the router can successfully send the packet to the host, it must first ARP for the host's MAC address. If the host is turned off, it does not have an IP address, and therefore the host would not reply to the ARP request. The packet would then be dropped.

The trick here is to actually send the WOL packet out of all the ports. To do this, a static host must be configured with the broadcast MAC address of FF:FF:FF:FF:FF:FF. Any packet going to that static host would be sent out of all interfaces.

To do this on a Linux-based router like a router belonging to the WRT54G/GS/GL series, you would type this command:
ip neigh add lladdr ff:ff:ff:ff:ff:ff nud permanent dev br0

On a Cisco equipment, you should use this command instead:
arp ffff.ffff.ffff arpa

Since this must be typed every single time the router starts up, you should put it in the Init scripts. Note that you would have to use an address that would never be occupied by a host, or strange things would start to happen whenever communication to the host is required.

Now you can forward UDP port 9 to the address from the router's GUI. In this arrangement, anything sent to port 9 would be broadcasted out all interfaces.

We'll now talk about the Magic Packet. The Magic Packet is a UDP packet with a sync stream and a MAC portion. The sync stream is simply a series of 1's spanning 6 bytes. The MAC portion is simply the MAC address of the WOL host repeated 16 times. The resulting packet has a payload size of (6+16*6)=102-bytes.

This is a sample WOL packet:
0000   00 00 0c 07 ac 03 02 00 4c 4f 4f 50 08 00 45 00
0010   00 82 3d 8e 00 00 80 11 aa 8b 98 e2 98 4a de a4
0020   42 80 ee 91 00 09 00 6e 53 b0 ff ff ff ff ff ff
0030   1c 6f 65 3f d4 f8 1c 6f 65 3f d4 f8 1c 6f 65 3f
0040   d4 f8 1c 6f 65 3f d4 f8 1c 6f 65 3f d4 f8 1c 6f
0050   65 3f d4 f8 1c 6f 65 3f d4 f8 1c 6f 65 3f d4 f8
0060   1c 6f 65 3f d4 f8 1c 6f 65 3f d4 f8 1c 6f 65 3f
0070   d4 f8 1c 6f 65 3f d4 f8 1c 6f 65 3f d4 f8 1c 6f
0080   65 3f d4 f8 1c 6f 65 3f d4 f8 1c 6f 65 3f d4 f8

This is a 11 (UDP) packet sent from 98 e2 98 4a ( to de a4 42 80 ( The packet is directed at port 00 09 (9). The payload starts from "ff ff ff ff ff ff" till the end of the packet. If you count, you would see 16 repetitions of the MAC address after the sync stream.

We'll now work on the programming part. We'll start by importing the networking packages because we'll need to transmit it using UDP (DatagramPacket, DatagramSocket):
import java.net.*;

Now, we'll begin by creating the payload in a byte array. We can very quickly create it by first storing the MAC address in its own byte array, then replicating it with a for-loop into another byte array representing the payload.

We'll first create the MAC array:
String macString = "ab:cd:ef:gh:ij:kl";
String[] macStringArray = macString.split(":");
byte[] macArray = new byte[6];
for (int i=0; i<6; i++)

Next, we'll create a payload array and replicate the data through:
byte[] payload = new byte[102];
for (int i=0; i<payload.length; i++)
if (i<6) {

From index 0 to 5, it would be filled with 1's. From 6 to 102, it would be filled with the MAC address of the target.

Now we'll create a Datagram packet with the payload array we have:
String inetAddressString = "syraxius.ath.cx";
InetAddress inetAddress = InetAddress.getByName(inetAddressString);
DatagramPacket datagramPacket = new DatagramPacket(payload, payload.length, inetAddress, port);

Now we can transmit by creating a DatagramSocket:
DatagramSocket datagramSocket = new DatagramSocket();

Finally, we close the socket:

And there you have it!

Tuesday, November 9, 2010


If you look at the previous few articles, you'd notice that BGP actually requires a lot of commands for each neighbor. If you have multiple neighbors, you'd have to type the same commands over and over a lot of times. This is where BGP peer groups come in!
BGP peer groups allow you to quickly put multiple similar routers into the same group. This is very useful if you look at the previously used topology:

Suppose that we've decided to run IBGP on all routers in the local AS. However, this would mean that we must type the same commands used on R1 on R2 and R4 as well. The better approach is to actually create a group configuration. We'll then apply the group configuration to all IBGP neighbors.

To do this, we'll create a peer-group:
neighbor IBGPPEERGROUP peer-group
neighbor IBGPPEERGROUP remote-as 1000
neighbor IBGPPEERGROUP next-hop-self
neighbor IBGPPEERGROUP update-source lo0

We'll now add the neighbors as shown:
neighbor peer-group IBGPPEERGROUP
neighbor peer-group IBGPPEERGROUP
neighbor peer-group IBGPPEERGROUP

Now, we would want to configure this into a full mesh topology. We cannot simply have R1 and R3 peer with R2 and R4. This is because of the IBGP split-horizon rule. The rule states that a route learned from IBGP would not be advertised to another IBGP neighbor. This would mean that if R2 or R4 learns of a route from R3, it would not pass it on to R1. To make them pass the routes, we would need to configure route reflectors, which is an advanced topic explained later on. For now, we'll need to configure all routers to have a full mesh neighborship with every other router.

Now, let's talk about how BGP neighbors form relationships. There are many steps and here's a summary:
1) Idle: Verifying route to neighbor
2) Active: Attempting to connect to neighbor
3) Open Sent: Open Message Sent to Neighbor
4) Open Confirm: Open Message Replied from Neighbor
5) Established

On step 4, if neighbor did not reply with a correct Open message, you would cycle back to Active instead. This is known as BGP Stuck-In-Active. (Of course, don't confuse this with EIGRP Stuck-In-Active where a broadcast storm is created while looking for backup routes.)

The first two steps take the longest time. We can actually view the neighbor forming process using the debug command:
debug ip bgp

We'll then clear the neighbor relationships using:
clear ip bgp *

This would be the typical output of a normal relationship forming process:
*Mar  1 00:05:27.971: BGP: went from Idle to Active
*Mar  1 00:05:27.987: BGP: open active, local address
*Mar  1 00:05:28.023: BGP: open failed: Connection refused by remote host, open active delayed 362ms (850ms max, 87% jitter)
*Mar  1 00:05:28.387: BGP: open active, local address
*Mar  1 00:05:28.443: BGP: open failed: Connection refused by remote host, open active delayed 659ms (1000ms max, 87% jitter)
*Mar  1 00:05:29.107: BGP: open active, local address
*Mar  1 00:05:29.151: BGP: went from Active to OpenSent
*Mar  1 00:05:29.155: BGP: sending OPEN, version 4, my as: 1, holdtime 180 seconds
*Mar  1 00:05:29.239: BGP: rcv message type 1, length (excl. header) 26
*Mar  1 00:05:29.243: BGP: rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 00:05:29.247: BGP: rcv OPEN w/ OPTION parameter len: 16
*Mar  1 00:05:29.247: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 00:05:29.251: BGP: OPEN has CAPABILITY code: 1, length 4
*Mar  1 00:05:29.251: BGP: OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 00:05:29.255: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:05:29.259: BGP: OPEN has CAPABILITY code: 128, length 0
*Mar  1 00:05:29.259: BGP: OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 00:05:29.263: BGP: rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:05:29.263: BGP: OPEN has CAPABILITY code: 2, length 0
*Mar  1 00:05:29.267: BGP: OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: rcvd OPEN w/ remote AS 1
*Mar  1 00:05:29.267: BGP: went from OpenSent to OpenConfirm
*Mar  1 00:05:29.267: BGP: went from OpenConfirm to Established
*Mar  1 00:05:29.271: %BGP-5-ADJCHANGE: neighbor Up

Now we'll check out some BGP verification commands. The most commonly used one is:
show ip bgp

This command is used to check the BGP prefixes table. From here, you can see which routes are learned, and which of those learned routes are accepted. You can also derive information about a route to find out why it wasn't added to the topology table.

Another show command which shows more information in a summarized form is:
show ip bgp sum

The above command shows all the routes statistics (instead of actual routes) as well as neighbors relationships.

There is a very detailed way to display information about neighbors. This is typically not used unless you require the details. Most of the useful information are in the first two commands. To see detailed neighbor information, use:
show ip bgp nei

If there are routes not showing up in the routing table (a route with no caret), you can see the reason why it isn't added using:
show ip bgp rib-failure

RIB-Failure sounds disgusting, but it actually means Routing Information Base Failure.

This should be enough to get you prepared for the next few BGP articles. If you thought BGP up to this point sounds nightmarish, wait till you see the BGP Attributes.


BGP has auto-summarization capabilities. However, it does summarization like EIGRP and RIP, and sadly there is a bad reason why we usually type "no auto" when we get into the EIGRP or RIP process. We'll talk about how to turn auto-summarization off later in this article.
Right now I want to focus on adding networks into the BGP process. There are two ways we can do this:
-"network" command
-"redistribution" command

Now let's get back on the same topology we used in the previous article.

Suppose that R5, the ISP router, has networks at and If we type "network", we would actually advertise a whole class A network! We should instead use:
network mask
network mask

You can advertise with the network command only either the classful boundary or the exact subnet. You cannot do summarization with the "network" command. For example, "network mask" will NOT work!

Typically IGP carries private network information, so it's not recommended to redistribute IGP routes into BGP. Redistribution should only be done when necessary and only the necessary routes should appear in the BGP process. How would we do this? If you've followed the previous articles, the first thing in your head would be Route-Maps and you would be right!

Now, let's assume that the ISP router has routes from its IGP going to 30.[0-7].0.0/16. We would only want and going out into BGP during redistribution. We'll create an access-list to permit those first:
ip access-l standard PERMIT_5_6

We can now permit using a Route-Map:
route-map REDISTRIBUTE_5_6
match ip address PERMIT_5_6

We can now redistribute OSPF with the Route-Map we created:
redistribute ospf 1 route-map REDISTRIBUTE_5_6

By default, 12.2(8)T and above have auto-summarization turned off by default. If you happen to be running an IOS below 12.2(8)T, you would have to type:
no auto

Now hop on over to R1 and check the BGP table:
show ip bgp

Notice that even though you've received the external routes from IBGP, they still may not be in the routing table. This is because of the BGP synchronization rule. BGP synchronization rule states that routes should not be used or advertised until its IGP has learnt it as well.

What this rule help prevent is the Networking Blackhole described in the previous article! BGP Synchronization is on by default in IOS versions 12.2(8)T and below. This is because Cisco assumed that if you're running IBGP, you would probably be running it contiguously, which you should!

To turn off synchronization, we should type (on all IBGP routers):
no sync

Now, even if you've disabled synchronization, it may still not be in the routing table. If we check the BGP table now ("show ip bgp"), we would notice that the route's next hop is set to R5's interface. R1 does not know how to get to R5!

By default, next-hop addresses would be changed to itself whenever a router advertises to an EBGP peer. However, next-hop addresses would remain the same if a router advertises to an IBGP peer! That explains why the next hop was still R5!

To fix this, we'll need to tell R3 to change the next-hop to itself when advertising all routes to R1. To do this, we'll go on R3 and type:
neighbor next-hop-self

BGP has a lot of queer behaviors and you would need to know these off the top of your head if you're into both the examination or real world implementation.


BGP can be implemented in two different ways: IBGP and EBGP. The I and the E stands for Internal and External respectively. As how it sounds, Internal BGP refers to BGP neighbors running between the same Autonomous System. External, then, refers to BGP run between different Autonomous Systems.
Typically, an organization can obtain an Internet-legal AS number. Like IP addresses, you also have private AS numbers.

BGP redefines what we consider "neighbors". You can actually have BGP neighbors that are NOT directly connected. The routing to the other neighbors can then be done with IGPs like OSPF and RIP.

We'll do our first BGP configuration using this topology:

IBGP is commonly run on routers connected to multiple ISPs in the same AS. This is used to provide redundancy. Organizations with such redundant connections typically become a transit AS. Transit AS's become a "node" in the public routing network where public traffic goes through.

Beware, though, being a transit AS you may create Networking Blackholes if you run IBGP with non-directly-connected neighbors.

Suppose that the network wants to communicate with the network, and your AS is the transit AS that has the best metric, the packet would go through you.

However, remember that only the IBGP routers know about and, so as it goes into your IGP domain, the router on the inside would not know where to route it. Therefore, the packet would be dropped! You have thus created a Networking Blackhole in the Internet where every packet in transit would be dropped!

There are three ways to solve this. The first is to simply redistribute BGP into your IGP. However, this is not recommended as IGP is not made to handle such traffic.

The second way is to have your IGP router also run IBGP. That way, they would all have the routes and would go through.

The final and recommended way is to actually have a direct link between both of your IBGP routers.

Now we'll begin some BGP basics. This will accomplish both IBGP and EBGP relationships:

For each link, the router with the lower router number will get the lower host address. All links are FastEthernet.

We'll begin configuration on the ISP router first. We'll put the ISP router in AS 2000 first:
router bgp 2000

The ISP router is, so R3 would be We'll add R3 to the ISP's neighbors:
neighbor remote-as 1000

There are many things you can do with a neighbor, but the first command you need to enter is the remote-as command. Other commands will not be accepted until this command is present. R5 is now attempting to connect to R3.

To see the configured neighbors, use:
show ip bgp sum

If you haven't configured the other side yet (hopefully, since you're following this), you would have the state of the neighbor written as "Active". Remember, "Active" is something bad. It means that the router is actively trying to establish the relationship.

We'll now hop over to R3 and put it in AS 1000:
router bgp 1000

The same way, we'll add R5 as a neighbor:
neighbor remote-as 2000

You may have to wait some time for the neighborship to come up. If you check the neighbors, you'll see that the neighbor is "Idle". "Idle" means that it knows that the router is there, but it hasn't attempted to establish a connection yet.

EBGP should come up by now. We'll now configure IBGP. There's no difference in configuration, except that the remote-as of the neighbor is the same as its own. Now, assuming that OSPF is up and running, we'll add R1 to the neighbor table.

Now, for R1, there are two addresses we can use: and However, if we choose one and it goes down, the neighbor relationship would go down. We should use neither one of this, and instead peer with a Loopback address. The Loopback would be advertised into OSPF!

On R1, we have a Loopback address advertised into OSPF. The other routers all have 10.0.1.x/32 Loopbacks advertised. We'll now peer with the Loopback from R3:
neighbor remote-as 1000

At this point, the neighborship won't come up even if both sides are configured to use each other's Loopbacks. This is because the connection is established from a FastEthernet interface. The other side would not recognize it as a neighbor and so the relationship will not come up. The way to fix this is to change the update source:
neighbor update-source lo0

Do this for R1 as well:
router bgp 1000
neighbor remote-as 1000
neighbor update-source lo0

Now they'll try to use their Loopbacks to establish the relationship with each other's Loopbacks.

Now, what if we have redundant ways to get to an ISP router? For example, what is R3 has two links to get to R4? The way to do this is to create two static route to the opposite router's Loopback interface (assuming you have another link at
ip route
ip route

The ISP would also have to create two static routes back. After this is done, and even after adding each other's Loopback interfaces, and changing the update-source, the neighbor relationship would still not come up! This is because by default EBGP neighbors MUST be directly connected!

To change this, we'll need to make use of multihop. To do this, we'll need to type:
neighbor ebgp-multihop 2

This is all the commands we'll need on R3 to peer with R5's Loopback:
ip route
ip route
router bgp 1000
neighbor remote-as 2000
neighbor update-source lo0
neighbor ebgp-multihop 2

You would have to mirror the configuration for R5:
ip route
ip route
router bgp 2000
neighbor remote-as 1000
neighbor update-source lo0
neighbor ebgp-multihop 2

This article focuses only on neighbor relationships. We'll talk about advertisements in future articles.

This sentence is here to test if Mr Soma would one day end up here through Google. Here's some keywords to help him out: L Somasundaram, IFC Alumni Advisor, 67805602, somasun@tp.edu.sg, Network Security, GreatSoma.

Network Security is my favorite subject! (<- I think Mr Soma came here to see this.)

On a side note, what does L stand for? I really couldn't find it in Google.

Sunday, November 7, 2010


We'll now go into the final and biggest protocol in the world: The Border Gateway Protocol (BGP). Interior Gateway Protocols are the protocols we use to do routing internally. Exterior Gateway Protocols are protocols used to route the Internet. EGP used to be a protocol, but now it's become a category of protocols, and BGP is the only EGP protocol employed now.
BGP is used when you have multiple ISPs. When you run BGP, you're not so much concerned which direction you're going OUT. You're more concerned about how people get INTO your organization! Organizations want to make sure that they have a redundant connection for people to access their sites if ISPs go down. To do this, they'll need to advertise their public address block to the BGP domain. Such usage of more than 1 ISP is known as multi-homing.

BGP runs on top of TCP, unlike other protocols which have their own transport mechanism. TCP is used for reliability, and updates are incremental and triggered. The metric of BGP is the biggest metric in all routing protocols. The metric for BGP is the BGP Attributes. The protocol goes through 7 different attributes looking for an attribute to break the tie. It is the slowest routing protocol to converge, which is good for the Internet.

There are many styles of BGP implementation. CCNP focuses on using BGP from the perspective of the enterprise. The simplest outgoing access style is simply to have one ISP be the primary, and the other ISP be the backup, or do a simple per-conversation load-balance.

The second style of implementation is to have Partial Updates. You can selectively receive updates for blocks of addresses that are important to you. For example, you can selectively opt to receive addresses belonging to your offices in other countries.

The final style of implementation is the Full Updates. You will need to have a very powerful router to support this as you will be receiving all routes in the Internet.

BGP is technically a Distance Vector protocol, but most people call it a "Path Vector" protocol. Without tuning, BGP behaves just like RIP! The path chosen is based on the lowest number of AS they see in the AS_PATH.

BGP communicates with these types of packets:

Open packets start the session with another router. It is like the initial Hello packet.

Keepalive messages make sure that the neighbors are still around. It is like the subsequent Hello packets.

Update packets gives network reachability information. This is the bulk of messages. The messages contain "prefixes", which is another term for "routes".

Notification packets tells the neighbors of a bad event. There is no good notification. It is also used to close a session.

Below is the list of tables used by BGP:
-Neighbor Table
-BGP Table
-Routing Table

Neighbor Table keeps a list of configured neighbors. Neighbors in BGP are statically configured.

BGP Table is the list of ALL BGP routes. This is a huge table.

Routing Table keeps a list of the best routes.


By design, routing protocol send routes, and the protocols send the routes to all neighbors as best as they could. However, sometimes, we do not want all routes to go through. For example, if we're partnering with other organizations, we wouldn't want certain routes to go to them.
There are many ways we can manipulate route updates. We will start with the simplest of all: Distribute Lists.

Distribute Lists allow us to apply an Access-List to routing updates. It can be applied inbound or outbound under a routing process. If you do not want to see your neighbor's routes, use an inbound Distribute List. If you do not want to tell your neighbor about some routes you have, use an outbound Distribute List.

However, it works slightly differently with OSPF and IS-IS. Remember that Link State protocol needs to know about all routes in the topology table. You cannot not tell your neighbors about routes. However, you can use Distribute Lists to keep it from entering the Routing table. Therefore, you can only apply an inbound Distribute List to your Link State routing protocol process.

Suppose that we're again using the following topology:

Suppose that there are networks 10.0.[0-7].0/24 networks sitting behind R1. The network is a secret lab, so it shouldn't be advertised to anyone else. Next, networks and should be kept within RIP domains only.

In this case, we'll need two access-lists. One is an Outbound Distribute List for R1 and another is a Redistribution Distribute List for R2.

On R1, we'll create a list that denies and permits the rest. To do this, we'll type:
ip access-l standard DENY_3
permit any

Now we'll need to add it into the routing process as shown:
router rip
distribute-list DENY_3 out f0/0

At this point, R2 will stop receiving networks. However, you would have to wait a while for the routes to disappear from the list. If we want to clear the table, use:
clear ip route *

We'll now deny and from going over to the OSPF domain. To do this, we'll create a new list on R2:
ip access-l standard DENY_6_7
permit any

Next, we'll filter the RIP protocol out of OSPF:
router ospf 1
distribute-list DENY_6_7 out rip
redistribute rip subnets metric 1

Another way to filter routes is through Route Maps. Route Maps operate similar to BASIC programming. Route Maps is essentially a compilation of multiple "If...Then" statements and is used heavily in BGP, Policy-Based Routing and Route Filtering.

In Route Maps, "match" correlates to "if", and "set" correlates to "then". Route Maps have sequence numbers, and it will go through the sequence numbers until a match occurs.

Here's how a Route Map looks like:
route-map ROUTE_MAP permit 10
match condition
set action
route-map ROUTE_MAP permit 20
match condition1 condition2
match condition3
set action1
set action2
route-map ROUTE_MAP deny 30
match condition
route-map ROUTE_MAP permit 40
set action

Route Maps are created in global configuration mode. The syntax is as follows:
route-map NAME <permit|deny> [SEQUENCE]

You can have many conditions in a match statement. When this happens, it's a logical-OR.

If you have multiple match statements, you have a logical-AND.

You can also have more than 1 set statements.

Anything matched by a deny entry would not be processed by the route-map.

If you do not specify a match statement, it matches everything.

Using the same scenario, we'll use a Distribute-List on R1 as usual, but on R2, we'll create a route-map to permit networks 6 and 7, then use a route-map to deny those networks:
ip access-l standard PERMIT_6_7
route-map FILTER_6_7 deny 10
match ip address PERMIT_6_7
route-map FILTER_6_7 permit 20

Now we'll apply the route-map to the redistribution process:
router ospf 1
redistribute rip route-map FILTER_6_7


Most of the CCIE R+S examination focuses on Route Redistribution. Now, performing Route Redistribution already means that you're moving routes across different routing protocols (well, with the exception of static routes). Why would people use multiple routing protocols?
In the real world, most of the time it's due to political reasons. As companies get larger, more and more policies and politics would surface. Some divisions of organizations forbid the use of proprietary protocols. On the other hand, the rest of the division is alright with proprietary protocols. This leads to a split in network politics where different parts of a large organization use different protocols.

Other reasons include upgrading of routing protocols where parts of organizations convert in phases. Also, implementation of different vendors would lead to this, such as EIGRP for Cisco equipment and OSPF for the others.

Redistribution from a bird's eye view is very simple. You simply have to have a router running two protocols at once. That router then mixes the routes between the protocols (can be one or two ways).

However, it can become complicated when we talk about the characteristics of different protocols. What happens when we want to redistribute OSPF into RIP? What happens to the metric? In this case, we would have to translate the "cost" type of metric into a "hop count" type of metric. Typically people create a "seed" metric for all routes from the OSPF domain, which is done manually by estimation and proves to be unreliable.

Another problem we can get from this is routing loops. Refer to the following topology:

If we perform full redistribution at both links, the RIP routes would be sent to the OSPF domain then redistributed back into RIP.

We'll talk about fixing this in a future article. Right now, we'll deal with a very simple redistribution exercise:

R1 has 10.0.0-3.0/24 networks connected to it. R1 uses RIP for the link to R2, and the networks it's connected to. R2 uses RIP as well as OSPF on the link to R1 and R3. R3 and R4 are full OSPF routers.

The point-to-point links between routers use networks from left to right.

Here's the configuration on R1:
router rip
no auto
ver 2

On R2, we have:
router rip
no auto
ver 2
router ospf 1
network area 0

On R3, we have:
router ospf 1
network area 0
network area 0

Finally, on R4, we have:
router ospf 1
network area 0

Now, R1 knows how to go up till the link between R2 and R3. R2 has full connectivity. R3 has only routes within OSPF.

Now, to redistribute OSPF into RIP, go to R2 and type:
router rip
redistribute ospf 1 metric 5

Now R1 would have all routes in both domains. It would appear as RIP routes. The direct RIP route from the link between R2 and R3 would be preferred to the redistributed one because of the metric. Pay attention to this as I would demonstrate how this would cause routing loops in future articles.

Now we'll redistribute RIP into OSPF from R2:
router ospf 1
redistribute rip subnets metric 1000

When redistributing into OSPF, we can also change the Metric Type to E1 by using the "metric-type" keyword. Recall that E1 routes will have the cost incremented through the OSPF domain, while E2 routes will not.

You can also tag routes using the "tag" keyword. This marks the route so that you would be able to check where it came from later on. This tag also allows you to manipulate the route later on using route filtering. This is what we'll use to prevent the routing loop described above.

When redistributing, you can also set a default-metric for all redistributed routes. This is done by typing:
default-metric 1800

This can be used in all protocols. The default-metric is overridden if you manually specify it in the redistribute statement.


All protocols have some conditions before they can put the routes in their databases in their routing tables. Here is how IS-IS does it:1) L1 and L2 Intermediate Systems perform separate calculations
2) SPF Algorithm is run to determine best paths for NSAP routing
3) Best paths are added to the OSI routing table
4) PRC Algorithm is run to determine best path for IP routing
5) Best paths are added to the IP routing table

The only time when SPF has to run again is when a router is added or changed. PRC is run when IP networks are changed. Since PRC is very lightweight, it ends up more efficient than OSPF.

This is what we'll use to demonstrate basic IS-IS routing:

The Area ID would be in the format 49.00aa where "aa" stands for the Area ID
The System ID would be in the format 0000.0000.000s where "s" stands for the Router ID
Finally, the NSEL is always 00

We'll first configure R1. To do this, we'll go to global configuration and type:
router isis

You can actually enter a tag after the "isis" keyword, which is similar to an EIGRP's AS number. If you do not enter anything, the default "0" is used.

We'll now need to enter the NSAP address for R1. It would be:
net 49.0050.0000.0000.0001.00

By default, routers are L1/L2 routers, so we'll need to set it to L1:
is-type level-1

We'll then need to turn on IS-IS under the interface. In this case, I have Loopbacks to simulate networks:
in lo0
ip router isis
in lo1
ip router isis
in lo2
ip router isis
in lo3
ip router isis
in f0/0
ip router isis

Now we'll need to configure R2:
router isis
net 49.0050.0000.0000.0002.00

Then we'll configure R2's interfaces:
in f0/0
ip router isis
isis circuit-type level-1
in f0/1
ip router isis
isis circuit-type level-2

The circuit-type restricts L1 or L2 Hellos in the interfaces. At this point, we can do some verification:
show clns neighbors

To see the neighbor's IP, we can use:
show clns neighbors detail

To see the interface status, use:
show clns int

CLNS stands for Connectionless Network Service. It is connectionless and unreliable, requiring upper layer protocols for reliability. Sounds familiar? Yes, it's the equivalent of IP.

We'll enable R3 for IS-IS similarly:
router isis
net 49.0020.0000.0000.0003.00
is-type level-2

Here, we also configure the interfaces:
in f0/1
ip router isis
in f0/0
ip router isis

Finally, we'll configure R4:
router isis
net 49.0005.0000.0000.0004.00

And we'll configure its interfaces:
in lo0
ip router isis
in lo1
ip router isis
in lo2
ip router isis
in lo3
ip router isis
in f0/0
ip router isis
isis circuit-type level-2

At this point you should have full connectivity and routing across the domain. Another verification we can use is:
show clns

To do summarization, we'll hop on to R2, then type:
router isis

What this does is that it summarizes that into the Level 2 database. You can also summarize into the L1 database from L2 by typing the "level-1" keyword behind the statement.

On R3, if we do a "show ip route" now, we would see IS-IS routes with a "i" marker. L2 routes will be marked with "L2" and L1 routes will be marked "L1". On R2, the summary route will be marked with "su" towards Null0.

We should also summarize on R4 by typing:
router isis

To check the topology table, use:
show isis top

Finally, to change the metric, you go under the interface and type:
isis metric 1

Remember that the default is 10. They are treated as cost so lower is better.


Now it's time to go through the feared part of IS-IS: That is the NSAP address applied to the routers. OSI uses CLNP addresses, and when it's applied on a router, it's called a NSAP (Network Service Access Point) address.
You only need one address per node (per IS), not per interface. This address tells what area the router is in. It tells the Cisco router what IS-IS area it's in and what's it's System ID (which is equivalent to the Router ID).

The NSAP address can be up to 20-bytes in length, compared to OSPF's 4-bytes.

The original implementation of OSI defined more than 5 sections the NSAP address would represent, compared to the 2 which IP addresses have.

Cisco's implementation only uses three of those fields:
- Area address
- System ID
- NSEL (NSAP Selector)

An example NSAP address is:

Every NSAP address assigned to a Cisco router will always have the last 2 bits set to 00. That is the NSEL. The NSEL of 00 shows that the address is assigned to an IS.

The System ID in this case is AA15.B322.1841. The System ID is always a fixed 6 bytes in length. As mentioned previously, the System ID is actually the equivalent of the Router ID.

Some Administrators like to put the MAC addresses as the System ID. Typically in lab environments, the System ID always ends up becoming the router's number.

Whatever is left represents the area. The best way to read the address is from right to left. In this case, the area is 49.1234. Areas starting from 49 represents a private address. These packets would theoretically be dropped by ISPs like how RFC 1918 packets would.

This example address is not the longest you can get. You can have up to 20 characters in an NSAP address.

IS-IS builds a topology of the OSI domain to find out how to reach various destinations based on the NSAP addresses. When routing, IS-IS checks the area address of the packet. If it's a different area, it would be routed based on Area ID. If it's in the same area, it would be routed based on the System ID.

If you are a L1 router, it would send it to the closest L1/L2 router. The L1/L2 router then sends the packet through the backbone to the other area.

For intra-area routing, L1 and L1/L2 routers simply route it based on the L1 database.

The term "packet" is a PDU, which is a Network Layer PDU. In OSI, a Network Layer Packet is simply referred to as a Network PDU. A Frame is known as a Data-Link PDU. Theses are the various packet types used by IS-IS:
-Link State Packet (LSP)
-Partial Sequence Number PDU (PSNP)
-Complete Sequence Number PDU (CSNP)

The Hello message is the foundation that forms neighbor relationships and serves as a keepalive.

The LSP is similar to OSPF's LSU. In each IS-IS LSP, there can be information for one or more routes.

CSNP acts like the OSPF's DBD.

PSNPs are typically used to request for information like a LSQ. It is also an acknowledgment for an LSP.

A typical Network PDU has the following structure:
LSP Header|TLV|TLV|TLV|...

The LSP header contains the PDU type, length, sequence number and lifetime. The TLVs contain neighbors, authentication information and attached subnet information. They simply added a new TLV for IP routing to work!

The original IS-IS and the Integrated IS-IS is really not that different at all! Integrated IS-IS still reads NSAP and routes NSAP! It simply has an extra TLV which allows the IS to match NSAP with IP. IS-IS is one of the first routing protocol to be released for IPv6 because they simply need to add a new TLV. On the other hand, OSPFv3 had to be completely re-engineered for IPv6!

The IS-IS network types are simple:

Broadcast mode assumes full connectivity. The Broadcast Mode elects a Designated IS (DIS) which is the same as DR/BDR. Broadcast Mode uses Multicast.

When dealing with NBMA networks without a full mesh, IS-IS simply uses point-to-point (sub-interfaces) design. Point-to-Point mode uses Unicast.

To keep databases tightly synchronized, CSNPs are sent once every 10 seconds in Broadcast mode, while only once initially (when link comes up) in Point-to-Point networks.


There are only two Link-State routing protocols in the world that are considered mainstream and popular: OSPF and IS-IS. IS-IS was never designed to support TCP/IP, but it is widely employed by service providers to route TCP/IP traffic!
In the past, the OSI model was never meant to be just a model. OSI was actually a full-blown routing suite for the Internet. It was a competing standard to TCP/IP and in the end OSI lost to TCP/IP because it is simpler.

In the OSI protocol, the a router is known as an Intermediate System (IS). IS-IS stands for Intermediate System To Intermediate System! IS-IS was the routing protocol created for the OSI protocol.

The OSI was originally deployed by ISPs due to government regulations because it was a good contender. When the Internet first appeared, ISPs had to support both the TCP/IP protocol AND the OSI protocol.

After OSI protocol died out, some people saw the potential in the IS-IS protocol and so they modified it to carry TCP/IP protocol. IS-IS was not completely written, but rather it was tuned. This tuning led to a new protocol known as Integrated IS-IS!

For IS-IS to work properly, a CLNP (Connectionless Network Protocol) address still needs to be assigned to the router. IS-IS is very similar to OSPF in many ways. Here's a brief rundown of IS-IS:
-Uses SPF
-Uses Hello Messages
-More Tunable than OSPF
-More Efficient that OSPF
-More Flexible than OSPF
-Much more difficult to understand than OSPF!

Once you've understood the basics of OSPF, you pretty much understand IS-IS. The only reason why IS-IS is more difficult in some ways is because of the CLNS address still required to be assigned to the router.

In IS-IS, there are no ABRs. All routers belong fully in one area. There are two types of routers, L1, L2 and L1/L2 routers.

L1 routers are designed to maintain the topology tables of an entire area. This is similar to an Internal router.

The L2 routers are considered the backbone routers. The L2 routers are those that know about the backbone routers.

L1/L2 routers are those that interface between L1 and L2 routers.

Analogically, L1 are Internal routers, L2 are Internal Backbone routers, and L1/L2 are ABRs.

The L1 (Level One) databases are kept completely separate from L2 databases. L1/L2 routers have to keep two databases, but it can summarize the L1 database before putting it in the L2 database.

When a L1 router needs to go to another area, it sends a message to the closest L1/L2 router. The L1/L2 router sort of serves as a default gateway for an area.

The Metric of IS-IS is not based on bandwidth. It is a value between 0 to 63 with 10 being the default. By default, IS-IS metric behaves like RIP. IS-IS metric is typically written in an organizationally-unique policy and implemented by Network Administrators.

In OSI, the End Systems (ES) would participate in routing by finding their closest IS. This is known as ES-IS. In the OSI world, you wouldn't have a default-gateway. The ES would be smart enough to discover default-gateways. (This is a "new" feature implemented in IPv6 as well).

L1 and L2 routers form like relationships and separate databases. L1 and L2 have separate Hello messages, so L1/L2 would have to send two types of different Hello messages. Two L1/L2 routers can form 2 relationships between them.

A typical IS-IS network design looks like this:

In the backbone area, L2 routers only know the summary of the different areas. These summaries are sent in by L1/L2 routers. Notice that in the end the concept is still roughly the same as OSPF in terms of design.

Here are the different Level of Routing in IS-IS:
-Level 0 routing refers to ES-IS routing.
-Level 1 routing refers to IS-IS routing.
-Level 2 routing refers to IS-IS inter-area routing.
-Level 3 routing refers to routing to other autonomous systems.

Here's some OSPF vs IS-IS breakdown:
-Both are Link-State protocols
-Topology, Neighbor and Routing Tables
-SPF Algorithm

OSPF: Interfaces belong to areas
IS-IS: Router belong to an area

OSPF: All areas tie to the backbone area (Area 0)
IS-IS: The backbone runs to all areas

OSPF supports more area types, supports a metric scaled by default, is supported by more vendors and is well understood by the majority of the industry.

IS-IS handles updates more efficiently, rarely runs the SPF algorithm, prefers using partial route calculation (PRC), is much faster (by default) to detect failures and converge, has less design constraints and is very easy to adapt to IPv6.


Authentication in EIGRP uses a key-chain during authentication to do auto-key-changing and so on. OSPF is much simpler, in which authentication is enabled on a per-interface basis.
OSPF supports two types of password authentication: Clear-text, or MD5. Every OSPF packet is keyed with the password. This includes Hellos, and so on. Neighbor relationships will be immediately severed if a packet has the wrong password.

The primary way to debug authentication in OSPF is:
debug ip ospf adj

To enable authentication, go under the interface pointing towards the neighbor, and type in:
ip ospf authentication message-digest
ip ospf message-digest-key 1 cisco md5

Beware. Using "ip ospf authentication-key" is actually for clear-text. No matter what you set for authentication-key, as long as both sides have no message-digest keys, authentication will go through if you have message-digest mode set.

When debugging, you would encounter a type 0, type 1 or a type 2 authentication method. Type 0 simply means no authentication, while type 1 is for clear-text and type 2 is for message-digest is set.

Recall that previously ASBR routes show up as E1 and E2 routes. E2 is the default type, in which the cost doesn't increment throughout the OSPF domain. If there is only 1 exit to that route, this makes sense.

The only time when E1 routes are useful is when there are multiple exits to that route. This helps the routers calculate which exit it would want to go out through.

To change a route to E1 when redistributing, you use the metric-type keyword. For example:
redistribute rip subnets metric 1 metric-type 1

The cost is actually calculated based on a reference speed. The default reference speed is FastEthernet which is 100Mbps. The formula to calculate the cost of a link is:
Reference/Link Speed

So anything faster than FastEthernet would give you a cost of 1. To change the refernce speed, you can use this under the OSPF context:
auto-cost reference-bandwidth 100000

The above is entered in Mbps. You need to make sure that all the routers have the same reference cost.

Now, if you wish to generate a warning after a number of LSAs a router receives per minute, you can use:
max-lsa 100 warning-only

OSPF can send a default route to the whole domain with the default-information command. There are two different ways you can use this. If you already have a default route, you can simply type this under the OSPF context:
default-information originate

Now, if you do not have a default-route, but still want to advertise a default-route to itself throughout the OSPF domain, you can use:
default-information originate always

The route will be propagated as an E2 route by default.

Saturday, November 6, 2010


Virtual Links do not belong in a normal network, but serves as a band-aid to temporarily fix network problems introduced when companies acquire other companies. Virtual Links allows areas to be connected to an area other than Area 0. A typical Virtual Link scenario looks like this:

In this topology, R1 has the Router ID set to, R2 is and R3 is The Router ID is very important in Virtual Link because you'll have to define it in the command. In this topology, we'll have to establish a Virtual Link through Area 1.

We'll first go to the router that connects to the backbone in the area. That would be R2. On R2, we'll use the following command:
area 1 virtual-link

The command would be the same regardless of how many routers are between R2 and R3. Now, we'll do the same command on R3:
area 1 virtual-link

You simply have to remember that the area always specifies the area that you're going through.

A Virtual Link is a tunnel to trick the process to believe that it is really connected to the backbone area. You can check the virtual link using:
show ip ospf virtual

There are many ways this can fail, and most commonly it's a mistyped Router ID, a changed Router ID, or wrong Area ID.

If the situation presents itself, you can actually do Virtual Links within Virtual Links!

Now I'm going to go into different area types. This is the third time I'm using this image! But oh well, here goes!

Notice that in the image, I have Area 1 written as a possible Stub and Area 2 written as a possible Not-So-Stubby-Area.

Now, notice that no matter what external routes Area 1 receives, it only has one exit out of the network. It doesn't need to know about all the other routes and ways out of the network because it makes no difference!

In a Stubby area, all Type 5 LSAs are blocked. Recall that Type 5 LSAs are external routes sent in from ASBRs. So if an Area is Stubby, it has all the routes in the OSPF domain, and a default route to the ABR.

Now, to step it up further, you can configure an area as a Totally Stubby area. In a Totally Stubby Area, Type 3, 4 and 5 LSAs are blocked. And if we recall, Type 3 is an ABR summary and Type 4 and 5 refers to the ASBR's IP and ASBR External Routes respectively. A default route to the ABR is also flooded.

To configure an area as a Stub, you simply go on the ABR and all Internal routers and type:
area 1 stub

The ABR sees no change in the routing table, but if we hop on to an Internal router, we would see a new default Inter-Area route pointing to the ABR.

Totally Stubby Areas are Cisco proprietary. The only equipment that needs to be Cisco is the ABR. The Internal routers can still use the "area 1 stub" command. The Totally Stubby Area command to be used on the ABR is:
area 1 stub no-summary

The "No-Summary" keyword refers to Summary LSAs. Remember that Type 3 and 4 are both called Summary LSAs. These are now blocked as well. Now, the routers in Area 1 should only know about local prefixes, and a default route towards the ABR.

Now, what if a router in a Totally Stubby area becomes an ASBR? You end up with a Not-So-Stubby-Area, and that's a real technical term! NSSAs passes external routes using a Type 7 LSA, which gets read as a Type 5 once they reach the ABR. You can have a Not-So-Stubby-Area, and a Not-So-Totally-Stubby-Area.

To change Area 2 into an NSSA, type this on the ABR:
area 1 nssa

Likewise, the "no-summary" keyword can be put behind to denote a Totally Stubby area. The ASBR in the NSSA would receive a default route to the ABR in addition to all the RIP routes it knows and redistributes.

When any internal router in the Not-So-Stubby-Area wants to access the external routes from its area's own ASBR, it will first go to the ABR, then back through itself to the ASBR then out.

Like Virtual Links, NSSAs are band-aids to fix design goof-ups. It is not standard practice to design networks with NSSAs in mind.


Recall that OSPF has areas for efficiency. Every router in the area needs to know about all the routes and changes in the area. If you want to keep the topology database small, you'd have to implement areas to localize routes and updates.
Also recall that there are multiple router types which you can see from this diagram:

(Yes I'm not using Cisco logos because I used an old image I made previously)

From this point I'd need you to be familiar with the areas and router types because we'll be talking about LSA types.


Yes, recall that after exchange of DBD, LSQs are used to request for LSUs which contain multiple LSAs. But there are many different types of LSAs!

Before we describe anything, we'll go through summarization in OSPF. We'll make use of this topology:

Now back on R1, I have links to the networks:

We can only summarize on ABRs or ASBRs, so we'll need to do this on R2. To summarize Area 1, we hop on over to R2 and type:
area 1 range is the summary mask that summarizes 192.168.[1-7].0/24 to a Once this is done, R2 will begin suppressing routes matching Routers in Area 0 and other areas would only see pointing towards R2. The "area 1 range" command can also be used to hide routes by adding the "not-advertise" keyword behind. The summarized range is suppressed and not advertised.

Now, assume that R4 has the routes:

R3 receives these routes as RIP routes. Now, remember that we can do summarization on ASBRs, so we should be able to summarize on R3, right? However, one thing comes in mind: Since the summarization command is "area x range", what area exactly do we use to specify an external AS?

We don't! Instead, we use the summary-address command! To summarize on R3, we use:
redistribute rip subnets

What this does is that it advertises all RIP routes into OSPF as E2 routes, then suppress and apply the summary-address of to every address matching it.

Now, we can talk about LSAs. LSA are the building blocks of OSPF, and below is a list of the 5 most common LSAs (there are 11 in total):
LSA Type 1: Router LSA
LSA Type 2: Network LSA
LSA Type 3: Summary LSA
LSA Type 4: Summary LSA
LSA Type 5: External LSA

The Type 1 LSA (Router) is generated by routers to talk about 1 specific network within the same area.

The Network LSA is generated by a DR to tell everyone about the other routers connected to the same network segment.

Type 3 LSAs are generated by ABRs to talk about routes and summaries from other areas.

Even though Type 4 LSAs are called Summary LSAs, they are just generated by ASBRs to point to the IP Address of the ASBR in the OSPF domain.

The real routes and summaries from external locations are advertised by ASBRs as Type 5 LSAs.


It has always been a nightmare to think about OSPF implementation over the different Non-Broadcast Multi-Access (NBMA) networks.
In this world, there are three types of networks:
-Broadcast, Multi-Access Networks
Ethernet, Token Ring
Single Operation Mode
DR/BDR Election, 10 second Hellos, Dual Multicast Address

-Point-to-Point Networks
Single Operation Mode
No DR/DR, 10 second Hellos, Single Multicast Address

-Non-Broadcast Multi-Access Networks
X.25, Frame Relay, ATM
Five Modes of Operation (Two are Industry Standard)

OSPF has 5 modes of operation over NBMA networks. It depends on what Frame Relay Topology you're going to use. Let's review the topologies:

The most costly but the one with the highest performance and redundancy is the Full Mesh network:

If you only keep the links between important sites meshed, you'd have a Partial Mesh network:

Finally, if you employ a star topology, you'd have a Hub and Spoke network and this is the most common because it's the cheapest to maintain but may have delay problems when it comes to VoIP:

Because there are so many ways you can connect your routers together, you have the flexibility (or complexity) of 5 Frame Relay modes:
-NBMA - RFC Standard
-Point-to-Multipoint - RFC Standard
-Point-to-Point - Cisco Proprietary
-Broadcast - Cisco Proprietary
-Point-to-Multipoint, Non-Broadcast - Cisco Proprietary

You cannot mix modes because they all use different timers.

NBMA mode is the default for X.25, Frame Relay and ATM. NBMA mode is also known as Non-Broadcast Mode. It means that no broadcast and no multicast messages are allowed over the cloud. The neighbors are statically configured and you have to use one subnet over the whole cloud. In Non-Broadcast mode, it is treated as a LAN environment (it assumes Full Mesh which you would need to fix with maps) and DR/BDR is elected and must be the hub.

In NBMA mode, it assumes that all broadcast and multicasts are denied, so you have to manually type in the neighbors. It will use unicast to reach the other routers. The place you define other routers is at the Hub of the network. For this to work properly, any router other than the Hub must have their priority set to 0:
ip ospf priority 0

To add neighbors in OSPF, simply type:
neighbor priority 0

Now we'll implement basic OSPF over NBMA in the following topology:

First of all we're going to set up basic connectivity. To do this, we'll first go on R1 and set:
in s0/0
encap frame
ip add
frame map ip 102 broadcast
frame map ip 103 broadcast
no shut

Next, on R2, we'll set:
in s0/0
encap frame
ip add
frame map ip 201 broadcast
frame map ip 201 broadcast
ip ospf pri 0
no shut

Finally, R3 will have:
in s0/0
encap frame
ip add
frame map ip 301 broadcast
frame map ip 301 broadcast
ip ospf pri 0
no shut

(Much thanks to Candie for spotting the mapping mistake =p That was a bad copy and paste there!)

Notice that for R2 and R3, we have two entries pointing to the same DLCI. This is because NBMA mode assumes full mesh, so you'll need to have connectivity to each other and it's only through R1 that R2 can reach R3.

The broadcast keyword is present to make sure that all broadcast messages destined to that interface will be transmitted to the IP Address and DLCI as a unicast packet.

Now we'll begin setting up the network statements. Only R1 needs to put the neighbor statements:
network area 0
neighbor priority 0
neighbor priority 0

For R2, it would be:
network area 0

Finally, for R3, we'll have:
network area 0

It will take an extremely long time for the neighbors to come up, so be patient! When you type the verification command "show ip ospf nei", it will be stuck at ATTEMPT for a minute or two.

The Point-to-Multipoint mode fixes issues with NBMA networks. In Point-to-Multipoint mode, there is no DR/BDR elected even though it still requires a single subnet. Neighbors automatically form without the need for static configuration. Broadcast and Multicast messages must be allowed across the Frame Relay cloud.

In Point-to-Multipoint mode, you don't have to specify overlapping DLCIs to go to each other. Instead, this would be the configuration of R2:
in s0/0
encap frame
ip add
frame map ip 201 broadcast
ip ospf network point-to-multipoint
no shut

For R3:
in s0/0
encap frame
ip add
frame map ip 301 broadcast
ip ospf network point-to-multipoint
no shut

The timers are still the same as NBMA so you can mix these.

Next, on R1, you would have:
in s0/0
encap frame
ip add
frame map ip 102 broadcast
frame map ip 103 broadcast
ip ospf network point-to-multipoint
no shut

You no longer need to specify neighbors, so R1 just needs one statement in the OSPF context:
network area 0

Now, on R3, you would have these routes: is variably subnetted, 5 subnets, 2 masks
O [110/128] via, 00:02:28, Serial0/0
C is directly connected, Loopback0
O [110/129] via, 00:02:28, Serial0/0
C is directly connected, Serial0/0
O [110/64] via, 00:02:28, Serial0/0

Notice that the routers are automatically discovered and advertised through the OSPF area. The next hop to get to R2 from R3 is now correctly recorded as R1! In a non-sub-interface environment, unless the ISP disallows broadcasts and multicasts, there is no reason why you should use NBMA over Point-to-Multipoint!

To configure Point-to-Multipoint Non-Broadcast mode, you simply have to use "ip ospf network point-to-multipoint non-broadcast". Neighbors will have to be statically specified.

Broadcast mode requires one subnet and full mesh connectivity. It treats the entire topology like a LAN. You would have a DR/BDR election and Multicast messages are used. It is exactly like the LAN environment. You set this with "ip ospf network broadcast".

The final and easiest (logically) mode to configure is the point-to-point mode. It makes the entire NBMA network act like a series of point-to-point links. Each DLCI gets its own sub-interface and requires one subnet each.

To configure this, we'll start on R1:
in s0/0
encap frame
no shut
in s0/0.102 point-to-p
frame interface-dlci 102
ip add
in s0/0.103 point-to-p
ip add
frame interface-dlci 103
router ospf 1
network area 0
network area 0

On R2, we have:
in s0/0
encap frame
no shut
in s0/0.201 point-to-p
frame interface-dlci 201
ip add
router ospf 1
network area 0

Finally, R3 will have:
in s0/0
encap frame
no shut
in s0/0.301 point-to-p
frame interface-dlci 301
ip add
router ospf 1
network area 0

This concludes the 5 modes of OSPF NBMA networks. You survived, really.


Now I'll walk through basic OSPF configuration. To do this, we'll use the following topology (notice I have new Cisco icons. The only other article I used these was at VPN Introduction!):

Now we'll assume that all IP addresses on interfaces are set and the interfaces are all up. We'll now begin configuration on R1.

First, we'll go into the OSPF process using:
router ospf 1

Next, we'll enable OSPF on its LAN interface:
network area 0

This is similar to flicking an ON switch on any interface starting with 172.16.1.x.

Since R1's interface is, we can actually be more specific by using:
network area 0

If you recall, typing "area 0" actually makes R1 a Backbone router. We'll now set up the Serial Link to be in Area 0 as well:
network area 0

In newer routers, we can use the interface command to add the interface to the OSPF process like this:
in s0/0
ip ospf 1 area 0

This is the only way we can use to add IPv6 interface to OSPF.

To check the router's Router ID, use:
show ip ospf

Alternately, you can use:
show ip prot

Notice that R1 is the DR for the network, and is the DR for the Serial interface as well.

Now, hop over to R2 and before we'll start configuration we can turn on the debugging for OSPF to see how the neighbors are formed:
debug ip ospf adj
debug ip ospf events

Now lets enable the process on the network:
router ospf 1
network area 0

You'll immediately start seeing a Hello packet being sent, and you'll continue seeing it every 10 seconds.

Now, for the good part, we'll enable OSPF on the Serial link as well. This will start the neighbor forming between R1 and R2 over the Serial Link:
network area 0

Below is a typical output:
*Mar  1 00:12:22.083: OSPF: Interface Serial0/0 going Up
*Mar  1 00:12:22.087: OSPF: Send hello to area 0 on Serial0/0 from
*Mar  1 00:12:22.299: OSPF: Rcv hello from area 0 from Serial0/0
*Mar  1 00:12:22.303: OSPF: Send immediate hello to nbr, src address, on Serial0/0
*Mar  1 00:12:22.307: OSPF: Send hello to area 0 on Serial0/0 from
*Mar  1 00:12:22.311: OSPF: End of hello processing
*Mar  1 00:12:22.335: OSPF: Rcv DBD from on Serial0/0 seq 0x14E9 opt 0x52 flag 0x7 len 32  mtu 1500 state INIT
*Mar  1 00:12:22.335: OSPF: 2 Way Communication to on Serial0/0, state 2WAY
*Mar  1 00:12:22.339: OSPF: Send DBD to on Serial0/0 seq 0xA33 opt 0x52 flag 0x7 len 32
*Mar  1 00:12:22.343: OSPF: NBR Negotiation Done. We are the SLAVE
*Mar  1 00:12:22.347: OSPF: Send DBD to on Serial0/0 seq 0x14E9 opt 0x52 flag 0x2 len 72
*Mar  1 00:12:22.363: OSPF: Rcv hello from area 0 from Serial0/0
*Mar  1 00:12:22.367: OSPF: End of hello processing
*Mar  1 00:12:22.387: OSPF: Rcv DBD from on Serial0/0 seq 0x14EA opt 0x52 flag 0x3 len 72  mtu 1500 state EXCHANGE
*Mar  1 00:12:22.395: OSPF: Send DBD to on Serial0/0 seq 0x14EA opt 0x52 flag 0x0 len 32
*Mar  1 00:12:22.423: OSPF: Rcv DBD from on Serial0/0 seq 0x14EB opt 0x52 flag 0x1 len 32  mtu 1500 state EXCHANGE
*Mar  1 00:12:22.423: OSPF: Exchange Done with on Serial0/0
*Mar  1 00:12:22.423: OSPF: Send LS REQ to length 12 LSA count 1
*Mar  1 00:12:22.427: OSPF: Send DBD to on Serial0/0 seq 0x14EB opt 0x52 flag 0x0 len 32
*Mar  1 00:12:22.427: OSPF: Rcv LS REQ from on Serial0/0 length 36 LSA count 1
*Mar  1 00:12:22.427: OSPF: Send UPD to on Serial0/0 length 40 LSA count 1
*Mar  1 00:12:22.431: OSPF: Rcv LS UPD from on Serial0/0 length 64 LSA count 1
*Mar  1 00:12:22.431: OSPF: Synchronized with on Serial0/0, state FULL
*Mar  1 00:12:22.435: %OSPF-5-ADJCHG: Process 1, Nbr on Serial0/0 from LOADING to FULL, Loading Done
*Mar  1 00:12:22.595: OSPF: Build router LSA for area 0, router ID, seq 0x80000006, process 1
*Mar  1 00:12:22.775: OSPF: Rcv LS UPD from on Serial0/0 length 88 LSA count 1

Notice that the IP addresses shown are actually the Router ID. Now, to look inside the Neighbor Table, type:
show ip ospf nei

Notice that on the Serial Link, nobody's the DR or BDR, and it's denoted by a hyphen:
Neighbor ID     Pri   State           Dead Time   Address         Interface        0   FULL/  -        00:00:35        Serial0/0

Now, we'll begin setting up R3 and R4. Once we have all R3 and R4 running in the same fashion, without changing the priority or the Router ID, who do you think would be the DR and BDR for the network?

If you guessed R4 and then R3, you are correct! Since Priority is the same, the highest Router ID would win. Since we have no Loopback interfaces, the Router ID would be the Fast Ethernet interface:
Neighbor ID     Pri   State           Dead Time   Address         Interface        0   FULL/  -        00:00:35        Serial0/0        0   FULL/  DR       00:00:35      FastEthernet0/0        0   FULL/  BDR      00:00:35      FastEthernet0/0

If you still have the debugging turned on, this is what you'll see in the flurry of messages:
*Mar  1 00:19:28.259: OSPF: DR/BDR election on FastEthernet0/0
*Mar  1 00:19:28.263: OSPF: Elect BDR
*Mar  1 00:19:28.263: OSPF: Elect DR
*Mar  1 00:19:28.267: OSPF: Elect BDR
*Mar  1 00:19:28.267: OSPF: Elect DR
*Mar  1 00:19:28.267:        DR: (Id)   BDR: (Id)

On the other routers, you would see R2 labeled as a DROTHER.

Now we'll go through two ways to change the Router ID. Back on R1, create a Loopback interface as shown:
in lo0
ip add

This is the official definition for the Router ID:
"The OSPF router ID is a 32-bit IP address selected at the start of the OSPF process. The highest IP address configured on the router is the router ID. If a loopback address is configured, it is the router ID. In the case of multiple loopback addresses, the highest loopback address is the router ID. Once the router ID is elected, it does not change until OSPF restarts or is manually changed with the [router-id] command under [the OSPF context]."

At this point, the Router ID would still not change if you check it with:
show ip ospf

To make the changes apply, you'll need to use:
clear ip ospf proc

If it doesn't change, you may have to reset the whole system:

Another way to change the Router ID is simply using the command:

The recommended way is the router-id command because it is important for advanced features like Virtual Link and you wouldn't want it to change by chance. As usual, you would have to clear the OSPF process.

Another way to influence DR/BDR election is to use the "priority" command under the interface:
in f0/0
ip ospf priority 2

A router with the priority of 0 will exempt it from election. You would have to clear the process of the existing DR and BDR after changing the priority of any router because it does not do preemption.

Now that we're done with the basic concepts, we'll go through some basic verification commands:

To check the timers being used, we can use:
show ip ospf int

To check the topology table, we can use:
show ip ospf database

In the topology table, we can check the age (in seconds) and the sequence number (a 4-byte-value) which increases every update. Once the sequence number reaches 0x8fffffff, it will notify neighbors with a special process and it starts from 0 again.

To check the neighbor table, we can use:
show ip ospf nei