120 likes | 237 Views
Overview of implementations. openBGP (and openOSPF) Active development Zebra Commercialized Quagga Active development XORP Hot Gated Dead/commercialized now Other…. GateD. One of the first open source implementations Now commercialized by nexthop Code is closed source now
E N D
Overview of implementations • openBGP (and openOSPF) • Active development • Zebra • Commercialized • Quagga • Active development • XORP • Hot • Gated • Dead/commercialized now • Other…
GateD • One of the first open source implementations • Now commercialized by nexthop • Code is closed source now • Last open gated version was out in 1999 • Original gated • All protocols inside a single process • Even based scheduling • Rich support for timers, memory management
Zebra and Quagga • Zebra started in 1996 in Japan • Last release in 2003 • Multiple processes one for each protocol • Corporate sponsor ipInfusion • Code still open though • Quagga • Based on zebra • Uses a more decentralized development model • More active • Last release in late 2006
openBGPd • 3 processes • Master • Control • Updates the routing table of the host • session manager • Maintain connections with peers • FSM • route decision engine • Computes routers • Originates UPDATE messages • Claims to be very • Fast and • Memory efficient
Security? • Each process in a jail • Only master has root access • Split in multiple processes is good • Routing worms • A router is infected • Propagates bad information and infects other routers • Usually bugs are in the parsing code, • Parsing code is isolated in the session manager • a bug in the parsing code can result in taking over the session manager • Router can drop peerings • Decision process is unaffected • Unfortunately the session manager is responsible for sending the update messages • Worms can propagate
Details • Each based around a polling loop as usual • Timers in the polling loop • No attempt for scalable timer library • Not too many timers, one per peer • Scheduling of long running operations? • Does not seem to have any limits • Any number of messages can be exchanged when processing routes • Rib walks continue until their end • openOSPF • Very similar design • Both openBGPd and openOSPF • Are isolated processes • Not a complete routing stack
XORP • Multiprocess routing stack • RIB, BGP, OSPF, manager • All in separate OS processes • Focus on extensibility • Through standardized APIs between components • Through extensible CLI etc… • Communicate through XRL • A type URL for exchanging information between components • E.g finder://bgp/AS6567/set_router_id=4.5.6.7 • They are ASCII so it is easy to script, log, etc… • Forwarding Engine Abstraction • Unified way to talk to any kind of forwarding plane
Implementation details • Event based architecture again • Uses an event loop that handles reading from descriptors and timers • Timer scaling • Should be good they use a heap and controlled expiration • Memory allocator? • Not clear they do something special • Event granularity • Nothing special • Delete safe iterators! • But no versioning and apparently no interruption • Register for notification for BGP next-hop changes • Detect birth/death of processes and restart asappropriate
Interesting policy manager • Focus on extensibility • Multiple filters • Inside protocols • To the rib, from the rib • Redistribution • Route tags • Programmable rules • Programmable attributes • Implement a stack machine for the filtering
Security • Sandboxing between components • Using XEN? • Some attempt to control unauthorized API exchanges • Break a component in more parts • To avoid propagation of malicious code • Separate message parsing from routing decisions or message generation
The open source router proposition • Vyatta: Open source router based on XORP • Commodity hardware • Open source s/w • Sounds good but: • S/W is always behind in features • Small forwarding capacity • Reliability is an issue • No redundancy in power supplies etc • Limited hardware support • Can not find easily sonet, ATM, E1/T1 cards etc • Some open source components may need work • Hardening of the linux OS • Optimization of applications (packet filtering etc…)
In summary • XORP • Open source • Centralized development • Well architected • Fairly complete • Good performance/scalability • Quagga • Active development • Large developer community • So and so performance/scalability • OpenBGP not a complete routing stack • The rest are proprietary or not very active anymore