It'll pass whatever label is passed on registration. I can send an example... Lou On March 27, 2017 4:32:04 PM Marc Sune <marc@voltanet.io> wrote:
Hi all,
Kind of an aside question about MPLS implementation in FRR;
On Mon, Mar 20, 2017 at 5:38 PM, Thomas Morin <thomas.morin@orange.com> wrote:
Hi everyone,
2017-03-18, Vincent Jardin:
+Thomas to be on track.
Vincent, you'll tell if what is below helped or not :)
Le 18 mars 2017 06:19:47 Vivek Venkatraman <vivek@cumulusnetworks.com> <vivek@cumulusnetworks.com> a écrit :
This is correct. By definition, if a router is the penultimate hop, it means the actual egress is downstream and has signaled (advertised) an implicit-null label to this router. The router doing the PHP knows the next hop to forward to (the egress) without doing any additional lookup.
(Note that with BGP/MPLS VPNs this is the typical behavior, but it is not a mandatory behavior: the egress router may have advertise a real label (i.e. not implicit null) in which case the penultimate router will swap the topmost label of the stack, not seeing/touching the vpn label. This is also a behavior that relates to the use of MPLS for transit, but with MPLS-over-GRE or MPLS-over-UDP, MPLS can be used with IP transit, in which case this behavior is not used).
In regular MPLS processing (no SR), does FRR currently support advertising any label other than implicit NULL for MPLS traffic termination(itself)? And for L2VPNs?
thanks Marc
This behavior should already be supported.
Yes, I can confirm that forwarding via a neighbor on an interface based on the incoming MPLS label is supported. This is what we use in bagpipe IP VPN 'linux' driver [1].
What is not supported (if I remember right) is the ability on the egress to terminate a label and perform a (route) lookup. That is needed to really be able to support any L2/L3 VPN service properly.
I think it is a requirement to have something efficient to trigger a lookup in any {routing table, vrf interface, netns}.
I hadn't tried (because no need). I thought we might achieve something like that by forwarding the packet on 'lo', or on a vrf interface, or on a veth device: wouldn't this kind of next hop specification trigger a re-enter of the packet in the IP stack after the pop operation ?
-Thomas
[1] http://git.openstack.org/cgit/openstack/networking-bagpipe/t ree/networking_bagpipe/bagpipe_bgp/vpn/ipvpn/mpls_linux_dataplane.py#n194
On Thu, Mar 16, 2017 at 10:45 AM, Jeff Tantsura <jefftant@gmail.com> wrote:
Donald,
Wrt PHP, this is incorrect, PHP node MUST not perform IP lookup, or in fact any lookup after POP. In most cases (labeled services, L2/L3 VPN) there's another label(s) in the stack, looking it up would be fatal.
Regards, Jeff
On Mar 15, 2017, at 08:05, Donald Sharp <sharpd@cumulusnetworks.com> wrote:
David/Roopa -
Olivier asked me about these two issues yesterday in the FRR Technical Meeting. I just wanted to make sure I didn't loose track of these questions that he had:
1) More than 2 labels in the kernel at a time, when will this be allowed in the kernel?
-> David is currently working on this issue. When he is done it will be upstreamed. So soonish(tm).
2) PenUltimate Hop Popping:
I know this issue is not trivial to solve. In fact, once the POP instruction perform, the packet must re-enter in the IP packet processing to determine what action must apply. A possible solution would be to process this packet as a new incoming IP packet when output interface is the loopback disregarding the IP address value. But, this issue is less urgent than the first one. Our OSPF Segment Routing implementation could announce if the router works in PenUltimate Hop Poping mode or not. So, for the moment, the option is force to yes.
thanks!
donald
_______________________________________________ frr mailing list frr@lists.nox.tf https://lists.nox.tf/listinfo/frr
_______________________________________________ frr mailing list frr@lists.nox.tf https://lists.nox.tf/listinfo/frr
_______________________________________________ frr mailing list frr@lists.nox.tf https://lists.nox.tf/listinfo/frr
_______________________________________________ frr mailing list frr@lists.nox.tf https://lists.nox.tf/listinfo/frr
---------- _______________________________________________ frr mailing list frr@lists.nox.tf https://lists.nox.tf/listinfo/frr