The curious case of Nokia SR OS yang module
LnetD can take igp(ISIS) information from JNP and XR to create a dynamic map of the network
( among other features).
( among other features).
Nokia was the vendor missing from the list. When I started the project I hoped to have an ISIS
speaker so I don't need to parse live device information with BGP-LS as a backup. From work
experience most companies have strict rules to deploy something like BGP-LS or even more
strict rules to add an IGP speaker into their network so slowly moved towards netconf as the
main method to get the topology.
speaker so I don't need to parse live device information with BGP-LS as a backup. From work
experience most companies have strict rules to deploy something like BGP-LS or even more
strict rules to add an IGP speaker into their network so slowly moved towards netconf as the
main method to get the topology.
This brings me back to Nokia SR OS. I never work with their OS , nor do I have an VSIM to
test but one friend know another and i manage to get in contact with someone at Nokia.
I can’t overstate how much help this person provided , this without ever asking if i’m the customer.
Long story short he share with me nokia sr os yang modules, and in particular the
route-isis-state.yang.
test but one friend know another and i manage to get in contact with someone at Nokia.
I can’t overstate how much help this person provided , this without ever asking if i’m the customer.
Long story short he share with me nokia sr os yang modules, and in particular the
route-isis-state.yang.
For LnetD i need mostly TLV22 with sub-tlv 6 and 8 to create the following structure:
source = router-nametarget = neigh router name
l_ip = router local interface ip
r_ip = neigh router interface ip
metric = igp metric of the link
So Nokia provides the information in as hex string
0x831b010012010003009c04b0011011011011000000
0000817c650101030249108101cc8902523186040b0b0b0b840802020
2010b0b0b0b1650022022022022000000644506040202020108040202
02020904503a43b70a04503a43b70b20503a43b7503a43b7503a43b75
03a43b7503a43b7503a43b7503a43b7503a43b7030400000000120300
00648711000000641802020200000000200b0b0b0b<
0000817c650101030249108101cc8902523186040b0b0b0b840802020
2010b0b0b0b1650022022022022000000644506040202020108040202
02020904503a43b70a04503a43b70b20503a43b7503a43b7503a43b75
03a43b7503a43b7503a43b7503a43b7503a43b7030400000000120300
00648711000000641802020200000000200b0b0b0b<
Funny enough that’s what the yang model shows.
leaf value {
type string {
length "27..9190";
}
description "Contents of the LSP.";
}
The initial ISIS speaker was based on : PyRT: Python Routeing Toolkit , and what it did was exactly
what I needed, parse isis msg. Unfortunately TLV 22 was not in the initial code so i had to add it.
what I needed, parse isis msg. Unfortunately TLV 22 was not in the initial code so i had to add it.
You can check the code on :
