So, I was wondering why I frequently got disconnected from IRC and it turns out OSPF starts acting like multipath routing when you feed it two equal cost paths. To show and prove what’s happening.

ospf-multipathrouting-woooheeee

It doesn’t stop here. If we look at the reverse path – from internet to clients – we notice the same happens because there are two equal intranet routers available.

vyatta@louise# sudo tcpdump -tnei eth0.12 not src net 172.20.0.0/22 and dst net 172.20.0.0/22 and not multicast | grep 54:43
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.12, link-type EN10MB (Ethernet), capture size 65535 bytes
20:6a:8a:3b:41:5a > dc:9f:db:28:54:43, ethertype IPv4 (0x0800), length 1454: 109.93.1.130.38077 > 172.20.1.201.61799: Flags [.], seq 3285290671:3285292059, ack 3146783506, win 256, options [nop,nop,TS val 3321908 ecr 271449236], length 1388
20:6a:8a:3b:41:5a > dc:9f:db:28:54:43, ethertype IPv4 (0x0800), length 54: 78.127.216.246.6881 > 172.20.1.68.16741: Flags [.], ack 2269875688, win 3072, length 0
20:6a:8a:3b:41:5a > dc:9f:db:28:54:43, ethertype IPv4 (0x0800), length 54: 78.127.216.246.6881 > 172.20.1.68.16741: Flags [.], ack 2905, win 3072, length 0
20:6a:8a:3b:41:5a > dc:9f:db:28:54:43, ethertype IPv4 (0x0800), length 54: 78.127.216.246.6881 > 172.20.1.68.16741: Flags [.], ack 5809, win 3072, length 0
[...]
^C108 packets captured
114 packets received by filter
0 packets dropped by kernel

[edit]

vyatta@louise# sudo tcpdump -tnei eth0.12 not src net 172.20.0.0/22 and dst net 172.20.0.0/22 and not multicast | grep -v 54:43
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.12, link-type EN10MB (Ethernet), capture size 65535 bytes
20:6a:8a:3b:41:5a > 24:a4:3c:05:fe:8e, ethertype IPv4 (0x0800), length 1254: 69.81.139.163.55597 > 172.20.1.201.61894: Flags [.], seq 724172768:724173956, ack 4069725010, win 65535, options [nop,nop,TS val 962663161 ecr 271463979], length 1188
20:6a:8a:3b:41:5a > 24:a4:3c:05:fe:8e, ethertype IPv4 (0x0800), length 1444: 86.163.212.128.51413 > 172.20.1.201.59594: UDP, length 1402
20:6a:8a:3b:41:5a > 24:a4:3c:05:fe:8e, ethertype IPv4 (0x0800), length 788: 86.163.212.128.51413 > 172.20.1.201.59594: UDP, length 746
^C224 packets captured
224 packets received by filter
0 packets dropped by kernel

[edit]
vyatta@louise# run show arp | grep fe:8e
172.20.0.34              ether   24:a4:3c:05:fe:8e   C                     eth0.12
[edit]
vyatta@louise# run show arp | grep 54:43
172.20.0.35              ether   dc:9f:db:28:54:43   C                     eth0.12
[edit]
vyatta@louise# run show ip route forward 172.20.1.64/27
172.20.1.64/27  proto zebra  metric 20
        nexthop via 172.20.0.34  dev eth0.12 weight 1
        nexthop via 172.20.0.35  dev eth0.12 weight 1
[edit]
vyatta@louise# run show ip route 172.20.1.64/27
Routing entry for 172.20.1.64/27
  Known via "ospf", distance 110, metric 20, best
  Last update 00:42:01 ago
  * 172.20.0.34, via eth0.12
  * 172.20.0.35, via eth0.12

[edit]

It’s interesting to note that the second internet router runs pfsense and doesn’t support OSPF multipath routing. I’m not sure because it’s FreeBSD or because pfsense.

pfsenseb

pfsense
We can conclude I’m running a full fledged multipath routing network where forward and reverse traffic might take totally different paths.