Use kubectl describe to gather information
When troubleshooting Kubernetes pods, the first step is to gather as much information as possible. The kubectl describe command is an invaluable tool for this task. This command provides detailed information about the state of a particular pod, including its current status, any events that have occurred, and any containers that are running within the pod.

To use the kubectl describe command, simply run the following command:

kubectl describe pod 

This will provide you with a wealth of information about the current state of the pod, including any error messages that may be present.

Check the logs
The next step in troubleshooting Kubernetes pods is to check the logs of the container running within the pod. Kubernetes provides a centralized logging system that allows developers to access logs from all containers within a cluster.

To view the logs of a particular container, you can use the kubectl logs command. For example, to view the logs of the container running within a pod named my-pod, you can run the following command:

kubectl logs my-pod 

This will display the logs of the specified container, allowing you to identify any issues that may be present.

Check resource allocation
Kubernetes allows developers to allocate resources to individual pods, including CPU and memory. If a pod is experiencing issues, it’s important to check the resource allocation to ensure that the pod has enough resources to operate correctly.

To check the resource allocation of a particular pod, you can use the kubectl top command. This command provides real-time information about the CPU and memory usage of each pod within a cluster.

For example, to view the resource allocation of a pod named my-pod, you can run the following command:

kubectl top pod my-pod

This will display the CPU and memory usage of the specified pod, allowing you to identify any resource allocation issues.

Check network connectivity
Finally, it’s important to check the network connectivity of a pod if it’s experiencing issues. Kubernetes provides several networking options, including service discovery and load balancing, that can be used to ensure that pods can communicate with each other.

To check the network connectivity of a pod, you can use the kubectl exec command to execute commands within the pod’s container. For example, to check the network connectivity of a pod named my-pod, you can run the following command:

kubectl exec my-pod -- curl http://<service-name>

This will execute the curl command within the specified container, allowing you to check the connectivity of the pod.

In conclusion, Kubernetes is a powerful platform for managing containerized applications, but troubleshooting individual pods can be challenging. By following these best practices, developers can quickly and efficiently troubleshoot Kubernetes pods, ensuring that their applications are running smoothly and without interruption.

Based on the guideline above, let us walk through the steps;

Everyone wants a healthy Pod. Your applications rely on a healthy Pod state for successful delivery of services for consumers. Just as life has its challenges, sometimes you may experience issues with your pods which could put them in any of these states.

Pending: Pods can be in a pending state if there are insufficient resources in the cluster to schedule the pod, or if there is a scheduling issue due to resource constraints, node affinity/anti-affinity, or pod affinity/anti-affinity.

CrashLoopBackOff: Pods can be in a CrashLoopBackOff state if the container in the pod is crashing repeatedly. This can be due to issues with the container image, configuration, dependencies, or resources.

Error: Pods can be in an Error state if there is an issue with the pod’s configuration or if the container is unable to start or run due to issues with the container image, configuration, or dependencies.

Check pod status: The first step in troubleshooting Kubernetes pods is to check the pod status. You can use the kubectl get pods command to view the status of all pods in a given namespace. If a pod is in a Pending, CrashLoopBackOff, or Error state, it indicates that there is an issue that needs to be resolved.

kubectl get pods

# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
nginx-585449566-4rqvm   1/1     Running   0          59s

Check container logs: Once you have identified the pod with issues, the next step is to check the container logs. You can use the kubectl logs command to view the logs of a specific container in a pod. This can help you identify any errors or issues that the container is encountering.

kubectl logs 

# kubectl logs nginx-585449566-4rqvm
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2023/03/06 11:04:49 [notice] 1#1: using the "epoll" event method
2023/03/06 11:04:49 [notice] 1#1: nginx/1.23.3
2023/03/06 11:04:49 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 
2023/03/06 11:04:49 [notice] 1#1: OS: Linux 5.15.0-56-generic
2023/03/06 11:04:49 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2023/03/06 11:04:49 [notice] 1#1: start worker processes
2023/03/06 11:04:49 [notice] 1#1: start worker process 29
2023/03/06 11:04:49 [notice] 1#1: start worker process 30
# 

Check container configuration: If the container logs do not provide any clues, the next step is to check the container configuration. You can use the kubectl describe pod command to view the pod configuration, including container image, environment variables, and resource limits. Make sure that the container configuration is correct and that all required resources are available.

kubectl describe pod  

Name:             nginx-585449566-4rqvm
Namespace:        default
Priority:         0
Service Account:  default
Node:             vectra-worker2/172.18.0.2
Start Time:       Mon, 06 Mar 2023 11:04:30 +0000
Labels:           app=nginx
                  pod-template-hash=585449566
Annotations:      
Status:           Running
IP:               10.244.2.2
IPs:
  IP:           10.244.2.2
Controlled By:  ReplicaSet/nginx-585449566
Containers:
  nginx:
    Container ID:   containerd://470ecc0771e2fd3a828e228016677c1084792d8a26ad9d100337d9dcc6086597
    Image:          nginx:latest
    Image ID:       docker.io/library/nginx@sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce1d4b4f55a5c2ef2
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 06 Mar 2023 11:04:48 +0000
    Ready:          True
    Restart Count:  0
    Environment:    
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-6h4xk (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-6h4xk:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  8m24s  default-scheduler  Successfully assigned default/nginx-585449566-4rqvm to vectra-worker2
  Normal  Pulling    8m24s  kubelet            Pulling image "nginx:latest"
  Normal  Pulled     8m7s   kubelet            Successfully pulled image "nginx:latest" in 17.21068267s
  Normal  Created    8m7s   kubelet            Created container nginx
  Normal  Started    8m7s   kubelet            Started container nginx
# 

Check cluster events: If the container configuration looks correct, the next step is to check the cluster events. You can use the kubectl get events command to view the events in the cluster. This can help you identify any issues or changes in the cluster that may be affecting the pod.

kubectl get events

LAST SEEN   TYPE      REASON                    OBJECT                       MESSAGE
13m         Normal    Scheduled                 pod/nginx-585449566-4rqvm    Successfully assigned default/nginx-585449566-4rqvm to vectra-worker2
13m         Normal    Pulling                   pod/nginx-585449566-4rqvm    Pulling image "nginx:latest"
13m         Normal    Pulled                    pod/nginx-585449566-4rqvm    Successfully pulled image "nginx:latest" in 17.21068267s
13m         Normal    Created                   pod/nginx-585449566-4rqvm    Created container nginx
13m         Normal    Started                   pod/nginx-585449566-4rqvm    Started container nginx
13m         Normal    SuccessfulCreate          replicaset/nginx-585449566   Created pod: nginx-585449566-4rqvm
13m         Normal    ScalingReplicaSet         deployment/nginx             Scaled up replica set nginx-585449566 to 1
18m         Normal    Starting                  node/vectra-control-plane    Starting kubelet.
18m         Normal    NodeHasSufficientMemory   node/vectra-control-plane    Node vectra-control-plane status is now: NodeHasSufficientMemory
18m         Normal    NodeHasNoDiskPressure     node/vectra-control-plane    Node vectra-control-plane status is now: NodeHasNoDiskPressure
18m         Normal    NodeHasSufficientPID      node/vectra-control-plane    Node vectra-control-plane status is now: NodeHasSufficientPID
18m         Normal    NodeAllocatableEnforced   node/vectra-control-plane    Updated Node Allocatable limit across pods
17m         Normal    Starting                  node/vectra-control-plane    Starting kube-proxy.
17m         Normal    RegisteredNode            node/vectra-control-plane    Node vectra-control-plane event: Registered Node vectra-control-plane in Controller
18m         Normal    Starting                  node/vectra-worker           Starting kubelet.
17m         Normal    NodeHasSufficientMemory   node/vectra-worker           Node vectra-worker status is now: NodeHasSufficientMemory
17m         Normal    NodeHasNoDiskPressure     node/vectra-worker           Node vectra-worker status is now: NodeHasNoDiskPressure
17m         Normal    NodeHasSufficientPID      node/vectra-worker           Node vectra-worker status is now: NodeHasSufficientPID
18m         Normal    NodeAllocatableEnforced   node/vectra-worker           Updated Node Allocatable limit across pods
17m         Warning   Rebooted                  node/vectra-worker           Node vectra-worker has been rebooted, boot id: fd9ad342-d276-46dd-a64e-c852092e755b
17m         Normal    Starting                  node/vectra-worker           Starting kube-proxy.
17m         Normal    RegisteredNode            node/vectra-worker           Node vectra-worker event: Registered Node vectra-worker in Controller
18m         Normal    Starting                  node/vectra-worker2          Starting kubelet.
17m         Normal    NodeHasSufficientMemory   node/vectra-worker2          Node vectra-worker2 status is now: NodeHasSufficientMemory
17m         Normal    NodeHasNoDiskPressure     node/vectra-worker2          Node vectra-worker2 status is now: NodeHasNoDiskPressure
17m         Normal    NodeHasSufficientPID      node/vectra-worker2          Node vectra-worker2 status is now: NodeHasSufficientPID
18m         Normal    NodeAllocatableEnforced   node/vectra-worker2          Updated Node Allocatable limit across pods
17m         Warning   Rebooted                  node/vectra-worker2          Node vectra-worker2 has been rebooted, boot id: fd9ad342-d276-46dd-a64e-c852092e755b
17m         Normal    Starting                  node/vectra-worker2          Starting kube-proxy.
17m         Normal    RegisteredNode            node/vectra-worker2          Node vectra-worker2 event: Registered Node vectra-worker2 in Controller

Check network connectivity: If the pod is still experiencing issues, it may be a network connectivity issue. You can use the kubectl exec -it — /bin/bash command to access the pod shell and perform network connectivity tests. For example, you can use ping to test connectivity to other pods or services.

kubectl exec -it  -- bash

# kubectl exec -it nginx-585449566-h8htf bash

nginx-585449566-h8htf:/# ls -al
total 88
drwxr-xr-x   1 root root 4096 Mar  6 11:52 .
drwxr-xr-x   1 root root 4096 Mar  6 11:52 ..
drwxr-xr-x   2 root root 4096 Feb 27 00:00 bin
drwxr-xr-x   2 root root 4096 Dec  9 19:15 boot
drwxr-xr-x   5 root root  360 Mar  6 11:52 dev
drwxr-xr-x   1 root root 4096 Mar  1 18:43 docker-entrypoint.d
-rwxrwxr-x   1 root root 1616 Mar  1 18:42 docker-entrypoint.sh
drwxr-xr-x   1 root root 4096 Mar  6 11:52 etc
drwxr-xr-x   2 root root 4096 Dec  9 19:15 home
drwxr-xr-x   1 root root 4096 Feb 27 00:00 lib
drwxr-xr-x   2 root root 4096 Feb 27 00:00 lib64
drwxr-xr-x   2 root root 4096 Feb 27 00:00 media
drwxr-xr-x   2 root root 4096 Feb 27 00:00 mnt
drwxr-xr-x   2 root root 4096 Feb 27 00:00 opt
dr-xr-xr-x 432 root root    0 Mar  6 11:52 proc
drwx------   1 root root 4096 Mar  6 11:57 root
drwxr-xr-x   1 root root 4096 Mar  6 11:52 run
drwxr-xr-x   2 root root 4096 Feb 27 00:00 sbin
drwxr-xr-x   2 root root 4096 Feb 27 00:00 srv
dr-xr-xr-x  13 root root    0 Mar  6 11:52 sys
drwxrwxrwt   1 root root 4096 Mar  1 18:43 tmp
drwxr-xr-x   1 root root 4096 Feb 27 00:00 usr
drwxr-xr-x   1 root root 4096 Feb 27 00:00 var

Check storage: Finally, if the pod is using storage, make sure that the storage is correctly mounted and accessible by the container. You can use the kubectl describe pod command to view the pod’s volume mounts and their associated storage classes.

kubectl describe pod 

# kubectl describe pod nginx-585449566-4rqvm
Name:             nginx-585449566-4rqvm
Namespace:        default
Priority:         0
Service Account:  default
Node:             vectra-worker2/172.18.0.2
Start Time:       Mon, 06 Mar 2023 11:04:30 +0000
Labels:           app=nginx
                  pod-template-hash=585449566
Annotations:      
Status:           Running
IP:               10.244.2.2
IPs:
  IP:           10.244.2.2
Controlled By:  ReplicaSet/nginx-585449566
Containers:
  nginx:
    Container ID:   containerd://470ecc0771e2fd3a828e228016677c1084792d8a26ad9d100337d9dcc6086597
    Image:          nginx:latest
    Image ID:       docker.io/library/nginx@sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce1d4b4f55a5c2ef2
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 06 Mar 2023 11:04:48 +0000
    Ready:          True
    Restart Count:  0
    Environment:    
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-6h4xk (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  kube-api-access-6h4xk:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  29m   default-scheduler  Successfully assigned default/nginx-585449566-4rqvm to vectra-worker2
  Normal  Pulling    29m   kubelet            Pulling image "nginx:latest"
  Normal  Pulled     28m   kubelet            Successfully pulled image "nginx:latest" in 17.21068267s
  Normal  Created    28m   kubelet            Created container nginx
  Normal  Started    28m   kubelet            Started container nginx
# 

By following these steps, you should be able to identify and resolve most issues with Kubernetes pods.

I love dashboards, yes the likes that gives me useful information, and bless God that Azure has such dashboards in place with rich detail that helps you the engineer to truly know what is happening on your network.

Deployment in an Azure Region showing Benign and Malicious traffic from different Regions

So here is the whole story. I had a project to deploy a new infrastructure which I gladly did in Terraform. There are a set of practices where cloud infrastructure is concerned. Spinning up virtual machines or instances is only a piece of the story.
NSGs as we call them have the ability to show you a great deal of information which by default is not enabled until certain pieces of configuration are set in place.

To test access to the virtual machine, I had created a Public IP and attached to the Network Interface of the Virtual Machine temporarily.

I had created a Public IP and attached to the Network Interface of the Virtual Machine temporarily.

Most problems originate from temporary rules, configurations in the name of tests. I had forgotten to test and also to remove the rule. This is the reason why it is of utmost importance to enable NSG Flow Logs and also to keep an eye on your Network Watcher. Never assume full protection until you have worked to attain it.

Create NSG Flow Logs to Capture Traffic Flows into NSG on Azure

Download Sample Script to Check for Malicious Traffic

AzureNetworkAnalytics_CL
| where SubType_s == 'FlowLog'
    and (FASchemaVersion_s == '1' or FASchemaVersion_s == '2')
    and FlowStartTime_t between (datetime('2022-06-03T04:44:29.994Z') .. datetime('2022-06-04T04:44:29.994Z'))

Figure 1.0 – Showing Malicious Traffic to Ports 22

Deployment in an Azure Region showing allowed Malicious Traffic

Identifying Source of Attacks

Checked the NSG for allowed Inbound Rules – SSH Inbound Was to Blame

Use Azure CLI to query this information – Include the Default Azure NSG Rules

az network nsg rule list --include-default --resource-group  --nsg-name 

Check Malicious Traffic Flows

What I did to mitigate this security failure.

1. Removed offending SSH rule on the NSG
2. Removed the Public IP

Network security group security rules are evaluated by priority using the combination of source, source port, destination, destination port, and protocol to allow or deny the traffic. A security rules can’t have the same priority and direction as an existing rule. You can’t delete default security rules, but you can override them with rules that have a higher priority.

Check Inbound Security Rules and delete the offending SSH Inbound Rule

Disassociate and Delete the Public IP attached to a Virtual Machine Network Interface

These articles are extremely useful;
Enable Azure Network Watcher
Traffic Analytics – frequently asked questions

Download GNS3 Lab | How to Troubleshoot DHCP Misconfigurations Step by Step

How to Troubleshoot DHCP Misconfigurations Step by Step

===============================================
DHCP Server Configuration
===============================================
ip dhcp excluded-address 172.16.1.1 172.16.1.50
ip dhcp excluded-address 172.16.3.200 172.16.3.254

================================================
DHCP Pool for VLAN 1
================================================
ip dhcp pool Subnet-1610
network 172.16.1.0 255.255.255.0
dns-server 172.16.2.14
default-router 172.16.1.1
domain-name subnetone.com
lease 0 20 30

================================================
DHCP Pool for VLAN 2
================================================
ip dhcp pool Subnet-1630
network 172.16.3.0 255.255.255.128
dns-server 172.16.2.14
default-router 172.16.3.254
lease 1 5 7

================================================
Router 1 – Relay Agent Configuration
================================================

Relay Agent
interface FastEthernet0/1
description “Downlink to Edge Network”
ip address 172.16.1.1 255.255.255.0
ip helper-address 172.16.2.14

===============================================================
Configured Subinterface Gateway for VLAN 2 Subnet 172.16.3.0/24
===============================================================
interface FastEthernet0/1.1
encapsulation dot1Q 2
ip address 172.16.3.254 255.255.255.0
ip helper-address 172.16.2.14

==============================================================
Layer 2 Access Switch Configuration
==============================================================

Trunk Interface
interface FastEthernet1/0
switchport mode trunk

VLAN 1 Member Interface
interface FastEthernet1/1
switchport access vlan 1

VLAN 2 Member Interface – Mr Banks PC2
interface FastEthernet1/2
switchport access vlan 2

===============================================================
Troubleshooting Steps
===============================================================

Check Connectivity States on the Physical Layer
Check Interface State -PC2 Interface up?
Show IP Configuration and VLAN States–
Check DHCP Server Connectivity
Check Gateway Interface Up State

=========================================
Compare with Working System
=========================================
Check if PC1 can get an IP Address

=========================================
Connect another PC to VLAN 2
=========================================
Swap PC2 for another PC to see if it works.

How did I fix the dhcp misconfiguration which made PC2 unable to get an IP Address?

How to Troubleshoot DHCP Misconfigurations Step by Step

The solution was in changing the network command under the DHCP Pool Subnet-1630. Previously, the network engineer had configured the DHCP Pool as follows;

network 172.16.3.0 255.255.255.128

Now the gateway for VLAN 2 is 172.16.3.254 – Here is the problem! 172.16.3.254 is in another scope and not the 172.16.3.0/25 which has valid hosts from 1 to 126. In order to fix this, I had to make sure that the network subnet mask covered the gateway address where VLAN 2 workstations are attached.

network 172.16.3.0 255.255.255.0

Modify the DHCP Pool to reflect the changes.

ip dhcp pool Subnet-1630
no network 172.16.3.0 255.255.255.128
 network 172.16.3.0 255.255.255.0
dns-server 172.16.2.14 
default-router 172.16.3.254 
lease 1 5 7
!

Verifying and Troubleshooting DHCP Configuration
Router#show ip dhcp binding
Displays a list of all bindings created.

Router#show ip dhcp binding w . x . y . z
Displays the bindings for a specific DHCP client with an IP address of w.x.y.z.

Router#clear ip dhcp binding a . b . c . d
Clears an automatic address binding from the DHCP server database.

Router#clear ip dhcp binding *
Clears all automatic DHCP bindings.

Router#show ip dhcp conflict
Displays a list of all address conflicts recorded by the DHCP server.

Router#clear ip dhcp conflict a.b.c.d
Clears address conflict from the database.

Router#clear ip dhcp conflict *
Clears conflicts for all addresses.

Router#show ip dhcp database
Displays recent activity on the DHCP database.

Router#show ip dhcp server statistics
Displays a list of the number of messages sent and received by the DHCP server.

Router#clear ip dhcp server statistics
Resets all DHCP server counters to 0.

Router#debug ip dhcp server {events | packets | linkage | class }
Displays the DHCP process of addresses being leased and returned.

Related Articles:

Cisco has a good resource on DHCP Configuration.

How to Configure IP Helper on a Cisco Switch for multiple VLANS

Have you been faced with a task laced with many prefixes you find intimidating? Well, you are in the right place at the right time to improve your understanding of subnetting once and for all.

You can read more on the subject broadly from Cisco’s website here.

Step by step guide to IP Subnetting Video

Below is a simple 6 step by step method I use to perform subnetting calculations.

Let us look at this question below;

1: You have been given an IP Address 10.20.4.13/29 and been asked to find out the following pieces;

1. Subnet Address
2. First Valid Host Address
3. Last Valid Host Address
4. Broadcast Address
5. Subnet Mask

How to Calculate Subnet Mask from IP Address Step by Step

Step 1: Find Subnet Number
Subtract Prefix Number from /32
32-29=3

Calculate Subnet Mask
8 Bits – 3 Bits = 5 Bits(Network Bits Turned On)

You might be asking why 8 Bits, 8 Bits are required for each octet.

Step 2: Find Subnet Size
Raise 2 to the power of deduction (8-3 =5 Bits). Let’s call the bits n!
2**n = Subnet Size
2**5 = Subnet Sizes for each subnet.
2*2*2 = 8

Note: 8 is the block size for the subnet so for example, the increments will now be 0 8 16 32 40 and so on!

Step 3: Find Broadcast Address
Subnet Size – 1
(2**n) – 1 = Broadcast Address
(2**3) – 1 = (8-1) = 7

Step 4: Locate IP Address Subnet
Identify Subnet Block for IP Address:
Where in each increment is the address 10.20.4.13/29 located 0 8 16 32 40?

13 falls between 8 and 16 and therefore the address is in the valid host range of the subnet 10.20.4.8/29

Step 5: Calculate Valid Hosts | How to calculate number of hosts in the subnet
2**n – 2 = Valid Host Range
2**3 – 2 = (8-2) = 6

Answer for question now is as follows;

Subnet Address: 10.20.4.8/29
Min Host Address: 10.20.4.9/29
Max Host Address: 10.20.4.14/29
Broadcast Address: 10.20.4.15/29

There you have it. A simple 6 step by step guide to subnetting effectively.

Related Posts:

How to connect GNS3 to a Physical Network Step by Step

OSPF Fundamentals

This is a routing protocol you would have been introduced to in your CCNA studies.
OSPF is a link state routing protocol as opposed to EIGRP as a distance routing protocol open standard from the IETF. OSPF can establish adjacencies with other routers. These adjacencies is what allows the routers to send link state updates between one another. OSPF routers sends link state advertisements(LSAs) to other routers in an area. OSPF routers recieves LSAs and is able to construct a link state database from them.
The routers runs the Dijkstra Shortest Path First(SFP) algorithm to determine the shortest path to a network. OSPF attempts to inject the best path for each network into a router’s IP routing table.

Video: The Ultimate Guide to Understanding and Configuring OSPF

OSPF Neighbor Formation

Neighborship vs Adjacency
Although these terms are often used interchangeably, there is a technical distinction that must be clarified elaborately to contrast their differences.

Figure 1.0 – The Ultimate OSPF Configuration Guide

Neighbors are routers that:
Reside on the same network link (meaning that the routers are connected via a switch and able to speak within a subnet)
Exchange Hello messages. These routers residing on the same link exchange Hello Messages by sending Hellos to a Destination OSPF Routers Multicast address 224.0.0.5. This ability to exchange Hellos in itself is able to form neighborship although no
Link State Advertisements have been exchanged by these Neighbors, the truth is that they do not necessarily do that.

Adjacencies are routers that:

1. Are Neighbors
2. Exchange Links State Updates.

let us look at these states:

• State 1: Link Down
• State 2: Link Comes Up
• State 3: Init (Router 2 receive a Hello from Router 2 and recognises that its own Route ID is not in the received Hello message list of Routers known to Router 1.
• Router 2 realises that the Hello is from a Neighbor). At this state, it also sends a Hello to Router 1 which also checks the Hello and recognises its Router ID and realises it has been listed as a Neighbor.
• State 4: Since Router 1 has recognised a Neighbor, it transitions to a 2-WAY State. It now sends a Hello message back to Router 2 and upon receipt of this Hello message, Router 2 recognises its own Router ID listed as a Neighbor and as a result, Router 2 goes into a 2-Way State.
• Stage 5: At this stage both routers are in the 2-Way State and therefore where needed a DR/BDR Election takes place. DR means Designated Router and BDR means Backup Designated Router. Some OSFP types do not require this election process.
• State 6: At this ExStart stage the Primary and Secondary Routers are selected.
• Stage 7: At this Exchange state the Database Description Packets are Exchanged. These are exchange between the primary and secondary routers. The Database Description Packet is a list of LSAs known to the router which sends it.
• Stage 8: At this Loading state the Routers Query One Another (Using LSRs) Link State Requests for Missing Entries (sent in Link State Update Packet).
• Stage 9: At the Full state, the Routers have fully formed adjacency.

Figure 1.0 – Link States in a Typical OSPF Neighborship

OSPF Areas

When setting up an OSPF network, one of the things to configure is an Area assignment.
OSPF uses the concept of areas to carve up a network. We could just do with a single area. The Dijsktra SPF will be ran against the area. But for scalabilty reasosn, many coporate networks like to design very large networks with multiple areas. In such designs, the dijsktra SPF is run against each Area which in effect reduces computational load on the routers responsible to running the large dijsktra algorithm.
In a multiarea topology, there has to be a Backbone Area, and this is normally called a backbone area or Area 0. I almost said Area 51, but that is all the way in Mexico so let’s stick with Area 0. The backbone area typically numbered 0 or decimal as 0.0.0.0 is the area which all other areas directly connect. In simple terms, you cannot have Area 1 and 2 without an Area 0. Every design starts with Area 0.

MultiArea OSPF Design

KeyPhrase: In a Multiple Area Design, the Dijkstra Algorithm runs on the Link State Database for each area.

As you can see from Figure 1.1, all the areas are connected to Area 0. To be able to do this, each area will need to be touching Area 0. So looking at Figure 1.1 again, we can identify two Routers, Router3 and Router7 where each of these have interfaces belonging to the Backbone Area and their home areas. Router 3 has an interface in Area 1 as well as Area 0.

Quick question to you, Which areas does Router 7 have interfaces connecting to?

The Routers in Area 0 for example does not need to know of every interlink between routers in Area 1 but must know how to get to that Area 1 subnet and which router to use as the gateway or route to that Area. When the topology is too big, it is only a better idea to break them down into areas which will make computational processor much more efficient. This is true for systems where older router technology was used as today’s routers are more powerful and so a multi area ospf topology not needed.
But what helps is the fact that since OSPF is supported by many vendors, you could decide to put that vendor party in a dedicated OSPF Area for performance reasons.

The Single Area design works well and mostly used by many enterprises.

In a situation where the areas are not directly touching Area 0, although not recommended by Cisco, a Virtual Link can be used to create the connection to Area 0 for Area 2 in Figure 1.2

R7 has a Virtual Link transiting Area 1 into Area 0 and likewise, R3 transits Area 1 to get into Area 2.

A Virtual Link is a logical link that interconnects the backbone area with an area that is not adjacent to the backbone area. The Virtual link makes it appear that Area 2 is connected to the Backbone Area also known as Area 0 or 0.0.0.0.

Basic OSPF Configuration Example

Allow me to let you in on a big secret. When it comes to configuring Routing Protocols, plan well before jumping into configuring. I have created the table below as a good guide to help you configure OSPF anywhere with ease. Yes, I know, thank me later!

The table below identifies the areas and the routers and their interfaces as well as subnets belonging to the relevant areas.

Figure 1.3 – Identify Subnets and Interfaces Belonging to the OSPF Areas (Click on Image to Zoom In)

Figure 1.4 – Identified Interfaces on Routers and their Subnets

Let’s dive straight into configuring OSPF on all Routers.

On Router 1

R1#show run | begin router ospf
!
router ospf 1
network 1.1.1.1 0.0.0.0 area 1
network 10.0.0.0 0.0.0.255 area 1
network 192.168.1.0 0.0.0.255 area 1
!

On Router 2

R2-ABR#show run | begin router ospf
router ospf 1
network 2.2.2.2 0.0.0.0 area 1
network 192.168.0.0 0.0.0.3 area 0
network 192.168.0.4 0.0.0.3 area 0
!

Configuring OSPF for an Interface

This is another method in getting an interface to participate in the OSPF Process- By issuing the command on the interface directly.

R2-ABR#show run int f0/0
Building configuration...

Current configuration : 111 bytes
!
interface FastEthernet0/0
 ip address 10.0.0.2 255.255.255.0
 ip ospf 1 area 1

On Router 3
Let us configure OSPF on this router in a different way, Instead of specifying the subnets, let us be generic by telling OSPF that every active upstate interface must become part of the OSPF Process by issuing the command network 0.0.0.0 255.255.255.255 area 0

R3#show run | begin router ospf
router ospf 1
network 0.0.0.0 255.255.255.255 area 0
!

On Router 4

R4#show run | begin router ospf
router ospf 1
network 172.16.2.0 0.0.0.255 area 0
network 192.168.0.4 0.0.0.3 area 0
network 192.168.0.8 0.0.0.3 area 0

Can we now see the OSPF routes?

R2-ABR#show ip route  ospf

     1.0.0.0/32 is subnetted, 1 subnets
O       1.1.1.1 [110/11] via 10.0.0.1, 00:16:27, FastEthernet0/0
     3.0.0.0/32 is subnetted, 1 subnets

O       3.3.3.3 [110/65] via 192.168.0.2, 00:17:02, Serial0/0
     172.16.0.0/24 is subnetted, 2 subnets

O       172.16.1.0 [110/74] via 192.168.0.2, 00:17:02, Serial0/0
O       172.16.2.0 [110/74] via 192.168.0.6, 00:17:02, Serial0/1
     192.168.0.0/30 is subnetted, 3 subnets

O       192.168.0.8 [110/128] via 192.168.0.6, 00:17:02, Serial0/1
                    [110/128] via 192.168.0.2, 00:17:02, Serial0/0
O    192.168.1.0/24 [110/20] via 10.0.0.1, 00:16:27, FastEthernet0/0

OSPF Verification

Let’s perform a verification of OSPF on Router 2 as it’s an Area Border Router and will have knowledge of the InterArea Routes.

R2-ABR#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Se0/1        1     0               192.168.0.5/30     64    P2P   1/1
Se0/0        1     0               192.168.0.1/30     64    P2P   1/1
Lo0          1     1               2.2.2.2/32         1     LOOP  0/0
Fa0/0        1     1               10.0.0.2/24        10    DR    1/1

Neighbor ID     Pri   State           Dead Time   Address         Interface
4.4.4.4           0   FULL/  -        00:00:31    192.168.0.6     Serial0/1
3.3.3.3           0   FULL/  -        00:00:31    192.168.0.2     Serial0/0
1.1.1.1           1   FULL/BDR        00:00:30    10.0.0.1        FastEthernet0/0

R2-ABR#show ip protocols
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 2.2.2.2
  It is an area border router
  Number of areas in this router is 2. 2 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    2.2.2.2 0.0.0.0 area 1
    192.168.0.0 0.0.0.3 area 0
    192.168.0.4 0.0.0.3 area 0
  Routing on Interfaces Configured Explicitly (Area 1):
    FastEthernet0/0
 Reference bandwidth unit is 100 mbps
  Routing Information Sources:
    Gateway         Distance      Last Update
    1.1.1.1              110      00:20:20
    4.4.4.4              110      00:20:56
    3.3.3.3              110      00:20:56
  Distance: (default is 110)

R2-ABR#show ip ospf database

            OSPF Router with ID (2.2.2.2) (Process ID 1)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
2.2.2.2         2.2.2.2         1368        0x80000002 0x00CE5F 4
3.3.3.3         3.3.3.3         1367        0x80000002 0x002FFD 6
4.4.4.4         4.4.4.4         1366        0x80000002 0x002616 5

                Summary Net Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum
1.1.1.1         2.2.2.2         1325        0x80000001 0x008D98
2.2.2.2         2.2.2.2         1370        0x80000001 0x00FA31
10.0.0.0        2.2.2.2         1360        0x80000002 0x002DF2
192.168.1.0     2.2.2.2         1325        0x80000001 0x00595D

                Router Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum Link count
1.1.1.1         1.1.1.1         1330        0x80000003 0x000D62 3
2.2.2.2         2.2.2.2         1329        0x80000003 0x002DB8 2

                Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
10.0.0.2        2.2.2.2         1329        0x80000001 0x0043D6

                Summary Net Link States (Area 1)

Link ID         ADV Router      Age         Seq#       Checksum
3.3.3.3         2.2.2.2         1371        0x80000001 0x004F98
172.16.1.0      2.2.2.2         1371        0x80000001 0x00A389
172.16.2.0      2.2.2.2         1371        0x80000001 0x009893
192.168.0.0     2.2.2.2         1381        0x80000001 0x000C82
192.168.0.4     2.2.2.2         1381        0x80000001 0x00E3A6
192.168.0.8     2.2.2.2         1371        0x80000001 0x003E08
R2-ABR#

OSPF Network Types
When we have a router interface configured for OSPF, it’s going to have a certain OSPF Network Type. Let’s talk about some of the characteristics of the different network types.

Broadcast Network Type:

Multiple Routers connected to a Broadcast Medium perhaps some flavour of ethernet. In order for all these routers to share he same OSPF database, someone may think they will have to form a full mesh of adjacencies with one another. We can elect a DR which will form a FULL adjacency with every router in the subnet. Incase the DR goes down the Backup Designated Router (BDR) will take over. The Broadcast Network Type will elect a DR and a BDR and associate the network type with a hello timer. The default Hello Interval on this network type is 10 seconds. The Dead interval is derived from the equation Hello Timer * 4 which is a full 40 second non-response for Hellos from Neighboring Routers. After that 40 seconds, the neighbor is considered as unavailable. We don’t need to type the Neighbor command on this network type as we can use Multicast to dynamically discover a neighbor.

Point to Point Network Type:

In this design, we might have a couple of routers interconnected over a WAN protocol, HDLC , Frame Relay. No scalability concerns here as there are only two routers. Because there are not many adjacencies like in the Broadcast Network Type, we will not need to Elect a DR and BDR. The default Hello Interval remains 10 seconds. The Dead Timer interval just like in the Boradcast Network Type is also 4 * Hello Timer which is 4 * 10seconds = 40 seconds. The Neighbor command is not required in this OSPF Network Type.

Non-Broadcast OSPF Network Type:

This network could be a Frame Relay as pictured here, let’s imagine that R1 is at our Head Quarters and R2,R3 and R4 are at different Remote offices. They can all be part of the same subnet, it will be a good idea to elect a Designtated Router here [DR and BDR] but the challenge is, this is a Non-Broadcast Network and bacause of that we will not be able to use Multicast to dynamically discover our neighbors. Instead, we will have to statically configure the IP Address of our Neighbors. We need to strategically select that DR. We need to pick a Designated Router that can be adjacent to every other router.
From this topology, R1 is the best candidate for DR. But to make sure no other router attempts to become the DR or the BDR for that matter, we will have to set the OSPF Priority to 0 for those routers so they do not even attempt to become a DR or BDR. Since we want R1 to be the Designated Router, we can set it’s OSPF Priority to a Non-Zero value so it becomes the DR of choice. The Hello Interval on the Non-Broadcast OSPF Network Type is rather longer than the ones we have discussed earlier. The Default Hello Interval is 30 Seconds which in turn will make the Dead Timer 4 * 30 seconds = 120 seconds. And like I said earlier, because this is a Non-Broadcast Network, we will have to statically define our Neighbors by using the neighbor Command.

Point to Multipoint:

Topologically, this looks like our Point to Point OSPF Network Type and so what is the difference? Consider R1, that interface that goes out to our frame relay service provider network in this case, if that OSPF interface is configured for the point to multipoint network type, it’s going to treat each of those dashed lines going to R2, R3 and R4 as separate point to point connections. Each of those dashed lines represent separate subnets.
A DR and and BDR is not required as they all each appear as their own point to point network. The Hello timer for a Point-to-Multipoint Network is 30 seconds and so the Dead timer will be 120 seconds. This does not require the neighbor command. R1 can discover R2 over the dashed lines. So will R1 to R3 and R4 to R1.

Figure 1.4 – OSPF Network Types Defaults

• Broadcast is the default network type on Ethernet networks.
• Point-to-Point is the default network type on Frame Relay point-to-point subinterfaces.
• Non-Broadcast(NBMA) is the default network type on Frame Relay physical interfaces and multipoint subinterfaces.

How do we determine, what is the OSPF Network Type for a particular interface?

R2-ABR#show ip ospf interface

R2-ABR#show ip ospf interface
Serial0/1 is up, line protocol is up
  Internet Address 192.168.0.5/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Index 2/4, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 4
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 4.4.4.4
  Suppress hello for 0 neighbor(s)
Serial0/0 is up, line protocol is up
  Internet Address 192.168.0.1/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Index 1/3, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 4
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 3.3.3.3
  Suppress hello for 0 neighbor(s)
Loopback0 is up, line protocol is up
  Internet Address 2.2.2.2/32, Area 1
  Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1
  Loopback interface is treated as a stub Host
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.2/24, Area 1
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:08
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 0, maximum is 7
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)
R2-ABR#

How do we determine, what is the OSPF Network Type for a particular interface?

To make your router to only show you the OSPF Network Types:

R2-ABR#show ip ospf interface | inc Network Type
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Process ID 1, Router ID 2.2.2.2, Network Type LOOPBACK, Cost: 1
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10

• Broadcast is the default network type on Ethernet networks.
• Point-to-Point is the default network type on Frame Relay point-to-point subinterfaces.
• Non-Broadcast(NBMA) is the default network type on Frame Relay physical interfaces and multipoint subinterfaces.

Make it only show you the Network Types:
R2-ABR:show ip ospf interface | inc Network Type

What if you really want to specify the type of network instead of automatically specified?
Type the command under the interface;

int s0/0
ip ospf network  [broadcast]

Designated Routers and Backup Designated Routers
We have already said routers in the same area need to have the same database view of that area. So they are going to need to exchange information and we have talked about how we can form adjacency between a couple of routers, however consider a multiaccess network like we have here, maybe a local area network with multiple routers connected to the same subnet that are going into something like a Cisco Catalyst Switch. Since they all have interfaces on the same subnet, instead of forming a full adjacency from every router to every other router, we can elect a DR, a Designated Router and BDR, a Backup Designated Router should the DR go down. We do this because having a full adjacency from every router to every other router does not scale well. In the topology below, we have 6 routers and so if every router formed adjacency with every other router, then its going to be [6 * (6-1)] /2 = 6*5 /2 = 15 Adjacencies. Now if 6 routers = 15 Adjacencies then 10 Routers will be (10* (10-1)/2 = 90/2 = 45 Adjacencies. So to summarise, in a scenario like the one we have here, it’s always a best practice to elect a DR and a BDR which mitigates the need to have too many Adjacencies and too many chat of Hellos. This reduces the mess the number of adjacencies can create in a broadcast network.

The number of adjacencies = [n * (n-1)] /2 , where n is the number of nodes or routers. What do you think the Number of Adjacencies will be for the topology below in Figure 1.5?

The Routers will now use the Multicast Address for OSPF to communicate.

224.0.0.5 – All OSPF Routers
224.0.0.6 – All Designated Routers

How does a DR get Elected?

The Hello protocol is used to elect a DR. During a DR election, the router with the highest OSPF priority value wins. Note that the OSPF priority value is associated with an interface and can be a value in the range 0 – 255. If we ver statically configure the OSPF priority value of O, this will then mean that the router will not become the DR. This was a popular practice on a frame relay topology so one of the spokes does not decide to become the DR. The OSPF priority of an interface can be configured using the ip ospf priority value command in interface configuration mode.
What if the priorities tie? In a situation like such, the Router with the highest router ID (RID) becomes the DR. A router’s RID can be configured in router configuration mode, with the command router-id ID. This is not a popular practice as when the RID is not configured, the highest IP address of a loopback interface(that is currently up) becomes the RID. If a router has no loopback interfaces, the highest IP address of a non-lopback interface(that is currently up becomes the RID). Which election happens first? The DR is elected first and then the BDR is elected afterwards.

Since there is no premption with OSPF, another router which may have a higher OSPF priority cannot just show up and become the DR. This makes the OSPF network safe preserving the architectural integrity without unexpected changes causing unexpected results. So a tip for you: Seeing a DR not having the highest OSPF priority is not strange as it could simply mean that the DR came online first.

If you are in a lab environment, you could change the OSPF Priority and then shut and no shut the interface to cause the OSPF to recalculate. Use clear ip ospf process

How to find out who is the DR on the network

R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:32    10.0.0.2        FastEthernet0/0

Since the FastEthernet0/0 is the interface where the DR is sourced from let us see what else that interface has to show us regarding the BDR.

FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.1/24, Area 1
  Process ID 1, Router ID 1.1.1.1, Network Type BROADCAST, Cost: 10
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:02
  Supports Link-local Signaling (LLS)
  Index 2/2, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Designated Router)
  Suppress hello for 0 neighbor(s)

Router 2 confirms this.

R2-ABR#show ip ospf int f0/1
%OSPF: OSPF not enabled on FastEthernet0/1
R2-ABR#show ip ospf int f0/0
FastEthernet0/0 is up, line protocol is up
  Internet Address 10.0.0.2/24, Area 1
  Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 10
  Enabled by interface config, including secondary ip addresses
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 2.2.2.2, Interface address 10.0.0.2
  Backup Designated router (ID) 1.1.1.1, Interface address 10.0.0.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04
  Supports Link-local Signaling (LLS)
  Index 1/1, flood queue length 0
  Next 0x0(0)/0x0(0)
  Last flood scan length is 7, maximum is 7
  Last flood scan time is 0 msec, maximum is 4 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 1.1.1.1  (Backup Designated Router)
  Suppress hello for 0 neighbor(s)

OSPF Timers

OSPF uses a couple of Timers. There is the Hello Timer (Hello Interval).
The Hello Timer measures the interval in seconds at which a router sends Hello messages out of an OSPF-enabled interface.

Dead Timer (Dead Interval) : If I haven’t heard from a specific adjacency, I am going to consider it as dead. The time in seconds measured for an OSPF-enabled interface as it waits to receive a Hello message from an adjacency, before considering that adjacency to be down. The Dead Timer = Hello Timer x 4. If the Hello timer is 5 seconds, the Dead timer is 5×4 = 20 seconds.

From our earlier outputs, see what the Hello and Dead Timers are for the Point_to_Point Network.

R2-ABR#show ip ospf interface
Serial0/1 is up, line protocol is up
  Internet Address 192.168.0.5/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type POINT_TO_POINT, Cost: 64
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    oob-resync timeout 40
    Hello due in 00:00:04

Let’s see what the default timers are for a different OSPF Network type – Let us set the OSPF Network type to Non-Broadcast.

R2-ABR(config)#int s0/0
R2-ABR(config-if)#ip ospf network non-broadcast

You should lose adjacency at this point:

*Mar  1 00:01:46.895: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on Serial0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

Hang on, you will have to repeat the same for the end interface. Go to the Neighbor’s interface and match the network type as per below:

R3(config)#int s0/0
R3(config-if)#ip ospf network non-broadcast

Let’s Verifiy for R2-ABR#

R2-ABR#show ip ospf interface s0/0
Serial0/0 is up, line protocol is up
  Internet Address 192.168.0.1/30, Area 0
  Process ID 1, Router ID 2.2.2.2, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State WAITING, Priority 1
  No designated router on this network
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120

Let’s verify for R3

R3#show ip ospf interface s0/0
Serial0/0 is up, line protocol is up
  Internet Address 192.168.0.2/30, Area 0
  Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 3.3.3.3, Interface address 192.168.0.2
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120

So as you can clearly see from above, the Hello and Dead Timer Intervals changes depending on the type of OSPF Network.

Hello TImer (Hello Interval)
Dead Timer : If I haven;t heard from an adjacency, I am going to consider it as dead.

OSPF Passive Interface

let’s consider the passive interface option for OSPF. Let’s say we have an interface that we want OSPF to advertise. Let’s take R1 topology and we can see that it has the 192.168.1.0/24 subnet space. This connects out to end users only. It is not connecting to another router and so will not need to advertise OSPF Messages from it’s Internet. When an interface is passive, it will not forward OSPF Messages out of that interface typically when it has no routers connected to it. You don’t want someone to show up with a Rogue Router to form neighborship to R1, this will be a security concern. We want that interface to be advertised to other routers but not for it to advertise OSPF message out of its interface.

This is how we do this;

R1(config)#router ospf 1
R1(config-router)#passive-interface fa 0/0
R1(config-router)#end

show ip ospf interface brief

show ip protocols

Related Articles:
Understanding OSPF Adjacency

Cisco has a good discussion on configuring OSPF. This might be a great resource to expand your knowledge.

Other popular routers like the 887va and 1914 come with SHDSL modules to cater for your PPPoE needs but it is not the case for the most loved Cisco ASA Security Devices. Cisco always cater for the business requirement at hand and so has provisioned a way to configure a PPPoE passthrough for your network in order to terminate connectivity to the trusted network device.

Configure Cisco ASA 5506-X for PPPoE Passthrough

The following picture shows the Cisco ASA 5506 with a BT OpenReach Fibre FTTC Modem which perfoms the PPPoE passthrough for the Cisco ASA 5506-X. Look at the setup below;

Figure 1.0 – Cisco ASA 5506-X with BT OpenReach Fibre Modem for PPPoE Passthrough

Now let us connect our Cisco ASA 5506 to the BT OpenReach Fibre Modem or the product you have for your location. The setup will always be similar to what is in the following drawing. Select the following interfaces on your Cisco ASA 5506-X and connect them up the way it is laid out in the drawing below;

1. Connect Interface X to LAN Network (In this scenario your laptop)
2. Connect Interface Y to Fibre Modem (In this Scenario your BT OpenReach Fibre Modem)
3. Connect DSL Line to DSL port on Fibre Modem

Figure 1.1 – How to setup Cisco ASA 5506-X for BT OpenReach Fibre Modem Passthrough

Figure 1.2 – Configure Inside Interface and Outside Interface on Cisco ASA 5506-X

I have chosen interface GigabitEthernet1/1 blue ethernet cable for my LAN Network and interface GigabitEthernet1/8 yellow ethernet cable for my Outside PPPoE Passthrough.

Follow the Instructions below to get your Cisco ASA 5506-X Up and running as PPPoE Passthrough.

Interface Configuration for Inside Network

!
interface GigabitEthernet1/1
 description "Inside Network LAN Interface"
 nameif lansubnet
 security-level 100
 ip address 192.168.1.1 255.255.255.0
!

Interface Configuration for Outside Network over PPPoE

!
interface GigabitEthernet1/8
 nameif outside
 security-level 0
 pppoe client vpdn group EE
 ip address pppoe setroute
!

IP Scope and DNS for Connecting Clients

!
dhcpd address 192.168.1.100-192.168.1.200 lansubnet
dhcpd dns 8.8.8.8 8.8.4.4 interface lansubnet
dhcpd enable lansubnet
!

Permit Pings to test connectivity once you have completed configuring the Cisco ASA 5506-X for PPPoE Passthrough

access-list 100 extended permit icmp any any
access-list from_outside extended permit icmp any any echo

Configure NAT for LAN to Reach Public Internet

!
nat (lansubnet,outside) after-auto source dynamic any interface
!

PPPoE Configuration – Use Chap for Fibre and PAP for ADSL

!
vpdn group EE request dialout pppoe
vpdn group EE localname pppoeusername.orangehome.co.uk@fs
vpdn group EE ppp authentication chap | pap | mschap 
vpdn username pppoeusername.orangehome.co.uk@fs password *****
!

Bonus PPPoE Configuration Sample for BT Customers

vpdn group BT request dialout pppoe
vpdn group BT localname bthomehub@btinternet.com
vpdn group BT ppp authentication pap
vpdn username bthomehub@btinternet.com password 
dhcpd dns 62.6.40.178 62.6.40.162 interface pppoe

Configure DNS

!
dns domain-lookup outside
dns server-group DefaultDNS
 name-server 8.8.8.8
 name-server 8.8.4.4
!

SSH Configuration

!This configuration tells the firewall to expect and accept SSH from Subnet via Gig1/1
ssh 192.168.1.0  255.255.255.0  lansubnet

Verification Commands

show ip address outside pppoe
show route
show vpdn session pppoe state
show vpdn session pppoe packets
show vpdn tunnel pppoe summary
show vpdn pppinterface

Results of verification commands based on debug output

ciscoasa# show ip address outside pppoe

PPPoE Assigned IP addr: 2.91.204.28 255.255.255.255 on Interface: outside
   Remote IP addr: 172.16.14.167
ciscoasa# show route

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 172.16.11.187 to network 0.0.0.0

S*       0.0.0.0 0.0.0.0 [1/0] via 172.16.11.187, outside
C        192.168.1.0 255.255.255.0 is directly connected, lansubnet
L        192.168.1.1 255.255.255.255 is directly connected, lansubnet

ciscoasa# show vpdn session pppoe state

PPPoE Session Information (Total tunnels=1 sessions=1)


SessID TunID Intf     State       Last Chg
 2458      3 outside  SESSION_UP  1846 secs

ciscoasa# show vpdn session pppoe packets

PPPoE Session Information (Total tunnels=1 sessions=1)


LocID RemID TunID Pkts-In   Pkts-Out  Bytes-In  Bytes-Out
 2458     3     47153     37838  35440125  22334650

ciscoasa# show vpdn tunnel pppoe summary

PPPoE Tunnel Information (Total tunnels=1 sessions=1)


LocID Intf       Remote MAC      Sessions
    3 outside 40:7c:7d:b3:79:94:        1

ciscoasa# show vpdn pppinterface

PPP virtual interface id = 1
PPP authentication protocol is CHAP
Server ip address is 172.16.11.187
Our ip address is 2.31.244.218
Transmitted Pkts: 37240, Received Pkts: 47213, Error Pkts: 0
MPPE key strength is None
  MPPE_Encrypt_Pkts: 0,  MPPE_Encrypt_Bytes: 0
  MPPE_Decrypt_Pkts: 0,  MPPE_Decrypt_Bytes: 0
  Rcvd_Out_Of_Seq_MPPE_Pkts: 0

ciscoasa#

Cisco addresses known issues in their forum on this subject concerning Configuring Cisco ASA 550-X for PPPoE Passthrough.

Once upon a time, we walked together holding hands, we enjoyed the breeze together, we called ourselves neighbors but could we say the same of our OSPF Neighbor Adjacency?

OSPF Neighbor Adjacency – Do I need to worry about it?

Troubleshooting OSPF Neigbor Adjacency is an important skill to have as a network engineer. OSPF is the most popular routing protocol loved by many and so with a good article as per below, you should be able to troubleshoot OSPF issues without difficulties.

Just like our behaviour in the real world, the fact that routers are neighbors is not sufficient enough to guarantee exchange of link-state updates; they must perform adjacencies which is based on a set of laid down requirements in order to exchange link-state updates. Adjacency is an advanced form of neighborship formed by routers that are willing to participate in the exchange of routing information after negotiating parameters of such an exchange. Routers therefore can only reach a FULL state of adjacency when they have synchronized views on a link-state database.

Interface type plays a major role in how the adjacencies are formed. For example, neighbors on point-to-point links always try to become adjacent, while routers attached to broadcast media such as Ethernet can choose to become adjacent only with a subset of neighboring routers on the interface.

Once a router decides to form an adjacency with a neighbor, it starts by exchanging a full copy of its link-state database. The neighbor, in turn says hi, I have some more updates and so doing, exchanges a full copy of its link-state database with the router. After passing through several neighbor states, the routers become fully adjacent.

OSPF Adjacency Requirements,

From the perspective of OSPF, there are a couple of things that must match for a OSPF neighborship to establish; these include:

1. The devices must be in the same area
2. The devices must have the same authentication configuration
3. The devices must be on the same subnet
4. The devices hello and dead intervals must match
5. The devices must have matching stub flags

OSPF Adjacency Formation States
During the adjacency formation process, two OSPF routers transition through several states, which include:

Down. Down is the starting state for all OSPF routers. A start event, such as configuring the protocol, transitions the router to the Init state. The local router may list a neighbor in this state when no hello packets have been received within the specified router dead interval for that interface.
Init. The Init state is reached when an OSPF router receives a hello packet but the local router ID is not listed in the received Neighbor field. This means that bidirectional communication has not been established between the peers.

Attempt. The Attempt state is valid only for Non-Broadcast Multi-Access (NBMA) networks. It means that a hello packet has not been received from the neighbor and the local router is going to send a unicast hello packet to that neighbor within the specified hello interval period.

2-Way. The 2-Way state indicates that the local router has received a hello packet with its own router ID in the Neighbor field. Thus, bidirectional communication has been established and the peers are now OSPF neighbors. (And this is where you stand and clap for the ingenuity of the neighborship concept. Note that till the point of Neighborship formation, databases haven’t been exchanged. It is only before they become adjacent that they exchange databases which is explained below.)

ExStart. In the ExStart state, the local router and its neighbor establish which router is in charge of the database synchronization process. The higher router ID of the two neighbors controls which router becomes the master.

Exchange. In the Exchange state, the local router and its neighbor exchange DD packets that describe their local databases.
Loading. Should the local router require complete LSA information from its neighbor, it transitions to the Loading state and begins to send link-state request packets.

Full. The Full state represents a fully functional OSPF adjacency, with the local router having received a complete link-state database from its peer. Both neighboring routers in this state add the adjacency to their local database and advertise the relationship in a link-state update packet.

Figure 1.0 – OSPF Neighbor Adjacency States and OSPF Neighbor Forming Process

Run the show ip ospf neighbor command to initiate the troubleshooting process for the lost OSPF neighbor adjacency,

Router1# show ip ospf neighbor

OSPF routers go through the seven states while building neighborship with other routers.

1. Down state
2. Attempt/Init state
3. Two ways state
4. Exstart state
5. Exchange state
6. Loading state
7. Full state

You can use the show ip ospf neighbor command in order to determine the state of the OSPF neighbor or neighbors. The output of this command will most likely reveal one of these:
nothing at all

state = down
state = init
state = exstart
state = exchange
state = 2-way
state = loading

OSPF Neighborship Requirement;
In order to become an OSPF neighbor, the following values must be match on both routers.

• Area ID
• Authentication
• Hello and Dead Intervals

Stub Flag
MTU Size

OSPF Stuck in INIT,

The init state indicates that a router sees Hello packets from the neighbor, but two-way communication has not been established. A Cisco router includes the router IDs of all neighbors in the init (or higher) state in the neighbor field of its Hello packets. Example 3-15 shows sample output of the show ip ospf neighbor command.

OSPF Neighbor Stuck in INIT—Cause: Access List on One Side Is Blocking OSPF Hellos
OSPF uses a multicast address of 224.0.0.5 for sending and receiving Hello packets. If an access list is defined on the interface and OSPF is enabled on that interface, this multicast address must be explicitly permitted in the access list; otherwise, it can produce problems such as stuck in INIT. The stuck in INIT problem occurs only if one side is blocking OSPF Hellos. If both sides are blocking OSPF Hellos, the output of show ip ospf neighbor returns an empty list.

OSPF Neighbor Stuck in INIT—Cause: Multicast Capabilities Are Broken on One Side
This is a specific situation that is valid only in the case of a Catalyst 6500 switch with the multilayer switch feature card (MSFC). The problem is that one side is sending OSPF Hellos that the other side does not receive.This situation is produced when the command set protocolfilter enabled is entered on the 6500 switch. By default, the protocol filter is disabled. Enabling this command begins altering the multicast frame to and from MSFC and port adapter within the FlexWan module of the 6500 switch. To fix this problem, disable the protocol filter on 6500 switch set protocolfilter disable.

OSPF Neighbor Stuck in INIT—Cause: Cause: Authentication Is Enabled Only on One Side
When authentication is used, it must be enabled on both sides; otherwise, one side will show the neighbor stuck in the INIT state. The router that has authentication enabled will reject all the nonauthenticated packets, and the adjacency will show stuck in INIT. The other side will not detect any problem because the authentication is turned on, so it will simply ignore the authentication in apacket and treat it as a normal packet.

OSPF Neighbor Stuck in INIT—Cause: The Frame-Relay Map/dialer-map Statement on One Side Is Missing the broadcast Keyword
OSPF uses a multicast address of 224.0.0.5 to send and receive OSPF Hellos. If one side is incapable of sending or receiving Hellos, the OSPF neighbor will be stuck in the INIT state. The important thing to note here is that only one side suffers from this multicast prob-lem. R1 sees the neighbor in INIT state but can see the neighbor Hellos without any problem. When R1 sends the Hello to R2, it never reaches R2 because Layer 2 is incapable of sending any broadcast or multicast packets. This is because of the lack of the broadcast keyword in frame-relay map statement on R1. A similar problem can occur in the case of ISDN or dialer interface when the dialer map statement is configured without the broadcast keyword.

OSPF Neighbor Stuck in INIT—Cause: Hellos Are Getting Lost on One Side at Layer 2
This situation happens when there is a problem on the Layer 2 media; for example, the Frame Relay switch is blocking the multicast traffic for some reason. When R1 sends the Hello, R2 never receives it. Because R2 never saw Hellos from R1, the neighbor list of R2 will be empty. However, R1 sees the Hellos from R2, which does not list R1 as a valid neighbor; so, R1 declares this neighbor in the INIT state.

OSPF Stuck in LOADING State
This is a rare problem in OSPF neighbor relationships. When a neighbor is stuck in the LOADING state, the local router has sent a link-state request packet to the neighbor requesting an outdated or missing LSA and is waiting for an update from its neighbor. If a neighbor doesn’t reply or a neighbors’ reply never reaches the local router, the router will be stuck in the LOADING state.
The most common possible causes of this problem are as follows:
1 Mismatched MTU
2 Corrupted link-state request packet

OSPF Neighbor Stuck in LOADING—Cause: Mismatched MTU Size
This is a unique problem that happens when an MTU mismatch occurs. If the MTUs are not the same across the link, this problem occurs. Specifically, if a neighbor’s MTU is greater than the local router’s, the neighbor sends a large MTU packet as a link-state update. This packet never reaches the local router; as a result, the neighbor gets stuck in the LOADING state.

OSPF Neighbor Stuck in LOADING—Cause: Link-State Request Packet Is Corrupted
When a link-state request packet is corrupted, the neighbor discards the packet and the local router never receives the response from the neighbor. This causes the OSPF neighbor to be stuck in the LOADING state.
Link-state request packets usually become corrupted because of the following reasons:
1 A device between the neighbors, such as a switch, is corrupting the packet.
2 The sending router’s packet is invalid. In this case, either the sending router’s interface is bad or the error is caused by a software bug.
3 The receiving router is calculating the wrong checksum. In this case, either the receiving router’s interface is bad or the error is caused by a software bug. This is the least likely cause of this error message.
Most of the time, this problem is fixed by replacing hardware. This could be a simple bad port on the switch or a bad interface card on the sending/receiving router.

OSPF Neighbor Stuck in EXSTART/EXCHANGE

This is an important state during the OSPF adjacency process. In this state, the router elects a master and a slave and the initial sequence number. The whole database also is exchanged during this state. If a neighbor is stuck in EXSTART/EXCHANGE for a long time, it is an indication of a problem.
The most common possible causes of this problem are as follows:

1. Mismatched interface MTU
2.  Duplicate router IDs on neighbors
3.  Inability to ping across with more than certain MTU size
4.  Broken unicast connectivity because of the following:
5. Wrong VC/DLCI mapping in Frame Relay/ATM switch
6.  Access list blocking the unicast
7.  NAT translating the unicast
8.  Network type of point-to-point between PRI and BRI/dialer

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Mismatched Interface MTU
OSPF sends the interface MTU in a database description packet. If there is a MTU mis-match, OSPF will not form an adjacency. The interface MTU option was added in RFC 2178. Previously, there was no mechanism to detect the interface MTU mismatch.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Duplicate Router IDs on Neighbors
When OSPF sends a DBD packet to elect a master and a slave, the router with the highest router ID becomes the master. This happens in the EXSTART process. If there is any problem with election, the router will be stuck in the EXSTART/EXCHANGE state.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Can’t Ping Across with More Than Certain MTU Size
When OSPF begins forming an adjacency with its neighbor, it goes through several states. In EXSTART state, OSPF determines which will be the master and which will be the slave. After the routers decided this, they start exchanging the LSA header in the form of DBD packets. If the database is huge, OSPF uses the interface MTU and tries to send as much data as possible up to the limit of the interface MTU. If there is a problem with Layer 2 accepting large packets that are within the interface MTU range, the OSPF adjacency will be stuck in the EXCHANGE state.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Unicast Connectivity Is Broken
When OSPF routers begin exchanging database information with each other, they send a unicast packet to each other in EXSTART/EXCHANGE state. This happens only if the network type is not a point-to-point link. In cases of a point-to-point link, OSPF sends all multicast packets. If unicast connectivity is broken, OSPF neighbor remains in EXSTART state.
This ping failure could occur for several reasons, including the following:
1 The wrong DLCI or VPI/VCI mapping exists in a Frame Relay or ATM switch, respectively.
2 An access list is blocking the unicast.
3 NAT is translating the unicast.
Wrong DLCI or VPI/VCI Mapping
In cases of Frame Relay or ATM, this is a very common problem. The packet will be lost in the Frame Relay or ATM cloud. To further verify that this is the case, turn on debug ip packet detail with the access list on both routers.

Access List Blocking the Unicast
If an access list is configured on a router, make sure that it’s not blocking the unicast packet.

NAT Is Translating the Unicast
This is another common problem that occurs when NAT is configured on the router. If NAT is misconfigured, it will start translating the unicast packet coming toward it, which will break the unicast connectivity.

OSPF Neighbor Stuck in EXSTART/EXCHANGE—Cause: Network Type Is Pointto- Point Between PRI and BRI/Dialer
The network type on a PRI interface is point-to-point. This causes OSPF to send multicast packets even after the 2-WAY state. If only one BRI comes up as an OSPF neighbor, it will work fine. However, when multiple BRIs try to form an adjacency with the PRI, the PRI will complain because its network type is point-to-point. Because all OSPF packets are sent as multicast on a point-to-point link, the PRI receives DBD packets from multiple BRI neighbors, and this causes all the neighbors to get into the EXSTART/EXCHANGE state.

OSPF Troubleshooting Summary
Neighborship stuck in down stage : When an OSPF router first receives a hello packet, it verifies that the data in some fields matches its own locally configured information. Should any of the checked data be different, the hello packet is discarded and not processed. The data fields verified are the Area ID, Authentication, Network Mask (on broadcast networks), Hello Interval, Router Dead Interval, and Options fields. If this information doesn’t match, then neighborship is stuck in the down stage.

OSPF adjacency gets stuck in the ExStart state : This occurs due to a final check the routers perform. In the DD packet, each router advertises the IP MTU of the interface it is using. Should the local and remote routers not agree on the MTU of the network link, the database synchronization process stops and both neighbors remain in the ExStart state.

Bonus : Top 8 OSPF Troubleshooting Commands;

show ip protocols
show ip ospf
show ip ospf interface
show ip ospf neighbor
show ip ospf database
debug ip ospf packet
debug ip ospf hello
debug ip ospf adj

Check out our other articles like – Configuring Cisco Router for PPPoE

Reference: PacketPushers  | Prasadkeni

How do millions of  inter-networks route traffic through the Internet?

Well the answer is not far reaching as this is the point of this article to explain the Routing Protocol of the Internet called BGP, the Border Gateway Protocol.

BGP is the standardized routing protocol of the Internet with the purpose to route traffic across the Internet. For this purpose, it’s an essential protocol which could also be the hardest one to understand.

The Internet comprises of two parts: the internal fine-grained segments managed by an Interior Gateway Protocol such as the Open Short Path First (OSPF) or Extensible Interior Gateway Routing Protocol(EIGRP) and the inter-connectivity of their Autononomous Systems (AS) via the Exterior Gateway Protocol called BGP.

Now an important keyword to pay attention to before we get into the beef of our discussion is an Autonomous System. So what is an Autonomous System or AS?

An autonomous system (AS) is a network controlled by a single entity typically an Internet Service Provider or a very large organization with independent connections to multiple networks.

Is understanding BGP Necessary?

If the organisation you support connects to two or more ISPs as well as interconnecting with other Network Providers, then BGP knowledge is a requirement for you. Small corporate Network Administrators may not necessarily need to know the depths of configuring and administering the BGP Protocol.

BGP Basics You Should Know

• Based on RFC4271 BGP version 4 is the most current version of the BGP Protocol.
• BGP is based on a path-vector protocol which furnishes routing information for Autonomous Systems on the Internet utilising its AS-Path attribute(s).
• BGP resides on TCP as a Layer 4 protocol . Comparatively, it is not as complex as OSPF, because it does not need to worry about the things TCP will handle.
• BGP unlike other routing protocols does not utilise a discovery process meaning that it does not learn new connections therefore, peers that have been manually configured to exchange routing information will form TCP connections and become BGP fluent.
• Medium-sized corporations utilises BGP to effectively Multi-Home for their entire network.
• An important aspect of BGP is that the AS-Path itself is an anti-loop mechanism. Routers intelligently will not import any routes that contain themselves in the AS-Path.

Configuring BGP on Cisco Routers

The following is a step by step  approach to configuring BGP on Cisco Devices. It reinforces the required understanding of the following;

• IBGP neighbors – when two neighbors are in the same AS;
• EBGP neighbors – when two neighbors belong to different AS.

Figure 1.0 –  BGP Topology with Two Autonomous Systems AS 60010 and AS 60020

From the above diagram, you can see that R1 with AS10BDR and R2 with AS20BDR are IBGP neighbours while AS10BDR with AS20BDR are EBGP neighbours (because they belong to different Autonomous Systems).

To configure BGP start with router bgp AS which puts you in to the BGP configuration mode. AS here represents the Autonomous System to which the router belongs to or is a part of.

Next, configure bgp neighbours with neighbor (ip-address | peer-group-name) remote-as AS command.

Neighbours  are based on ip address not on peer groups as per the configuration which follows below. To tell the router what to advertise use this command: network network-number [mask network-mask] [ route-map map-tag].  Route Maps will not be used in the configuration below.

Below you see configurations according to our topology and commands described above.

R1

R1(config)#interface fa0/0
R1(config-if)#ip address 192.168.0.2 255.255.255.0
R1(config-if)#no shutdown 

R1(config)#router bgp 60010 
R1(config-router)#neighbor 192.168.0.1 remote-as 60010

AS10BDR

AS10BDR(config)#interface fastEthernet 0/0
AS10BDR(config-if)#ip address 10.0.0.1 255.255.255.0
AS10BDR(config-if)#no shutdown 
AS10BDR(config-if)#interface fastethernet 0/1
AS10BDR(config-if)#ip address 192.168.0.1 255.255.255.0
AS10BDR(config-if)#no shutdown 

AS10BDR(config)#router bgp 60010
AS10BDR(config-router)#neighbor 192.168.0.2 remote-as 60010
AS10BDR(config-router)#neighbor 10.0.0.2 remote-as 60020
AS10BDR(config-router)#network 192.168.0.0 mask 255.255.255.0

AS20BDR

AS20BDR(config)#interface fastEthernet 0/0
AS20BDR(config-if)#ip address 10.0.0.2 255.255.255.0
AS20BDR(config-if)#no shutdown
AS20BDR(config-if)#interface fa0/1
AS20BDR(config-if)#ip address 192.168.100.1 255.255.255.0
AS20BDR(config-if)#no shutdown

AS20BDR(config)#router bgp 60020
AS20BDR(config-router)#neighbor 10.0.0.1 remote-as 60010
AS20BDR(config-router)#neighbor 192.168.100.2 remote-as 60020
AS20BDR(config-router)#network 192.168.100.0 mask 255.255.255.0

R2

R2(config)#interface fastEthernet 0/0
R2(config-if)#ip address 192.168.100.2 255.255.255.0
R2(config-if)#no shutdown

R2(config)#router bgp 60020
R2(config-router)#neighbor 192.168.100.1 remote-as 60020

Note that if you use the mask in network command then the network in routing table must match network from this command. Also note that you can advertise any network that resides in routing table and is not necessary to be directly connected.

You have few tools to verify bgp status:

show ip bgp;
show ip bgp summary;
show ip bgp neighbors;
show ip bgp rib-failure.

Also you can use debug command. Let’s show BGP neighbors on AS10BDR:

AS10BDR#show ip bgp neighbors 
BGP neighbor is 10.0.0.2,  remote AS 60020, external link
  BGP version 4, remote router ID 192.168.100.1
  BGP state = Established, up for 00:20:11

... output ommited ...

BGP neighbor is 192.168.0.2,  remote AS 60010, internal link
  BGP version 4, remote router ID 192.168.0.2
  BGP state = Established, up for 00:28:42

As you see we have two neighbors with AS10BDR one internal and one external. Let’s see the results of show ip route on R1:

R1#show ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.0.0/24 is directly connected, FastEthernet0/0
R1#

Hmmm … ! As you have seen on R1 we don’t have external route to 192.168.100.0/24 which is expected to be. This is because routing updates sent by AS20BDR, which is an external router, have address 10.0.0.2 as source ip address, but in this case R1 doesn’t have any idea how to get to 10.0.0.0 network and that’s why BGP on R1 doesn’t put in routing table a route to 192.168.100.0/24 but keep it only in BGP table (you can check it with show ip bgp command). To overcome this we have to add on AS10BDR this command: AS10BDR(config-router)#neighbor 192.168.0.2 next-hop-self, which will change source ip address of routing updates sent to R1 (will change to its fa0/1 ip address).

AS10BDR(config-router)#neighbor 192.168.0.2 next-hop-self

The same you need to do on AS20BDR to change update source to neighbor R1.

AS20BDR(config-router)#neighbor 192.168.100.2 next-hop-self

And now let’s see again routing table on R1

R1#show ip route 
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

C    192.168.0.0/24 is directly connected, FastEthernet0/0
B    192.168.100.0/24 [200/0] via 192.168.0.1, 00:02:42
R1#

And a ping from R1 to R2

R1#ping 192.168.100.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.100.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/69/92 ms

Do I know this already?

Refer to the exhibit. Router RIP is attempting to establish BGP neighbor relationships with routers RT1 and RT3. On the basis of the information that is presented in the exhibit, which two statements are true? (Choose two)

A – RTR has a BGP password set but neighbor 10.0.0.1 does not
B – RTR has a BGP password set but neighbor 10.0.0.5 does not
C – RTR has a BGP password set but neighbor 10.0.0.1 has an incorrect password set
D – RTR has a BGP password set but neighbor 10.0.0.5 has an incorrect password set
E – Neighbor 10.0.0.1 has a BGP password set but RTR does not
F – Neighbor 10.0.0.5 has a BGP password set but RTR does not

Introduction to the Spanning Tree Protocol | Configuring | Verifying and Troubleshooting

Figure 1.0

Modern networks require redundancy to preserve business continuity as the consumption of networked-based resources are in the greatest demand in our century more than any other as we have become internet oriented. Our over reliance on internet technology only means that our servers, business and web applications must be constantly available and accessible, hence the need for a redundant network design to address these keen needs.

STP, otherwise known as the Spanning Tree Protocol (802.1D) was invented to maintain Redundant Networks without incurring loops on the network as broadcasts are channeled in the right optimal paths. Spanning Tree Protocol uses a clever mechanism or algorithms to create this loop free network by doing the following. This unique algorithm computes the optimum loop-free path through a switched Layer 2 network by assigning a role to each port based on the role of the port in the active topology:

• Root—A forwarding port elected for the spanning-tree topology
• Designated—A forwarding port elected for every switched LAN segment
• Alternate—A blocked port providing an alternate path to the root bridge in the spanning tree
• Backup—A blocked port in a loopback configuration

Spanning-Tree Interface States

Switches LANs can experience propagation delays with protocol information passing through the network and as a result, topology changes can occur at different times and at different points or locations on the switched network. An interface transitioning directly from non-participation in the spanning-tree topology to a forwarding state can create temporary data loops which could cause issues on the network. Interfaces therefore must wait for current topology information to propagate through the switched LAN before beginning to forward frames (BPDUs). They must allow the frame lifetime to expire for forwarded frames that have used the old topology.

Each Layer 2 interface on a switch using spanning tree exists in one of these states:

1. Blocking—The interface does not participate in frame forwarding.
2. Listening—The first transitional state after the blocking state when the spanning tree decides that the interface should participate in frame forwarding.
3. Learning—The interface prepares to participate in frame forwarding.
4. Forwarding—The interface forwards frames.
5. Disabled—The interface is not participating in spanning tree because of a shutdown port, no link on the port, or no spanning-tree instance running on the port.

An interface moves through these states:

1. From initialization to blocking
2. From blocking to listening or to disabled
3. From listening to learning or to disabled
4. From learning to forwarding or to disabled
5. From forwarding to disabled

Electing the Root Bridge or the Reference Switch of the Topology:

The election is made based on the Bridge Priority which by default for all switches is 32768. The BID is customisable but when the election becomes a tie due to the Switches’ Bridge Priority being the same for example Switch A# BID 32768 and Switch B# BID 32768, then the selection is now based on the Mac Address of the Switches.

The Switch with the lowest Mac Address becomes the Root Bridge on the network. The idea behind the use of the lowest Mac Address is due to the fact that, aged switches on the network are likely to know and maintain a CAM Tsble which is indepth than a newly introduced switch to the network. If on the other hand, the Root Bridge is failing and you have been tasked to replace it, then you will have to bring in a switch whose Bridge Priority is lower.

Manually Change the Bridge Priority

 SWITCH-A(config)#spanning-tree vlan 1 priority 24576
SWITCH-A(config)#end
SWITCH-A#
%SYS-5-CONFIG_I: Configured from console by console

Verify Manually Configured Priority and Root Bridge Status

 
SWITCH-A#show spanning-tree
VLAN0001
  Spanning tree enabled protocol ieee
  Root ID    Priority    24577
             Address     00D0.5877.63C5
             This bridge is the root
             Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec

This Switch becomes the Reference Point for the maintaining of a Loop FreeNetwork as the switches now makes decisions with this reference in mind.

Root Bridges sets their directly connected ports to Designated Forwarding Ports meaning that it s available for transactions to and from.

Figure 1.1 – Diagram of Root Bridge Ports in Designated Forwarding Mode

Every Non-Root Bridge selects only one path to the Root Bridge based on the cost of the link. The path cost

• 10 Gbps link cost is 2
• 1 Gbps link cost is 4
• 100 MB link cost is 19
• 10 MB link cost is 100

Figure 1.2 – Diagram of Non Root Bridge Ports Connecting to the Root Bridge based on costs

Feature

It is important to note the following when troubleshooting STP problems.

Switches forward broadcast packets out all ports by design
Redundant connections are necessary in business networks

How STP Finds the Best Path

1. Elect the Root
2. Find the Best Path to the Root
   • Lowest Cost
   • Lowest Bridge ID
   • Lowest Port Number
3. Block whatever is left over.

What could go wrong in real networks?

1. Mac Address Flapping /Broadcast Storm
2. Temporary Portfast Loop (Short Duration)
3. BPDU Filter/Root Guard Incorrectly Applied
4. Wrong Root Bridge Elected
5. Misconfiguration (Such as Etherchannel, Native Vlan).

Spanning Tree Verification and Troubleshooting Commands

 
    show spantree vlan_id 
    show spantree summary 
    show spantree statistics
    show spantree backbonefast 
    show spantree blockedports
    show spantree portstate 
    show spantree portvlancost
    show spantree uplinkfast

show spantree vlan_id —Shows the current state of the spanning tree for this VLAN ID, from the perspective of the switch on which you issue the command.
show spantree summary —Provides a summary of connected spanning tree ports by VLAN.
show spantree statistics —Shows spanning tree statistical information.
show spantree backbonefast —Displays whether the spanning tree BackboneFast Convergence feature is enabled.
show spantree blockedports —Displays only the blocked ports.
show spantree portstate —Determines the current spanning tree state of a Token Ring port within a spanning tree.
show spantree portvlancost —Shows the path cost for the VLANs on a port.
show spantree uplinkfast —Shows the UplinkFast settings.