Overview of implementations

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_id4.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 as
  appropriate

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