So I went through and marked all the rules as “stateless”. Next trick is to make the ruleset stateless since we have asymmetric routing due to BGP peering… no simple in-out single default route here. Some tweaking of inbound/outbound/both parameters and addition of the generic “any/any both on loopback” and we looked to be in business. I ended up needing to go line-by-line through the ACL to ensure that the generated fwbuilder line was correct and efficient. Hmm – some slight anomalies with the import from an IOS access-list into iptables equivalent rules. Right, I ought to migrate them too.Ĭlickety click, a copy and paste and an import into fwbuilder. At this point I nearly progressed but then remembered the ACLs on the eBGP peering interface. I had double checked the iBGP and eBGP configuration, including route-maps, prefix lists, etc on the Linux router so I was pretty confident of success. no “shutdown” the eBGP peer on the Linux router.up the peering interface on the Linux router.shutdown the peering interface on the Cisco router.shutdown the eBGP peer on the Cisco router.I also added the eBGP peer’s configuration to the bgpd instance with an included “shutdown” statement.Īt this point, I figured all that would be needed to switch over would be to Added the peering /30 subnet to a VMNIC (did not up the interface in the VM nor on the host – nothing like double protection), added said subnet to the OSPF configuration (so next hop address would be available) to be propagated when the interface is up. So I did some configuration work in preparation for the eBGP peering. BGP and OSPF routes were being exchanged and routing (routes advertised out OSPF) was happening to a newly created test subnet behind the Linux router. I then added the BGP (iBGP initially) component and checked for route propagation – which worked. I did it in steps – first added the Linux box into the existing OSPF area 0 and checked routes were sent and received. I did a functional test in a lab where I swapped out a border BGP/OSPF speaking router with a Linux VM and Quagga. Technically – yes a Linux server coupled with Quagga can do a similar routing function to a Cisco router. Any given deployment scenario is different and the various requirements and their associated costs, benefits and risks need to be evaluated. Now – how viable or wise this would be depends on one’s circumstances so I don’t expect everyone to agree – this raises similar debate points as the debate around the wisdom of virtualising a VMware Virtual Center server instance. A benefit of this is that it is possible to use a Linux VM to do this, if one so wishes. Given how expensive data-centre space and power is, I thought I would evaluate using a Linux server in place of a Cisco router. I thought I’d write a quick post on using Linux and Quagga (zebra, ospfd and bgpd) in place of a Cisco router.
0 Comments
Leave a Reply. |