1 / 12

Overview of implementations

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

jefferye
Download Presentation

Overview of implementations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Overview of implementations • openBGP (and openOSPF) • Active development • Zebra • Commercialized • Quagga • Active development • XORP • Hot • Gated • Dead/commercialized now • Other…

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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…)

  12. 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

More Related