Default routes in BGP

There are 3 ways of advertising default route in BGP.

Method 1: Using network command.
It requires only that the route is present in the Interior Gateway Protocol (IGP) routing table. This is the preferred approach.

Method 2: Using default-information originate command.
It requires explicit redistribution of the route This protects against someone accidentally redistributing a default route in BGP which could potentially be disastrous.

Method 3: Using neighbor default-originate command.
This method does not require the presence of the network in the routing table of the advertising router.

VPN Ports

To allow PPTP tunnel maintenance traffic, open TCP 1723.
To allow PPTP tunneled data to pass through router, open Protocol ID 47.

L2TP over IPSec
To allow Internet Key Exchange (IKE), open UDP 500.
To allow IPSec Network Address Translation (NAT-T) open UDP 4500.
To allow L2TP traffic, open UDP 1701.


OpenVPN uses port 1194 udp and tcp:

Here’s the Cisco access list: (gre=Protocol ID 47, pptp=1723, isakmp=500, non500-isakmp=4500):

permit gre any any
permit tcp any any eq 1194
permit udp any any eq 1194
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit udp any any eq 5500
permit tcp any any eq 1723
permit udp any any eq 1701

If natted address is being used by any of the peer then you need to open up the UDP port 4500 for ISAKMP.

If no natting is there then you need to open up the UDP port 500 for ISAKMP

For Phase 2: you need to explicitly open up the port for specific protocol like port 50 for AH and port 51 for ESP

IPSec can use ESP (protocol 50), or AH (protocol 51).   AH breaks if used with any type of NAT with IPv4, so it is rarely ever used in a transform set.

Optimising LEDE (OpenWrt) for the PC Engines APU2

I’m planning to get APU2 in near future, I found this article is useful for my future project and created a mirror here. Credit to original post.

The PC Engines APU2 is an embedded system based on AMD’s Jaguar family of processors. Many people prefer to run pfSenseon it, but since the rest of my hardware is alread on LEDE, it’s easier for me to stick with that; the APU2 will manage a network running other LEDE nodes, with customised images (see my article on UCI defaults for more information on that). To get an idea of all the tidbits the APU2 offers, the OpenWrt wiki page is a good starting point – since there are no subtargets anymore for x86/64 (alas), you have to install all extra packages manually to get full support for the hardware capabilities.

Default configuration

Because LEDE uses generic targets – a kind of catch-all – for the x86 and x86_64 platforms, by default it only configures eth0, the leftmost interface. It took me a while (coming from consumer platforms) to realise the images I built were fine, I just kept trying the two rightmost interfaces, figuring those were the LAN interfaces… So if you don’t seem to be getting an IP, try all of those ports. You never know. There’s also no WAN interface defined, so it won’t work as a router out of the box.

Hardware support

A stock LEDE image will boot just fine from internal mSATA/S-ATA storage or USB altogether. I have not been able to verify if booting off SD works yet.

Gigabit Ethernet

The APU2 comes with Intel’s i210AT or i211AT Gigabit Ethernet NICs, which need the igb driver on Linux. The stock x86_64 LEDE builds include this driver by default.

SDHC card reader

For the card reader, install the kmod-sdhci package. If you’d like to include it in your own build, enable it under Kernel modules > Other modules in the buildroot. To boot off an SD card, however, you need the following symbols to be enabled:


You can grep target/linux/x86/64/config-default for them, they should all be enabled by default. Add them to the same file if they aren’t. I have been unable to test so far if booting off SD cards works; I’ve seen some statements that the APU2 will ignore SD or USB 3 boot devices if there is an mS-ATa SSD installed.

USB 3.0 support

Booting off USB 3.0 works just fine out of the box – not much to add.

Temperature sensor

For basic temperature reading support – which may come in handy as you essentially rely on passive cooling – install the kmod-hwmon-k10temp package, or enable kmod-hwmon-k10temp in the buildroot under Kernel modules > Hardware Monitoring Support. Reading out the temperature is as simple as typing sensors:

# sensors 
Adapter: PCI adapter
temp1:        +53.2°C  (high = +70.0°C)
               (crit = +105.0°C, hyst = +104.0°C)

As you can see, though, it only reports one temperature instead of one per core.

VLAN support

For VLAN support, you need the 8021q module installed. The generic target statically includes it. You will find a package under Kernel modules > Network Support; however, this is only useful for targets that do not include the module by default. On targets like e.g. ar71xx or x86, it will just generate a package only containing a modprobe file, nothing more. You can set up tagged VLANs through LEDE’s framework -in /etc/config/network, e.g.:

config interface 'guest'
    option type 'bridge'
    option proto 'static'
    option netmask ''
    option ip6assign '60'
    option ifname 'eth1.20 eth2.20'
    option ipaddr ''

This will set up a bridge named br-guest, containing both eth1 and eth2, tagged with VLAN ID 20. This is standard; the bridge itself apparently does not get tagged, only the member interfaces.

# for i in eth1.20 eth2.20 br-guest; do ip -d link show $i; done
9: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:b9:41:45:61 brd ff:ff:ff:ff:ff:ff promiscuity 1 
    vlan protocol 802.1Q id 20 <REORDER_HDR> 
    bridge_slave state forwarding priority 32 cost 4 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64 
10: eth2.20@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:b9:41:45:62 brd ff:ff:ff:ff:ff:ff promiscuity 1 
    vlan protocol 802.1Q id 20 <REORDER_HDR> 
    bridge_slave state forwarding priority 32 cost 4 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64 
8: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:b9:41:45:61 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    bridge forward_delay 200 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32767 vlan_filtering 0 addrgenmode eui64

I can confirm this works as expected – for more info on VLANs on OpenWrt/LEDE, see my older post.

LED support

By default only the leftmost LED is active, and it just stays on. As of commit fe12d51, LEDE has a driver for the APU2’s PCB LEDs and reset button. I have backported this to my LEDE 17.01 builds.

GPIO header

The GPIO headers are controlled by the Nuvoton NCT5104D chip. To use them, enable the kmod-gpio-nct5104d package under Kernel modules > Other modules.

AMD’s cryptographic coprocessor (‘CCP’)

Enable the kmod-crypto-hw-ccp package under Kernel modules > Cryptographic API modules.

Hardware watchdog

Enable the kmod-sp5100-tco package under Kernel modules > Other modules.

Optimising LEDE for the APU2

GCC optimisation

GCC has its own target for the Jaguar SoCs. You can optimise by using the -march=btver2 -mtune=btver2 GCC options, with a recent GCC version. In the buildroot, enable Advanced configuration options (for developers), then tick Target Options and add the compiler flags to Target Optimizations. Do keep in mind though this will greatly limit your testing capabilites – I haven’t found a way to emulate a CPU supporting the same feature set yet, if you do, let me know, that would greatly simplify testing. For now I build a separate generic x86_64 build so I can test it in a VM, before deploying it.


One of the cooler things with the APU2 is it supports AES-NI, which is handy for applications relying on encryption (e.g. a VPN). LEDE enabled the necessary bits and bolts for that in the meantime.

Resizing partitions

Chances are you’ll be running conventional storage, so the default 4/48 configuration for the kernel and root partitions do not really use the space available. You can change this by setting the CONFIG_TARGET_ROOTFS_PARTSIZE= (for the root file system) and CONFIG_TARGET_KERNEL_PARTSIZE= for the kernel partition size.

UCI defaults

I have preconfigured my LEDE builds for the APU2 to set up a WAN interface on eth0 and a LAN bridge on the eth1 and eth2interfaces, as well as some other tidbits. Imho, if you want to deploy the APU2 with LEDE, prepping the network is a must.

LEDE discussion forum link for APU2

Arista EOS 101

This is a simple short notes taken from Arista Configuration Essentials (ACE) Lab Guide


Enter bash
switch# bash
switch-bash$ ifconfig -a
switch-bash$ top
switch-bash$ cd /mnt/flash

Upgrade EOS

Upload EOS to switch
switch# copy flash:

Verify image
switch# dir flash:

Configure boot image
switch# boot system flash: EOS-4.15.5M.swi

Verify boot-config
switch# show boot-config


Configure port channel for your peerlink
switch# interface Ethernet47-48
switch# channel-group 1000 mode active
switch# interface port-channel 1000
switch# switchport mode trunk

Configure a VLAN and trunk group used for MLAG peer communications
switch# vlan 9094
switch# trunk group mlagpeer

Assign the port-channel to the trunk group
switch# interface po1000
switch# switchport trunk group mlagpeer

Disable STP on the VLAN used for the MLAG peer
switch# no spanning-tree vlan 4094

Configure SVI for peer-to-peer communications
switch# int vlan 4094
switch# ip address
switch# no autostate

Configure local interface and peer address
switch# mlag configuration
switch# local-interface vlan 4094
switch# peer-address

Configure domain-d, peer-link & reload-delay on BOTH switches
switch# domain-id mlagDomain
switch# peer-link port-channel 1000
switch# reload-delay 200

Configure the MLAG interface (upstream interface to spine)
switch# int Eth31-32
switch# channel-group 999 mode active
switch# int po999
switch# mlag 999

Optional (configure Virtual ARP for downstream device)
switch# ip virtual-router address 001c.7300.0009 (for both switches)
switch# int vlan 2 (for both switches)
switch# ip address
switch# ip virtual-router address (for both switches)

Verify MLAG
switch# show mlag
switch# show mlag config-sanity
switch# show mlag detail
switch# show mlag interfaces
switch# show int po999


switch-XX# interface Vxlan 1
switch-XX# vxlan source-interface Loopback 1
switch-XX# vxlan vlan 101 flood vtep
switch-XX# vxlan udp-port 4789
switch-XX# vxlan vlan 101 vni 10000

switch-YY# interface Vxlan 1
switch-YY# vxlan source-interface Loopback 1
switch-YY# vxlan vlan 101 flood vtep
switch-YY# vxlan udp-port 4789
switch-YY# vxlan vlan 101 vni 10000

Verify vxlan
switch# sh vxlan vtep
switch# sh vxlan address-table


Configure port mirror to CPU (control plane)
switch# monitor session sniff source Eth33 both
switch# monitor session sniff destination Cpu

switch# bash
switch-bash$ tcpdump -i mirror1

*use the mirror number from “sh monitor session” output (Cpu : active (mirror1)

BGP Path Selection


RIB – Routing Information Base
FIB – Forwarding Information Base

This is a routing protocols database of routing prefixes that could potentially be installed in the routing table.
Derived from the control plane, it is not used for forwarding.
Every protocol such as OSPF, EIGRP, BGP has its own RIB and select their best candidates to try to install to global RIB so that it can then be selected for forwarding.
Is a selection of routing information learned via static definition or a dynamic routing protocol.
EX: show ip ospf databse show ip eigrp topology show ip bgp etc

The actual information that a routing/switching device uses to choose the interface that a given packet will use for egress.
Used for forwarding, information is derived from the RIB and from adjacency tables so that the packet can be rewritten with the correct encapsulation.
Is programmed by one or more RIB.
EX: show ip cef

Installing Guacamole on Raspberry Pi

Guacamole is a clientless remote desktop gateway. After successful implementation of this system on some PCs, now I want to use this on a Raspberry Pi 3 B+. Following is how I do the installation on Raspbian system.

OS Version: Raspbian GNU/Linux 9 (stretch)
  1. Upgrade the system:
$ sudo apt-get update
$ sudo apt-get upgrade
  1. Install the required dependencies:
$ sudo apt-get install libcairo2-dev
$ sudo apt-get install libjpeg62-turbo-dev
$ sudo apt-get install libpng12-dev
$ sudo apt-get install libossp-uuid-dev
  1. Install the optional packages:
$ sudo apt-get install libavcodec-dev libavutil-dev libswscale-dev
$ sudo apt-get install libpango1.0-dev
$ sudo apt-get install libssh2-1-dev
$ sudo apt-get install libtelnet-dev
$ sudo apt-get install libvncserver-dev
$ sudo apt-get install libpulse-dev
$ sudo apt-get install libssl-dev
$ sudo apt-get install libvorbis-dev
$ sudo apt-get install libwebp-dev
  1. Download Guacamole Server and Client packages:
$ wget
$ wget
  1. Build and install the server:
$ tar xzf guacamole-server-0.9.14.tar.gz
$ cd guacamole-server-0.9.14
$ ./configure --with-init-dir=/etc/init.d
$ make
$ sudo make install
$ sudo update-rc.d guacd defaults
$ sudo ldconfig
  1. Build the client:
$ sudo apt-get install maven
$ tar xzf guacamole-client-0.9.14.tar.gz
$ cd guacamole-client-0.9.14
$ mvn package
  1. Install jetty9 servlet container:
$ sudo apt-get install jetty9
  1. Deploy Guacamole:
$ sudo cp guacamole/target/guacamole-0.9.14.war /var/lib/jetty9/webapps/guacamole.war
$ sudo mkdir -p /etc/guacamole/extensions
$ sudo cp extensions/guacamole-auth-noauth/target/guacamole-auth-noauth-0.9.14.jar /etc/guacamole/extensions/.
  1. Copy following text and save it as “/etc/guacamole/”
#    Guacamole - Clientless Remote Desktop
#    Copyright (C) 2010  Michael Jumper
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU Affero General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    GNU Affero General Public License for more details.
#    You should have received a copy of the GNU Affero General Public License
#    along with this program.  If not, see <>.

# Hostname and port of guacamole proxy
guacd-hostname: localhost
guacd-port:     4822

# Auth provider class (authenticates user/pass combination, needed if using the provided login screen)
basic-user-mapping: /etc/guacamole/user-mapping.xml

# NoAuth properties
noauth-config: /etc/guacamole/noauth-config.xml
  1. Copy following text and save it as “/etc/guacamole/noauth-config.xml”
    <config name="pi" protocol="vnc">
        <param name="hostname" value="localhost" />
        <param name="port" value="5900" />
  1. Copy following text and save it as “/etc/guacamole/user-mapping.xml”. The password is “raspberry”.
        <connection name="pi">
        <param name="hostname">localhost</param>
        <param name="port">5900</param>
        <param name="swap-red-blue">false</param>
        <param name="enable-audio">true</param>
  1. Install x11vnc VNC-Server:
$ sudo apt-get install x11vnc
  1. Copy following text and save it as “~/.config/autostart/x11vnc.desktop”
[Desktop Entry]
Name=X11 VNC
Comment=Remotedesktop Server
Exec=x11vnc -forever -nopw -rfbport 5900 -display :0
Comment[de_DE]=Remotedesktop Server
  1. Restart Raspberry Pi:
$ sudo reboot

At this point guacamole should be automatically started at system boot. You can try to open it from a web-browser, the address is “<ip-address>:<port>/guacamole”. On my network it looks like this “”.

In case you use headless system (Raspberry Pi without display attached) and you have poor display resolution, you can set the parameters in “/boot/config.txt” from this:



to this (for full HD resolution):



Restart the system and that’s it. Have fun!


Odroid HC2 Heat Issue

The infamous heat issue with the Odroid HC2 is here. My simple solution is simply by plugging in cheap USB fan to the bottom of the case (I put my HC2 vertically for better heat dissipation). Below is the result.

CPU thermal reduction
3.5 HDD thermal reduction

And for the sake of comparison, here’s the CPU thermal reading for my RPi2 with no cooling (and running Node JS + Munin server)

Raspberry Pi 2 in a case, no fan

TP-Link Smart Plug Monitoring

I found a great web based monitoring tools for this smart plug, and I will share my method running this tools in Raspberry Pi (with DietPi).

Read more about this tool here:

There are few method to run this, but I found that using Node+NPM is the easiest for this platform.

apt install git npm
git clone && cd tplink-energy-monitor
npm install
npm start

Once installed and run, go to http://server-ip:3000

Munin monitoring on RaspberryPi/DietPi

Here’s the situation. I have an Odroid XU4 and Raspberry Pi, both of them running with DietPi image. The mission is to perform system monitoring for both of the system.

Install Munin server

Ensure that the system is up to date before you start to install Munin, run:

apt-get updateapt-get upgrade

Apache is used to show the Munin pages, the apache fcgid module is required for the Munin graph zoom feature. Install apache and the fcgid module with apt.

apt-get install apache2 libcgi-fast-perl libapache2-mod-fcgid

Enable the fcgid module in apache.

a2enmod fcgid

Install & Configure Munin

To install Munin on DietPi, we do this:

apt-get install munin munin-node munin-plugins-extra 

Next, we must edit the Munin configuration file /etc/munin/munin.conf. Uncomment the dbdirhtmldirlogdirrundir, and tmpldir lines (the default values are fine). We want Munin to use the name raspiblack.local instead of localhost.localdomain in the HTML output, therefore we replace localhost.localdomain with raspiblack.local in the simple host tree section. Without the comments, the changed file looks like this:

nano /etc/munin/munin.conf
# Example configuration file for Munin, generated by 'make build'

# The next three variables specifies where the location of the RRD
# databases, the HTML output, logs and the lock/pid files. They all
# must be writable by the user running munin-cron. They are all
# defaulted to the values you see here.
dbdir /var/lib/munin
htmldir /var/cache/munin/www
logdir /var/log/munin
rundir /var/run/munin

# Where to look for the HTML templates
tmpldir /etc/munin/templates

# Where to look for the static www files
#staticdir /etc/munin/static

# temporary cgi files are here. note that it has to be writable by
# the cgi user (usually nobody or httpd).
# cgitmpdir /var/lib/munin/cgi-tmp # (Exactly one) directory to include all files from. includedir /etc/munin/munin-conf.d [...] # a simple host tree
use_node_name yes
use_node_name yes [...]

Run these commands to enable and load the configuration into apache.

cd /etc/apache2/conf-enabled/ln -s /etc/munin/apache24.conf munin.confservice apache2 restart

Make sure you comment out the line Require local and add Require all granted and Options FollowSymLinks SymLinksIfOwnerMatch instead (otherwise you will only be able to access the Munin output from localhost):

nano /etc/munin/apache24.conf
Alias /munin /var/cache/munin/www
<Directory /var/cache/munin/www>
 # Require local
 Require all granted
 Options FollowSymLinks SymLinksIfOwnerMatch
 Options None

ScriptAlias /munin-cgi/munin-cgi-graph /usr/lib/munin/cgi/munin-cgi-graph
<Location /munin-cgi/munin-cgi-graph>
 # Require local
 Require all granted
 Options FollowSymLinks SymLinksIfOwnerMatch
 <IfModule mod_fcgid.c>
 SetHandler fcgid-script
 <IfModule !mod_fcgid.c>
 SetHandler cgi-script

Restart Apache:

service apache2 restart

Then restart Munin:

service munin-node restart

Install munin node on XU4

apt-get install munin-node munin-plugins-extra 

Edit munin node configuration

nano /etc/munin/munin-node.conf

Change munin node identification and allow probe

host_name XU4.local 
allow ^192\.168\.1\.230$ is the address of the munin server

Then restart Munin:

service munin-node restart

Now wait a few minutes so that Munin can produce its first output, and then go to http://munin-server-ip-address/munin/ in your browser, and you see the first statistics.


Routing protocols – recap and quick notes

Types of dynamic routing protocols:


RIP : Routing Information Protocol - AD 120
IGRP : Interior Gateway Routing Protocol - AD-100
EIGRP : Enhanced IGRP AD-90
OSPF : Open Shortest Path First AD-110
IS-IS : Intermediate system to intermediate system AD-115
BGP: Border Gateway Protocol AD-20


Property   EIGRP OSPF  BGP
Administrative Distances Internal – 90
External 170
110 EBGP – 20
IBGP – 200
Method   Advanced distance vector  Link state Path vector
Summarization   Auto and manual Manual Auto and Manual
VLSM  Yes Yes Yes
Convergence Speed    Very fast convergence Fast Slow
Timers: Update
Triggered (LAN 5/15, WAN 60/180)  Triggered when network change occurs, send periodic update LSA refreshes every 30 minutes (NBMA 30/120, LAN 10/40) Triggered (60/180)
Network Size  Large Large Very large
Mixed-Vendor Devices No Yes Yes
Use multicast  
Feature  – Partial updates conserve network bandwidth
– Support for IP, AppleTalk, and IPX
– Runs directly over IP, using protocol number 88
– Support for all Layer2 (data link layer) protocols and topologies
– Load balancing across equal-and unequal-cost pathways
– Multicast and unicast instead of broadcast address
– Support for authentication
– Manual summarization at any interface
– 100% loop-free classless routing
 – Minimizes the number of routing table entries
– Contains LSA flooding to a reasonable area
– Each routing device takes a copy of the LSA updates its LSDB and forward the LSA to all neighbor devices within area
– Minimizes the impact of a topology change
– Enforces the concept of a hierarchical network design
 – BGP provides the routing betw these autonomouse systems.
– BGP uses the concept of autonomous systems (AS). An autonomous system is a group of networks under a common administration. The Internet Assigned Numbers Authority (IANA) assigns AS numbers: 1 to 64511 are public AS
numbers and 64512 to 65535 are private AS numbers.
– IGP: A routing protocol that exchanges routing infor within AS. RIP, IGRP, OSPF, IS-IS and EIGRP are examples of IFPs.
– EGP: A routing protocol that exchanges routing infor betw different AS. BGP is an example of an EGP.
– The administrative distance for EBGP routes is 20. The administrative distance for IBGP routes is 200.
– BGP neighbors are called peers and must be statically configured.
– BGP uses TCP port 179. BGP peers exchange incremental, triggered route updates and periodic keepalives.
Operation – IP EIGRP Neighbor Table
– IP EIGRP Topology Table AD+FD
– The IP Routing Table
Neighbor Table
Topology Table LSDB
Routing Table
(LSA-> LSDB-> SPF algorithm-> SPF Tree-> Routing Table)
Function is controlled by EIGRP’s function is controlled by 4 key technologies:
– Neighbor discovery and maintenance: Periodic hello messages
– The Reliable Transport Protocol (RTP): Controls sending, tracking, and acknowledging EIGRP messages
– Diffusing Update Algorithm (DUAL): Determines the best loop-free route
– Protocol-independent modules (PDM): Modules are “plug-ins” for IP, IPX, Novel Netware and AppleTalk versions of EIGRP
Following are several types of areas:
– Backbone area: Area 0, which is attached to every other area.
– Regular area: Nonbackbone area; its database contains both internal and external routes.
– Stub area: It’s database contains only internal routes and a default route.
– Totally Stubby Area: Cisco proprietary area designation. Its database contains routes only for its own area and a
default route.
– Not-so-stubby area (NSSA): Its database contains internal routes, routes redistributed from a connected routing
process, and optionally a default route.
– Totally NSSA: Cisco proprietary area designation. Its database contains only routes for its own area, routes redistributed
from a connected routing process, and a default route.
BGP uses 3 databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:
– Neighbor database: A list of all configured BGP neighbors. To view it, use the show ip bgp summary
– BGP database, or RIB (Routing Information Base): A list of networks known by BGP, along with their
paths and attributes. To view it, use the show ip bgp command.
– Routing table: A list of the paths to each network used by the router, and the next hop for each network. To view
it, use the show ip route command.
Packet Types/BGP Message Types EIGRP uses 5 packet types:
Hello: Identifies neighbors and serves as a keepalive mechanism sent multicast
Update: Reliably sends route information unicast to a specific router
Query: Reliably requests specific route information query packet multicast to its neighbors
Reply: Reliably responds to a query replies are unicast
ACK: Acknowledgment
The 5 OSPF packet types follow:
Hello: Identifies neighbors and serves as a keepalive.
Link State Request (LSR): Request for a Link State Update (LSU). Contains the type of LSU requested and the
ID of the router requesting it.
Database Description (DBD): A summary of the LSDB, including the RID and sequence number of each LSA
in the LSDB.
Link State Update (LSU): Contains a full LSA entry. An LSA includes topology information; for example, the
RID of this router and the RID and cost to each neighbor. One LSU can contain multiple LSAs.
Link State Acknowledgment (LSAck): Acknowledges all other OSPF packets (except Hellos).
BGP has 4 types of messages:
Open: After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor.
Includes information such as autonomous system number, router ID, and hold time.
Update: Message used to transfer routing information between peers. Includes new routes, withdrawn routes, and
path attributes.
Keepalive: BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session
Notification: When a problem occurs that causes a router to end the BGP peering session, a notification message
is sent to the BGP neighbor and the connection is closed.
Neighbor Discovery and Route Exchange Neighbor Discovery and Route Exchange
Step 1. Router A sends out a hello.
Step 2. Router B sends back a hello and an update. The update contains routing information.
Step 3. Router A acknowledges the update.
Step 4. Router A sends its update.
Step 5. Router B acknowledges.
Establishing Neighbors and Exchanging Routes
Step 1. Down state: OSPF process not yet started, so no Hellos sent.
Step 2. Init state: Router sends Hello packets out all OSPF interfaces.
Step 3. Two-way state: Router receives a Hello from another router that contains its own router ID in the neighbor
list. All other required elements match, so routers can become neighbors.
Step 4. Exstart state: If routers become adjacent (exchange routes), they determine which one starts the
exchange process.
Step 5. Exchange state: Routers exchange DBDs listing the LSAs in their LSD by RID and sequence number.
Step 6. Loading state: Each router compares the DBD received to the contents of its LS database. It then sends a
LSR for missing or outdated LSAs. Each router responds to its neighbor’s LSR with a Link State Update.
Each LSU is acknowledged.
Step 7. Full state: The LSDB has been synchronized with the adjacent neighbor.
BGP Peering States
The command show ip bgp neighbors shows a list of peers and the status of their peering session. This status can
include the following states:
Idle: No peering; router is looking for neighbor. Idle (admin) means that the neighbor relationship has been
administratively shut down.
Connect: TCP handshake completed.
OpenSent, or Active: An open message was sent to try to establish the peering.
OpenConfirm: Router has received a reply to the open message.
Established: Routers have a BGP peering session. This is the desired state.
Metric (Calculation) Bandwidth+Delay Cost= 100 Mbps/Bandwidth IBGP – 0
Redistributed routes metric = IGP metric