11-27-2023 11:51 PM
I wanted to be able to better understand how the SD-WAN topology works on a sandbox environment. However, I have not found any documents that clearly indicate this topology. Can someone please give me an overview?
Because I can't access the device, I don't know what policies and templates have been applied. Can someone with experience please help me?
many thanks.
11-28-2023 05:32 AM
@trangthu0326 you can access this sandbox here ---> https://devnetsandbox.cisco.com/RM/Diagram/Index/ed2c839d-621e-4c55-b176-db2457baf4c8?diagramType=Topology to get started with the devnet sandbox see this getting started guide here https://developer.cisco.com/docs/sandbox/#!first-reservation-guide
In this sandbox you will find the following set up
In addition, to the environment described above, the Sandbox has the capability to provide traffic generation and policy activation. The following enclosed link below, provides the necessary steps to evaluate policy activation using pre-defined DNS traffic.
Hope this helps.
11-28-2023 05:35 PM
As far as I can see, the internet flow from site1 goes through DC and then to the internet? Why does it have to go through DC?
Or does it go through the devnet environment and then go to the internet?
11-29-2023 02:56 AM
Hello, the internet flow from site1 goes through DC and then to the internet, (although i do not believe devnet sandbox has open internet access). In this design this is because the DC is likely where the internet connection for the entire network is located.
DevNet has its own network which the sandboxes are located in, think of this as a DMZ, if sandboxes (other others could reach the internet) they could the sites could go direct to the internet via the DevNet Gateway.
Hope this helps.
01-11-2024 02:29 PM
I'm sorry, I can not for the life of me find a large enough picture of the topology to read. I am using the SDWAN sandbox just fine but I can't see a link to the topology anywhere aside from the small picture of it under Instructions / Access details which is not big enough to read. I suspect a cisco site update that moved stuff around... again. Please help.
01-12-2024 01:41 AM
@grayswan937 you would need to ask the Cisco DevNet team for this information.
Hope this helps.
11-30-2023 12:14 AM
I have some problems as follows:
1. 1 DC/Regional Hub IOS-XE SD-WAN router: meaning this device will contain virtual vSmart, virtual vBond, virtual vManage? 2 Is the Data Center in the model virtual? Or two other devices? If it's virtual, I don't see VM details.
2. 2 DCs have 2 interfaces connected to the management network? Why?
3. "2 IOS-XE SD-WAN (C8000v) branch routers with 1 router at each branch and 1 vEdge Cloud branch router". Does this mean that each branch will have 2 vEdges? 1 physical vEdge, 1 Cloud vEdge? Why must there be 2 vEdge? Where is vEdge Cloud deployed?
Please help me answer my questions, many thanks.
11-30-2023 01:03 AM
Please find inline
1. 1 DC/Regional Hub IOS-XE SD-WAN router
Yes, the 1 DC/Regional will contain virtual vSmart, virtual vBond, and virtual vManage.These virtual components are responsible for different aspects of the SD-WAN architecture:
The two other devices in the model are the branch routers.
2. 2 DCs have 2 interfaces connected to the management network
The two DCs have two interfaces connected to the management network for redundancy and failover. If one of the interfaces fails, the other interface can be used to manage the DC. Additionally, the two interfaces can be used to load balance management traffic.
3. "2 IOS-XE SD-WAN (C8000v) branch routers with 1 router at each branch and 1 vEdge Cloud branch router".
Yes, this means that each branch will have 2 vEdges: 1 physical vEdge and 1 Cloud vEdge. The physical vEdge is deployed at the branch site and provides connectivity to the branch network. The Cloud vEdge is deployed in a cloud environment and provides connectivity to cloud-based applications.
The reason for having two vEdges at each branch is to provide redundancy and failover. If one of the vEdges fails, the other vEdge can be used to maintain connectivity. Additionally, the two vEdges can be used to load balance traffic between the branch network and the cloud.
Hope this helps.
11-30-2023 01:15 AM
Thank you for this helpful answer.
but, sentence 2 meaning the 2 DCs (dc-cedge1 and DC WAN) are not virtual in the DC/Regional Hub but are 2 separate routers?
So "Centralized hub-n-spoke control policy activated so that, SD-WAN overlay tunnels are formed in Hub-n-Spoke topology with all spokes forming IPsec tunnels only with DC/Hub router" are tunnels established to DC/ regional (contains vSmart, vBond, virtual vManage)? I think branches need to set up tunnels to DC WAN to transmit data to each other, right?
11-30-2023 01:30 AM
Thats correct that the two DCs (dc-cedge1 and DC WAN) are virtual two separate routers, in a production environment they would be physical routers. The centralized hub-n-spoke control policy means that all of the branches will form IPsec tunnels with the DC/Hub router. This means that all data traffic between the branches will go through the DC/Hub router.
In this particular design, the branches do not need to set up tunnels to each other to transmit data. This is because all of the traffic between the branches is routed through the DC/Hub router. This can simplify the network design and reduce the amount of bandwidth required between the branches.
Hope this helps
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide