Thanks for another great video! I read through the Ciscopress SDWAN: Designing, Deploying, and Securing your Next Generation WAN with Cisco SD-WAN book (great book btw!) and wanted to throw in some information I took notes on in regards to the issue with the vEdge's trying to build across all colors. You were spot on with the "restrict" option. There is also another method. Below are the notes I took: - By default, WAN Edges will attempt to build data plane tunnels to each other site using every Color available. - If that is not desired, then you can configure the "restrict" attribute in the TLOC. This will prevent tunnels from being built to that color from another color. - Another method to restrict tunnels from being built is by using Tunnel Groups. You can configure it so that tunnels are only built to other TLOCs in that tunnel group - An example would be where you have a data center with two MPLS connections and one Internet connection. You have two branches, and each one only has access to one MPLS provider and one Internet connection. If you were to just use Colors with Restrict, then the branches would only be able to build to the MPLS interface of the Data Center with that same color. However, if you put all of the MPLS interfaces in the same tunnel group, and the Internet interfaces in another one, then all of the MPLS interfaces will form tunnel adjacencies.
Hi Rob, just found the channel/subscribed as I am currently starting to learn this topic for work - you're a natural at teaching, fantastic SD-WAN series and explained really well and very informative, you kept me engaged all the way thru, thanks for your hard work super appreciated. Shall be keeping an eye on your channel from now on, great stuff... :)
Rob, can you share this eve-ng SD-WAN toplogy in the membership section? The one you shared in the members section has different ip address in the mpls, Inet and DC-SW Gi0/0 etc. The MPLS and Inet config files shared don't match this video's ip's either. I went and changed the devices and IP's myself to match what Rob's doing here, seems the ones on the membership site are not matching on purpose from what Rob was saying in his Thursday night support video. One thing to note is I never said I could not change IP's nor that I needed someone to change them I asked if you had files that matched and the obvious if you did can you upload them. I have Learned a bunch from this series thank you.
Thanks for the labs. FYI, I'm running version 20.3.4 without any major hitches. It does seem that tftp is not supported for the copy cert operations but I work around it using vshell and pasting the certs to the local file system, then import. Good work!
Rob great videos!! In terms of getting cross transport BFDs up, I think you missed one step. Yes INET->MPLS BFD would be OK because you have that connection between INET and MPLS and vEdges have default route out INET transport so yes it will work. I believe the issue you ran into was the return, MPLS->INET BFD. The MPLS router has the static route (192.1.0.0/16) back to INET but did you redistribute that into BGP 100 on MPLS router so the vEdges learn that route? If you didn’t include that MPLS->INET BFD would fail, keep it up!! MPLS# router bgp 100 ! address-family ipv4 redistribute static
Correct !! You can even use NAT Between MPLS and INET transport. One thing to note is that ICMP traffic routes per destination based. But Tunnel traffic routes the same interface it originates on regarding of the routing table.
26:35 I had to turn off the interface ge0/0 and remove it from vpn 0 to get rid of the partial control status =) 😀 It seems vManage read that vEdge5 has 2 WAN connections.
Hi Rob, thanks for the SD-WAN series of videos, the vEdge onboarding process seems to be very complex, is that because we're using vedge ? for real hardware, I assume there is a zero touch provisioning process that the cert and controller/orchestrator related configuration can be pushed to device easily ?
Hi! I really appresciate you job! i really amazed by the work you have done. just let me know how to configure switches and random router, i mean MPLS INET, i cant ping through to them
Thank you for this video. I tried a minimal version of the lab with just 2 vEdges, and even after all the configuration, there are no bfd sessions. The "show bfd sessions" command turns up empty, even though the control connections are all up on the MPLS and INET colors. Also in the vManage GUI, I can see all the control connections up. What could be the issue?
Did you manage to resolve this? I have the same issue. No output in show bfd session and show ipsec outbound-conn. This has something to do with viptela versions. I am on 20.4.2. I rebuild this on a second lab in GCP and still has the same issue. One of my labs running 18.4.4 did not have this issue. I can see a few others in commends having the same issue in SD-WAN004 as well. What version are you using? Has anyone else managed to get this working in non 18.x version?
Found the root cause. Its because we copy paste Site ID on vedge3,4, 5 without changing site ID to 3,4, and 5. Correct the site ID so Viptela knows they are different WAN sites.
Hi Rob, I have gone through multiple Tutorial for CISCO SDWAN and Must say it's a Best SDWAN Tutorial in Yotube, Thank you so much for shariring these vedios ! I have one query,During Brownfield Migration- if we have any site with only MPLS circuit and want to Migrate to SDWAN( Considering All 3 controllers in Cloud) over same circuit then in this case how we can onboard vedge or how will reach to Vbond or ZTP server for initial authentication or orchestration as these controllers have public IP ? like as we know in case of Internet circuit it's very convenient for Vedge to reach out to public Vbond or controllers for successful on-boarding.
You would have to make a concession and give access internet access to those sites via MPLS. It's not very hard to do, backhualing internet over MPLS VPNs. If there's a business use case, IT has to figure it out, ya know what I mean?
@@RobRikerTechChannel Thank you Rob for explanation ! Yes, what I understood is need to ask MPLS provider to give access towards Internet in order to reach controllers in the cloud.Also am very curious to know there are many SDWAN vendors like Fortinet & Silverpeak which doesn't have separate control plane component( like we have Vsmart in CISCO) and as I understand in Fortinet solution - Control plane and data plane exists on edge devices itself, Do you think such solutions are scalable and achieve Granular or extensive Traffic Engineering please.
Hey Rob... I know it's 2 years later but I have built the same lab and having and issue at my dual site, the mpls link is showing down but they are able to ping each other via mpls🤷🏻♂️
Hi Rob... i am in video 5 .. i am unable to ping 172.31.12.2 from Vedge1 logs as below , can you pls help here .. there is no routing in 192.31.12.0/24 in Vedge1 VEDGE1# sh 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 10.1.16.0/24 connected - ge0/2 - - - - - F,S 0 10.12.0.1/32 connected - system - - - - - F,S 0 172.31.11.0/24 connected - ge0/1 - - - - - F,S 0 172.31.13.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S 0 172.31.14.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S 0 172.31.15.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S 0 192.1.1.0/24 connected - ge0/0 - - - - - F,S 0 223.1.1.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S VEDGE1# show bfd sessions SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 10.3.0.1 3 up mpls mpls 172.31.11.2 172.31.13.2 12426 ipsec 7 1000 0:00:39:25 0 10.3.0.1 3 down public-internet public-internet 192.1.1.2 192.1.3.2 12386 ipsec 7 1000 NA 0 10.4.0.1 4 up mpls mpls 172.31.11.2 172.31.14.2 12386 ipsec 7 1000 0:00:39:25 0 10.4.0.1 4 down public-internet public-internet 192.1.1.2 192.1.4.2 12366 ipsec 7 1000 NA 1 10.5.0.1 5 up mpls mpls 172.31.11.2 172.31.15.2 12406 ipsec 7 1000 0:00:38:52 0 VEDGE1# ping 172.31.12.2 vpn ? Description: List of VPN instances Possible completions: 0 512 VEDGE1# ping 172.31.12.2 vpn 0 source ? Possible completions: Source interface or IP address VEDGE1# ping 172.31.12.2 vpn 0 source ge0/0 Ping in VPN 0 PING 172.31.12.2 (172.31.12.2) from 192.1.1.2 : 56(84) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable
Did you manage to resolve this? I have the same issue. No output in show bfd session and show ipsec outbound-conn. This has something to do with viptela versions. I am on 20.4.2. I rebuild this on a second lab in GCP and still has the same issue. One of my labs running 18.4.4 did not have this issue. I can see a few others in commends having the same issue in SD-WAN004 as well. What version are you using? Has anyone else managed to get this working in non 18.x version?
@@johnmathew5115 Sure, I was using the same site id on the vedges, which is wrong, however there is a feature that you can apply to have an ipsec tunnel with the same site id
@@choe182 Thank you so much. This ended up being the problem. I have corrected my Site ID from 12 to the correct site ID such as 3,4,5 and all my bfd sessions are now working.
Hello Sir, How are you, I like you channel and recomend for every one its a very best channel for SDWAN learning, Sir if you don't mind could you shere this topology with me. thank you very much. CCIE # 47481 HCIE # 9339
Hi Rob... i am in video 5 .. i am unable to ping 172.31.12.2 from Vedge1 logs as below , can you pls help here .. there is no routing in 192.31.12.0/24 in Vedge1 VEDGE1# sh 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 10.1.16.0/24 connected - ge0/2 - - - - - F,S 0 10.12.0.1/32 connected - system - - - - - F,S 0 172.31.11.0/24 connected - ge0/1 - - - - - F,S 0 172.31.13.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S 0 172.31.14.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S 0 172.31.15.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S 0 192.1.1.0/24 connected - ge0/0 - - - - - F,S 0 223.1.1.0/24 bgp e ge0/1 172.31.11.1 - - - - F,S VEDGE1# show bfd sessions SOURCE TLOC REMOTE TLOC DST PUBLIC DST PUBLIC DETECT TX SYSTEM IP SITE ID STATE COLOR COLOR SOURCE IP IP PORT ENCAP MULTIPLIER INTERVAL(msec) UPTIME TRANSITIONS ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 10.3.0.1 3 up mpls mpls 172.31.11.2 172.31.13.2 12426 ipsec 7 1000 0:00:39:25 0 10.3.0.1 3 down public-internet public-internet 192.1.1.2 192.1.3.2 12386 ipsec 7 1000 NA 0 10.4.0.1 4 up mpls mpls 172.31.11.2 172.31.14.2 12386 ipsec 7 1000 0:00:39:25 0 10.4.0.1 4 down public-internet public-internet 192.1.1.2 192.1.4.2 12366 ipsec 7 1000 NA 1 10.5.0.1 5 up mpls mpls 172.31.11.2 172.31.15.2 12406 ipsec 7 1000 0:00:38:52 0 VEDGE1# ping 172.31.12.2 vpn ? Description: List of VPN instances Possible completions: 0 512 VEDGE1# ping 172.31.12.2 vpn 0 source ? Possible completions: Source interface or IP address VEDGE1# ping 172.31.12.2 vpn 0 source ge0/0 Ping in VPN 0 PING 172.31.12.2 (172.31.12.2) from 192.1.1.2 : 56(84) bytes of data. ping: sendmsg: Network is unreachable ping: sendmsg: Network is unreachable
You won't be able to. vEdge 1 and 2 are part of the same site. They both use the same BGP ASN so you run into the AS path loop prevention mechanism. You can override this on the MPLS router by using the "as-override" command on each neighbor, vEdge 1 and vEdge 2. But when you think about it, it's pointless for a vEdge to communicate with another vEdge at the same site. You have vEdge3, 4 and 5 present which is the main goal. When you get further into the series, you'll see why, specifically iBGP peerings later.
