Question 1
Question 2
Question 3
Question 4
Explanation
Cloud-based Cisco SD-WAN controllers means all SD-WAN controllers, which include vManage, vBond and vSmart, are hosted on cloud while only the data plane (vEdges) are located at the customer side. The most popular public clouds (IaaS) that can store these controllers are Amazon Web Service, Microsoft Azure and Google Cloud Platform.
Question 1
Explanation
To limit the remote TLOCs that the local TLOC can establish BFD sessions with, mark the TLOC with the restrict option. When a TLOC is marked as restricted, a TLOC on the local router establishes tunnel connections with a remote TLOC only if the remote TLOC has the same color.
Question 2
Explanation
Only on the vEdge at the hub we need to configure the “service FW address”. For example, we need to configure on the vEdge at the hub to provision the firewall service:
vpn 10
service FW address 1.1.1.1
Question 3
Explanation
The “show policy from-vsmart” command displays a centralized data policy, an application-aware policy, or a cflowd policy that a vSmart controller has pushed to the vEdge router (on vEdge routers only). The vSmart controller pushes the policy via OMP after it has been configured and activated on the controller.
Question 4
Explanation
The “connect” in the “STATE” column means the control connection is trying to establish. If the attempt is successful then it will come to “up” state. If it is stuck in “connect” state then there are routing issues in the network.
Question 5
Explanation
TLOC routes are the logical tunnel termination points on the vEdge routers that connect into a transport network. A TLOC route is uniquely identified and represented by a three-tuple, consisting of system IP address, link color, and encapsulation (Generic Routing Encapsulation [GRE] or IPSec).
Reference: https://explore.cisco.com/sd-wan-adopt/cvd-sd-wan-design-colors#page=7
Question 6
Explanation
The “Show control local-properties “ command displays the Certificate validity, Certificate Status ( Installed or Installed ), Chassis ID, Serial Number.
The output of the “show control summary” is shown below:
“show certficate installed” command:
There is no “show certificate status” command:
Question 7
Explanation
Answer A and answer B are not correct as their commands are not accepted. The only suitable answer is answer C because the range command may change the subnet mask of a prefix, thus make a WAN Edge router a less preferred exit.
Question 8
Explanation
VRRP default hello timer is 1 second.
Question 9
Explanation
DTLS Connection Failure (DCONFAIL) is one of the common issues of control connectivity that does not come up. Probable causes include Firewall or some other connectivity issues. It could be that some or all packets are dropped/filtered somewhere.
Question 10
Question 11
Question 12
Question 1
Explanation
A highly available Cisco SD-WAN network contains three or more vManage NMSs in each domain (cluster). Each vManage instance or device in a cluster can manage approximately 2000 devices, so a cluster of three vManage devices can manage up to 6000 devices.
Question 2
Question 3
Explanation
Display all available vEdge routers in the overlay network.
URL: https://vmanage-ip-address/dataservice/system/device/vedges
Question 4
Question 1
Explanation
OMP advertises three types of routes:
+ OMP routes are prefixes that are learned from the local site, or service side, of a vEdge router. The prefixes are originated as static or connected routes, or from within the OSPF or BGP protocol, and redistributed into OMP so they can be carried across the overlay. OMP routes advertise attributes such as transport location (TLOC) information, which is similar to a BGP next-hop IP address for the route, and other attributes such as origin, originator, preference, site ID, tag, and VPN. An OMP route is only installed in the forwarding table if the TLOC to which it points is active.
+ TLOC routes are the logical tunnel termination points on the vEdge routers that connect into a transport network. A TLOC route is uniquely identified and represented by a three-tuple, consisting of system IP address, link color, and encapsulation (Generic Routing Encapsulation [GRE] or IPSec). In addition to system IP address, color, and encapsulation, TLOC routes also carry attributes such as TLOC private and public IP addresses, carrier, preference, site ID, tag, and weight. For a TLOC to be considered in an active state on a particular vEdge, an active BFD session must be associated with that vEdge TLOC.
+ Service routes represent services (firewall, IPS, application optimization, etc.) that are connected to the vEdge local-site network and are available for other sites for use with service insertion. In addition, these routes also include VPNs; the VPN labels are sent in this update type to tell the vSmart controllers what VPNs are serviced at a remote site.
Reference: https://explore.cisco.com/sd-wan-adopt/cvd-sd-wan-design-colors#page=7
Question 2
Explanation
The Cisco IOS XE SD-WAN image supports the following hardware platforms:
+ Cisco ASR 1000 Series Aggregation Services Routers
+ Cisco 1000 Series ISRs
+ Cisco 4000 Series ISRs
+ Cisco 5400 ENCS
Question 3
Question 4
Explanation
For vEdge Cloud routers, vManage NMS can also sign certificates and generate bootstrap configurations, and it can decommission the devices.
Question 5
Explanation
By default, the control plane uses Datagram Transport Layer Security (DTLS) as the protocol that provides privacy on all its tunnels. DTLS runs over UDP.
You can change the control plane security protocol to TLS, which runs over TCP. The primary reason to use TLS is that, if you consider the vSmart controller to be a server, firewalls protect TCP servers better than UDP servers.
Question 6
Explanation
Cisco vBond resides in the orchestration plane. The vBond controller is largely responsible for the Zero-Touch Provisioning process as well as first-line authentication, control/management information distribution, and facilitating Network Address Translation (NAT) traversal. When a router boots up for the first time in an unconfigured state, vBond is responsible for onboarding the device into the SD-WAN fabric. It is the job of vBond to understand how the network is constructed and then share that information amongst other components.
Question 7
Explanation
The vSmart controller is the brain of the overlay network, establishing, adjusting, and maintaining the connections that form the fabric of the overlay network. In these functions, it oversees the control plane of the Cisco SD-WAN overlay network. The vSmart controller participates only in the overlay network and has no direct peering relationships with any of the devices that an edge router is connected to on the host-facing side.
Question 8
Question 9
Question 10
SD-WAN represents the shift from an older, hardware-based model of legacy WAN to a secure, software-based, virtual IP fabric overlay that runs over standard network transport services. The Cisco SD-WAN solution is comprised of separate orchestration, management, control, and data planes:
+ Orchestration plane (vBond) assists in securely onboarding the SD-WAN WAN Edge routers into the SD-WAN overlay. The vBond controller, or orchestrator, authenticates and authorizes the SD-WAN components onto the network. The vBond orchestrator takes an added responsibility to distribute the list of vSmart and vManage controller information to the WAN Edge routers. vBond is the only device in SD-WAN that requires a public IP address as it is the first point of contact and authentication for all SD-WAN components to join the SD-WAN fabric. All other components need to know the vBond IP or DNS information.
+ Management plane (vManage) is responsible for central configuration and monitoring. The vManage controller is the centralized network management system that provides a single pane of glass GUI interface to easily deploy, configure, monitor and troubleshoot all Cisco SD-WAN components in the network.
+ Control plane (vSmart) builds and maintains the network topology and make decisions on the traffic flows. The vSmart controller disseminates control plane information between WAN Edge devices, implements control plane policies and distributes data plane policies to network devices for enforcement.
+ Data plane (vEdge) is responsible for forwarding packets based on decisions from the control plane. WAN Edge physical or virtual devices provide secure data-plane connectivity between the sites in the same SD-WAN overlay network. WAN Edge devices are responsible for establishing secure connections for traffic forwarding, for security, encryption, Quality of Service (QoS) enforcement and more.
Data plane connections are only formed between vEdges. By default, vEdges will attempt to form an IPSec tunnel with every other vEdge across every link on each device. This kind of full mesh results in a lot of overhead just managing and maintaining IPSec. It is recommended to use policy to limit the topology to hub and spoke, partial mesh or something in between that makes sense to the business requirements.
In summary, the Cisco SD-WAN solution includes the vBond orchestrator on the orchestration layer, vManage on the management plane, vSmart controller on the control plane, and vEdge devices on the data plane. A summarization of the functions of each plane is shown below:
Orchestration Plane (Cisco vBond)
+ Orchestrates connectivity between management, control and data plane
+ First point of contact & authentication for all SD-WAN components to join the SD-WAN fabric
+ Requires dedicated public IP Address
+ Facilitates NAT traversal
+ All other components need to know the vBond IP or DNS information
+ Authorizes all control connections (white-list model)
+ Distributes list of vSmarts to all vEdges
Management Plane (Cisco vManage)
+ Intuitive GUI dashboard
+ Real time alerting
+ Centralized provisioning
+ Configuration standardization
+ Simplicity of deploying
+ Simplicity of change
+ Supports:
• REST API
• CLI
• Syslog
• SNMP
• NETCONF
Control Plane (Cisco vSmart)
+ Centralized brain of the solution
+ Facilitates fabric discovery
+ Establishes OMP peering with all vEdges
+ Implements control plane policies, such as service chaining, traffic engineering and per VPN topology
+ Dramatically reduces complexity of the entire network
+ Distributes connectivity information between vEdge
+ Orchestrates secure data plane connectivity between vEdges
Data Plane (Physical/Virtual Cisco vEdge)
+ WAN edge router
+ Provides secure data plane with remote vEdge routers
+ Establishes secure control plane with vSmart controllers (OMP)
+ Implements data plane and application aware routing policies
+ Exports performance statistics
+ Leverages traditional routing protocols like OSPF, BGP and VRRP
+ Support Zero Touch Deployment
+ Physical or Virtual form factor (100Mb, 1Gb, 10Gb)
Underlay Network
An underlay network is the underlying physical infrastructure of a network typically built from a number of routers and switches with a layer 3 routing protocol. In the topology above, underlay network is the full-mesh circle. It includes multiple WAN transport technologies such as MPLS, broadband, 4G, Internet connections…
Overlay Network
The overlay network is a virtual IP fabric built on top of the underlay transport using IPsec tunnels. The fabric can be either full mesh, partial mesh or hub and spoke topologies.
Overlay network consists of:
+ The secure channels formed between the vEdges and the controllers (vBond, vManage, vSmart)
+ The secure channels formed between the vEdges:
Cisco SD-WAN uses Overlay Management Protocol (OMP) which manages the overlay network. OMP runs between the vSmart controllers and WAN Edge routers (and among vSmarts themselves) where control plane information, such as the routing, policy, and management information, is exchanged over a secure connection. If no policy is defined, the default behavior of OMP is to allow a full mesh topology, where each WAN Edge router can connect directly to other WAN Edge routers.
Centralized policies are built using vManage, and then stored in its database. They are then sent via NETCONF to the vSmart controller to become a part of vSmart configurations. The vSmart controller then uses OMP to send the policy parameters as updates in the routing protocol to all of the WAN edge devices. WAN edge devices learn the policy and then execute them in memory. As a result, all configurations are backed up in vManage configuration database.
OMP is a propriety protocol that is enabled by default in our Transport VPN (VPN0), so we do not need to configure anything to make it come up. As soon as our DTLS connections to our vSmart are established, our OMP peerings will automatically be formed and the exchange of routing information takes place.
OMP advertises three types of routes:
+ OMP routes are routes learned from the local site, or service side, of a vEdge router (via connected, static, OSPF or BGP…). The routes are redistributed into OMP so they can be carried across the overlay. OMP routes advertise attributes such as:
– Transport location (TLOC) information: which is similar to a BGP next-hop IP address for the route. TLOC is a 3 tuple value {System IP, Color, Encapsulation}:
— System IP is the address of the OMP speaker that originates the OMP route. It is a 32 bit number presented in the classic IPv4 dotted-decimal notation (which is equivalent to router-id in traditional routing protocols like OSPF)
— Color represents the type of WAN interfaces on vEdge router. The Cisco (Viptela) solution offers predefined colors, which are assigned in the configuration of the vEdge routers. The color can be one of default, 3g, biz-internet, blue, bronze, custom1, custom2, custom3, gold, green, lte, metro-ethernet, mpls, private1, private2, public-internet, red, and silver.
— Encapsulation type on the transport tunnel. It can be either IPsec or GRE.
– Origin: identifies the origin of the vRoute (whether route originated from BGP, OSPF, Connected or Static…) along with the metric of the original route.
– Originator: IP address from which the route has propagated.
– Preference: If two similar OMP protocol routes exist, the one with higher preference is preferred. Default is 0.
– Service: Network service associated with the OMP protocol route.
– Site-ID: Identifier of the site from which the OMP route is propagated.
– Tag: Optional which can be used to match a specific route and then take necessary action on that.
– VPN: VPN-ID in which the route has been propagated.
An OMP route is only installed in the forwarding table if the TLOC to which it points is active.
+ TLOC routes are the logical tunnel termination points on the vEdge routers that connect into a transport network. A TLOC route is uniquely identified and represented by a three-tuple, consisting of system IP address, link color, and encapsulation (Generic Routing Encapsulation [GRE] or IPSec). In addition to system IP address, color, and encapsulation, TLOC routes also carry attributes such as TLOC private and public IP addresses, carrier, preference, site ID, tag, and weight. For a TLOC to be considered in an active state on a particular vEdge, an active BFD session must be associated with that vEdge TLOC.
+ Service routes represent services (firewall, IPS, application optimization…) that are connected to the vEdge local-site network and are available for other sites for use with service insertion. In addition, these routes also include VPNs; the VPN labels are sent in this update type to tell the vSmart controllers what VPNs are serviced at a remote site.
Let’s take an example:
In the above topology, notice that the system IP of vSmart1 is 1.1.1.1. We can check all the OMP peers of vEdge1 router with the “show omp peers” command:
vEdge1#show omp peers
R -> routes received
I -> routes installed
S -> routes sent
DOMAIN OVERLAY SITE
PEER TYPE ID ID ID STATE UPTIME R/I/S
-------------------------------------------------------------------------------------
1.1.1.1 vsmart 1 1 100 up 0:02:11:22 1/1/1
As we can see, only vSmart1 is the OMP peer of vEdge1 with the System IP of 1.1.1.1. It is in “up” state. Notice that vEdge1 does not establish OMP peer with vEdge2.
In the last column (R/I/S) we see vEdge1 received (“R” letter in the last column) one route and installed it (“I”) into OMP routing table. It also sent one route (“S”) to vSmart1.
To check the detail of which route was installed into OMP routing table of vEdge1, we can use the command “show omp routes”:
vedge1#show omp routes
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Inv -> invalid
Stg -> staged
U -> TLOC unresolved
PATH ATTRIBUTE
VPN PREFIX FROM PEER ID LABEL STATUS TYPE TLOC IP COLOR ENCAP PREFERENCE
--------------------------------------------------------------------------------------------------------------------------------------
1 192.168.1.0/24 0.0.0.0 65 1003 C,Red,R installed 3.3.3.3 default ipsec -
1 192.168.2.0/24 1.1.1.1 1 1003 C,I,R installed 4.4.4.4 default ipsec -
From the last line of the output above, we can see the prefix 192.168.2.0/24 was learned from TLOC {4.4.4.4, default, ipsec}. Remember that TLOCs are defined by three tuple value {System IP, Color, Encapsulation}.
We also see our local prefix 192.168.1.0/24 was redistributed (“Red” in the “Status” column) automatically into OMP and it is the route that vEdge1 advertised to vSmart1 because it is a (directly) connected route.
| Note: OMP automatically redistributes the following types of routes that it learns either locally or from its routing peers: Connected, Static, OSPF intra-area routes, OSPF inter-area routes. |
The prefix 192.168.2.0/24 was learned from TLOC {4.4.4.4, default, ipsec} so in order to reach 192.168.2.0/24 network, vEdge1 must find information from TLOC {4.4.4.4, default, ipsec}. We can check the detail of this TLOC with the “show omp tlocs” command:
vedge1# show omp tlocs
Code:
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
PUBLIC PRIVATE
PSEUDO PUBLIC PRIVATE PUBLIC IPV6 PRIVATE IPV6 BFD
TLOC IP COLOR ENCAP FROM PEER STATUS KEY PUBLIC IP PORT PRIVATE IP PORT IPV6 PORT IPV6 PORT STATUS
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3.3.3.3 default ipsec 0.0.0.0 C,Red,R 1 10.10.20.60 12366 10.10.20.60 12366 :: 0 :: 0 up
4.4.4.4 default ipsec 1.1.1.1 C,I,R 1 10.10.20.61 12366 10.10.20.61 12366 :: 0 :: 0 up
All the information to reach this TLOC{4.4.4.4, default, ipsec} is listed in the last line with Public IP of 10.10.20.61, public port of 12366.
Finally let’s check the routing table of vEdge1 to see all the routes learned by vEdge1 with the “show ip route” command:
vedge1# show ip route
Codes Proto-sub-type:
IA -> ospf-intra-area, IE -> ospf-inter-area,
E1 -> ospf-external1, E2 -> ospf-external2,
N1 -> ospf-nssa-external1, N2 -> ospf-nssa-external2,
e -> bgp-external, i -> bgp-internal
Codes Status flags:
F -> fib, S -> selected, I -> inactive,
B -> blackhole, R -> recursive
PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN PREFIX PROTOCOL SUB TYPE IF NAME ADDR VPN TLOC IP COLOR ENCAP STATUS
---------------------------------------------------------------------------------------------------------------------------------------------
0 0.0.0.0/0 static - ge0/0 10.10.20.254 - - - - F,S
0 3.3.3.3/32 connected - system - - - - - F,S
0 10.10.20.0/24 connected - ge0/0 - - - - - F,S
1 192.168.1.0/24 connected - ge0/1 - - - - - F,S
1 192.168.2.0/24 omp - - - - 4.4.4.4 default ipsec F,S
There is only one prefix 192.168.2.0/24 was learned via OMP.
Note: The prefix 10.10.20.0/24 on interface G0/0 is only used to SSH to this device for configuration.
We can ping from vEdge1 to 192.168.2.0/24 network on vEdge2:
vedge1# ping vpn 1 192.168.2.2 count 4 Ping in VPN 1 PING 192.168.2.2 (192.168.2.2) 100(128) bytes of data. 108 bytes from 192.168.2.2: icmp_seq=1 ttl=64 time=0.449 ms 108 bytes from 192.168.2.2: icmp_seq=2 ttl=64 time=0.214 ms 108 bytes from 192.168.2.2: icmp_seq=3 ttl=64 time=0.218 ms 108 bytes from 192.168.2.2: icmp_seq=4 ttl=64 time=0.241 ms --- 192.168.2.2 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4000ms rtt min/avg/max/mdev = 0.214/0.267/0.449/0.093 ms
Reference: https://explore.cisco.com/sd-wan-adopt/cvd-sd-wan-design-colors#page=7
Reference: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/SDWAN/sdwan-dia-deploy-2019nov.pdf
Bi-directional Forwarding Detection (BFD) is a extremely lightweight detection protocol that provides very fast forwarding-path failure detection for all media types, encapsulations, topologies, and the routing protocols (like BGP, EIGRP, IS-IS and OSPF). By using along with these routing protocols, BFD can greatly reduce network convergence time.
In the picture below, we see we have two routers R1 and R2 connected together through a layer 2 switch. These two routers are OSPF neighbors with each other. What if the physical interface between R2 and the layer 2 switch goes down?
The answer is:
+ R2 will tear down the OSPF neighbor immediately based on the layer 1 down event.
+ The physical interface on R1 remains up so it has no awareness of the link local event between the switch and R2. R1 will keep the OSPF neighbor up until the detection of four missing OSPF hellos. By default, OSPF uses a 10-second hello timer and 40-second hold timer on broadcast (Ethernet) links. Therefore R1 may need 40 seconds to detect the broken OSPF neighbor relationship in the worst case.
Of course we can fine tune the hello and hold timer to the minimum values (1 second for hello and 2 or 3 seconds for hold timer is recommended). But BFD can provide failure detection in less than one second (technically, 10s of miliseconds failure detection). This is very useful for real-time applications like Voice over IP (VoIP)
When OSPF discovers a neighbor:
1. OSPF discovers a neighbor
2. OSPF sends a request to the local BFD process to initiate a BFD neighbor session with the OSPF neighbor router
3. The BFD neighbor session with the OSPF neighbor router is established. BFD establishes a session between two endpoints over a particular link.
What happens when a failure occurs in the network:
1. A failure occurs on a link between two BFD neighbors
2. The BFD neighbor session with the OSPF neighbor router is torn down
3. BFD notifies the local OSPF process that the BFD neighbor is no longer reachable
4. The local OSPF process tears down the OSPF neighbor relationship
5. If an alternative path is available the routers will immediately start converging on it.
BFD is enabled by default on all vEdge routers and we cannot disable it. For SDWAN, BFD is used to detect path liveliness (up/down) and measure quality (loss/latency/jitter/IPSec tunnel MTU).
A BFD session may operate in one of two modes: asynchronous mode and demand mode.
In asynchronous mode, both endpoints periodically send Hello packets to each other. If a number of those packets are not received, the session is considered down.
The demand mode is different, once the BFD session is established, the participating systems can request that BFD packets not be sent, then request an exchange of packets only when needed to verify connectivity.
BFD Configuration
In this simple lab we will enable BFD along with OSPF. Only two routers are required in this lab:
The routers in this lab run IOSv15.4.
First let’s complete OSPF configuration on R1 & R2:
|
R1: router ospf 1 |
R2: router ospf 1 |
After OSPF neighbor relationship has been established between R1 & R2, we can try turning off one interface to see how much time for OSPF to notify this:
|
R1(config)#int e0/0 On R2 we see: *Jul 21 04:39:07.763: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired |
It took about 30 seconds for OSPF to detect link down and shut down OSPF neighbor relationship. Recall that on Ethernet interfaces the OSPF dead timer is 40 seconds so it may take 40 seconds to tear down OSPF neighbor relationship in the worst case.
Do a “no shut” on interface FastEthernet0/0 of R1 and enable BFD on interfaces of R1 and R2:
| R1(config)#int e0/0 R1(config)#no shut R1(config-if)#bfd interval 50 min_rx 50 multiplier 3 |
R2(config)#int e0/0 R2(config-if)#bfd interval 50 min_rx 50 multiplier 3 |
BFD timers are configured with the “bfd interval send-timer mix_rx receive-timer multiplier number” interface configuration command.
+ The send-timer specifies the frequency of BFD packets originated by the router (in milliseconds)
+ The receive-timer is the minimum interval between packets accepted from BFD peers (in milliseconds). This is how often we expect to receive a BFD packet from our neighbor. BFD adjacency will not form if the send-timer on one peer is lower than the receive-timer on another peer.
+ The multiplier number is the number of BFD packets that can be lost before the BFD peer is declared “down”
Therefore in the configuration above, we want to send BFD packets every 50 milliseconds and if four BFD packets are lost in a row then it will be considered “down”.
All the BFD was done so we can instruct OSPF to use BFD on its interfaces:
| R1(config)#router ospf 1 R1(config-router)#bfd all-interfaces |
R2(config)#router ospf 1 R2(config-router)#bfd all-interfaces |
Note: In OSPF mode, we have two ways to configure BFD:
+ Use the command “bfd all-interfaces” to enable BFD on all OSPF interfaces. Then we can disable OSPF interfaces that do not need BFD with the “ospf bfd disable” command in interface configuration mode.
+ Enable BFD for a subset of OSPF interfaces by using the ip ospf bfd command in interface configuration mode
Now let’s try turning off interface on R1 again:
|
R1(config)#interface e0/0 |
We can see OSPF changes state from FULL to DOWN immediately (less than 1 second):
|
On R1: *Jul 21 04:50:32.653: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.2 on Ethernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached On R2: *Jul 21 04:50:32.821: %OSPF-5-ADJCHG: Process 1, Nbr 10.10.10.1 on Ethernet0/0 from FULL to DOWN, Neighbor Down: BFD node down |
In order to verify BFD configuration, we can use the “show bfd neighbors” or “show bfd neighbors detail” command:
R1#show bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.10.10.2 1/1 Up Up Et0/0
R1#show bfd neighbors details
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.10.10.2 1/1 Up Up Et0/0
Session state is UP and using echo function with 50 ms interval.
Session Host: Software
OurAddr: 10.10.10.1
Handle: 1
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Holddown (hits): 0(0), Hello (hits): 1000(6)
Rx Count: 7, Rx Interval (ms) min/max/avg: 1/985/732 last: 230 ms ago
Tx Count: 8, Tx Interval (ms) min/max/avg: 1/985/650 last: 69 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: OSPF
Uptime: 00:00:04
Last packet: Version: 1 - Diagnostic: 0
State bit: Up - Demand bit: 0
Poll bit: 0 - Final bit: 0
C bit: 0
Multiplier: 3 - Length: 24
My Discr.: 1 - Your Discr.: 1
Min tx interval: 1000000 - Min rx interval: 1000000
Min Echo interval: 50000
In the SD-WAN overlay, virtual private networks (VPNs) provide segmentation. Each VPN is equivalent to a VRF, which is isolated from one another and have their own forwarding tables. An interface or subinterface is explicitly configured under a single VPN and cannot be part of more than one VPN. Devices attached to an interface in one VPN cannot communicate with devices in another VPN unless policy is put in place to allow it. The VPN ranges from 0 to 65535, but several VPNs are reserved for internal use.
The Transport & Management VPNs
There are two implicitly configured VPNs in the WAN Edge devices and controllers: VPN 0 and VPN 512.
– VPN 0 is the transport VPN. It contains all the interfaces that connect to the WAN links. Secure DTLS/TLS connections to the controllers are initiated from this VPN. Static or default routes or a dynamic routing protocol needs to be configured inside this VPN in order to get appropriate next-hop information so the control plane can be established and IPsec tunnel traffic can reach remote sites.
VPN 0 connects the WAN Edge to the WAN transport and creates control plane and data plane connections. The WAN Edge device can connect to multiple WAN transport(s) on different interfaces on the same VPN 0 transport segment. At least one interface needs to be configured to initially reach the SD-WAN controllers for onboarding.
– VPN 512 is the management VPN. It carries the out-of-band management traffic to and from the Cisco SD-WAN devices. This VPN is ignored by OMP and not carried across the overlay network.
VPN 0 and 512 are the only VPNs that can be configured on vManage and vSmart controllers. For the vBond orchestrator, although more VPNs can be configured, only VPN 0 and 512 are functional and the only ones that should be used.
Service VPNs
Service VPNs are defined as any VPN between 1 and 65530 (excluding 512). Interfaces associated with these VPNs are LAN facing. Our traditional routing protocols run in these VPNs. Each VPN can be thought of in the same way as a traditional VRF. Devices in a service VPN can only reach any other devices in the same VPN. Different service VPNs cannot communicate with each other without an explicit policy being defined to allow the communication. In summary, in WAN Edges VPN = VRF.
User traffic can be directed over the IPsec tunnels to other sites by redistributing OMP routes received from the vSmart controllers at the site into the service-side VPN routing protocol. In turn, routes from the local site can be advertised to other sites by advertising the service VPN routes into the OMP routing protocol, which is sent to the vSmart controllers and redistributed to the other WAN Edge routers in the network.
Note: In IOS XE SD-WAN routers, VRF is used instead of the VPN terminology.
Reference: https://www.cisco.com/c/en/us/td/docs/solutions/CVD/SDWAN/cisco-sdwan-design-guide.html
In this article, I will try to summarize all the Frequently Asked Questions in the ENARSI 300-410 Exam. Hope it will save you some time searching through the Internet and asking your friends & teachers.
1. Please tell me how many questions in the real ENSDWI exam, and how much time to answer them?
You have 90 minutes to answer 60 questions, include multiple choice and drag drop questions. There are no lab sims in this exam currently. You can take this exam in English and Japanese language. If your native language is not English or Japanese, Cisco allows you a 30-minute exam time extension. But there are a few requirements to get this extension, so the best way is asking your teacher or mentor before taking the exam.
2. How much does the ENSDWI 300-415 cost? And how many points I need to pass the exam?
This exam costs $300. You need at least 825/1000 points to pass this exam.
3. I passed the ENSDWI exam, will I get a CCNP certificate for it?
ENARSI is just a concentration exam, in order to get CCNP certificate, you need to pass the ENCOR 350-401 exam as well.
4. Can I get the ENSDWI exam before ENCOR exam?
Yes, you can get ENSDWI exam before ENCOR exam.
5. Please tell me more about the detail of the ENSDWI exam?
From the syllabus of the ENSDWI exam, it will teach you in depth of Cisco Software-defined Wide Area Network (SD-WAN) solution:
+ SD-WAN components: vManage, vBond, vSmart, vEdge
+ Controllers (cloud & on-premises)
+ OMP, TLOC, Templates
+ Policies & Security in SD-WAN
6. In the real exam, I clicked “Next” after choosing the answer, can I go back for reviewing?
No, you can’t go back so you can’t re-check your answers after clicking the “Next” button.
7. What are your recommended materials for ENSDWI ?
There are many materials for learning ENARSI but below are popular materials that many candidates recommend.
Books
ENSDWI 300-415 Official Cert Guide
Video training
CBT Nuggets
Simulator (all are free)
SD-WAN sandbox (you need to register a free account): https://developer.cisco.com/sdwan/sandbox/
8. Are the exam questions the same in all the geographical locations?
Yes, the exam questions are the same in all geographical locations. But notice that Cisco has a pool of questions and each time you take the exam, a number of random questions will show up so you will not see all the same questions as the previous exam.
9. I passed the ENSDWI exam. Do you have any site similar for CCNP Enterprise exams?
We have digitaltut.com for ENCOR (the Core exam of CCNP Enterprise certification), networktut.com for CCNP Enterprise ENARSI (a concentration exam of CCNP Enterprise certification).
We also support the SCOR 350-701 exam (the Core exam of CCNP Security certification).
We also have other sites (but only for sharing experience) like voicetut.com for Voice/Collaboration track, securitytut.com for Security track, dctut.com for Data Center track, sptut.com for Service Provider track, wirelesstut.com for Wireless track, opstut.com for DevNet track. Hope you enjoy these sites and find useful information too!
10. How many CCNP tracks does Cisco support now?
Cisco supports 6 CCNP tracks, which are:
1. CCNP Enterprise
2. CCNP Security
3. CCNP Service provider
4. CCNP Collaboration
5. CCNP Data Center
6. Cisco certified DevNet Professional
In each track, you need to pass a dedicated core exam then pass one concentration exam of that track. Please check the picture below for more detail:
(Reference from https://www.imedita.com/blog/new-changes-to-cisco-certification-programs/)
Note: With these new tracks, CCNA is no longer a prerequisite for CCNP. You can go directly for CCNP certs. But the knowledge of CCNA is highly recommended if you want to reach CCNP.
11. I passed (old) CCNP but my CCNP cert is going to expire and I want to recertify it. Which exam should I get?
According to Cisco Recertification Policy page, you need to complete one of the following things:
– Pass one technology core exam
– Pass any two professional concentration exams
– Pass one CCIE lab exam
Therefore if you only want to take one exam to recertify then you must pass the ENCOR 350-401 exam or any technology core exam of other tracks (for example the DCCOR 350-601 of Data Center track or the SCOR 300-701 of Security track).
Also if you earn 80 CE credits then you can also recertify your CCNP Enterprise cert.
12. Why don’t I see any questions and answers on certprepare.com? I only see the explanation…
Because of copyrighted issues, we had to remove all the questions and answers. You can download a PDF file to see the questions at this link: https://www.certprepare.com/ensdwi-questions-and-answers
Is there anything you want to ask? Just ask! All of us will help you.
The new ENSDWI 300-415 v1.2 has come to replace the old ENSDWI v1.1 exam so we create the “Share your ENSDWI v1.2 Experience” for everyone to share their experience to prepare for this new exam.
Please share with us your experience to prepare for the new ENSDWI 300-415 v1.2 exam, your materials, the way you learned, your recommendations… But please DO NOT share any information about the detail of the exam or your personal information, your score, exam date and location, your email…
Note: To get the new CCNP Enterprise certificate, you need to pass the ENCOR 350-401 exam (core exam) and one of the concentration exam (like this ENSDWI exam)
Your posts are warmly welcome! Hope you will find useful information here!
MATERIALS PROVIDED ON THIS SITE (certprepare.com) ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON INFRINGEMENT. certprepare.com specifically does not make any warranties or representations as to the accuracy or completeness of any such materials. certprepare.com periodically adds, removes, alters, improves, or updates the Materials on this Site without notice. Under no circumstances shall certprepare.com be liable for any loss, damage, liability or expense incurred or suffered which is claimed to resulted from use of this site, including without limitation, any fault, error, omission, interruption or delay with respect thereto. Use of this Site is at users sole risk. Under no circumstances, including, but not limited to, negligence, shall certprepare.com or his affiliates be liable for any direct, indirect, incidental, special or consequential damages, even if certprepare.com has been advised of the possibility of such damages. User specifically acknowledges and agrees that certprepare.com is not liable for any conduct of any visitor to certprepare.com.
This site may contain advice, opinions, and statements of various information providers and content providers. certprepare.com does not represent or endorse the accuracy or reliability of any advice, opinion, statement or other information provided by any information provider or content provider, or any user of this site or other person or entity. Reliance upon any such opinion, advice, statement, or other information shall also be at your own risk. Neither certprepare.com nor his affiliates, nor any of their information providers or content providers shall be liable to any User or anyone else for any inaccuracy, error, omission, interruption, timeliness, completeness, deletion, defect, failure of performance, computer virus, communication line failure, alteration of, or use of any content herein, regardless of cause, for any damages resulting therefrom.
As a condition of use of this Site, User agrees to indemnify certprepare.com and his affiliates from and against any and all actions, claims, losses, damages, liabilities and expenses (including reasonable attorneys’ fees) arising out a user’s use of this site, including without limitation any claims alleging facts that if true would constitute a breach by the user of these terms and conditions. If a user is dissatisfied with any material on this site or with any of terms and conditions of use of this Site, the user’s sole and exclusive remedy is to discontinue using this Site.
This Site contains links to third-party websites. While we do our best to provide quality links, the linked sites are not under the control of certprepare.com and certprepare.com is not responsible for the contents of any linked site or any link contained in a linked site certprepare.com provides these links only as a convenience, and the inclusion of a link does not imply endorsement of the linked site by certprepare.com
All contents copyright by certprepare team. All rights reserved. No part of this website or the related files may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording, or otherwise) without the prior written permission of the publisher.
certprepare.com.com is not responsible for the content of external links and cannot assure that all of them work.
There are no questions to answer.
