On Thu, Jun 4, 2015 at 11:46 AM, Robert Shearman wrote:
> On 03/06/15 19:43, Vivek Venkatraman wrote:
>>
>> On Tue, Jun 2, 2015 at 2:06 PM, Robert Shearman
>> wrote:
>>>
>>> On 02/06/15 19:57, roopa wrote:
On 6/2/15, 9:33 AM, Robert Shearman wrote:
>
>
> On 02/06/15 17:
On 03/06/15 19:43, Vivek Venkatraman wrote:
On Tue, Jun 2, 2015 at 2:06 PM, Robert Shearman wrote:
On 02/06/15 19:57, roopa wrote:
On 6/2/15, 9:33 AM, Robert Shearman wrote:
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
On Tue, Jun 2, 2015 at 2:06 PM, Robert Shearman wrote:
> On 02/06/15 19:57, roopa wrote:
>>
>> On 6/2/15, 9:33 AM, Robert Shearman wrote:
>>>
>>> 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 encap
On 06/02/15 at 06:23pm, Eric W. Biederman wrote:
> Thomas I may have misunderstood what you are trying to do.
>
> Is what you were aiming for roughly the existing RTA_FLOW so you can
> transmit packets out one network device and have enough information to
> know which of a set of tunnels of a give
Thomas Graf writes:
> On 06/02/15 at 01:26pm, Eric W. Biederman wrote:
>> What we really want here is xfrm-lite. By lite I mean the tunnel
>> selection criteria is simple enough that it fits into the normal
>> routing table instead of having to do weird flow based magic that
>> is rarely needed.
Thomas Graf writes:
> On 06/02/15 at 01:26pm, Eric W. Biederman wrote:
>> What we really want here is xfrm-lite. By lite I mean the tunnel
>> selection criteria is simple enough that it fits into the normal
>> routing table instead of having to do weird flow based magic that
>> is rarely needed.
On 06/02/15 at 01:26pm, Eric W. Biederman wrote:
> What we really want here is xfrm-lite. By lite I mean the tunnel
> selection criteria is simple enough that it fits into the normal
> routing table instead of having to do weird flow based magic that
> is rarely needed.
>
> I believe what we want
On 02/06/15 19:57, roopa wrote:
On 6/2/15, 9:33 AM, Robert Shearman wrote:
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-nextho
On 6/2/15, 9:33 AM, Robert Shearman wrote:
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 o
Robert Shearman writes:
> 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 ha
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_NEWS
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 w
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 encaps
13 matches
Mail list logo
