Understanding Network Topology Acquisition on the NorthStar Controller
After you use BGP-LS to establish BGP peering between the Junos VM and one or more routers in the backbone network, the NorthStar Controller acquires real-time topology changes, which are recorded in the traffic engineering database (TED). To compute optimal paths through the network, the NorthStar Controller requires a consolidated view of the network topology. This routing view of the network includes the nodes, links, and their attributes (metric, link utilization bandwidth, and so on) that comprise the network topology. Thus, any router CLI configuration changes to IGP metric, RSVP bandwidth, Priority/Hold values, and so on are instantly available from the NorthStar Controller UI topology view.
To provide a network view, the NorthStar Controller runs Junos OS in a virtual machine (JunosVM) that uses routing protocols to communicate with the network and dynamically learn the network topology. To provide real-time updates of the network topology, the JunosVM, which is based on a virtual Route Reflector (vRR), establishes a BGP-LS peering session with one or more routers from the existing MPLS TE backbone network. A router from the MPLS TE backbone advertises its traffic engineering database (TED) in BGP-LS. The JunosVM receives real-time BGP-LS updates and forwards this topology data into the Network Topology Abstractor Daemon (NTAD), which is a server daemon that runs in the JunosVM.
The NorthStar Controller stores network topology data in the following routing tables:
lsdist.0—stores the network topology from TED
lsdist.1—stores the network topology from IGP database
NTAD then forwards a copy of the updated topology information to the Path Computation Server (PCS), which displays the live topology update from the NorthStar Controller UI.
To provide a real-time topology update of the network, you can configure direct IS-IS or OSPF adjacency between the NorthStar Controller and an existing MPLS TE backbone router, but we recommend that you use BGP-LS rather than direct IGP adjacency or IGP adjacency over GRE.
The current BGP-LS implementation only considers TED information, and some IGP-specific attributes might not be forwarded during topology acquisition. The following IGP attributes are not forwarded:
Link net mask.
IGP metric (TED provides TE metric only).
In some cases, using IS-IS or OSPF adjacency instead of BGP-LS might produce stale data because IS-IS and OSPF have a database lifetime period that is not automatically cleared when the adjacency is down. In this case, NTAD will export all information in the OSPF or IS-IS database to the NorthStar Path Computation Server (PCS), so the NorthStar Controller might show incorrect topology.
Starting with NorthStar 4.3.0, BGP Monitoring Protocol (BMP) can be used as an alternative to NTAD. BMP runs automatically when you install NorthStar, but is not used unless you configure NorthStar and the JunosVM to make it the active topology acquisition method.
Unlike NTAD, BMP is a standard protocol which has the advantage of relieving the user of responsibility for version control to prevent mismatches. BMP also has the potential to be more compatible than NTAD with third-party routers. The third party router needs to support BGP-LS and BMP, and receive topology via BGP-LS. One disadvantage however, is that BMP only has access to the lsdist.0 routing table while NTAD accesses both lsdist.0 and lsdist.1.
With BMP, NorthStar can obtain the topology information from the BGP-LS data. When using BMP, only traffic engineering entries (from the TED) are available. NTAD also provides IGP entries if the router is peering with the IGP area. Topology data learned via IGP is not available through BMP.
See Configuring Topology Acquisition for information about configuring both NTAD and BMP.