Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MPLSWatcher - Labels, LSPs, Mappings. #53

Open
fischerdouglas opened this issue Nov 16, 2024 · 3 comments
Open

MPLSWatcher - Labels, LSPs, Mappings. #53

fischerdouglas opened this issue Nov 16, 2024 · 3 comments

Comments

@fischerdouglas
Copy link

This tools are incredible! Excellent work!
I will adopt and recommend it.

Have you considered an equivalent view of MPLS things?
At least the basic Labels.
But it would be great if it could show LSPs.
Even greater if would permit to see the L2/L3 vs Labels vs PEs Mappings.

@Vadims06
Copy link
Owner

Vadims06 commented Nov 16, 2024

thanks @fischerdouglas for the feedback!

Have you considered an equivalent view of MPLS things?

yes, I have, but I'm limited by Topolograph design to get maximum what I can get from the network via a single connection to it :) Since Topolograph builds its network view from LSDB, I can onboard to Topolograph everything what LSDB has. In the sense of LSP - it would require a connection to PE routers and getting details about ingress/transit/egress LSP (output also depends on vendor). It's not a problem from network automation perspective - it's possible to achieve vendor agnostic via Netbox and prepare get_lsp methods for each vendor, but I think it should be outside of Topolograph and implemented in topolograph's SDK (it doesn't exist right now ;). In the end, the process of onboarding and tracking LSPs into Topolograph would look like this:

  • systemd runs the script, which
  1. get network devices from local Netbox by the role - PE
  2. make a call get_lsp to all network entities from step 1
  3. upload it to Topolograph via Topolograph's API
    Add more details if I missed something)

Regarding labels - I can onboard Source Routing labels, since they are shared in LSDB across area.

L2/L3 vs Labels vs PEs Mappings.

L2/L3 mapping it's a challenging task where Netbox may be also helpful. If we have routerA with established Adj to routerB we can build L2/L3 mapping if Netbox has routerA and routerB with all links filled into it, then we can make a call Hey, give me all links between routerA and routerB. But it requires to:

  1. have Netbox
  2. fill Netbox with network devices and links between them.

@fischerdouglas
Copy link
Author

Hum... Just wondering in my mind, and echoing here...

  • Stablishing a LDP neighboring over GRE could help to get some of that information.
  • BGP-LU also could help on that.
  • On networks with L2VPN Kompella-Based, BGP also helps.
  • BGP rtfilter address-family could help a bit with mapping the VRFs.

@Vadims06
Copy link
Owner

thanks for sharing ideas, sounds interesting! )
I think, it's time to build a lab in containerlab to get details how to link all such information and tie the pieces together. Any help you can offer here would be greatly appreciated :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants