Ask the Expert- SD-WAN fundamentals and implementation

[Cisco Moderador]

This topic is a chance to discuss more about SD-WAN, it's foundations and inner mechanisms as well as its correct design and implementation to achieve desired business outcomes. Software-Defined WAN (SD-WAN), is a popular technology and this event is aimed to help engineers/customers/partners understand the benefits and possible advantages that its implementation can bring.

To participate in this event, please use thebutton below to ask your questions

Ask questions from Monday 19th to Friday 30th of August, 2019

Featured expert

David Samuel Peñaloza Seijas works as a Senior Network Consulting Engineer at Verizon Enterprise Solutions in the Czech Republic. Previously, he worked as a Network Support Specialist in the IBM Client Innovation Center in the Czech Republic. David is an expert interested in all topics related to networks. However, he focuses mainly on data centers, enterprise networks, and network design, including software-defined networking (SDN). David has a long relationship with Cisco. He has been a Cisco Instructor for the Cisco Academy and was recognized as a Cisco Champion and a Cisco Designated VIP for 2017, 2018 and 2019. David holds a CCNP R&S, CCDP, CCNA Security, CCNA CyberOps and a CCNA SP certification. Currently, he is preparing for a CCDE.

David might not be able to answer each question due to the volume expected during this event. Remember that you can continue the conversation on the SD-WAN community.

Find other events https://community.cisco.com/t5/custom/page/page-id/Events?categoryId=technology-support  

**Helpful votes Encourage Participation! **
Please be sure to rate the Answers to Questions

[kevin.charron]

I have an issue using a NAT0 policy towards zScaler subnets for a couple of hybrid sites. I'll explain the "hybrid" setup I speak of. So, in an effort to get rid of AT&T Netgate solution as a backup VPN/Local Internet breakout, I have setup a couple of sites to only use the vEdge as a backup connection and local internet breakout.

For example, Site 1 is 10.6.160.0/20. On the MPLS side, I advertise 10.6.160.0/21 and 10.6.168.0/21. On the vEdge I advertise via an aggregate-route the 10.6.160.0/20, which isn't as specific and would only be used in the event the sites MPLS connection fails. This works as designed and when looking at the OMP route table, it see's the /21's from the traditional WAN and the /20 from the vEdge.

On the Core switch of the site (Cisco 3850) I have IP SLA configured to track routing and if working, send all traffic to zScaler to the vEdge. The vEdge has a local traffic policy to send traffic to those subnet via NAT0. This also works as designed.

Here is the issue. After a few day's, both sites just stop being able to browse the internet and the only workaround is to reboot the devices currently. These are local traffic policies, but the behavior would indicate something happening at a higher level. This happens on 18.4.0, 19.1.0 and 18.4.3.

Sites that are dedicated SD-WAN do not have these issues and have the same policy applied. I just don't know how to troubleshoot this or determine why it's happening. When looking at "show app cflowd flows", things look normal. No indication that it shoudn't be working.

Any thoughts on what could be happening?

[David Samuel Penaloza Seijas]

Hello @kevin.charron 

I have seen a similar behavior during migration between legacy solutions and SD-WAN, it was related to ARP cache not being flushed in the 3850 switch and IP redirects configured under the VLAN. The VRRP virtual IP was the same between devices so failover could be performed minimizing impact to the users. 

We had to involve TAC as it was quite an atypical behavior. The initial recommendation was to reboot the boxes due to time constraints. Later investigation revealed ARP was handled in different ways between viptela and the catalyst switch.

Hope that helps!

[kevin.charron]

Thanks for the feedback. Are you saying to issue the command "no ip redirects" on the Client VLAN, the interface to the vEdge (which is an L3 /30 link by the way) or both?

Also, arp timeout is on a per interface level. Should I reduce the timeout on the L3 interface of the vEdge?

And to my disappointment, a reboot of the device last night did not resolve the issue this time. I'm going to try and get a packet capture from vManage to see if I can get any useful data.

[David Samuel Penaloza Seijas]

The change must be done in the legacy infra (non-SD-WAN).

We got this when TAC got involved:

Prior to SD-WAN cut-over:

1. Execute “no ip redirect” on LAN port of legacy CE routers
2. Execute “no ip redirect” on VLAN interface of core switch 
3. Run “sh ip redirects” then “clear ip redirect” and “sh ip redirects” again on all access switches. Validate before/after output as ip redirect table should be empty in the end.

Hope it helps

[joshua-network-guy]

Hi David,

Can you route leak between a Services VPN and Transport VPN?

Thanks!

[David Samuel Penaloza Seijas]

Hello @joshua-network-guy 

Viptela supports route leaking between VPNs, but its intended for services VPNs, not transport and services. They are kept separate as the services VPNs are an overlay using transport VPN.

The following document explains route leaking: https://sdwan-docs.cisco.com/Product_Documentation/Software_Features/Release_18.3/04Segmentation/03Segmentation_(VPN)_Configuration_Examples

Thanks!

[joshua-network-guy]

Thanks David.

Yup understand what the original intention was.

But we have someone who has a requirement to access provider services via the MPLS underlay.

So unfortunately it is a needed.

I've seen it discussed here that the recommended solution is to have logical connections in the MPLS WAN via a services VPN.

Which we may end up doing but just exploring this option first.

[afroze]

For Local break-out MPLS, there is not feature as such, but this can be achieved by design 

You can have one of the interfaces ge0/2 (or sub-interface) on the vEdge/XE-SDWAN device connected to the underlay and place it in Service VPN n. This service VPN n will learn underlay routes via BGP. Use same VPN tag n for all the LAN segments that need access to the underlay sites. 

Traffic entering the router on the LAN interface in VPN n, if destined for an underlay site, will exit from ge0/2 and head to the PE router. Traffic destined for overlay sites should see a valid route through OMP and use the overlay path through VPN0 (Ge0/0 or Ge0/1)

HTH

[joshua-network-guy]

Thank you.

But would we still need to have 2 logical connections into the MPLS WAN.

One for underlay and one for overlay?

[daniel.dib]

Yes, you would. If the provider supports subinterfaces, you could use a single physical link but have two logical interfaces to the SP. You could then put one of them in VPN 0 and the other in the service VPN of choice.

[lishengtao]

Hi, is there any SLA violation events generated by vManage or v/cEdge? Or is there any API query for such violations? Let's assume SLA Class, Traffic Policy and Centralized AAR policy have been defined and applied to Device Template.

Thanks!

Shen

[David Samuel Penaloza Seijas]

Hello @lishengtao 

The notifications are generated for a plethora of events, see the following URL for more details: https://sdwan-docs.cisco.com/Product_Documentation/vManage_How-Tos/Troubleshooting/Monitor_Event_Notifications

Quoting:

When something of interest happens on an individual device in the overlay network, the device reports the event in the following ways:

Send a notification to the vManage NMS. The vManage NMS filters the event notifications and correlates related events, and it consolidates major and critical events into alarms.
Send an SNMP trap to the configured trap target. For each SNMP trap that a device generates, the device also generates a corresponding notification message.
Generate a system logging (syslog) message and place it in a syslog file in the /var/log directory on the local device and, if configured, on a remote device.

Notifications are messages that the device sends to the vManage NMS server.

Also, alarms can be monitored, this link also provides more information: https://sdwan-docs.cisco.com/Product_Documentation/vManage_How-Tos/Troubleshooting/Monitor_Alarms

Using vManage REST APIs: https://sdwan-docs.cisco.com/Product_Documentation/Command_Reference/Command_Reference/vManage_REST_APIs/vManage_REST_APIs_Overview/Using_the_vManage_REST_APIs

Events: https://sdwan-docs.cisco.com/Product_Documentation/Command_Reference/Command_Reference/vManage_REST_APIs/Alarms_Audit_Log_and_Events_APIs/Events

https://sdwan-docs.cisco.com/Product_Documentation/Command_Reference/Command_Reference/vManage_REST_APIs/Bulk_APIs/Overview_of_Bulk_API_Operations

[lishengtao]

Thank you David for the info! For the SLA specific events, I got the following from our Cisco support team and it works for me.

For Alarm event use POST API request to this below link

https://vmanage/dataservice/event  

use below payload

{

  "query": {

    "condition": "AND",

    "rules": [

      {

        "value": [

          "3"

        ],

        "field": "entry_time",

        "type": "date",

        "operator": "last_n_hours"

      },

                  {"value": ["major"], "field": "severity_level", "type": "string", "operator": "in"},

                  {"value": ["App-Route"], "field": "component", "type": "string", "operator": "in"},

                  {"value": ["100.90.3.4"], "field": "system_ip", "type": "string", "operator": "in"},

                  {"value": ["sla-change","sla-violation","sla-violation-pkt-drop"],"field": "eventname","type": "string","operator": "in"}

    ]

  },

  "size": 10000

}

[David Samuel Penaloza Seijas]

Thats excellent! Glad something was helpful!

[Hilda Arteaga]

Dear @David Samuel Penaloza Seijas 

Thanks for sharing your knowledge on this Cisco Community event, your participation is always impeccable and well received.  

Also, we would like to thank @daniel.dib who has been doing an amazing job helping to clarify diverse questions of this session. Thanks for extending the information and guiding the community members.

You are indeed admirable Cisco Designated VIP members!