overview of implementations

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

Upload: rigg

Post on 05-Jan-2016

24 views

Category:

Documents


1 download

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 Presentation

TRANSCRIPT

Page 1: Overview of implementations

Overview of implementations• openBGP (and openOSPF)

– Active development

• Zebra– Commercialized

• Quagga– Active development

• XORP– Hot

• Gated– Dead/commercialized now

• Other…

Page 2: Overview of implementations

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

Page 3: Overview of implementations

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

Page 4: Overview of implementations

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

Page 5: Overview of implementations

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

Page 6: Overview of implementations

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

Page 7: Overview of implementations

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

Page 8: Overview of implementations

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

Page 9: Overview of implementations

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

Page 10: Overview of implementations

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

Page 11: Overview of implementations

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

Page 12: Overview of implementations

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