Difference between revisions of "Project rockhammer"
Jump to navigation
Jump to search
(early concept revision :)) |
m (6 revisions) |
||
| (5 intermediate revisions by the same user not shown) | |||
| 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 |
| − | * '''!''' candidate vs committed configuration | + | * '''(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? | ||
| + | |||
| + | = Lessons Learned Elsewhere = | ||
| + | * "commit confirmed": best to avoid hosing oneself. | ||
| + | * a well organized hierarchical config is easier to read and maintain | ||
| + | * easily accessed inline/onboard help (syntax and reference) is a GOOD thing | ||
| + | * allow access to inspect all components, but don't make it a requirement | ||
| + | * having a real onboard editor, and valid [configurable] line editing makes people happy. | ||
| + | * read-only root filesystem and ramdisks makes for a survivable system | ||
| + | * give the people what they want: OpenVPN, SSH | ||
| + | |||
| + | = 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. | ||
| + | |||
| + | = Reference Links = | ||
| + | * [http://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/ OpenBSD rdomain tutorial @ packetmischief.ca] | ||
Latest revision as of 21:52, 4 January 2013
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?
Lessons Learned Elsewhere
- "commit confirmed": best to avoid hosing oneself.
- a well organized hierarchical config is easier to read and maintain
- easily accessed inline/onboard help (syntax and reference) is a GOOD thing
- allow access to inspect all components, but don't make it a requirement
- having a real onboard editor, and valid [configurable] line editing makes people happy.
- read-only root filesystem and ramdisks makes for a survivable system
- give the people what they want: OpenVPN, SSH
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.