Contributed by johan on from the big-in-japan dept.
I just came back from a nice trip to japan. As people may have noticed I did a presentation about the OpenBSD network stack internals and some upcoming changes inside it.
Thanks Claudio for sending us this blog and thanks for all the hard work you have put into OpenBSD.I crammed as much information into the available 45min slot as possible and still only covered the tip of the iceberg. The correct use of mbufs itself would fill a full presentation. This comes from the fact that many mbuf functions have more or less nasty side effects. The main idea of the talk was to explain how packets flow through the network stack. I hope this may help other people to untangle the maze of calls.
All in all AsiaBSDCon was a very nice event. A good occasion to meet and talk to other people. Unfortunately mine was the only OpenBSD talk however I can recommend it to everyone and I hope next year more OpenBSD papers are presented and more OpenBSD people are joining the event.
Now I'm back home and the world is not standing still. First of all the plan to get MPLS support into OpenBSD is getting more concrete. norby@, laurent@ and I started again to bring the old ayame code base ready for OpenBSD. There is still a lot missing, the label switching process is very different to routing. The routing code does a longest prefix lookup on the destination; while label switching does a perfect match on the incoming interface label pair, and then a push, pop or swap operation changes the label in the packet. Our routing code is currently not able to represent such a logic in a clean way. The other huge missing piece is LDP -- the label distribution protocol -- necessary to setup label switch paths in a dynamic fashion.
In less than a month a network hackathon will happen and hopefully we will get some of the code committed. If people are interested in helping out with testing or writing missing code don't hesitate to contact me.
Please donate to the project in order to make sure we can have this and other hackathons further down the road!
(Comments are closed)
By Anonymous Coward (84.206.25.236) on
And what about the full VRF support??? The 4.4 release will include it?
Comments
By Lennie (194.213.15.37) on
By Anonymous Coward (213.185.19.190) on
By Pete (195.1.147.126) on
However I believe the majority of larger MPLS net use ISIS instead of OSPF for the internal IGP (for BGP next-hop reachability etc). Quoted advantages range from faster convergence, through simpler codebase, to ahead in protocol advances e.g. TE implementation. Maybe OpenISIS is in the pipes ?
Secondly, I know much of the multiple table stuff is done, but most of the tools have yet to gain support for it yet (they only operate on table 0). This may not matter much on a pure P device, but on a PE they are definitely required. The stability of multiple table devices is (was) also not great - a fixed N tables was fine, but repeated adding/removing of tables dynamically caused problem (and is needed for decent MPLS net), don't know if this opinion is dated now though ?
We'll I guess I'll shut up and donate now, since that's the quickest way to better code ;-)
/Pete
Comments
By Claudio Jeker (62.48.30.130) claudio@ on
>
> However I believe the majority of larger MPLS net use ISIS instead of
> OSPF for the internal IGP (for BGP next-hop reachability etc). Quoted
> advantages range from faster convergence, through simpler codebase,
> to ahead in protocol advances e.g. TE implementation. Maybe OpenISIS
> is in the pipes ?
Currently we need to bring ospf6d and dvrmpd into usable shape
additonally for MPLS we will look at LDP. When that is done I may start
considering isisd.
> Secondly, I know much of the multiple table stuff is done, but most
> of the tools have yet to gain support for it yet (they only operate
> on table 0). This may not matter much on a pure P device, but on a PE
> they are definitely required. The stability of multiple table devices
> is (was) also not great - a fixed N tables was fine, but repeated
> adding/removing of tables dynamically caused problem (and is needed
> for decent MPLS net), don't know if this opinion is dated now though?
VRF and MPLS are two overlapping projects I'm currently working on. The
code I have to support multiple routing domains is making slow progress.
Initial bits should develop in parallel to MPLS.
About the problems with multiple tables; I think some of the bugs have
been fixed, not sure if all critical issues got covered.
By Anonymous Coward (193.25.105.76) on
By nuintari (64.246.109.27) on
Comments
By Claudio Jeker (62.48.30.130) claudio@ on
> the core developers were opposed to MPLS in OpenBSD. Something about,
> a recreation of ATM, did I dream this statement?
Yes, you must have dreamt that. MPLS is not the greatest thing but it
is a necessary evil.
Comments
By sthen (2a01:348:108:155:20a:e4ff:fe2d:99ee) on
> > the core developers were opposed to MPLS in OpenBSD. Something about,
> > a recreation of ATM, did I dream this statement?
>
> Yes, you must have dreamt that. MPLS is not the greatest thing but it
> is a necessary evil.
>
ah, that'll be this one - now softened from "evil" to "necessary evil" (and, I agree :)
http://marc.info/?m=113654771822707
Comments
By nuintari (64.246.109.27) on
> > > the core developers were opposed to MPLS in OpenBSD. Something about,
> > > a recreation of ATM, did I dream this statement?
> >
> > Yes, you must have dreamt that. MPLS is not the greatest thing but it
> > is a necessary evil.
> >
>
> ah, that'll be this one - now softened from "evil" to "necessary evil" (and, I agree :)
> http://marc.info/?m=113654771822707
>
I'm not crazy!
By Anonymous Coward (81.83.46.237) on
By Anonymous Coward (128.171.90.200) on
By Rob Sessink (2001:610:64b:6:217:31ff:fe26:9760) on
In what for an environments would OpenBSD + MPLS be used ? As a PE router for VPN routing at ISP's or large networks ?
Regards Rob
Comments
By Benny (203.111.73.67) on
>
> In what for an environments would OpenBSD + MPLS be used ? As a PE router for VPN routing at ISP's or large networks ?
>
> Regards Rob
You can take advantage of separate routing tables for things like control plane segregation even on small networks. eg make sure wireless AP cloud can only traverse the routers and even if your exposed OSPF gets hacked your other core OSPF (bring on ISIS) remains untouched.
Stylin move
By Lawrence Teo (lteo) lteo.openbsd1 ! calyptix.com on http://www.calyptix.com/
Don't forget to check out Claudio's paper (PDF) too.
Claudio: Thank you for the excellent writeup and slides!