In this post, I demonstrate how to define MPLS LSPs dynamically using a lightweight BGP-LU controller, even though the underlying network does not run BGP-LU at all.
The transport inside the network is built entirely on IS-IS Segment Routing, while a dedicated BGP-LU session exists only between the router and the controller.
This design makes it possible to inject labeled routes externally and influence forwarding behavior without modifying the SR fabric.
Architecture Summary and Topology
The internal topology uses IS-IS SR for label allocation and forwarding:
- Node-SIDs
- Adjacency-SIDs
- SRGB mappings
- Native SR MPLS dataplane
There is no LDP, RSVP, or BGP-LU inside the network.
Only one BGP-LU session exists with yaBGP controller and R1 router.
This keeps the SR domain untouched while giving the controller the authority to define external MPLS LSPs through labeled route injection.
Why Define LSPs Through a Controller?
This model mirrors real operator designs:
- The SR network handles internal reachability
- The controller injects “policy routes” using BGP-LU
- Label values are dynamically manipulated
- Traffic engineering experiments become extremely simple
- The controller effectively defines the headend’s LSP behavior
It is similar to how a PCE or an SR-TE orchestrator influences MPLS forwarding without interfering with the IGP.
yaBGP Installation and Configuration
We reference the documentation for yaBGP installation. As controller, we need a BGP session between yaBGP controller and our ingress R1 router, which is PE router. We will manipulate the label route by sending labels from controller to this router.
We will establish BGP on management interface of R1 router and controller interface. yaBGP configuration will be as below:
(yabgp-venv) root@ubuntu:~/yabgp/bin# python yabgpd --bgp-local_addr=172.22.111.41 --bgp-remote_addr=172.22.111.99 --bgp-local_as=1 --bgp-remote_as=1 --bgp-afi_safi=ipv4,ipv4_lu
Above, I am using virtuan environment, and command is run under /yabgp/bin.
R1 shows BGP is up with controller:
Using Postman for REST API
As soon as you run BGP commands in yaBGP, there will API endpoint for that BGP, which is http://172.22.111.41:8801/
Remember that, default API user is admin/admin. You can change it in config file. Since there is API endpoint, we can send some attributes via POSTMAN. Attributes or other manipulation is also references in yaBGP documentation. It is not our scope.
We will send a label stack to steer traffic from R1 to R6, 66.6.6.6. But traffic will pass through R2 and R5.
As you see below, there is no route for 66.6.6.6 in R1 before implementation.R6 is not advertising it.
now, let’s send label stack from postman:
API endpoint is http://172.22.111.41:8801/v1/peer/172.22.111.99/send/update. Please check body carefully:
After post, let’s check R1 route table: As you see below, R1 will make label to packet for destination 66.6.6.6.
Packet Forwarding
When R1 sends a packet to destination 66.6.6.6, it will send to 10.0.0.2 as nexthop. Because it gets route information from the controller. This packet will have label stack 900005 900006 as mpls label.
As soon as R2 receives the packet, it will check its label forwading table. Since the packet has 900005 on top of label field, it will be popped according to forwarding table. 900005 will be removed, 900006 will remain on packet’s label field. Now, the packet will send to R5.10.5.5.2 is R5.
The packet has 900006 label and it reaches to R5. R5 will check its label forwading table. 900006 will be popped and will be sent to ethernet 4 for egress. Now, the packet has no label.
When R6 receives unlabeled packet, it will check its normal ip routing table and will evalute the packet.
Conclusion
Using a BGP-LU controller to define MPLS LSPs on top of an IS-IS Segment Routing network provides extraordinary flexibility without touching the core IGP.
This architecture is ideal for TE experiments, POC studies, and BGP-based label manipulation.
Outputs
