We spent a lot of time on trying to provide state-of-the-art networking in the data center. This document describes the requirements, ideas and implementation details of the network topology that hosts the metal-stack.
The document is separated into three main sections describing the constraints, theoretical ideas and implementation details.
Finding the requirements for this greenfield project was kicked off with a handful of design parameters that included:
- Investigation of the idea of a layer-3 based infrastructure to overcome the drawbacks of traditional layer-2 architectures.
- Application of a routing technology that involves a single stand-alone protocol BGP for operational simplicity.
- Utilization of the overlay virtual network technology EVPN to support cost-effective scaling, efficient network information exchange and a manageable amount of administration effort.
- Applying the routing topology on top of a completely new physical infrastructure that is designed as a CLOS network topology.
Evaluation of those parameters led to more specific requirements:
- Physical Wiring:
- The data center is made of a leaf-spine CLOS topology containing:
- leaf switches
- spine switches
- exit switches
- management server
- management switch
- tenant servers
- tenant firewalls.
- Bare metal servers are dual-attached to leaf switches. The bare metal servers either become tenant servers or firewalls for a group of tenant servers.
- All network switches are connected to a management switch. A management server provides access to this management network.
- The data center is made of a leaf-spine CLOS topology containing:
- Network Operation Characteristics:
- IPv4 based network.
- No IPv6 deployment.
- Utilization of external BGP.
- Numbered BGP only for peerings at exit switches with third parties (Internet Service Provider).
- Overall BGP unnumbered.
- 4-byte private ASN instead of default 2-byte ASN for BGP.
- Network operation relies on SONiC Linux.
- Bleeding edge Routing-to-the-Host/EVPN-to-the-Host with ordinary Linux distributions.
- Layer-3 routing using BGP and VXLAN/EVPN.
- Every VTEP acts as a layer-3 gateway and does routing. Routing is done on both the ingress and the egress VTEP (aka distributed symmetric routing).
- Tenant isolation is realized with VRF.
- Internet Access is implemented with route leak on the firewall servers and during the PXE-Process with route leak on the exit switches.
- MTU 9216 is used for VXLAN-facing interfaces, otherwise MTU 9000 is used.
Furthermore, requirements such as operational simplicity and network stability that a small group of people can effectively support have been identified being a primary focus for building metal-stack.
The theoretical concept targets the aforementioned requirements. New technologies have been evaluated to apply the best solutions. The process was heavily inspired by the work of Dinesh G. Dutt regarding BGP (bgp-ebook) and EVPN (evpn-ebook).
External BGP together with network overlay concepts as EVPN can address the essential demands. These revolutionary concepts are part of the next evolutionary step in data center design. It overcomes common issues of traditional layer 2 architectures (e.g. VLAN limitations, network visibility for operations, firewall requirements) by introducing a layer 3 based network topology.
A CLOS topology is named after the pioneer Charles Clos (short: CLOS) who first formalized this approach. CLOS defines a multistage network topology that is used today to improve performance and resilience while enabling a cost effective scalability. A CLOS topology comprises network switches aggregated into spine and leaf layers. Each leaf switch (short: leaf) is connected to all spine switches (short: spine) but there is no direct leaf-to-leaf or spine-to-spine connection (See: picture 1).
Picture 1: Fragment of CLOS to show leaf-spine layer.
This data center network architecture, based on a leaf-spine architecture, is also know as "two-tier" CLOS topology.
Picture 2: Fragment to show a 3-stage, 2-layer CLOS topology.
Tenant servers are dual-attached to the leaf layer in order to have redundancy and load balancing capability (Picture 2). The set of leaves, spine switches and tenant servers define stages. From top down each server is reachable with 3 hops (spine -> leaf -> server). This is why that CLOS design is called a 3-stage CLOS. Consistent latency throughout the data center are an outcome of this design.
It is not only important to have a scalable and resilient infrastructure but also to support planning and operation teams. Visibility within the network is of significant meaning for them. Consequently layer-3 routing in favor of layer-2 bridging provides this kind of tooling.
For routing the Border Gateway Protocol (BGP), more specific: External BGP was selected. Extensive testing and operational experiences have shown that External BGP is well suited as a stand-alone routing protocol (see: RFC7938).
Not all tenant servers are connected to the same leaf. Instead they can be distributed among any of the leaves of the data center. To not let this detail restrict the intra-tenant communication it is required to interconnect those layer-2 domains. In the context of BGP there is a concept of overlay networking with VXLAN/ EVPN that was evaluated to satisfy the needs of the metal-stack.
In BGP traditionally each BGP peer-facing interface requires a separate IPv4 address. This consumes a lot of IP addresses. RFC 5549 defines the BGP unnumbered standard. It allows to use interface's IPv6 link local address (LLA) to set up a BGP session with a peer. With BGP unnumbered the IPv6 LLA of the remote is automatically discovered via Router Advertisement (RA) protocol. Important: This does not (!) mean that IPv6 must be deployed in the network. BGP uses RFC 5549 to encode IPv4 routes as reachable over IPv6 next-hop using the LLA. Having unnumbered interfaces does not mean no IPv4 address may be in place. It is a good practice to configure an IP address to the never failing and always present local loopback interface (lo). This lo address is reachable over BGP from other peers because the RFC 5549 standard provides an encoding scheme to allow a router to advertise IPv4 routes with an IPv6 next-hop. BGP unnumbered also has an advantage from security perspective. It removes IPv4 and global IPv6 addresses from router interfaces, thus reducing the attack vector.
To sum it up:
- BGP unnumbered uses IPv6 next-hops to announce IPv4 routes.
- There is no IPv6 deployment in the network required.
- IPv6 just has to be enabled on the BGP peers to provide LLA and RA.
In BGP, ASN is how BGP peers know each other.
Within the data center each BGP router is identified by a private autonomous system number (ASN). This ASN is used for internal communication. The default is to have 2-byte ASN. To avoid having to find workarounds in case the ASN address space is exhausted, a 4-byte ASN that supports up to 95 million ASNs (4200000000–4294967294) is used from the beginning.
ASN numbering in a CLOS topology should follow a model to avoid routing problems (path hunting) due to it's redundant nature. Within a CLOS topology the following ANS numbering model is suggested to solve path hunting problems:
- Leaves have unique ASN
- Spines share an ASN
- Exit switches share an ASN
As stated, BGP is a multi-protocol routing protocol. Since it is planned to use IPv4 and overlay networks using EVPN/VXLAN several address-families have to be activated for the BGP sessions to use:
- IPv4 unicast address-family
- L2 EVPN address-family
Ethernet VPN (EVPN) is an overlay virtual network that connects layer-2 segments over layer-3 infrastructure. EVPN is an answer to common problems of entire layer-2 data centers.
Challenges such as large failure domains, spanning tree complexities, difficult troubleshooting and scaling issues are addressed by EVPN:
- administration: less routers are involved in configuration (with VLAN every switch on routing-paths needs VLAN awareness). The configuration is less error prone due to the nature of EVPN and the good support in FRR.
- scaling: EVPN overcomes scaling issues with traditional VLANs (max. 4094 VLANs).
- cost-effectiveness: EVPN is an overlay virtual network. Not every switch on the routing path needs EVPN awareness. This enables the use of standard routers (in contrast to traditional VLAN); e.g.: spine switches act only as evpn information replicator and do not need to have knowledge of specific virtual networks.
- efficiency: EVPN information is exclusively exchanged via BGP (Multiprotocol BGP). Only a single eBGP session is needed to advertise layer-2 reachability. No other protocols beneath BGP are involved and flood traffic is reduced to a minimum (no "flood-and-learn", no BUM traffic).
Virtual routing permits multiple network paths without the need of multiple switches. Hence the servers are logically isolated by assigning their networks to dedicated virtual routers using virtual routing and forwarding (short: VRF).
EVPN (technology) is based on BGP as control plane protocol (underlay) and VXLAN as data plane protocol (overlay).
As EVPN is an overlay network, only the VXLAN Tunnel End Points (VTEPs) must be configured. In the case of two-tier CLOS networks leaf switches are tunnel endpoints.
In EVPN routing is assumed to occur in the context of a VRF. VRF enables true multitenancy. Therewith, VRF is the first step for EVPN configuration and there is a 1:1 relationship between tenant and VRF.
To enable layer-2 connectivity, we need a special interface to route between layer-2 networks. This interface is called Switched VLAN Interface (SVI). The SVI is realized with a VLAN. It is part of a VRF (layer-3).
The VTEP configuration requires the setup of a VXLAN interface. A VLAN aware bridge interconnects the VXLAN interface and the SVI.
Required Interfaces to establish the EVPN control plane:
- VRF: because routing happens in the context of this interface.
- SVI: because remote host routes for symmetric routing are installed over this interface.
- VLAN-aware bridge: because router MAC addresses of remote VTEPs are installed over this interface.
- VXLAN Interface / VXLAN Tunnel Endpoint: because the VRF to layer-3 VNI mapping has to be consistent across all VTEPs)
Picture 3: Required interfaces on the switch to wire up the vrf to swp 1 connectivity with a given vxlan
Integrated routing and bridging (IRB) is the most complex part of EVPN. You could choose between centralized or distributed routing, and between asymmetrical (routing on ingress) or symmetrical (routing on ingress and egress) routing. We expect a lot of traffic within the data center itself which implies the need to avoid zigzag routing. This is why we go with distributed routing model. Further it is recommended to use the symmetric model since it makes the cut in most cases and has advantages in scalability (see "EVPN in the Data Center", Dinesh G. Dutt).
In a layer-3 network it is important to associate each interface with a proper Maximum Transmission Unit (MTU) to avoid fragmentation of IP packets. Typical modern networks do not fragment IP packets and the introduction of VXLAN adds another additional header to the packets that must not exceed the MTU. If the MTU is exceeded, VXLAN might just fail without error. This already represents a difficult-to-diagnose connectivity issue that has to be avoided.
It is common practice to set the MTU for VXLAN facing interfaces (e.g. inter-switch links) to a value of
9216 to compensate the additional VXLAN overhead and an MTU of
9000 as a default to other interfaces (e.g. server facing ports). The common MTU of
1500 is not sufficient for traffic inside a data center!
Routing is needed for communication between VXLAN tunnels or between a VXLAN tunnel and an external networks. VXLAN routing supports layer-3 multi-tenancy. All routing occurs in the context of a VRF. There is a 1:1 relation of a VRF to a tenant. Picture 3 illustrates this. Servers A and B belong to the same vrf VRF1. Server C is enslaved into VRF2. There is no communication possible between members of VRF1 and those of VRF2.
Picture 4: Illustration of two distinct routing tables of VRF1 (enslaved: servers A and B) and VRF2 (enslaved: server C)
To leaverage the potential and power of BGP, VRF, EVPN/VXLAN without a vendor lock-in the implementation relies on hardware that is supported by open network operating system: SONiC.
Implementation of the network operation requires the data center infrastructure to be in place. To implement a functional meaning for the parts of the CLOS network, all members must be wired accordingly.
Reference: See the CLOS overview picture in ./README.md.
|Tenant server (aka Machine)||Bare metal server that is associated to a tenant. Dual-connected to leafs.|
|Tenant firewall||Bare metal server that is associated to a tenant. Dual-connected to leafs.|
|Leaf||Network Switch that interconnects tenant servers and firewalls. Connected to spines.|
|Spine||Network switch that interconnects leafs and exit switches.|
|Exit||Network switch that connects to spines and interconnects to external networks.|
|Management Server||Jump-host to access all network switches within the CLOS topology for administrative purpose.|
|Management Switch||Connected to the management port of each of the network switches.|
Tenant servers are organized into a layer called projects. In case those tenant servers require access to or from external networks, a new tenant server to function as a firewall is created. Leaf and spine switches form the fundament of the CLOS network to facilitate redundancy, resilience and scalability. Exit switches establish connectivity to or from external networks. Management Switch and Management Server are mandatory parts that build a management network to access the network switches for administration.
To operate the CLOS topology, software defined configuration to enable BGP, VRF, EVPN and VXLAN must be set up.
SONiC as the network operating system will be installed on all network switches (leaves, spines, exit switches) within the CLOS topology. SONiC cannot be installed on bare metal servers that require BGP/EVPN but does not have a switching silicon.
Components without a switching silicon are:
- tenant servers
- tenant firewalls
- management server
There exist two paradigms to use BGP and/or VXLAN/EVPN on non switching bare metal servers: BGP-to-the-host and EVPN-to-the-host. Both describe a setup of Free Range Routing Framework (see frrouting.org) and its configuration. FRR seamlessly integrates with the native Linux IP networking stacks.
Starting with an explanation of the tenant server's BGP-to-the-Host helps to get an insight into the setup of the CLOS network from a bottom-up perspective.
Tenant servers are dual-connected to leaf switches. To communicate with other servers or reach out to external networks they must join a BGP session with each of the leaf switches. Thus, it is required to bring BGP to those hosts (aka BGP-to-the-Host). Each tenant server becomes a BGP router (aka BGP speaker).
BGP-to-the-Host is established by installing and configuring FRR. The required FRR configuration for tenant servers is limited to a basic setup to peer with BGP next-hops:
# /etc/network/interfaces auto lo iface lo inet static address 10.0.0.1/32 auto lan0 iface lan0 inet6 auto mtu 9000 auto lan1 iface lan1 inet6 auto mtu 9000
Listing 1: Network interfaces of a tenant server.
Listing 1 shows the local interfaces configuration. lan0 and lan1 connect to the leaves. As described, there is no IPv4 address assigned to them (BGP unnumbered). The local loopback has an IPv4 address assigned that is announced by BGP.
The required BGP configuration:
# /etc/frr/frr.conf frr version 7.0 frr defaults datacenter log syslog debugging service integrated-vtysh-config ! interface lan0 ipv6 nd ra-interval 6 no ipv6 nd suppress-ra ! interface lan1 ipv6 nd ra-interval 6 no ipv6 nd suppress-ra ! router bgp 4200000001 bgp router-id 10.0.0.1 bgp bestpath as-path multipath-relax neighbor TOR peer-group neighbor TOR remote-as external neighbor TOR timers 1 3 neighbor lan0 interface peer-group TOR neighbor lan1 interface peer-group TOR neighbor LOCAL peer-group neighbor LOCAL remote-as internal neighbor LOCAL timers 1 3 neighbor LOCAL route-map local-in in bgp listen range 10.244.0.0/16 peer-group LOCAL address-family ipv4 unicast redistribute connected neighbor TOR route-map only-self-out out exit-address-family ! bgp as-path access-list SELF permit ^$ ! route-map local-in permit 10 set weight 32768 ! route-map only-self-out permit 10 match as-path SELF ! route-map only-self-out deny 99 !
Listing 2: FRR configuration of a tenant server.
The frr configuration in Listing 2 starts with
frr defaults datacenter. This is a marker that enables compile-time provided settings that e.g. set specific values for BGP session timers. This is followed by a directive to state that instead of several configuration files for different purposes a single frr.conf file is used:
service integrated-vtysh-config. The two interface specific blocks starting with
interface ... enable the RA mechanism that is required for BGP unnumbered peer discovery. There is a global BGP instance configuration
router bgp 4200000001 that sets the private ASN. The BGP router configuration contains a setup that identifies the BGP speaker
bgp router-id 10.0.0.1. This router id should be unique. It is a good practice to assign the local loopback IPv4 as router-id. To apply the same configuration to several interfaces a peer group named
TOR is defined via
neighbor TOR peer-group.
remote-as external activates external BGP for this peer group. To have a fast convergence, limits of default timers are reduced by
timer 1 3 section. The two BGP-peer-facing interfaces are enslaved into the peer-group to inherit the peer-group's setup. Activation of IPv4 unicast protocol is completed with
address-family ipv4 unicast. To prevent a tenant server from announcing other paths than
lo interface a route-map
only-self-out is defined. This route map is activated within the ipv4 address family:
neighbor TOR route-map only-self-out out.
Application of the route map
only-self-out enables to announce only local ip(s). This is to avoid that a tenant server announces paths to other servers (prevents unwanted traffic). To achieve this:
the route-map named
only-self-outpermits only matches against an access list named
SELFpermits only empty path announcements
the path of the tenant server itself has no ASN. It is always empty (see line
*> 10.0.0.2/32 0.0.0.0 0 32768 ?):
root@machine:~# vtysh -c 'show bgp ipv4 unicast' BGP table version is 7, local router ID is 10.0.0.2, vrf id 0 Default local pref 100, local AS 4200000002 Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, i internal, r RIB-failure, S Stale, R Removed Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *= 0.0.0.0/0 lan1 0 4200000012 4200000040 i *> lan0 0 4200000011 4200000040 i *= 10.0.0.1/32 lan1 0 4200000012 4200000001 ? *> lan0 0 4200000011 4200000001 ? *> 10.0.0.2/32 0.0.0.0 0 32768 ? *= 10.0.0.78/32 lan1 0 4200000012 4200000001 ? *> lan0 0 4200000011 4200000001 ? Displayed 4 routes and 7 total paths
That is why only the self ip (looback ip) is announced.
To allow for peering between FRR and other routing daemons on a tenant server a
listen range is specified to accept iBGP sessions on the network
10.244.0.0/16. Therewith it gets possible that pods / containers like metal-lb with IPs of this range may peer with FRR.
This is the only place where we use iBGP in our topology. For local peering this has the advantage, that we don't need an additional ASN that has to be handled / pruned in the AS-path of routes. Routes coming from other routing daemons look as if they are configured on the tenant server's lo interface from the viewpoint of the leaves. iBGP routes are differently handled than eBGP routes in BGPs best path algorithm. Generally BGP has the rule to prefer eBGP routes over iBGP routes (s. 'eBGP over iBGP' ). BGP adds automatically an weight based on the route type. To overcome this issue, we set the weight of iBGP routes to the same weight that eBGP routes have, namely 32768 (
set weight 32768). Without this configuration we will only get a single route to the IPs announced via iBGP. So this setting is essential for HA/failover!
Statistics of the established BGP session can be viewed locally from the tenant server via:
sudo vtysh -c 'show bgp ipv4 unicast'
To establish this BGP session a BGP setup is required on the leaves as well.
Every leaf switch is connected to every spine switch. Tenant servers can be distributed within the data center and thus be connected to different leaves. Routing for tenant servers is isolated in unique VRFs. These constraints imply several configuration requirements for the leaf and spine switches:
- leaves define tenant VRFs
- leaves terminate VXLAN tunnels (aka "VXLAN tunnel endpoint" = VTEP)
The leaf setup requires the definition of a tenant VRF that enslaves the tenant server facing interfaces:
# /etc/network/interfaces # [...] iface vrf3981 vrf-table auto iface swp1 mtu 9000 post-up sysctl -w net.ipv6.conf.swp1.disable_ipv6=0 vrf vrf3981 # [...]
Listing 3: Fragment that shows swp1 being member of vrf vrf3981.
There is a VRF defintion
iface vrf3981 to create a distinct routing table and a section
vrf vrf3981 that enslaves swp1 (connects the tenant server) into the VRF. Those host facing ports are also called
Unfortunately, due to a kernel bug, IPv6 is not reliably enabled, so it is enforced explicitly via
post-up sysctl -w net.ipv6.conf.swp1.disable_ipv6=0. If this
post-up trigger is missing the LLA of the interface might be absent.
Additional to the VRF definition the leaf must be configured to provide and connect a VXLAN interface to establish a VXLAN tunnel. This network virtualization begins at the leaves. Therefore, the leaves are also called Network Virtualization Edges (NVEs). The leaves encapsulate and decapsulate VXLAN packets.
# /etc/network/interfaces # [...] iface bridge bridge-ports vni3981 bridge-vids 1001 bridge-vlan-aware yes iface vlan1001 mtu 9000 vlan-id 1001 vlan-raw-device bridge vrf vrf3981 iface vni3981 mtu 9000 bridge-access 1001 bridge-arp-nd-suppress on bridge-learning off mstpctl-bpduguard yes mstpctl-portbpdufilter yes vxlan-id 3981 vxlan-local-tunnelip 10.0.0.11 # [...]
Listing 4: Fragment that shows VXLAN setup for vrf vrf3981.
All routing happens in the context of the tenant VRF. To send and receive packets of a VRF, several interface are in place.
A bridge is used to attach VXLAN interface
bridge-ports vni3981 and map its local VLAN to a VNI. Router MAC addresses of remote VTEPs are installed over this interface.
The Routed VLAN Interface or Switched Virtual Interface (SVI)
iface vlan1001 is configured corresponding to the per-tenant VXLAN interface. It is attached to the tenant VRF. Remote host routes are installed over this SVI. The
vlan-raw-device bridge is used to associate the SVI with the VLAN aware bridge. For a packet received from a locally attached host the SVI interface corresponding to the VLAN determines the VRF
The VXLAN interface
iface vni3981 defines a tunnel address that is used for the VXLAN tunnel header
vlxan-local-tunnelip 10.0.0.11. This VTEP IP address is typically the loopback device address of the switch. When EVPN is provisioned, data plane MAC learning for VXLAN interfaces must be disabled because the purpose of EVPN is to exchange MACs between VTEPs in the control plane:
bridge-learning off. EVPN is responsible for installing remote MACs.
bridge-arp-nd-suppress suppresses ARP flooding over VXLAN tunnels. Instead, a local proxy handles ARP requests received from locally attached hosts for remote hosts. ARP suppression is the implementation for IPv4; ND suppression is the implementation for IPv6. It is recommended to enable ARP suppression on all VXLAN interfaces. Bridge Protocol Data Unit (BPDU) are not transmitted over VXLAN interfaces. So as a good practice bpduguard and pbdufilter are enabled with
mstpctl-bpduguard yes and
mstpctl-portbpdufilter yes. These settings filter BPDU and guard the spanning tree topology from unauthorized switches affecting the forwarding path.
vxlan-id 3981 specifies the VXLAN Network Identifier (VNI). The type of VNI can either be layer-2 (L2) or layer-3 (L3). This is an implicit thing. A VNI is a L3 VNI (L3VNI) when a mapping exists that maps the VNI to a VRF (configured in
/etc/frr/frr.conf) otherwise it is a L2 VNI (L2VNI).
# /etc/frr/frr.conf # [...] vrf vrf3981 vni 3981 exit-vrf #[...] router bgp 4200000011 # [...] address-family ipv4 unicast redistribute connected route-map LOOPBACKS # [...] address-family l2vpn evpn neighbor FABRIC activate advertise-all-vni exit-address-family # [...] router bgp 4200000011 vrf vrf3981 # [...] address-family ipv4 unicast redistribute connected neighbor MACHINE maximum-prefix 100 exit-address-family ! address-family l2vpn evpn advertise ipv4 unicast exit-address-family # [...] route-map LOOPBACKS permit 10 match interface lo # [...]
Listing 5: Leaf FRR configuration.
Listing 5 shows the required FRR configuration of the BGP control plane. Only content not discussed so far is explained. The section
vrf vrf3981 contains the mapping from layer-3 VNI to VRF. This is required to be able to install EVPN IP prefix routes (type-5 routes) into the routing table. Further the file contains a global BGP instance
router bgp 4200000011 definition. A new setting
redistribute connected route-map LOOPBACKS is in place to filter the redistribution of routes that are not matching the local loopback interface. The route-map is defined with
route-map LOOPBACKS permit 10. With the configuration line
address-family l2vpn evpn, the EVPN address family is enabled between BGP neighbours.
advertise-all-vni makes the switch a VTEP configures it in such a way, that all locally configured VNIs should be advertised by the BGP control plane.
The second BGP instance configuration is specific to the tenant VRF
router bgp 4200000011 vrf vrf3981. This VRF BGP instance configures the l2vpn evpn address family with
advertise ipv4 unicast to announce IP prefixes in BGP's routing information base (RIB). This is required to apply learned routes to the routing tables of connected hosts. The Maximum-Prefix feature is useful to avoid that a router recieves more routes than the router memory can take. The maximum number of prefixes a tenant server is allowed to announce is limited to
neighbor MACHINE maximum-prefix 100.
On the spine switches the setup is quite simple.
/etc/network/interfaces contains the loopback interface definition to support BGP unnumbered and listings for connected switch ports to provide proper MTUs (Listing 6). I.e. swp1 is configured with an MTU of 9216 as it is a VXLAN-facing interface.
# /etc/network/interfaces # [...] iface swp1 mtu 9216
Listing 6: Fragment of spine interface configuration.
The spines are important to forward EVPN routes and transport VXLAN packets between the VTEPs. They are not configured as VTEPs. The FRR configuration only contains the already known global BGP instance configuration
router bgp 4200000020 plus the activation of the l2vpn evpn address family
address-family l2vpn evpn to enable EVPN type-5 route forwarding (Listing 7).
hostname spine01 username admin nopassword ! # [...] interface swp1 ipv6 nd ra-interval 6 no ipv6 nd suppress-ra ! # [...] ! router bgp 4200000020 # [...] ! address-family l2vpn evpn neighbor FABRIC activate exit-address-family ! # [...]
Listing 7: Fragment of spine FRR configuration to show the activated L2VPN EVPN address-family.
In case a tenant server needs to reach out to external networks as the Internet, a tenant firewall is provisioned. The firewall is a bare metal server without a switching silicon. Thus, there is no installation of SONiC. FRR provides the BGP / EVPN functionality known as
EVPN-to-the-host. The firewall is configured as a VTEP and applies
dynamic route-leaking to install routes of an foreign VRF. The set of routes that are leaked are restricted with route-maps.
As Listing 8 shows, the firewall is configured with VXLAN interfaces as known from the leaf setup. Additionally, a VXLAN setup for VRF
vrfInternet is added to provide Internet access. vrfInternet contains a route to the Internet that will be leaked into the tenant VRF.
Traffic that originates from the tenant network
10.0.0.0/22 will be masqueraded before leaving the inferface
vlanInternet towards the internet.
# /etc/network/interfaces # [...] iface bridge # [...] iface vlan1001 # [...] iface vni3981 # [...] iface vrf3981 # [...] iface vlanInternet mtu 9000 vlan-id 4009 vlan-raw-device bridge vrf vrfInternet address 22.214.171.124 post-up iptables -t nat -A POSTROUTING -s 10.0.0.0/22 -o vlanInternet -j MASQUERADE pre-down iptables -t nat -D POSTROUTING -s 10.0.0.0/22 -o vlanInternet -j MASQUERADE iface vniInternet mtu 9000 bridge-access 4009 mstpctl-bpduguard yes mstpctl-portbpdufilter yes vxlan-id 104009 vxlan-local-tunnelip 10.0.0.40 iface vrfInternet mtu 9000 vrf-table auto
Listing 8: Interfaces configuration of firewall to show the VTEP interface configuration.
To install a default route into the routing table of tenant VRF vrf3981 a dynamic route leak is established for it (
import vrf vrfInternet). With the help of a route-map
import vrf route-map vrf3981-import-map only the default route will be leaked:
root@firewall01:~# vtysh -c 'show ip route vrf vrf3981' # [...] VRF vrf3981: S>* 0.0.0.0/0 [1/0] is directly connected, vrfInternet(vrf vrfInternet), 03:19:26 B>* 10.0.0.1/32 [20/0] via 10.0.0.12, vlan1001 onlink, 02:34:48 * via 10.0.0.11, vlan1001 onlink, 02:34:48 B>* 10.0.0.2/32 [20/0] via 10.0.0.12, vlan1001 onlink, 02:34:49 * via 10.0.0.11, vlan1001 onlink, 02:34:49
To receive responses from vrfInternet in vrf3981 a route is leaked into vrfInternet as well (
import vrf vrf3981) restricted with the route-map
vrfInternet-import-map that allows leaking of the tenant routes as well as internet prefixes used on worker nodes of the tenant. To limit the prefixes that are announced from the firewall within the global BGP instance a route-map
only-self-out is defined and applied within the ipv4 and l2vpn evpn address family. Together with the definition of an as path access list
bgp as-path access-list it avoids the announcement of prefixes to non VRF BGP peers.
# /etc/frr/frr.conf ! vrf vrf3981 vni 3981 ! vrf vrfInternet vni 104009 ! # [...] ! router bgp 4200000040 # [...] ! address-family ipv4 unicast # [...] neighbor FABRIC route-map only-self-out out exit-address-family ! ! router bgp 4200000040 vrf vrf3981 # [...] address-family ipv4 unicast redistribute connected import vrf vrfInternet import vrf route-map vrf3981-import-map # [...] addrress-family l2vpn evpn advertise ipv4 unicast # [...] router bgp 4200000040 vrf vrfInternet # [...] address-family ipv4 unicast redistribute connected import vrf vrf3981 import vrf route-map vrfInternet-import-map # [...] addrress-family l2vpn evpn advertise ipv4 unicast # [...] bgp as-path access-list SELF permit ^$ ! route-map only-self-out permit 10 match as-path SELF ! route-map only-self-out deny 99 ! route-map LOOPBACKS permit 10 match interface lo ! ip prefix-list vrf3981-import-prefixes seq 100 permit 0.0.0.0/0 ! route-map vrf3981-import-map permit 10 match ip address prefix-list vrf3981-import-prefixes ! route-map vrf3981-import-map deny 99 ! ip prefix-list vrfInternet-import-prefixes seq 100 permit 10.0.0.0/22 le 32 ip prefix-list vrfInternet-import-prefixes seq 101 permit 126.96.36.199/24 le 32 ip prefix-list vrfInternet-import-prefixes seq 102 permit 188.8.131.52/27 le 32 ! route-map vrfInternet-import-map permit 10 match ip address prefix-list vrfInternet-import-prefixes ! route-map vrfInternet-import-map deny 99 ! line vty !
Listing 9: FRR configuration of a tenant firewall to show route leak and prefix announcement filtering.
Traffic to external networks is routed via the firewalls to the exit switch. The exit switch, as an exception, connects to the Internet Service Provider using numbered BGP. Numbered BGP implies to assign IPv4 addresses to network interfaces (See Listing 10, swp1). Interface swp1 is enslaved into
vrf vrfInternet to include the port that is connected to the ISP within the VRF that is expected to contain a way into the Internet. The exit switch is configured to be a VTEP to terminate traffic coming from the firewall VRF
# /etc/network/interfaces # [...] iface swp1 mtu 9000 vrf vrfInternet address 184.108.40.206/30 # [...] iface vlan4000 mtu 9000 address 10.0.0.71/24 vlan-id 4000 vlan-raw-device bridge # [...] iface vlanInternet # [...] iface vniInternet # [...] iface vrfInternet # [...]
Listing 10: Fragment of interfaces configuration of exit switch.
The configuration of FRR is equivalent to the previously discussed ones. It contains a global BGP instance configuration that enables IPv4 unicast and l2vpn evpn address families. The vrfInternet BGP instance defines
neighbor 220.127.116.11 peer-group INTERNET to use "old style BGP" transit network.
# [..] vrf vrfInternet vni 104009 ! # [...] router bgp 4200000031 bgp router-id 10.0.0.31 neighbor FABRIC peer-group neighbor FABRIC remote-as external neighbor FABRIC timers 1 3 # [...] ! address-family ipv4 unicast neighbor FABRIC activate redistribute connected route-map LOOPBACKS exit-address-family ! address-family l2vpn evpn neighbor FABRIC activate advertise-all-vni exit-address-family ! router bgp 4200000031 vrf vrfInternet bgp router-id 10.0.0.31 bgp bestpath as-path multipath-relax neighbor INTERNET peer-group neighbor INTERNET remote-as external neighbor INTERNET timers 1 3 neighbor 18.104.22.168 peer-group INTERNET ! address-family ipv4 unicast neighbor INTERNET route-map PREPEND-PATH-TO-DISFAVOR-IN in neighbor INTERNET route-map PREPEND-PATH-TO-DISFAVOR-OUT out exit-address-family ! address-family l2vpn evpn advertise ipv4 unicast exit-address-family ! route-map LOOPBACKS permit 10 match interface lo ! route-map PREPEND-PATH-TO-DISFAVOR-IN permit 10 set as-path prepend last-as 2 ! route-map PREPEND-PATH-TO-DISFAVOR-OUT permit 10 set as-path prepend last-as 2 ! vrf mgmt ip route 10.0.0.0/24 10.0.0.71 nexthop-vrf default exit-vrf ! ip route 0.0.0.0/0 192.168.0.254 nexthop-vrf mgmt ! line vty !
Listing 11: Fragment of FRR configuration on exit switch to give an example for numbered BGP and route leak.
In addition to the standard BGP setup the exit switches have configured
static route leak to support internet access during PXE. There is one route leak from
default VRF into the
mgmt VRF defined with:
ip route 0.0.0.0/0 192.168.0.254 nexthop-vrf mgmt and another one from
mgmt VRF into the
ip route 10.0.0.0/24 10.0.0.71 nexthop-vrf default. The first one adds a default route into the
default VRF and the second one routes traffic destined to the PXE network back from
mgmt VRF into the
To reach out into external networks each of the exit nodes joins a BGP session with a distinct external router. There is a different latency to each of these routers. To favor routes of exit nodes connected with lower latency over exit nodes with higher latency two route maps
PREPEND-PATH-TO-DISFAVOR-OUT are added to high latency exit nodes. These route maps apply actions to prolong the path of the incoming and outgoing routes. Because of this path extension BGP will calculate a lower weight for these paths and favors paths via other exit nodes. It is important to know that within an address family only one route map (the last) will be applied. To apply more than one actions within a route-map the required entries can be applied to a single route-map.
Before a bare metal server can act as tenant server or tenant firewall, it has to be provisioned. Within the Metal domain, this provisioning mode is called "PXE Mode" since it is based on Preboot eXecution Environment (PXE). PXE uses protocols like DHCP. This requires all bare metal servers that need provisioning to be located in a layer-2 domain where DHCP is available. This domain is a VLAN
vlan4000. A DHCP server for PXE Mode is installed on the exit switches to work in this specific VLAN.
# /etc/default/isc-dhcp-server INTERFACES="vlan4000"
Listing 13: DHCP server configration of exit switches.
As shown in listing 13, the PXE DHCP server is located on the exit switches and enforced to bind to interface
vlan4000. This represents a layer-2 separation that allows only DHCP clients in the same VLAN to request IP addresses. Only unprovisionned bare metal servers are configured to be member of this VLAN. Thus unwanted or accidential provisionning is impossible.
vlan4000 on the leaves (that face the bare metal servers) the exit and leaf switches are configured as VTEPs and share an interface configuration that contains the required interfaces (Listing 13). Since no EVPN routing is in place
vni104000 is configured as an L2 VNI (there is no mapping for this VNI in
# /etc/network/interfaces # [...] iface bridge bridge-ports vni104000 [...] bridge-vids 4000 [...] bridge-vlan-aware yes iface vlan4000 # [...] iface vni104000 # [...]
Listing 13: Interfaces configuration on exit and leaf switches to show DHCP/PXE related fragments.
On the leaf switches the bare metal server facing ports are configured as VLAN access ports to carry the traffic for only the PXE VLAN
vlan4000 (listing 14)to separate unprovisioned from other bare metal servers.
# /etc/network/interfaces # [...] auto swp1 iface swp1 mtu 9000 bridge-access 4000 # [...]
Listing 14: VLAN access setup for bare metal server facing ports on leaves.
Once a bare metal server is provisioned it is deconfigured from PXE VLAN
vlan4000 to avoid accidential or unwanted provisioning.
During provisioning bare metal servers get internet access via the management network of the exit switches. This is because the exit switches are announced as DHCP gateway to the DHCP clients.
To manage network switches beside the out-of-band system console access a further management access is required. For this purpose the concept of Management VRF is applied. The Management VRF is a subset of VRF. It provides a separation between out-of-band management network and the in-band data plane network by introducing another routing table mgmt. SONiC supports eth0 to be used as the management interface.
To enable and use the Management VRF all switches have to be connected via their eth0 interface to a management-switch. The management switch is connected to a management server. All access is established from within the managment server. Logins to the switch are set into the Management VRF context once the Managment VRF is enabled.


Southwire’s Medium Voltage Switchgear and Substation Cable is a non-shielded, protected, carefully stranded cable that has no voltage rating. The cable doesn’t have UL listing and isn’t identified by the National Electrical Code (NEC). The cable’s mainly use is for installment in medium voltage switchgear, motor controllers, and substations. In regard to make use of inside enclosures and equipment, even if this cable itself is not UL listed, a UL approval can be acquired on the complete assembly by getting the system tested and approved.
The cable includes a finely stranded conductor to enable simpler installation and tight bends inside enclosures. Because the cable doesn’t have metal shield it’s easy and straightforward to terminate. There isn’t any semi-conductive insulation shield to get rid of and there’s no metallic shield to terminate. Termination is as easy as taking out the insulation to reveal the conductor and attaching the lug. The possible lack of a complex termination and the truth that the cable’s conductor is finely stranded facilitates quick and easy use and installation inside enclosures and substations.
No Standard or Approvals
Even though Southwire’s Medium Voltage Switchgear and Substation Cable doesn’t have industry approvals, the cable does meet the requirements for insulation utilized on conductors (whether rigid or flexible) within clause 126.96.36.199 of ANSI/IEEE C37.20.2-1999 and clause 188.8.131.52 of ANSI/IEEE C37.20.3-2001), which identifies the test requirements for insulating material utilized on bus bars. On top of that, the cable has gone by the fundamental Insulation Level (BIL) test that simulates a Lightning Strike with-stand of 150kV. This is actually the particular test voltage employed for BIL testing of switchgear operating at 38kV. Passing these tests shows the cables viability to be utilized within medium voltage switchgear.
No Voltage Rating
The cable doesn’t have voltage rating since the voltage a conductor can safely hold is associated with the cable’s insulation, air spacing and the dielectric strength of the insulator. The NEC offers no recommendations for cable spacing inside enclosures for insulated cables. They have printed cable spacing data for outdoor and indoor bare cables in Table 490.24.
Insulated cables, like Southwire’s Medium Voltage Switchgear and Substation Cable could be spaced closer together than a non-insulated cable. Southwire has carried out testing on this cable in managed conditions and has established spacing guidelines for installation inside medium voltage enclosures under ideal conditions. Under less than ideal circumstances where water, dirt, dust, or other contaminants can find their distance to the enclosure, cable tracking can happen and cause failure. It is quite crucial that the inside of the enclosure be kept free and clean of contaminates.


“AMKODOR” develops lithium-ion batteries for its equipment
During 2019-2020, Production Unitary Enterprise "Amkodor-Radian" (part of JSC "Amkodor-Belvar"), in scientific and technical cooperation with the Joint Institute of Mechanical Engineering of the National Academy of Sciences of Belarus, developed lithium-ion batteries for electric forklifts and electric trucks manufactured by JSC AMKODOR, the holding's management company.
The "Joint Institute of Mechanical Engineering of the National Academy of Sciences of Belarus" has the necessary testing equipment, and most important -employees who have been developing an electric bus, an electric utility vehicle, a Belarusian electric ice filling machine and other electric-powered equipment, including software for them, for more than two years. "Amkodor-Radian" and another company of JSC "Amkodor-Belvar" - the Unitary Enterprise "SVT Plant" - in recent years have also accumulated expertise in the production of traction batteries and electronic components for maintenance and control of their condition.
The use of lithium-ion batteries is expanding significantly in the world. They are used not only in electric transport, but also in the electric power industry, on lifting machines, in telecommunications systems; in solar systems; in railway transport; in uninterruptible power supplies. In general, it is used everywhere where energy conservation is required for next use.
In fact, new technologies have revolutionized electrical engineering, rapidly replacing lead-acid batteries. The reason lies in a number of very significant advantages. For example, the service life of lithium-ion batteries (3000-5000 charge-discharge cycles) is 2-3 times longer than of lead-acid batteries. They don’t require controlling the level and refilling of the electrolyte, which means that there is no need for its preparation, training of service staff and the allocation of specially equipped rooms for charging. Honestly speaking, a lithium-ion battery, just needed to be connected to a special socket anywhere and at any time (for example, during a lunch break), because it doesn’t emit aggressive acid vapors and is without a memory effect. The latter is very important, because new technologies allow you to recharge a partially discharged battery without any damage to it a lot of times.
The tightness of the new batteries is a guarantee of their safety in the food and chemical industries, as well as in fire-hazardous industries.
Among the advantages of lithium-ion batteries are small weight and size (2-3 times less than traditional ones), fast charging (3-7 times), long continuous operation time (up to 8 hours or more with partial recharges).
One of the first 48V 350ACH batteries created at the "Amkodor-Radian" is currently undergoing factory tests at the "Amkodor-Unicab" enterprise.
It is installed on the AMKODOR E16 electric forklift truck with a load capacity of 1600 kg instead of the lead-acid 48V 500Ah.
The tests are successful and according to experts ' calculations, the operation of such a loader will recoup the cost of purchasing a lithium-ion battery for 2.5 years, while the owner will only save more than 7 thousand rubles on reducing electricity consumption during this time. And after that, the battery life is still far from being used up, the remainder will be another 2000-4000 charge-discharge cycles.
In the future, new batteries are also planned to be equipped with electric fork-lift trucks AMKODOR E25 and platform electric trucks AMKODOR EP20 and AMKODOR EP30.
In the meantime, testing of the AMKODOR E16 with a new traction battery continues, the company is working on creating prototypes of new models of lithium-ion batteries of various capacities, which, without a doubt, are the future.


Wednesday, June 19th 2013, 13:00 - 17:30h, FHI, Leusden
Where do we find the right technology partner?
Pick up the technology for your company's future!
You are invited for the 'MicroNano 4FutureProfit' on Wednesday, June 19th to meet and network with innovation partners, OEMs and development companies. This event is organised in cooperation with NanoNextNL (see Cooperation).
During this afternoon, we aim to close the gap between requests for technology solutions and technology innovation and supply in the fields of microsystem and nano technology. The MinacNed members, all high tech companies and institutes among the fields of lab-on-a-chip, microfluidics, nano instrumentation, MEMS, sensors, deposition technology, nano coatings and more expose themselves, show their new development or products and build innovative leads with their knowledge and expertise. Dutch companies, from high-tech manufacturing industry, OEMs, first tier suppliers and especially the underlying links, who are searching for development capacity and innovation partners, are welcome to this inspiring afternoon.


I operate a simplex EchoLink node in Middleton on 146.500, PL Tone 100.0. It is right in town with reasonable coverage as far south as Costco and west to the interstate.
You must transmit at 100.0 hz tone in order to be received by the receiver. This is necessary to prevent interference and local simplex traffic from being repeated on to the EchoLink network inadvertently. This node also transmits a 100.0 hz tone – you can configure your radio to decode this tone and not unmute on fringe signals elsewhere in the valley.
This node consists of a 2 channel Motorola Radius mobile set to 25 watts, powered by an Astron RS-35M that also feeds a high power fan to blow air across the radio heat sink. The radio is connected with 50 feet of CNT600 coax to a custom tuned Ventenna at 20′ above ground level. The radio is interfaced with a Tigertronics Signalink USB to a surplus Dell laptop running Windows 7 and the EchoLink software. You can connect directly to this node by using the EchoLink software on a PC, using the Android app or over the air through another EchoLink node by dialing 707383.
To use the Middleton 146.500 PL 100.0 Simplex Node:
Dial node number to connect directly, i.e. 707383
By call sign dial C+CALLSIGN+#, i.e. CK6LOR#
Status (currently connected node/conference) 08
Disconnect last connected station #
Disconnect all stations ##
Listen Only 0510
Listen Only Off 0511
Play Middleton Node Info *
Query By Call 07
Query By Node 06
Random Conference 02
Random Link 01
Random Node 00
Random User 03
Reconnect to last node/conference 09


İf you are interested in artificial intelligence one of the most important issues you should know is the brain function of the human brain. Because artificial intelligence is based on human intelligence. That is why, scientists need to know how their brains work because they try to replace human intelligence. If we describe the structure of the brain in a short, the information will be processed in the brain and the result will be acted upon. This description is an open illustration of closed box logic for those involved in software management or at least for those who are part of the software engineering course.
In fact, when we go to a little bit deeper, we can see that these processes are imitated by machines, we can observe the input and output of the data, because the working principle of today's computers is based on this logic. However, it performs predetermined operations to make decisions. However, studies on the human brain did not help to create a complete theory of human brain activity. Even now it is difficult to explain how works brain of human. Although psychotronic brain structures are effective in understanding the functional structure of the human brain, they have also an important role in the development of brain research, but have not yet been able to achieve experiments with these devices.
Although Delqado's experiments and animal’s brain research have been successful over 70 years, humans have failed to succeed in the same experiments. One of the most important reasons for this is the complexity of the human brain. We can compare the decision-making ideology with machines that the initiator is Lutfi Aliaskarzadezade. Although it is not clear how the brain works, it is wrong to say that these studies did not work. At least we know about 20% of our brain structure. By using this percentage and combining our own strength, we will be the best tool to achieve a hundred percent of the artificial intelligence we have prepared.


513 Blockpraktikum Einkristallzüchtung, Elektronenmikroskopie, Pulverdiffraktometrie
High-temperature single crystal growth out of solution
In this advanced lab session, we perform single crystal growth out of a high-temperature metallic solution. We study the crystallization processes, and the laws of thermodynamics which control the solidification of a binary solution and rule these processes. Phase diagrams are the most important tool for crystal growth. They are represented as maps, in the temperature-composition space, of the state of the system in thermodynamic equilibrium. After learning how to read a binary phase diagram and how to use it determine the right parameters for the growth process (such as liquidus, solidus, solidification ranges and eutectic temperatures), we will grow single crystals of a binary phase using a self-flux technique that will be explained in details. The appropriate composition and amount of starting materials will be weighted and loaded in a crucible, sealed in protective atmosphere and heated in a furnace. After a first analysis of the growth, the obtained single crystals will be characterized in subsequent lab sessions using x-ray diffraction and electron microscopy. The lab session takes place at the Institute of Experimental Physics IV, NB 4
Responsible: Dr. Haneen Abushammala
Electron microscopy and energy-dispersive x-ray spectroscopy
In this advanced lab session, the single crystals which were obtained previously will be characterized using electron microscopy and energy-dispersive x-ray spectroscopy. A scanning electron microscope (SEM) is commonly used for analysis of the surface of bulk samples. In addition to imaging the surface, it allows to obtain information about the local chemical composition via energy-dispersive x-ray spectroscopy. In research and development, scanning electron microscopes are used from semiconductor- and nanotechnology to biology. In an SEM, a finely focused electron beam scans the sample surface. These primary electrons interact with the surface. Products of this interaction, such as secondary electrons or x-rays, are used for imaging and sample analysis. The goal of this advanced lab session ist to understand the fundamental physical processes involved and the diverse interaction mechanisms of electron beam and sample. In the course of the lab session, the students will become familiar with sample preparation and operation of the SEM. While studying their own samples, the students will discuss the different contrasts mechanisms and interaction between electron beam and sample. In addition to analyzing the sample surface, the sample composition and chemical homogeneity will be studied.
Responsible: Dr. Sangeetha N.S.
Powder x-ray diffraction
In this advanced lab session, the single crystals which were obtained previously will be characterized with powder X-ray diffraction (PXRD). PXRD is a major technique in the investigation of condensed matter. It is primarily used for phase identification and for determination of crystal structure and lattice parameters of crystalline materials. The goal of this experiment is to teach the students the basics of PXRD. The students will start by preparing finely ground samples of investigated materials as well as a standard material for comparison. During the experiment the students will be given a detailed introduction of the x-ray diffractometer, showing them all of the major components and teaching them how to handle it. After collecting the diffraction data, the students will be asked to analyze them using standard programs and provide detailed information on the investigated material such as composition, structure and lattice parameters. The obtained results will be compared to literature.
Responsible: Dr. Luqman Mustafa


For my non techie friends and family, IoT = the Internet of Things. So what does that mean? Well as our computing devices get smaller and smaller, we are able to create more things that can connect to the ever growing internet. It isn't just your computer or mobile phone anymore. We have tablets, game consoles, smart TVs and other media devices. We now also have thermostats (Nest), home automation systems, refrigerators, toasters, small robots, cats and dogs living together MASS HYSTERIA!
For the most part this space has been frequented by micro-controller boards like the Arduino, Beaglebone, and the much smarter Raspberry Pi computers. Newer and smaller boards have now entered the market and they have come ready for the internet. Spark.io has been releasing a different board every few months. Their first was a Wi-Fi enabled Spark Core, then came the much smaller Photon (about the size of a postage stamp), and now they have a cellular enabled board called the Electron.
So with all this IoT growth, it is only natural that Microsoft decided to jump in the pool. As a software company, you almost need to be in there if you want to stay relevant. So what's this new Windows 10 IoT all about? Well it is the latest in Microsoft's embedded OS. As of now they are supporting 3 hardware platforms - Raspberry Pi 2, MinnowBoard Max, and Galileo. Galileo has supported previous versions of Windows embedded but does not yet support Windows 10. But Microsoft has instructions on how to get started anyway. I will focus on the Raspberry Pi 2. This latest version of Pi was released a few months ago and is a pretty impressive tiny computer (just don't use high powered camera flashes next to it). With a 900MHz quad-core ARM Cortex-A7 processor and 1GB of RAM, it certainly has some juice to run a scaled down Windows OS.
So what will you need to get going? Well first a Raspberry Pi 2, availability is up and down so grab one when you can. Next you will need something to run Windows 10 Insider Preview (current version is 10074). I ran it in a VM but there are some very annoying bugs in the current version. I have not run it on a physical device yet since I don't have spare laptops lying around. You will also need Visual Studio 2015 to do development on. Follow the instructions on their github page. Flashing the SD card is pretty straight forward. Once the Pi is booted up, you will have a screen with some basic information including the name of the device and it's IP address. You will need to hardwire it with ethernet as it does not appear to have any out-of-box support for your standard wireless controllers. Once you have the device info you can connect via Powershell from your dev box. This can be done from Windows 7 or 8.1 running updated Powershell. There are a few other steps you must complete to finish the setup. Unfortunately the rest of the development requires Visual Studio 2015.
One thing to note about Windows IoT, it comes with remote debugging enabled. So I would recommend not tossing this on the public internet until it is production ready. Visual Studio 2015 does have some IoT management features, hopefully that will allow you to enable/disable remote debugging when required. The geek in me is loving all this, but the security guy wants to start drinking heavily. The world is becoming more and more connected each day. Some of these technologies are improving our lives in various ways. We have more energy efficient homes, doctors can perform maintenance on healthcare devices without surgery, parents can keep track of their children, and brew masters can monitor their brewing processes without spending long hours at the brewery. But with every newly connected device there is a new possible risk for exploitation. Nothing is unhackable. If a vendor tells you this, they are lying. So if it can be turned on or off, it can probably be hacked. But without hacking we would probably not have our most successful breakthroughs in science and technology. Just like the discovery of nuclear power, it is both a great energy resource and extremely destructive force if put in the wrong hands.
So, don't be afraid of the Internet of Things, go out there, make something! Who knows maybe that something will be used in future space explorations or help an amputee walk again!


It started in 1962 at Purdue University, the precursor to the Digital Age, when the first Department of Computer Science was established. Computer Science is the most versatile and innovative fields today. In simple terms, those who major in computer science use technology to solve problems. Computer science impacts everything. Yes, everything in society today. Most industries rely on data and software programs developed by computer science graduates. The Computer Science curriculum is constantly evolving and adapting to the latest innovative technology. In four years at a university, a computer science major will hardly touch half of the material in their field. It is next to impossible to fit into four years of curriculum. In order to bridge the gap between academia and applied Computer Science, Massachusetts Institute of Technology gave Computer Science a college of its own. With education shifting to technological fields, MIT aims to offer its students dual degrees and integrate computing into departments across the university. With technology in the driver’s seat, it is looking like other higher education institutions will soon follow MIT. To accommodate the increase in technology in our world today, higher education must adapt to fill the void of much needed computer scientists. Although a bachelor’s or master’s degree in computer science is not easy, it is rewarding. With advancing technology, the demand for Computer Science Majors only rises. Whether advancing transportation, healthcare, or an entrepreneur of your own business like our co-founders, a degree in Computer Science has endless opportunities.


- 20.07.2018: We extended the deadline for abstract submissions to 27th July!
- 12.06.2018: Our 2nd Keynote Speaker will be Prof. Dimitri Van de Ville talking about graph signal processing for human brain imaging.
- 06.06.2018: Deadline for complete papers is extended until 18th June!
- 21.05.2018: CMT System is open for submissions of both, complete and abstract papers! Click here to submit your manuscript
- 21.05.2018: PC Members are online! (More TBA)
- 09.04.2018: This year we will accept papers in two modalities: Complete papers (8-10 pages) and Abstract papers (2-3 pages). Read more about it in the section "Submit a paper"
- 09.04.2018: GRAIL accepted papers will be invited to submit an extended version to a Special Issue on Graphs in Biomedical Image Analysis that we will organize in a top-tier journal of the area.
- 09.04.2018: The GRAIL Best Paper Award will include a cash price sponsored by EntelAI !
- 30.03.2018: The GRAIL Website is up and running!
GRAIL 2018 is the second international workshop on GRaphs in biomedicAl Image anaLysis, organised as a satellite event of MICCAI 20178 in Granada, Spain.
Graph-based models have been developed for a wide variety of problems in computer vision and biomedical image analysis. Applications ranging from segmentation, registration, classification, and shape modelling, to population analysis have been successfully encoded through graph structures, demonstrating the versatile and principled nature of the graph based approaches.
Graphs are powerful mathematical structures which provide a flexible and scalable framework to model objects and their interactions in a readily interpretable fashion. As a consequence, an important body of work has been developed around different methodological aspects of graph including, but not limited to, graphical models, graph-theoretical algorithms, spectral graph analysis, graph dimensionality reduction, and graph-based network analysis. However, new topics are also emerging as the outcome of interdisciplinary studies, shedding light on areas like deep structured models and signal processing on graphs.
With this workshop we aim to highlight the potential of using graph-based models for biomedical image analysis. Our goal is to bring together scientists that use and develop graph-based models for the analysis of biomedical images and encourage the exploration of graph-based models for difficult clinical problems within a variety of biomedical imaging contexts.
The covered topics include but are not limited to:
- Probabilistic graphical models for biomedical image analysis
- Discrete and continuous optimization for graphical models
- Signal processing on graphs for biomedical image analysis
- Deep/machine learning on structured and unstructured graphs
- Convolutional neural networks on graphs
- Graphs for large scale population analysis
- Graph-based shape modeling and dimensionality reduction
- Combining imaging and non-imaging data through graph structures
- Graph-based generative models for biomedical image analysis
- Graph spectral methods
- Algorithms on graphs
- Graphs in neuroimaging
- Applications of graph-based models and algorithms to biomedical image analysis tasks (segmentation, registration, classification, etc.)
Prof. Michael Bronstein
University of Lugano / Tel Aviv University / Intel Perceptual Computing
Deep Learning on Graphs
Bio : Michael Bronstein is a full professor of Informatics at USI Lugano in Switzerland, associate professor of Applied Mathematics at Tel Aviv University in Israel, and a Principal Engineer at the Intel Perceptual Computing group. He got his Ph.D. with distinction in Computer Science from the Technion in 2007. He holds or has previously held visiting appointments at Politecnico di Milano, Stanford, Harvard, and MIT. His research appeared in the international media such as CNN and was recognized by numerous prestigious awards, including several best paper awards, the Hershel Rich Innovation Award (2003), three ERC grants (Starting Grant 2012, Proof of Concept Grant 2016, and Consolidator Grant 2016), two Google Faculty Research Awards (2015, 2017), Radcliffe Fellowship from the Institute for Advanced Study at Harvard University (2017), and Rudolf Diesel Industrial Fellowship from TU Munich (2017). Michael is the author of the first book on deformable 3D shape analysis, editor of four books, more than 150 papers in top scientific journals and conferences, and inventor of 25 granted patents. He has chaired more than a dozen of conferences and workshops in his field, and has served as area chair at ECCV 2016 and ICCV 2017 and as associate editor of four top journals is his field (IJCV, SIAM J. Imaging Sciences, CVIU and IJVC). He has given over 100 invited and keynote talks during his career.
During the last years, Michel has published several works about deep learning on graphs, contributing to the development of this incipient research area.
Prof. Dimitri Van De Ville
EPFL / University of Geneva
Graph Signal Processing Opens New Perspectives for Human Brain Imaging
Abstract: State-of-the-art magnetic resonance imaging (MRI) provides unprecedented opportunities to study brain structure (anatomy) and function (physiology). Based on such data, graph representations can be built where nodes are associated to brain regions and edge weights to strengths of structural or functional connections. In particular, structural graphs capture major neural pathways in white matter, while functional graphs map out statistical interdependencies between pairs of regional activity traces. Network analysis of these graphs has revealed emergent system-level properties of brain structure or function, such as efficiency of communication and modular organization. In this talk, graph signal processing (GSP) will be presented as a novel framework to integrate brain structure, contained in the structural graph, with brain function, characterized by activity traces that can be considered as time-dependent graph signals. Such a perspective allows to define novel meaningful graph-filtering operations of brain activity that take into account the anatomical backbone. For instance, we will show how activity can be analyzed in terms of being aligned versus liberal with respect to brain structure, or how additional prior information about cognitive systems can be incorporated. The well-known Fourier phase randomization method to generate surrogate data can also be adapted to this new setting. Finally, recent work will highlight how the spatial resolution of this type of analyses can be increased to the voxel level, representing a few ten thousands of nodes.
Bio: Dimitri Van De Ville (Senior Member, IEEE) received the M.S. degree in engineering and computer sciences and the Ph.D. degree from Ghent University, Ghent, Belgium, in 1998, and 2002, respectively. After a postdoctoral stay (2002-2005) at the lab of Prof. M. Unser at the Ecole Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland, he became responsible for the Signal Processing Unit at the University Hospital of Geneva, Geneva, Switzerland, as part of the Centre d'Imagerie Biomédicale (CIBM). In 2009, he received a Swiss National Science Foundation professorship and since 2015 became Professor of Bioengineering at the EPFL and the University of Geneva, Geneva, Switzerland. His research interests include wavelets, sparsity, graphs, pattern recognition, and their applications in computational neuroimaging.
Dr. Van De Ville served as an Associate Editor for the IEEE Transactions on Image Processing from 2006 to 2009 and the IEEE Signal Processing Letters from 2004 to 2006, as well as Guest Editor for several special issues. He was the Chair of the Bio Imaging and Signal Processing (BISP) Technical Committee of the IEEE Signal Processing Society (2012-2013) and is the Founding Chair of the EURASIP Biomedical Image & Signal Analytics SAT. He is Co-Chair of the biennial Wavelets & Sparsity series conferences, together with V. Goyal, Y. Lu, and M. Papadakis. He was a recipient of the Pfizer Research Award 2012, the NARSAD Independent Investigator Award 2014, and the Leenaards Foundation Award 2016.
Submissions should be done through the GRAIL CMT portal. The submission system will open on May 20th.
This year we will accept papers in 2 formats:
- Complete papers: Papers describing original research with length of 8-10 pages. These papers are eligible for the "Best Paper Award" and will be published in the GRAIL Open Proceedings and Lecture Notes in Computer Sciences (LNCS) series. Submissions should be anonymous, and formatted following the LNCS Style. All complete papers will be peer-reviewed by 3 members of the program committee, with double-blinded review process. The selection of the papers will be based on significance of results, technical merit, relevance and clarity of presentation.
- Abstracts: In order to encourage interesting discussions within the community, this year we are also inviting papers describing on-going, recently published or original research in a short paper of 2-3 pages. Depending on the number of submissions, we will organize a poster or oral session during GRAIL, where accepted short papers will be invited to present. The selection of the short abstracts will be made by members of the program committee and/or organizers. Submissions should be anonymous, and formatted following the LNCS Style.
The authors of the best paper of the workshop will receive a cash price (sponsored by EntelAI).
Accepted papers will be invited to submit an extended version to a Special Issue on Graphs in Biomedical Image Analysis in a top-tier journal of the area, that we will organize after the event.
|20 May 2018||Submission system opens.|
|Complete Paper submission deadline.|
|10 July 2018||Reviews due.|
|Notification of acceptance.|
|20 July 2018||Camera-ready papers (Complete papers).|
|Abstract Paper submission deadline.|
|3rd August 2018||Notification of acceptance for Abstract Paper submission.|


LOC have a couple of these Seiko DPU-3445 printers. They usually work pretty well, but typically, one of them stopped working just at the wrong time.
The printer would feed and print out the printer settings sheet (with the printer off, hold down both keys and release the power one first). It just wouldn’t print out results.
The settings sheet showed Data Input as IrDA and the Data Input mode as Auto Select.
These needed changing to:
DIP Switch 1
Data Input: Serial
Baud rate: 4800bps
Bit length: 8 bit
Stop Bit: 1 bit
Data Control: Busy
DIP Switch 2
Data Input Mode : Serial
The way to do this is a little complex, but the manual is available here.
DIP Switch 1 should show 11001010
DIP Switch 2 should show 11111101
No need to change DIP Switch 3.


First I configured the device to use inside my 3CX pbx phone system to connect analog phones to the system. This was fairly straightforward especially with the notes provided on the 3CX blog. After following these steps the device showed a status of REGISTERED in the device configuration screen as well as in the 3CX console. This enabled me to connect an analog telephone to function as an extension on my VOIP phone system - it could send and receive internal extension calls and send and receive calls with phones outside the system.
Next I wanted to see if I could use this device to connect a fax machine to send/receive faxes over a VOIP SIP service. I have accounts with a few SIP services and I tried the connection with my primary service from NexVortex and also with another service from CallCentric. These services both support T.38 which is a method for sending fax data over an internet connection. I'm not going to attempt to explain this but suffice it to say that you need at least this to have a hope of sending a fax over the internet. Even so, this is not a guarantee that it will work in every situation. There are many variables involved.
In any event, my limited test did work for sending a fax and receiving a fax. By the way, for this test, and to keep things simple, I configured the Grandstream 286 directly to the SIP provider - bypassing the 3CX server. This required some network configuration changes to route the SIP traffic from my router directly to the Grandstream. I used an available DID which routed directly to the Grandstream.


A free WiFi https://renewal-coupons.org/tools-tips-expressvpn-and-a-deal-for-you reader is a method that can identify the cellular networks in your town. These devices are great if you have challenges connecting into a WiFi network or should you just want to test out your connections. They will also help you troubleshoot wireless challenges. There are several cost-free WiFi scanners available, nevertheless the paid types are much more complex. Let’s look at some of them. Here is a look at a number of the more popular kinds.
WiFi Scanner is useful for finding nearby systems and getting vital WiFi information about them. It is also useful to find ad hoc systems, where you can make a network not having entering a password. The program also has a Speed Check function, which allows you to check the down load and upload speeds of the numerous networks. You can save scan periods to review different ones. You can share the results with all your friends to diagnose the problem and find out if it’s the network’s carelessness.
A free Wireless scanner for Mac is able to do a full study of the surrounding networks and offer vital Wi-fi information. It can also generate a heat map, which helps you find the WiFi appliances or units that will gain access to the network. The program could also display sign coverage, channel usage, and security options. It can also preserve scan instruction so you can compare them afterwards. It is possible to utilize a free Wireless scanner in your Mac to determine which network has the maximum signal strength.


The need for protection of personal information privacy and the distrust of transferring internal information to a third party make it increasingly difficult to enhance the accuracy of deep learning in large datasets. ari uses federal learning to encrypt the learning model and the parameters on the blockchain. The data of each zone does not need to be trained, ensuring privacy and data security, and it conforms to the personal information protection laws of various countries. The characteristic parameters after learning are returned to the model’s central system. The shared AI model of each zone does not belong to a single unit or organization as well.
Using blockchain to encrypt is different from using Certificate Encryption (cA). The organization that signs the certificate has the root visa (Root CA), which also gives the right to use the AI model. This feature is time effective and there is no open guarantee mechanism for storing the root visa.
Graphics Processing Units (GPUs) can significantly accelerate numeric calculations for AI model development and the inferencing time. That is, GPUs can potentially speed up the AI development.
Under the scenario in figure 1 (without GPU sharing), a single GPU needs lots of time to finish a complex task. But, GPU2 is free. If GPU2 can help GPU1 and GPU3 with their tasks, time could be saved.
Let’s look at another scenario in figure2, all the GPUs are dealing with the same computing task. However, they are not fully loaded. In this case, GPUs have the ability to handle more tasks.
With GPU sharing, we can increase the throughput per unit time after task scheduling.
When developing an AI model, we can use the GUI to drag and drop all the functions, algorithms, actions, or other process you need. Or, you can even make them an automated pipeline.
Take a facial recognition system in school for example. Parents will receive a message when students recognized by the system when they arrived at the school; while a security will be alerted when the camera captured an unrecognized person.
The facial recognition process includes various steps such as face detection (localization), feature extraction, face identification and verification.
During face detection, when the system receives the RGB images, the images will be first processed with HOG (histogram of gradients.) The SVM (support vector machine) algorithm will then implemented to find where the face is located.
Here the SVM model is pre-trained with LFW (Labeled Faces in the Wild) and some images without faces. Noted that we used PCA (Principal component analysis) to separate eigen-face before feed the images into SVM.
With the pipeline, you can do all the tasks mentioned previously by simple drag-and-drop function. That is the say, you can build and manage your AI development environment easily and efficiently. Moreover, you can pick a best performance algorithm under different container image with different AI models.
CDSS is one of the target products of the ari AI development platform. It utilizes AI into practice SaaS applications. During the development of the AI model, CDSS provides data analysis and statistics. If the statistical data is imbalanced, the artificial intelligence learning will be inaccurate. However, performing data cleaning beforehand will greatly affect the results. The CDSS of ari is an integration of AI model training, data analysis, diagnosis recommendations, and treatment images. It evaluates and classifies the images to determine if the disease is positive or negative, and estimates the probability of getting the disease.


Mercury Marine Advances Electric Propulsion with Avator 20e and 35e Electric Outboards
Mercury Marine recently introduced its Avator 20e and 35e electric propulsion systems, with plans to unveil two additional electric outboard products in the coming months as part of its commitment to leading the advancement of electric marine propulsion.
“We’re thrilled to advance our electrification strategy and the Mercury Avator brand with the introduction of the 20e and 35e electric outboards,” says John Buelow, Mercury Marine president. “Building off the success of the Avator 7.5e, these outboards set new benchmarks for innovation, performance, and connectivity. The investment and advancements we’re making position Mercury to continue expanding our Avator portfolio and soon deliver additional industry-changing, low-voltage electric outboards.”
The Avator 20e and 35e feature many of the innovative features of the 7.5e, with added power and the ability to connect multiple Avator batteries to extend range and run time.
Ideal for powering small vessels like fishing boats, rigid inflatables, tenders and small pontoons and featuring tiller or remote steering, the 20e can produce similar acceleration as a 5hp FourStroke outboard, while the 35e generates acceleration that is comparable to a Mercury 9.9hp FourStroke outboard.
“Avator outboards are intelligent, electric propulsion systems engineered to deliver a superior boating experience with flexibility to easily extend range and runtime,” adds Tim Reid, Mercury Marine vice president of product development and engineering. “Up to four of Mercury’s new 2300Wh batteries can be connected and managed through our exclusive Power Center which safely merges power, enables communication between the batteries and outboard, and allows single point charging.”
Developed in partnership with the Navico Group’s Mastervolt brand and engineered exclusively for marine applications, the Avator 20e and 35e 2300Wh lithium-ion battery is a safe, reliable power source that’s been drop-tested and IP67 rated for water resistance.
Boaters can choose to connect directly to one 2300Wh battery for peak simplicity and portability or extend their range and runtime by adding an Avator Power Center and connecting up to four batteries, with the Power Center serving as a central hub for power cable connections, allowing for a clean and organized boat installation.
To learn more, visit mercurymarine.com.


Digital transformation led by information
Organizations are expected to adopt new business models at a rapid speed. When catering to modern, highly mobile, informed customers, if your company isn’t innovating, it’s faltering.
We’ll help you embrace the latest technologies with Real-Time Business. Through machine learning, advanced analytics and smart devices, you’ll power the future of your business.
Innovate with intelligence.
Explore what happens when you harness the power of real-time data through machine learning, data analytics and more in this short video outlining the Real-Time Business solution.
Data that gets you ahead
Without a robust strategy, you’re forced to be reactive. We’ll help you use data to respond rapidly. With modern data architecture, you’ll access more information faster — while advanced analytics and machine learning help you apply it.
Now you can empower employees to make better informed decisions, gain visibility into customer sentiments in real time, respond to events as they happen, and evaluate potential strategies and models through trends.
Your success starts with Insight.
With 30 years of IT experience, we have the expertise, global reach and partner relationships to help you gain a competitive edge:
countries with Insight
hardware, software &
Thrive in the Internet of Things (IoT).
The IoT is the future of business, but it has a lot of moving parts. Bringing an IoT product to market requires an end-to-end strategy, from assessment and development to deployment and ongoing operations.
Our partnerships with the most trusted names in IT help you implement an IoT business model while reducing risk, cost and time to market — all with ongoing end-user support that gives you peace of mind.
We’ll help you manage customer, partner and employee identities across your new digital platforms while providing an enjoyable yet secure experience. Explore our identity management services to learn even more about this offering.
Easier user access
Enable single sign-on through a hybrid cloud solution that integrates Office 365®, on-premise and Azure® systems.
We’ll help you incorporate multifactor authentication across different personas — from external to internal users.
Through a streamlined, secure way to interact with your business, you’ll boost satisfaction — and efficiency.
Conquer software with DevOps.
From methodology to design, implementation and management, DevOps creates modern software solutions. Improve product delivery and offer feature-rich Software as a Service (SaaS) apps with:
- 24/7 availability on any device
- An automated platform that drives impact
- Quicker insights into your operations
Let’s do big things together.
Innovating is the only way to stay relevant in today’s uber-competitive market. Our unique approach and deep knowledge put you on the path to true innovation.
Contact us to learn more.
Fill out the form below to have an Insight specialist contact you.


TITLE: Repeat Forever
MEDIUM: computer motherboard, computer video card, wire
DIMENSIONS/RUN TIME: 9 3/4″ x 10″ x 3 1/4″
DESCRIPTION/STATEMENT: I view the computer’s motherboard or printed circuit board as being analogous to the skeletal structure in the human body. The video card could be part of the skull that connects the eyes (monitor) to the brain (CPU). Only the motherboard and video card of this computer system were found for preservation.


AAPG and the National Science Foundation have signed a Memorandum of Understanding (MOU) to increase funding for earth scientists over the next five years.
The MOU is the first NSF-energy industry collaboration of its kind, opening doors to new funding possibilities that bring together the expertise of both organizations.
“This is the first NSF-energy industry program for funding academia-centered basic research in the geosciences,” said Tim Killeen, NSF assistant director for geosciences, who signed the agreement along with AAPG Executive Director Rick Fritz.
“Advances in basic geoscience research are the basis for new solutions to societal needs ranging from natural resources to understanding Earth’s history,” said Fritz, also the AAPG Foundation executive director.
“The AAPG Foundation is committed to these scientific objectives,” he added, “and is pleased to partner with NSF to move toward this goal.”
AAPG and NSF will strive to enhance earth science research and education to expand collaborative support for basic research in the earth sciences, which will contribute to:
The MOU will be in force from July 1 to July 1, 2015, at which time it may be renewed.
NSF and the AAPG will coordinate research funding to support new earth sciences research. Photo courtesy of NASA


Jim Grant's Tech Tips
GMC Sonoma, Frustrated's Wife
is the "back-up" light switch located on a "93 GMC Sonoma?
(Standard transmission) and why is the "check gauge" light always
on and why does the water temperature gauge always say "0"?
back-up light switch is mounted on the driver's side rear of the transmission.
That's the easy part, getting at the switch on some applications can be
a vocabulary enhancer. The "check gauge" light and the non-functioning
cooler temperature gauge are likely related. Start by checking the electrical
connector at the temperature sensor. If the connector is unplugged or
corroded, the temperature gauge will not display the engine's coolant
temperature. The "check gauge" light is alerting you to the
fact that there is a problem with the readings on one of the gauges, which
may be related to the inoperative temperature gauge.


Pontoon boats are ideal for a sunset cruise or entertaining friends under the stars. With wide-open deck plans and plenty of comfortable seating, they are the perfect place to relax.
A nice feature on this Bennington pontoon is the LED lighting package. You will find many new pontoon boats with LED sidelights, deck lights, and underwater lights as standard or optional equipment.
These can be single color lights or RGB “color-changing” lights depending on the make and model. Low-end models come with no lighting or single-color LED lights. In contrast, high-end pontoon boats include single-color or color-changing LEDs.
Either way, LED lighting adds a serious “cool factor” to a pontoon boat that attracts plenty of attention at the marina and on your lakefront property.
Color-Changing Pontoon Boat Lights-
As mentioned above, high-end pontoon boats usually have better lighting packages. Frequently, these include RGB, (red, green, blue) LEDs and a light controller.
RGB LEDs are different than other lights. A group of three LEDs, one red, one green, and one blue work together to produce a rainbow of colors.
A light controller precisely controls the intensity of each LED to create different colors. Naturally, better light controllers give you more colors. But they also allow you to change the brightness of each color and even cycle through different colors.
Often, low-end pontoon boats and older boats have no LED lighting. But this is not a disadvantage. It’s an opportunity. With a small investment in time and money, these boats can have a lighting system as good as or even better than what comes from the factory.
In this post, I’ll show you how to install led strips on a pontoon boat as sidelights. In future posts, we’ll expand on this project to include accent lighting and underwater lights.
LED Pontoon Boat Sidelights-
As with factory lighting, you have two options for pontoon boat sidelights. Single color or color-changing.
Single color LED strip lights are cheap and easy to install. Mount them to the underside of the deck on each side of the boat then wire them to a switch.
What You Need-
- Waterproof LED Strip Lights: A silicone sleeve protects the LEDs from water while tinned wire prevents corrosion.
- Silicone Mounting Brackets: Inexpensive and easy to use. Place them over the light strips silicone sleeve of and fasten in place with two screws.
- Drill with Phillips Head Bit
- Switch: Single color lights use an ON/OFF switch.
- Extra wire, butt connectors, crimping tool, and heat shrink.
Wiring the Light Switch-
To begin with, you need a switch to power the lights. Oftentimes, boat manufacturers build boats with an extra switch. If this is the case with your boat, that switch can be used to power the lights.
Look for a power wire coming from the back of the switch. Oftentimes it is red, but it could be one of several other colors as well. Knowing the color of this wire will make it easier to find in the next step.
Wires are often bundled together at the switch panel and routed to a central location. Follow this bundle and look for unconnected wires the same color of the wires from the switch. Use a test light to verify that this is the wire from the switch.
In the event, your boat does not have an empty switch you will have to add one. The video below gives you the basics of how to do that.
Wiring LED Strip Lights-
First, turn off the power at the main battery switch and remove the negative cable from the house battery.
Next, run wires from the switch to each side of the boat. Use a multi-wire butt connector to split the single wire from the switch into two wires.
Crimp the small side of the butt connector to the wire from the switch. Crimp the wires from the lights to the other end of the butt connector. Use heat shrink to seal the connection.
Run one wire to each side of the boat. Use a butt connector to connect that wire to the power wire of each light. Again, crimp and heat shrink the connection.
Finally, connect the negative wires from the lights to the boat’s negative bus bar. Again butt connectors and heat shrink tubing connect the negative wire from the lights to the wire that runs to the bus bar. Crimp a ring connector to the end of the wire for a secure connection to the bus bar.
With all wires connected it is time to test the lights.
- Check for a fuse at the fuse block .
- Reconnect the negative cable to the battery.
- Set the main battery switch on.
Flip the switch to make sure the lights come on. If not, disconnect the power and check your connections.
Finally, you can mount the light strips to the underside of the deck using the silicone mounting brackets. The brackets fit over the light strips and are held in place using two screws. Don’t over tighten the screws as this can damage the bracket.
Color-Changing Pontoon Boat Sidelights-
Color-changing pontoon boat sidelights are more expensive and complicated to wire than single-color lights. But, if you want a truly awesome lighting system it is worth the expense and effort.
RGB light strips have four wires. Red, green, and blue wires supply power to the LEDs. Black is a common ground. Again, look for waterproof RGB light strips encased in a silicone sleeve with tinned wires.
A waterproof RGB light controller is a must. Look for one enclosed in a watertight box or sealed housing.
Several different types of LED RGB light controllers are available. To keep things simple I am only going to talk about a basic controller that uses an ON/OFF momentary switch to control the lights.
There are two parts to this system.
- RGB Light Controller: This is a watertight box that houses the electronics and acts as a hub for wires from the lights and the switch.
- ON/OFF/Momentary Switch: This switch has three positions. On, off, and momentary. An example of a momentary switch is a doorbell. Pressing the switch closes a circuit and sends an electrical signal. Releasing the switch opens the circuit and the signal stops.
Wiring RGB Light Strips-
The switch mounts at the helm. It draws power from a fuse block and grounds to a negative bus bar. Three wires, power, ground, and control, connect the light controller to the switch.
The RGB light controller has three snap-down terminals to accept the wires from the switch. These terminals are color-coded to make wiring easier. The controller has four, color-coded terminals for the wires from the lights as well. Red, green, and blue terminals for the power wires and black for the ground.
RGB strip lights have three power wires, red, green, and blue, along with a black ground wire. **Power wires from the lights must connect to the correct terminal. Red to red, green to green, and blue to blue. It is recommended you use red, green, and blue wires from the lights to the power box.
When all of the wires are connected, turn the power back on and test the lights.
Depending on your light controller, you should be able to change colors, dim the lights, and cycle them between different colors. Check your owner’s manual for how to operate your light controller.
Once everything is working properly the RGB light strips can be mounted to the underside of the deck.
Adding LED lights to your pontoon boat is a wonderful way to make your new lake home truly feel like fun!
Original Post by https://underwater-lightsusa.com/diy-pontoon-boat-sidelights/
Reposted by Scott Freerksen “The Lake Guy”