On Fri, Jan 04, 2008 at 01:42:19PM +0200, Mihai Chelaru wrote: > David Young wrote: > >MPLS decap/encap appears to be intricately entwined with ether_output, > >ip_output, ip_input, et cetera. That doesn't seem right. Instead, I > >think that there should be a pseudo-interface, mpls0, whose input/output > >routines do decap/encap, respectively. This de-clutters the IPv4/IPv6 > >stacks and the ethernet code, and it provides a location for tapping > >packets with tcpdump before encapsulation and after decapsulation. > > > > Hi, > > I had an idea at one moment to create an pseudo-interface for every > neighbor and route packets through those pseudo-interfaces. Also one > single interface was a pre-option. But I don't think this will be very > intuitive and I didn't see any vendor reporting something similar to > this so I assume no one does it. Last night, I scanned the web for MPLS configuration examples, and all that I found was Cisco IOS, which was not very compelling, and a discussion on an OpenSolaris forum which, albeit vague, did mention an MPLS pseudo-interface, <https://www.opensolaris.org/jive/thread.jspa?messageID=33315>. I don't think that the word "intuitive" really applies to MPLS, and it is a vague word that deserves to be defined in any discussion, <http://www.asktog.com/papers/raskinintuit.html>. I think that it will be helpful if MPLS uses familiar abstractions in familiar ways; using a pseudo-interface to add/subtract encapsulation is familiar to users of VLANs and tunnels. > Also this raises another problem: I could do this if NetBSD would have a > clear difference between control and forwarding but this is not the case > and I don't want to change the ifa/p for a route without a very strong > reason. You seem to have a precise meaning in mind, but what you have written is vague. Can you elaborate on this lack of control/forwarding separation as it applies to ifa/ifp and MPLS? > Btw, tcpdump decapsulates the MPLS frames and reports the inner IP > packets generating an output like this: > > 13:32:20.880484 MPLS (label 20, exp 0, [S], ttl 64) > IP (tos 0x0, ttl 64, id 17838, offset 0, flags [none], proto > UDP (17), length 71) 193.28.151.120.50013 > 193.28.151.5.53: [udp sum >ok] 29453+ PTR? 2.116.208.68.in-addr.arpa. (43) > > Are you interested in catching IP packets before shim push/pop for some > other reasons ? Yes, I am. I also believe it makes the system a lot more transparent and comprehensible to use a pseudo-interface. We have the opportunity to apply a packet filter or to tap packets. Tapping packets is an essential aid for troubleshooting. (IMO, a deficiency of IPSec in NetBSD is that it does not use pseudo-interfaces, even when it does tunnel-like things like IPSEC_NAT_T.) > >There are several fragments of code like this, > > > > if (m->m_len < sizeof (struct ip) && > > (m = m_pullup(m, sizeof(struct ip))) == NULL) > > return ENOBUFS; > > > >that should be written like this, > > > > if (M_UNWRITABLE(m, sizeof(struct ip)) && > > (m = m_pullup(m, sizeof(struct ip))) == NULL) > > return ENOBUFS; > > > >instead. > > I'm not sure about that. True, I should check M_READONLY but in a > mandatory way where I actually want to write data into that mbuf. But > should I check if it's readonly for cases like the m_push_inet{6}() > where I prepend and modify only the prepended data ? No, you don't need to use it if you will only read the data. I suggest extracting a const pointer to the data with mtod, then. Dave -- David Young OJC Technologies dyoung%ojctech.com@localhost Urbana, IL * (217) 278-3933 ext 24