Difference between revisions of "Project rockhammer"
Jump to navigation
Jump to search
m |
(add a few notes from last night's session) |
||
| Line 1: | Line 1: | ||
| + | = Design Goals = | ||
| + | * consistant platform, consistant behavior | ||
| + | * unified configuration to ease provisioning and maintenance, promote familiarity. | ||
| + | * reliability: at least to the level provided by the underlying OS. preferrably more. | ||
| + | * easily documented | ||
| + | |||
= Software Architecture = | = Software Architecture = | ||
* '''(early)''' pf for filtering, NAT, filter-forwarding, etc. | * '''(early)''' pf for filtering, NAT, filter-forwarding, etc. | ||
* '''(late)''' carp for redundancy (failover/load balancing)? | * '''(late)''' carp for redundancy (failover/load balancing)? | ||
| + | * same platform for any hardware combination | ||
= Hardware Architecture = | = Hardware Architecture = | ||
| Line 8: | Line 15: | ||
= Configuration = | = Configuration = | ||
| − | * '''( | + | * '''(phase 1)''' single config file |
| + | * '''(phase 2)''' config shell | ||
* '''(!)''' candidate vs committed configuration | * '''(!)''' candidate vs committed configuration | ||
| + | * currently, a reboot will sync on-disk config to in-core, but no mechanism exists to do the opposite (in core -> on disk): this is the real problem to solve, and the biggest win. | ||
| + | |||
| + | = C-F plane link = | ||
| + | * Underlying UDP transport from dedicated NIC on each plane | ||
| + | * Should work fine for single-machine setup, maybe use unix socket in this case for performance? | ||
| + | * Probably best written in C eventually: a prototype in a higher level language is a prudent step | ||
| + | * Custom protocol, custom code: optimized flow for operations. | ||
| + | * Caching routing table on forwarding plane? Has some interesting benefits and drawbacks, and warrants its own section here.. (TODO) | ||
| + | |||
| + | = Design Problems = | ||
| + | * Source packets from control plane, but really source them from forwarding plane: NAT tricks, or ssh-rcmd? | ||
| + | * pf config in single config file: parse it, embed it inline, ? | ||
| + | * heavy use of regression testing would be beneficial. | ||
| + | * how does one update the system? | ||
| + | |||
| + | = Misc Notes = | ||
| + | * All custom code/patches should be considered for submission to upstream repositories: written with this in mind. Use generic mechanisms that could be useful to others. | ||
Revision as of 16:13, 29 September 2011
Design Goals
- consistant platform, consistant behavior
- unified configuration to ease provisioning and maintenance, promote familiarity.
- reliability: at least to the level provided by the underlying OS. preferrably more.
- easily documented
Software Architecture
- (early) pf for filtering, NAT, filter-forwarding, etc.
- (late) carp for redundancy (failover/load balancing)?
- same platform for any hardware combination
Hardware Architecture
- (early) simple single-machine model for proof-of-concept, lower-end device
- (late) multiple machines in a single chassis, split control/forwarding plane
Configuration
- (phase 1) single config file
- (phase 2) config shell
- (!) candidate vs committed configuration
- currently, a reboot will sync on-disk config to in-core, but no mechanism exists to do the opposite (in core -> on disk): this is the real problem to solve, and the biggest win.
C-F plane link
- Underlying UDP transport from dedicated NIC on each plane
- Should work fine for single-machine setup, maybe use unix socket in this case for performance?
- Probably best written in C eventually: a prototype in a higher level language is a prudent step
- Custom protocol, custom code: optimized flow for operations.
- Caching routing table on forwarding plane? Has some interesting benefits and drawbacks, and warrants its own section here.. (TODO)
Design Problems
- Source packets from control plane, but really source them from forwarding plane: NAT tricks, or ssh-rcmd?
- pf config in single config file: parse it, embed it inline, ?
- heavy use of regression testing would be beneficial.
- how does one update the system?
Misc Notes
- All custom code/patches should be considered for submission to upstream repositories: written with this in mind. Use generic mechanisms that could be useful to others.