BGP Intro: Hands on WIP, BIRD protocols and tables

bgp-intro/README.md

@@ -254,11 +254,13 @@ The bgp protocol is named after the router which it's talking to, `R10`, and is
 
 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`.
 
-Remember, 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.
+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.
+
+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.
 
 ### Seeing it in action!
 
-After adding the configuration, fire up the interactive BIRD console, using `birdc`:
+After adding the configuration on `R3`, fire up the interactive BIRD console, using `birdc`:
 
     root@R3:/# birdc 
     BIRD 1.4.5 ready.
@@ -278,7 +280,7 @@ After adding the configuration, fire up the interactive BIRD console, using `bir
 
 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`!
 
-When successful, the output of the commands above should show, on `R10`:
+When successful, the output of the commands above should show the BGP session to R3 as Established now:
 
     bird> show protocols 
     name     proto    table    state  since       info
@@ -288,12 +290,18 @@ When successful, the output of the commands above should show, on `R10`:
     originate_to_r3 Static   t_r3     up     00:48:27    
     ebgp_r3  BGP      t_r3     up     00:48:32    Established   
     p_master_to_r3 Pipe     master   up     00:48:27    => t_r3
-    
+
+Table `t_r3` now also contains the routes that are learned from `AS64080`:
+
     bird> show route table t_r3
     10.40.216.0/21     via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i]
     10.40.32.0/19      blackhole [originate_to_r3 00:48:27] * (200)
     10.40.0.0/22       via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i]
-    
+
+The above shows for example that prefix `10.40.216.0/21` was learned via the protocol `ebgp_r3`, 48 minutes ago, 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. On this router 
+
+The BIRD master routing table also contains the routes learned over BGP, thanks to the `p_master_to_r3` protocol:
+
     bird> show route 
     10.40.217.16/30    dev vlan217 [ospf1 2015-06-14] * I (150/10) [10.40.32.10]
     10.40.216.0/21     via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i]
@@ -305,6 +313,8 @@ When successful, the output of the commands above should show, on `R10`:
     10.40.0.0/22       via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i]
     10.40.32.12/32     via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.12]
 
+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`.
+
     bird> show route export kernel1
     10.40.216.0/21     via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i]
     10.40.36.0/24      via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/20) [10.40.32.12]
@@ -313,7 +323,7 @@ When successful, the output of the commands above should show, on `R10`:
     10.40.0.0/22       via 10.40.217.17 on vlan217 [ebgp_r3 00:48:32] * (100) [AS64080i]
     10.40.32.12/32     via 10.40.33.3 on vlan33 [ospf1 2015-06-14] * I (150/10) [10.40.32.12]
 
-Since there is no explicit name given for the kernel protocol in the configuration, BIRD just names it `kernel1`. As you can see, the table `t_r3` contains the static routes which are exported via BGP to `R3`, and it also contains two routes that were learned from `R3`. Yay! The default `show route` command shows routes that are in the BIRD master table. You can see that the `p_master_to_r3` pipe protocol correctly copied the routes that were learned from `R3` from table `t_r3` to the `master` table. The kernel protocol then exports all dynamically learned routes to the actual forwarding table in the Linux kernel, where they show up as output of `ip route`, labeled with proto bird:
+Now the routes show up in the output of `ip route`, labeled with proto bird:
 
     root@R10:/# ip r
     10.40.0.0/22 via 10.40.217.17 dev vlan217  proto bird 
@@ -360,34 +370,52 @@ Now make sure you can do the following, and answer the following questions:
         rtt min/avg/max/mdev = 0.099/0.249/0.399/0.150 ms
 
  * 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.
+ * 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.
+   - `R3` -> `R10`: `root@R3:/# ping 10.40.32.10`
+   - `R3` -> `R11`: `root@R3:/# ping 10.40.32.11`
+   - `R11` -> `R3`: `root@R11:/# ping 10.40.217.3`
+   - `H12` -> `R1`: `root@R12:/# ping 10.40.217.1`
 
-------------
+After explaining a bit more about the BIRD tables and protocols, we'll fix all these reachability issues.
 
 ## Intermezzo: BIRD tables, protocols, import, export
 
-BIRD concepts:
- * table: multiple routing tables (not like the linux kernel, it's just a collection of routes). e.g. there may be multiple paths to the same network in a table present.
- * protocol: move routes around between tables (pipe) or into / out of BIRD (ospf, bgp)
- * import: draw routes closer to BIRD
- * export: push routes away from BIRD to the outside world
- * table "master": central route table, import = pull to it, export = push away
+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.
 
-picture:
+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).
 
-    master <-- p_master_to_ebgp_r10 <-- t_ebgp_r10 <-> ebgp_r10
-                                                 \ <-- originate_to_r10
+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.
 
- * t\_ebgp\_r10 holds route information about routes originates to r10 and routes that are learned from r10
- * originate\_to\_r10 is a collection of routes that is advertised by this network
- * pipe to master forwards all routes that are learned from the ebgp session
- * master can just export all to kernel
+Here's a diagram of the BIRD configuration that we just used:
 
-## Let's do it
+![BIRD protocols, tables, import and export](/bgp-intro/bird-prototable.png)
 
- * show BIRD config for pipe and table and ebgp
- * reload, show proto, show route export p_blah etc
- * see that routes are imported from the other end
- * see that they end up in master table and in ip r
+And here's how you should read the configuration that is in your routers right now:
+ * table `master` is the central routing table of BIRD
+ * kernel protocol `kernel1` exports routes from BIRD to Linux
+ * ospf protocol `ospf1` imports routes from other OSPF routers in the network into BIRD
+ * pipe protocol `p_master_to_r10` imports routes from its peer table `t_r10` into table `master`
+ * table `t_r10` is another BIRD table that contains a collection of routes with attributes
+ * static protocol `originate_to_r10` imports static routes into table `t_r10`
+ * bgp protocol `ebgp_r10` exports routes from table `t_r10` to `R10`
+
+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.
+
+The output of `show protocols` should also totally make sense now (table column width adjusted):
+
+    root@R3:/# birdc show protocols
+    BIRD 1.4.5 ready.
+    name              proto    table    state  since       info
+    kernel1           Kernel   master   up     2015-06-14  
+    device1           Device   master   up     2015-06-14  
+    ospf1             OSPF     master   up     2015-06-14  Running
+    originate_to_r10  Static   t_r10    up     2015-06-18  
+    p_master_to_r10   Pipe     master   up     2015-06-18  => t_r10
+    ebgp_r10          BGP      t_r10    up     2015-06-19  Established
+
+Assignments:
+ * 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.
+ * 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.
 
 ## Connecting the internal network, not only edge
 
@@ -403,10 +431,3 @@ picture:
  * BGP needs OSPF to provide internal nexthop towards external router -> recap: BGP trusts on OSPF behaviour
  * small link nets for ebgp sessions need to be in IGP!
  * make it work!
-
-## What about the third network?
-
- * build R1,R2,R3 with 3 containers
- * show AS-path
- * disable link between routers, see traffic being redirected
- * just put some address from the umbrella range on loopback, yolo