Skip to content

Configure BGP Routing and .Pi DNS Resolution

Preparation

Review your final network planning documentation and identify the following details:

  • The ASN value assigned to your LAN. Each group member should have a unique ASN from the range given in PiCANN
  • Routing links and associated VLANs that connect to your Pi:
    • Each edge network router will have one routing link to the ISP router
    • The ISP router will have on routing link per edge network plus an uplink to the class network
  • An address from your public address range that you will use to configure your BGP router's router ID
  1. Follow Getting Started with Free Range Routing (FRR) on Raspberry Pi OS to install FRR and perform the initial configuration.
  2. Using the instructions provided in Configure a Routing Link for BGP Peers, perform the following tasks needed to configure BGP:
    1. Assign the router ID to the loopback interface
    2. Create and configure VLAN interfaces for "unnumbered" routing links
    3. Configure a BGP router using your router ID and ASN
    4. Use the neighbor directive to establish "unnumbered" ethernet peers over each routing link
    5. Use the network directive to advertise the full LAN/WAN address range you've been assigned.
  3. Save your configuration.

Firewall Rules for Edge Routers

Information

Since we are on a lab network, you can simplify troubleshoting by setting the default forwarding policy to accept. Once you are confident that routing works, change the policy back to drop and troubleshoot your rules.

Ensure that outbound traffic from your internal subnets is permitted.1 For simplicity, you may also open up your firewall to traffic arriving from your routing links.

Since our entire class network is assigned to the 172.30.0.0/16 networks you won't need to make any changes to the current NAT configuration. Likewise, you should continue to use connection state to make sure inbound packets (from wlan0) are dropped when they aren't related to established sessions

Firewall Rules for ISP routers

Information

Since we are on a lab network, you can simplify troubleshoting by setting the default forwarding policy to accept. Once you are confident that routing works, change the policy back to drop and troubleshoot your rules.

In addition to local traffic, your router is responsible for transit between your partners' networks and the rest of the class. To ensure that you don't interfere with this operation, add a rule to allow forwarded traffic originating from any of the routing links that you've configured.

Since our entire class network is assigned to the 172.30.0.0/16 networks you won't need to make any changes to the current NAT configuration. Likewise, you should continue to use connection state to make sure inbound packets (from wlan0) are dropped when they aren't related to established sessions

Configure .Pi DNS Resolution (all name servers)

We've intentionally set up all of our domains within the non-existent .pi top-level domain and are limiting the resolution of these domains to our class network. By default, our resolvers won't be able to perform queries against other .pi domains since the recursive process depends on relationship between the ICANN root and the top-level domain registries.

Our TLD is not present in those data stores, so we need to offer it a little help to resolve .pi domains. The work-around we're employing is to have each of your resolvers maintain a copy of the .pi zone so that it can directly discover the authoritative name servers of your peers' domains.

The primary name server for .pi is running at the 10.10.10.10 address (one member of your group will host a copy). By adding the following section to your /etc/bind/named.conf.local, your pi will perform a zone transfer with 10.10.10.10 and then periodically refresh based on the settings specified in the SOA for the top-level domain.

zone "pi" IN {
  type secondary;
  primaries { 10.10.10.10; };
};

  1. This change is discussed in the LAN portion of the guide. ↩

Back to top