Jekyll2018-09-23T14:16:07+02:00https://weiti.org/Blog @ Weiti.ORGThoughts, stories and ideas. Some technical stories or fail/success stories, some other things i want to publish and hopefully usefull content ...My DN42 Peering Types (explained)2018-09-23T00:00:00+02:002018-09-23T00:00:00+02:00https://weiti.org/dn42/2018/09/23/my-dn42-peering-types<p>I use some peerings types documented in my aut-num object within the registry, to be more exact, what theses peering times mean to me and
for the peering partner i tried to explain wyh i use them as is use them. ( i leave out the IXP Type of peering as i had no active peering with
an IXP in DN42 currently.)</p>
<p>The following picture hopefully helps to understand the descriptions of the peering types later on:</p>
<p><img src="https://weiti.org/assets/img/MY-DN42-Peering-Types.png" alt="MY DN42 Peering Types" /></p>
<h1 id="peering-type-standard-dn42-peering">Peering Type: Standard DN42 Peering</h1>
<p>With the Type “Standard DN42 Peering” i would describe the normal peering used by DN42 participants. They accept all prefixes from their
peering partner (maybe they do some ROA Filtering and filter on DN42, FreiFunk, ChaosVPN Aggregates, …) and send them all their prefixes.</p>
<p>Nothing is wrong with that, and thats the peering type i’m started with also. But if you increase your network and every peering sends you ~400-500
prefixes (ipv4 <em>g</em>) and something went wrong (loop, rogue announcement, …) your network gets this information on every peering. This can set your nodes
under heavy load. Also why did you need all prefixes on all 20 peerings on a node? Or on 40 peerings in your network?</p>
<p>Therefore i decided to be more strict on my peerings.</p>
<h2 id="my-standard-peering-types">My Standard Peering Types</h2>
<h1 id="peering-type-peer">Peering Type: PEER</h1>
<p>Let’s look on my normal default peering type. PEER type means the following: i learn all prefixes which originates (route objects in registry) from the peering partner ASN. Vice Versa i will send the peering partner all my originating prefixes, and all prefixes i learned from PEER, CLIENT peerings (and originating routes from my UPSTREAM peerings).</p>
<p>For example, i learn all AS3 originated prefixes (as documented in the registry). I will send AS3 all routes originates from AS5, AS4, AS2 and AS1. I will not send any routes from other ASN’s to AS3. So AS3 will not see AS51/AS51 or any other prefix on this peering connection!</p>
<p>So AS3 can connect to AS1,AS2,AS4,AS5 ressources through me, but won’t see AS51 ressources.</p>
<h1 id="peering-type-client">Peering Type: CLIENT</h1>
<p>The second peering type CLIENT, is very similar to the PEER Type, with one change. I will send all my known prefixes to the CLIENT. This means i learn all prefixes which originates (route object in registry) fromt the peering partner ASN. Vice Versa i will send all known prefixes from UPSTREAMs, PEERs, CLIENTs to the peering partner ( with ROA checks of course).</p>
<p>For example, i learn all AS2 originated prefixes (as documented in the registry). I will send AS2 all routes i know, regardless from where i know them (UPSTREAM, PEER, CLIENT, …). So AS2 should see the full DN42 table (hopefully AS51/52 has some other peerings which i see through my UPSTREAMs).</p>
<p>Normally with this kind of peering AS2 should be able to connect to all DN42, FreiFunk, ChaosVPN ressources i get from any of my peerings. But ASN’s connected only to AS2 wouldn’t be able to use these connectivity unless they had some second peering which do TRANSIT/UPSTREAM for them.</p>
<h1 id="peering-type-upstream">Peering Type: UPSTREAM</h1>
<p>The third used peering type is UPSTREAM. From an upstream peering i will learn all their prefixes regardless if they are originate from their AS or not. Vice Versa i will send the peering partner all my originating prefixes, and all prefixes i learned from PEER, CLIENT peerings (and originating routes from other UPSTREAM peerings).</p>
<p>If my CLIENTs or my own ressources needs to use some ressources from AS10 (which i’m not peering directly with) i will use my upstream ressources to connect to them. Not every node in my network has UPSTREAM peerings, so maybe the routing is through another node of my network to the UPSTREAM peering partner.</p>
<h2 id="special-peering-types-in-use">Special Peering Types in use</h2>
<p>I use two special peering types: PEER w AS-SET and BiDi UPSTREAM. They are only used case by case, but i will try to explain them in short:</p>
<h1 id="special-peering-type-peer-w-as-set">Special Peering Type: PEER w AS-SET</h1>
<p>On this Peering type i generate an AS-SET in my internal IRRd to allow additional ASN/prefix ressources to be learned & used from the peering partner. For exampple if AS5 has such a peering with me, the AS-SET includes AS5, AS51, AS52 and therefore i learn prefixes originated from all three ASNs through this peering (of course if AS5 sends them to me). The other direction will be the same as PEER type (only PEER, CLIENT, UPSTREAM originated prefixes).</p>
<h1 id="special-peering-type-bidi-upstream">Special Peering Type: BiDi UPSTREAM</h1>
<p>Well this is more or less the “Standard DN42 Peering” i described first. I learn all from this peering partner (of course with ROA checking) and send them all i know. I think this peering has also the same problems than the “Standard DN42 Peering” and i will only use this very rarely.</p>
<p>Hope this explain the behaviour of my network a bit more.</p>I use some peerings types documented in my aut-num object within the registry, to be more exact, what theses peering times mean to me and for the peering partner i tried to explain wyh i use them as is use them. ( i leave out the IXP Type of peering as i had no active peering with an IXP in DN42 currently.)Bird2 as FlowSpec Controller (Part 1)2018-06-25T00:00:00+02:002018-06-25T00:00:00+02:00https://weiti.org/network/2018/06/25/flowspec-bird2-controller<p>The last days i spent several hours to try Bird2 as FlowSpec Controller and hopefully the post helps others to
avoid some of my challenges.</p>
<p>First what means Client/Controller in an FlowSpec environment?</p>
<ul>
<li>A FlowSpec Controller is able to create FlowSpec Rules and Actions and announce them via BGP to Clients.</li>
<li>A FlowSpec Client is an BGP Listener which receives the FlowSpec Rules and execute the corresponding actions. One of
the advantages of proper FlowSpec Clients are, that the actions don’t need more implementations on the Client side (don’t need
to write drop ACLs/Firewall Rules for an discard action).</li>
</ul>
<p><strong>Info:</strong> the following information belongs to Bird 2.0.2, 06/2018:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Bird2 is capable to announce FlowSpec Rules and receive them, currently there
is no implementation to act on actions in the Rules (maybe on your own with
scripts/cron/birdc). So Bird2 acts best as Controller or reflecting FlowSpec
Rules.
</code></pre></div></div>
<p>Implementing Bird2 as FlowSpec Controller is very easy, you need some flowspec tables, a static protocol and some configuration on
the BGP Peering. The following example will <em>discard</em> all packets from <em>198.51.100.10</em> to <em>203.0.113.53</em>:</p>
<figure class="highlight"><pre><code class="language-shell" data-lang="shell">flow4 table flowtab4<span class="p">;</span>
<span class="c"># RFC 5575 flow specification</span>
protocol static flowstat4 <span class="o">{</span>
flow4<span class="p">;</span>
route flow4 <span class="o">{</span>
src 198.51.100.10/32<span class="p">;</span>
dst 203.0.113.53/32<span class="p">;</span>
<span class="o">}</span> <span class="o">{</span>
bgp_ext_community.add<span class="o">(</span> <span class="o">(</span>generic, 0x80060000, 0x0 <span class="o">)</span> <span class="o">)</span><span class="p">;</span>
<span class="o">}</span><span class="p">;</span>
<span class="o">}</span></code></pre></figure>
<p>And in the Peering Configuration you need to add a FlowSpec Channel:</p>
<figure class="highlight"><pre><code class="language-shell" data-lang="shell">protocol bgp XYZ <span class="o">{</span>
...
<span class="c"># IPv4 Flowspec (1/133)</span>
flow4 <span class="o">{</span>
<span class="c"># connects to flowtab4 table by default</span>
import all<span class="p">;</span>
<span class="nb">export </span>all<span class="p">;</span>
<span class="o">}</span><span class="p">;</span>
...
<span class="o">}</span> </code></pre></figure>
<p>On an cisco ASR-1002 with IOS-XE 3.16 the config snippets are really, really simple, the first one will ensure, that the flowspec actions will be
executed on every interface of the router:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>!
flowspec
address-family ipv4
local-install interface-all
!
</code></pre></div></div>
<p>Additional add flowspec afi to your bgp config:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>!
router bgp 65000
[...]
!
address-family ipv4 flowspec
neighbor <bird2-neighbor-ip> activate
exit-address-family
!
[...]
!
</code></pre></div></div>
<p>You can see the flowspec rules and action with the following command on the ASR:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ASR-1002#show flowspec ipv4 detail
AFI: IPv4
Flow :Dest:203.0.113.53/32,Source:198.51.100.10/32
Actions :Traffic-rate: 0 bps (bgp.1)
Statistics (packets/bytes)
Matched : 0/0
Dropped : 0/0
</code></pre></div></div>
<p>That was the easy part, now we want change the above rule to do rate-limiting on the flow to 50 mbit/s. And there the struggling begins, how should the
rate limit be encoded in the community?</p>
<p>After several tries and a second brain, it comes to the following:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>50 / 8 == 6.25 MByte/s
6.25 * 1024 * 1024 == 6553600 Bytes/s
Convert them to Float IEEE754 ( use some online tools,
e.g.: http://www.binaryconvert.com/convert_float.html or python2
see below):
FloatIEEE754(6250000) == 0x4ac80000
</code></pre></div></div>
<p>You can also use a python one liner to do the calculation/conversion: <code class="highlighter-rouge">python2 -c 'import struct; print "%#x" % struct.unpack("I", struct.pack("f", (((50.0 / 8) *1024) *1024) ))'</code>.</p>
<p>After this conversion the static protocol entry would look like:</p>
<figure class="highlight"><pre><code class="language-shell" data-lang="shell">flow4 table flowtab4<span class="p">;</span>
<span class="c"># RFC 5575 flow specification</span>
protocol static flowstat4 <span class="o">{</span>
flow4<span class="p">;</span>
route flow4 <span class="o">{</span>
src 198.51.100.10/32<span class="p">;</span>
dst 203.0.113.53/32<span class="p">;</span>
<span class="o">}</span> <span class="o">{</span>
bgp_ext_community.add<span class="o">(</span> <span class="o">(</span>generic, 0x80060000, 0x4ac80000 <span class="o">)</span> <span class="o">)</span><span class="p">;</span>
<span class="o">}</span><span class="p">;</span>
<span class="o">}</span></code></pre></figure>
<p>On the cisco side you will see the following now:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ASR-1002#sh flowspec ipv4 detail
AFI: IPv4
Flow :Dest:203.0.113.53/32,Source:198.51.100.10/32
Actions :Traffic-rate: 52428800 bps (bgp.1)
Statistics (packets/bytes)
Matched : 0/0
Dropped : 0/0
</code></pre></div></div>
<p>The traffic rate should be equivalent for: 52428800 / 1024 / 1024 == 50 mbit/s.</p>
<p>The next part will be explaining other actions which can be used with FlowSpec. Stay tuned!</p>The last days i spent several hours to try Bird2 as FlowSpec Controller and hopefully the post helps others to avoid some of my challenges.iBGP - BGP within AS42424239052018-01-13T00:00:00+01:002018-01-13T00:00:00+01:00https://weiti.org/dn42/2018/01/13/ibgp-bgp-within-as4242423905<p>For a better understanding here are the picture of my iBGP Mesh:</p>
<p><img src="https://weiti.org/assets/img/DN42-loopback-tunnel.png" alt="DN42 Basic Network" /></p>
<p>Every Peering has its own Bird Routing Table and i use pipes to leak from the Peering Tables to master. Following are
the details of my iBGP Peerings/Templates and Filters. The lines indicates <a href="https://www.wireguard.io">WireGuard</a> VPN Links (purple) and iBGP
Peerings (green dotted).</p>
<h1 id="used-bird-templates-for-ibgp-peerings-and-pipes">Used Bird Templates for iBGP Peerings and Pipes</h1>
<figure class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="c"># Template for iBGP Peerings</span>
template bgp iBGP_Peer <span class="o">{</span>
<span class="nb">local </span>as MYAS<span class="p">;</span>
<span class="c"># Table should be set within each Peer to T_PEERNAME</span>
igp table T_OSPF<span class="p">;</span>
path metric on<span class="p">;</span> <span class="c"># Enable comparison of path lengths when deciding which BGP route is the best one</span>
import keep filtered<span class="p">;</span> <span class="c"># Keep Filtered Routes for this peering.</span>
import where iBGP_import_peer_policy<span class="o">()</span><span class="p">;</span> <span class="c"># iBGP Import Peer Policy</span>
<span class="nb">export </span>where iBGP_export_peer_policy<span class="o">()</span><span class="p">;</span> <span class="c"># iBGP Export Peer Policy</span>
<span class="nb">source </span>address MYIPv4<span class="p">;</span> <span class="c"># iBGP Peering with MYIPv4 to add backup pathes</span>
next hop self<span class="p">;</span> <span class="c"># Set Next Hop Self for clean routing</span>
<span class="o">}</span><span class="p">;</span>
<span class="c"># Template Pipe for iBGP Peerings</span>
template pipe iBGP_Pipe <span class="o">{</span>
<span class="c"># Table had to be set in each Peer Definition to T_IBGP_PEERNAME</span>
peer table master<span class="p">;</span>
import where iBGP_routing_policy<span class="o">()</span><span class="p">;</span>
<span class="nb">export </span>where iBGP_routing_policy<span class="o">()</span><span class="p">;</span>
<span class="o">}</span><span class="p">;</span></code></pre></figure>
<p>With these Templates, a iBGP Peering consists of one file in peers4/6 directory, for example Peering Definition on dn42-uk01 for dn42-de02 aka dn42-gw:</p>
<figure class="highlight"><pre><code class="language-shell" data-lang="shell">table T_IBGP_DE02<span class="p">;</span>
protocol bgp B_IBGP_DE02 from iBGP_Peer <span class="o">{</span>
table T_IBGP_DE02<span class="p">;</span>
neighbor 172.20.175.211 as 4242423905<span class="p">;</span>
<span class="o">}</span><span class="p">;</span>
protocol pipe P_IBGP_DE02 from iBGP_Pipe <span class="o">{</span>
table T_IBGP_DE02<span class="p">;</span>
<span class="o">}</span><span class="p">;</span></code></pre></figure>
<h1 id="bgp-communities-for-as4242423905">BGP Communities for AS4242423905</h1>
<p>I added the following communities to routes i learned:</p>
<table align="left" width="100%">
<tr><th align="left">BGP Community</th><th align="left">Desription</th></tr>
<tr><td>MYPeerID</td><td>PeerID of System who learns the route( PeerID == iBGP Loopback IP)</td></tr>
<tr><td>1000 + MYPeerID</td><td>Peering Originates from an Peer on System with PeerID</td></tr>
<tr><td>7000 + MYPeerID</td><td>Route was learned from a "Customer/Peering" on System with PeerID</td></tr>
<tr><td>8000 + MYPeerID</td><td>Route was learned from an IXP on System with PeerID</td></tr>
<tr><td>9000 + MYPeerID</td><td>Route was learned from an "Upstream" on System with PeerID</td></tr>
</table>
<p>.</p>
<p>Based on this communities i update <em>local_pref</em> on iBGP egress per System. Below you find my current Filter/Routing Polica on iBGP Links.</p>
<h1 id="ibgp-routing-policy-and-importexport-filter">iBGP Routing Policy and import/export filter</h1>
<figure class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="c">#</span>
<span class="c">##</span>
<span class="c">## iBGP Policies</span>
<span class="c">##</span>
<span class="c">#</span>
<span class="c"># iBGP Peer Policies</span>
<span class="k">function </span>iBGP_import_peer_policy<span class="o">()</span> <span class="o">{</span>
<span class="k">if </span>bgp_path.len <span class="o">></span> 64 <span class="k">then return </span><span class="nb">false</span><span class="p">;</span> <span class="c"># Reject too long BGP Paths</span>
<span class="k">if </span>local_nets<span class="o">()</span> <span class="k">then return </span><span class="nb">false</span><span class="p">;</span> <span class="c"># Reject local used networks (IXP, Peerings) from iBGP Peers</span>
<span class="k">if</span> <span class="o">(</span> bgp_local_pref <span class="o">></span> 1000 <span class="o">)</span> <span class="k">then</span> <span class="o">{</span> <span class="c"># Reset local pref on iBGP Links, to do AS Path Metric only</span>
bgp_local_pref <span class="o">=</span> 100<span class="p">;</span>
<span class="o">}</span>
<span class="k">return </span><span class="nb">true</span><span class="p">;</span> <span class="c"># Allow all on iBGP Links</span>
<span class="o">}</span><span class="p">;</span>
<span class="k">function </span>iBGP_export_peer_policy<span class="o">()</span> <span class="o">{</span>
<span class="k">if </span>proto <span class="o">=</span> <span class="s2">"dn42_static"</span> <span class="k">then return </span><span class="nb">true</span><span class="p">;</span> <span class="c"># Allow Static announced routes, should be renamed to S_STATIC</span>
<span class="k">if </span><span class="nb">source</span> <span class="o">!=</span> RTS_BGP <span class="k">then return </span><span class="nb">false</span><span class="p">;</span>
<span class="k">if </span>bgp_path.len <span class="o">></span> 64 <span class="k">then return </span><span class="nb">false</span><span class="p">;</span>
<span class="k">if</span> <span class="o">(</span> bgp_ext_community ~ <span class="o">[</span> <span class="o">(</span>rt, MYAS, MYPeerID + 9000 <span class="o">)</span> <span class="o">]</span> <span class="o">)</span> <span class="k">then</span> <span class="o">{</span>
bgp_local_pref <span class="o">=</span> 100<span class="p">;</span>
<span class="o">}</span>
<span class="k">if</span> <span class="o">(</span> bgp_ext_community ~ <span class="o">[</span> <span class="o">(</span>rt, MYAS, MYPeerID + 8000 <span class="o">)</span> <span class="o">]</span> <span class="o">)</span> <span class="k">then</span> <span class="o">{</span>
bgp_local_pref <span class="o">=</span> 110<span class="p">;</span>
<span class="o">}</span>
<span class="k">if</span> <span class="o">(</span> bgp_ext_community ~ <span class="o">[</span> <span class="o">(</span>rt, MYAS, MYPeerID + 6000 <span class="o">)</span> <span class="o">]</span> <span class="o">)</span> <span class="k">then</span> <span class="o">{</span>
bgp_local_pref <span class="o">=</span> 115<span class="p">;</span>
<span class="o">}</span>
<span class="k">if</span> <span class="o">(</span> bgp_ext_community ~ <span class="o">[</span> <span class="o">(</span>rt, MYAS, MYPeerID + 7000 <span class="o">)</span> <span class="o">]</span> <span class="o">)</span> <span class="k">then</span> <span class="o">{</span>
bgp_local_pref <span class="o">=</span> 145<span class="p">;</span>
<span class="o">}</span>
<span class="k">return </span><span class="nb">true</span><span class="p">;</span> <span class="c"># Allow all on iBGP Links</span>
<span class="o">}</span><span class="p">;</span>
<span class="c"># iBGP Routing Policies</span>
<span class="k">function </span>iBGP_routing_policy<span class="o">()</span> <span class="o">{</span>
<span class="k">if </span><span class="nb">source</span> <span class="o">=</span> RTS_OSPF <span class="k">then return </span><span class="nb">false</span><span class="p">;</span> <span class="c"># For iBGP i don't want OSPF in my Routing Policy</span>
<span class="k">if </span><span class="nb">source</span> <span class="o">=</span> RTS_DEVICE <span class="k">then return </span><span class="nb">false</span><span class="p">;</span> <span class="c"># For iBGP i don't want DEVICE ROUTES in my Routing Policy</span>
krt_prefsrc <span class="o">=</span> MYIPv4<span class="p">;</span>
<span class="k">return </span><span class="nb">true</span><span class="p">;</span> <span class="c"># Allow all on iBGP Links</span>
<span class="o">}</span><span class="p">;</span></code></pre></figure>For a better understanding here are the picture of my iBGP Mesh:BASICS - Tunnels & OSPF2018-01-05T00:00:00+01:002018-05-28T17:58:00+02:00https://weiti.org/dn42/2018/01/05/basics-tunnels-ospf<p>First i had ipsec/gre for interconnecting my nodes itself, but now i completely switched to <a href="https://www.wireguard.io">WireGuard</a>. As it is really simple to setup (if you can compile an kernel module or use dkms), it is fast, high throughput and you don’t need gre as with ipsec to use for example OSPF on the links.</p>
<p>As i don’t want to setup a full mesh with <a href="https://www.wireguard.io">WireGuard</a>, i decided to only setup a few “direct tunneled” connections between some nodes and announce Node specific <code class="highlighter-rouge">Loopback IPs</code> via OSPF. With this, i had every Node reachable by any node, and if i want to setup an direct tunnel between two nodes, OSPF will get aware of this connection and use this instead of indirect connection over an other node.</p>
<p>The <code class="highlighter-rouge">Loopback IPs</code> will be used later for iBGP Peering (full mesh) between all 6 Nodes.</p>
<p>Every Node gets a minimum of two <code class="highlighter-rouge">Loopback IPs</code>, one as iBGP Peering IP and one as eBGP (or DN42) Peering IP. The <code class="highlighter-rouge">Loopback IPs</code> are shown in the drawing below, also the Tunnel setups and iBGP Peerings:</p>
<p><img src="https://weiti.org/assets/img/DN42-World-View.png" alt="DN42 Basic Network" /></p>
<h1 id="wireguard-tunnel-setup">Wireguard Tunnel Setup</h1>
<p>For Installation just look on the <a href="https://www.wireguard.io">WireGuard</a> Website for support. I use an ifupdown approach on Debian to setup my iBGP Tunnels (and most of the eBGP Tunnels, too).</p>
<p>You need a config file in <code class="highlighter-rouge">/etc/wirguard/</code> and a corresponding ifupdown config in <code class="highlighter-rouge">/etc/network/interfaces.d/</code>. For example these are my conf files for an WireGuard Tunnel between dn42-gw <-> dn42-uk01:</p>
<p>On dn42-gw:</p>
<p>/etc/network/interfaces.d/wg-ibgp-uk01.conf</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>auto wg-ibgp-uk01
iface wg-ibgp-uk01 inet static
address 172.20.175.195
netmask 255.255.255.255
pointopoint 172.20.175.198
pre-up ip link add wg-ibgp-uk01 type wireguard
pre-up wg setconf wg-ibgp-uk01 /etc/wireguard/wg-ibgp-uk01.conf
post-up ip -6 addr add fe80::de49:211/64 dev wg-ibgp-uk01
post-down ip link del wg-ibgp-uk01
</code></pre></div></div>
<p>/etc/wireguard/wg-ibgp-uk01.conf</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[Interface]
ListenPort = 23909
PrivateKey = <NOT SHOWN>
[Peer]
PublicKey = qAr6EBKEQ2D20H5bs+USOOeRJHEijEy/IAxrLxFLBRM=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = dn42-uk01.weiti.org:23110
</code></pre></div></div>
<p>On dn42-uk01:</p>
<p>/etc/network/interfaces.d/wg-ibgp-de02</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>auto wg-ibgp-de02
iface wg-ibgp-de02 inet static
address 172.20.175.198
netmask 255.255.255.255
pointopoint 172.20.175.195
pre-up ip link add wg-ibgp-de02 type wireguard
pre-up wg setconf wg-ibgp-de02 /etc/wireguard/wg-ibgp-de02.conf
post-up ip -6 addr add fe80::de49:225/64 dev wg-ibgp-de02
post-down ip link del wg-ibgp-de02
</code></pre></div></div>
<p>/etc/wireguard/wg-ibgp-de02.conf</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>[Interface]
ListenPort = 23110
PrivateKey = <NOT SHOWN>
[Peer]
PublicKey = zuRXi9t+uMW9CxlN1gy0X8ZCxeQ9Xm8RwlyIr05SbBU=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = dn42-gw.weiti.org:23909
</code></pre></div></div>
<p>And on the wg-* links i use OSFP to announce the Loobpack IPs:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>protocol ospf O_OSPF {
table T_OSPF;
area 0.0.0.0 {
interface "lo" {
stub;
};
interface "wg-ibgp*" {
};
};
}
</code></pre></div></div>
<p>This is the OSPF Config part of my bird.conf. For IPv6 i use the same config. Within the pipe from <em>T_OSPF</em> to <em>master</em>, i allow only /32 or /128 from the corresponding Loopback Network. An example of my LO Addressing, OSPF Neighbor and Routing Table from dn42-uk01 will look like the following examples:</p>
<p><strong>Loopback IPs</strong></p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ip addr list lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet 172.20.175.198/32 scope global lo
valid_lft forever preferred_lft forever
inet 172.20.175.225/32 scope global lo
valid_lft forever preferred_lft forever
inet6 fdf7:17d5:de49:4::1/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::666/128 scope link
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
</code></pre></div></div>
<p><strong>OSPF Neighbor Table</strong></p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>birdc 'show ospf neighbor'
BIRD 1.6.0 ready.
O_OSPF:
Router ID Pri State DTime Interface Router IP
172.20.175.197 1 Full/PtP 00:38 wg-ibgp-fr01 172.20.175.197
172.20.175.199 1 Full/PtP 00:32 wg-ibgp-au01 172.20.175.199
172.20.175.193 1 Full/PtP 00:35 wg-ibgp-de01 172.20.175.193
172.20.175.195 1 Full/PtP 00:36 wg-ibgp-de02 172.20.175.195
</code></pre></div></div>
<p><strong>OSPF Routing Table</strong></p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>birdc 'show route table T_OSPF'
BIRD 1.6.0 ready.
172.20.175.215/32 via 172.20.175.197 on wg-ibgp-fr01 [O_OSPF 2017-12-31] * I (150/10) [172.20.175.197]
172.20.175.210/32 via 172.20.175.193 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
172.20.175.211/32 via 172.20.175.195 on wg-ibgp-de02 [O_OSPF 09:12:02] * I (150/10) [172.20.175.195]
172.20.175.220/32 via 172.20.175.195 on wg-ibgp-de02 [O_OSPF 09:12:41] * I (150/20) [172.20.175.196]
172.20.175.196/32 via 172.20.175.195 on wg-ibgp-de02 [O_OSPF 09:12:41] * I (150/20) [172.20.175.196]
172.20.175.197/32 via 172.20.175.197 on wg-ibgp-fr01 [O_OSPF 2017-12-31] * I (150/10) [172.20.175.197]
172.20.175.198/32 dev lo [O_OSPF 2017-06-01] * I (150/0) [172.20.175.198]
172.20.175.199/32 via 172.20.175.199 on wg-ibgp-au01 [O_OSPF 2017-12-17] * I (150/10) [172.20.175.199]
172.20.175.193/32 via 172.20.175.193 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
172.20.175.195/32 via 172.20.175.195 on wg-ibgp-de02 [O_OSPF 09:12:02] * I (150/10) [172.20.175.195]
172.20.175.252/32 via 172.20.175.193 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
172.20.175.253/32 via 172.20.175.193 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
172.20.175.254/32 via 172.20.175.193 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
172.20.175.249/32 via 172.20.175.195 on wg-ibgp-de02 [O_OSPF 09:12:02] * I (150/10) [172.20.175.195]
172.20.175.250/32 via 172.20.175.195 on wg-ibgp-de02 [O_OSPF 09:12:02] * I (150/10) [172.20.175.195]
172.20.175.251/32 via 172.20.175.193 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
172.20.175.230/32 via 172.20.175.199 on wg-ibgp-au01 [O_OSPF 2017-12-17] * I (150/10) [172.20.175.199]
172.20.175.225/32 dev lo [O_OSPF 2017-06-01] * I (150/0) [172.20.175.198]
</code></pre></div></div>
<p><strong>OSPFv3 Neighbor Table</strong></p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>birdc6 'sh ospf neighbors'
BIRD 1.6.4 ready.
O_OSPF:
Router ID Pri State DTime Interface Router IP
172.20.175.196 1 Full/PtP 00:37 wg-ibgp-us01 fe80::de49:220
172.20.175.197 1 Full/PtP 00:34 wg-ibgp-fr01 fe80::42
172.20.175.195 1 Full/PtP 00:34 wg-ibgp-gw fe80::de49:211
172.20.175.198 1 Full/PtP 00:33 wg-ibgp-uk01 fe80::de49:225
172.20.175.199 1 Full/PtP 00:30 wg-ibgp-au01 fe80::de49:230
</code></pre></div></div>
<p><strong>OSPFv3 Routing Table</strong></p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>birdc6 'show route table T_OSPF'
BIRD 1.6.0 ready.
fdf7:17d5:de49::250/128 via fe80::de49:211 on wg-ibgp-de02 [O_OSPF 09:11:57] * I (150/10) [172.20.175.195]
fdf7:17d5:de49::251/128 via fe80::1 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
fdf7:17d5:de49::249/128 via fe80::de49:211 on wg-ibgp-de02 [O_OSPF 09:11:57] * I (150/10) [172.20.175.195]
fdf7:17d5:de49::42/128 via fe80::1 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
fdf7:17d5:de49::43/128 via fe80::1 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
fdf7:17d5:de49:5::1/128 via fe80::de49:230 on wg-ibgp-au01 [O_OSPF 2017-12-17] * I (150/10) [172.20.175.199]
fdf7:17d5:de49:4::1/128 dev lo [O_OSPF 2017-06-01] * I (150/0) [172.20.175.198]
fdf7:17d5:de49:1::1/128 via fe80::de49:211 on wg-ibgp-de02 [O_OSPF 09:11:57] * I (150/10) [172.20.175.195]
fdf7:17d5:de49::1/128 via fe80::1 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
fdf7:17d5:de49:3::1/128 via fe80::de49:215 on wg-ibgp-fr01 [O_OSPF 2017-11-16] * I (150/10) [172.20.175.197]
fdf7:17d5:de49:2::1/128 via fe80::de49:211 on wg-ibgp-de02 [O_OSPF 09:12:47] * I (150/20) [172.20.175.196]
fdf7:17d5:de49::5222/128 via fe80::1 on wg-ibgp-de01 [O_OSPF 2017-12-29] * I (150/10) [172.20.175.193]
</code></pre></div></div>Tim WeippertFirst i had ipsec/gre for interconnecting my nodes itself, but now i completely switched to WireGuard. As it is really simple to setup (if you can compile an kernel module or use dkms), it is fast, high throughput and you don’t need gre as with ipsec to use for example OSPF on the links.OVN - Logical Router and changed Next Hop MAC2018-01-03T00:00:00+01:002018-01-03T00:00:00+01:00https://weiti.org/ovn/2018/01/03/ovn-logical-router-next-hop-mac<p>While my tests with OVN i get a situation, where the next hop of my Entry Point (Logical Router) to OVN changed his mac (As it was an tap interface with no fixed MAC). And all i tried, the Logical Router doesn’t seem to time out his <em>ARP Cache</em>.</p>
<p>I thought about how to <strong>clear</strong> an ARP Cache on an Logical Router … and i found the following Binding Table in the Southbound Table:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>root@gateway:~# ovn-sbctl list Mac_Binding
_uuid : b0253ec1-0f3e-4404-a46e-fa671b7e0181
datapath : d395a03d-001b-439d-b2be-7196964dc6b0
ip : "172.18.30.50"
logical_port : MGMT
mac : "52:54:00:29:9f:5f"
_uuid : 80f2bdab-cd89-430f-8bb2-81db256186e0
datapath : d395a03d-001b-439d-b2be-7196964dc6b0
ip : "172.18.16.1"
logical_port : EXT
mac : "c2:f9:61:ef:64:e0"
</code></pre></div></div>
<p>There you find the <em>MAC Bindings</em> or <em>ARP Cache</em> for the Logical Router.</p>
<p>To clear an entry you use the following command:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>root@gateway:~# ovn-sbctl destroy Mac_Binding 80f2bdab-cd89-430f-8bb2-81db256186e0
</code></pre></div></div>
<p>When the entry was removed, the Logical Router send an <em>arp request</em> and updates the <em>Mac_Binding</em> Table.</p>Tim WeippertWhile my tests with OVN i get a situation, where the next hop of my Entry Point (Logical Router) to OVN changed his mac (As it was an tap interface with no fixed MAC). And all i tried, the Logical Router doesn’t seem to time out his ARP Cache.OVN - L2 Breakout Options2018-01-03T00:00:00+01:002018-01-03T00:00:00+01:00https://weiti.org/ovn/2018/01/03/ovn-l2-breakout-options<p>Currently we had the following LAB generated:</p>
<p><img src="https://weiti.org/assets/img/OVN-LAB01.png" alt="OVN_LAB01" /></p>
<ul>
<li>OVN-Central up & running</li>
<li>kvmhost01 & 03 are connected as Chassis to OVN-Central</li>
<li>Created an Logical Switch <em>SERVER</em> on OVN-Central</li>
</ul>
<p>Before we go and create some VMs, we should discuss, how we want to interconnect them with the outside world. There are two major options L3 or L2. As the <em>SERVER</em> Network outside OVN is an VLAN based Network (VLAN 200) with many VMs on it, we focus on L2 Breakout, to had an easy migration path from <strong>non-ovn</strong> VMs to <strong>ovn</strong> VMs and to use all existing Network Functions (Gateway, DHCPv4 + v6 …).</p>
<p>We want an L2 Breakout, which connects the Logical Switch <em>SERVER</em> with the existing OVS <em>HOME</em> on VLAN 200. And there are also 2 options:</p>
<ul>
<li>L2 localnet breakout</li>
<li>L2 gateway breakout</li>
</ul>
<p>What are the best to use? What are the differences?</p>
<p>FOr both L2 breakout’s we need a <em>Brige Mapping</em>, which is a definition of a <em>network_name:OVS_Bridge</em>. For example, we want a network name <em>physnet200</em> to be on OVS Bridge <em>HOME</em> we will use:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet200:HOME
</code></pre></div></div>
<p>This needs to be set on the Chassis/KVM Node where we need it (see below).</p>
<h1 id="l2-localnet-breakout">L2 localnet breakout</h1>
<p>This L2 breakout is an direct breakout on every KVM Node. Means there is an “local” connection between the Logical Switch <em>SERVER</em> OVN Bridge and a OVS Bridge which connects to VLAN 200. If we generate an <em>localnet port</em> on OVN-Central, this <em>localnet port</em> gets predecence above other connection mechanisms (geneve tunnels for example).</p>
<p>What does it mean?</p>
<p>If we had two VMs running in the Logical Switch <em>SERVER</em>, one on kvmhost01 and the other on kvmhost03. Normally the communication between the two VMs will be forwarded over <em>geneve tunnels</em> between the hosts. If the Logical Switch has an <em>localnet port</em> configured, the communication is done via the VLAN 200 interconnection as with normal communication between KVM/OVS Nodes with an physical transport network connected.</p>
<blockquote>
<p>An direct HA concept does not exists, as if one node looses the local L2 breakout, all VMs on this Node looses the connection to outside L2. NO reroute to an other Node will be occure.</p>
</blockquote>
<p><img src="https://weiti.org/assets/img/OVN-LAB01-L2-Localnet.png" alt="OVN_LAB01" /></p>
<p>How to configure ?</p>
<p>On every Chassis/KVM Node (in our LAB kvmhost01, kvmhost03):</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet200:HOME
</code></pre></div></div>
<p>On <em>OVN-Central</em> (will be transferred to every OVN attached Chassis/KVM Node):</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovn-nbctl lsp-add SERVER server-localnet "" 200
ovn-nbctl lsp-set-addresses server-localnet unknown
ovn-nbctl lsp-set-type server-localnet localnet
ovn-nbctl lsp-set-options server-localnet network_name=physnet200
</code></pre></div></div>
<p>This will configure a <em>localnet port</em> with VLAN Tag 200 and Bridge Mapping <em>physnet200</em> to <em>HOME</em>. Which will mean:</p>
<blockquote>
<p>Send all unknown L2 traffic to this logical Port, switch it over to Bridge named HOME with VLAN Tag200.</p>
</blockquote>
<h1 id="l2-gateway-breakout">L2 gateway breakout</h1>
<p>This L2 breakout was only on <strong>one</strong> defined Chassis / KVM Node. The other participating Nodes use tunnel to use this L2 breakout.</p>
<p>What does it mean?</p>
<p>If we had two VMs runing in the Logical Switch <em>SERVER</em>, one on kvmhost01 and the other on kvmhost03 and kvmhost01 is the configured L2 gateway. The communication between this VMs will be done via Tunnel in the Overlay Network. If the VM on kvmhost01 will use the L2 breakout, this is done locally and if the other VM on kvmhost03 needs to breakout, the transport is first done via Tunnel to kvmhost01 and then to the configured breakout bridge/VLAN.</p>
<blockquote>
<p>It seem an HA concept for this may exists, but on several sides you can read not to use L2HAGateway implementations as they are likely to create loops or other problems.</p>
</blockquote>
<p><img src="https://weiti.org/assets/img/OVN-LAB01-L2-Gateway.png" alt="OVN_LAB01" /></p>
<p>How to configure?</p>
<p>Only on Chassis/KVM Node which is the L2 Gateway Chassis (in our LAB kvmhost01):</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovs-vsctl set open . external-ids:ovn-bridge-mappings=physnet200:HOME
</code></pre></div></div>
<p>On <em>OVN-Central</em> (will be transferred to every OVN attached Chassis/KVM Node):</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovn-nbctl lsp-add SERVER server-l2gateway "" 200
ovn-nbctl lsp-set-addresses server-l2gateway unknown
ovn-nbctl lsp-set-type server-l2gateway l2gateway
ovn-nbctl lsp-set-options server-l2gateway network_name=physnet200 l2gateway-chassis=bffe235d-b222-49ce-9723-180ad5ba8b90
</code></pre></div></div>
<blockquote>
<blockquote>
<p><strong>ATTENTION:</strong></p>
<p>The lsp-set-options need to be on one Line with spaces as delimiter, no commata or breakup in more lines. This won’t work, trust me i tried it serveral hours …</p>
</blockquote>
</blockquote>
<p>This will configure a <em>l2gateway port</em> with VLAN Tag 200 and Bridge Mapping <em>physnet200</em> to <em>HOME</em> only on Chassis with given
ID (kvmhost01 in our LAB). Which will mean:</p>
<blockquote>
<p>Send all unknown L2 traffic from other Chassis via geneve tunnel to Chassis with ID & Port and switch it over to Bridge named HOME with VLAN Tag200. Local Chassis Traffic will be send to this Port directly and switched to Bridge named HOME with VLAN TAG 200.</p>
</blockquote>
<h1 id="conclusion-for-our-lab">Conclusion for our LAB:</h1>
<p>I will use the L2 Gateway breakout for the upcoming Lab Parts, as i see one advantage over the <em>L2 localnet breakout</em>: You can have participating hosts, which only needs a connection to the overlay network and an OVN integration and they can participate on the hole environment, they can even host Systems within VLAN 200, wihtout needing an Interface in this VLAN (as we will transform kvmhost02 in near future into such a system). Downside is the <em>single point of failure</em> but this is acceptable in this scenario.</p>Tim WeippertCurrently we had the following LAB generated:OVN - br-int? Or other name?2018-01-02T00:00:00+01:002018-01-02T00:00:00+01:00https://weiti.org/ovn/2018/01/02/ovn-br-int-or-other-name<p>First i read that i need an <em>“Integration Bridge”</em> which will normally named <em>“br-int”</em>. As i normally name my Switches/Bridges in capital letters, i want to change the <em>“Integration Bridge”</em> to <strong>OVN</strong>.</p>
<p>But how does it work, and how does the <em>“Controller”</em> nows what he should configure and where?</p>
<p>I tried to show on Overview of the components and dependencies:</p>
<p><img src="https://weiti.org/assets/img/OVN-Overview.png" alt="OVN_Overview" /></p>
<p>OVN consists of the following basic components:</p>
<ul>
<li>ovn-central: ovn-northd + north & south db</li>
<li>ovn-controller: connects to south db and configures the <em>“Integration Bridge”</em></li>
<li>ovs-vswitchd: Normal Open vSwitch daemon for Bridges</li>
</ul>
<p>You don’t need all components on all systems. For example, the ovn-northd with the north & south DB can be run on an system without an “normal” Open vSwitch daemon. Only as an Central Instance. I will name this Instance (where ovn-northd is running) <em>ovn-central</em> from now on. It is the same name as the corresponding debian package to install <em>ovn-northd</em>.</p>
<p>The <em>ovn-central</em> System holds the configuration of Logical Switches and Ports, Logical Routers, Logical Loadbalancers and more “Logical Network Definition”. With <em>ovn-nbctl</em> you define your virtual network and with <em>ovn-sbctl</em> you can see the participating chassis and where the logical components reside in your network.</p>
<p>We will create/use this environment according this picture (create only the OVN specific parts):</p>
<p><img src="https://weiti.org/assets/img/OVN-LAB01.png" alt="OVN_LAB01" /></p>
<ul>
<li>L3 Gateway is an Linux Debian Stretch System with interconnects my HOME Networks</li>
<li>kvmhost01-03 are my current KVM Hosts with around 10-15 VM Machines in one VLAN (200)</li>
<li>Overlay Network is the new Network between L3 Gateway, kvmhost01 and kvmhowst03 (kvmhost02 had no interface left <em>g</em>)</li>
</ul>
<p>First we build the <em>ovn-central</em> System on the Gateway. I use therefore debian jessie with an backported sid openvswitch package, as my kvmhosts are Arch Linux and they had an OVS 2.8.X installed.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>apt-get install ovn-central
</code></pre></div></div>
<p>The Debian Package ensure, that the needed Services are running (ovn-northd, ovsdb-server for nb & sb db). Since OVS 2.7 you need to start listening for OVN components:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovn-sbctl set-connection ptcp:6642
ovn-nbctl set-connection ptcp:6641
</code></pre></div></div>
<p>On the Gateway we can now use <code class="highlighter-rouge">ovn-nbctl show</code> to see our logical definitions, which should be empty.</p>
<p>Let us create the first logical Switch on the Gateway:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovn-nbctl ls-add SERVER
</code></pre></div></div>
<p>That is it, <code class="highlighter-rouge">ovn-nbctl show</code> should now print something like:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>switch d87948b3-c94e-4329-aa54-37a953b2aaa8 (SERVER)
</code></pre></div></div>
<p>Ok, now we had an Logical Switch on an Central Controll System, but nothing really usefull. Just let us attach the Chassis to the OVN Network. As my kvmhosts running on Arch Linux, they had installed the openvswitch binaries and scripts (<code class="highlighter-rouge">pacman -S openvswitch</code>). Make sure, that the <em>ovs-vswitchd</em> is running and the <em>ovn-controller</em> is stopped. The <em>ovn-controller</em> will be managed by an <em>ovn-ctl</em> script located in <em>/usr/lib/openvswitch/scripts/</em>.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>/usr/share/openvswitch/scripts/ovn-ctl stop_controller
</code></pre></div></div>
<p>Let us create an <em>Integration Bridge</em> with the Name OVN on kvmhost01 ad kvmhost03:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>ovs-vsctl add-br OVN -- set Bridge OVN fail-mode=secure
</code></pre></div></div>
<p>We now tell the Hosts, how the <em>ovn-central</em> system can be reached and which <em>Integration Bridge</em> should be used:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>id_file=/etc/openvswitch/system-id.conf
test -e $id_file || uuidgen > $id_file
ovs-vsctl set open . external_ids:system-id=$(cat $id_file)
ovs-vsctl set open . external_ids:ovn-nb="tcp:172.18.31.1:6641"
ovs-vsctl set open . external-ids:ovn-remote="tcp:172.18.31.1:6642"
ovs-vsctl set open . external-ids:ovn-encap-type=geneve
ovs-vsctl set open . external-ids:ovn-encap-ip=172.18.31.10
ovs-vsctl set open . external_ids:ovn-bridge=OVN
</code></pre></div></div>
<p>On Arch Linux the Package doesn’t generate an system-id.conf file with an system wide uuid, so the first lines will create them if it isn’t already there. The above settings are made on kvmhost01, be sure to change the <em>ovn-encap-ip</em> to your Overlay IP of the Host. And start the <em>ovn-controller</em> after configure the settings above:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>/usr/share/openvswitch/scripts/ovn-ctl start_controller
</code></pre></div></div>
<p>If all went well, you can see on your <em>ovn-central</em> system the new Chassis with <code class="highlighter-rouge">ovn-sbctl show</code>:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Chassis "bffe235d-b222-49ce-9723-180ad5ba8b90"
hostname: "kvmhost01"
Encap geneve
ip: "172.18.31.10"
options: {csum="true"}
</code></pre></div></div>
<p>Just repeat the settings on all of your participating hosts and <code class="highlighter-rouge">ovn-sbctl show</code> and with our lab setup, it should look like:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Chassis "bffe235d-b222-49ce-9723-180ad5ba8b90"
hostname: "kvmhost01"
Encap geneve
ip: "172.18.31.10"
options: {csum="true"}
Chassis "804c7da4-04c8-416e-9420-0345f7335284"
hostname: "kvmhost03"
Encap geneve
ip: "172.18.31.30"
options: {csum="true"}
</code></pre></div></div>
<p>What we now had is like our LAB Picture, and Central Controll System with two Chassis connected. Also we had created an Logical Switch (SERVER) it is not really used currently.</p>
<p>In the next article, we create an L2 Breakout to be used by VMs in the Logical Switch (SERVER) …</p>Tim WeippertFirst i read that i need an “Integration Bridge” which will normally named “br-int”. As i normally name my Switches/Bridges in capital letters, i want to change the “Integration Bridge” to OVN. But how does it work, and how does the “Controller” nows what he should configure and where?OVN - Open Virtual Network for Open vSwitch2018-01-01T18:38:19+01:002018-01-01T18:38:19+01:00https://weiti.org/ovn/2018/01/01/ovn-open-virtual-network-for-open-vswitch<p>What is OVN? An Controller based Virtual Network for Open vSwitch. It brings Logical Switches/Routers/Loadbalancers and even more network functions.</p>
<p>I had some time and thoughts, how my internal Virtualized Network can be changed from libvirt, kvm, ovs, vlan based to something more “state of the art” but without implementing an complete Openstack or similar ….</p>
<p>And i found “OVN - Open Virtual Network for Open vSwitch”. This should be (or is) the implementation for Open vSwitch in Openstack/Neutron. So i move to: libvirt, kvm, ovs, ovn. Seems not much change …</p>
<p>First i need to understand about the Basics and Wordings of OVN, and i tried to establish an seperated “Virtualized Network” with an L3 Gateway for “external” reachability.</p>
<p>As OVN (can use) uses “tunnels” for inter-chassis (KVM/OVS Node == Chassis) communication, you should consider use an seperate Network/Interface and increase MTU to something higher than 1600. As i want to create an iSCSI Network with MTU 9000 since several years, this is the same network in the future. Currently i use it for Controller Management and Tunnel Traffic.</p>
<p>I will try to summarize my errors and success within a short Story of Blog Posts ….</p>
<p>You will find all OVN related posts in a own category:</p>
<p><a href="/category/ovn/">OVN Category</a></p>Tim WeippertWhat is OVN? An Controller based Virtual Network for Open vSwitch. It brings Logical Switches/Routers/Loadbalancers and even more network functions.My DN42 Network2017-04-18T16:57:25+02:002017-04-18T16:57:25+02:00https://weiti.org/dn42/2017/04/18/my-dn42-network<p>I setup a little network within <a href="https://dn42.net/Home">DN42</a> to experiment and learn on BGP based networking. Currently my DN42 Network consists of 6 Nodes and more than 65 Peering ASN.</p>
<p>Within this Series of Articles i want to explain, what i do in my network and how it works.</p>
<ol>
<li><a href="/dn42/2018/01/05/basics-tunnels-ospf.html">BASICS</a> - Connection of the nodes itself (Tunnel & OSPF)</li>
<li><a href="/dn42/2018/01/13/ibgp-bgp-within-as4242423905.html">iBGP</a> - BGP within AS4242423905</li>
<li>ASN - Other ASN of mine (AS4242423906, AS4242423907)</li>
<li>AUTOMATE - Filtering and Automation within AS4242423905</li>
<li>PEER - Peering with other (eBGP, VPN, GRE)</li>
</ol>
<h5 id="big-picture">Big Picture</h5>
<p><img src="https://dn42-svc.weiti.org/images/dn42-peering.png" alt="DN42 Network" /></p>
<p>The picture is more or less accurate as it is manually generated .. automation is planned.</p>
<p>The green lines identify iBGP peering. The viloet ones are wireguard connections and blue are ipsec/gre. Yellow are EBGP Peering and gray open vpn.</p>I setup a little network within DN42 to experiment and learn on BGP based networking. Currently my DN42 Network consists of 6 Nodes and more than 65 Peering ASN.Welcome to my new Website/Blog2017-04-17T08:27:56+02:002017-04-17T08:27:56+02:00https://weiti.org/2017/04/17/welcome-to-my-new-website-blog<p>Hopefully this site/blog will be filled up with some interesting content, technical reviews and idea’s and some minor technical thoughts.</p>
<p>Check out this site later again …</p>Hopefully this site/blog will be filled up with some interesting content, technical reviews and idea’s and some minor technical thoughts.