28 Mar

BGP Additional Paths

BGP routers only advertise the best path to their neighbors. When a better path is found, it replaces the current path. Advertising a path and replacing it with a new path is called an implicit withdraw.

Since we only advertise the best path, a lot of other possible paths are unknown to some of the routers. We call this path hiding.

Extra notes on additional path command syntax:

  • neighbor neighbor-id additional-paths send: We use this to configure the router so it sends multiple BGP paths to a neighbor.
  • neighbor neighbor-id additional-paths receive: If you have a neighbor that sends multiple paths, that’s nice but you still have to configure your local router that it wants to receive multiple paths.
  • bgp additional-paths select : you receive a bunch of paths from your neighbor but you can still configure your router which of these paths you actually want to use.
  • bgp additional-paths install: this tells the router to actually install a backup path that you selected with the “bgp additional-paths install” command.
  • neighbor neighbor-id advertise additional-paths: This configures your router which additional-paths you want to advertise to a neighbor. “all” means all additional-paths.

Reference:
https://networklessons.com/bgp/bgp-additional-paths
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-3s/irg-xe-3s-book/irg-additional-paths.html

19 Mar

Default routes in BGP

There are 3 ways of advertising default route in BGP.

Method 1: Using network 0.0.0.0 command.
It requires only that the route 0.0.0.0 is present in the Interior Gateway Protocol (IGP) routing table. This is the preferred approach.

Method 2: Using default-information originate command.
It requires explicit redistribution of the route 0.0.0.0. This protects against someone accidentally redistributing a default route in BGP which could potentially be disastrous.

Method 3: Using neighbor default-originate command.
This method does not require the presence of the 0.0.0.0/0 network in the routing table of the advertising router.

https://community.cisco.com/t5/routing/bgp-default-information-originate/td-p/772779

http://lostintransit.se/2013/06/12/default-routes-in-bgp/

18 Mar

VPN Ports

 

PPTP:
To allow PPTP tunnel maintenance traffic, open TCP 1723.
To allow PPTP tunneled data to pass through router, open Protocol ID 47.

L2TP over IPSec
To allow Internet Key Exchange (IKE), open UDP 500.
To allow IPSec Network Address Translation (NAT-T) open UDP 4500.
To allow L2TP traffic, open UDP 1701.

OpenVPN:

OpenVPN uses port 1194 udp and tcp:

Here’s the Cisco access list: (gre=Protocol ID 47, pptp=1723, isakmp=500, non500-isakmp=4500):

permit gre any any
permit tcp any any eq 1194
permit udp any any eq 1194
permit udp any any eq isakmp
permit udp any any eq non500-isakmp
permit udp any any eq 5500
permit tcp any any eq 1723
permit udp any any eq 1701

If natted address is being used by any of the peer then you need to open up the UDP port 4500 for ISAKMP.

If no natting is there then you need to open up the UDP port 500 for ISAKMP

For Phase 2: you need to explicitly open up the port for specific protocol like port 50 for AH and port 51 for ESP

IPSec can use ESP (protocol 50), or AH (protocol 51).   AH breaks if used with any type of NAT with IPv4, so it is rarely ever used in a transform set.

Common Cisco ACL for allowing VPN traffic:

remark Allow VPN Traffic
permit udp any host [IPSec Headend] eq 500
permit udp any host [IPSec Headend] eq 4500
permit 50 any host [IPSec Headend]
permit 51 any host [IPSec Headend]
permit 47 any host [IPSec Headend]
permit 57 any host [IPSec Headend]
deny   ip any host [IPSec Headend]

16 Feb

Optimising LEDE (OpenWrt) for the PC Engines APU2

I’m planning to get APU2 in near future, I found this article is useful for my future project and created a mirror here. Credit to original post.

The PC Engines APU2 is an embedded system based on AMD’s Jaguar family of processors. Many people prefer to run pfSenseon it, but since the rest of my hardware is alread on LEDE, it’s easier for me to stick with that; the APU2 will manage a network running other LEDE nodes, with customised images (see my article on UCI defaults for more information on that). To get an idea of all the tidbits the APU2 offers, the OpenWrt wiki page is a good starting point – since there are no subtargets anymore for x86/64 (alas), you have to install all extra packages manually to get full support for the hardware capabilities.

Default configuration

Because LEDE uses generic targets – a kind of catch-all – for the x86 and x86_64 platforms, by default it only configures eth0, the leftmost interface. It took me a while (coming from consumer platforms) to realise the images I built were fine, I just kept trying the two rightmost interfaces, figuring those were the LAN interfaces… So if you don’t seem to be getting an IP, try all of those ports. You never know. There’s also no WAN interface defined, so it won’t work as a router out of the box.

Hardware support

A stock LEDE image will boot just fine from internal mSATA/S-ATA storage or USB altogether. I have not been able to verify if booting off SD works yet.

Gigabit Ethernet

The APU2 comes with Intel’s i210AT or i211AT Gigabit Ethernet NICs, which need the igb driver on Linux. The stock x86_64 LEDE builds include this driver by default.

SDHC card reader

For the card reader, install the kmod-sdhci package. If you’d like to include it in your own build, enable it under Kernel modules > Other modules in the buildroot. To boot off an SD card, however, you need the following symbols to be enabled:

CONFIG_MMC_BLOCK=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PCI=y

You can grep target/linux/x86/64/config-default for them, they should all be enabled by default. Add them to the same file if they aren’t. I have been unable to test so far if booting off SD cards works; I’ve seen some statements that the APU2 will ignore SD or USB 3 boot devices if there is an mS-ATa SSD installed.

USB 3.0 support

Booting off USB 3.0 works just fine out of the box – not much to add.

Temperature sensor

For basic temperature reading support – which may come in handy as you essentially rely on passive cooling – install the kmod-hwmon-k10temp package, or enable kmod-hwmon-k10temp in the buildroot under Kernel modules > Hardware Monitoring Support. Reading out the temperature is as simple as typing sensors:

# sensors 
k10temp-pci-00c3
Adapter: PCI adapter
temp1:        +53.2°C  (high = +70.0°C)
               (crit = +105.0°C, hyst = +104.0°C)

As you can see, though, it only reports one temperature instead of one per core.

VLAN support

For VLAN support, you need the 8021q module installed. The generic target statically includes it. You will find a package under Kernel modules > Network Support; however, this is only useful for targets that do not include the module by default. On targets like e.g. ar71xx or x86, it will just generate a package only containing a modprobe file, nothing more. You can set up tagged VLANs through LEDE’s framework -in /etc/config/network, e.g.:

config interface 'guest'
    option type 'bridge'
    option proto 'static'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ifname 'eth1.20 eth2.20'
    option ipaddr '10.0.1.1'

This will set up a bridge named br-guest, containing both eth1 and eth2, tagged with VLAN ID 20. This is standard; the bridge itself apparently does not get tagged, only the member interfaces.

# for i in eth1.20 eth2.20 br-guest; do ip -d link show $i; done
9: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:b9:41:45:61 brd ff:ff:ff:ff:ff:ff promiscuity 1 
    vlan protocol 802.1Q id 20 <REORDER_HDR> 
    bridge_slave state forwarding priority 32 cost 4 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64 
10: eth2.20@eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-guest state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:b9:41:45:62 brd ff:ff:ff:ff:ff:ff promiscuity 1 
    vlan protocol 802.1Q id 20 <REORDER_HDR> 
    bridge_slave state forwarding priority 32 cost 4 hairpin off guard off root_block off fastleave off learning on flood on addrgenmode eui64 
8: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:0d:b9:41:45:61 brd ff:ff:ff:ff:ff:ff promiscuity 0 
    bridge forward_delay 200 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32767 vlan_filtering 0 addrgenmode eui64

I can confirm this works as expected – for more info on VLANs on OpenWrt/LEDE, see my older post.

LED support

By default only the leftmost LED is active, and it just stays on. As of commit fe12d51, LEDE has a driver for the APU2’s PCB LEDs and reset button. I have backported this to my LEDE 17.01 builds.

GPIO header

The GPIO headers are controlled by the Nuvoton NCT5104D chip. To use them, enable the kmod-gpio-nct5104d package under Kernel modules > Other modules.

AMD’s cryptographic coprocessor (‘CCP’)

Enable the kmod-crypto-hw-ccp package under Kernel modules > Cryptographic API modules.

Hardware watchdog

Enable the kmod-sp5100-tco package under Kernel modules > Other modules.

Optimising LEDE for the APU2

GCC optimisation

GCC has its own target for the Jaguar SoCs. You can optimise by using the -march=btver2 -mtune=btver2 GCC options, with a recent GCC version. In the buildroot, enable Advanced configuration options (for developers), then tick Target Options and add the compiler flags to Target Optimizations. Do keep in mind though this will greatly limit your testing capabilites – I haven’t found a way to emulate a CPU supporting the same feature set yet, if you do, let me know, that would greatly simplify testing. For now I build a separate generic x86_64 build so I can test it in a VM, before deploying it.

AES-NI

One of the cooler things with the APU2 is it supports AES-NI, which is handy for applications relying on encryption (e.g. a VPN). LEDE enabled the necessary bits and bolts for that in the meantime.

Resizing partitions

Chances are you’ll be running conventional storage, so the default 4/48 configuration for the kernel and root partitions do not really use the space available. You can change this by setting the CONFIG_TARGET_ROOTFS_PARTSIZE= (for the root file system) and CONFIG_TARGET_KERNEL_PARTSIZE= for the kernel partition size.

UCI defaults

I have preconfigured my LEDE builds for the APU2 to set up a WAN interface on eth0 and a LAN bridge on the eth1 and eth2interfaces, as well as some other tidbits. Imho, if you want to deploy the APU2 with LEDE, prepping the network is a must.

LEDE discussion forum link for APU2

13 Feb

Arista EOS 101

This is a simple short notes taken from Arista Configuration Essentials (ACE) Lab Guide

CLI & BASH

Enter bash
switch# bash
switch-bash$ ifconfig -a
switch-bash$ top
switch-bash$ cd /mnt/flash

Upgrade EOS

Upload EOS to switch
switch# copy http://1.1.1.1/EOS/EOS-4.15.5M.swi flash:

Verify image
switch# dir flash:

Configure boot image
switch# boot system flash: EOS-4.15.5M.swi

Verify boot-config
switch# show boot-config

MLAG

Configure port channel for your peerlink
switch# interface Ethernet47-48
switch# channel-group 1000 mode active
switch# interface port-channel 1000
switch# switchport mode trunk

Configure a VLAN and trunk group used for MLAG peer communications
switch# vlan 9094
switch# trunk group mlagpeer

Assign the port-channel to the trunk group
switch# interface po1000
switch# switchport trunk group mlagpeer

Disable STP on the VLAN used for the MLAG peer
switch# no spanning-tree vlan 4094

Configure SVI for peer-to-peer communications
switch# int vlan 4094
switch# ip address 10.100.100.9/30
switch# no autostate

Configure local interface and peer address
switch# mlag configuration
switch# local-interface vlan 4094
switch# peer-address 10.100.100.10

Configure domain-d, peer-link & reload-delay on BOTH switches
switch# domain-id mlagDomain
switch# peer-link port-channel 1000
switch# reload-delay 200

Configure the MLAG interface (upstream interface to spine)
switch# int Eth31-32
switch# channel-group 999 mode active
switch# int po999
switch# mlag 999

Optional (configure Virtual ARP for downstream device)
switch# ip virtual-router address 001c.7300.0009 (for both switches)
switch# int vlan 2 (for both switches)
switch# ip address 10.2.2.1/24
switch# ip virtual-router address 10.2.2.254 (for both switches)

Verify MLAG
switch# show mlag
switch# show mlag config-sanity
switch# show mlag detail
switch# show mlag interfaces
switch# show int po999

VXLAN

switch-XX# interface Vxlan 1
switch-XX# vxlan source-interface Loopback 1
switch-XX# vxlan vlan 101 flood vtep 10.1.2.1
switch-XX# vxlan udp-port 4789
switch-XX# vxlan vlan 101 vni 10000

switch-YY# interface Vxlan 1
switch-YY# vxlan source-interface Loopback 1
switch-YY# vxlan vlan 101 flood vtep 10.1.1.1
switch-YY# vxlan udp-port 4789
switch-YY# vxlan vlan 101 vni 10000

Verify vxlan
switch# sh vxlan vtep
switch# sh vxlan address-table

Use TCPDUMP

Configure port mirror to CPU (control plane)
switch# monitor session sniff source Eth33 both
switch# monitor session sniff destination Cpu

switch# bash
switch-bash$ tcpdump -i mirror1

*use the mirror number from “sh monitor session” output (Cpu : active (mirror1)

BGP Path Selection