├── bgp-intro ├── lxc │ ├── H19 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── H34 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── H6 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── H7 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── R0 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── R1 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── R11 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── R12 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── R10 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ ├── R3 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── bird │ │ │ ├── bird.conf │ │ │ └── bird6.conf │ │ │ └── network │ │ │ └── interfaces │ └── fixnetwork.sh ├── bgp-hey2.dia ├── bgp-hey2.png ├── bgp-ospf.dia ├── bgp-ospf.png ├── bgp-heythere.dia ├── bgp-heythere.png ├── bgp-ospf-zoom.dia ├── bgp-ospf-zoom.png ├── bird-prototable.dia ├── bird-prototable.png ├── ibgp-loopback.dia ├── ibgp-loopback.png ├── ospf-ebgp-ibgp.dia ├── ospf-ebgp-ibgp.png └── README.md ├── ospf-intro ├── ospf-r6.dia ├── ospf-r6.png ├── ospf-separate.dia ├── ospf-separate.png ├── ospf-together.dia ├── ospf-together.png ├── ospf-neighbours.dia ├── ospf-neighbours.png ├── ospf-together-hosts.dia ├── ospf-together-hosts.png ├── ospf-together-hosts-linkdown.dia ├── ospf-together-hosts-linkdown.png ├── lxc │ ├── R1 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ └── bird │ │ │ └── bird.conf │ ├── R2 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ └── bird │ │ │ └── bird.conf │ ├── R5 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ └── bird │ │ │ └── bird.conf │ ├── R6 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ └── bird │ │ │ └── bird.conf │ └── fixnetwork.sh └── README.md ├── bgp-contd ├── bgp-redundancy.dia ├── bgp-redundancy.png ├── bird-prototable.dia ├── bird-prototable.png ├── bird-prototable_branch.dia ├── bgp-redundancy-ibgp-r0-r1.dia ├── bgp-redundancy-ibgp-r0-r1.png ├── bgp-redundancy-transit1.dia ├── bgp-redundancy-transit1.png ├── bgp-redundancy-transit2.dia ├── bgp-redundancy-transit2.png ├── lxc │ ├── check_connectivity.sh │ ├── R2 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ ├── R12 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ ├── R0 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ ├── R10 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ ├── R20 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ ├── R1 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ ├── R11 │ │ └── rootfs │ │ │ └── etc │ │ │ ├── network │ │ │ └── interfaces │ │ │ ├── hosts │ │ │ └── bird │ │ │ └── bird6.conf │ └── fixnetwork.sh └── README.md ├── birdhouse-intro ├── birdhouse-intro.dia ├── birdhouse-intro.png └── README.md ├── lxcbird ├── lxc-openvswitch-topology.dia ├── lxc-openvswitch-topology.png └── README.md ├── birdhouse-vlans-vpn ├── birdhouse-vlans-vpn.dia ├── birdhouse-vlans-vpn.png ├── birdhouse-vlans-vpn-split.dia ├── birdhouse-vlans-vpn-split.png ├── birdhouse-vlans-vpn-split-routing-vlan.dia ├── birdhouse-vlans-vpn-split-routing-vlan.png └── README.md ├── COPYING ├── README.md └── LICENSE-fdl-1.3 /bgp-intro/lxc/H19/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H34/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H6/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H6/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H7/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H7/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H19/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H34/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /bgp-intro/bgp-hey2.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-hey2.dia -------------------------------------------------------------------------------- /bgp-intro/bgp-hey2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-hey2.png -------------------------------------------------------------------------------- /bgp-intro/bgp-ospf.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-ospf.dia -------------------------------------------------------------------------------- /bgp-intro/bgp-ospf.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-ospf.png -------------------------------------------------------------------------------- /ospf-intro/ospf-r6.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-r6.dia -------------------------------------------------------------------------------- /ospf-intro/ospf-r6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-r6.png -------------------------------------------------------------------------------- /bgp-intro/bgp-heythere.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-heythere.dia -------------------------------------------------------------------------------- /bgp-intro/bgp-heythere.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-heythere.png -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy.dia -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy.png -------------------------------------------------------------------------------- /bgp-contd/bird-prototable.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bird-prototable.dia -------------------------------------------------------------------------------- /bgp-contd/bird-prototable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bird-prototable.png -------------------------------------------------------------------------------- /bgp-intro/bgp-ospf-zoom.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-ospf-zoom.dia -------------------------------------------------------------------------------- /bgp-intro/bgp-ospf-zoom.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bgp-ospf-zoom.png -------------------------------------------------------------------------------- /bgp-intro/bird-prototable.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bird-prototable.dia -------------------------------------------------------------------------------- /bgp-intro/bird-prototable.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/bird-prototable.png -------------------------------------------------------------------------------- /bgp-intro/ibgp-loopback.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/ibgp-loopback.dia -------------------------------------------------------------------------------- /bgp-intro/ibgp-loopback.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/ibgp-loopback.png -------------------------------------------------------------------------------- /bgp-intro/ospf-ebgp-ibgp.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/ospf-ebgp-ibgp.dia -------------------------------------------------------------------------------- /bgp-intro/ospf-ebgp-ibgp.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-intro/ospf-ebgp-ibgp.png -------------------------------------------------------------------------------- /ospf-intro/ospf-separate.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-separate.dia -------------------------------------------------------------------------------- /ospf-intro/ospf-separate.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-separate.png -------------------------------------------------------------------------------- /ospf-intro/ospf-together.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-together.dia -------------------------------------------------------------------------------- /ospf-intro/ospf-together.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-together.png -------------------------------------------------------------------------------- /ospf-intro/ospf-neighbours.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-neighbours.dia -------------------------------------------------------------------------------- /ospf-intro/ospf-neighbours.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-neighbours.png -------------------------------------------------------------------------------- /ospf-intro/ospf-together-hosts.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-together-hosts.dia -------------------------------------------------------------------------------- /ospf-intro/ospf-together-hosts.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-together-hosts.png -------------------------------------------------------------------------------- /bgp-contd/bird-prototable_branch.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bird-prototable_branch.dia -------------------------------------------------------------------------------- /birdhouse-intro/birdhouse-intro.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-intro/birdhouse-intro.dia -------------------------------------------------------------------------------- /birdhouse-intro/birdhouse-intro.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-intro/birdhouse-intro.png -------------------------------------------------------------------------------- /lxcbird/lxc-openvswitch-topology.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/lxcbird/lxc-openvswitch-topology.dia -------------------------------------------------------------------------------- /lxcbird/lxc-openvswitch-topology.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/lxcbird/lxc-openvswitch-topology.png -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy-ibgp-r0-r1.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy-ibgp-r0-r1.dia -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy-ibgp-r0-r1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy-ibgp-r0-r1.png -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy-transit1.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy-transit1.dia -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy-transit1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy-transit1.png -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy-transit2.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy-transit2.dia -------------------------------------------------------------------------------- /bgp-contd/bgp-redundancy-transit2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/bgp-contd/bgp-redundancy-transit2.png -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/birdhouse-vlans-vpn.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-vlans-vpn/birdhouse-vlans-vpn.dia -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/birdhouse-vlans-vpn.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-vlans-vpn/birdhouse-vlans-vpn.png -------------------------------------------------------------------------------- /ospf-intro/ospf-together-hosts-linkdown.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-together-hosts-linkdown.dia -------------------------------------------------------------------------------- /ospf-intro/ospf-together-hosts-linkdown.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/ospf-intro/ospf-together-hosts-linkdown.png -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/birdhouse-vlans-vpn-split.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-vlans-vpn/birdhouse-vlans-vpn-split.dia -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/birdhouse-vlans-vpn-split.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-vlans-vpn/birdhouse-vlans-vpn-split.png -------------------------------------------------------------------------------- /ospf-intro/lxc/R1/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.9.99.1/32 dev lo 4 | down ip addr del 10.9.99.1/32 dev lo 5 | -------------------------------------------------------------------------------- /ospf-intro/lxc/R2/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.9.99.2/32 dev lo 4 | down ip addr del 10.9.99.2/32 dev lo 5 | -------------------------------------------------------------------------------- /ospf-intro/lxc/R5/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.9.99.5/32 dev lo 4 | down ip addr del 10.9.99.5/32 dev lo 5 | -------------------------------------------------------------------------------- /ospf-intro/lxc/R6/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.9.99.6/32 dev lo 4 | down ip addr del 10.9.99.6/32 dev lo 5 | -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/birdhouse-vlans-vpn-split-routing-vlan.dia: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-vlans-vpn/birdhouse-vlans-vpn-split-routing-vlan.dia -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/birdhouse-vlans-vpn-split-routing-vlan.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knorrie/network-examples/HEAD/birdhouse-vlans-vpn/birdhouse-vlans-vpn-split-routing-vlan.png -------------------------------------------------------------------------------- /ospf-intro/lxc/R1/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.9.99.1; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | -------------------------------------------------------------------------------- /ospf-intro/lxc/R2/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.9.99.2; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | -------------------------------------------------------------------------------- /ospf-intro/lxc/R5/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.9.99.5; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | -------------------------------------------------------------------------------- /ospf-intro/lxc/R6/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.9.99.6; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | -------------------------------------------------------------------------------- /bgp-contd/lxc/check_connectivity.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | routers='0 1 2 10 11 12 20' 4 | for src in $routers 5 | do 6 | for dst in $routers 7 | do 8 | lxc-attach -n R$src -- ping6 -c 1 r$dst >/dev/null 2>&1 9 | if [ $? -ne 0 ] 10 | then 11 | echo "[FAIL] R$src -> R$dst" 12 | else 13 | echo "[OK] R$src -> R$dst" 14 | fi 15 | done 16 | done 17 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R2/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8::2/128 dev lo 4 | down ip addr del 2001:db8::2/128 dev lo 5 | 6 | auto lan 7 | iface lan inet manual 8 | up ip link set up dev lan 9 | up ip addr add 2001:db8:0:1::2/120 dev lan 10 | down ip addr del 2001:db8:0:1::2/120 dev lan 11 | down ip link set down dev lan 12 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R12/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8:10::12/128 dev lo 4 | down ip addr del 2001:db8:10::12/128 dev lo 5 | 6 | auto lan 7 | iface lan inet manual 8 | up ip link set up dev lan 9 | up ip addr add 2001:db8:10:2::12/120 dev lan 10 | down ip addr del 2001:db8:10:2::12/120 dev lan 11 | down ip link set down dev lan 12 | -------------------------------------------------------------------------------- /COPYING: -------------------------------------------------------------------------------- 1 | Copyright (C) 2016 Hans van Kranenburg 2 | 3 | Permission is granted to copy, distribute and/or modify the text and images in 4 | these networking tutorials under the terms of the GNU Free Documentation 5 | License, Version 1.3 or any later version published by the Free Software 6 | Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 7 | Texts. 8 | 9 | A copy of the license is included in the LICENSE-fdl-1.3 file. 10 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R0/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.217.0; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | interface "lo" { 18 | stub; 19 | }; 20 | interface "vlan216" { 21 | }; 22 | interface "vlan2" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R1/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.217.1; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | interface "lo" { 18 | stub; 19 | }; 20 | interface "vlan216" { 21 | }; 22 | interface "vlan3" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R11/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.32.11; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | interface "lo" { 18 | stub; 19 | }; 20 | interface "vlan33" { 21 | }; 22 | interface "vlan48" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R12/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.32.12; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | interface "lo" { 18 | stub; 19 | }; 20 | interface "vlan33" { 21 | }; 22 | interface "vlan36" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R10/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.32.10; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | interface "lo" { 18 | stub; 19 | }; 20 | interface "vlan33" { 21 | }; 22 | interface "vlan217" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R3/rootfs/etc/bird/bird.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.217.3; 2 | 3 | log "/var/log/bird/bird.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | interface "lo" { 18 | stub; 19 | }; 20 | interface "vlan216" { 21 | }; 22 | interface "vlan217" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H6/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | 4 | auto vlan2 5 | iface vlan2 inet manual 6 | up ip link set up dev vlan2 7 | up ip addr add 10.40.2.6/24 brd + dev vlan2 8 | up ip addr add 2001:db8:40:2::6/120 dev vlan2 9 | up ip route add default via 10.40.2.1 dev vlan2 10 | up ip route add default via 2001:db8:40:2::1 dev vlan2 11 | down ip route -6 del default 12 | down ip addr del 2001:db8:40:2::6/120 dev vlan2 13 | down ip addr del 10.40.2.6/24 dev vlan2 14 | down up link set down dev vlan2 15 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H7/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | 4 | auto vlan3 5 | iface vlan3 inet manual 6 | up ip link set up dev vlan3 7 | up ip addr add 10.40.3.7/24 brd + dev vlan3 8 | up ip addr add 2001:db8:40:3::7/120 dev vlan3 9 | up ip route add default via 10.40.3.1 dev vlan3 10 | up ip route add default via 2001:db8:40:3::1 dev vlan3 11 | down ip route -6 del default 12 | down ip addr del 2001:db8:40:3::7/120 dev vlan3 13 | down ip addr del 10.40.3.7/24 dev vlan3 14 | down up link set down dev vlan3 15 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R0/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.217.0; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:40::/128; 19 | interface "vlan216" { 20 | }; 21 | interface "vlan2" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R1/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.217.1; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:40::1/128; 19 | interface "vlan216" { 20 | }; 21 | interface "vlan3" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R10/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.32.10; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:10:6::a/128; 19 | interface "vlan33" { 20 | }; 21 | interface "vlan217" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R11/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.32.11; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:10:6::b/128; 19 | interface "vlan33" { 20 | }; 21 | interface "vlan48" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R12/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.32.12; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:10:6::c/128; 19 | interface "vlan33" { 20 | }; 21 | interface "vlan36" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R3/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.40.217.3; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:40::3/128; 19 | interface "vlan216" { 20 | }; 21 | interface "vlan217" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H19/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | 4 | auto vlan48 5 | iface vlan48 inet manual 6 | up ip link set up dev vlan48 7 | up ip addr add 10.40.52.19/21 brd + dev vlan48 8 | up ip addr add 2001:db8:10:30::413/117 dev vlan48 9 | up ip route add default via 10.40.48.1 dev vlan48 10 | up ip route add default via 2001:db8:10:30::1 dev vlan48 11 | down ip route -6 del default 12 | down ip addr del 2001:db8:10:30::413/117 dev vlan48 13 | down ip addr del 10.40.52.19/21 dev vlan48 14 | down up link set down dev vlan48 15 | -------------------------------------------------------------------------------- /bgp-intro/lxc/H34/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | 4 | auto vlan36 5 | iface vlan36 inet manual 6 | up ip link set up dev vlan36 7 | up ip addr add 10.40.36.34/24 brd + dev vlan36 8 | up ip addr add 2001:db8:10:24::22/120 dev vlan36 9 | up ip route add default via 10.40.36.1 dev vlan36 10 | up ip route add default via 2001:db8:10:24::1 dev vlan36 11 | down ip route -6 del default 12 | down ip addr del 2001:db8:10:24::22/120 dev vlan36 13 | down ip addr del 10.40.36.34/24 dev vlan36 14 | down up link set down dev vlan36 15 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R0/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8::ff/128 dev lo 4 | down ip addr del 2001:db8::ff/128 dev lo 5 | 6 | auto lan 7 | iface lan inet manual 8 | up ip link set up dev lan 9 | up ip addr add 2001:db8:0:1::ff/120 dev lan 10 | down ip addr del 2001:db8:0:1::ff/120 dev lan 11 | down ip link set down dev lan 12 | 13 | auto ebgp_r11 14 | iface ebgp_r11 inet manual 15 | up ip link set up dev ebgp_r11 16 | up ip addr add 2001:db8:0:3::ff/120 dev ebgp_r11 17 | down ip addr del 2001:db8:0:3::ff/120 dev ebgp_r11 18 | down ip link set down dev ebgp_r11 19 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R10/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8:10::10/128 dev lo 4 | down ip addr del 2001:db8:10::10/128 dev lo 5 | 6 | auto lan 7 | iface lan inet manual 8 | up ip link set up dev lan 9 | up ip addr add 2001:db8:10:2::10/120 dev lan 10 | down ip addr del 2001:db8:10:2::10/120 dev lan 11 | down ip link set down dev lan 12 | 13 | auto ebgp_r1 14 | iface ebgp_r1 inet manual 15 | up ip link set up dev ebgp_r1 16 | up ip addr add 2001:db8:10:4::10/120 dev ebgp_r1 17 | down ip addr del 2001:db8:10:4::10/120 dev ebgp_r1 18 | down ip link set down dev ebgp_r1 19 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R20/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8:20::20/128 dev lo 4 | down ip addr del 2001:db8:20::20/128 dev lo 5 | 6 | auto ebgp_r1 7 | iface ebgp_r1 inet manual 8 | up ip link set up dev ebgp_r1 9 | up ip addr add 2001:db8:0:5::20/120 dev ebgp_r1 10 | down ip addr del 2001:db8:0:5::20/120 dev ebgp_r1 11 | down ip link set down dev ebgp_r1 12 | 13 | auto ebgp_r11 14 | iface ebgp_r11 inet manual 15 | up ip link set up dev ebgp_r11 16 | up ip addr add 2001:db8:10:6::20/120 dev ebgp_r11 17 | down ip addr del 2001:db8:10:6::20/120 dev ebgp_r11 18 | down ip link set down dev ebgp_r11 19 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R1/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8::1/128 dev lo 4 | down ip addr del 2001:db8::1/128 dev lo 5 | 6 | auto lan 7 | iface lan inet manual 8 | up ip link set up dev lan 9 | up ip addr add 2001:db8:0:1::1/120 dev lan 10 | down ip addr del 2001:db8:0:1::1/120 dev lan 11 | down ip link set down dev lan 12 | 13 | auto ebgp_r10 14 | iface ebgp_r10 inet manual 15 | up ip link set up dev ebgp_r10 16 | up ip addr add 2001:db8:10:4::1/120 dev ebgp_r10 17 | down ip addr del 2001:db8:10:4::1/120 dev ebgp_r10 18 | down ip link set down dev ebgp_r10 19 | 20 | auto ebgp_r20 21 | iface ebgp_r20 inet manual 22 | up ip link set up dev ebgp_r20 23 | up ip addr add 2001:db8:0:5::1/120 dev ebgp_r20 24 | down ip addr del 2001:db8:0:5::1/120 dev ebgp_r20 25 | down ip link set down dev ebgp_r20 26 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R11/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 2001:db8:10::11/128 dev lo 4 | down ip addr del 2001:db8:10::11/128 dev lo 5 | 6 | auto lan 7 | iface lan inet manual 8 | up ip link set up dev lan 9 | up ip addr add 2001:db8:10:2::11/120 dev lan 10 | down ip addr del 2001:db8:10:2::11/120 dev lan 11 | down ip link set down dev lan 12 | 13 | auto ebgp_r0 14 | iface ebgp_r0 inet manual 15 | up ip link set up dev ebgp_r0 16 | up ip addr add 2001:db8:0:3::11/120 dev ebgp_r0 17 | down ip addr del 2001:db8:0:3::11/120 dev ebgp_r0 18 | down ip link set down dev ebgp_r0 19 | 20 | auto ebgp_r20 21 | iface ebgp_r20 inet manual 22 | up ip link set up dev ebgp_r20 23 | up ip addr add 2001:db8:10:6::11/120 dev ebgp_r20 24 | down ip addr del 2001:db8:10:6::11/120 dev ebgp_r20 25 | down ip link set down dev ebgp_r20 26 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R0/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R1/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R10/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R11/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R12/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R2/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R20/rootfs/etc/hosts: -------------------------------------------------------------------------------- 1 | 127.0.0.1 localhost 2 | ::1 localhost ip6-localhost ip6-loopback 3 | ff02::1 ip6-allnodes 4 | ff02::2 ip6-allrouters 5 | 6 | 2001:db8::ff lo.r0 r0 7 | 2001:db8:0:1::ff lan.r0 8 | 2001:db8:0:3::ff ebgp_r11.r0 9 | 10 | 2001:db8:10::10 lo.r10 r10 11 | 2001:db8:10:2::10 lan.r10 12 | 2001:db8:10:4::10 ebgp_r1.r10 13 | 14 | 2001:db8:10::11 lo.r11 r11 15 | 2001:db8:10:2::11 lan.r11 16 | 2001:db8:0:3::11 ebgp_r0.r11 17 | 2001:db8:10:6::11 ebgp_r20.r11 18 | 19 | 2001:db8:10::12 lo.r12 r12 20 | 2001:db8:10:2::12 lan.r12 21 | 22 | 2001:db8::1 lo.r1 r1 23 | 2001:db8:0:1::1 lan.r1 24 | 2001:db8:10:4::1 ebgp_r10.r1 25 | 2001:db8:0:5::1 ebgp_r20.r1 26 | 27 | 2001:db8:20::20 lo.r20 r20 28 | 2001:db8:0:5::20 ebgp_r1.r20 29 | 2001:db8:10:6::20 ebgp_r11.r20 30 | 31 | 2001:db8::2 lo.r2 r2 32 | 2001:db8:0:1::2 lan.r2 33 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R0/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.40.217.0/32 dev lo 4 | up ip addr add 2001:db8:40:: dev lo 5 | down ip addr del 2001:db8:40:: dev lo 6 | down ip addr del 10.40.217.0/32 dev lo 7 | 8 | auto vlan2 9 | iface vlan2 inet manual 10 | up ip link set up dev vlan2 11 | up ip addr add 10.40.2.1/24 brd + dev vlan2 12 | up ip addr add 2001:db8:40:2::1/120 dev vlan2 13 | down ip addr del 2001:db8:40:2::1/120 dev vlan2 14 | down ip addr del 10.40.2.1/24 dev vlan2 15 | down up link set down dev vlan2 16 | 17 | auto vlan216 18 | iface vlan216 inet manual 19 | up ip link set up dev vlan216 20 | up ip addr add 10.40.216.2/28 brd + dev vlan216 21 | up ip addr add 2001:db8:40:d8::2/120 dev vlan216 22 | down ip addr del 2001:db8:40:d8::2/120 dev vlan216 23 | down ip addr del 10.40.216.2/28 dev vlan216 24 | down up link set down dev vlan216 25 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R1/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.40.217.1/32 dev lo 4 | up ip addr add 2001:db8:40::1 dev lo 5 | down ip addr del 2001:db8:40::1 dev lo 6 | down ip addr del 10.40.217.1/32 dev lo 7 | 8 | auto vlan3 9 | iface vlan3 inet manual 10 | up ip link set up dev vlan3 11 | up ip addr add 10.40.3.1/24 brd + dev vlan3 12 | up ip addr add 2001:db8:40:3::1/120 dev vlan3 13 | down ip addr del 2001:db8:40:3::1/120 dev vlan3 14 | down ip addr del 10.40.3.1/24 dev vlan3 15 | down up link set down dev vlan3 16 | 17 | auto vlan216 18 | iface vlan216 inet manual 19 | up ip link set up dev vlan216 20 | up ip addr add 10.40.216.3/28 brd + dev vlan216 21 | up ip addr add 2001:db8:40:d8::3/120 dev vlan216 22 | down ip addr del 2001:db8:40:d8::3/120 dev vlan216 23 | down ip addr del 10.40.216.3/28 dev vlan216 24 | down up link set down dev vlan216 25 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R11/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.40.32.11/32 dev lo 4 | up ip addr add 2001:db8:10:6::b dev lo 5 | down ip addr del 2001:db8:10:6::b dev lo 6 | down ip addr del 10.40.32.11/32 dev lo 7 | 8 | auto vlan48 9 | iface vlan48 inet manual 10 | up ip link set up dev vlan48 11 | up ip addr add 10.40.48.1/21 brd + dev vlan48 12 | up ip addr add 2001:db8:10:30::1/117 dev vlan48 13 | down ip addr del 2001:db8:10:30::1/117 dev vlan48 14 | down ip addr del 10.40.48.1/21 dev vlan48 15 | down up link set down dev vlan48 16 | 17 | auto vlan33 18 | iface vlan33 inet manual 19 | up ip link set up dev vlan33 20 | up ip addr add 10.40.33.2/26 brd + dev vlan33 21 | up ip addr add 2001:db8:10:21::2/120 dev vlan33 22 | down ip addr del 2001:db8:10:21::2/120 dev vlan33 23 | down ip addr del 10.40.33.2/26 dev vlan33 24 | down up link set down dev vlan33 25 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R12/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.40.32.12/32 dev lo 4 | up ip addr add 2001:db8:10:6::c dev lo 5 | down ip addr del 2001:db8:10:6::c dev lo 6 | down ip addr del 10.40.32.12/32 dev lo 7 | 8 | auto vlan36 9 | iface vlan36 inet manual 10 | up ip link set up dev vlan36 11 | up ip addr add 10.40.36.1/24 brd + dev vlan36 12 | up ip addr add 2001:db8:10:24::1/120 dev vlan36 13 | down ip addr del 2001:db8:10:24::1/120 dev vlan36 14 | down ip addr del 10.40.36.1/24 dev vlan36 15 | down up link set down dev vlan36 16 | 17 | auto vlan33 18 | iface vlan33 inet manual 19 | up ip link set up dev vlan33 20 | up ip addr add 10.40.33.3/26 brd + dev vlan33 21 | up ip addr add 2001:db8:10:21::3/120 dev vlan33 22 | down ip addr del 2001:db8:10:21::3/120 dev vlan33 23 | down ip addr del 10.40.33.3/26 dev vlan33 24 | down up link set down dev vlan33 25 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R10/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.40.32.10/32 dev lo 4 | up ip addr add 2001:db8:10:6::a dev lo 5 | down ip addr del 2001:db8:10:6::a dev lo 6 | down ip addr del 10.40.32.10/32 dev lo 7 | 8 | auto vlan33 9 | iface vlan33 inet manual 10 | up ip link set up dev vlan33 11 | up ip addr add 10.40.33.1/26 brd + dev vlan33 12 | up ip addr add 2001:db8:10:21::1/120 dev vlan33 13 | down ip addr del 2001:db8:10:21::1/120 dev vlan33 14 | down ip addr del 10.40.33.1/26 dev vlan33 15 | down up link set down dev vlan33 16 | 17 | auto vlan217 18 | iface vlan217 inet manual 19 | up ip link set up dev vlan217 20 | up ip addr add 10.40.217.18/30 brd + dev vlan217 21 | up ip addr add 2001:db8:40:d910::2/120 dev vlan217 22 | down ip addr del 2001:db8:40:d910::2/120 dev vlan217 23 | down ip addr del 10.40.217.18/30 dev vlan217 24 | down up link set down dev vlan217 25 | -------------------------------------------------------------------------------- /bgp-intro/lxc/R3/rootfs/etc/network/interfaces: -------------------------------------------------------------------------------- 1 | auto lo 2 | iface lo inet loopback 3 | up ip addr add 10.40.217.3/32 dev lo 4 | up ip addr add 2001:db8:40::3 dev lo 5 | down ip addr del 2001:db8:40::3 dev lo 6 | down ip addr del 10.40.217.3/32 dev lo 7 | 8 | auto vlan216 9 | iface vlan216 inet manual 10 | up ip link set up dev vlan216 11 | up ip addr add 10.40.216.1/28 brd + dev vlan216 12 | up ip addr add 2001:db8:40:d8::1/120 dev vlan216 13 | down ip addr del 2001:db8:40:d8::1/120 dev vlan216 14 | down ip addr del 10.40.216.1/28 dev vlan216 15 | down up link set down dev vlan216 16 | 17 | auto vlan217 18 | iface vlan217 inet manual 19 | up ip link set up dev vlan217 20 | up ip addr add 10.40.217.17/30 brd + dev vlan217 21 | up ip addr add 2001:db8:40:d910::1/120 dev vlan217 22 | down ip addr del 2001:db8:40:d910::1/120 dev vlan217 23 | down ip addr del 10.40.217.17/30 dev vlan217 24 | down up link set down dev vlan217 25 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R2/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.2; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8::2/128; 19 | interface "lan" { 20 | }; 21 | }; 22 | } 23 | 24 | protocol static { 25 | import all; 26 | route 2001:db8::/48 blackhole; 27 | } 28 | 29 | ############################################################################## 30 | # iBGP 31 | # 32 | 33 | protocol bgp ibgp_r0 { 34 | import all; 35 | export none; 36 | local 2001:db8::2 as 65000; 37 | neighbor 2001:db8::ff as 65000; 38 | } 39 | 40 | protocol bgp ibgp_r1 { 41 | import all; 42 | export none; 43 | local 2001:db8::2 as 65000; 44 | neighbor 2001:db8::1 as 65000; 45 | } 46 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R12/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.12; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:10::12/128; 19 | interface "lan" { 20 | }; 21 | }; 22 | } 23 | 24 | protocol static { 25 | import all; 26 | route 2001:db8:10::/48 blackhole; 27 | } 28 | 29 | ############################################################################## 30 | # iBGP 31 | # 32 | 33 | protocol bgp ibgp_r10 { 34 | import all; 35 | export none; 36 | local 2001:db8:10::12 as 65010; 37 | neighbor 2001:db8:10::10 as 65010; 38 | } 39 | 40 | protocol bgp ibgp_r11 { 41 | import all; 42 | export none; 43 | local 2001:db8:10::12 as 65010; 44 | neighbor 2001:db8:10::11 as 65010; 45 | } 46 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R0/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.0; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8::ff/128; 19 | interface "lan" { 20 | }; 21 | interface "ebgp_r11" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | 27 | protocol static { 28 | import all; 29 | route 2001:db8::/48 blackhole; 30 | } 31 | 32 | ############################################################################## 33 | # BGP table 34 | # 35 | 36 | # Use this routing table to gather external routes received via BGP which we 37 | # want push to the kernel via our master table and to other routers in our AS 38 | # via iBGP or even to other routers outside our AS again (transit), which can 39 | # be connected here or to a router elsewhere on the border of our AS. 40 | 41 | table t_bgp; 42 | 43 | protocol pipe p_master_to_bgp { 44 | table master; 45 | peer table t_bgp; 46 | import all; # default 47 | export none; # default 48 | } 49 | 50 | ############################################################################## 51 | # eBGP R11 52 | # 53 | 54 | table t_r11; 55 | 56 | protocol static originate_to_r11 { 57 | table t_r11; 58 | import all; # originate here 59 | route 2001:db8::/48 blackhole; 60 | } 61 | 62 | protocol bgp ebgp_r11 { 63 | table t_r11; 64 | local 2001:db8:0:3::ff as 65000; 65 | neighbor 2001:db8:0:3::11 as 65010; 66 | import all; 67 | export all; 68 | } 69 | 70 | protocol pipe p_bgp_to_r11 { 71 | table t_bgp; 72 | peer table t_r11; 73 | import where proto = "ebgp_r11"; 74 | export none; 75 | } 76 | 77 | ############################################################################## 78 | # iBGP 79 | # 80 | 81 | protocol bgp ibgp_r2 { 82 | table t_bgp; 83 | igp table master; 84 | import none; 85 | export all; 86 | local 2001:db8::ff as 65000; 87 | neighbor 2001:db8::2 as 65000; 88 | } 89 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R10/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.10; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:10::10/128; 19 | interface "lan" { 20 | }; 21 | interface "ebgp_r1" { 22 | stub; 23 | }; 24 | }; 25 | } 26 | 27 | protocol static { 28 | import all; 29 | route 2001:db8:10::/48 blackhole; 30 | } 31 | 32 | ############################################################################## 33 | # BGP table 34 | # 35 | 36 | # Use this routing table to gather external routes received via BGP which we 37 | # want push to the kernel via our master table and to other routers in our AS 38 | # via iBGP or even to other routers outside our AS again (transit), which can 39 | # be connected here or to a router elsewhere on the border of our AS. 40 | 41 | table t_bgp; 42 | 43 | protocol pipe p_master_to_bgp { 44 | table master; 45 | peer table t_bgp; 46 | import all; # default 47 | export none; # default 48 | } 49 | 50 | ############################################################################## 51 | # eBGP R1 52 | # 53 | 54 | table t_r1; 55 | 56 | protocol static originate_to_r1 { 57 | table t_r1; 58 | import all; # originate here 59 | route 2001:db8:10::/48 blackhole; 60 | } 61 | 62 | protocol bgp ebgp_r1 { 63 | table t_r1; 64 | local 2001:db8:10:4::10 as 65010; 65 | neighbor 2001:db8:10:4::1 as 65000; 66 | import all; 67 | export all; 68 | } 69 | 70 | protocol pipe p_bgp_to_r1 { 71 | table t_bgp; 72 | peer table t_r1; 73 | import where proto = "ebgp_r1"; 74 | export none; 75 | } 76 | 77 | ############################################################################## 78 | # iBGP 79 | # 80 | 81 | protocol bgp ibgp_r12 { 82 | table t_bgp; 83 | igp table master; 84 | import none; 85 | export all; 86 | local 2001:db8:10::10 as 65010; 87 | neighbor 2001:db8:10::12 as 65010; 88 | } 89 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R20/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.20; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:20::20/128; 19 | interface "ebgp_r1" { 20 | stub; 21 | }; 22 | interface "ebgp_r11" { 23 | stub; 24 | }; 25 | }; 26 | } 27 | 28 | protocol static { 29 | import all; 30 | route 2001:db8:20::/48 blackhole; 31 | } 32 | 33 | ############################################################################## 34 | # BGP table 35 | # 36 | 37 | # Use this routing table to gather external routes received via BGP which we 38 | # want push to the kernel via our master table and to other routers in our AS 39 | # via iBGP or even to other routers outside our AS again (transit), which can 40 | # be connected here or to a router elsewhere on the border of our AS. 41 | 42 | table t_bgp; 43 | 44 | protocol pipe p_master_to_bgp { 45 | table master; 46 | peer table t_bgp; 47 | import all; # default 48 | export none; # default 49 | } 50 | 51 | ############################################################################## 52 | # eBGP R1 53 | # 54 | 55 | table t_r1; 56 | 57 | protocol static originate_to_r1 { 58 | table t_r1; 59 | import all; # originate here 60 | route 2001:db8:20::/48 blackhole; 61 | } 62 | 63 | protocol bgp ebgp_r1 { 64 | table t_r1; 65 | local 2001:db8:0:5::20 as 65020; 66 | neighbor 2001:db8:0:5::1 as 65000; 67 | import all; 68 | export all; 69 | } 70 | 71 | protocol pipe p_bgp_to_r1 { 72 | table t_bgp; 73 | peer table t_r1; 74 | import where proto = "ebgp_r1"; 75 | export none; 76 | } 77 | 78 | ############################################################################## 79 | # eBGP R11 80 | # 81 | 82 | table t_r11; 83 | 84 | protocol static originate_to_r11 { 85 | table t_r11; 86 | import all; # originate here 87 | route 2001:db8:20::/48 blackhole; 88 | } 89 | 90 | protocol bgp ebgp_r11 { 91 | table t_r11; 92 | local 2001:db8:10:6::20 as 65020; 93 | neighbor 2001:db8:10:6::11 as 65010; 94 | import all; 95 | export all; 96 | } 97 | 98 | protocol pipe p_bgp_to_r11 { 99 | table t_bgp; 100 | peer table t_r11; 101 | import where proto = "ebgp_r11"; 102 | export none; 103 | } 104 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R1/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.1; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8::1/128; 19 | interface "lan" { 20 | }; 21 | interface "ebgp_r10" { 22 | stub; 23 | }; 24 | interface "ebgp_r20" { 25 | stub; 26 | }; 27 | }; 28 | } 29 | 30 | protocol static { 31 | import all; 32 | route 2001:db8::/48 blackhole; 33 | } 34 | 35 | ############################################################################## 36 | # BGP table 37 | # 38 | 39 | # Use this routing table to gather external routes received via BGP which we 40 | # want push to the kernel via our master table and to other routers in our AS 41 | # via iBGP or even to other routers outside our AS again (transit), which can 42 | # be connected here or to a router elsewhere on the border of our AS. 43 | 44 | table t_bgp; 45 | 46 | protocol pipe p_master_to_bgp { 47 | table master; 48 | peer table t_bgp; 49 | import all; # default 50 | export none; # default 51 | } 52 | 53 | ############################################################################## 54 | # eBGP R10 55 | # 56 | 57 | table t_r10; 58 | 59 | protocol static originate_to_r10 { 60 | table t_r10; 61 | import all; # originate here 62 | route 2001:db8::/48 blackhole; 63 | } 64 | 65 | protocol bgp ebgp_r10 { 66 | table t_r10; 67 | local 2001:db8:10:4::1 as 65000; 68 | neighbor 2001:db8:10:4::10 as 65010; 69 | import all; 70 | export all; 71 | } 72 | 73 | protocol pipe p_bgp_to_r10 { 74 | table t_bgp; 75 | peer table t_r10; 76 | import where proto = "ebgp_r10"; 77 | export none; 78 | } 79 | 80 | ############################################################################## 81 | # eBGP R20 82 | # 83 | 84 | table t_r20; 85 | 86 | protocol static originate_to_r20 { 87 | table t_r20; 88 | import all; # originate here 89 | route 2001:db8::/48 blackhole; 90 | } 91 | 92 | protocol bgp ebgp_r20 { 93 | table t_r20; 94 | local 2001:db8:0:5::1 as 65000; 95 | neighbor 2001:db8:0:5::20 as 65020; 96 | import all; 97 | export all; 98 | } 99 | 100 | protocol pipe p_bgp_to_r20 { 101 | table t_bgp; 102 | peer table t_r20; 103 | import where proto = "ebgp_r20"; 104 | export none; 105 | } 106 | 107 | ############################################################################## 108 | # iBGP 109 | # 110 | 111 | protocol bgp ibgp_r2 { 112 | table t_bgp; 113 | igp table master; 114 | import none; 115 | export all; 116 | local 2001:db8::1 as 65000; 117 | neighbor 2001:db8::2 as 65000; 118 | } 119 | -------------------------------------------------------------------------------- /bgp-contd/lxc/R11/rootfs/etc/bird/bird6.conf: -------------------------------------------------------------------------------- 1 | router id 10.0.0.11; 2 | 3 | log "/var/log/bird/bird6.log" all; 4 | debug protocols { states, routes, filters, interfaces } 5 | 6 | protocol kernel { 7 | import none; 8 | export all; 9 | } 10 | 11 | protocol device { 12 | # defaults... 13 | } 14 | 15 | protocol ospf { 16 | area 0 { 17 | # BIRD ignores the IPv6 lo because it has no link local address 18 | stubnet 2001:db8:10::11/128; 19 | interface "lan" { 20 | }; 21 | interface "ebgp_r0" { 22 | stub; 23 | }; 24 | interface "ebgp_r20" { 25 | stub; 26 | }; 27 | }; 28 | } 29 | 30 | protocol static { 31 | import all; 32 | route 2001:db8:10::/48 blackhole; 33 | } 34 | 35 | ############################################################################## 36 | # BGP table 37 | # 38 | 39 | # Use this routing table to gather external routes received via BGP which we 40 | # want push to the kernel via our master table and to other routers in our AS 41 | # via iBGP or even to other routers outside our AS again (transit), which can 42 | # be connected here or to a router elsewhere on the border of our AS. 43 | 44 | table t_bgp; 45 | 46 | protocol pipe p_master_to_bgp { 47 | table master; 48 | peer table t_bgp; 49 | import all; # default 50 | export none; # default 51 | } 52 | 53 | ############################################################################## 54 | # eBGP R0 55 | # 56 | 57 | table t_r0; 58 | 59 | protocol static originate_to_r0 { 60 | table t_r0; 61 | import all; # originate here 62 | route 2001:db8:10::/48 blackhole; 63 | } 64 | 65 | protocol bgp ebgp_r0 { 66 | table t_r0; 67 | local 2001:db8:0:3::11 as 65010; 68 | neighbor 2001:db8:0:3::ff as 65000; 69 | import all; 70 | export all; 71 | } 72 | 73 | protocol pipe p_bgp_to_r0 { 74 | table t_bgp; 75 | peer table t_r0; 76 | import where proto = "ebgp_r0"; 77 | export none; 78 | } 79 | 80 | ############################################################################## 81 | # eBGP R20 82 | # 83 | 84 | table t_r20; 85 | 86 | protocol static originate_to_r20 { 87 | table t_r20; 88 | import all; # originate here 89 | route 2001:db8:10::/48 blackhole; 90 | } 91 | 92 | protocol bgp ebgp_r20 { 93 | table t_r20; 94 | local 2001:db8:10:6::11 as 65010; 95 | neighbor 2001:db8:10:6::20 as 65020; 96 | import all; 97 | export all; 98 | } 99 | 100 | protocol pipe p_bgp_to_r20 { 101 | table t_bgp; 102 | peer table t_r20; 103 | import where proto = "ebgp_r20"; 104 | export none; 105 | } 106 | 107 | ############################################################################## 108 | # iBGP 109 | # 110 | 111 | protocol bgp ibgp_r12 { 112 | table t_bgp; 113 | igp table master; 114 | import none; 115 | export all; 116 | local 2001:db8:10::11 as 65010; 117 | neighbor 2001:db8:10::12 as 65010; 118 | } 119 | -------------------------------------------------------------------------------- /bgp-contd/lxc/fixnetwork.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | sed -i '/lxc.network/d' R*/config 4 | 5 | cat <> R0/config 6 | 7 | lxc.net.0.type = veth 8 | lxc.net.0.flags = up 9 | lxc.net.0.name = lan 10 | lxc.net.0.veth.pair = r0.1 11 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 12 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 13 | 14 | lxc.net.1.type = veth 15 | lxc.net.1.flags = up 16 | lxc.net.1.name = ebgp_r11 17 | lxc.net.1.veth.pair = r0.3 18 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 19 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 20 | EOF 21 | 22 | cat <> R1/config 23 | 24 | lxc.net.0.type = veth 25 | lxc.net.0.flags = up 26 | lxc.net.0.name = lan 27 | lxc.net.0.veth.pair = r1.1 28 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 29 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 30 | 31 | lxc.net.1.type = veth 32 | lxc.net.1.flags = up 33 | lxc.net.1.name = ebgp_r10 34 | lxc.net.1.veth.pair = r1.4 35 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 36 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 37 | 38 | lxc.net.2.type = veth 39 | lxc.net.2.flags = up 40 | lxc.net.2.name = ebgp_r20 41 | lxc.net.2.veth.pair = r1.5 42 | lxc.net.2.script.up = /etc/lxc/lxc-openvswitch 43 | lxc.net.2.script.down = /etc/lxc/lxc-openvswitch 44 | EOF 45 | 46 | cat <> R2/config 47 | 48 | lxc.net.0.type = veth 49 | lxc.net.0.flags = up 50 | lxc.net.0.name = lan 51 | lxc.net.0.veth.pair = r2.1 52 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 53 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 54 | EOF 55 | 56 | cat <> R10/config 57 | 58 | lxc.net.0.type = veth 59 | lxc.net.0.flags = up 60 | lxc.net.0.name = lan 61 | lxc.net.0.veth.pair = r10.2 62 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 63 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 64 | 65 | lxc.net.1.type = veth 66 | lxc.net.1.flags = up 67 | lxc.net.1.name = ebgp_r1 68 | lxc.net.1.veth.pair = r10.4 69 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 70 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 71 | EOF 72 | 73 | cat <> R11/config 74 | 75 | lxc.net.0.type = veth 76 | lxc.net.0.flags = up 77 | lxc.net.0.name = lan 78 | lxc.net.0.veth.pair = r11.2 79 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 80 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 81 | 82 | lxc.net.1.type = veth 83 | lxc.net.1.flags = up 84 | lxc.net.1.name = ebgp_r0 85 | lxc.net.1.veth.pair = r11.3 86 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 87 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 88 | 89 | lxc.net.2.type = veth 90 | lxc.net.2.flags = up 91 | lxc.net.2.name = ebgp_r20 92 | lxc.net.2.veth.pair = r11.6 93 | lxc.net.2.script.up = /etc/lxc/lxc-openvswitch 94 | lxc.net.2.script.down = /etc/lxc/lxc-openvswitch 95 | EOF 96 | 97 | cat <> R12/config 98 | 99 | lxc.net.0.type = veth 100 | lxc.net.0.flags = up 101 | lxc.net.0.name = lan 102 | lxc.net.0.veth.pair = r12.2 103 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 104 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 105 | EOF 106 | 107 | cat <> R20/config 108 | 109 | lxc.net.0.type = veth 110 | lxc.net.0.flags = up 111 | lxc.net.0.name = ebgp_r1 112 | lxc.net.0.veth.pair = r20.5 113 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 114 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 115 | 116 | lxc.net.1.type = veth 117 | lxc.net.1.flags = up 118 | lxc.net.1.name = ebgp_r11 119 | lxc.net.1.veth.pair = r20.6 120 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 121 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 122 | EOF 123 | 124 | -------------------------------------------------------------------------------- /birdhouse-vlans-vpn/README.md: -------------------------------------------------------------------------------- 1 | # The Birdhouse Factory continued 2 | 3 | ## A larger network 4 | 5 | While we were [playing around with linux containers](/birdhouse-intro/README.md), Carl, the Birdhouse Factory sysadmin has been busy expanding the computer network at the Birdhouse Factory! 6 | 7 | ![Birdhouse network with vlans and vpn](/birdhouse-vlans-vpn/birdhouse-vlans-vpn.png) 8 | 9 | Instead of only having a simple NAT router with a single vlan for a server and a few workstations, the following new elements have been introduced: 10 | 11 | * Three different vlans have been created, to split networks for workstations of employees in the main office, internal servers and the warehouse, which has network-connected manufacturing equipment. 12 | * VPN server software has been installed to provide employees with the ability to work outside the office. Carl has configured the VPN to push a route to clients that contains all three office vlans, `10.1.32.0/19`. 13 | * A branch office has been opened in a new location, and an IP in IP tunnel has been established to provide access to the servers in the main office. 14 | * Using the firewall on the main office gateway, access is granted from the office network and remote branch office network to the internal server network, but not between workstations in different locations, and not from workstations to the warehouse network. 15 | 16 | ## Separating concerns... 17 | 18 | One thing that's bothering Carl is the amount of functionality that's currently running on the single router "sparrow". Besides being the office gateway, it's also a VPN server and gateway to an external office now. But, not visible in the picture, it's also a webmail proxy, backup server, it runs nagios and munin and an outgoing mail relay. 19 | 20 | In order to make maintenance and upgrades easier, Carl would like to refactor the network in a way so that functionality is split over multiple servers. 21 | 22 | ## Separate routers 23 | 24 | Carl fires up his network diagram editor, loads the drawing of his network layout, and starts changing it: 25 | 26 | ![Birdhouse network with split routers](/birdhouse-vlans-vpn/birdhouse-vlans-vpn-split.png) 27 | 28 | Two new routers have been introduced here, a separate VPN gateway, "pigeon", and a separate IP tunnel gateway "owl". 29 | 30 | Both of the new routers have an interface in the public network: 31 | 32 | * The VPN server "pigeon" needs to have a public accessible IP address for VPN clients to connect to. 33 | * The tunnel gateway connecting the branch office to the internal network needs a public address to be able to connect to the remote tunnel endpoint. 34 | 35 | Although this is a nice first step, Carl realizes it's not ready yet. Something is missing. 36 | 37 | The internal network has been split up, and the various parts of it cannot communicate with each other any more. Using the public network segment to point RFC1918 routes to the other routers is not really an option, since it will result in complex firewall/NAT exceptions, because of the SNAT rules for outgoing traffic, which rewrite the RFC1918 addresses. So, as a best-practice, Carl does not like to mix RFC1918 with public routable addresses on the same vlan, knowing it will cause too many headaches. 38 | 39 | ## An internal routing vlan 40 | 41 | Carl decides to introduce an extra vlan, which is going to be used for exchanging traffic between the routers: 42 | 43 | ![Birdhouse network with split routers and internal routing vlan](/birdhouse-vlans-vpn/birdhouse-vlans-vpn-split-routing-vlan.png) 44 | 45 | Using this extra vlan, each router can be configured with routes to the rest of the network. This is already much better. 46 | 47 | However, the next question immediately rises... In order to make sure each part of the network can be reached from each other part, Carl would have to program all the following routes into the separate routers: 48 | 49 | Office Gateway "sparrow": 50 | * `10.1.18.0/24 via 10.1.32.3` 51 | * `10.1.33.66/31 via 10.1.32.3` 52 | * `10.1.62.0/24 via 10.1.32.2` 53 | 54 | VPN Gateway "pigeon": 55 | * `10.1.18.0/24 via 10.1.32.3` 56 | * `10.1.33.66/31 via 10.1.32.3` 57 | * `10.1.59.0/24 via 10.1.32.1` 58 | * `10.1.60.0/24 via 10.1.32.1` 59 | * `10.1.63.0/24 via 10.1.32.1` 60 | 61 | Tunnel gateway "owl": 62 | * `10.1.59.0/24 via 10.1.32.1` 63 | * `10.1.60.0/24 via 10.1.32.1` 64 | * `10.1.62.0/24 via 10.1.32.2` 65 | * `10.1.63.0/24 via 10.1.32.1` 66 | 67 | Carl realizes this is going to turn into a real nightmare when the network keeps expanding in the future, and starts looking for a better way to handle all the routes. 68 | 69 | It would be cool if the routers could just talk to each other on the internal routing lan and tell each other which networks are reachable via them... 70 | 71 | Next: [An introduction to OSPF](/ospf-intro/README.md) 72 | -------------------------------------------------------------------------------- /bgp-intro/lxc/fixnetwork.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | sed -i '/lxc.net/d' R*/config H*/config 4 | 5 | cat <> H6/config 6 | 7 | lxc.net.0.type = veth 8 | lxc.net.0.flags = up 9 | lxc.net.0.name = vlan2 10 | lxc.net.0.veth.pair = h6.2 11 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 12 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 13 | lxc.net.0.hwaddr = 02:00:0a:28:02:06 14 | EOF 15 | 16 | cat <> R0/config 17 | 18 | lxc.net.0.type = veth 19 | lxc.net.0.flags = up 20 | lxc.net.0.name = vlan216 21 | lxc.net.0.veth.pair = r0.216 22 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 23 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 24 | lxc.net.0.hwaddr = 02:00:0a:28:d8:02 25 | 26 | lxc.net.1.type = veth 27 | lxc.net.1.flags = up 28 | lxc.net.1.name = vlan2 29 | lxc.net.1.veth.pair = r0.2 30 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 31 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 32 | lxc.net.1.hwaddr = 02:00:0a:28:02:01 33 | EOF 34 | 35 | cat <> H7/config 36 | 37 | lxc.net.0.type = veth 38 | lxc.net.0.flags = up 39 | lxc.net.0.name = vlan3 40 | lxc.net.0.veth.pair = h7.3 41 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 42 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 43 | lxc.net.0.hwaddr = 02:00:0a:28:03:07 44 | EOF 45 | 46 | cat <> R1/config 47 | 48 | lxc.net.0.type = veth 49 | lxc.net.0.flags = up 50 | lxc.net.0.name = vlan216 51 | lxc.net.0.veth.pair = r1.216 52 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 53 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 54 | lxc.net.0.hwaddr = 02:00:0a:28:d8:03 55 | 56 | lxc.net.1.type = veth 57 | lxc.net.1.flags = up 58 | lxc.net.1.name = vlan3 59 | lxc.net.1.veth.pair = r1.3 60 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 61 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 62 | lxc.net.1.hwaddr = 02:00:0a:28:03:01 63 | EOF 64 | 65 | cat <> R3/config 66 | 67 | lxc.net.0.type = veth 68 | lxc.net.0.flags = up 69 | lxc.net.0.name = vlan216 70 | lxc.net.0.veth.pair = r3.216 71 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 72 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 73 | lxc.net.0.hwaddr = 02:00:0a:28:d8:01 74 | 75 | lxc.net.1.type = veth 76 | lxc.net.1.flags = up 77 | lxc.net.1.name = vlan217 78 | lxc.net.1.veth.pair = r3.217 79 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 80 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 81 | lxc.net.1.hwaddr = 02:00:0a:28:d9:10 82 | EOF 83 | 84 | cat <> R10/config 85 | 86 | lxc.net.0.type = veth 87 | lxc.net.0.flags = up 88 | lxc.net.0.name = vlan33 89 | lxc.net.0.veth.pair = r10.33 90 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 91 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 92 | lxc.net.0.hwaddr = 02:00:0a:28:21:01 93 | 94 | lxc.net.1.type = veth 95 | lxc.net.1.flags = up 96 | lxc.net.1.name = vlan217 97 | lxc.net.1.veth.pair = r10.217 98 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 99 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 100 | lxc.net.1.hwaddr = 02:00:0a:28:d9:11 101 | EOF 102 | 103 | cat <> R11/config 104 | 105 | lxc.net.0.type = veth 106 | lxc.net.0.flags = up 107 | lxc.net.0.name = vlan33 108 | lxc.net.0.veth.pair = r11.33 109 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 110 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 111 | lxc.net.0.hwaddr = 02:00:0a:28:21:02 112 | 113 | lxc.net.1.type = veth 114 | lxc.net.1.flags = up 115 | lxc.net.1.name = vlan48 116 | lxc.net.1.veth.pair = r11.48 117 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 118 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 119 | lxc.net.1.hwaddr = 02:00:0a:28:30:01 120 | EOF 121 | 122 | cat <> H19/config 123 | 124 | lxc.net.0.type = veth 125 | lxc.net.0.flags = up 126 | lxc.net.0.name = vlan48 127 | lxc.net.0.veth.pair = h19.48 128 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 129 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 130 | lxc.net.0.hwaddr = 02:00:0a:28:34:13 131 | EOF 132 | 133 | cat <> R12/config 134 | 135 | lxc.net.0.type = veth 136 | lxc.net.0.flags = up 137 | lxc.net.0.name = vlan33 138 | lxc.net.0.veth.pair = r12.33 139 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 140 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 141 | lxc.net.0.hwaddr = 02:00:0a:28:21:03 142 | 143 | lxc.net.1.type = veth 144 | lxc.net.1.flags = up 145 | lxc.net.1.name = vlan36 146 | lxc.net.1.veth.pair = r12.36 147 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 148 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 149 | lxc.net.1.hwaddr = 02:00:0a:28:24:01 150 | EOF 151 | 152 | cat <> H34/config 153 | 154 | lxc.net.0.type = veth 155 | lxc.net.0.flags = up 156 | lxc.net.0.name = vlan36 157 | lxc.net.0.veth.pair = h34.36 158 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 159 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 160 | lxc.net.0.hwaddr = 02:00:0a:28:24:22 161 | EOF 162 | -------------------------------------------------------------------------------- /ospf-intro/lxc/fixnetwork.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | sed -i '/lxc.net/d' R*/config H*/config 4 | 5 | cat <> R1/config 6 | lxc.net.0.type = veth 7 | lxc.net.0.flags = up 8 | lxc.net.0.name = vlan1001 9 | lxc.net.0.veth.pair = r1.1001 10 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 11 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 12 | lxc.net.0.hwaddr = 02:00:0a:00:01:05 13 | lxc.net.0.ipv4.address = 10.0.1.5/24 14 | lxc.net.1.type = veth 15 | lxc.net.1.flags = up 16 | lxc.net.1.name = vlan1012 17 | lxc.net.1.veth.pair = r1.1012 18 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 19 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 20 | lxc.net.1.hwaddr = 02:00:0a:01:02:07 21 | lxc.net.1.ipv4.address = 10.1.2.7/24 22 | lxc.net.2.type = veth 23 | lxc.net.2.flags = up 24 | lxc.net.2.name = vlan1356 25 | lxc.net.2.veth.pair = r1.1356 26 | lxc.net.2.script.up = /etc/lxc/lxc-openvswitch 27 | lxc.net.2.script.down = /etc/lxc/lxc-openvswitch 28 | lxc.net.2.hwaddr = 02:00:0a:03:38:01 29 | lxc.net.2.ipv4.address = 10.3.56.1/24 30 | EOF 31 | 32 | cat <> R2/config 33 | lxc.net.0.type = veth 34 | lxc.net.0.flags = up 35 | lxc.net.0.name = vlan1012 36 | lxc.net.0.veth.pair = r2.1012 37 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 38 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 39 | lxc.net.0.hwaddr = 02:00:0a:01:02:7b 40 | lxc.net.0.ipv4.address = 10.1.2.123/24 41 | lxc.net.1.type = veth 42 | lxc.net.1.flags = up 43 | lxc.net.1.name = vlan1082 44 | lxc.net.1.veth.pair = r2.1082 45 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 46 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 47 | lxc.net.1.hwaddr = 02:00:0a:08:02:01 48 | lxc.net.1.ipv4.address = 10.8.2.1/24 49 | lxc.net.2.type = veth 50 | lxc.net.2.flags = up 51 | lxc.net.2.name = vlan1050 52 | lxc.net.2.veth.pair = r2.1050 53 | lxc.net.2.script.up = /etc/lxc/lxc-openvswitch 54 | lxc.net.2.script.down = /etc/lxc/lxc-openvswitch 55 | lxc.net.2.hwaddr = 02:00:0a:32:01:01 56 | lxc.net.2.ipv4.address = 10.50.1.1/24 57 | EOF 58 | 59 | cat <> R5/config 60 | lxc.net.0.type = veth 61 | lxc.net.0.flags = up 62 | lxc.net.0.name = vlan1001 63 | lxc.net.0.veth.pair = r5.1001 64 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 65 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 66 | lxc.net.0.hwaddr = 02:00:0a:00:01:04 67 | lxc.net.0.ipv4.address = 10.0.1.4/24 68 | lxc.net.1.type = veth 69 | lxc.net.1.flags = up 70 | lxc.net.1.name = vlan1012 71 | lxc.net.1.veth.pair = r5.1012 72 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 73 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 74 | lxc.net.1.hwaddr = 02:00:0a:01:02:38 75 | lxc.net.1.ipv4.address = 10.1.2.56/24 76 | EOF 77 | 78 | cat <> R6/config 79 | lxc.net.0.type = veth 80 | lxc.net.0.flags = up 81 | lxc.net.0.name = vlan1001 82 | lxc.net.0.veth.pair = r6.1001 83 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 84 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 85 | lxc.net.0.hwaddr = 02:00:0a:00:01:08 86 | lxc.net.0.ipv4.address = 10.0.1.8/24 87 | lxc.net.1.type = veth 88 | lxc.net.1.flags = up 89 | lxc.net.1.name = vlan1034 90 | lxc.net.1.veth.pair = r6.1034 91 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 92 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 93 | lxc.net.1.hwaddr = 02:00:0a:2b:02:01 94 | lxc.net.1.ipv4.address = 10.34.2.1/24 95 | EOF 96 | 97 | cat <> H12/config 98 | lxc.net.0.type = veth 99 | lxc.net.0.flags = up 100 | lxc.net.0.name = vlan1050 101 | lxc.net.0.veth.pair = h12.1050 102 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 103 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 104 | lxc.net.0.hwaddr = 02:00:0a:32:01:0c 105 | lxc.net.0.ipv4.address = 10.50.1.12/24 106 | lxc.net.0.ipv4.gateway = 10.50.1.1 107 | EOF 108 | 109 | cat <> H10/config 110 | lxc.net.0.type = veth 111 | lxc.net.0.flags = up 112 | lxc.net.0.name = vlan1082 113 | lxc.net.0.veth.pair = h10.1082 114 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 115 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 116 | lxc.net.0.hwaddr = 02:00:0a:08:02:0a 117 | lxc.net.0.ipv4.address = 10.8.2.10/24 118 | lxc.net.0.ipv4.gateway = 10.8.2.1 119 | EOF 120 | 121 | cat <> H8/config 122 | lxc.net.0.type = veth 123 | lxc.net.0.flags = up 124 | lxc.net.0.name = vlan1356 125 | lxc.net.0.veth.pair = h8.1356 126 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 127 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 128 | lxc.net.0.hwaddr = 02:00:0a:03:38:08 129 | lxc.net.0.ipv4.address = 10.3.56.8/24 130 | lxc.net.0.ipv4.gateway = 10.3.56.1 131 | EOF 132 | 133 | cat <> H5/config 134 | lxc.net.0.type = veth 135 | lxc.net.0.flags = up 136 | lxc.net.0.name = vlan1034 137 | lxc.net.0.veth.pair = h5.1034 138 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 139 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 140 | lxc.net.0.hwaddr = 02:00:0a:2b:02:05 141 | lxc.net.0.ipv4.address = 10.34.2.5/24 142 | lxc.net.0.ipv4.gateway = 10.34.2.1 143 | EOF 144 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | Network Examples 2 | ================ 3 | 4 | Welcome to my Linux Networking tutorials. The first part, learning two widely used routing protocols, OSPF and BGP, is almost completed. 5 | 6 | ## Target audience 7 | 8 | You've been a Linux server and network administrator for some years, have been building an office and/or colocation network with IPv4, IPv6, firewalls with IPTables, some stateful filtering (and NAT for IPv4). You've set up VPN tunnels between different locations to be able to reach the internal IPv4 network using RFC1918 addresses on the other side. 9 | 10 | You know how to use the `iproute2` programs (`ip a`, `ip r`, etc) to set up your networking, and haven't typed the `ifconfig` or `route` commands in your terminal since 1999. You know how to debug problems using `tcpdump`, `traceroute` etc... 11 | 12 | But... your network doesn't show much redundancy. You're pointing a static route to your VPN tunnel to be able to reach the other side, and when you connect a third location, you're realizing that this way of working is getting more and more painful. 13 | 14 | You're googling the interwebz for tutorials about an introduction to routing protocols, and discover that most of them start out with a huge amount of theoretical information, and then teach you how to configure Cisco equipment. 15 | 16 | You found out that there's helper software to make routing more dynamic, like BIRD, but you have no idea where to start. You don't have money to buy physical routers and switches and cables to connect them, and got a headache after once playing around with a cisco simulator for an hour, missing your cozy linux command line. 17 | 18 | ## Does the web need more tutorials on these topics? 19 | 20 | There aren't a lot of tutorials that take a practical approach, ignoring most of the theory that's not yet needed to be known before just starting to explore the working of e.g. a routing protocol. In my opinion there is really no use in first of all learning that "a type 5 AS-external Link State Advertisement is not allowed in a Not So Stubby Area, unless it's a type 7 Link State Advertisement, that has been converted to a type 5 at an Area Border router, which makes it possible to traverse a..." whatever... :o) 21 | 22 | And, while BIRD (the routing software used in these tutorials) has good reference documentation, it's missing tutorial-style documentation for new users. Even if you already know routing protocols, these tutorials should be a quick way to learn using BIRD and some of its quirks on Linux. 23 | 24 | I hope that while following the tutorials, you're going to experience the "Wow!" moments, that "make the penny drop" and suddenly make you understand a lot more about complex networking topologies on the internet. Just reading the pages will not make that happen, setting up the examples and doing the assignments will. 25 | 26 | Depending on your current knowledge and experience, following the tutorials can take quite some time. This is normal. Don't skip pages or part of them, because when writing, I assume that everything told before is known already. Even though the tutorials are meant as an introduction, there's still already a huge amount of information hidden in them. 27 | 28 | Have fun! 29 | 30 | ## Getting up to speed setting up test environments 31 | 32 | All test setups used in the tutorials are built using Linux, LXC and OpenvSwitch for setting up network topologies, and using BIRD as routing daemon. 33 | 34 | * [Setting up a lab environment](/lxcbird/README.md) explains how to set up a local test environment to build example networks using LXC and openvswitch. The result of the tutorial is having a base container that can be cloned into routers and end hosts. 35 | * [A basic network example](/birdhouse-intro/README.md) provides an introduction to the computer network of a fictional company, the Birdhouse Factory. The tutorial part is to practice some more with setting up a network with containers and openvswitch. 36 | 37 | ## Learning OSPF and BGP 38 | 39 | * [The Birdhouse Factory continued](/birdhouse-vlans-vpn/README.md) shows how the network at the Birdhouse Factory is evolving, and shows the need for a dynamic routing protocol when multiple routers are introduced. 40 | * [An introduction to OSPF](/ospf-intro/README.md) explains the basics of using OSPF as an IGP. 41 | * [An introduction to BGP](/bgp-intro/README.md) shows using BGP to make a connection to an external network that is managed by someone else. Also shows how the routes learned are propagated into the local network, having OSPF and iBGP work together. 42 | * [A bigger BGP network](/bgp-contd/README.md) shows redundant routes, asymmetric traffic flow and explains the difference between "peering" and "transit". 43 | * To be finished: [Wait what... The Internet](/routing-on-the-internet/README.md) shows that with the little amount of knowledge we built up about routing, we can suddenly understand how the whole Internet works! (So, fun with traceroute, bgp.he.net, etc...) 44 | 45 | ## Further ideas 46 | 47 | * Building a pair of stateful filtering IPv4 and IPv6 gateways that can fail over traffic to each other, using `keepalived` and `conntrackd`, while participating in OSPF. 48 | * Building a load balancer using LVS. 49 | * Example showcases would be really nice. For example, visiting some IXP that uses BIRD as route server, and doing a writeup of what their network architecture looks like and the been-there-done-thats that they want to share. 50 | * ... 51 | 52 | ## Feedback, getting help 53 | 54 | * I'm very interested in feedback on the amount of time it takes to work through the tutorials. Since I wrote them, I cannot predict those, and it may provide useful information about reordering the pages if they're too long. 55 | * If you like IRC, try the `#bird` channel on Libera Chat. There's a bunch of friendly BIRD users in there that might help you with the BIRD configuration if you have questions. 56 | 57 | Hans van Kranenburg, `hans@knorrie.org` 58 | -------------------------------------------------------------------------------- /birdhouse-intro/README.md: -------------------------------------------------------------------------------- 1 | # A basic network example 2 | 3 | In the very first part of this tutorial, we're going to play around with the linux containers and networking a bit, and introduce the network of a fictional company that I'll be using as example in the tutorials. 4 | 5 | The goal is to become comfortable with quickly setting up and tearing down example networks. 6 | 7 | ## The Birdhouse Factory 8 | 9 | Well, there it is... The Birdhouse Factory network: 10 | 11 | ![Birdhouse Network](/birdhouse-intro/birdhouse-intro.png) 12 | 13 | The Birdhouse Factory is a fictional company that manufactures little wooden birdhouses. Besides their manufacturing process and the warehouse, they have an office where accounting and sales people work. 14 | 15 | Since the Birdhouse Factory people also like internet technology, they combined these interests and run their own webshop where you can buy birdhouses online, and their own mail server. The Factory has some IPv4 space allocated from an ISP, where they run their servers, and where they have a NAT router in front of their office network, which uses RFC1918 IPv4 network ranges. 16 | 17 | ## Cloning and configuring new containers 18 | 19 | After following the [tutorial to set up a lab environment](/lxcbird/README.md) we end up with the first container, "birdbase". Make sure this birdbase container is stopped (by using `lxc-stop`, or typing `halt` on the container prompt after using `lxc-attach`), so it can be cloned into new ones. 20 | 21 | lxcbird:/var/lib/lxc 0-# lxc-ls --fancy 22 | NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED 23 | birdbase STOPPED 0 - - - false 24 | 25 | Let's create some of the systems shown in the network picture: 26 | 27 | lxcbird:/var/lib/lxc 0-# lxc-copy -s -n birdbase -N sparrow 28 | lxcbird:/var/lib/lxc 0-# lxc-copy -s -n birdbase -N weaver 29 | 30 | Now we need to configure the network interfaces and add a little iptables ruleset for the NAT gateway. 31 | 32 | ### Sparrow 33 | 34 | Sparrow has two interfaces, one in vlan10, the network to run public services, and vlan60, the office network. In `sparrow/config`, network interfaces are defined: 35 | 36 | lxc.net.0.type = veth 37 | lxc.net.0.name = vlan10 38 | lxc.net.0.veth.pair = sparrow.10 39 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 40 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 41 | lxc.net.0.hwaddr = 02:00:c6:33:64:13 42 | lxc.net.1.type = veth 43 | lxc.net.1.name = vlan60 44 | lxc.net.1.veth.pair = sparrow.60 45 | lxc.net.1.script.up = /etc/lxc/lxc-openvswitch 46 | lxc.net.1.script.down = /etc/lxc/lxc-openvswitch 47 | lxc.net.1.hwaddr = 02:00:0a:01:3c:01 48 | 49 | And they're configured with addresses in `sparrow/rootfs/etc/network/interfaces`: 50 | 51 | auto lo 52 | iface lo inet loopback 53 | 54 | auto vlan10 55 | iface vlan10 inet manual 56 | pre-up iptables-restore < /etc/network/firewall 57 | up ip link set up dev vlan10 58 | up ip addr add 198.51.100.19/26 brd + dev vlan10 59 | up ip route add default via 198.51.100.1 dev vlan10 60 | down ip addr del 198.51.100.19/26 dev vlan10 61 | down ip link set down dev vlan10 62 | 63 | auto vlan60 64 | iface vlan60 inet manual 65 | up ip link set up dev vlan60 66 | up ip addr add 10.1.60.1/24 brd + dev vlan60 67 | down ip addr del 10.1.60.1/24 dev vlan60 68 | down ip link set down dev vlan60 69 | 70 | In order to activate NAT, here's the bare minimal thing to put in `sparrow/rootfs/etc/network/firewall`: 71 | 72 | *nat 73 | -A POSTROUTING -o vlan10 -j MASQUERADE 74 | COMMIT 75 | 76 | Now, start the container with `lxc-start -d -n sparrow` and get a command prompt with `lxc-attach -n sparrow`. Use `ip a`, `ip r` etc, to verify that addresses and routes are set correctly. 77 | 78 | ### Weaver 79 | 80 | Weaver is a bit simpler, since it's just an end host with one network interface. For `weaver/config`: 81 | 82 | lxc.net.0.type = veth 83 | lxc.net.0.name = vlan60 84 | lxc.net.0.veth.pair = weaver.60 85 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 86 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 87 | lxc.net.0.hwaddr = 02:00:0a:01:3c:15 88 | 89 | And `weaver/rootfs/etc/network/interfaces`: 90 | 91 | auto lo 92 | iface lo inet loopback 93 | 94 | auto vlan60 95 | iface vlan60 inet manual 96 | up ip link set up dev vlan60 97 | up ip addr add 10.1.60.21/24 brd + dev vlan60 98 | up ip route add default via 10.1.60.1 dev vlan60 99 | down ip addr del 10.1.60.21/24 dev vlan60 100 | down ip link set down dev vlan60 101 | 102 | Start weaver, get a command prompt, and see if you have proper connectivity to the outside internet. Traceroute something outside for example. If not, debug the IP addresses and routes and fix it. 103 | 104 | ## Finishing up... some assignments. 105 | 106 | The "ISP Router" functionality can be handled by the LXC host machine, as shown in the [introduction](/lxcbird/README.md). 107 | 108 | To finish this tutorial: 109 | * Verify how openvswitch is used by looking at the output of `ovs-vsctl show` in the lxc host machine. 110 | * Create a third container, the webshop server, and configure it. Confirm you can reach it from weaver, by running a SimpleHTTPServer with python (`python -m SimpleHTTPServer`) and pointing wget to it from weaver. You should see the outside IPv4 address of sparrow as source address of the request because of the NAT. Also, because of the NAT, the webshop server does not need to know a route to the `10.1.60.0/24` network, because it's hidden behind sparrow. 111 | 112 | That's basically it. As you can see, when you get the hang of this, it's instantly also getting extremely boring to do the configuration every time. For later tutorials, I'll make sure all files that make up the starting point of the configuration are available to simply copy into the newly cloned containers. 113 | 114 | # Cleanup! 115 | 116 | Oh, wait, before we move on, let's introduce the cleaning up step... 117 | 118 | When working through the next pages of the tutorial, we'll often create a bunch of containers by cloning the birdbase container. Before starting the next tutorial, you want to clean them up, since container names might be reused. 119 | 120 | For now, we can stop and remove them like this: 121 | 122 | lxcbird:/var/lib/lxc 0-# lxc-stop -n sparrow 123 | lxcbird:/var/lib/lxc 0-# lxc-stop -n weaver 124 | lxcbird:/var/lib/lxc 0-# lxc-destroy -n sparrow 125 | lxcbird:/var/lib/lxc 0-# lxc-destroy -n weaver 126 | 127 | (N.B. With Debian Buster and btrfs, I currently get a lot of error like `lxc-destroy: sparrow: storage/btrfs.c: get_btrfs_subvol_path: 103 Failed to append name - rootfs�x`, it seems it actually in the end can remove everything, so I'm ignoring those for now.) 128 | 129 | Next up: [Meanwhile at the Birdhouse Factory...](/birdhouse-vlans-vpn/README.md) 130 | -------------------------------------------------------------------------------- /lxcbird/README.md: -------------------------------------------------------------------------------- 1 | # Setting up a lab environment 2 | 3 | For the tutorials, I've chosen to use Debian GNU/Linux with lxc, btrfs and openvswitch and some extra git thrown at it to build simulations of complete networks. The current stable Debian Release, 10 (Buster) already contains everything you need for this. 4 | 5 | So, make sure you get your hands on an empty physical or virtual machine. The one I use is a standard Debian x86-64 (a.k.a. amd64) virtual machine. 6 | 7 | * LXC provides a very lightweight way to run containers with their own network namespace, separated from each other. 8 | * I use btrfs subvolumes as container filesystems. 9 | * The advantage of using openvswitch is that we can very easily run a vlan capable switch, by just configuring ports on it as either access or trunk port with any of the vlan numbers assigned, much like you would do with a physical switch. 10 | * Creating a git repository just outside the container root filesystems with a .gitignore that only includes specific files allows to easily store the configuration of a whole test network. For example, when destroying a complete container and cloning it from another container again, a simple git checkout is enough to put the configuration inside the container back in place. 11 | 12 | Here's a simple schematic overview of what I mean: 13 | 14 | ![lxc-openvswitch-topology](/lxcbird/lxc-openvswitch-topology.png) 15 | 16 | ## Some basic packages 17 | 18 | To be able to create containers and hook up their network interfaces to openvswitch, we need the following packages: 19 | 20 | apt-get install lxc lxc-templates debootstrap openvswitch-switch git 21 | 22 | ## Setting up networking 23 | 24 | The lxc host system only needs a single external network interface, for you to manage it, and probably to masquerade outgoing traffic from the test environment, using NAT. It's of course also possible to route some real address space to this box for use in the test networks, but I'm not doing so. 25 | 26 | Here's the `/etc/network/interfaces` of my lxc host, well, almost, since I replaced the eth0 addresses with fakes: 27 | 28 | lxcbird:/etc/network 0-# cat interfaces 29 | auto lo 30 | iface lo inet loopback 31 | 32 | auto eth0 33 | iface eth0 inet manual 34 | up ip link set up dev eth0 35 | up ip addr add 10.255.1.34/24 brd + dev eth0 36 | up ip addr add 2001:db8:ffff::22/64 dev eth0 37 | up ip route add default via 10.255.1.1 dev eth0 38 | up ip route add default via 2001:db8:ffff::1 dev eth0 39 | down ip -6 route del default 40 | down ip addr del 2001:db8:ffff::22/64 dev eth0 41 | down ip addr del 10.255.1.34/24 dev eth0 42 | down ip link set down dev eth0 43 | 44 | allow-ovs ovs0 45 | iface ovs0 inet manual 46 | pre-up ovs-vsctl -- --if-exists del-br ovs0 47 | pre-up ovs-vsctl add-br ovs0 48 | up ip link set up dev ovs0 49 | down ip link set down dev ovs0 50 | post-down ovs-vsctl del-br ovs0 51 | 52 | allow-ovs vlan10 53 | iface vlan10 inet manual 54 | pre-up ovs-vsctl add-port ovs0 vlan10 tag=10 -- set interface vlan10 type=internal 55 | up ip link set up dev vlan10 56 | up ip addr add 198.51.100.1/24 brd + dev vlan10 57 | up ip addr add 2001:db8:1998::1/120 dev vlan10 58 | down ip addr del 2001:db8:1998::1/120 dev vlan10 59 | down ip addr del 198.51.100.1/24 dev vlan10 60 | down ip link set down dev vlan10 61 | post-down ovs-vsctl del-port ovs0 vlan10 62 | 63 | As you can see, I'm not a fan of the default way `network/interfaces` works in Debian. Actually, I always use manual mode and (pre-)up and (post-)down rules to set up and tear down everything. This is more convenient if you don't like magic too much, and often work with multiple addresses and extra commands on interfaces. 64 | 65 | ## Masquerading outgoing traffic 66 | 67 | To enable masquerading outgoing traffic from the test networks, make sure you enable IP forwarding, for example by putting the following settings in the `/etc/sysctl.conf`... 68 | 69 | net.ipv4.ip_forward = 1 70 | net.ipv6.conf.all.forwarding = 1 71 | net.ipv6.conf.default.forwarding = 1 72 | 73 | ...and by using a few simple netfilter rules to do the NAT, like... 74 | 75 | *nat 76 | -A POSTROUTING -o eth0 -j MASQUERADE 77 | COMMIT 78 | *filter 79 | :FORWARD DROP [0:0] 80 | -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT 81 | -A FORWARD -i vlan10 -o eth0 -j ACCEPT 82 | COMMIT 83 | 84 | ...which can be done for IPv4, as well as for IPv6, because NAT for IPv6 has finally been implemented. For test environments like this, it's very helpful, since we can just use documentation addresses from `2001:db8::/32` and are still able to access the outside internet if needed. 85 | 86 | ## Setting up version control 87 | 88 | lxcbird:/var/lib/lxc 0-# git init 89 | Initialized empty Git repository in /var/lib/lxc-bird/.git/ 90 | 91 | Now make sure your `.gitignore` looks like this, to include only very specific files from all containers: 92 | 93 | lxcbird:/var/lib/lxc 0-# cat .gitignore 94 | *.log 95 | */* 96 | !*/config 97 | !*/rootfs 98 | */rootfs/* 99 | !*/rootfs/etc/ 100 | */rootfs/etc/* 101 | !*/rootfs/etc/hosts 102 | !*/rootfs/etc/sysctl.conf 103 | 104 | !*/rootfs/etc/network/ 105 | */rootfs/etc/network/* 106 | !*/rootfs/etc/network/interfaces 107 | !*/rootfs/etc/network/firewall 108 | !*/rootfs/etc/network/firewall6 109 | 110 | !*/rootfs/etc/bird/ 111 | */rootfs/etc/bird/* 112 | !*/rootfs/etc/bird/bird.conf 113 | !*/rootfs/etc/bird/bird6.conf 114 | lxcbird:/var/lib/lxc 0-# git add .gitignore 115 | lxcbird:/var/lib/lxc 0-# git commit -m "Only include specific files from containers" 116 | [master (root-commit) 8ecfeec] Only include specific files from containers 117 | 1 file changed, 20 insertions(+) 118 | create mode 100644 .gitignore 119 | 120 | ## Creating the first container 121 | 122 | Here's an example to create a first container, which we'll configure a bit and use as a template to clone all other containers from. 123 | 124 | lxcbird:/var/lib/lxc 0-# MIRROR=http://ftp.nl.debian.org/debian lxc-create -t debian -B btrfs -n birdbase -- -r buster 125 | 126 | Note that I'm using a btrfs file system on my computer, and lxc is using btrfs snapshots to clone the containers. When using a different storage backend for lxc, e.g. ext4 and overlayfs, some of the details of placement of files may vary. It is left as exercise for the reader to deal with these small differences. 127 | 128 | ### Configure the network and openvswitch up/down script 129 | 130 | In `birdbase/config`, lxc-create has put some basic configuration. The networking configuration has to be set up now, so we can test our connectivity and install some extra software. To be able to do so, I'm going to configure it with an IPv4 and IPv6 address in the range of vlan10, and point my default gateway to the lxc host system. 131 | 132 | In the config file, instead of... 133 | 134 | lxc.net.0.type = empty 135 | 136 | ...it should look more like this... 137 | 138 | lxc.net.0.type = veth 139 | lxc.net.0.name = vlan10 140 | lxc.net.0.veth.pair = birdbase.10 141 | lxc.net.0.flags = up 142 | lxc.net.0.script.up = /etc/lxc/lxc-openvswitch 143 | lxc.net.0.script.down = /etc/lxc/lxc-openvswitch 144 | 145 | ...and also, if you don't have apparmor stuff set up (apparently I haven't), then you can disable all of that by changing the following option to 'unconfined'. It took me a bit to figure this out, based on only a "No such file or directory" error I got: 146 | 147 | lxc.apparmor.profile = unconfined 148 | 149 | Oh, and by the way, the lxc network script referenced is a really simple script to integrate lxc with openvswitch, which simply attaches an interface in the container to a vlan inside openvswitch based on the number after the dot. It has to be present on the host system, not in the container, and it needs the executable permission bit set. 150 | 151 | lxcbird:/etc/lxc 0-# cat lxc-openvswitch 152 | #!/bin/sh 153 | 154 | # $1 container name 155 | # $2 config section name (net) 156 | # $3 execution context (up/down) 157 | # $4 network type (empty/veth/macvlan/phys) 158 | # $5 (host-sided) device name 159 | 160 | if [ "$3" = "up" ] 161 | then 162 | vlan=$(echo "$5" | awk -F . '{ print $NF }') 163 | ovs-vsctl add-port ovs0 $5 tag=$vlan 164 | else 165 | ovs-vsctl del-port ovs0 $5 166 | fi 167 | 168 | lxcbird:/etc/lxc 0-# chmod +x lxc-openvswitch 169 | lxcbird:/etc/lxc 0-# ls -l lxc-openvswitch 170 | -rwxr-xr-x 1 root root 314 Apr 6 2015 lxc-openvswitch 171 | 172 | Instead of setting the container IP address and gateway in the lxc configuration file, I prefer using network/interfaces inside the container, because we'll be using that for more complex networking anyway in the tutorials: 173 | 174 | lxcbird:/var/lib/lxc/birdbase 0-# cat rootfs/etc/network/interfaces 175 | auto lo 176 | iface lo inet loopback 177 | 178 | auto vlan10 179 | iface vlan10 inet manual 180 | up ip link set up dev vlan10 181 | up ip addr add 198.51.100.254/24 brd + dev vlan10 182 | up ip addr add 2001:db8:1998::fe/120 dev vlan10 183 | up ip route add default via 198.51.100.1 dev vlan10 184 | up ip route add default via 2001:db8:1998::1 dev vlan10 185 | down ip -6 route del default 186 | down ip addr del 2001:db8:1998::fe/120 dev vlan10 187 | down ip route del default 188 | down ip addr del 198.51.100.254/24 dev vlan10 189 | down ip link set down dev vlan10 190 | 191 | ### Prevent Debian from installing unnecessary packages 192 | 193 | Now, before starting it, we need to finish up a few basic configuration settings... 194 | 195 | lxcbird:/var/lib/lxc/birdbase 0-# echo 'APT::Install-Recommends "false";' > rootfs/etc/apt/apt.conf.d/00InstallRecommends 196 | 197 | I hate the default of installing recommends in Debian, so I always turn that off. Generally, it's recommended to install Recommends when using Debian, so it installs other packages that are 'generally found together with these ones'. Generally, I don't really see the pattern in this, and I recommend to just try disabling Recommends to see which issues you run into, so you learn more about how related software works together. Anyway, for your minimal BIRD lxc container, we won't run into any problem doing so now. 198 | 199 | ### Start! 200 | 201 | Now, let's try to start it and see what happens! 202 | 203 | lxcbird:/var/lib/lxc/birdbase 0-# lxc-start -d -n birdbase 204 | lxcbird:/var/lib/lxc/birdbase 0-# lxc-attach -n birdbase 205 | root@birdbase:/# 206 | root@birdbase:/# ip a 207 | 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 208 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 209 | inet 127.0.0.1/8 scope host lo 210 | valid_lft forever preferred_lft forever 211 | inet6 ::1/128 scope host 212 | valid_lft forever preferred_lft forever 213 | 7: vlan10@if8: mtu 1500 qdisc noqueue state UP group default qlen 1000 214 | link/ether ce:21:b1:f4:b8:c5 brd ff:ff:ff:ff:ff:ff link-netnsid 0 215 | inet 198.51.100.254/24 brd 198.51.100.255 scope global vlan10 216 | valid_lft forever preferred_lft forever 217 | inet6 2001:db8:1998::fe/120 scope global 218 | valid_lft forever preferred_lft forever 219 | inet6 fe80::cc21:b1ff:fef4:b8c5/64 scope link 220 | valid_lft forever preferred_lft forever 221 | 222 | Let's verify if we have proper outgoing network connectivity! 223 | 224 | root@birdbase:/# ping knorrie.org 225 | bash: ping: command not found 226 | 227 | Oh, there's our first problem... it's still a bit too basic :) 228 | 229 | ## Finishing our birdbase container 230 | 231 | root@birdbase:/# apt-get update 232 | [...] 233 | root@birdbase:/# apt-get install iputils-ping bird dnsutils iptables iptstate mtr-tiny tcpdump nmon traceroute iftop iperf3 234 | [...] 235 | 236 | The fact that we can do this already proves networking is set up right! 237 | 238 | root@birdbase:/# ping4 -n -c 3 knorrie.org 239 | PING knorrie.org (82.94.188.77) 56(84) bytes of data. 240 | 64 bytes from 82.94.188.77: icmp_seq=1 ttl=54 time=6.64 ms 241 | 64 bytes from 82.94.188.77: icmp_seq=2 ttl=54 time=5.12 ms 242 | 64 bytes from 82.94.188.77: icmp_seq=3 ttl=54 time=3.91 ms 243 | 244 | --- knorrie.org ping statistics --- 245 | 3 packets transmitted, 3 received, 0% packet loss, time 2002ms 246 | rtt min/avg/max/mdev = 3.913/5.228/6.646/1.118 ms 247 | root@birdbase:/# ping6 -n -c 3 knorrie.org 248 | PING knorrie.org(2001:888:2177::4d) 56 data bytes 249 | 64 bytes from 2001:888:2177::4d: icmp_seq=1 ttl=53 time=5.51 ms 250 | 64 bytes from 2001:888:2177::4d: icmp_seq=2 ttl=53 time=3.99 ms 251 | 64 bytes from 2001:888:2177::4d: icmp_seq=3 ttl=53 time=3.39 ms 252 | 253 | --- knorrie.org ping statistics --- 254 | 3 packets transmitted, 3 received, 0% packet loss, time 2002ms 255 | rtt min/avg/max/mdev = 3.398/4.302/5.513/0.890 ms 256 | 257 | And now ping confirms it. Both IPv4 and IPv6 masquerading works. 258 | 259 | ### BIRD logfile location 260 | 261 | Since there is no separate syslog process in the container, create a directory where we can point logging configuration to later: 262 | 263 | root@birdbase:/# mkdir /var/log/bird 264 | root@birdbase:/# chown bird: /var/log/bird 265 | root@birdbase:/# > /var/log/bird/bird.log; chown bird: /var/log/bird/bird.log 266 | root@birdbase:/# > /var/log/bird/bird6.log; chown bird: /var/log/bird/bird6.log 267 | 268 | The creation of the log file is necessary to work around a bug in the Debian packaging, that causes the logfile to be created with root as owner, and subsequent causes bird startup to fail because it cannot write to the logfile as user bird. :-( 269 | 270 | ### IP forwarding 271 | 272 | For IP forwarding, make sure you uncomment `net.ipv4.ip_forward=1` and `net.ipv6.conf.all.forwarding=1` in sysctl.conf inside the container. Hint: editing configuration files inside a container can be done from outside the container, by looking for them in the `rootfs` folder inside the container directories. 273 | 274 | ## Disabling icmp error rate limiting 275 | 276 | Since we'll be doing a lot of tracerouting in the example networks, it's nice to disable icmp error rate limiting in sysctl.conf, to prevent hickups while executing quick subsequent traceroute commands: 277 | 278 | net.ipv4.icmp_ratelimit = 0 279 | net.ipv6.icmp.ratelimit = 0 280 | 281 | You probably wouldn't want to do this in a production network. For more information, see [the blog post "A strange packet loss"](http://backreference.org/2012/11/16/a-strange-packet-loss/) 282 | 283 | ### Root password 284 | 285 | You might also want to change the password for root, since it's set to some random string by default. 286 | 287 | ## Cleanup 288 | 289 | Before the birdbase container is ready as a template to be used for cloning other containers, let's shut it down and remove some container-specific configuration, so we won't accidentally start a new one with duplicate configuration, and, to make the diff look nicer when configuring a clone: 290 | 291 | lxcbird:/var/lib/lxc 1-# lxc-stop -n birdbase 292 | 293 | lxcbird:/var/lib/lxc 1-# sed -i /^lxc.net/d birdbase/config 294 | lxcbird:/var/lib/lxc 1-# > birdbase/rootfs/etc/bird/bird.conf 295 | lxcbird:/var/lib/lxc 1-# > birdbase/rootfs/etc/bird/bird6.conf 296 | lxcbird:/var/lib/lxc 1-# > birdbase/rootfs/etc/network/interfaces 297 | 298 | Finally, we can check that git only wants to store our bird and network configuration, and do so: 299 | 300 | lxcbird:/var/lib/lxc/birdbase 0-# git status 301 | On branch master 302 | Untracked files: 303 | (use "git add ..." to include in what will be committed) 304 | 305 | ./ 306 | 307 | nothing added to commit but untracked files present (use "git add" to track) 308 | lxcbird:/var/lib/lxc/birdbase 0-# git add . 309 | lxcbird:/var/lib/lxc/birdbase 0-# git status 310 | On branch master 311 | Changes to be committed: 312 | (use "git reset HEAD ..." to unstage) 313 | 314 | new file: config 315 | new file: rootfs/etc/sysctl.conf 316 | new file: rootfs/etc/bird/bird.conf 317 | new file: rootfs/etc/bird/bird6.conf 318 | new file: rootfs/etc/network/interfaces 319 | 320 | lxcbird:/var/lib/lxc/birdbase 0-# git commit -m "birdbase network and bird config" 321 | [...] 322 | 323 | Right! As you might notice, there are "end-hosts" in the drawing on top of this page, and we just configured the base container to start bird and enable IP forwarding. While this is not needed, or wanted for the end host containers, I don't really care, because it will not influence the working of the test environment, as bird has no configuration, end hosts will not attract traffic that's not for themselves. However, if you like, you can create two different containers to clone from, one for a router, and one for an end host. 324 | 325 | Let's head over to the next page to [meet the Birdhouse Factory network](/birdhouse-intro/README.md)! 326 | -------------------------------------------------------------------------------- /LICENSE-fdl-1.3: -------------------------------------------------------------------------------- 1 | 2 | GNU Free Documentation License 3 | Version 1.3, 3 November 2008 4 | 5 | 6 | Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. 7 | 8 | Everyone is permitted to copy and distribute verbatim copies 9 | of this license document, but changing it is not allowed. 10 | 11 | 0. PREAMBLE 12 | 13 | The purpose of this License is to make a manual, textbook, or other 14 | functional and useful document "free" in the sense of freedom: to 15 | assure everyone the effective freedom to copy and redistribute it, 16 | with or without modifying it, either commercially or noncommercially. 17 | Secondarily, this License preserves for the author and publisher a way 18 | to get credit for their work, while not being considered responsible 19 | for modifications made by others. 20 | 21 | This License is a kind of "copyleft", which means that derivative 22 | works of the document must themselves be free in the same sense. It 23 | complements the GNU General Public License, which is a copyleft 24 | license designed for free software. 25 | 26 | We have designed this License in order to use it for manuals for free 27 | software, because free software needs free documentation: a free 28 | program should come with manuals providing the same freedoms that the 29 | software does. But this License is not limited to software manuals; 30 | it can be used for any textual work, regardless of subject matter or 31 | whether it is published as a printed book. We recommend this License 32 | principally for works whose purpose is instruction or reference. 33 | 34 | 35 | 1. APPLICABILITY AND DEFINITIONS 36 | 37 | This License applies to any manual or other work, in any medium, that 38 | contains a notice placed by the copyright holder saying it can be 39 | distributed under the terms of this License. Such a notice grants a 40 | world-wide, royalty-free license, unlimited in duration, to use that 41 | work under the conditions stated herein. The "Document", below, 42 | refers to any such manual or work. Any member of the public is a 43 | licensee, and is addressed as "you". You accept the license if you 44 | copy, modify or distribute the work in a way requiring permission 45 | under copyright law. 46 | 47 | A "Modified Version" of the Document means any work containing the 48 | Document or a portion of it, either copied verbatim, or with 49 | modifications and/or translated into another language. 50 | 51 | A "Secondary Section" is a named appendix or a front-matter section of 52 | the Document that deals exclusively with the relationship of the 53 | publishers or authors of the Document to the Document's overall 54 | subject (or to related matters) and contains nothing that could fall 55 | directly within that overall subject. (Thus, if the Document is in 56 | part a textbook of mathematics, a Secondary Section may not explain 57 | any mathematics.) The relationship could be a matter of historical 58 | connection with the subject or with related matters, or of legal, 59 | commercial, philosophical, ethical or political position regarding 60 | them. 61 | 62 | The "Invariant Sections" are certain Secondary Sections whose titles 63 | are designated, as being those of Invariant Sections, in the notice 64 | that says that the Document is released under this License. If a 65 | section does not fit the above definition of Secondary then it is not 66 | allowed to be designated as Invariant. The Document may contain zero 67 | Invariant Sections. If the Document does not identify any Invariant 68 | Sections then there are none. 69 | 70 | The "Cover Texts" are certain short passages of text that are listed, 71 | as Front-Cover Texts or Back-Cover Texts, in the notice that says that 72 | the Document is released under this License. A Front-Cover Text may 73 | be at most 5 words, and a Back-Cover Text may be at most 25 words. 74 | 75 | A "Transparent" copy of the Document means a machine-readable copy, 76 | represented in a format whose specification is available to the 77 | general public, that is suitable for revising the document 78 | straightforwardly with generic text editors or (for images composed of 79 | pixels) generic paint programs or (for drawings) some widely available 80 | drawing editor, and that is suitable for input to text formatters or 81 | for automatic translation to a variety of formats suitable for input 82 | to text formatters. A copy made in an otherwise Transparent file 83 | format whose markup, or absence of markup, has been arranged to thwart 84 | or discourage subsequent modification by readers is not Transparent. 85 | An image format is not Transparent if used for any substantial amount 86 | of text. A copy that is not "Transparent" is called "Opaque". 87 | 88 | Examples of suitable formats for Transparent copies include plain 89 | ASCII without markup, Texinfo input format, LaTeX input format, SGML 90 | or XML using a publicly available DTD, and standard-conforming simple 91 | HTML, PostScript or PDF designed for human modification. Examples of 92 | transparent image formats include PNG, XCF and JPG. Opaque formats 93 | include proprietary formats that can be read and edited only by 94 | proprietary word processors, SGML or XML for which the DTD and/or 95 | processing tools are not generally available, and the 96 | machine-generated HTML, PostScript or PDF produced by some word 97 | processors for output purposes only. 98 | 99 | The "Title Page" means, for a printed book, the title page itself, 100 | plus such following pages as are needed to hold, legibly, the material 101 | this License requires to appear in the title page. For works in 102 | formats which do not have any title page as such, "Title Page" means 103 | the text near the most prominent appearance of the work's title, 104 | preceding the beginning of the body of the text. 105 | 106 | The "publisher" means any person or entity that distributes copies of 107 | the Document to the public. 108 | 109 | A section "Entitled XYZ" means a named subunit of the Document whose 110 | title either is precisely XYZ or contains XYZ in parentheses following 111 | text that translates XYZ in another language. (Here XYZ stands for a 112 | specific section name mentioned below, such as "Acknowledgements", 113 | "Dedications", "Endorsements", or "History".) To "Preserve the Title" 114 | of such a section when you modify the Document means that it remains a 115 | section "Entitled XYZ" according to this definition. 116 | 117 | The Document may include Warranty Disclaimers next to the notice which 118 | states that this License applies to the Document. These Warranty 119 | Disclaimers are considered to be included by reference in this 120 | License, but only as regards disclaiming warranties: any other 121 | implication that these Warranty Disclaimers may have is void and has 122 | no effect on the meaning of this License. 123 | 124 | 2. VERBATIM COPYING 125 | 126 | You may copy and distribute the Document in any medium, either 127 | commercially or noncommercially, provided that this License, the 128 | copyright notices, and the license notice saying this License applies 129 | to the Document are reproduced in all copies, and that you add no 130 | other conditions whatsoever to those of this License. You may not use 131 | technical measures to obstruct or control the reading or further 132 | copying of the copies you make or distribute. However, you may accept 133 | compensation in exchange for copies. If you distribute a large enough 134 | number of copies you must also follow the conditions in section 3. 135 | 136 | You may also lend copies, under the same conditions stated above, and 137 | you may publicly display copies. 138 | 139 | 140 | 3. COPYING IN QUANTITY 141 | 142 | If you publish printed copies (or copies in media that commonly have 143 | printed covers) of the Document, numbering more than 100, and the 144 | Document's license notice requires Cover Texts, you must enclose the 145 | copies in covers that carry, clearly and legibly, all these Cover 146 | Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on 147 | the back cover. Both covers must also clearly and legibly identify 148 | you as the publisher of these copies. The front cover must present 149 | the full title with all words of the title equally prominent and 150 | visible. You may add other material on the covers in addition. 151 | Copying with changes limited to the covers, as long as they preserve 152 | the title of the Document and satisfy these conditions, can be treated 153 | as verbatim copying in other respects. 154 | 155 | If the required texts for either cover are too voluminous to fit 156 | legibly, you should put the first ones listed (as many as fit 157 | reasonably) on the actual cover, and continue the rest onto adjacent 158 | pages. 159 | 160 | If you publish or distribute Opaque copies of the Document numbering 161 | more than 100, you must either include a machine-readable Transparent 162 | copy along with each Opaque copy, or state in or with each Opaque copy 163 | a computer-network location from which the general network-using 164 | public has access to download using public-standard network protocols 165 | a complete Transparent copy of the Document, free of added material. 166 | If you use the latter option, you must take reasonably prudent steps, 167 | when you begin distribution of Opaque copies in quantity, to ensure 168 | that this Transparent copy will remain thus accessible at the stated 169 | location until at least one year after the last time you distribute an 170 | Opaque copy (directly or through your agents or retailers) of that 171 | edition to the public. 172 | 173 | It is requested, but not required, that you contact the authors of the 174 | Document well before redistributing any large number of copies, to 175 | give them a chance to provide you with an updated version of the 176 | Document. 177 | 178 | 179 | 4. MODIFICATIONS 180 | 181 | You may copy and distribute a Modified Version of the Document under 182 | the conditions of sections 2 and 3 above, provided that you release 183 | the Modified Version under precisely this License, with the Modified 184 | Version filling the role of the Document, thus licensing distribution 185 | and modification of the Modified Version to whoever possesses a copy 186 | of it. In addition, you must do these things in the Modified Version: 187 | 188 | A. Use in the Title Page (and on the covers, if any) a title distinct 189 | from that of the Document, and from those of previous versions 190 | (which should, if there were any, be listed in the History section 191 | of the Document). You may use the same title as a previous version 192 | if the original publisher of that version gives permission. 193 | B. List on the Title Page, as authors, one or more persons or entities 194 | responsible for authorship of the modifications in the Modified 195 | Version, together with at least five of the principal authors of the 196 | Document (all of its principal authors, if it has fewer than five), 197 | unless they release you from this requirement. 198 | C. State on the Title page the name of the publisher of the 199 | Modified Version, as the publisher. 200 | D. Preserve all the copyright notices of the Document. 201 | E. Add an appropriate copyright notice for your modifications 202 | adjacent to the other copyright notices. 203 | F. Include, immediately after the copyright notices, a license notice 204 | giving the public permission to use the Modified Version under the 205 | terms of this License, in the form shown in the Addendum below. 206 | G. Preserve in that license notice the full lists of Invariant Sections 207 | and required Cover Texts given in the Document's license notice. 208 | H. Include an unaltered copy of this License. 209 | I. Preserve the section Entitled "History", Preserve its Title, and add 210 | to it an item stating at least the title, year, new authors, and 211 | publisher of the Modified Version as given on the Title Page. If 212 | there is no section Entitled "History" in the Document, create one 213 | stating the title, year, authors, and publisher of the Document as 214 | given on its Title Page, then add an item describing the Modified 215 | Version as stated in the previous sentence. 216 | J. Preserve the network location, if any, given in the Document for 217 | public access to a Transparent copy of the Document, and likewise 218 | the network locations given in the Document for previous versions 219 | it was based on. These may be placed in the "History" section. 220 | You may omit a network location for a work that was published at 221 | least four years before the Document itself, or if the original 222 | publisher of the version it refers to gives permission. 223 | K. For any section Entitled "Acknowledgements" or "Dedications", 224 | Preserve the Title of the section, and preserve in the section all 225 | the substance and tone of each of the contributor acknowledgements 226 | and/or dedications given therein. 227 | L. Preserve all the Invariant Sections of the Document, 228 | unaltered in their text and in their titles. Section numbers 229 | or the equivalent are not considered part of the section titles. 230 | M. Delete any section Entitled "Endorsements". Such a section 231 | may not be included in the Modified Version. 232 | N. Do not retitle any existing section to be Entitled "Endorsements" 233 | or to conflict in title with any Invariant Section. 234 | O. Preserve any Warranty Disclaimers. 235 | 236 | If the Modified Version includes new front-matter sections or 237 | appendices that qualify as Secondary Sections and contain no material 238 | copied from the Document, you may at your option designate some or all 239 | of these sections as invariant. To do this, add their titles to the 240 | list of Invariant Sections in the Modified Version's license notice. 241 | These titles must be distinct from any other section titles. 242 | 243 | You may add a section Entitled "Endorsements", provided it contains 244 | nothing but endorsements of your Modified Version by various 245 | parties--for example, statements of peer review or that the text has 246 | been approved by an organization as the authoritative definition of a 247 | standard. 248 | 249 | You may add a passage of up to five words as a Front-Cover Text, and a 250 | passage of up to 25 words as a Back-Cover Text, to the end of the list 251 | of Cover Texts in the Modified Version. Only one passage of 252 | Front-Cover Text and one of Back-Cover Text may be added by (or 253 | through arrangements made by) any one entity. If the Document already 254 | includes a cover text for the same cover, previously added by you or 255 | by arrangement made by the same entity you are acting on behalf of, 256 | you may not add another; but you may replace the old one, on explicit 257 | permission from the previous publisher that added the old one. 258 | 259 | The author(s) and publisher(s) of the Document do not by this License 260 | give permission to use their names for publicity for or to assert or 261 | imply endorsement of any Modified Version. 262 | 263 | 264 | 5. COMBINING DOCUMENTS 265 | 266 | You may combine the Document with other documents released under this 267 | License, under the terms defined in section 4 above for modified 268 | versions, provided that you include in the combination all of the 269 | Invariant Sections of all of the original documents, unmodified, and 270 | list them all as Invariant Sections of your combined work in its 271 | license notice, and that you preserve all their Warranty Disclaimers. 272 | 273 | The combined work need only contain one copy of this License, and 274 | multiple identical Invariant Sections may be replaced with a single 275 | copy. If there are multiple Invariant Sections with the same name but 276 | different contents, make the title of each such section unique by 277 | adding at the end of it, in parentheses, the name of the original 278 | author or publisher of that section if known, or else a unique number. 279 | Make the same adjustment to the section titles in the list of 280 | Invariant Sections in the license notice of the combined work. 281 | 282 | In the combination, you must combine any sections Entitled "History" 283 | in the various original documents, forming one section Entitled 284 | "History"; likewise combine any sections Entitled "Acknowledgements", 285 | and any sections Entitled "Dedications". You must delete all sections 286 | Entitled "Endorsements". 287 | 288 | 289 | 6. COLLECTIONS OF DOCUMENTS 290 | 291 | You may make a collection consisting of the Document and other 292 | documents released under this License, and replace the individual 293 | copies of this License in the various documents with a single copy 294 | that is included in the collection, provided that you follow the rules 295 | of this License for verbatim copying of each of the documents in all 296 | other respects. 297 | 298 | You may extract a single document from such a collection, and 299 | distribute it individually under this License, provided you insert a 300 | copy of this License into the extracted document, and follow this 301 | License in all other respects regarding verbatim copying of that 302 | document. 303 | 304 | 305 | 7. AGGREGATION WITH INDEPENDENT WORKS 306 | 307 | A compilation of the Document or its derivatives with other separate 308 | and independent documents or works, in or on a volume of a storage or 309 | distribution medium, is called an "aggregate" if the copyright 310 | resulting from the compilation is not used to limit the legal rights 311 | of the compilation's users beyond what the individual works permit. 312 | When the Document is included in an aggregate, this License does not 313 | apply to the other works in the aggregate which are not themselves 314 | derivative works of the Document. 315 | 316 | If the Cover Text requirement of section 3 is applicable to these 317 | copies of the Document, then if the Document is less than one half of 318 | the entire aggregate, the Document's Cover Texts may be placed on 319 | covers that bracket the Document within the aggregate, or the 320 | electronic equivalent of covers if the Document is in electronic form. 321 | Otherwise they must appear on printed covers that bracket the whole 322 | aggregate. 323 | 324 | 325 | 8. TRANSLATION 326 | 327 | Translation is considered a kind of modification, so you may 328 | distribute translations of the Document under the terms of section 4. 329 | Replacing Invariant Sections with translations requires special 330 | permission from their copyright holders, but you may include 331 | translations of some or all Invariant Sections in addition to the 332 | original versions of these Invariant Sections. You may include a 333 | translation of this License, and all the license notices in the 334 | Document, and any Warranty Disclaimers, provided that you also include 335 | the original English version of this License and the original versions 336 | of those notices and disclaimers. In case of a disagreement between 337 | the translation and the original version of this License or a notice 338 | or disclaimer, the original version will prevail. 339 | 340 | If a section in the Document is Entitled "Acknowledgements", 341 | "Dedications", or "History", the requirement (section 4) to Preserve 342 | its Title (section 1) will typically require changing the actual 343 | title. 344 | 345 | 346 | 9. TERMINATION 347 | 348 | You may not copy, modify, sublicense, or distribute the Document 349 | except as expressly provided under this License. Any attempt 350 | otherwise to copy, modify, sublicense, or distribute it is void, and 351 | will automatically terminate your rights under this License. 352 | 353 | However, if you cease all violation of this License, then your license 354 | from a particular copyright holder is reinstated (a) provisionally, 355 | unless and until the copyright holder explicitly and finally 356 | terminates your license, and (b) permanently, if the copyright holder 357 | fails to notify you of the violation by some reasonable means prior to 358 | 60 days after the cessation. 359 | 360 | Moreover, your license from a particular copyright holder is 361 | reinstated permanently if the copyright holder notifies you of the 362 | violation by some reasonable means, this is the first time you have 363 | received notice of violation of this License (for any work) from that 364 | copyright holder, and you cure the violation prior to 30 days after 365 | your receipt of the notice. 366 | 367 | Termination of your rights under this section does not terminate the 368 | licenses of parties who have received copies or rights from you under 369 | this License. If your rights have been terminated and not permanently 370 | reinstated, receipt of a copy of some or all of the same material does 371 | not give you any rights to use it. 372 | 373 | 374 | 10. FUTURE REVISIONS OF THIS LICENSE 375 | 376 | The Free Software Foundation may publish new, revised versions of the 377 | GNU Free Documentation License from time to time. Such new versions 378 | will be similar in spirit to the present version, but may differ in 379 | detail to address new problems or concerns. See 380 | http://www.gnu.org/copyleft/. 381 | 382 | Each version of the License is given a distinguishing version number. 383 | If the Document specifies that a particular numbered version of this 384 | License "or any later version" applies to it, you have the option of 385 | following the terms and conditions either of that specified version or 386 | of any later version that has been published (not as a draft) by the 387 | Free Software Foundation. If the Document does not specify a version 388 | number of this License, you may choose any version ever published (not 389 | as a draft) by the Free Software Foundation. If the Document 390 | specifies that a proxy can decide which future versions of this 391 | License can be used, that proxy's public statement of acceptance of a 392 | version permanently authorizes you to choose that version for the 393 | Document. 394 | 395 | 11. RELICENSING 396 | 397 | "Massive Multiauthor Collaboration Site" (or "MMC Site") means any 398 | World Wide Web server that publishes copyrightable works and also 399 | provides prominent facilities for anybody to edit those works. A 400 | public wiki that anybody can edit is an example of such a server. A 401 | "Massive Multiauthor Collaboration" (or "MMC") contained in the site 402 | means any set of copyrightable works thus published on the MMC site. 403 | 404 | "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0 405 | license published by Creative Commons Corporation, a not-for-profit 406 | corporation with a principal place of business in San Francisco, 407 | California, as well as future copyleft versions of that license 408 | published by that same organization. 409 | 410 | "Incorporate" means to publish or republish a Document, in whole or in 411 | part, as part of another Document. 412 | 413 | An MMC is "eligible for relicensing" if it is licensed under this 414 | License, and if all works that were first published under this License 415 | somewhere other than this MMC, and subsequently incorporated in whole or 416 | in part into the MMC, (1) had no cover texts or invariant sections, and 417 | (2) were thus incorporated prior to November 1, 2008. 418 | 419 | The operator of an MMC Site may republish an MMC contained in the site 420 | under CC-BY-SA on the same site at any time before August 1, 2009, 421 | provided the MMC is eligible for relicensing. 422 | 423 | 424 | ADDENDUM: How to use this License for your documents 425 | 426 | To use this License in a document you have written, include a copy of 427 | the License in the document and put the following copyright and 428 | license notices just after the title page: 429 | 430 | Copyright (c) YEAR YOUR NAME. 431 | Permission is granted to copy, distribute and/or modify this document 432 | under the terms of the GNU Free Documentation License, Version 1.3 433 | or any later version published by the Free Software Foundation; 434 | with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. 435 | A copy of the license is included in the section entitled "GNU 436 | Free Documentation License". 437 | 438 | If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, 439 | replace the "with...Texts." line with this: 440 | 441 | with the Invariant Sections being LIST THEIR TITLES, with the 442 | Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. 443 | 444 | If you have Invariant Sections without Cover Texts, or some other 445 | combination of the three, merge those two alternatives to suit the 446 | situation. 447 | 448 | If your document contains nontrivial examples of program code, we 449 | recommend releasing these examples in parallel under your choice of 450 | free software license, such as the GNU General Public License, 451 | to permit their use in free software. 452 | -------------------------------------------------------------------------------- /bgp-contd/README.md: -------------------------------------------------------------------------------- 1 | BGP, Part II 2 | ============ 3 | 4 | In [BGP, Part I](/bgp-intro/README.md), our knowledge of OSPF to manage routing details inside a network was extended with the ability to connect entire networks together, hiding the detailed topology of one network to the other. Since it was done with a single BGP connection between only two networks, it's time for something more extensive now. Let's throw more networks and some redundancy into the game: 5 | 6 | ![BGP network with redundant paths](/bgp-contd/bgp-redundancy.png) 7 | 8 | Hint: print this picture so you can make notes on it and keep it in sight during the tutorial! 9 | 10 | In the picture, we see three networks, which are connected by several links that use the BGP protocol to exchange routing information. I've deliberately kept the internal structure of the networks as simple as possible. 11 | * `AS65000` and `AS65010`, the left and right network, have a redundant link between them. When properly configured, this should make it possible to do maintenance on either of the two connections (e.g. shutting down `R0` and `R11`, or just one of them, or the physical link in between) without any interruption of network traffic between the two networks. 12 | * The links between `R0` and `R11`, and between `R1` and `R10` are high bandwidth, low latency links. 13 | * `AS65000` and `AS65010`, the two bigger networks, run OSPF inside, so that e.g. `R2` learns about the subnets that are used for the interconnects to the neighbour networks (to be able to resolve the the BGP next hop on `R2`). 14 | * `AS65020` is a smaller network, that has only a single gateway connecting it to the outside world. It's connected to both of the bigger networks with links that have a relatively lower bandwidth and higher latency. During the tutorial, we'll make adjustments to the configuration so `AS65020` can still reach both `AS65000` and `AS65010` when one of the external links is down. 15 | * Ah, and this time it's an IPv6 only example. 16 | 17 | ## Setting up the example network 18 | 19 | Well, you know the drill. :-) 20 | 21 | Thankfully, most of the configuration is provided already, so we can quickly set up this whole network using our LXC environment. Just like in the previous tutorials, the birdbase container can be cloned, after which the lxc network information and configuration inside the containers can be copied into them. 22 | 23 | 1. Clone this git repository somewhere to be able to use some files from the bgp-contd/lxc/ directory inside: 24 | 25 | cd ~ 26 | git clone https://github.com/knorrie/network-examples.git 27 | 28 | 2. lxc-copy the birdbase container several times: 29 | 30 | for router in 0 1 2 10 11 12 20; do lxc-copy -s -n birdbase -N R$router; done 31 | 32 | 3. Set up the network interfaces in the lxc configuration. This can be done by removing all network related configuration that remains from the cloned birdbase container, and then appending all needed interface configuration by running the fixnetwork.sh script that can be found in `bgp-contd/lxc/` in this git repository. Of course, have a look at the contents of the script first, before executing it. 33 | 34 | cd /var/lib/lxc 35 | ~/network-examples/bgp-contd/lxc/fixnetwork.sh 36 | 37 | 4. Copy extra configuration into the containers. The bgp-contd/lxc/ directory inside this git repository contains a little file hierarchy that can just be copied over the configuration of the containers. For each router, it's a network/interfaces configuration file whcih adds an IP address that corresponds with the Router ID to the loopback interface, and a simple BIRD configuration file that serves as a starting point for our next steps: 38 | 39 | cp ~/network-examples/bgp-contd/lxc/[RH]* . -r 40 | 41 | 5. Start all containers 42 | 43 | for router in 0 1 2 10 11 12 20; do echo "Starting R${router}..."; lxc-start -d -n R$router; sleep 2; done 44 | 45 | ## Looking around... 46 | 47 | There's a lot of bird config already in place, which looks like the Part I config, but multiple times for each connection. Take some time to browse through the bird6.conf files on all routers, so you can grasp the idea of how the configuration is set up. Hint: you can also do this from outside the lxc containers, so you can easily open multiple files and compare them. 48 | 49 | Note: some parts of the configuration are still missing, because we'll be adding them while doing the tutorial. If you can already spot something that is missing now, you receive some bonus points! :) 50 | 51 | ### ...from the viewpoint of R2 52 | 53 | `lxc-attach` to `R2` and verify the routes to the other two networks from there. It might take a few extra seconds after starting all the containers for them to figure out the complete network topology and set up all routing protocol sessions and exchange all routing information. 54 | 55 | * Do a `birdc6 show route` and `birdc6 show route all 2001:db8:10::/48`. 56 | * `traceroute 2001:db8:10::12` to `R12` in `AS65010` 57 | * Look at the route from `R2` to `R20`: `birdc6 show route all 2001:db8:20::/48` 58 | * `traceroute 2001:db8:20::20` to `R20` in `AS65020` 59 | 60 | The output of the commands should show that `R2` knows two different routes to `2001:db8:10::/48`. One of them gets chosen to end up in the linux kernel routing table (marked with the `*`), and the information about the route shows from which ibgp connection the route was learned. In my case here it's the route learned from the ibgp session `ibgp_r0` that gets chosen, but it might as well be the one via `R1` in your case. 61 | 62 | For traffic to `R20`, there's only one route shown from the viewpoint of `R2`, which is pointing to `R1`, since this is the only router in the local network that has a connection to the remote `AS65020`. 63 | 64 | ## Asymmetric traffic flows 65 | 66 | Since there are two active network paths between `AS65000` and `AS65010`, each of the networks is free to choose which connection to use to send traffic to the other network. 67 | 68 | Let's do some traceroute again, to look at traffic flow between `R2` and `R12`: 69 | 70 | root@R2:/# traceroute r12 71 | traceroute to r12 (2001:db8:10::12), 30 hops max, 80 byte packets 72 | 1 lan.r0 (2001:db8:0:1::ff) 0.384 ms 0.385 ms 0.389 ms 73 | 2 ebgp_r0.r11 (2001:db8:0:3::11) 0.565 ms 0.577 ms 0.490 ms 74 | 3 lo.r12 (2001:db8:10::12) 1.081 ms 1.012 ms 1.014 ms 75 | 76 | root@R12:/# traceroute r2 77 | traceroute to r2 (2001:db8::2), 30 hops max, 80 byte packets 78 | 1 lan.r10 (2001:db8:10:2::10) 0.292 ms 0.290 ms 0.369 ms 79 | 2 ebgp_r10.r1 (2001:db8:10:4::1) 0.435 ms 0.375 ms 0.392 ms 80 | 3 lo.r2 (2001:db8::2) 0.829 ms 0.785 ms 0.770 ms 81 | 82 | Thanks to the information in the `/etc/hosts` file in the containers, the output shows us the names of the network interfaces that correspond to the used addresses. 83 | 84 | As you can see, `R2` chooses to send traffic over `R0` as next hop, which will forward it to `R11` to get it into `AS65010`. In the meantime, traffic in the other direction chooses the path over `R10` and `R1`. When receiving traffic, a router has no idea of the path that a packet has traveled along before arriving. When sending traffic back, the router will just use its own thoughts about the best path towards that destination, which might mean choosing an outgoing network interface that is different from the one the packet it's responding to was received on. 85 | 86 | _Understanding asymmetric traffic flow is essential in the process of debugging network troubles in a larger network._ 87 | 88 | Let me give you an example why. Say, you're debugging latency on a connection to a remote host (look at the rtt measurements): 89 | 90 | root@R2:/# traceroute r12 91 | traceroute to r12 (2001:db8:10::12), 30 hops max, 80 byte packets 92 | 1 lan.r0 (2001:db8:0:1::ff) 0.389 ms 0.389 ms 0.398 ms 93 | 2 ebgp_r0.r11 (2001:db8:0:3::11) 0.614 ms 0.572 ms 0.525 ms 94 | 3 lo.r12 (2001:db8:10::12) 101.208 ms 101.121 ms 101.142 ms 95 | 96 | When you're not aware of the possibility of asymmetric traffic flows, you could incorrectly assume that there's a problem with the network link between `R11` and `R12`, because of the introduced extra latency. However, there might be multiple other possibilities, since you do not know which route the traffic from `R12` back to you takes. In our little example network we know, since we just found out by looking at it from both ends. It could as well be the link between `R12` and `R10`, or between `R10` and `R1`, or even between `R1` and `R2`... 97 | 98 | Let's have a look at a trace from the other end back to `R2`: 99 | 100 | root@R12:/# traceroute r2 101 | traceroute to r2 (2001:db8::2), 30 hops max, 80 byte packets 102 | 1 lan.r10 (2001:db8:10:2::10) 0.402 ms 0.341 ms 0.330 ms 103 | 2 ebgp_r10.r1 (2001:db8:10:4::1) 200.490 ms 200.472 ms 200.453 ms 104 | 3 lo.r2 (2001:db8::2) 101.053 ms 101.039 ms 101.020 ms 105 | 106 | Router `R10` can be reached just fine, but the next step (`ebgp_r10.r1` is the network interface on `R1` that is looking at `R10`) shows quite some introduced latency. Since the shortest route from `R1` back to `R12` is by sending it back to `R10` directly, the total round trip in the second step shows twice the amount of extra latency, while the total round trip time for reaching `R2` only shows the introduced latency once. 107 | 108 | Here's an edited version of the traceroute output, with the paths mentioned: 109 | 110 | root@R2:/# traceroute r12 111 | traceroute to r12 (2001:db8:10::12), 30 hops max, 80 byte packets 112 | 1 lan.r0 r2 -> r0 (ttl expired), r0 -> r2 113 | 2 ebgp_r0.r11 r2 -> r0 -> r11 (ttl expired), r11 -> r0 -> r2 114 | 3 lo.r12 r2 -> r0 -> r11 -> r12 (destination), r12 -> r10 -> r1 -> r2 115 | 116 | root@R12:/# traceroute r2 117 | traceroute to r2 (2001:db8::2), 30 hops max, 80 byte packets 118 | 1 lan.r10 r12 -> r10 (ttl expired), r0 -> 12 119 | 2 ebgp_r10.r1 r12 -> r10 -> r1 (ttl expired), r1 -> r10 -> r12 120 | 3 lo.r2 r12 -> r10 -> r1 -> r2 (destination), r2 -> r0 -> r11 -> r12 121 | 122 | Introducing latency for test purposes can be done with the linux traffic control tooling. Here's the two commands I just used on `R1` and `R10` to achieve the effect shown above: 123 | 124 | root@R1:/# tc qdisc add dev ebgp_r10 root netem delay 100ms 125 | root@R10:/# tc qdisc add dev ebgp_r1 root netem delay 100ms 126 | 127 | ## Playing with redundant paths 128 | 129 | Having redundancy in the network has the advantage that the network can survive a partial outage, which can be either planned (maintenance) or unplanned (failure of a component): 130 | 131 | ![BGP network with an inactive path](/bgp-contd/bgp-redundancy-ibgp-r0-r1.png) 132 | 133 | ### Moving around traffic 134 | 135 | By disabling the BGP session on `R0` towards `R11`, we can force traffic between `AS65000` and `AS65010` to choose the route over `R1` and `R10` instead: 136 | 137 | root@R0:/# birdc6 138 | BIRD 1.4.5 ready. 139 | 140 | bird> show protocols 141 | name proto table state since info 142 | kernel1 Kernel master up 15:07:17 143 | device1 Device master up 15:07:17 144 | ospf1 OSPF master up 15:07:17 Running 145 | static1 Static master up 15:07:17 146 | p_master_to_bgp Pipe master up 15:07:17 => t_bgp 147 | originate_to_r11 Static t_r11 up 15:07:17 148 | ebgp_r11 BGP t_r11 up 15:07:34 Established 149 | p_bgp_to_r11 Pipe t_bgp up 15:07:17 => t_r11 150 | ibgp_r2 BGP t_bgp up 15:08:17 Established 151 | 152 | bird> disable ebgp_r11 153 | ebgp_r11: disabled 154 | 155 | When doing some `mtr` from `R2` to `R12`, you can see the path switch over to the other connection, while disabling the eBGP session on `R0`: 156 | 157 | root@R2:/# mtr r12 158 | 159 | My traceroute [v0.85] 160 | R2 (::) Sun Nov 29 15:30:58 2015 161 | Keys: Help Display mode Restart statistics Order of fields quit 162 | Packets Pings 163 | Host Loss% Snt Last Avg Best Wrst StDev 164 | 1. 2001:db8:0:1::ff 0.0% 36 0.1 0.1 0.1 0.5 0.0 165 | 2001:db8:0:1::1 166 | 2. 2001:db8:0:3::11 0.0% 36 0.1 0.1 0.1 0.4 0.0 167 | 2001:db8:10:4::10 168 | 3. 2001:db8:10::12 0.0% 35 0.1 0.1 0.1 0.5 0.0 169 | 170 | Also, the bird6 log file in `/var/log/bird/bird6.log` shows that bird gets an update from the iBGP session to `R0` about the fact that the route to `2001:db8:10::/48` over `R0` should no longer be used, following by a replacement of the route in the linux kernel, pointing to `R1` instead: 171 | 172 | ibgp_r0 > removed [replaced] 2001:db8:10::/48 via fe80::4ef:8ff:fe02:cef6 on lan 173 | kernel1 < replaced 2001:db8:10::/48 via fe80::bc5d:a8ff:fee4:c062 on lan 174 | 175 | Note that shutting down a BGP session only will stop the exchange of routing information. The link itself is not disabled in this example. This means that if for whatever reason (like manual configuration of routes) traffic would arrive over this link, it would still happily be handled by the linux kernel. 176 | 177 | ### Fixing iBGP 178 | 179 | As I said a little earlier, there is still some configuration missing, although we didn't spot it yet it seems. Well, if you try to reach any router in `AS65010` from `R0`, you will see it fail: 180 | 181 | root@R0:/# traceroute r11 182 | traceroute to r11 (2001:db8:10::11), 30 hops max, 80 byte packets 183 | connect: Network is unreachable 184 | 185 | Also, `R20` is not reachable from `R0`, while the connection between `AS65000` and `AS65020` is still active... 186 | 187 | root@R0:/# traceroute r20 188 | traceroute to r20 (2001:db8:20::20), 30 hops max, 80 byte packets 189 | connect: Network is unreachable 190 | 191 | In the BGP introduction tutorial, we learned that iBGP sessions are used to share information about reachability of remote networks, outside of the own AS. By setting up an iBGP connection between `R2` and both `R0` and `R1`, we can make sure that `R2` is kept up to date about a path to external networks that are connected via `R0` and `R1`. However, the same has to be done between `R0` and `R1` to make sure that it knows an alternative route to the remote network `AS65010` when its own connection to it is down, and also knows to reach `AS65020` using `R1`. 192 | 193 | ### Assignments 194 | 195 | Now, do the following things: 196 | * Add iBGP configuration to share BGP routes between `R0` and `R1`, and also between `R10` and `R11`. Pay special attention to the `import` and `export` rules. Use e.g. `show route protocol ibgp_r0` on `R1` to verify that it's receiving information about external routes. 197 | 198 | bird> show route protocol ibgp_r0 199 | 2001:db8:10::/48 via fe80::4ef:8ff:fe02:cef6 on lan [ibgp_r0 23:24:03 from 2001:db8::ff] (100/20) [AS65010i] 200 | bird> show route export ibgp_r0 201 | 2001:db8:20::/48 via 2001:db8:0:5::20 on ebgp_r20 [ebgp_r20 2015-11-28] * (100) [AS65020i] 202 | 2001:db8:10::/48 via 2001:db8:10:4::10 on ebgp_r10 [ebgp_r10 2015-11-28] * (100) [AS65010i] 203 | 204 | * Check that you can reach every external network from every router in all of the three networks. You can use the script `bgp-contd/lxc/check_connectivity.sh` to check that every router can ping any other router. 205 | * Try disabling the link between `R0` and `R11`, by using the `disable`/`enable` commands on the bird command line, from either side. Check if you still can reach all parts of the network. Do the same for the link between `R1` and `R10`. If this succeeds your iBGP configuration is correct. 206 | * Change `import` and `export` filters in the `protocol bgp ebgp_r*` sections in `bird6.conf` so that you end up with a situation where all traffic is forced into an asymmetric traffic pattern in which traffic from `AS65000` to `AS65010` has to leave via `R1` to `R10`, and traffic back flows over `R11` to `R0`. Verify the changes seen in bird `show route all` output when you change filters. 207 | 208 | ## A closer look at the BIRD configuration 209 | 210 | Here's a picture of the tables and protocols used in the BIRD configuration of `R1`: 211 | 212 | ![BIRD protocols, tables, import and export](/bgp-contd/bird-prototable.png) 213 | 214 | As you might have noticed, I prefer using multiple internal routing tables in BIRD in favor of less complex filters. Since we're dealing with a very limited number of routes it's not a problem at all that a lot of routes are duplicated in multiple tables. 215 | 216 | If you compare this drawing to the previous one from the BGP Introduction tutorial, you'll notice an extra table, in between the eBGP sessions and the master table. Here's the corresponding part from `bird6.conf`: 217 | 218 | ############################################################################## 219 | # BGP table 220 | # 221 | 222 | # Use this routing table to gather external routes received via BGP which we 223 | # want push to the kernel via our master table and to other routers in our AS 224 | # via iBGP or even to other routers outside our AS again (transit), which can 225 | # be connected here or to a router elsewhere on the border of our AS. 226 | 227 | table t_bgp; 228 | 229 | protocol pipe p_master_to_bgp { 230 | table master; 231 | peer table t_bgp; 232 | import all; # default 233 | export none; # default 234 | } 235 | 236 | eBGP sessions are connected to `t_bgp` via an intermediate table for their own, which is used to insert routes that are originated from our own AS that we want to announce to the other side. iBGP sessions are connected to the `t_bgp` directly, as they just need to share the collection of externally learned routes with routers inside the network. 237 | 238 | ### Assignments 239 | 240 | * Compare the drawing with the configuration file of `R1`. 241 | 242 | ## Redundancy for the branch office: Transit traffic 243 | 244 | The following picture is the same as the one at the beginning of this page: 245 | 246 | ![BGP network with redundant paths](/bgp-contd/bgp-redundancy.png) 247 | 248 | Until now, we have ignored the top network, with `R20` in it. Let's have a better look at this part now. `AS65020` is connected to both of the other networks with a single connection. 249 | 250 | What would the result be for the connectivity of `AS65020` if one of those links would be down because of maintenance or a defect? We can do some tests to find out. 251 | 252 | First make sure you can reach `R20` from `R10`: 253 | 254 | root@R10:/# traceroute r20 255 | traceroute to r20 (2001:db8:20::20), 30 hops max, 80 byte packets 256 | 1 lan.r11 (2001:db8:10:2::11) 0.901 ms 0.883 ms 0.868 ms 257 | 2 lo.r20 (2001:db8:20::20) 0.897 ms 0.804 ms 0.803 ms 258 | 259 | Next, shut down eBGP between `R11` and `R20`, and see what happens... 260 | 261 | root@R11:/# birdc6 262 | BIRD 1.4.5 ready. 263 | bird> disable ebgp_r20 264 | ebgp_r20: disabled 265 | 266 | root@R10:/# traceroute r20 267 | traceroute to r20 (2001:db8:20::20), 30 hops max, 80 byte packets 268 | connect: Network is unreachable 269 | 270 | There's still an open network path to `R20`, via `R1`. But, `R10` is not aware of this, because the routers in `AS65000` do not tell the ones in `AS65010` that they also know a path to `R20`... 271 | 272 | root@R1:/# birdc6 273 | BIRD 1.4.5 ready. 274 | bird> show route table t_bgp 275 | 2001:db8:20::/48 via 2001:db8:0:5::20 on ebgp_r20 [ebgp_r20 20:47:42] * (100) [AS65020i] 276 | 2001:db8:10::/48 via 2001:db8:10:4::10 on ebgp_r10 [ebgp_r10 2015-11-28] * (100) [AS65010i] 277 | via fe80::4ef:8ff:fe02:cef6 on lan [ibgp_r0 2015-12-01 from 2001:db8::ff] (100/20) [AS65010i] 278 | bird> show route export ebgp_r10 279 | 2001:db8::/48 blackhole [originate_to_r10 2015-11-28] * (200) 280 | 281 | As seen above in the configuration diagram, the routers that connect to external networks in `AS65000` and `AS65010` collect all external routes in their BIRD `t_bgp` table, so they can be sent over iBGP to the other routers in their network. However, as you can see in the `bird6.conf` configuration files of them, the routes in `t_bgp` are not exported again to external peers. 282 | 283 | ### Assignments 284 | 285 | ![BGP Transit](/bgp-contd/bgp-redundancy-transit1.png) 286 | 287 | * Change the BIRD configuration of `R1` so that externally learned routes are exported again to other external networks. The routes are available in the `t_bgp` table, and can simply all be exported again towards `R10` and `R20`. Now check that you can already reach `R20` from `R10` with a traceroute, which means that `R20` also knows a path back to `R10` now: 288 | 289 | root@R10:/# traceroute r20 290 | traceroute to r20 (2001:db8:20::20), 30 hops max, 80 byte packets 291 | 1 ebgp_r10.r1 (2001:db8:10:4::1) 0.330 ms 0.317 ms 0.309 ms 292 | 2 lo.r20 (2001:db8:20::20) 0.441 ms 0.432 ms 0.405 ms 293 | 294 | * In the logfiles in `/var/log/bird/bird6.log` on `R20`, `R1` and `R10` you should see that the extra routing information was received, and how bird processed the routes internally. Pay some attention to the 'ignored', 'filtered' and 'rejected by protocol' lines. They show that the defined filters are used, and they also show that bird will by default be clever about not pushing routes back through a pipe or protocol it just learned them from, which simplifies the filter definitions a lot, since we can just use 'all' for exporting from `t_bgp` to e.g. `t_r20`. 295 | * On `R1`, check `show route export ebgp_r10` and `show route export ebgp_r20`. 296 | * Adjust the other three routers in the same way: `R0`, `R10` and `R11`. Don't change `R20`, since we do not want `AS65020`, with its two slow low-bandwith links to be a transit area for traffic between `AS65000` and `AS65010`. Those two networks already have fast redundant links between them. 297 | * Enable the BGP session between `R11` and `R20` again, and notice that the routing immediately switches back to using this path. 298 | * Disable the network path between `R1` and `R20`, and make sure you can still reach `R20` from `R2`. 299 | 300 | ### Extra assignment 301 | 302 | Instead of disabling a whole BGP session between routers to stop using a particular path, it's also possible to keep the BGP connection alive, and just stop originating prefixes or re-announcing them if we're a transit network, but still accept them from the remote or just the other way around. When doing so we can configure a situation with an asymmetric traffic flow. 303 | 304 | ![BGP Transit fun assignment](/bgp-contd/bgp-redundancy-transit2.png) 305 | 306 | * Without disabling any BGP session, change the filters configuration so that traffic flow between `R10` and `R20` is as shown in the picture above: 307 | 308 | root@R10:/# traceroute r20 309 | traceroute to r20 (2001:db8:20::20), 30 hops max, 80 byte packets 310 | 1 lan.r11 (2001:db8:10:2::11) 0.068 ms 0.018 ms 0.016 ms 311 | 2 ebgp_r11.r0 (2001:db8:0:3::ff) 0.380 ms 0.356 ms 0.341 ms 312 | 3 ebgp_r10.r1 (2001:db8:10:4::1) 0.462 ms 0.458 ms 0.388 ms 313 | 4 lo.r20 (2001:db8:20::20) 0.401 ms 0.409 ms 0.435 ms 314 | 315 | root@R20:/# traceroute r10 316 | traceroute to r10 (2001:db8:10::10), 30 hops max, 80 byte packets 317 | 1 ebgp_r20.r11 (2001:db8:10:6::11) 0.073 ms 0.019 ms 0.018 ms 318 | 2 lo.r10 (2001:db8:10::10) 0.320 ms 0.268 ms 0.245 ms 319 | 320 | * Notice that this is actually a stupid way to prefer specific routes for traffic, because by disabling BGP sessions or by not announcing or not accepting routes, we reduce redundancy in the network, because the disabled paths also do not function as less-preferable path any more. See BGP route selection below for more thoughts about this. 321 | 322 | ## Bonus material 323 | 324 | Now you've learned the basics of building a network with BGP, you should be able to better understand the average "BGP introduction" page published on the Internet that immediately tries to overwhelm you with technical terms instead of just providing an example. ;-] 325 | 326 | The following topics are also a minimal set of hints for further study: 327 | 328 | ### Peering and Transit 329 | 330 | In the above examples, we've already seen the difference between just connecting two networks so they can reach each other, and on top of that, forwarding route announcements, so that a network can act as transit area for traffic between two other networks. These concepts are called "Peering" and "Transit" and if you search for them, you should be able to find a lot more information. 331 | 332 | The next page of this tutorial, [Routing on the internet](/the-internet/README.md), will be about discovering the fact that with the limited knowledge we have now, it's already possible to understand how the whole internet works together. The page hasn't been written yet, but will show how networks of ISPs, Transit Providers and Internet Exchanges connect the whole world together and how you can find out using tools on the internet how they're connected, and how they provide a path between your own computer to every remote destination on the internet you're connecting to every day. 333 | 334 | ### BGP route selection 335 | 336 | As hinted above ("Notice that this is actually a stupid way...") there are smarter ways to prefer specific network paths for specific routes than to just disable a path or stop accepting announcements. BGP has a bunch of knobs to adjust that you can combine to create a routing policy inside your own AS. 337 | 338 | In the BIRD documentation about BGP, you can find a list about "Route selection rules" that BIRD applies to select which BGP route to a particular destination will be chosen if multiple ones are available for the same prefix: 339 | 340 | * Prefer route with the highest Local Preference attribute. 341 | * Prefer route with the shortest AS path. 342 | * Prefer IGP origin over EGP and EGP origin over incomplete. 343 | * Prefer the lowest value of the Multiple Exit Discriminator. 344 | * Prefer routes received via eBGP over ones received via iBGP. 345 | * Prefer routes with lower internal distance to a boundary router. 346 | * Prefer the route with the lowest value of router ID of the advertising router. 347 | 348 | Using other resources on the internet you should be able to find out what all of these mean. Using the BIRD documentation, you can change the configuration of all routers in our example network to route traffic around in different ways using these options. 349 | 350 | Within a single AS, it's really important to have a single policy, so that all routers are on the same page about where to send traffic. You cannot have two border routers, which independently from each other determine that the other one should be used as exit point to a specific external peer. They would pingpong all traffic between them until the IP packet TTL expires and then drop the traffic, resulting in a big black hole and a bunch of overloaded internal connections. So, yes, this can get quite complex quickly if you start to make customizations. 351 | 352 | Remember that we started this tutorial with an example network in which traffic between `AS65000` and `AS65010` was already using the two paths between them in an asymmetric way. Because the setup of both networks is so similar and mirrored, the fact that traffic back and forth flows asymmetrically is actually thanks to the last rule: "Prefer the route with the lowest value of router ID of the advertising router.". After initially setting up the example, I had to swap `R10` and `R11` again to get this behaviour. :-) 353 | 354 | # Cleaning up 355 | 356 | Make sure you preserve the configs that you wrote if you want to have a look at them later. Then, we can stop and remove everything: 357 | 358 | for router in 0 1 2 10 11 12 20; do lxc-stop -n R$router; lxc-destroy -n R$router; sleep 2; done 359 | -------------------------------------------------------------------------------- /ospf-intro/README.md: -------------------------------------------------------------------------------- 1 | OSPF 2 | ==== 3 | 4 | In this tutorial, I'll explain a bit about how the OSPF routing protocol works, followed by a full hands-on tutorial to practice and see it in action yourself! 5 | 6 | In the [previous page of this tutorial series](/birdhouse-vlans-vpn/README.md), we met the Birdhouse Factory sysadmin Carl, who was about to get a little depressed about the amount of manual work he needed to do to get his newly created set of routers forward traffic into the right direction. He wondered if there would be a better way to do this, having the routers just tell each other what traffic should go where. 7 | 8 | Luckily, such a thing actually exists. Instead of programming all routers in detail with the next hop for each possible subnet that exists in the network, it's possible to let the routers figure this out themselves. 9 | 10 | ## Step one: separate routers with interfaces 11 | 12 | The network in this tutorial has four routers. Each of these routers has connections to multiple networks: 13 | 14 | ![OSPF network, separate](/ospf-intro/ospf-separate.png) 15 | 16 | Each of the four routers is shown as a little "card" with information on it, which contains: 17 | 18 | * A unique IP address-like number (in bold), which is a so called 'Router ID'. 19 | * Several interfaces, which are connected to different subnets, having a unique address in each of those subnets. 20 | * A "stub" sign that is either missing or present on the interface. 21 | 22 | If the network is a "stub", it's like a dead end road, and we expect that the network contains end hosts (like servers and workstations), but no other routers. If the network is not a stub, we consider it a network where other routers are present, and usually no end hosts. 23 | 24 | So what's different between the network drawings of the Birdhouse Factory that we've seen in the previous tutorials? On the last page, we learned that sysadmin Carl had designed the whole network on paper first, and then had to program all routes to other networks into each router in the network. The image above looks like the complete opposite. We have four routers, and each of them only knows about its directly connected subnets, and has no idea at all about the existence of the other three routers. This seems strange, but it's an ideal starting point for a dynamic routing protocol like OSPF. The topology of an OSPF network is not laid out in advance. The network completely discovers itself "on the go". 25 | 26 | ## Step two: activating OSPF, discovering network topology 27 | 28 | When looking at the picture with the four separate routers, you should already have noticed that some of the interfaces of different routers share the same subnet. For example, `10.0.1.5` of R1 and `10.0.1.4` of R5 are in the same subnet, and connected to the same vlan. This means they should be able to communicate with each other. Only, they don't know about each other yet. 29 | 30 | *Warning: the following is a grossly oversimplified description of the OSPF discovery process, but just enough to grasp the basics that we need to know before trying it.* 31 | 32 | ### Discovering local neighbours 33 | 34 | To discover which routers can directly see each other, the following is being done by them: 35 | 36 | * Send out Hello! packets, describing themselves (containing, most importantly, their Router ID) on all interfaces that actively participate in the OSPF network (so all non-stub interfaces). 37 | * Listen for Hello! packets from other routers, to learn who else is active out there. 38 | 39 | ![OSPF network with discovered neighbours](/ospf-intro/ospf-neighbours.png) 40 | 41 | Now, the upper part of the network contains three routers which know they are neighbours, as does the lower part. But, router 2 and 6 do not know about each other's existence yet. 42 | 43 | ### Discovering the full network topology 44 | 45 | To discover the full topology of the network, the following happens: 46 | * Send out the complete information card of the router itself, with all information of active "links" that the router has to all neighbours. 47 | * Receive the same information from neighbour routers. 48 | * When an information card of a router arrives, store it, and send it out again on all other interfaces that are not a stub, unless the information of this particular router was already received before. 49 | 50 | And magically... After a short burst of network traffic, all routers have now received each other's information, and are in possession of the four cards with information. Now that each router has all information about the other ones, let's see what happens when we simply connect the information about the four different routers together, turning the shared subnet ranges into a subnet between the routers: 51 | 52 | ![OSPF network, joined together](/ospf-intro/ospf-together.png) 53 | 54 | And now here's a very important characteristic of the OSPF protocol: *Each* of the four routers can do this, and each of them now has an overview of the complete topology of the network! And, all of them have the *exact* same one. 55 | 56 | ## Step three: figuring out shortest paths and determining next-hops 57 | 58 | Now that each router has gathered enough information to assemble a complete detailed map of the complete network, the meaning of the abbreviation OSPF comes into play. OSPF means "Open Shortest Path First". Using the details of the network topology map, it's possible to find out the shortest path to every subnet that exists in the network (being stub or not). If you want to know how this is done, look up the Dijkstra's algorithm, which is the mathematical algorithm that is used by OSPF. 59 | 60 | While each router can determine the complete shortest path to any destination in the network, it might sound quite disappointing to know that most of this valuable information can not be used by any individual router to get an IP packet to its destination. 61 | 62 | * First of all, the routing software (for which BIRD will be used in these tutorials) is not in charge of the forwarding of packets itself (which is done by the Linux kernel in these examples). This difference is well known as the difference between a "Control Plane" and a "Forwarding Plane", which have nothing to do with aircrafts. 63 | * The routing software (control plane) has to program the kernel (forwarding plane) with a next hop router for each existing subnet in the network, and it can not provide more information than just that next hop, which has to be in a directly connected subnet. So the OSPF routing process knows much more about the path that the to be forwarded packet will travel than it is able to tell the forwarding path. 64 | 65 | And why shouldn't we care too much about all of this? The fun part here is that each of the participating routers in the OSPF network knows exactly the same amount of information about the whole network topology, and uses the same way to calculate the shortest routes from itself to all subnets that exist in the network. So, it's not a problem at all that the OSPF process on R2 can only tell the linux kernel to forward packets for `10.34.2.89` to a next hop of `10.1.2.56`, because it can trust on the fact that R5 will always forward them again to `10.0.1.8`, having R6 receive them, which will drop them into the connected subnet to reach the end host in there. 66 | 67 | If you're confused now, don't worry. Take a short break and continue with the hands-on part to see it all happen! After doing so, re-read the above, which should probably make more sense then. 68 | 69 | If you're not confused yet, here's some bonus information to think about: To make it even worse, the IP address of this next hop is not even used when actually forwarding a packet to the next router! It's only being used to determine the layer 2 mac address of the interface of the next hop. :-) An IP packet contains a source and a destination IP address. It does not contain a list of routers that it needs to pass before reaching its destination. It does not even contain the address of the very first next hop that it needs to go to, and the receiving next router has no idea where the packet it just received has been, or which IP address was used to forward it. It only sees the mac address of the sending router. 70 | 71 | # Hands on! 72 | 73 | Enough of this theoretical babble! Let's create the network ourselves, using some linux containers and vlans with openvswitch! 74 | 75 | Ok, first of all, to be honest, the stub links still look a bit sad, so let's connect a host to them, which we will use later, when we'll actually building the network, to execute tests between them to see if they can reach each other, and if so, using what route over the network: 76 | 77 | ![OSPF network, joined together with some hosts](/ospf-intro/ospf-together-hosts.png) 78 | 79 | ## Building the containers 80 | 81 | Let's build some containers! If you don't have [a lab environment](/lxcbird/README.md) with a template 'birdbase' container yet, create it! 82 | 83 | To create the eight containers we need, connected together in different networks, the following steps are needed: 84 | 85 | 1. Clone this git repository somewhere to be able to use some files from the ospf-intro/lxc/ directory inside: 86 | 87 | cd ~ 88 | git clone https://github.com/knorrie/network-examples.git 89 | 90 | 2. lxc-copy the birdbase container several times: 91 | 92 | lxc-copy -s -n birdbase -N R1 93 | lxc-copy -s -n birdbase -N R2 94 | lxc-copy -s -n birdbase -N R5 95 | lxc-copy -s -n birdbase -N R6 96 | lxc-copy -s -n birdbase -N H12 97 | lxc-copy -s -n birdbase -N H10 98 | lxc-copy -s -n birdbase -N H8 99 | lxc-copy -s -n birdbase -N H5 100 | 101 | 3. Set up the network interfaces in the lxc configuration. This can be done by removing all network related configuration that remains from the cloned birdbase container, and then appending all needed interface configuration by running the fixnetwork.sh script that can be found in `ospf-intro/lxc/` in this git repository. Of course, have a look at the contents of the script first, before executing it. Since this example is only using IPv4 and single IP addresses on the interfaces, I simply added them to the lxc configuration instead of the network/interfaces file inside the container. 102 | 103 | cd /var/lib/lxc 104 | ~/network-examples/ospf-intro/lxc/fixnetwork.sh 105 | 106 | 4. Copy extra configuration into the containers. The ospf-intro/lxc/ directory inside this git repository contains a little file hierarchy that can just be copied over the configuration of the containers. For each router, it's a network/interfaces configuration file which adds an IP address that corresponds with the Router ID to the loopback interface, and a simple BIRD configuration file that serves as a starting point for our next steps. 107 | 108 | cp ~/network-examples/ospf-intro/lxc/[RH]* . -r 109 | 110 | 5. Start all containers 111 | 112 | for router in 1 2 5 6; do lxc-start -d -n R$router; sleep 2; done 113 | for host in 12 10 8 5; do lxc-start -d -n H$host; sleep 2; done 114 | 115 | 6. Verify connectivity and look around a bit. Here's an example for R1: 116 | 117 | lxc-attach -n R1 118 | 119 | root@R1:/# 120 | root@R1:/# ip a 121 | 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default 122 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 123 | inet 127.0.0.1/8 scope host lo 124 | valid_lft forever preferred_lft forever 125 | inet 10.9.99.1/32 scope global lo 126 | valid_lft forever preferred_lft forever 127 | inet6 ::1/128 scope host 128 | valid_lft forever preferred_lft forever 129 | 247: vlan1001: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 130 | link/ether 02:00:0a:00:01:05 brd ff:ff:ff:ff:ff:ff 131 | inet 10.0.1.5/24 brd 10.0.1.255 scope global vlan1001 132 | valid_lft forever preferred_lft forever 133 | inet6 fe80::aff:fe00:105/64 scope link 134 | valid_lft forever preferred_lft forever 135 | 249: vlan1012: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 136 | link/ether 02:00:0a:01:02:07 brd ff:ff:ff:ff:ff:ff 137 | inet 10.1.2.7/24 brd 10.1.2.255 scope global vlan1012 138 | valid_lft forever preferred_lft forever 139 | inet6 fe80::aff:fe01:207/64 scope link 140 | valid_lft forever preferred_lft forever 141 | 251: vlan1356: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 142 | link/ether 02:00:0a:03:38:01 brd ff:ff:ff:ff:ff:ff 143 | inet 10.3.56.1/24 brd 10.3.56.255 scope global vlan1356 144 | valid_lft forever preferred_lft forever 145 | inet6 fe80::aff:fe03:3801/64 scope link 146 | valid_lft forever preferred_lft forever 147 | 148 | root@R1:/# ip r 149 | 10.0.1.0/24 dev vlan1001 proto kernel scope link src 10.0.1.5 150 | 10.1.2.0/24 dev vlan1012 proto kernel scope link src 10.1.2.7 151 | 10.3.56.0/24 dev vlan1356 proto kernel scope link src 10.3.56.1 152 | 153 | root@R1:/# ping -c 3 10.3.56.8 154 | PING 10.3.56.8 (10.3.56.8) 56(84) bytes of data. 155 | 64 bytes from 10.3.56.8: icmp_seq=1 ttl=64 time=0.545 ms 156 | 64 bytes from 10.3.56.8: icmp_seq=2 ttl=64 time=0.084 ms 157 | 64 bytes from 10.3.56.8: icmp_seq=3 ttl=64 time=0.078 ms 158 | 159 | --- 10.3.56.8 ping statistics --- 160 | 3 packets transmitted, 3 received, 0% packet loss, time 1998ms 161 | rtt min/avg/max/mdev = 0.078/0.235/0.545/0.219 ms 162 | root@R1:/# 163 | 164 | root@R1:/# traceroute 10.34.2.5 165 | traceroute to 10.34.2.5 (10.34.2.5), 30 hops max, 60 byte packets 166 | connect: Network is unreachable 167 | 168 | Looking good! :-) Feel free to test some more and by attaching to the console of containers and playing around. 169 | 170 | ## Basic BIRD configuration 171 | 172 | To be able to use the OSPF routing protocol, we need to run a program on each router that implements it. BIRD, the BIRD Internet Routing Daemon is one of those and I'll be using it for all examples and tutorials here. 173 | 174 | Let's have a look at the BIRD configuration of R6: 175 | 176 | # cat R6/rootfs/etc/bird/bird.conf 177 | router id 10.9.99.6; 178 | 179 | log "/var/log/bird/bird.log" all; 180 | debug protocols { states, routes, filters, interfaces } 181 | 182 | protocol kernel { 183 | import none; 184 | export all; 185 | } 186 | 187 | protocol device { 188 | # defaults... 189 | } 190 | 191 | This is a really basic BIRD configuration: 192 | 193 | * The Router ID is set to a unique value in the network, which is 10.9.99.6 for this router. Actually, this is not an IP address. It's just a 32 bit value, but it's written in the same notation we use for IPv4 address, instead of 0x0a096306 or 168387334. 194 | * A kernel protocol. This is not a real routing protocol, but it's the way BIRD uses to export route information from the internal BIRD routing table to the Linux kernel (remember, the control plane programs the forwarding plane). The filters are set to export all routes that BIRD will be learning from other routers to the Linux kernel routing table, which is fine for now. 195 | * A device protocol. This is also not a real routing protocol, but the way BIRD uses to import information about the local network interfaces that are already present in this routers. Usually this is added to your BIRD configuration and just sits there, doing its thing. 196 | 197 | As you have seen above, all of the routers currently only see their connected subnets. R1 which was used as an example above has no idea how to reach a computer with IP address 10.34.2.5, because it has no available route to a network this address is in: 198 | 199 | root@R1:/# ip r 200 | 10.0.1.0/24 dev vlan1001 proto kernel scope link src 10.0.1.5 201 | 10.1.2.0/24 dev vlan1012 proto kernel scope link src 10.1.2.7 202 | 10.3.56.0/24 dev vlan1356 proto kernel scope link src 10.3.56.1 203 | 204 | `ip r` shows the Linux kernel route table, which is used to actually forward packets. The BIRD process has its own internal routing table, which can also be shown: 205 | 206 | root@R1:/# birdc show route 207 | BIRD 1.4.5 ready. 208 | root@R1:/# 209 | 210 | Well, actually it's still empty now. :-) 211 | 212 | birdc is a little program which connects to a running BIRD process for diagnostics and like manipulation of the running protocols, like disabling or enabling them: 213 | 214 | root@R1:/# birdc 215 | BIRD 1.4.5 ready. 216 | bird> show route 217 | bird> show ? 218 | show bfd ... Show information about BFD protocol 219 | show interfaces Show network interfaces 220 | show memory Show memory usage 221 | show ospf ... Show information about OSPF protocol 222 | show protocols [ | ""] Show routing protocols 223 | show roa ... Show ROA table 224 | show route ... Show routing table 225 | show static [] Show details of static protocol 226 | show status Show router status 227 | show symbols ... Show all known symbolic names 228 | bird> show status 229 | BIRD 1.4.5 230 | Router ID is 10.9.99.1 231 | Current server time is 2015-06-07 00:51:52 232 | Last reboot on 2015-06-07 00:02:37 233 | Last reconfiguration on 2015-06-07 00:43:57 234 | Daemon is up and running 235 | bird> 236 | bird> show protocols 237 | name proto table state since info 238 | kernel1 Kernel master up 00:02:37 239 | device1 Device master up 00:02:37 240 | 241 | ## Configuring OSPF 242 | 243 | The moment we've all been waiting for! Add the following to bird.conf of R6. Editing the bird.conf file can be done from outside the container. 244 | 245 | protocol ospf { 246 | area 0 { 247 | interface "lo" { 248 | stub; 249 | }; 250 | interface "vlan1001" { 251 | }; 252 | interface "vlan1034" { 253 | stub; 254 | }; 255 | }; 256 | } 257 | 258 | Now, tell BIRD to reload the configuration: 259 | 260 | root@R6:/# birdc 261 | BIRD 1.4.5 ready. 262 | bird> configure 263 | Reading configuration from /etc/bird/bird.conf 264 | Reconfigured 265 | 266 | An OSPF protocol instance has been started now, which has been provided with information that closely relates to the little "router information cards" seen earlier: 267 | 268 | ![OSPF R6](/ospf-intro/ospf-r6.png) 269 | 270 | The interface in network `10.0.1.0/24` has been configured as active OSPF interface. The interface in `10.34.2.0/24` is a stub, and also the Linux loopback interface has been specified as stub, causing the `10.9.99.6/32` address that is present on the loopback interface to be included in the OSPF process. 271 | 272 | After starting OSPF, the Linux kernel routing table still looks unchanged, but the routing table inside BIRD has changed: 273 | 274 | root@R6:/# ip r 275 | 10.0.1.0/24 dev vlan1001 proto kernel scope link src 10.0.1.8 276 | 10.34.2.0/24 dev vlan1034 proto kernel scope link src 10.34.2.1 277 | 278 | root@R6:/# birdc show route 279 | BIRD 1.4.5 ready. 280 | 10.0.1.0/24 dev vlan1001 [ospf1 00:58:01] * I (150/10) [10.9.99.6] 281 | 10.9.99.6/32 dev lo [ospf1 00:58:01] * I (150/0) [10.9.99.6] 282 | 10.34.2.0/24 dev vlan1034 [ospf1 00:58:01] * I (150/10) [10.9.99.6] 283 | 284 | Since BIRD has been told which interfaces are participating in the OSPF protocol, it has been able to determine which network ranges are active on those interfaces. When talking to other OSPF routers, this is the information that will be sent to them in the R6 information message! 285 | 286 | There are more useful commands to show what R6 is currently seeing in the OSPF network: 287 | 288 | bird> show ospf topology 289 | 290 | area 0.0.0.0 291 | 292 | router 10.9.99.6 293 | distance 0 294 | bird> show ospf neighbors 295 | ospf1: 296 | Router ID Pri State DTime Interface Router IP 297 | 298 | Only, the output is not very exciting, because apparently there are no other routers available yet which can answer the Hellos that R6 is sending onto vlan1001... 299 | 300 | ## A second OSPF router, or more! 301 | 302 | The inevitable must happen. Right now, you should know enough to be able to configure OSPF on R1 as well, which has two active OSPF interfaces, the stub interface which connects to the network with H8, and of course the loopback interface. 303 | 304 | Go ahead, do it, now! 305 | 306 | After adding the configuration and making BIRD reload it, `birdc show protocols` should show an active OSPF protocol. Now, just wait for a few seconds and do `ip r` again on R6, which shows us the routing table that is actually used by the forwarding process: 307 | 308 | root@R6:/# ip r 309 | 10.0.1.0/24 dev vlan1001 proto kernel scope link src 10.0.1.8 310 | 10.1.2.0/24 via 10.0.1.5 dev vlan1001 proto bird 311 | 10.3.56.0/24 via 10.0.1.5 dev vlan1001 proto bird 312 | 10.9.99.1 via 10.0.1.5 dev vlan1001 proto bird 313 | 10.34.2.0/24 dev vlan1034 proto kernel scope link src 10.34.2.1 314 | 315 | In the interactive BIRD console, `show route` can be used to see the view that BIRD has on the network. You can see that the three routes that have nexthop `10.0.1.5` were learned from router `10.9.99.1`, which is the Router ID of R1. 316 | 317 | bird> show route 318 | 10.0.1.0/24 dev vlan1001 [ospf1 2015-06-07] * I (150/10) [10.9.99.6] 319 | 10.1.2.0/24 via 10.0.1.5 on vlan1001 [ospf1 22:51:52] * I (150/20) [10.9.99.1] 320 | 10.3.56.0/24 via 10.0.1.5 on vlan1001 [ospf1 2015-06-07] * I (150/20) [10.9.99.1] 321 | 10.9.99.1/32 via 10.0.1.5 on vlan1001 [ospf1 2015-06-07] * I (150/10) [10.9.99.1] 322 | 10.9.99.6/32 dev lo [ospf1 2015-06-07] * I (150/0) [10.9.99.6] 323 | 10.34.2.0/24 dev vlan1034 [ospf1 2015-06-07] * I (150/10) [10.9.99.6] 324 | 325 | I guess it's not very useful any more to continue typing much more text in this tutorial page now, because I'm quite surely losing your attention. :-D Just go ahead, and configure OSPF on the other two routers and see what happens. One fun thing to do is to start a `watch ip r` on R6 and see live changes of what will happen while you're working on the other routers. 326 | 327 | When enabling OSPF on all four routers, you should be able to reach anything from anything in the whole network. 328 | 329 | root@H12:/# traceroute -n 10.34.2.5 330 | traceroute to 10.34.2.5 (10.34.2.5), 30 hops max, 60 byte packets 331 | 1 10.50.1.1 0.199 ms 0.227 ms 0.119 ms 332 | 2 10.1.2.56 0.238 ms 0.234 ms 0.284 ms 333 | 3 10.0.1.8 0.283 ms 0.282 ms 0.332 ms 334 | 4 10.34.2.5 0.310 ms 0.389 ms 0.246 ms 335 | 336 | Or... 337 | 338 | root@H12:/# mtr -n -c 3 -r 10.3.56.8 339 | Start: Sun Jun 7 01:46:49 2015 340 | HOST: H12 Loss% Snt Last Avg Best Wrst StDev 341 | 1.|-- 10.50.1.1 0.0% 3 0.1 0.2 0.1 0.3 0.0 342 | 2.|-- 10.1.2.7 0.0% 3 0.1 0.2 0.1 0.3 0.0 343 | 3.|-- 10.3.56.8 0.0% 3 0.1 0.2 0.1 0.4 0.0 344 | 345 | ## More Dynamics! 346 | 347 | There's two more topics I want to cover before ending this tutorial. The first one is how the network will handle changes in the availability of paths. 348 | 349 | Attach to H12 and start an `mtr -n 10.34.2.5`. In my case here, it shows a path via `10.50.1.1` (R2), `10.1.2.56` (R5) and `10.0.1.8` (R6). Now, just for fun, do an `ip link set down vlan1012` on R5 if your traceroute shows the same path, or if the route is over R1, just down an interface on R1 instead, and look what's happening to your running mtr output. Doing this is equivalent to pulling a network cable out of a network port of a "real" router. 350 | 351 | Here's mine: 352 | 353 | My traceroute [v0.85] 354 | H12 (0.0.0.0) Sun Jun 7 01:56:35 2015 355 | Keys: Help Display mode Restart statistics Order of fields quit 356 | Packets Pings 357 | Host Loss% Snt Last Avg Best Wrst StDev 358 | 1. 10.50.1.1 0.0% 230 0.1 0.1 0.1 0.4 0.0 359 | 2. 10.1.2.56 0.9% 230 0.1 0.1 0.1 0.3 0.0 360 | 10.1.2.7 361 | 3. 10.0.1.8 0.9% 230 0.1 0.1 0.1 0.4 0.0 362 | 4. 10.34.2.5 0.9% 230 0.1 0.1 0.1 0.4 0.0 363 | 364 | ![OSPF network, reconvergence](/ospf-intro/ospf-together-hosts-linkdown.png) 365 | 366 | When I disabled the interface on R5, BIRD on R5 got notified by netlink that the interface went down. OSPF on R5 had to change its information card immediately and send it out again. But... it was only able to send it out on the `10.0.1.0/24` network. So it did, and R1 and R6 received it. Since R1 had not seen an update on the lower side of the network, it notified routers in there of the change and R2 was able to recalculate the shortest paths to the entire network after changing its view of the complete network topology with the missing link between R5 and the `10.1.2.0/24` network. After doing so, R2 determined that the current open shortest path to `10.34.2.5` had to be via `10.1.2.7` and used the BIRD kernel protocol to retract the route to `10.34.2.0/24` via `10.1.2.56` and inserted a new route into the Linux kernel routing table which points to `10.1.2.7` as next hop for `10.34.2.0/24`. And then, mtr noticed there was a change in the path. 367 | 368 | Apparently, I lost a ping while the network was busy to get into a stable converged state again. ;-( 369 | 370 | ## The loopback address 371 | 372 | The second thing I want to point out is about the /32 addresses on the loopback interfaces of the routers. I figure you might be wondering what they're useful for. Well, normally, a /32 address on a network interface would not make much sense. But imagine what happens when we include it in our OSPF process... It suddenly becomes a network subnet whose reachability information is propagated throughout the whole network. Ok, this subnet can only contain a single address, but it's a perfect way to make sure that if any path exists to this single router in the network, OSPF will make you able to use it to connect to the router. So, if I'm the network administrator of the example network we've just built, and `10.50.1.12` is my workstation, I can use `10.9.9.5` to connect to, for example with SSH, to manage this router. Even when I accidentally would disable the link to the `10.1.2.0/24` network, my SSH session would simply stay active, the traffic to and from R5 being rerouted via R1 back to my workstation... :-D Later on, in the BGP tutorial we'll see that there are actually other routing protocols that rely on this mechanism to function correctly. 373 | 374 | ## Next... 375 | 376 | There are numerous pages with information about OSPF on the internet. Since I couldn't really find one of them that did not directly deep-dive into 100s of pages of concepts like different type of LSAs, DR, BDR, Areas, and a lot of other complex things instead of just showing that a bunch of routers can talk to each other, I created this tutorial to prove routing protocols are fun, and to encourage you to have fun building networks. :-) 377 | 378 | First of all, don't forget to take a look at the BIRD documentation about OSPF. You can find it at User's guide -> Protocols -> OSPF at the [BIRD web page](http://bird.network.cz/). There's a lot more options than "stub". :) While I just proved you don't need to know about them to set up an interesting network with dynamic routing, there must be scenarios in which they can be very useful. For example: 379 | * If there are untrusted hosts inside your routing vlans, you might want to use password authentication. 380 | * If you want to decrease the time until the network gets reconfigured when a router crashes without notifying anyone, you might want to play with hello timers, or even bfd. 381 | * Equal cost multipath routing (ECMP) is a big thing nowadays, which is used a lot to load balance traffic over multiple paths to a destination instead of choosing only one as best path. You can even enable that in the network we just built by just specifying `ecmp yes` in the OSPF configuration (try it on R2 or R6) and see what effect it has on the output of `ip r` on the linux command line. Just search for information on it on the Internet to learn more. 382 | * 'Cost' is an aspect that is fundamental to OSPF and the calculation of the shortest paths in the network. Traditionally, cost is related to the bandwidth of a link between routers, and causes higher bandwidth connections to be prefered above lower bandwidth connections. Since we're working with switched Gigabit/s networks by default now, if it's not 10Gb/s, in the datacenter and even in our office, I've just been ignoring that. 383 | 384 | Another thing you can play with is rolling out IPv6 on this little network that was just built. It needs a `bird6.conf` configuration file, and you'll soon find out doing IPv6 is very similar to what we did here with IPv4. Just pick some subnets from the `2001:db8::/32` network to work with and there you go. 385 | 386 | After completing this tutorial, I also encourage you to start reading the other "An Introduction to OSPF" like pages on the internet, since they should be a lot easier to understand while having seen it work for real! Have fun. 387 | 388 | # Cleaning up 389 | 390 | Before starting the next tutorial, we need to get rid of all our container stuff, since the names starting with R and H will be reused. Make sure you preserve the configs that you wrote if you want to have a look at them later. Then, we can stop and remove everything: 391 | 392 | for router in 1 2 5 6; do lxc-stop -n R$router; lxc-destroy -n R$router; sleep 2; done 393 | for host in 12 10 8 5; do lxc-stop -n H$host; lxc-destroy -n H$host; sleep 2; done 394 | 395 | Next: [An introduction to BGP](/bgp-intro/README.md) 396 | -------------------------------------------------------------------------------- /bgp-intro/README.md: -------------------------------------------------------------------------------- 1 | BGP, Part I 2 | =========== 3 | 4 | In the previous tutorial, we discovered how to let [OSPF](/ospf-intro/README.md) dynamically configure routing inside a network. This tutorial provides an introduction to another routing protocol, which is BGP, the Border Gateway Protocol. As the name implies, this protocol acts on the border of a network. Where OSPF is well suited to keep track of all tiny details of what's happening in our internal network, BGP will be talking to the outside world to interconnect our network with other networks, managed by someone else. 5 | 6 | ## BGP Essentials 7 | 8 | When routers talk BGP to each other, they essentially just claim that network ranges are reachable via them: 9 | 10 | ![BGP network, barebones](/bgp-intro/bgp-heythere.png) 11 | 12 | Let's look at the same picture again, hiding less information: 13 | 14 | ![BGP network, less simplified](/bgp-intro/bgp-hey2.png) 15 | 16 | The picture shows two networks, which are interconnected through router `R3` and `R10`. 17 | 18 | * A complete network under control of somebody has an AS ([Autonomous System](https://tools.ietf.org/html/rfc1930)) number. This number will be used later in the BIRD BGP configuration. 19 | * The routes that are published to another network are as aggregated as possible, to minimize the amount of them. While the internal routing table in for example `AS64080` might contain dozens of prefixes, for each little vlan, and probably a number of single host routes (IPv4 `/32` and IPv6 `/128`), they're advertised to the outside as just three routes in total. 20 | * If neighbouring routers between different networks are directly connected, they often interconnect using a minimal sized network range. For IPv4, this is usually a `/30` and for IPv6 a `/120` or a `/126` prefix, containing only the two routers. In the example above, the small network ranges are taken from the network of `AS64080`. 21 | 22 | ## OSPF vs. BGP 23 | 24 | While the title of this section might seem logical, since we're considering BGP after just having spent quite some time on OSPF, it's actually a non-issue. OSPF and BGP are two very different routing protocols, which are used to get different things done. Nonetheless, let's look at some differences: 25 | 26 | OSPF: 27 | * Routes in the network are originated by just putting ip addresses on a network interface of a router, and letting the routing protocol pick them up automatically. 28 | * The routes in OSPF are addresses and subnets that are actually in use. 29 | * Every router that participates in the OSPF protocol has a full detailed view on the network using link state updates that are broadcasted over the network. This knowledge is used to calculate the shortest path to every part of the network. 30 | 31 | BGP: 32 | * Routes that are published to other networks are "umbrella ranges", which are as big as possible and are defined manually. 33 | * There is no actual proof that the addresses which are advertised are actually in use inside the network. 34 | * A neighbour BGP router knows that some prefix is reachable via another network, but where OSPF shortest path deals with knowledge about all separate routers, paths and weights, BGP just looks on a higher level, considering a complete network (AS) being one step. By default BGP also tries to forward traffic into the direction that contains the smallest amount of AS-hops to a destination (the shortest AS-path), but BGP provides a fair amount of configurable options to influence the routing decisions. 35 | 36 | So, OSPF is an IGP (Interior Gateway Protocol) and BGP is an EGP (Exterior Gateway Protocol). BGP can connect OSPF networks to each other, hiding a lot of detail inside them. 37 | 38 | ## BGP and OSPF with BIRD: Setting up the containers and networks 39 | 40 | In the second half of this tutorial we'll configure a network, using OSPF, BGP and the BIRD routing software. BGP wise, it's kept simple, using just a single connection between two networks. 41 | 42 | ![BGP and OSPF network](/bgp-intro/bgp-ospf.png) 43 | 44 | Our networks start to look serious now! It might be handy to print this image so you don't have to scroll back up all the time, comparing all the routes in the output of commands with the network topology. 45 | 46 | Thankfully, most of the configuration is provided already, so we can quickly set up this whole network using our LXC environment. Just like in the previous tutorial, the birdbase container can be cloned, after which the lxc network information and configuration inside the containers can be copied into them. 47 | 48 | 1. Clone this git repository somewhere to be able to use some files from the bgp-intro/lxc/ directory inside: 49 | 50 | cd ~ 51 | git clone https://github.com/knorrie/network-examples.git 52 | 53 | 2. lxc-copy the birdbase container several times: 54 | 55 | lxc-copy -s -n birdbase -N R0 56 | lxc-copy -s -n birdbase -N R1 57 | lxc-copy -s -n birdbase -N R3 58 | lxc-copy -s -n birdbase -N R10 59 | lxc-copy -s -n birdbase -N R11 60 | lxc-copy -s -n birdbase -N R12 61 | lxc-copy -s -n birdbase -N H6 62 | lxc-copy -s -n birdbase -N H7 63 | lxc-copy -s -n birdbase -N H19 64 | lxc-copy -s -n birdbase -N H34 65 | 66 | 3. Set up the network interfaces in the lxc configuration. This can be done by removing all network related configuration that remains from the cloned birdbase container, and then appending all needed interface configuration by running the fixnetwork.sh script that can be found in `bgp-intro/lxc/` in this git repository. Of course, have a look at the contents of the script first, before executing it. 67 | 68 | cd /var/lib/lxc 69 | ~/network-examples/bgp-intro/lxc/fixnetwork.sh 70 | 71 | 4. Copy extra configuration into the containers. The bgp-intro/lxc/ directory inside this git repository contains a little file hierarchy that can just be copied over the configuration of the containers. For each router, it's a network/interfaces configuration file which adds an IP address that corresponds with the Router ID to the loopback interface, and a simple BIRD configuration file that serves as a starting point for our next steps. 72 | 73 | cp ~/network-examples/bgp-intro/lxc/[RH]* . -r 74 | 75 | 5. Start all containers 76 | 77 | for router in 0 1 3 10 11 12; do lxc-start -d -n R$router; sleep 2; done 78 | for host in 6 7 19 34; do lxc-start -d -n H$host; sleep 2; done 79 | 80 | 6. Verify connectivity and look around a bit. Here's an example for R1: 81 | 82 | lxc-attach -n R1 83 | 84 | root@R1:/# ip a 85 | 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default 86 | link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 87 | inet 127.0.0.1/8 scope host lo 88 | valid_lft forever preferred_lft forever 89 | inet 10.40.217.1/32 scope global lo 90 | valid_lft forever preferred_lft forever 91 | inet6 2001:db8:40::1/128 scope global 92 | valid_lft forever preferred_lft forever 93 | inet6 ::1/128 scope host 94 | valid_lft forever preferred_lft forever 95 | 109: vlan216: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 96 | link/ether 02:00:0a:28:d8:03 brd ff:ff:ff:ff:ff:ff 97 | inet 10.40.216.3/28 brd 10.40.216.15 scope global vlan216 98 | valid_lft forever preferred_lft forever 99 | inet6 2001:db8:40:d8::3/120 scope global 100 | valid_lft forever preferred_lft forever 101 | inet6 fe80::aff:fe28:d803/64 scope link 102 | valid_lft forever preferred_lft forever 103 | 111: vlan3: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 104 | link/ether 02:00:0a:28:03:01 brd ff:ff:ff:ff:ff:ff 105 | inet 10.40.3.1/24 brd 10.40.3.255 scope global vlan3 106 | valid_lft forever preferred_lft forever 107 | inet6 2001:db8:40:3::1/120 scope global 108 | valid_lft forever preferred_lft forever 109 | inet6 fe80::aff:fe28:301/64 scope link 110 | valid_lft forever preferred_lft forever 111 | 112 | root@R1:/# ip r 113 | 10.40.2.0/24 via 10.40.216.2 dev vlan216 proto bird 114 | 10.40.3.0/24 dev vlan3 proto kernel scope link src 10.40.3.1 115 | 10.40.216.0/28 dev vlan216 proto kernel scope link src 10.40.216.3 116 | 10.40.217.0 via 10.40.216.2 dev vlan216 proto bird 117 | 10.40.217.3 via 10.40.216.1 dev vlan216 proto bird 118 | 10.40.217.16/30 via 10.40.216.1 dev vlan216 proto bird 119 | 120 | root@R1:/# birdc show route 121 | BIRD 1.4.5 ready. 122 | 10.40.217.16/30 via 10.40.216.1 on vlan216 [ospf1 22:58:02] * I (150/20) [10.40.217.3] 123 | 10.40.216.0/28 dev vlan216 [ospf1 22:58:02] * I (150/10) [10.40.217.3] 124 | 10.40.217.0/32 via 10.40.216.2 on vlan216 [ospf1 22:58:02] * I (150/10) [10.40.217.0] 125 | 10.40.217.1/32 dev lo [ospf1 22:57:42] * I (150/0) [10.40.217.1] 126 | 10.40.217.3/32 via 10.40.216.1 on vlan216 [ospf1 22:58:02] * I (150/10) [10.40.217.3] 127 | 10.40.2.0/24 via 10.40.216.2 on vlan216 [ospf1 22:58:02] * I (150/20) [10.40.217.0] 128 | 10.40.3.0/24 dev vlan3 [ospf1 22:57:42] * I (150/10) [10.40.217.1] 129 | 130 | root@R1:/# ip -6 r 131 | 2001:db8:40:: via fe80::aff:fe28:d802 dev vlan216 proto bird metric 1024 132 | unreachable 2001:db8:40::1 dev lo proto kernel metric 256 error -101 133 | 2001:db8:40::3 via fe80::aff:fe28:d801 dev vlan216 proto bird metric 1024 134 | 2001:db8:40:2::/120 via fe80::aff:fe28:d802 dev vlan216 proto bird metric 1024 135 | 2001:db8:40:3::/120 dev vlan3 proto kernel metric 256 136 | 2001:db8:40:d8::/120 dev vlan216 proto kernel metric 256 137 | 2001:db8:40:d910::/120 via fe80::aff:fe28:d801 dev vlan216 proto bird metric 1024 138 | fe80::/64 dev vlan216 proto kernel metric 256 139 | fe80::/64 dev vlan3 proto kernel metric 256 140 | 141 | root@R1:/# birdc6 show route 142 | BIRD 1.4.5 ready. 143 | 2001:db8:40:d8::/120 dev vlan216 [ospf1 22:58:08] * I (150/10) [10.40.217.3] 144 | 2001:db8:40::/128 via fe80::aff:fe28:d802 on vlan216 [ospf1 22:58:08] * I (150/20) [10.40.217.0] 145 | 2001:db8:40:2::/120 via fe80::aff:fe28:d802 on vlan216 [ospf1 22:58:08] * I (150/20) [10.40.217.0] 146 | 2001:db8:40:3::/120 dev vlan3 [ospf1 22:57:41] * I (150/10) [10.40.217.1] 147 | 2001:db8:40::3/128 via fe80::aff:fe28:d801 on vlan216 [ospf1 22:58:08] * I (150/20) [10.40.217.3] 148 | 2001:db8:40:d910::/120 via fe80::aff:fe28:d801 on vlan216 [ospf1 22:58:08] * I (150/20) [10.40.217.3] 149 | 150 | As you can see, OSPF is running for IPv4 and IPv6, and has discovered the complete internal network of `AS64080`. 151 | 152 | Now make sure you can do the following, and answer the following questions: 153 | * From H6, `traceroute -n` and `traceroute6 -n` to a few destinations in `AS64080` to get acquainted with the network topology. 154 | * Look at the BIRD logging. A fun way to follow the logging is to do `tail -F R*/rootfs/var/log/bird/*.log` from outside the containers, and then start all of them. 155 | * Find out why `10.40.217.18` or `2001:db8:40:d910::2` on `R10` cannot be pinged from `R1`, while the route to `10.40.217.16/30` and `2001:db8:40:d910::/120` are actually present in the routing table of `R1` and `R3`. 156 | 157 | ## BIRD BGP configuration 158 | 159 | Let's zoom in a bit first, and focus on the connection between `R3` and `R10`. This section will show how to configure the actual BGP connection between those two routers, so they will learn about each others network. 160 | 161 | ![BGP and OSPF network, zoom in on R3, R10](/bgp-intro/bgp-ospf-zoom.png) 162 | 163 | The routing table of `R3` contains information about the internal network of its own network, `AS64080`. As you can see, routes to the ranges in `AS65033` are missing. 164 | 165 | root@R3:/# ip r 166 | 10.40.2.0/24 via 10.40.216.2 dev vlan216 proto bird 167 | 10.40.3.0/24 via 10.40.216.3 dev vlan216 proto bird 168 | 10.40.216.0/28 dev vlan216 proto kernel scope link src 10.40.216.1 169 | 10.40.217.0 via 10.40.216.2 dev vlan216 proto bird 170 | 10.40.217.1 via 10.40.216.3 dev vlan216 proto bird 171 | 10.40.217.16/30 dev vlan217 proto kernel scope link src 10.40.217.17 172 | 173 | root@R3:/# ip -6 r 174 | 2001:db8:40:: via fe80::aff:fe28:d802 dev vlan216 proto bird metric 1024 175 | 2001:db8:40::1 via fe80::aff:fe28:d803 dev vlan216 proto bird metric 1024 176 | unreachable 2001:db8:40::3 dev lo proto kernel metric 256 error -101 177 | 2001:db8:40:2::/120 via fe80::aff:fe28:d802 dev vlan216 proto bird metric 1024 178 | 2001:db8:40:3::/120 via fe80::aff:fe28:d803 dev vlan216 proto bird metric 1024 179 | 2001:db8:40:d8::/120 dev vlan216 proto kernel metric 256 180 | 2001:db8:40:d910::/120 dev vlan217 proto kernel metric 256 181 | fe80::/64 dev vlan216 proto kernel metric 256 182 | fe80::/64 dev vlan217 proto kernel metric 256 183 | 184 | Now, add the following configuration to `bird.conf` of `R3`: 185 | 186 | ############################################################################## 187 | # eBGP R10 188 | # 189 | 190 | table t_r10; 191 | 192 | protocol static originate_to_r10 { 193 | table t_r10; 194 | import all; # originate here 195 | route 10.40.0.0/22 blackhole; 196 | route 10.40.216.0/21 blackhole; 197 | } 198 | 199 | protocol bgp ebgp_r10 { 200 | table t_r10; 201 | local 10.40.217.17 as 64080; 202 | neighbor 10.40.217.18 as 65033; 203 | import filter { 204 | if net ~ [ 10.0.0.0/8{19,24} ] then accept; 205 | reject; 206 | }; 207 | import keep filtered on; 208 | export where source = RTS_STATIC; 209 | } 210 | 211 | protocol pipe p_master_to_r10 { 212 | table master; 213 | peer table t_r10; 214 | import where source = RTS_BGP; 215 | export none; 216 | } 217 | 218 | ### A closer look 219 | 220 | Let me explain a bit about what's going on here. So far, we've used the BIRD protocol types `kernel`, `device` and `ospf`. This configuration snippet introduces three other ones: `static`, `bgp` and `pipe`. Besides that, there's also a table definition on top. 221 | 222 | table t_r10; 223 | 224 | By issuing `table t_r10`, we tell BIRD that we'd like to use an extra internal routing table with the name `t_r10`. By default, BIRD always has a routing table named `master`, and now we added a second one. Routing tables in BIRD are just a collection of routes, having some attributes. 225 | 226 | protocol static originate_to_r10 { 227 | table t_r10; 228 | import all; # originate here 229 | route 10.40.0.0/22 blackhole; 230 | route 10.40.216.0/21 blackhole; 231 | } 232 | 233 | The static protocol is used to generate a collection of static routes. In this case, we define a protocol static with name `originate_to_r10`, and connect it to table `t_r10`. The import statement causes the routes that are generated by this static route protocol to be imported into the `t_r10` table. Static routes usually have a target of a neighbor router, using a via statement, but in this case, we don't care about a next hop, since it's just a collection of some prefixes that will be exported via BGP. The blackhole won't be actually used for anything here. 234 | 235 | protocol bgp ebgp_r10 { 236 | table t_r10; 237 | local 10.40.217.17 as 64080; 238 | neighbor 10.40.217.18 as 65033; 239 | import filter { 240 | if net ~ [ 10.0.0.0/8{19,24} ] then accept; 241 | reject; 242 | }; 243 | import keep filtered on; 244 | export where source = RTS_STATIC; 245 | } 246 | 247 | The bgp protocol is named after the router which it's talking to, `R10`, and is also connected to the `t_r10` routing table inside BIRD. It has a local and remote IP address and AS number. The import rules are a bit more complex than a simple `import all`, which also would have been sufficient here to get it working. The filter shown here just makes sure only RFC1918 prefixes from `10/8` are accepted, which are allowed to be from a `/19` to `/24` in size each. The export rule contains a simple filter that tells BIRD to push all routes from table `t_r10` that originate from a static protocol to the outside, to `R10`. 248 | 249 | protocol pipe p_master_to_r10 { 250 | table master; 251 | peer table t_r10; 252 | import where source = RTS_BGP; 253 | export none; 254 | } 255 | 256 | The pipe protocol is a simple protocol that is able to move around routes between internal BIRD routing tables. In this case, the pipe protocol `p_master_to_r10` is connected to the central `master` routing table and is looking at table `t_r10`. From table `t_r10`, all routes that originate from an external BGP peer are imported into the master table. Doing so will cause the routes that will be learned from the remote network to end up in the routing table of the Linux kernel (via the kernel protocol that exports them from the BIRD master table outside BIRD), while the routes that only were meant to be used to export to the BGP peer (generated by the static protocol) stay in `t_r10`. 257 | 258 | Don't worry if the whole construction with tables, protocols and pipes is still a bit confusing. First goal is to see the BGP routing in action, and afterwards I'll explain more about those BIRD internals. 259 | 260 | Also, remember that the internal BIRD routing tables are not used to actually do packet forwarding. During the OSPF tutorial, we already discussed this difference between the "Control Plane" and "Forwarding Plane". Actually, the routing table inside the control plane is usually called the "RIB" (Routing Information Base), while the routing table that is used in the forwarding plane is called the "FIB" (Forwarding Information Base). Just look up all those terms on the internet to see what everyone is saying about them. 261 | 262 | ### Seeing it in action! 263 | 264 | After adding the configuration on `R3`, fire up the interactive BIRD console, using `birdc`: 265 | 266 | root@R3:/# birdc 267 | BIRD 1.4.5 ready. 268 | bird> 269 | 270 | Don't forget to tell BIRD to read and apply the changed configuration: 271 | 272 | bird> con 273 | Reading configuration from /etc/bird/bird.conf 274 | Reconfigured 275 | 276 | Now, the three new protocols should be shown: 277 | 278 | bird> show protocols 279 | name proto table state since info 280 | kernel1 Kernel master up 2015-06-14 281 | device1 Device master up 2015-06-14 282 | ospf1 OSPF master up 2015-06-14 Running 283 | originate_to_r10 Static t_r10 up 23:54:16 284 | p_master_to_r10 Pipe master up 23:54:16 => t_r10 285 | ebgp_r10 BGP t_r10 start 00:34:16 Active Socket: Connection refused 286 | 287 | bird> show route table t_r10 288 | 10.40.216.0/21 blackhole [originate_to_r10 23:54:16] * (200) 289 | 10.40.0.0/22 blackhole [originate_to_r10 23:54:16] * (200) 290 | 291 | Well, the routes are waiting to be pushed to `R10` in the `t_r10` table, and no routes from `AS65033` are visible yet. There's only an ugly "Connection refused"... reminding you that the other end of the BGP connection needs to be configured. Now it's up to you to configure `R10` with the opposite part of the configuration, and make it talk to `R3`! 292 | 293 | When successful, the output of the commands above should show the BGP session to R3 as Established now: 294 | 295 | bird> show protocols 296 | name proto table state since info 297 | kernel1 Kernel master up 2015-06-14 298 | device1 Device master up 2015-06-14 299 | ospf1 OSPF master up 2015-06-14 Running 300 | originate_to_r3 Static t_r3 up 00:48:27 301 | ebgp_r3 BGP t_r3 up 00:48:32 Established 302 | p_master_to_r3 Pipe master up 00:48:27 => t_r3 303 | 304 | Table `t_r3` now also contains the routes that are learned from `AS64080`: 305 | 306 | bird> show route table t_r3 307 | 10.40.216.0/21 via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i] 308 | 10.40.32.0/19 blackhole [originate_to_r3 00:48:27] * (200) 309 | 10.40.0.0/22 via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i] 310 | 311 | The above shows for example that prefix `10.40.216.0/21` was learned via the protocol `ebgp_r3`, at 00:48 AM, and that the range is originating from `AS64080`. The `via 10.40.217.17` is the BGP next-hop, which is the first router _outside_ our own network. 312 | 313 | The BIRD master routing table also contains the routes learned over BGP, thanks to the `p_master_to_r3` protocol: 314 | 315 | bird> show route 316 | 10.40.217.16/30 dev vlan217 [ospf1 2015-06-14] * I (150/10) [10.40.32.10] 317 | 10.40.216.0/21 via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i] 318 | 10.40.33.0/26 dev vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.12] 319 | 10.40.36.0/24 via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.12] 320 | 10.40.48.0/21 via 10.40.33.2 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.11] 321 | 10.40.32.10/32 dev lo [ospf1 2015-06-14] * I (150/0) [10.40.32.10] 322 | 10.40.32.11/32 via 10.40.33.2 on vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.11] 323 | 10.40.0.0/22 via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i] 324 | 10.40.32.12/32 via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.12] 325 | 326 | The last step to get the routes into the actual forwarding table inside the Linux kernel is done by the kernel protocol. Since there is no explicit name given for the kernel protocol in the configuration, BIRD just names it `kernel1`. 327 | 328 | bird> show route export kernel1 329 | 10.40.216.0/21 via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i] 330 | 10.40.36.0/24 via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.12] 331 | 10.40.48.0/21 via 10.40.33.2 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.11] 332 | 10.40.32.11/32 via 10.40.33.2 on vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.11] 333 | 10.40.0.0/22 via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i] 334 | 10.40.32.12/32 via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.12] 335 | 336 | Now the routes show up in the output of `ip route`, labeled with proto bird: 337 | 338 | root@R10:/# ip r 339 | 10.40.0.0/22 via 10.40.217.17 dev vlan217 proto bird 340 | 10.40.32.11 via 10.40.33.2 dev vlan33 proto bird 341 | 10.40.32.12 via 10.40.33.3 dev vlan33 proto bird 342 | 10.40.33.0/26 dev vlan33 proto kernel scope link src 10.40.33.1 343 | 10.40.36.0/24 via 10.40.33.3 dev vlan33 proto bird 344 | 10.40.48.0/21 via 10.40.33.2 dev vlan33 proto bird 345 | 10.40.216.0/21 via 10.40.217.17 dev vlan217 proto bird 346 | 10.40.217.16/30 dev vlan217 proto kernel scope link src 10.40.217.18 347 | 348 | Well, let's have a look what we can do with this result. Since both networks are now aware of each other's routes, I'd expect I can do some tracerouting into a remote network now! 349 | 350 | root@R10:/# traceroute -n 10.40.2.6 351 | traceroute to 10.40.2.6 (10.40.2.6), 30 hops max, 60 byte packets 352 | 1 10.40.217.17 0.356 ms 0.319 ms 0.324 ms 353 | 2 10.40.216.2 0.430 ms 0.427 ms 0.378 ms 354 | 3 10.40.2.6 0.781 ms 0.724 ms 0.716 ms 355 | 356 | `R10` now knows the route to IPv4 ranges used in `AS64080`, and it seems `H6` also knows a route back to `R10`. 357 | 358 | Let's try it from `H34`! 359 | 360 | root@H34:/# traceroute -n 10.40.2.6 361 | traceroute to 10.40.2.6 (10.40.2.6), 30 hops max, 60 byte packets 362 | 1 10.40.36.1 0.296 ms !N 0.091 ms !N * 363 | 364 | Meh, that doesn't look to good. Apparently there's more work to do. 365 | 366 | ### Some assignments 367 | 368 | Now make sure you can do the following, and answer the following questions: 369 | 370 | * Configure the IPv6 BGP connection between `R3` and `R10`. IPv4 and IPv6 is handled separately by BIRD now, but the configuration for IPv6 is very similar to the configuration I showed here. Just use import all for bgp if you don't want to learn more about filtering now. 371 | * Explain why `10.40.217.18` or `2001:db8:40:d910::2` on `R10` can be pinged from `R1` now, while this was not the case before: 372 | 373 | root@R1:/# ping6 2001:db8:40:d910::2 374 | PING 2001:db8:40:d910::2(2001:db8:40:d910::2) 56 data bytes 375 | 64 bytes from 2001:db8:40:d910::2: icmp_seq=1 ttl=63 time=0.399 ms 376 | 64 bytes from 2001:db8:40:d910::2: icmp_seq=2 ttl=63 time=0.099 ms 377 | ^C 378 | --- 2001:db8:40:d910::2 ping statistics --- 379 | 2 packets transmitted, 2 received, 0% packet loss, time 1000ms 380 | rtt min/avg/max/mdev = 0.099/0.249/0.399/0.150 ms 381 | 382 | * Try to export a route outside of `10.0.0.0/8` over BGP, from `R3` to `R10` and notice that the filter will actually stop that route from being propagated, while accepting the other routes. Using the `show route filtered protocol ebgp_r3` command the route should be visible, thanks to the `import keep filtered on` option that is set. 383 | * Figure out why, despite the fact that the two networks learned each others prefixes, you still cannot reach any router or host in the neighbor network that lies behing the border router. Try the following ICMP echo commands and explain why they do or don't succeed. Hint: use `tcpdump -ni vlanXYZ` on the right vlan interface to see the actual traffic, with source and destination addresses. 384 | - `R3` -> `R10`: `root@R3:/# ping 10.40.32.10` 385 | - `R3` -> `R11`: `root@R3:/# ping 10.40.32.11` 386 | - `R11` -> `R3`: `root@R11:/# ping 10.40.217.3` 387 | - `H12` -> `R1`: `root@R12:/# ping 10.40.217.1` 388 | 389 | After explaining a bit more about the BIRD tables and protocols, we'll fix all these reachability issues. 390 | 391 | ## Intermezzo: BIRD tables, protocols, import, export 392 | 393 | The usage of import, export, different protocols and routing tables can be a bit confusing at first. Well, at least [it was very frustrating for me](http://bird.network.cz/pipermail/bird-users/2013-January/008071.html), until [I found out](http://bird.network.cz/pipermail/bird-users/2013-January/008081.html) how to use it. 394 | 395 | The main gotcha here is that the import and export statements are to be considered from the point of view of the BIRD routing table that is connected to the protocol (either by specifying the table option, or omitting it, using the default `master` table). 396 | 397 | What I found out is that the easiest way to prevent confusion is to take the BIRD 'master' table as central point of reasoning, and then configure everything so that 'import' points closer to the master table, importing routes closer to the heart of BIRD, and 'export' points away from it, pushing routes to the outside world. 398 | 399 | Here's a diagram of the BIRD configuration that we just used: 400 | 401 | ![BIRD protocols, tables, import and export](/bgp-intro/bird-prototable.png) 402 | 403 | And here's how you should read the configuration that is in your routers right now: 404 | * table `master` is the central routing table of BIRD 405 | * kernel protocol `kernel1` exports routes from BIRD to Linux 406 | * ospf protocol `ospf1` imports routes from other OSPF routers in the network into BIRD 407 | * pipe protocol `p_master_to_r10` imports routes from its peer table `t_r10` into table `master` 408 | * table `t_r10` is another BIRD table that contains a collection of routes with attributes 409 | * static protocol `originate_to_r10` imports static routes into table `t_r10` 410 | * bgp protocol `ebgp_r10` exports routes from table `t_r10` to `R10` 411 | 412 | Note that the OSPF protocol itself also generates routes for connected subnets that are stub or non-stub networks. These routes are not imported via the kernel protocol. 413 | 414 | The output of `show protocols` should also totally make sense now (table column width adjusted): 415 | 416 | root@R3:/# birdc show protocols 417 | BIRD 1.4.5 ready. 418 | name proto table state since info 419 | kernel1 Kernel master up 2015-06-14 420 | device1 Device master up 2015-06-14 421 | ospf1 OSPF master up 2015-06-14 Running 422 | originate_to_r10 Static t_r10 up 2015-06-18 423 | p_master_to_r10 Pipe master up 2015-06-18 => t_r10 424 | ebgp_r10 BGP t_r10 up 2015-06-19 Established 425 | 426 | Assignments: 427 | * The OSPF protocol configuration that we are using does not contain any table, import or export. This means it's using the defaults, which are table master, import all, export none. Add a line specifying `import none;` to the OSPF protocol configuration, and look at the effect on the BIRD master table, and the Linux routing table. 428 | * Change the BIRD configuration to use only the `master` table, eliminating the extra `t_r10` routing table, without changing the set of routes that are actually exported to the Linux kernel. Doing so should show that it's entirely possible, but that decreasing complexity by removing the extra table will increase complexity in the filters needed. 429 | 430 | ## Connecting the internal network 431 | 432 | There's a last task that needs to be completed before every host and router in the two networks can see each other. As you just found out, only the border routers that actually speak BGP have learned the routes to the other network, and the internal routers still have no idea about them. 433 | 434 | So, how should `R0` and `R1` be told about the routes from `AS65033` that are already known to `R3`? 435 | 436 | ### iBGP 437 | 438 | BGP is not only meant to be used to connect to a router in an external network, it can also be used to connect back to routers in our own AS, to provide them with the learned information about externally reachable networks. A connection to a router in a different AS is called an eBGP connection, and, a connection to a router inside the same AS is called an iBGP connection. 439 | 440 | In the inside network, iBGP can run alongside OSPF on the routers, the difference between them being that OSPF carries the internal routes, and BGP the external ones: 441 | 442 | * OSPF, the IGP, contains all information about routes _inside_ our network. 443 | * BGP, the EGP, contains all information about _external_ connectivity. 444 | 445 | ![OSPF, eBGP and iBGP](/bgp-intro/ospf-ebgp-ibgp.png) 446 | 447 | ### BIRD iBGP configuration 448 | 449 | Here's an example for the IPv6 iBGP connection between `R3` and `R1`: 450 | 451 | In the IPv6 BIRD configuration of `R3`, add: 452 | 453 | protocol bgp ibgp_r1 { 454 | import none; 455 | export where source = RTS_BGP; 456 | local 2001:db8:40::3 as 64080; 457 | neighbor 2001:db8:40::1 as 64080; 458 | } 459 | 460 | In the IPv6 BIRD configuration of `R1`, add: 461 | 462 | protocol bgp ibgp_r3 { 463 | local 2001:db8:40::1 as 64080; 464 | neighbor 2001:db8:40::3 as 64080; 465 | } 466 | 467 | Using the same AS number for the local and neighbor address simply tells BIRD that we're dealing with an iBGP connection. 468 | 469 | Do a `birdc6 configure` in `R1` and `R3`, and look at the result on `R1`: 470 | 471 | root@R1:/# birdc6 show route protocol ibgp_r3 472 | BIRD 1.4.5 ready. 473 | 2001:db8:10::/48 via fe80::aff:fe28:d801 on vlan216 [ibgp_r3 23:26:12 from 2001:db8:40::3] * (100/20) [AS65033i] 474 | 475 | BIRD just learned a route to the remote AS! And, because of this, `H7` in `AS64080` and `R10` in `AS65033` can now find each other: 476 | 477 | root@H7:/# traceroute6 -n 2001:db8:10:6::a 478 | traceroute to 2001:db8:10:6::a (2001:db8:10:6::a), 30 hops max, 80 byte packets 479 | 1 2001:db8:40:3::1 0.556 ms 0.501 ms 0.501 ms 480 | 2 2001:db8:40:d8::1 1.059 ms 1.074 ms 1.078 ms 481 | 3 2001:db8:10:6::a 1.281 ms 1.274 ms 1.268 ms 482 | 483 | ### How OSPF and BGP work together 484 | 485 | Since BGP only handles external connectivity, the protocol does not try to be clever about routes inside the local network. When taking a closer look at the BGP route that is received by `R1`, it shows that the BGP information attached to the route only contains information about the first hop _outside_ the network, which is called the BGP next hop: 486 | 487 | root@R1:/# birdc6 488 | BIRD 1.4.5 ready. 489 | bird> show route all 2001:db8:10::/48 490 | 2001:db8:10::/48 via fe80::aff:fe28:d801 on vlan216 [ibgp_r3 23:26:11 from 2001:db8:40::3] * (100/20) [AS65033i] 491 | Type: BGP unicast univ 492 | BGP.origin: IGP 493 | BGP.as_path: 65033 494 | BGP.next_hop: 2001:db8:40:d910::2 495 | BGP.local_pref: 100 496 | 497 | Since `R1` has only got this information, BIRD has to find out what the actual next hop to a router in a directly connected subnet has to be before a route can be exported to the Linux kernel. Luckily this is where the cooperation of the IGP comes into play. Since OSPF knows a route to `2001:db8:40:d910::2`, it can tell us where to forward the traffic in the local network to push it closer to that external BGP next hop. This is exactly the reason why the subnets that connect to routers just outside our own network are also included in OSPF as stub networks! 498 | 499 | bird> show route for 2001:db8:40:d910::2 500 | 2001:db8:40:d910::/120 via fe80::aff:fe28:d801 on vlan216 [ospf1 2015-06-14] * I (150/20) [10.40.217.3] 501 | 502 | Remember the section about next-hops in the OSPF tutorial? If not, go back and re-read it ("Step three: figuring out shortest paths and determining next-hops"). The same logic applies here. While this router already has a strong opinion about the path that traffic to `2001:db8:10:6::a` has to take to reach the remote network, all this knowledge gets thrown away even before the actual IP packet leaves this router... While BIRD knows the entry point in the remote network, as well as the path through the internal network to reach it, it can only install a route to the locally connected next hop into the actual forwarding routing table of the Linux kernel. The next router which receives the packet has to apply all routing logic again itself to get it forwarded into the right direction. Luckily, protocols like OSPF and BGP are designed in a way that enables us to trust that all routers that cooperate in the routing protocols have the same mindset and will perfectly work together to get the traffic to its destination without endlessly forwarding it in loops between them. 503 | 504 | The only thing that the routers in`AS64080` know is that `R10` is the entry point for `AS65033`, and how to get there. They do not have the slightest knowledge about how the internal network of `AS65033` is organized, and there is no way for them to learn about this. When the traffic enters the remote network, that network will take care of delivering it to the actual router or host in that network. 505 | 506 | ### Can OSPF be used instead of iBGP? 507 | 508 | After getting to know iBGP, you might still wonder: "If the routes are in the BIRD master table, and we already have the routers inside the AS talking to each other, why not just export the BGP routes into OSPF?". Well, actually, that can be done, and we can try it for fun. In order to redistribute the BGP routes into OSPF, just shut down the iBGP connections again and add the line `export where source = RTS_BGP;` to the OSPF section of both `R3` and `R10` and `birdc configure`. 509 | 510 | For example, `R11` now shows: 511 | 512 | root@R11:/# birdc6 show r 513 | BIRD 1.4.5 ready. 514 | 2001:db8:10:24::/120 via fe80::aff:fe28:2103 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.12] 515 | 2001:db8:10:21::/120 dev vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.12] 516 | 2001:db8:10:30::/117 dev vlan48 [ospf1 2015-06-14] * I (150/10) [10.40.32.11] 517 | 2001:db8:10:6::a/128 via fe80::aff:fe28:2101 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.10] 518 | 2001:db8:10:6::c/128 via fe80::aff:fe28:2103 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.12] 519 | 2001:db8:40::/48 via fe80::aff:fe28:2101 on vlan33 [ospf1 21:00:55] * E2 (150/20/10000) [10.40.32.10] 520 | 2001:db8:40:d910::/120 via fe80::aff:fe28:2101 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.10] 521 | 522 | You can see that the route to the neighbor AS is present, but it's tagged as an 'E2' route in OSPF, instead of the usual 'I', meaning it was imported from a different routing protocol on the router that originates this prefix, `10.40.32.10`. 523 | 524 | While using OSPF to transport the routes to the other internal routes might work in our little example network in this tutorial, it introduces a number of limitations, one of them being that all extra BGP specific information attached to a route is lost when converting it from a BGP to an OSPF route. This limits the amount of control that can be exercised on the selection of the exit point for traffic from a network to external networks. Another reason to refrain from doing this is that the full BGP table of the Internet contains more than half a million network prefixes. So if you would run a router in a location where you have all those routes in a BGP table, redistributing them to OSPF, pretending that the entire Internet is part of your local network will probably blow up your OSPF process. It's not designed to handle that. ;-) 525 | 526 | ### The usage of loopback addresses 527 | 528 | It might have occurred to you that the iBGP BIRD configuration specifies the local and remote address using loopback addresses instead of interface addresses from an actual connected subnet. Think back of the "The loopback address" section of the OSPF tutorial! The BGP router on the edge of the network, and the internal router which wants to learn about external connectivity using iBGP can be anywhere in the internal network. There may even exist multiple possible paths between them. By using a loopback address as source and target of the iBGP connection, the connection will keep functioning as long as there is any possible path between the two routers. The flow of traffic to the external network will follow the same directions as the iBGP control connection, since both of them use the IGP to reach each other. 529 | 530 | ![iBGP relying on the IGP](/bgp-intro/ibgp-loopback.png) 531 | 532 | ### Final assignments: 533 | 534 | * Well, this one is obvious... Practice some more by finishing setting up all connectivity by configuring the iBGP sessions for IPv4 and IPv6 between `R0` and `R3`, between `R10` and `R11`, and between `R10` and `R12`. Confirm by tracerouting from `H34` and `H19` in `AS65033` to `H6` and `H7` in `AS64080`. 535 | * If there's any part of the this first BGP tutorial that you do not understand already, make sure you will. The following tutorials will be building upon the knowledge gathered here. Don't get depressed if you don't get all of it the first time. Just go back to the top and read the page again, there's an awful lot of information compacted in this page. If you're brave, make up your own example network and try to build it from scratch. It will take some time, but as soon as you are able to traceroute from one far end to another, you've likely run into and solved all aspects you missed before. 536 | * Look around on the internet and read other blogs and tutorials about OSPF and BGP and see if they're much more easy to understand having a frame of reference which was set by following this tutorial. 537 | 538 | In the next tutorial, [BGP Part II](/bgp-contd/README.md), I'll show more interesting topologies of different networks connecting together using BGP than just two networks with one eBGP connection. By doing so, we'll quickly discover and understand how the actual huge Internet is organized. 539 | 540 | # Cleaning up 541 | 542 | Before starting the next tutorial, we need to get rid of all our container stuff, since the names starting with R and H will be reused. Make sure you preserve the configs that you wrote if you want to have a look at them later. Then, we can stop and remove everything: 543 | 544 | for router in 0 1 3 10 11 12; do lxc-stop -n R$router; lxc-destroy -n R$router; sleep 2; done 545 | for host in 6 7 19 34; do lxc-stop -n H$host; lxc-destroy -n H$host; sleep 2; done 546 | --------------------------------------------------------------------------------