How to steal a control plane or cooking EIGRP for Juniper

As you know, SDN was originally defined as the ability to physically separate control and data plane. I want to show the realization of this idea without openflow and special controllers. The control plane will be the ODROID-C1 debugging board with IOS running inside Dynamips. As the data plane stands Juniper EX-2200.

The EIGRP protocol will work on the board, build the routing table, and the switch will send data based on this table.

First, I will explain why this choice:

1. EIGRP is a well-known protocol fully implemented only on cisco devices.
2. Juniper - because second most popular vendor
3. The Juniper EX-2200 is the youngest model, so the method will work with all the older ones.
4. ODROID-C1 was chosen due to the “fair” 1G network card (you can use any server with linux).
5. The EX-2200 is smaller than a unit in width, and the debug board fits completely in the free space, so the whole structure fits in 1U and does not require additional rack space

')
How it will work in 2 words:
there is a network built on the equipment cisco, the routing protocol EIGRP. Add a Juniper EX-2200 switch, connect it as "as needed" (that is, as a combat router). We switch on the debug board with Dynamips to the Switch, redirect all the routing protocol service traffic to it. Virtual cisco builds the routing table and redistribute it to the switch. As a result, all traffic with data will be sent to the routing table built by the EIGRP protocol.

So, the test circuit:



for simplicity, the networks are attached to the links, and the last octet of the address always coincides with the device number.

configurations for tsisok:




Configure the switch:


For the redirection of service traffic, port mirroring is used in VLAN with an IP filter overlay (EIGRP).

Dynamyps and Dynagen are installed on the debug board,
collected from source codes, it was emulated 7200.

R15 (virtual cisco)

thus, a direct correspondence of the interfaces between K15 and R15 is obtained:

vlan.1001 - fa0 / 1
vlan.1010 - fa0 / 1.1010
vlan.1011 - fa0 / 0.1011
vlan.1014 - fa1 / 1

Now service traffic gets to odroid with a double tag,
and the responses from our control plane should go to K15 with only one, “second” tag.
for this we stand linux bridges:

ip link add link eth0 v101 type vlan id 101 ip link add link eth0 vl1001 type vlan id 1001 ip link add link eth0 vl1014 type vlan id 1014 brctl addbr br0 brctl addif br0 v101 brctl addif br0 eth0 brctl addif br0 tap0 brctl addif br0 tap1 brctl addif br0 tap2 brctl addif br0 vl1001 brctl addif br0 vl1014 

now we need the packets to be transmitted in accordance with the logic shown by arrows in the figure, and no more.

To do this, we will transfer the bridge to the hub mode (stops learning Macs):

 brctl setageing br0 0 

and we filter everything unnecessary:

  ebtables -A FORWARD -i tap0 -o eth0 -j ACCEPT ebtables -A FORWARD -i tap1 -o vl1001 -j ACCEPT ebtables -A FORWARD -i tap2 -o vl1014 -j ACCEPT ebtables -A FORWARD -i v101 -o tap1 -p ipv4 --ip-source 10.1.0.0/24 -j ACCEPT ebtables -A FORWARD -i v101 -o tap2 -p ipv4 --ip-source 10.14.0.0/24 -j ACCEPT ebtables -A FORWARD -i v101 -o tap0 -p 802_1q -j ACCEPT ebtables -P FORWARD DROP 

in this place we are confronted with the fact that K15 and R15 have the same IP addresses, but different MAC addresses,
which leads to interesting problems, we solve this with the help of ebtables too, for a start we will learn the poppy with which K15 works:

 root@K15> show ethernet-switching table | match router v-R10 78:fe:3d:11:22:33 Static - Router v-R11 78:fe:3d:11:22:33 Static - Router v-R14 78:fe:3d:11:22:33 Static - Router v-S1 78:fe:3d:11:22:33 Static - Router 

now we need all the packages to leave with this poppy:

 ebtables -t nat -A POSTROUTING -o eth0 -j snat --to-src 78:fe:3d:11:22:33 --snat-arp --snat-target ACCEPT ebtables -t nat -A POSTROUTING -o vl1001 -j snat --to-src 78:fe:3d:11:22:33 --snat-arp --snat-target ACCEPT ebtables -t nat -A POSTROUTING -o vl1014 -j snat --to-src 78:fe:3d:11:22:33 --snat-arp --snat-target ACCEPT 

Everything, our “control plane” built RIB:

 R15#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/24 is subnetted, 9 subnets C 10.10.0.0 is directly connected, FastEthernet0/0.1010 C 10.11.0.0 is directly connected, FastEthernet0/0.1011 C 10.14.0.0 is directly connected, FastEthernet1/1 D 10.12.2.0 [90/28416] via 10.14.0.14, 00:53:32, FastEthernet1/1 D 10.12.1.0 [90/28416] via 10.11.0.11, 00:53:32, FastEthernet0/0.1011 D 10.2.0.0 [90/30720] via 10.10.0.10, 00:28:41, FastEthernet0/0.1010 D 10.3.0.0 [90/28672] via 10.14.0.14, 00:08:31, FastEthernet1/1 [90/28672] via 10.11.0.11, 00:08:31, FastEthernet0/0.1011 C 10.1.0.0 is directly connected, FastEthernet0/1 D 10.4.0.0 [90/30720] via 10.14.0.14, 00:03:09, FastEthernet1/1 R15# 

now we need to send this routing information to Juniper,
to do this, we use OSPF and the features of its implementation in the default vendor.
We also add a link and interfaces for the exchange of information between R15 and K15:
K15

 set vlans v-cplane vlan-id 4000 l3-interface vlan.4000 set interfaces ge-0/0/1 unit 0 family ethernet-switching vlan members v-cplane set interfaces vlan.4000 family inet address 100.65.127.129/30 set protocols ospf area 0.0.0.0 interface vlan.4000 hello-interval 1 dead-interval 4 set protocols ospf area 0.0.0.0 interface vlan.1001 passive set protocols ospf area 0.0.0.0 interface vlan.1010 passive set protocols ospf area 0.0.0.0 interface vlan.1011 passive set protocols ospf area 0.0.0.0 interface vlan.1014 passive 

R15

 R15>en R15#conf t R15(config)#interface fa0/0.4000 R15(config-subif)#encapsulation dot1Q 4000 R15(config-subif)#ip address 100.65.127.130 255.255.255.252 R15(config-subif)#ip ospf hello-interval 1 R15(config-subif)#ip ospf dead-interval 4 R15(config-subif)#exit R15(config)#router eigrp 1 R15(config-router)#no auto-summary R15(config-router)#exit R15(config)#router ospf 1 R15(config-router)#network 0.0.0.0 0.0.0.0 area 0 R15(config-router)#redistribute eigrp 1 subnets R15(config-router)#end R15# 

We add rules to ebtables so that the traffic in the 4000th VLAN is passed without changes.
add to the beginning of the chain.

 ebtables -t nat -A POSTROUTING -p 802_1Q --vlan-id 4000 -j ACCEPT ebtables -A FORWARD -i eth0 -o tap0 -p 802_1q --vlan-id 4000 -j ACCEPT 

Check the availability of the necessary routes in the RIB at K15:

 root@K15> show route inet.0: 16 destinations, 16 routes (16 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.1.0.0/24 *[Direct/0] 02:59:01 > via vlan.1001 10.1.0.15/32 *[Local/0] 1d 03:21:44 Local via vlan.1001 10.2.0.0/24 *[OSPF/150] 00:13:16, metric 20, tag 0 > to 10.10.0.10 via vlan.1010 10.3.0.0/24 *[OSPF/150] 00:13:16, metric 20, tag 0 > to 10.14.0.14 via vlan.1014 10.4.0.0/24 *[OSPF/150] 00:13:16, metric 20, tag 0 > to 10.14.0.14 via vlan.1014 10.10.0.0/24 *[Direct/0] 1d 03:21:26 > via vlan.1010 10.10.0.15/32 *[Local/0] 1d 03:21:44 Local via vlan.1010 10.11.0.0/24 *[Direct/0] 1d 03:21:26 > via vlan.1011 10.11.0.15/32 *[Local/0] 1d 03:21:44 Local via vlan.1011 10.12.1.0/24 *[OSPF/150] 00:13:16, metric 20, tag 0 > to 10.11.0.11 via vlan.1011 10.12.2.0/24 *[OSPF/150] 00:13:16, metric 20, tag 0 > to 10.14.0.14 via vlan.1014 10.14.0.0/24 *[Direct/0] 1d 03:21:27 > via vlan.1014 10.14.0.15/32 *[Local/0] 1d 03:21:44 Local via vlan.1014 100.65.127.128/30 *[Direct/0] 01:01:08 > via vlan.4000 100.65.127.129/32 *[Local/0] 01:01:08 Local via vlan.4000 224.0.0.5/32 *[OSPF/10] 01:01:09, metric 1 MultiRecv 

routes are in place, all servers are pinging.

launch iperf and pump traffic between S1-S3 and S2-S4:

 root@S3:~# iperf -c 10.1.0.1 -t 10 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 10.1.0.1, TCP port 5001 TCP window size: 413 KByte (default) ------------------------------------------------------------ [ 5] local 10.3.0.3 port 33375 connected with 10.1.0.1 port 5001 [ 4] local 10.3.0.3 port 5001 connected with 10.1.0.1 port 51122 [ ID] Interval Transfer Bandwidth [ 5] 0.0-10.0 sec 1.09 GBytes 939 Mbits/sec [ 4] 0.0-10.0 sec 1.08 GBytes 928 Mbits/sec 

 root@S4:~# iperf -c 10.2.0.2 -t 10 -d ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 10.2.0.2, TCP port 5001 TCP window size: 82.5 KByte (default) ------------------------------------------------------------ [ 5] local 10.4.0.4 port 59485 connected with 10.2.0.2 port 5001 [ 4] local 10.4.0.4 port 5001 connected with 10.2.0.2 port 41829 [ ID] Interval Transfer Bandwidth [ 5] 0.0-10.0 sec 111 MBytes 92.5 Mbits/sec [ 4] 0.0-10.3 sec 102 MBytes 83.2 Mbits/sec 

make sure that normal traffic runs wire speed.
at the same time, during the entire testing time, the EIGRP neighborhood is not broken.
and that’s what they wanted.

limitations:
1. link aggregation is not considered.
2. Considered option only for RVI (Routed VLAN Interface).
3. Traffic balancing does not work, only one route is given to the switch.
4. slow convergence of the routing protocol, since based only on hello packages (the control plane does not see the port status and there is no BFD)
5. about 6-7 times the complicated configuration, since instead of one protocol on one device, we set up a whole set of protocols and rules on actually 3 entities.