overview of implementations
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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 as appropriate
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