LABRST-2099 iwan Deployment using NSO

Transcription

1 LABRST-2099 iwan Deployment using NS Intelligent WAN (IWAN) enables businesses to switch smoothly between different WAN transports with no compromise in terms of application performance, reliability, or security. Cisco Network Services rchestrator (NS) enabled by NETCNF and YANG models, provides faster and easier deployment of Cisco IWAN transport solution. This lab provides a hands-on experience of provisioning IWAN solution using NS. This lab provides systematic guidelines to setup YANG models, and NETCNF, and deploy the IWAN solution. Lab Goal: The purpose of this lab is to familiarize the user to deploy Cisco s IWAN transport solution using NS. We will use the IWAN function pack (a collection of packages that is solving a specific use case). This function pack provides Day 1 configuration to implement the IWAN solution. Lab Topology: The lab topology includes two Hub locations and three Branch locations. Each location has two types of WAN transport: MPLS and INET (Internet). The hub includes a Master Controller (MC), an MPLS Border Router (MPLS-BR) and an INET Border Router (INET- BR) while the branch sites each include Border Router (BR). The branch sites include dualpath connectivity to the hub site across an MPLS and INET path.

2 Pre-Verification: 1) Check IWAN Release version. Use the shortcut available on the desktop to connect to the NS and run following commands from NS operational mode: show iwan-release iwan-release iwan-version IWAN-CoreFP-M Aug15 iwan-release iwan-function-packs IWAN 2) Check if packages are loaded correctly show packages package oper-status PACKAGE PRGRAM META FILE CDE JAVA BAD NCS PACKAGE PACKAGE CIRCULAR DATA LAD ERRR NAME UP ERRR UNINITIALIZED VERSIN NAME VERSIN DEPENDENCY ERRR ERRR INF access X branchinfra X cisco-ios X cisco-pnp X core-fp-common X id-allocator X infrastructure X ipaddress-allocator X iwan-cfs X iwan-demo-ui X iwan-rfs X monitor X nso-util X pnp-manager X resource-manager X resource-manager-proxy X services X tailf-etsi-rel2-nfvo X template-utils X ) Verify Package Version admin@ncs> show packages package package-version PACKAGE NAME VERSIN access branchinfra cisco-ios 5.4 cisco-pnp core-fp-common id-allocator infrastructure ipaddress-allocator iwan-cfs iwan-demo-ui iwan-rfs monitor nso-util pnp-manager resource-manager resource-manager-proxy services tailf-etsi-rel2-nfvo template-utils 1.1.0

3 Step 1: nboarding of devices to NS There are two ways to onboard a device to NS. The first method will be using NS CLI and the second one via XML file. 1) Verification of existing devices: admin@ncs> show devices list NAME ADDRESS DESCRIPTIN NED ID ADMIN STATE ) Create Authgroup: Before devices are added, we need to create authgroup on the NS server. This authgroup will be used for authentication between NS and the devices. admin@ncs> config Entering configuration mode private admin@ncs% set devices authgroups group IWAN cisco123 remote-secondary-password cisco123 default-map remote-name admin remote-password 3) You can check the configuration stage with the command show compare admin@ncs% show compare devices { authgroups { group IWAN { default-map { remote-password $8$jJeV3Jzy8ouFKGKIKdprs/X6/4BF4g3FLINLDoqjc=; remote-password $8$UrSWYQA4A1xqkgqHirsXbddXBa/9aDWVZ84TeWIo3k=; remote-secondary-password $8$AfcqgDGZqxe3Dtk1wuq9xcgFpdsFd6jTrv07nHLCA=; remote-secondary-password $8$BCeLywszYYjvMhkXELYki6GRbAPePhEDBBBzoNuDQE=; 4) Commit the configuration admin@ncs% commit Commit complete. Add Device using the CLI 1) Add R11 admin@ncs% set devices device R11 description Bogota address port 22 authgroup IWAN device-type cli ned-id cisco-ios [edit] admin@ncs% set devices device R11 state admin-state unlocked admin@ncs% commit Commit complete.

4 2) Verify R11 is added run show devices list NAME ADDRESS DESCRIPTIN NED ID ADMIN STATE R Bogota cisco-ios unlocked Add Device using XML 1) A file with the devices on the simulation is already created. Type the following command. admin@ncs% load merge /home/admin/iwan/1-devices.xml 2) The XML file contains the list of devices and the device groups admin@ncs% commit dry-run cli { local-node { data devices { authgroups { group IWAN { default-map { - remote-password $8$UrSWYQA4A1xqkgqHirsXbddXBa/9aDWVZ84TeWIo3k=; remote-password $8$wa9awyPn9QIGb/X4lFDkVZXR9ny76xbHuqrL07Ras=; - remote-secondary-password $8$BCeLywszYYjvMhkXELYki6GRbAPePhEDBBBzoNuDQE=; remote-secondary-password $8$DCbMzfsQC7KEFkQSDrJYwMAcltqS7n61jbmfPyPek=; device-group Bogota { device-name [ R20 R21 R22 ]; device-group Brasilia { device-name [ R10 R11 R12 R13 ]; device-group Cancun { device-name [ R51 R52 ]; device-group Caracas { device-name [ R31 ]; device-group Santiago { device-name [ R41 ]; device-group iwan { device-group [ Bogota Brasilia Cancun Caracas Santiago ]; device R10 { address ; port 22; description Bogota; authgroup IWAN; device-type { cli { ned-id cisco-ios; state { admin-state unlocked; Device group where created. This will allow the grouping of devices under a logic tree. This could represent added for future operations.

5 3) Commit the configuration. commit Commit complete. [edit] run show devices list NAME ADDRESS DESCRIPTIN NED ID ADMIN STATE R Bogota cisco-ios unlocked R Bogota cisco-ios unlocked R Bogota cisco-ios unlocked R Bogota cisco-ios unlocked R Brasilia cisco-ios unlocked R Brasilia cisco-ios unlocked R Brasilia cisco-ios unlocked R Caracas cisco-ios unlocked R Santiago cisco-ios unlocked R Cancun cisco-ios unlocked R Cancun cisco-ios unlocked Step 2: Fetch-ssh-keys and sync from connect and sync-from for all the devices In order for NS to start interacting with the devices we need to fetch their SSH keys and have the ConfD Configuration Database (CDB) sync. request devices fetch-ssh-host-keys fetch-result { device R10 result unchanged fingerprint { algorithm ssh-rsa value a4:b9:cc:5b:e5:9f:f2:d2:a9:f5:e0:42:a4:98:cb:62. admin@ncs% request devices connect connect-result { device R10 result true info (admin) Connected to R :22 admin@ncs% request devices sync-from sync-result { device R10 result true sync-result { device R11 result true

6 We can now start to push configuration to the devices Step 3: Add devices to Provider infrastructure There could be several devices managed by the NS that are not part of the IWAN infrastructure so we need to create the tenancy of devices. These devices will be added to the catalog of the service. load merge /home/admin/iwan/2-provider.xml A provider infrastructure was created with the designation ACME and it contains one tenant CLC (Cisco Live Cancun). admin@ncs% commit dry-run cli { local-node { data core-fp-common:provider-infrastructure ACME { tenant-infrastructure CLC { catalog iwan-physical; device SITE1xR10 { type physical; device-on-boarding pnp-unmanaged; device-name R10;.. Commit when done. admin@ncs% commit Commit complete. Verification admin@ncs% show core-fp-common:provider-infrastructure core-fp-common:provider-infrastructure ACME { tenant-infrastructure CLC { catalog iwan-physical; device SITE1xR10 { type physical; device-on-boarding pnp-unmanaged; device-name R10; device SITE1xR11 { type physical; device-on-boarding pnp-unmanaged; device-name R11;

7 NS browser Let us now select the Google Chrome desktop shortcut. This will open the NS Web GUI. Please login with the NS credentials: admin/cisco123 We can see that no iwan service was created for the ACME provider.

8 NTE: The iwan NS GUI was disabled and no actions can be performed via GUI. Step 4: Service creation Create the Transport VPN (DMVPN). Let us have a look at the content of the file 3-iwanservice.xml <iwan-service xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns=" <service-name>sd_wan</service-name> <provider>acme</provider> <tenant>clc</tenant> <!-- GLBAL PARAMETERS --> <options xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <single-global-vrf>true</single-global-vrf> <vrf-offset>100</vrf-offset> <dci>true</dci> <set-dc-preference-on-site>true</set-dc-preference-on-site> <enable-igp-on-topology>true</enable-igp-on-topology> <asymmetric-routing-at-central-site>true</asymmetric-routing-at-central-site> </options> <!-- TRANSPRT DEFINITIN --> <transport-information xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <transport-id>1</transport-id> <transport-type>mpls</transport-type> </transport-information> <transport-information xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <transport-id>2</transport-id> <transport-type>inet</transport-type> </transport-information> <!-- VPN DEFINITIN --> <vpn xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <iwanv2 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <dmvpn-data xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <transport-id>1</transport-id> <dmvpn-key>cisco123=</dmvpn-key> <nhrp-auth>cisco123</nhrp-auth> <has-fvrf>true</has-fvrf> <network-id>100</network-id> <overlay-pools xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <vrf-id>0</vrf-id> <pool> /24</pool> </overlay-pools> </dmvpn-data> <dmvpn-data xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <transport-id>2</transport-id> <dmvpn-key>cisco123</dmvpn-key> <nhrp-auth>cisco123</nhrp-auth> <has-fvrf>true</has-fvrf> <network-id>200</network-id> <overlay-pools xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <vrf-id>0</vrf-id> <pool> /24</pool> </overlay-pools> </dmvpn-data> <enterprise-prefix xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <prefix> /8</prefix> </enterprise-prefix> <asymmetric-routing-information xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <network-id>1</network-id>

9 <asymmetric-routing-pools xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> <vrf-id>0</vrf-id> <pool> /24</pool> </asymmetric-routing-pools> </asymmetric-routing-information> </iwanv2> </vpn> </iwan-service> Add the service SD_WAN load merge /home/admin/iwan/3-iwan-service.xml [edit] commit Commit complete. Let s now refresh the NS GUI We can now see that two transports VPN were created.

10 Step 5: Assigning the devices (sites) to the iwan domain. load merge /home/admin/iwan/4-dcsite.xml NTE: Commit dry-run will show the changes about to be performed. commit Commit complete. Please refresh the NS GUI. The two DC sites were added to the GUI. NTE: n the navigation panel, there is a Notifications separator. This will contain the result of actions performed by the CFP

11 We can also collect information about the state of the progress directly on the NS CLI, under operational mode. exit show notification stream srvc-notif last 1 notification { eventtime T13:04: :00 srvc-notif { name SD_WAN provider ACME tenant CLC notif-type PRVISIN srvc-type IWAN status DNE We will now add the branch sites to our iwan service. Given the several line of configuration we will just configure one device/interface via NS CLI and add the remaining via XML file admin@ncs% set iwan-service:iwan-service SD_WAN infrastructure device Site3xR31 wan GigabitEthernet2 description "IWAN - MPLS" ip mask gtw bandwidth path 1 [ok [edit] admin@ncs% show compare iwan-service:iwan-service SD_WAN { infrastructure { device Site3xR31 { wan GigabitEthernet2 { description "IWAN - MPLS"; ip ; mask ; gtw ; bandwidth 42000; path 1; Adding the remaining devices/interfaces

12 load merge /home/admin/iwan/5-site3.xml [ :14:35] [edit] load merge /home/admin/iwan/5-site4.xml [ :14:39] [edit] load merge /home/admin/iwan/5-site5.xml [edit] commit Commit complete. Go back to NS GUI and place the cursor over one of the devices to verify the information on that device. Verify that the configuration was pushed to the interfaces show devices device R11 config ios:interface GigabitEthernet 2 description IWAN - MPLS; negotiation { auto true;

13 bandwidth { kilobits 42000; mop { enabled false; sysid false; hold-queue in { queue-length 4096; hold-queue out { queue-length 4096; vrf { forwarding MPLS1; ip { address { primary { address ; mask ; load-interval 30; Let us now verify some commands on the devices. For that just right-click on the device you want to perform the command on VIRL

14 Let us check the DMVPN created R11-BR#show dmvpn Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete N - NATed, L - Local, X - No Socket T1 - Route Installed, T2 - Nexthop-override C - CTS Capable, I2 - Temporary # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ========================================================================== Interface: Tunnel100, IPv4 NHRP Details Type:Hub, NHRP Peers:3, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb UP 01:59:18 D UP 01:59:18 D UP 01:59:21 D!!!! R11-BR#Show ip nhrp brief **************************************************************************** NTE: Link-Local, No-socket and Incomplete entries are not displayed **************************************************************************** Legend: Type --> S - Static, D - Dynamic Flags --> u - unique, r - registered, e - temporary, c - claimed a - authoritative, t - route ============================================================================ Intf NextHop Address NBMA Address Target Network T/Flag Tu /32 D/r Tu /32 D/r Tu /32 D/r Step 6 Configuring routing protocols Let us check the route table for vrf MPLS1 before adding the routing protocols configuration. R11-BR#show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, - SPF, IA - SPF inter area N1 - SPF NSSA external type 1, N2 - SPF NSSA external type 2 E1 - SPF external type 1, E2 - SPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - DR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is not set S C C L C L C L /8 is variably subnetted, 6 subnets, 3 masks /8 is directly connected, Null /32 is directly connected, Loopback /24 is directly connected, GigabitEthernet /32 is directly connected, GigabitEthernet /24 is directly connected, GigabitEthernet /32 is directly connected, GigabitEthernet /24 is variably subnetted, 2 subnets, 2 masks /24 is directly connected, Tunnel /32 is directly connected, Tunnel100

15 Let us now apply the routing configuration set iwan-service:iwan-service SD_WAN provider ACME tenant CLC overlay-routing-protocol type bgp bgp bgp-asn set iwan-service:iwan-service SD_WAN provider ACME tenant CLC igp type ospf ospf ospfarea 0 ospf-process-id 100 [edit] admin@ncs% commit Commit complete. Verification R11-BR#show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, - SPF, IA - SPF inter area N1 - SPF NSSA external type 1, N2 - SPF NSSA external type 2 E1 - SPF external type 1, E2 - SPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - DR, P - periodic downloaded static route, H - NHRP, l - LISP a - application route - replicated route, % - next hop override, p - overrides from PfR Gateway of last resort is to network *E2 S S C C L C L B B S C L /0 [110/1] via , 00:00:25, GigabitEthernet /8 is variably subnetted, 30 subnets, 4 masks /8 is directly connected, Null /16 is directly connected, Null /32 is directly connected, Loopback /32 [110/3] via , 00:00:25, GigabitEthernet /32 [110/3] via , 00:00:25, GigabitEthernet /32 [110/2] via , 00:00:25, GigabitEthernet /24 is directly connected, GigabitEthernet /32 is directly connected, GigabitEthernet /32 [110/2] via , 00:00:25, GigabitEthernet /32 [110/2] via , 00:00:25, GigabitEthernet /24 [110/2] via , 00:00:25, GigabitEthernet /24 is directly connected, GigabitEthernet /32 is directly connected, GigabitEthernet /24 [110/2] via , 00:00:25, GigabitEthernet /24 [110/2] via , 00:00:25, GigabitEthernet /32 [110/1003] via , 00:00:25, GigabitEthernet /32 [110/1003] via , 00:00:25, GigabitEthernet /32 [110/1002] via , 00:00:25, GigabitEthernet /24 [110/1003] via , 00:00:25, GigabitEthernet /32 [110/1002] via , 00:00:25, GigabitEthernet /32 [110/1002] via , 00:00:25, GigabitEthernet /24 [110/1002] via , 00:00:25, GigabitEthernet /24 [110/1002] via , 00:00:25, GigabitEthernet /24 [110/1002] via , 00:00:25, GigabitEthernet /32 [89/0] via , 00:00: /32 [89/0] via , 00:00: /16 is directly connected, Null /24 [110/1001] via , 00:00:25, GigabitEthernet /32 [110/2] via , 00:00:25, GigabitEthernet /32 [110/1002] via , 00:00:25, GigabitEthernet /24 is variably subnetted, 2 subnets, 2 masks /24 is directly connected, Tunnel /32 is directly connected, Tunnel100

16 Step 7 Set Performance Routing (PfR) Performance Routing (PfR) delivers intelligent path selection. Devices play four roles in PfRv3 configuration: Hub Master Controller (MC) - The master controller at the hub-site, which can be either a data center or headquarters. All policies are configured on the hub MC. It acts as master controller for domain and makes optimization decisions. Hub Border Routers - The border controllers at the hub-site. WAN interfaces terminate in the hub border routers, which are also acting as DMVPN Next Hop Resolution servers. A PfRv3 path name is enabled on the tunnel interfaces of these routers. You can configure more than one WAN interface on the same device. You can also have multiple hub border devices like those that we do in our topology. Branch Master Controller - The branch master controller is the master controller at the branch-site. There is no policy configuration on this device. It receives policy from the Hub MC. This device acts as master controller for that site and is responsible for making optimization decisions. Branch Border Router - The border device at the branch-site. There is no configuration other than enabling of PfRv3 border MC on the device. The WAN overlay interface that terminates on the device is detected automatically. Let us have a look at the configuration file <iwan-service xmlns=" <service-name>sd_wan</service-name> <provider>acme</provider> <tenant>clc</tenant> <pfr> <central-master-controllers> <central-site-name>bogota</central-site-name> <serial>site1xr10</serial> <device-role>hub</device-role> </central-master-controllers> <central-master-controllers> <central-site-name>brasilia</central-site-name> <serial>site2xr20</serial> <device-role>transit</device-role> </central-master-controllers> <pfr-policy> <load-balance-advanced> <path>1</path> <path>2</path> </load-balance-advanced> <class> <name>vice</name> <dscp> <services-value>ef</services-value> <policy>voice</policy> </dscp> <path>1</path> <fallback> <fallback-path>2</fallback-path>

17 </fallback> </class> <class> <name>vide</name> <dscp> <services-value>af41</services-value> <policy>real-time-video</policy> </dscp> <dscp> <services-value>af42</services-value> <policy>real-time-video</policy> </dscp> <dscp> <services-value>af43</services-value> <policy>real-time-video</policy> </dscp> <dscp> <services-value>cs4</services-value> <policy>real-time-video</policy> </dscp> <path>1</path> <fallback> <fallback-path>2</fallback-path> </fallback> </class> <class> <name>critical</name> <dscp> <services-value>af21</services-value> <policy>bulk-data</policy> </dscp> <dscp> <services-value>af22</services-value> <policy>bulk-data</policy> </dscp> <dscp> <services-value>af23</services-value> <policy>bulk-data</policy> </dscp> <path>1</path> <fallback> <fallback-path>2</fallback-path> </fallback> </class> <class> <name>default</name> <dscp> <services-value>default</services-value> <policy>best-effort</policy> </dscp> <path>2</path> <fallback> <fallback-path>1</fallback-path> </fallback> </class> </pfr-policy> </pfr> </iwan-service> Verification of PfR policy before configuration R10-HMC#show run sec domain no ip domain lookup ip domain name iwan.net

18 We need to load the configuration to NS load merge /home/admin/iwan/7-pfr.xml [edit] commit Commit complete. Verification of PfR policy after configuration R10-HMC#show run sec domain no ip domain lookup ip domain name iwan.net domain IWAN master hub advanced channel-unreachable-timer 4 vrf default master hub source-interface Loopback0 site-prefixes prefix-list SITE_PREFIX password C A5F load-balance advanced path-preference MPLS1 INET2 fallback routing enterprise-prefix prefix-list ENTERPRISE_PREFIX class VIDE sequence 7259 match dscp cs4 policy real-time-video match dscp af41 policy real-time-video match dscp af42 policy real-time-video match dscp af43 policy real-time-video path-preference MPLS1 fallback INET2 class CRITICAL sequence match dscp af21 policy bulk-data match dscp af22 policy bulk-data match dscp af23 policy bulk-data path-preference MPLS1 fallback INET2 class VICE sequence match dscp ef policy voice path-preference MPLS1 fallback INET2 Verification on the NS CLI admin@ncs% request iwan-service:iwan-service SD_WAN show-site-state for-branch { branch-name Santiago site-state { device-name R41 status complete is-pnp-managed pnp-unmanaged Access-Layer-Configuration { vrf success ipsec success egp success dia not-present interfaces success igp not-present Service-Layer-Configuration { pfr success ß Success avc not-present nbar not-present lan-qos not-present wan-qos not-present dia-qos not-present waas not-present n the NS GUI we will now find the PfR policies created.

19 Just place the cursor over one of them to visualize the primary path. The same applies to the PFR tab if we just press the bottom left next until step 4 summary.

20 Additional step to be performed based on time availability Step 8 Delete Branch site The CFP allows selective deletion of sites/branches. Explore the NS CLI and select a branch to be deleted. admin@ncs% delete iwan-service:iwan-service SD_WAN vpn iwanv2 branch-sites? Description: Remote branch sites Possible completions: Cancun Caracas Santiago For demonstration purpose we choose Santiago. The branch is removed from the iwan service Analyzing the Notifications tab. Step 9 Configuring QoS policies for Wan Please add the configuration to the NS CLI set iwan-service:iwan-service SD_WAN wan-qos-marking qos-class CALL-SIGNALING dscp-value [ cs3 ]

21 set iwan-service:iwan-service af13 af21 af22 af23 ] set iwan-service:iwan-service 4 set iwan-service:iwan-service set iwan-service:iwan-service set iwan-service:iwan-service 25 set iwan-service:iwan-service set iwan-service:iwan-service set iwan-service:iwan-service set iwan-service:iwan-service based commit SD_WAN wan-qos-marking qos-class CRITICAL-DATA dscp-value [ af11 af12 SD_WAN wan-qos-marking qos-policy CALL-SIGNALING bandwidth-percentage SD_WAN wan-qos-marking qos-policy CALL-SIGNALING dscp af41 SD_WAN wan-qos-marking qos-policy CALL-SIGNALING dscp-tunnel SD_WAN wan-qos-marking qos-policy CRITICAL-DATA bandwidth-percentage SD_WAN SD_WAN SD_WAN SD_WAN wan-qos-marking wan-qos-marking wan-qos-marking wan-qos-marking qos-policy qos-policy qos-policy qos-policy CRITICAL-DATA CRITICAL-DATA CRITICAL-DATA CRITICAL-DATA dscp af21 dscp-tunnel random-detect random-detect dscp- Let us verify the configuration added admin@ncs% request iwan-service:iwan-service SD_WAN show-site-state for-hub { hub-name Bogota site-state { device-name R10 status complete is-pnp-managed pnp-unmanaged Access-Layer-Configuration { vrf success interfaces success igp success Service-Layer-Configuration { pfr success sdavc not-present site-state { device-name R11 status inprogress is-pnp-managed pnp-unmanaged Access-Layer-Configuration { vrf success ipsec success egp success interfaces success igp success Service-Layer-Configuration { pfr success avc not-present nbar not-present lan-qos not-present wan-qos success ß Success waas not-present sdavc not-present The same is visible on the QoS tab in NS GUI

22 The NS iwan GUI will represent all the parts configured