On 02/06/15 17:15, roopa wrote:
On 6/1/15, 9:46 AM, Robert Shearman wrote:
Allow creating an mpls device for the purposes of encapsulating IP
packets with:
ip link add type ipmpls
This device defines its per-nexthop encapsulation data as a stack of
labels, in the same format as for RTA_NEWST. It uses the encap data
which will have been stored in the IP route to encapsulate the packet
with that stack of labels, with the last label corresponding to a
local label that defines how the packet will be sent out. The device
sends packets over loopback to the local MPLS forwarding logic which
performs all of the work.
Maybe a silly question, but when you loop the packet back, what does the
local MPLS forwarding logic
lookup with ? It probably assumes there is a mpls route with that label
and nexthop.
Will this need any internal labels (thinking same label stack different
tunnel device etc) ?
Yes, it requires that local/internal labels have been allocated and
label routes installed in the label table for them.
It is entirely possible to put the outgoing interface into the encap
data to avoid having to allocate extra labels, but I did it this way in
order to support PIC Core for MPLS-VPN routes.
Note: I have two extra patches which avoid using the loopback device
(which causes the TTL to end up being one less than it should on
output), but I haven't posted them here because they were dependent on
other mpls changes in my tree.
Thanks,
Rob
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
