BGP notes

Neighbor states:

Idle: all connections are refused
Connect: wait for TCP to establish
Active: initiates the TCP connections
OpenSent: Local waits for Open message from peer. After receiving open, if no errors BGP sends keepalive
OpenConfirm: BGP waits for keepalive or notification
Established: Can exchange update, notification and keepalive

Message types:

Open: sent when TCP 3way is complete. Initiates the BGP session and contains details about BGP neighbor and supported and negotiated potions
Update: Transports routing information between BGP peers
Keepalive: On BGP level. Contains the BGP header and has no data.
Notification: sent when something is wrong (eg. unsupported options in the open message, hold time expires)
Refresh: BGP does not readvertise sent routes by default. Route refresh supports soft clearing of BGP sessions by allowing routes already sent to be re-advertised

BGP attributes:

- contained in the Update message, describes the prefixes in the message
- used to influence route selection and select best path

Local preference:
- exchanged by IBGP peers only
- used to set the exit path from the local AS

OSPF notes

Packet types:
Hello (type1): used to discover neighbors, build and maintain adjacencies
DBD(type2): database description packets. These are a summary of the topological database. Detects MTU mismatches (fragmentation is not allowed). Have bits I (start of DBD), M (more ackets DB), MS(master/slave used to decides who starts sending DBD first)
LSR(type3): link state request. Request specific link state advertisement (LSA) from a neighbor, typically after receiving DBD packets and noticing the local link state database is out of date
LSU(type4): link state updates. Advertises LSAs into the network . Can contain multiple LSAs
LSAck(type5): link state acknowledgements. Acknowledges LSUs

Packet formats:

OSPF packet:
Version | Type | Length | Router ID | Area ID | Cksum | Auth type | Auth data | Data

LSU packet (type 4):
Number of LSAs | LSA header | LSA data | LSA header | LSA data | ...

LSA header:
Age | Options | Link-state Type | Link-state ID | Advertising router | Seq number | Cksum | Length

LSA types:

Router LSA (type 1):
- has area scope
- describes local router
- standards LSA header  plus some extras (only a few showed below):
   - 5 bits set to 0 followed by bits 6,7,8  set for virtual links (V), ASBR (E), ABR (B)
   - number of links (2 bytes)
   - link ID (4 bytes)
   - link data (4 bytes)
   - link type (1 bytes)
   - metric (2 bytes)

 Link-type: Type 1 (P2P). Link ID: Neighbor Router ID. Link data: Local interface IP
 Link-type: Type 2 (Transit). Link ID: DR's interface IP. Link data: Local interface IP [broadcast segment]
 Link-type: Type 3 (Stub). Link ID: Network number. Link data: Subnet mask [passive interfaces, loopback interfaces]
 Link-type: Type 4 (Virtual link). Link ID: Neighbor Router ID. Link data: Local interface IP

Catfish fails to update database

I have just tried Catfish for local files search. I am using it (at time of writing version 1.2.2) with Debian Jessie  and Xfce desktop.
Every time I opened catfish I was prompted to update the database as it was never updated. I was updating this with administrative rights, but after closing and opening the application the same message was displayed.

From the message prompt catfish looks for the database in /var/lib/locate.findutils/locate.findutils.db.
The catfish utility is based on locate and find and the locate database is updated by the updatedb command.
The man page of updatedb for my debian system says:

       --output=dbfile
              The  database  file  to  build.  Default is system-dependent.  In Debian GNU/Linux, the default is /var/cache/locate/locatedb.

cli remote management of ESXi virtual machines over ssh

One of the ways to manage ESXi virtual machines is through vim-cmd commands. You can look at a quick tutorial of the command here.

Let's say there are a multitude of ESXi servers in your environment and you'd like to manage some virtual machines through cli.
One way to do this is to run vim-cmd commands over ssh. For example, I have 2 ESXis named in the example esxi1 and esxi2. On both of them I have one VM:

~$ ssh root@esxi1.localdomain "vim-cmd vmsvc/getallvms"
Vmid             Name                                         File                                  Guest OS       Version             Annotation
7      Linux                       [datastore1] Linux/Linux.vmx                                 debian6_64Guest    vmx-08

~$ ssh root@esxi2.localdomain "vim-cmd vmsvc/getallvms"
Password: 
Vmid           Name                                      File                                  Guest OS        Version             Annotation
13     VSRX                   [datastore1] VSRX/VSRX.vmx                                   otherGuest          vmx-09    VSRX OVF Template

So, this works fine and nice and actually there's nothing special about it. It's just running remote commands over ssh.

If you'd like to make things more easy, you can use ssh public key authentication for the remote esxi hosts (no need to type in the password every time you want to run a command).
I wrote some bash functions to make it even easier (to remember) and shorter to type.
This is what I have among other functions and things in my .bashrc file:

function start_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.on" "$2";}
function stop_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.off" "$2";}
function reboot_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.reboot" "$2";}
function getallvm () { ssh root@${1}.localdomain "vim-cmd vmsvc/getallvms" ;}
function powerstate_vm () { ssh root@${1}.localdomain "vim-cmd vmsvc/power.getstate" "$2";}
function getnetwrorks () { ssh root@${1}.localdomain "vim-cmd vmsvc/get.networks" "$2";}

How to remove Juniper ethernet encapsulation from pcap packet capture

When capturing packets on a Junos device, the output packet capture will include a Juniper ethernet header.
Example of such capture:

tcpdump -c1 -nvvr capture.pcap

reading from file JTAC.pcap, link-type JUNIPER_ETHER (Juniper Ethernet)

14:58:06.569634

 Juniper PCAP Flags [Ext], PCAP Extension(s) total length 16

   Device Media Type Extension TLV #3, length 1, value Ethernet (1)

   Logical Interface Encapsulation Extension TLV #6, length 1, value Ethernet (14)

   Device Interface Index Extension TLV #1, length 2, value 149

   Logical Interface Index Extension TLV #4, length 4, value 872

 -----original packet-----

     ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.128.123.19 tell 10.128.123.254, length 28

To remove this header we need to chop the pcap [-C]  (in my case the first 22 bytes) , adjust the frame length [-L] and specify that the new frame type [-T] (ethernet in my case). I am using editcap version 1.12.1 and the default output type for the new pcap is pcapng. As I can see there's a problem when converting with this output type, so I am using libpcap as the output type.

editcap -C22 -L -F libpcap -T ether capture.pcap cap_libpcap.pcap

As you can see the Juniper ethernet header is  gone.

tcpdump -c1 -nvvr cap_libpcap.pcap

reading from file cap_libpcap.pcap, link-type EN10MB (Ethernet)

14:58:06.569634 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.128.123.19 tell 10.128.123.254, length 28