Commit c5d1680d authored by Dominik Süß's avatar Dominik Süß

reinit to gitlab pages

parents
resources/
# All available Hugo versions are listed here: https://gitlab.com/pages/hugo/container_registry
image: registry.gitlab.com/pages/hugo:latest
variables:
GIT_SUBMODULE_STRATEGY: recursive
test:
script:
- hugo
except:
- master
pages:
script:
- hugo
artifacts:
paths:
- public
only:
- master
---
title: "{{ replace .TranslationBaseName "-" " " | title }}"
date: {{ .Date }}
draft: true
---
baseURL = "/"
languageCode = "en-us"
title = "suess.wtf"
theme = "coder" # Set the theme.
languagecode = "en" # The site’s language code used to generate RSS.
defaultcontentlanguage = "en" # The default content language.
paginate = 20 # Default number of pages per page in pagination.
canonifyurls = true # Enable to turn relative URLs into absolute.
pygmentsstyle = "tango" # Color-theme or style for syntax highlighting.
pygmentscodefences = true # Enable code fence background highlighting.
pygmentscodefencesguesssyntax = true # Enable syntax guessing for code fences without specified language.
[params] # theme parameters
author = "Dominik Süß" # Author's name.
info = "Software Engineer" # Author's job title or info.
description = "Dominik's personal website" # Site description.
keywords = "blog,developer,personal" # Site keywords.
#avatarurl = "images/avatar.jpg" # Contain the path of the optionnal avatar in the static folder.
#footercontent = "Made with <3" # Add footer content
# Whether you want to hide copyright and credits in the footer.
hideCredits = false
hideCopyright = false
# Custom CSS
custom_css = ["/extra.css"]
# RTL support
rtl = false
# Multilanguage mode
langseparator = "|" # Separates menus from language selectors when site is multilingual.
# Social links
[[params.social]]
name = "GitHub"
icon = "fab fa-github"
weight = 1
url = "https://github.com/theSuess/"
[[params.social]]
icon = "fab fa-gitlab"
name = "GitLab"
weight = 2
url = "https://gitlab.com/theSuess/"
[[params.social]]
icon = "fab fa-keybase"
name = "Keybase"
weight = 3
url = "https://keybase.io/thesuess"
# Menu links
[[menu.main]]
name = "Blog"
weight = 1
url = "/posts/"
[[menu.main]]
name = "About"
weight = 2
url = "/pages/about/"
---
title: "About"
date: 2018-02-24T18:06:02+01:00
menu: true
---
My name is Dominik Süß and I am a student from Vienna.
Things I like to do:
* Writing nice code
* Designing innovative systems
* Mess with systems
* Automating things
Skills:
* Go, Haskell, C# & Elixir
* Network-`{Management, Monitoring, Design, Exploitation}`
* fluent in English as well as a minimum amount по русски
* certified junior project manager
* thinking outside of the box
If you think I'm the right guy for the job, contact me at <a href="mailto:[email protected]">[email protected]</a>
```
-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEWoPn3RYJKwYBBAHaRw8BAQdAOWQy7jGGUzuZwJ8972iXNzsGF/q01AkuBGsu
QHI1zWW0LERvbWluaWsgU8O8w58gKHRoZVN1ZXNzKSA8ZG9taW5pa0BzdWVzcy53
dGY+iJAEExYKADgWIQRfR5ROXF8Amoay0MqPNVQu4p/rggUCWoPn3QIbAwULCQgH
AwUVCgkICwUWAgMBAAIeAQIXgAAKCRCPNVQu4p/rgpkWAQCqySLCFS5FdVk4ml0L
+18jk8CiMb3b0Sh05J0sGVFFvgD/eALs+DbkfpfSfUNUKPQJSW3hK2E4zniMl7IV
b+8/RAS5Ag0EWoPoCQEQAKzndI6B1zmVYBeVoFZTyUrr6l6dFUNn0LIdLdflmxLu
Gd3+MgVNmbcN3eBgTqA6EbDOWZA6CbOcm5hIusBxUoCaU1ihcvVci6wc/nVEJg0G
KeRicpc654fZ4BvABLCwTEIn9ZnGy3aACwu3q0HuV08LK8SG6CVTdiGB5SPV1Huj
vSK2XByLch4KisZLMHMq4/G16s2hMuVfkZi0C2AgiEpxKiRrVDf/GHS52o9Csl2l
L6+S/yDP8/w1U+C91xVNt6KKENd4gtUr9gcBx5Ocrgbre/PDeLZ7pCOSh1aIi5tT
bBFn9rpH5gPruF7tKJXPKCfPn2oXTZRYLzMQSDMwuGKVfS12J5aeNn6/3aM1ItWu
M6fD04AezpfFKZaz011eDxR647AL+Cn/hMDL3AZcTNHAAu6e/XzOAIMh7ebm/1nF
Rg/ZczCn0rygzSc/H+LPJuaXFNklXTh6jN/ekjst15i+xbdUrqNZqO6HdYO896wg
YiH/xd4MsGeuTWa4tBT//RoTeIjbxYgSQtCl7+ENynm26paLi3630eIwDsBA61Z3
PJgDG+vawOc0/GnDiIaR7ZtSTO+I/8PZCv8yDMWBy27e9TTVOVrKI65n2dRNWcoF
cOkiytTJkKRNBCiZ+AHK7y9nIhutR/c2xFcEb12Oh1Qwd2L4TL+6UqYd47cMRBzL
ABEBAAGJAq4EGBYKACAWIQRfR5ROXF8Amoay0MqPNVQu4p/rggUCWoPoCQIbAgJA
CRCPNVQu4p/rgsF0IAQZAQoAHRYhBDymcxDPp7dfB480tJsd20tFuGgGBQJag+gJ
AAoJEJsd20tFuGgGjbQP/j8X6X0eOugxHI7zZ1J3iKo65aseJTkrB1nfKi9B/Rxy
IHqLigx5KO84J/Ps0CL/yFs3BbW+86vbLf6k2b12CPeCI2XZFJdad1IbQpDzKfP/
AVW1G1R93wQJDoVF8qCXdqJlMCEaffka+7XbMxKnsC7Hf0bmKdQH11kLt9gsuJXO
ZZ87fzytQ58CO/nkCwE+aXE5GfdKOpccnHlPOOj/p1SwdgwGJxd1Utr0G7xffQVA
VPV3zjFVNo8Ch0DUpIdzszu5JvtR9+01CskLwDiU3Qh6aBrSmzXZxtuHpOkC8emJ
RxsJspYuFFzrSMlri1wtTB7hAvm+OOm7L1ssh8CCZ9S7FmjtfnprhS8gPaIP0ngo
7MyjdAn9bSqiHBmS31xCe09jKbX9gpxuodKNVa+yBCpH2u7xl88tBzMJWyEF7Kjw
yGKmEtv8cqA2wKtkxbaW5oihPchS4oLAd71TIH/AvKUYSvq2hH2J+HF91TPY0B8x
GrGGF51ICoT5FCWxR7XXlvlllpUsR/jSvNwHu6RWZhqPnAy0GI6AbbSnx0KMMyD9
VH3H8dZZZObm9BJJhUnpvFigDkxfKRYtTvNajqtjxUl+uB3stG1L3rmFLgNAMiVh
rkfqK4n3NKA+zgIzy0RfG9en8H4yt4NOLXC1KnM18b0yaa+DvYFWqZymZZk8Sbn+
a1wA/Roe1qUYcIeAQpPssIi3pH8sZr6qNJepQa85d1Ma9pVNAQCUwdFKdpRDU01n
ZYXl/AJ//phbq1mRCeoKU27slNqeCLkCDQRag+gsARAAy01TZPle+KxV2TJ3XT5X
ewoYtUitwH2rAhzFwNnGJ/0yYdtvfmv1Wls9j35PgOobdPaa2eJsydAxhHOXmUPc
gSp7DG9qFbfaGIBR0VgI3h/fShJcZnbmJR6/+QfbE8ipqwxlg7tZ8YLv995kKbuO
YRmE0VFSMQaeFdjNWh91ZtJYtoz0XNrvFABF2+eKHJS3ZuRF2ENi34CU5/0hmjyS
Cx1AobgpSCL245cNTfm7bXmzS/bC+u9ttA6HB8q6ZVKXdvS+n7HdQBsAfwo4qBjI
FfEf8UXDw6bjgyrHT6VbQVkbZ/AJ/1VIxO54X9KdcP37BIIg1xKjPWioGfJKwrQC
fRx5Etz3+Q92Ti+bYJ3RqryWlURMBCm5ko1DdMbES4E7RYl+yxtA03wAqbbE10cW
1hA+X3jZ3miL6Kw05ONX3h29gkQ6XC+E8WYeXF4aP/UeesMLqVFk/raT9WZn/OXP
VtWybYOBv3Wfk5lvRqr4kYTMziMjMVRVDRx/dd2FbtD70CJ61lCQn+AbZth8zLnf
hSYk1h8sFLAJ3VQORAfiirbfAPTSeK5dOS8gYR+idd2ETB/TXkaKUqkhu+7Sp419
pGAOehPWaRiy9wnavmFrFxypUkYBIHmnO+PfA1LSb2lb8oWa33JiuT2uUjzsbc8F
PEqgfDtV/HKvQvXNH973cQsAEQEAAYh4BBgWCgAgFiEEX0eUTlxfAJqGstDKjzVU
LuKf64IFAlqD6CwCGwwACgkQjzVULuKf64I2ugD/WWLyKKJ3wSF6j62zKmj0Lefh
vBYsw2DlNdUhm7CGk34BANyTQ/XDMYYVTmC2KZtI4HIhkoY5dNQkanF3mcPmZ5ED
uQINBFqD6D8BEAC/HLm3MHhZKGkaY2+JUYD+gqHtiKEPSsfhn2Z+UwpO7LqWfouN
F4CkcJhe+rOOhzGa4/F9PvydTB0WA9WJFf+QXGXNObow3+E25NO+skzThcaOPrzR
TUfEXIVlaMI/UY/+pjqiMVSr1L8uXQWOmGvp6YunwpTj98OtpeUxLCZr06vZpY8Z
OsLJ1icHFPRPWAVV+eQu4SFJtQ2Cq/94DortdYGjyLKoY+6gWiAJKyAKd00yodbq
Fwu++nJXLsxr1JwyOQClxDHakzwMrjS/Mlfs4AF6BPFefvGt0B7S29SgQaJlGoyd
wmELlL8qGMeyyiwBVNAZe2mldTEANJQqHQWenRFaQ6VXCNrGCvKh+VbqoxBxbOz5
yCHNndj9V/zlTzNlcGXj1/WidD2RbGuENhF0A0hv9xRROoTegYPUfeC7ULYFUyPd
7vyqfc9E6joB4ThkhnN5+f9f+Knfo81StLMNmTvjj+lsfbG9e6GfeWifRnBdNb3m
IEh9bjzThdSOVCX0ldpVk5afLqsRCzIAFIxXvwRS31Jix+t90rQWego+bnfAv1Hi
Z/+R54I3wMPyY9ZA0C+6UlSjUfQVXur9JGGXz7ChSihs6NCYRsWMvopeB0axHpYy
ycJJWE3fdfjiVa5gN+dj9dmWgNTGcq0gSJCOFlfMG3DEmV89MBQP9PKGEQARAQAB
iHgEGBYKACAWIQRfR5ROXF8Amoay0MqPNVQu4p/rggUCWoPoPwIbIAAKCRCPNVQu
4p/rgrvbAQDZw+JjiHvP1SX7q+7QhgTyhaY8QnZA1JIT31Eo2Dq//gD/Z+JncbUJ
JfKoV3t+DrrfFI7/0sbRSYpVO9qFqEPusg4=
=63tW
-----END PGP PUBLIC KEY BLOCK-----
```
---
title: "Pixels"
menu: true
---
Collection of pixel art done by me:
![toast_ghost.gif](toast_ghost.gif)
---
title: "BGP"
date: 2018-03-09T12:49:16+01:00
categories:
- matura
- networks
draft: true
---
> ... or how the internet works
The _Border Gateway Protocol_ is the backbone of the internet. But how does all
of this actuall work? For this, we first have to establish what an _Autonomous
system_(AS) is.
In the context of BGP, an AS is a self contained network under controll by a
single entity. It is the smallest network unit for BGP. The "Internet" as we
know it, is made up of a huge number of systems interconnected. But it is
obvious that not every AS can be connected to every single remote AS. This is
where BGP comes into play.
An AS needs to reach the internet somehow. We now have several Options:
* Multi Homed: We connect the AS to two different remote systems. This can
either be used to provide failover or load balancing.
* Dual Homed: We connect the AS to one remote AS using two physical links. This
allows the failure of a pyhsical link (for example when an underground cable
gets destroyed by accident) but does not provide any connectivity in the event
of provider downtime.
* Stub: We simply connect our AS to one remote AS with a single link, using the
connected AS as a default gateway.
* Transit: We connect to multiple systems, allowing their traffic to pass
through our network. This is mostly used by ISPs.
It is also possible to combine the various options and create a Dual-Multihomed
AS.
The routers used to connect to remote systems are called autonomous system
border routers (ASBR). An AS needs at leas one ASBR, but can have as many as it wants.
## ISP Tiers
Many tiers of ISPs exist and they are interconnected at the so called Internet
Exchange Points (IXP). To improve performance, they are directly connected via a
layer 2 network. Two ISPs can either have a peering or a transit contract. While
peering is usually "free" (the two parties still have to pay for the physical
connection and rental space at the IXP), transit contracts have to be bought.
Tier 1 ISPs are usually peered with other tier ones and smaller, tier 2 and 3
ISPs buy a transit connection to them.
To keep track of the various AS peerings, the IXP keeps a peering matrix
## Planning the BGP Network
![Network Topology](topology.png)
For this example, we'll connect `AS 1` to two different remotes: `AS2` and `AS2`.
First of all, we have to enable BGP on every router
```
ASBR-1(config)# router bgp 1
```
Unlike with OSPF, the id is _not_ the process id but our AS number.
To connect with the partner:
```
ASBR-1(config-router)# neighbour 192.168.12.2 remote-as 2
ASBR-1(config-router)# neighbour 192.168.13.3 remote-as 3
```
Last but not least, we have to advertise our network
```
ASBR-1(config-router)# network 1.1.1.0 mask 255.255.255.0
```
And we are done. Thats all there is to BGP. Easy!
> ... or is it???
As of now, bgp seems like a simplified OSPF. But BGP is a so called "Policy
based routing protocol". This means that instead of using the path cost as a
metric, "Layer 8" (Network politics) are the main decision factor. To achieve
this, we have various tools at our disposal. A BGP router chooses the path for a
specific prefix based on _WLAM_:
* Weight: (Cisco proprietary attribute)
* Local Pref
* AS Path: Actual path to the remote AS
* MED: Multi Exit Descriminator
### Weight
When choosing which path to use, weight is the first attribute BGP looks at. It
is configured on every router and is not published on the network.
### Local Preference
In contrast to the weight attribute, the local pref setting is published.
```
|R1|\
|R3|
|R2|/
```
To choose the desired path out of `R3`, we need to set the local pref on `R1` and
`R2`. The router with the highest local pref is chosen
### AS Path
The AS Path is the full list of systems to cross when trying to reach the remote
AS. You can artificially extend this list by inserting the same AS multiple
times. This is called AS-Path prepending. Using this technique you can choose
through which path, packets enter your network
### MED
The MED is used to achieve the same goal but unlike AS path prepending, the MED
only gets published to the direct neighbour.
---
title: "Multicast"
description: "Everything you need to know about mullticast"
date: 2018-02-21T20:23:25+01:00
categories:
- matura
- networks
---
# What is Multicast?
In an IPv4 network, there are _three_ types of packets:
* **Unicast** One-to-One host communication.
* **Broadcast** A broadcast message is sent from one hoste to _all_ hosts in the
current subnet. Routers will, by definition, not forward broadcast messages
* **Multicast** Here is where things get interesting. Multicast traffic is sent
from one host to a specific group of receivers. (Cheap) Switches will forward
multicast on all ports. Routers will not forward multicast packets by default.
In order to keep everything simple, the IPv6 specification excludes any type of
broadcast in favor of an `all ipv6 devices` well known multicast group.
The main usecase for multicast is the distribution of the same data to many
clients. This applies to: Streaming services, VoIP or LAN Chat apps.
In order to receive multicast packets, a host must first _join_ a _multicast
group_. This can either be done statically or dynamically. Most of the time,
traffic is sent from the server to a group of clients (Rare cases exist where
the client sends back a multicast packet).
While Multicast works out of the box in most networks, the challenge is shaping
the traffic, so that _only hosts in the multicast group receive the data.
## Multicast Addressing
### IPv4
Multicast IPv4 addresses are a _Class D_ network. There are serveral well known
multicast ranges:
* `224.0.0.0` - `224.0.0.255`: Reserved for routing and other network protocols
such as OSPF, RIP, HSRP, etc
* `224.0.1.0` - `238.255.255.255`: Reserved for "public use. Can be used
publicly on the Internet. Many addresses in this range have been reserved for
specific applications
* `239.0.0.0` - `239.255.255.255.`: Reserved for "private" use. Will not be
routed on the internet
The most important IPv4 Multicast addresses are
| Address | Description |
| ----------- | -------------------------- |
| `224.0.0.1` | All hosts on this subnet |
| `224.0.0.1` | All routers on this subnet |
### IPv6
Multicast addresses in IPv6 use the prefix `ff00::/8`. They can either use the
[old (RFC2373)](https://tools.ietf.org/html/rfc2373) or the
[new (RFC7371)](https://tools.ietf.org/html/rfc7371) format.
```
Old Format:
| 8 Bits | 4 Bits | 4 Bits | 112 Bits |
| ------ | ------ | ------ | -------- |
| prefix | flags | scope | group id |
New Format:
| 8 Bits | 4 Bits | 4 Bits | 4 Bits | 4 Bits | 8 Bits | 64 Bits | 32 Bits |
|--------|--------|--------|--------|----------|--------|----------------|----------|
| prefix | ff1 | scope | ff2 | reserved | plen | network prefix | group ID |
```
The most important IPv6 Multicast addresses are
| Address | Description |
| --------- | ---------------------- |
| `ff02::1` | All link-local devices |
| `ff02::2` | All link-local routers |
### Ethernet
To convert a Multicast IP Address to a MAC address, we use the `0100.5e` prefix.
To complete the MAC, the last _23_ bits of the MC address are used.
```
Decimal: 224 . 65 . 130 . 195
Binary: 11100000.01000001.10000010.11000011
Hex: 0100.5e
Binary: 0000000100000000.01011110.0
Combined: 0000000100000000.0101111001000001.1000001011000011
Hex: 0100.5e41.82c3
```
Because only the last 23 bits are used, every Multicast MAC can match 32
Multicast IP Addresses.
# Multicast Routing
Multicast routing has to be explicitly enabled
```
Switch(config)# ip multicast-routing
```
Multicast routing protocols make sure that only the correct clients receive the
data.
There are several multicast routing protocols available:
* Protocol Independend Multicast (**PIM**)
* Multicast OSPF (**MOSPF**)
* Distance Vector Multicast Routing Protocol (**DVMRP**)
* Core-Based Trees (**CBT**)
Terminology:
```
|---|
|+++| Multicast Server
|---|
|
| <- Upstream
|
_
/ \
| | Router
\_/
|
| <- Downstream
|
|
|---|
|+++| Client
|---|
```
## Reverse Path Forwarding
To guarantee a loop free multicast environment, switches perform an RPF check on
incoming multicast traffic. Whenever a multicast packet arrives, the router
looks up the source address in its unicast routing table. If the incoming
interface matches the outgoing interface of the routing table, the traffic is
forwarded.
## Forwarding Trees
When the RPF Check succeds the router still has to know where to send the
traffic to. This is where Multicast Forwarding Trees come into play.
They controll the flow of multicast traffic inside the network and exist on a
per-group basis.
### Source Trees
Source trees are the most basic forwarding trees. Their root is the multicast
source and they branch to reach every client. Because they use the shortest
path, they are also called _shortest path tree (SPT)_.
### Shared Trees
Shared trees utilize a so called _Rendezvous Point (RP)_. Multicast traffic is
always sent toward the RP using a source tree. The RP then builds a seperate
source tree towards the receivers.
At first glance, this just sounds like extra overhead so why even use Shared
Trees?
In a network with many sources and destination, every router has to build their
own tree when using source trees. This is very processor heavy and might be too
much for small access layer devices. With shared trees, only the route to the
rendezvous point has to be stored. The RP is usually a strong device, capable of
handling the entire multicas traffic of the network.
## PIM
_Protocol indepenedt Multicast_ is a so called Multicast routing protocol.
Although the name suggests tht is indepenedt of any other protocol, PIM strongly
depends on the unicast routing table.
PIM is also responsible for creating the multicast tree, and "pruning" the tree
so that no traffic is sent unnecessarily down a link.
PIM can operate in multiple modes:
* Dense Mode (`PIM-DM`)
* Sparse Mode (`PIM-SM`)
* Sparse-Dense Mode (Cisco proprietary, `PIM-SM-DM`)
### Dense Mode
Dense mode relies on flooding the network with multicast traffic.
All downstream routers recieve the multicast packet until it times out. To
minimize traffic, routers send a pruning message upstream when:
* The RPF Check fails
* A leaf router (has clients directly attached to it) has no receivers
* A non leaf router recieves a prune message from all its neighbours
Dense mode is most usefull when:
* Senders and receivers are in close proximity to another
* Few senders - many receivers
* Much multicast traffic
* Constant stream of traffic
Dense mode is _not_ the method of choice for enterprise and service providers
because of its scalability and flooding properties.
### Sparse Mode
Spares mode is based on the assumptions that the multicast group members are
sparsely distributed throughout the network and that bandwith is limited
Sparse mode multicast traffic is first directed to a RP. After traffic starts
flowing, the routers in the path optimize it to remove unnecessary hops.
#### RP Distribution
Following methods are available to automate the distribution of the RP:
* Auto-RP
* Bootstrap router (BSR)
##### Auto-RP
Auto-RP utilizes a seperate Router called the RP Mapping agent. All candidate
RPs announce their availability every minute to 224.0.1.39 (Cisco-RP-announce).
The mapping agent then sends out the Group-to-RP mappings to 224.0.1.40
(Cisco-RP-discovery) and will continue to do so every 60 seconds.
##### BSR
BSR is only available in PIMv2. The BSR sends out special BSR Packets with a TTL
of 1. This packet is flooded by all receivers. If there are multiple BSR
candidates available, the BSR with the higher priority wins. Downstream routers
advertise their group ranges to the BSR which then continuously floods the new
information through the domain
---
title: "Reviving an old NetApp FAS2040"
date: 2018-04-13T17:39:38+02:00
---
So this week I revived an old netapp FAS2040 system. It was a big mess.
This was the architecture I was working with
![arch.png](/posts/reviving_na/arch.png)
The two core switches are cisco devices and na1 & na2 are two FAS2040s.
# Getting the licenses
Since the FAS2040 is now officially EOL, we must resort to less “official” ways to get ourselves the cf license. This license is needed in order to enable takeover.
> Disclaimer: Always check with your netapp affiliate for all your license/rip-off needs
Luckily the licenses on these old devices only consist of 7 letters, case insensitive. This gives us 26^7 = 8031810176 possibilities. At first this may sound like a lot but we only need to find one valid cf license.
Using the crunch tool and some shell magic, I was able to find a 428 node license in under five minutes.
```.bash
./crunch 7 7 \
| awk '{print "license add " $0}' \
| ssh [email protected] \
| grep -vi "invalid license code" \
| tee out.txt
```
This command leaves us with a text file called out.txt containing every tried license code and its result, if it wasn’t invalid.
Let’s see what we’ve got:
```
grep -i "a .* node license" licenses.txt
A snapmanagerexchange 293 node license has been installed.
A syncmirror_local 293 node license has been installed.
A cf 124 node license has been installed.
A snapvalidator 423 node license has been installed.
A snaplock 103 node license has been installed.
A cf 6 node license has been installed.
A snaplock_enterprise 480 node license has been installed.
A snapmanagerexchange 208 node license has been installed.
A snaplock_enterprise 53 node license has been installed.
A env_exception 136 node license has been installed.
A flex_clone 98 node license has been installed.
A snapmanager_vi 163 node license has been installed.
A sv_application_pri 435 node license has been installed.
...
```
# Setting up HA
To start using the cf features, you need to reboot the two filers.
> Be careful! Check your /etc/rc file first or you may lose your network configuration
With that out of the way, takeover now simply works™
# Understanding the NA takeover model
NA takeover does not behave like failover on the ASA or any other system I know of. The two filers communicate over the enclosure backplane and operate independently of one another. In the case of failure, the second controller takes over the functionality of the failing one. This means you don’t have a floating IP between these two devices. Instead, the partner attaches the IP Address of the failed node to its own interfaces.
For a concrete example, this is the /etc/rc file of our first (primary) controller:
```
hostname NA1
ifgrp create lacp ifgrp_ab -b rr e0a e0b
ifgrp create lacp ifgrp_cd -b rr e0c e0d
ifgrp create single ifgrp_200_ha ifgrp_ab ifgrp_cd
ifgrp favor ifgrp_ab
ifconfig ifgrp_200_ha 192.168.1.200 netmask 255.255.255.0 partner ifgrp_200_ha
route add default 192.168.1.200 1
routed on
options dns.enable off
options nis.enable off
savecore
```
and the second
```
hostname NA1
ifgrp create lacp ifgrp_ab -b rr e0a e0b
ifgrp create lacp ifgrp_cd -b rr e0c e0d
ifgrp create single ifgrp_200_ha ifgrp_ab ifgrp_cd
ifgrp favor ifgrp_ab
ifconfig ifgrp_200_ha partner ifgrp_200_ha
route add default 192.168.1.200 1
routed on
options dns.enable off