Install f5 wireshark plugin f5ethtrailer.so on MacOS

The documentation I could find on F5 devcentral about installing the f5 wireshark plugin goes about compiling wireshark from sources, patching the code to include the f5 plugin, etc. After downloading the 2.2.0 version I could see that the plugin is already in binary format, namely f5ethtrailer.so (this goes for all platforms, except windows where this is a dll file).

To install the plugin in wireshark, you just need to figure what is the plugin directory (Wireshark -> About Wireshark (Folders tab) menu in MacOS). The copy the f5ethtrailer.so into the Global Plugins folder. (/Applications/Wireshark.app/Contents/PlugIns/wireshark/ in MacOS Sierra)

Then restart wireshark and double check the plugin is present by checking the menu Wireshark -> About Wireshark (Plugins tab)

Juniper "error: Could not create temporary directory"

Got into an issue a couple of days ago on a Junos EX virtual chassis where the following was being reporded

> show system snapshot media internal member 0
fpc0:
--------------------------------------------------------------------------
error: Could not create temporary directory

The command tries to create a temporary directory into the /tmp filesystem and it fails. Going to the shell prompt and trying to create a file there revealed the real issue (no inodes left; %iused = 100%):

% touch /tmp/a

/tmp: create/symlink failed, no inodes free
touch: /tmp/a: No space left on device

% df -hi /tmp
Filesystem    Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/md17     126M     33M     83M    28%   16382     0  100%   /tmp

Looking at the number of inodes in use, we can see that they are filled up 100% and that there were just as many files in /tmp as inodes taken. To solve this and allow some space I deleted some (most) of these files from /tmp

% df -hi /tmp/
Filesystem    Size    Used   Avail Capacity iused ifree %iused  Mounted on
/dev/md17     126M    428K    115M     0%       7 16375    0%   /tmp

MacOS append search-domain

I recently started using a Mac laptop (with MacOS Sierra) for work and one thing soon saw was that the search-domains were not appended when trying to use utilities such as ping or ssh (tough the configuration in the network preferences lists domain.com in the list of search-domains).

So, saying I have host1.domain.com using the following:
ping host1 would not resolve host1 (no search-domain appended)
ping host1.domain.com would resolve host1 (is specified in FQDN)
host host1 would resolve host1 (but that's because host uses its own resolver that is using the search-domain)

Looking for manual page of mDNSResponder - the system wide DNS resolver - this says:

 
OPTIONAL ARGUMENTS
     mDNSResponder accepts the following optional arguments:

     -AlwaysAppendSearchDomains
                                Append search domains for multi-labeled Par-
                                tially Qualified Domain Name as well as sin-
                                gle-labeled Partially Qualified Domain Name.
                                This argument is not recommended because of
                                the extra DNS traffic it generates and its
                                adverse effect on battery life.
..
     To cause mDNSResponder to run with these optional arguments when it
     launches on OS X 10.11 (El Capitan) and later, set the
     AlwaysAppendSearchDomains or NoMulticastAdvertisements boolean keys to
     true in /Library/Preferences/com.apple.mDNSResponder.plist and reboot.

If you're a newb like me on MacOS, the next question is "how do I set the boolean key to true for AlwaysAppendSearchDomains? ". I found the answer here:

sudo defaults write /Library/Preferences/com.apple.mDNSResponder.plist AlwaysAppendSearchDomains -bool YES

Then, as the manual says, reboot. Bouncing the mDNSResponder would probably also work.

DDNS and QNAP NAS

I was looking recently to allow remote access into my home QNAP NAS from remote locations.
My IP address at home is dynamic so I needed a DDNS provider and some port forwarding on the home router.
My setup at home is simple. My internet connection is over a DSL line. I have a DSL router from the ISP serving as an Wifi access point for my devices at home. It also has 4 ethernet ports and to one of them I have my QNAP NAS connected.

After looking throgh a few reviews on the internet, I choosed DuckDNS. What i liked about it the most is their variety support in operating systems and the way the dynamic update is done - through an HTTPS GET request (can use also HTTP GET, but HTTPS is recommended). Secure and implemented in any decent OS. Full specs here.
You log in with one account from various social networks (reddit, G+, facebook, twitter) and you get a token assigned with your account. Further, at this time you can use 5 subdomains.

The QNAP itself can act as a DDNS client for a few providers. The whole list is below. Duckdns is not one of them.

To make use of duckdns on the QNAP NAS I've added in the /etc/config/crontab file an entry to update my IP every 2 hours:

 0 */2 * * * /share/Valentin/duckdns/duck.sh >/dev/null 2>&1

IS-IS notes

General:
- routing protocol for ISO CLNP (Connectionless Network Protocol)
- NET (Network Entity Title) required by configuration (L3 address) Has different formats. One practical is below:
   Area (1-13 bytes)| System ID (6 bytes) | Selector (1 byte) (eg. 47.000|1921.6810.0001|00)
   Selector is 00 in a NET. The NET must begin with one octet (eg 47) and end with one octed (00)
   Selector is non 00, the address is NSAP (Network Service Access Point)
   NSAP describes a service attachment at the network layer (similar to IP protocol at the IP layer)
- operates over Ethernet 802.2 LLC  (not over the common Ethernet II)
- dual ISIS (RFC1195) supports CLNS and IP
- hierarchical with 2 level hierarchy (L2 - core)
- ignores TLVs it does not understand


Adjacencies:
- L1 area ID must be the same

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