BGP setup on XORP

I spent a couple of days recently playing with a small testbed of FreeBSD machines and XORP, the open routing platform, to enable BGP forwarding across a few machines. XORP’s documentation is, shall we say, functional, often really useful, but sometimes lacking. So after a lot of prodding, guessing, and trawling of mailing lists, I got things talking to each other.

So, I hope this little example will be useful to others. The machines I am testing on are set up as follows:

          1.0.0.0/8                                       4.0.0.0/8
          2.1.0.0/16      2.0.0.0/8        3.0.0.0/8      3.1.0.0/16
         +---------+     +---------+      +---------+    +---------+
         |         |     |         |      |         |    |         |
  +------+ AS65001 +-----+ AS65002 +------+ AS65003 +----+ AS65004 |
  |      |         |     |         |      |         |    |         |
  |      +---------+     +---------+      +---------+    +---------+
  |        (host1)         (host2)          (host3)        (host4)
  V
(to main network)

XORP on each machine is configured with the AS number shown, advertising the prefixes listed above. The interfaces used to chain the machines together are on different 10.foo.0.0/16 subnets via a very noisy Netgear router (10.10.0.0/16 between hosts 1 and 2, 10.11.0.0/16 between hosts 2 and 3, etc).

With BGP forwarding these routes between all hosts, the resulting routing table (RIB) at AS65001 is as follows:

Prefix                Nexthop                    Peer            AS Path
------                -------                    ----            -------
*> 1.0.0.0/8             10.10.10.10                0.0.0.0        i
*> 2.0.0.0/8             10.10.10.11                10.11.10.10   65002 i
*> 3.1.0.0/16            10.10.10.11                10.11.10.10   65002 65003 65004 i
*> 2.1.0.0/16            10.10.10.10                0.0.0.0        i
*> 3.0.0.0/8             10.10.10.11                10.11.10.10   65002 65003 i
*> 4.0.0.0/8             10.10.10.11                10.11.10.10   65002 65003 65004 i

Adding a 3.1.1.1 alias on host4, and a 2.1.1.1 alias on host1, gives proper endpoints for packets to hit. So Running traceroute to 3.1.1.1 from host1, I can see packets bouncing from node to node:

traceroute to 3.1.1.1 (3.1.1.1) from 2.1.1.1, 64 hops max, 40 byte packets
 1  10.10.10.11 (10.10.10.11)  0.423 ms  0.338 ms  0.202 ms
 2  10.11.10.11 (10.11.10.11)  0.412 ms  0.351 ms  0.290 ms
 3  n003-000-000-000.static.ge.com (3.1.1.1)  0.788 ms  0.471 ms  0.586 ms

So, thanks to BGP setting up the forwarding tables on those intermediate nodes, I can ssh directly into host4 from host1 without having to manually bounce via hosts 2 and 3. The only slight catchout is that for ping, ssh, traceroute, I have to set the source address so that packets can be routed back; the default choice for the source address otherwise is the local 10.10/16 address. But that’s just a side-effect of this made-up scenario.

And, yes, this is an entirely made-up, convoluted example, and no, I would not recommend using these prefixes on any eBGP setup you’re configuring to operate on the real Internet. Unless you happen to own those /8’s or /16’s, of course.

My config for this setup, in particular host1, is as follows:

interfaces {
    interface rl0 {
	vif rl0 {
	    address 10.10.10.10 {
		prefix-length: 24
	    }
	}
    }
}

fea {
    unicast-forwarding4 {
	disable: false
    }
}

protocols {
        static {
                route 1.0.0.0/8 {
                        next-hop: 10.10.10.10
                        metric: 1
                }
		route 2.1.0.0/16 {
			next-hop: 10.10.10.10
			metric: 1
		}
        }
}

policy {
	policy-statement bgp_out {
		term 0 {
			from {
				protocol: "static"
			}
			then {
				accept
			}
		}
		term 1 {
			from {
				protocol: "bgp"
			}
			then {
				accept
			}
		}
	}

	policy-statement bgp_in {
		term 0 {
			from {
			}
			then {
				accept
			}
		}
	}
}

protocols {
    bgp {
	export: "bgp_out"
	import: "bgp_in"

	bgp-id: 10.10.10.10
	local-as: 65001

	peer 10.10.10.11 {
	    local-ip: 10.10.10.10
	    as: 65002
	    next-hop: 10.10.10.10
	}
    }
}