NorthStar Egress Peer Engineering
Egress Peer Engineering (EPE) allows users to steer egress traffic to peers external to the local network, by way of egress ASBRs. NorthStar Controller uses BGP-LS and the SIDs to the external EPE peers to learn the topology. Segment Routing is used for the transport LSPs.
In NorthStar 4.3, only manual steering of traffic is supported. NorthStar uses netflowd to create the per-prefix aggregation of traffic demands. Netflowd processes the traffic data and periodically identifies the Top N demands which, based on congestion, are the best candidates for steering. These demands are displayed in the network information table, Demand tab.
Traffic steering involves creating a colored SRTE LSP and then mapping that LSP to traffic demands via PRPD.
NorthStar EPE functionality requires the following:
The Junos OS Release must be 18.4R2 or later.
Netflow must be configured on the router. See Netflow Collector for instructions.
For NorthStar Controller, the following must be enabled:
PRPD client (see the Enable PRPD section later in this topic)
Netflow processes must be running on NorthStar
Figure 1 shows a sample EPE topology which we can use to visualize what NorthStar EPE does.
This example topology includes ten routers as follows:
PE1 acts as the provider edge router
P1, P2, P3, and P4 act as core routers
ASBR11 and ASBR12 act as local ASBRs
10.0.0.31, 10.0.0.22 and 10.0.0.21 are BGP external peer routers
NorthStar has no information about the traffic past the ASBRs in this example, because the nodes are external to the local network; they belong to a service provider. So it is also not possible for NorthStar to display congestion on the links past the ASBRs. The goal is to be able to reroute traffic among external destinations that all advertise the same prefix (source). One of the paths is designated as “preferred”. Rerouting the traffic changes the preferred path. Use Junos OS show route commands to view the preferred path and the advertised prefixes. Use NorthStar to reroute the traffic.
The following sections describe enabling, configuring, and viewing information related to setting up and using NorthStar EPE.
PRPD enables NorthStar to push the mapping using the PRPD client at the local ASBR. PRPD must be enabled, both in NorthStar (Device Profile), and in the router configuration.
To enable PRPD in NorthStar, use the following procedure:
- Navigate to Administration > Device Profile.
- In the device list, click on a device that will be used for EPE and select Modify.
- In the General tab of the Modify Device window, the login and password credentials must be correct for NorthStar to access the router.
- In the Access tab of the Modify Device window, check Enable PRPD, and enter the port on the router that NorthStar will use to establish the PRPD session. Port 50051 is the default, but you can modify it. If you leave the PRPD IP field empty, the router ID (router’s loopback address) is used. The Access tab is shown in Figure 2.
- Click Modify to save your changes.
To enable the PRPD service on the router, use the following procedure:
- Add the following configuration statements to the router
configuration. The values are examples only:
set system services extension-service request-response grpc clear-text address 10.0.0.11 set system services extension-service request-response grpc clear-text port 50051 set system services extension-service request-response grpc max-connections 10
The IP address is typically the loopback address of the router. The port number must match the one you entered in the device profile in NorthStar. The max-connections value is the total number of connections the router can receive from other clients. NorthStar will use one of those connections.
- Make sure you have the BGP protocol enabled on the router.
- For NorthStar to learn and display the BGP routes associated
with each router, configure a policy with these statements (example
policy is called “monitor”):
set policy-options policy-statement monitor then analyze set policy-options policy-statement monitor then next policy
import monitorunder the BGP configuration.
If configured successfully, you should be able to right-click on a node in the Node tab of the network information table and select View Routes to see the routing table for that node. Figure 3 shows an example. Only routing tables for nodes where PRPD is Up can be viewed in this way.
You can view the PRPD Status in the network information table (Node tab) as either Up or Down. If the PRPD Status is unexpectedly Down, check the device profile in NorthStar, and the router configuration, including whether BGP protocol is enabled.
Manual Rerouting Using SRTE Color Provisioning
In the sample topology shown in Figure 1, source node PE1 is sending traffic to destination prefix 10.4.3.0/24, which was advertised by nodes 10.0.0.21, 10.0.0.22, and 10.0.0.31. From PE1’s perspective, the preferred route is to ASBR11. From ASBR11’s perspective, the preferred destination node is 10.0.0.21. So before any rerouting, PE1 is sending traffic to node 10.0.0.21 via ASBR11.
To reroute the traffic from ASBR11 to destination node 10.0.0.22 (instead of 10.0.0.21), you would:
Provision a NETCONF SRTE colored LSP
Map the demand using the PRPD client
Provisioning a NETCONF SRTE Colored LSP
From the network information table, Tunnel tab, click Add at the bottom of the table to display the Provision LSP window. For this example, we provision an SR LSP using NETCONF from PE1 to 10.0.0.22. The provisioning method must be NETCONF and the provisioning type must be SR. On the path tab, select “required” and specify that the traffic is to go through ASBR11.
In the Advanced tab, specify the Color Community and check Use Penultimate Hop as Signaling Address for Color Community. In our example, the penultimate hop is ASBR11. Figure 4 shows the Advanced tab of the Provision LSP window.
On the Design tab, select “default” so NorthStar will calculate the ERO.
Because the LSP is provisioned using NETCONF, NETCONF pushes the configuration to the router. The LSP entry in the Tunnel tab of the network information table shows the new destination address. NorthStar pushes the hop-by-hop route in the form of segment (SID) labels.
On the router, you can use the
protocols source-packet-routing command from the source
node (node A) to see the segment list. You can use the
show spring-traffic-engineering lsp command from the
source node to see the final destination with the color designation,
the state (up/down), and the LSP name. The
protocols source-packet-routing command also displays
Mapping the Demand Using the PRPD Client
The following sections describe creating the demands and mapping them to SRTE colored LSPs.
Demands Created by Netflowd
The netflowd process analyzes traffic from the router and displays it in the Demands tab in the network information table. By default, Netflow aggregates traffic by PE, but for EPE, you want the traffic aggregated by prefix. To configure this, use a text editing tool such as vi to modify the northstar.cfg file, setting the netflow_aggregate_by_prefix parameter to “always”:
[root@ns]# vi /opt/northstar/data/northstar.cfg . . . # netflowd settings . . . netflow_aggregate_by_prefix=always
After changing the setting, restart the analytics:netflowd process:
[root@ns]# supervisorctl restart analytics:netflowd
You can use
supervisorctl status to
check that the process comes back up.
Mapping the Demands
To map a demand, select it in the network information table and click Modify to display the Modify Demand window. Select the LSP Mapping tab as shown in Figure 5.
Click the check box beside the LSP to which you want the demand routed. In NorthStar 4.3.0, you can only select one LSP. In our example, this would be the new SR LSP we created. Click Submit. NorthStar pushes the mapping via the PRPD client.
You can use the
show route command
to confirm that the preferred path has changed as you specified.
To reverse the mapping, you can access the Modify Demand window again and deselect the check box for the LSP in the LSP Mapping tab. You can also delete the demand.