SDWAN - Port Hopping and Port-Offset with example

Port Hopping: 

WAN Edge devices manage control plane connectivity using port hopping.

To summarize and clarify:

• Default base port: 12346

• Port hopping pattern: Increments by 20, trying 12366, 12386, 12406, 12426, then loops back.

• Enabled by default on WAN Edge routers, but can be disabled globally or per interface

• Recommended practice:

  • Enable on branches for better connection reliability

  • Disable on data centers, hubs, or high-traffic locations to avoid connection disruption

• Disabled by default on controllers (vManage, vSmart) and should remain disabled

• vManage/vSmart with multi-core setup: Use different base ports per core

Port Offset:

Why Use Port Offsets Behind NAT?

When multiple WAN Edge routers sit behind the same NAT device and share a public IP address, if they all use the same base port (12346) to initiate connections to the controllers, the NAT device may not handle translation cleanly, causing connection failures or instability.

Solution: Port Offset

• Base Port: 12346

• With Port Offset = 1:

  • Base port becomes 12347

  • Port hopping pattern becomes: 12367, 12387, 12407, 12427

vBond IPs and port are static, It is recommended to permit UDP destination port 12346 to vBond and permit UDP source port 12346 from vBond.

This offset ensures each WAN Edge behind the same NAT has a unique source port pattern, minimizing NAT conflicts and making port usage predictable.

Default Behavior

• Port Offset = 0 by default (i.e., no change from 12346)

• You must explicitly configure an offset per WAN Edge router

Now Lets Play with Port-offset 

from vEDGE to Other vEDGE and Controllers BFD session and Control Connections  with destination UDP port 12346

Lets change the Port-offset = 2 on vEDGE 

all BFD and IPsec tunnel are reset 

CISCO ISE - How to change DOMAIN NAME

            TASK - Need to change the Domain for ISE  

Current Domain Name - dsldevice.lan

Changed Domain Name - bignetwork.com

STEP 1 - First check current domain name 

STEP 2 - During bootup if you want to change the domain name you will see below 

When you apply "ip domain bignetwork.com" , ISE will ask you with below Warning 

When you ask to YES then it will start stoping services 

Again it started the Services 

STEP 3- Validation 
now you can validate the domain has been changed

SDWAN tloc-list verses local-tloc-list

CASE STUDY - LOCAL-TLOC-LIST ver TLOC-LIST

LOCAL-TLOC-LIST 

Syntax : set local-tloc color {color} [encap {ipsec|gre}] 

where color is any one of the supported TLOC colors. This action directs packets to be forwarded out of the TLOC that is specified in the color argument. If this TLOC is not available (because it is not configured, the tunnel is down, or so on), then the traffic is forwarded out any valid TLOC, as indicated by the routing table. There is also a configuration command called set local-tloc-list that allows for the selection of one or more colors.

local-tloc action selects the preferred egress TLOC on the local WAN Edge router, while the
TLOC-List action mandates the TLOCs on the receiving WAN Edge that the traffic will be forwarded to

CONFIGURATION DIFFERENCE 

Seqence 11 for youtube traffic follow the traffic path biz-internet and when biz-internet down it take path from avalible color - mpls 

sequence 11

  match
    app-list YouTube
     source-ip 0.0.0.0/0
!
 action accept
set
 local-tloc-list
  color biz-internet
  encap ipsec

Sequence 21 is for fackbook traffic during biz-internet UP will follow biz-internet path but when biz-internet down then fackbook traffic drop

sequence 21

    match

      app-list Facebook

      source-ip 0.0.0.0/0

!

    action accept

    set

       vpn 1

       tloc-list DC_INET_TLOCS

Let see when applying above command during avalibilty of  Color biz-internt and when BFD down for biz-internet so traffic for youtube and fackbook follow different way based on given command - local-tloc-list ver tloc-list 

FLOW EXAMPLE

When BFD related with Color- biz-internet - UP 

local-tloc-list 

Branch-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app youtube all

!

Number of possible next hops: 1

Next Hop: IPsec

Source: 100.64.102.2 12346 Destination: 100.64.21.2 12386 Color:biz-internet 

tloc-list

Branch-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app facebook all

!

Number of possible next hops: 1

Next Hop: IPsec

Source: 100.64.102.2 12346 Destination: 100.64.21.2 12386 Color:biz-internet 

When BFD related with Color- biz-internet - DOWN 

local-tloc-list

BR2-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app youtube all

dest-ip 0.0.0.0 protocol 1 app youtube all

Number of possible next hops: 1

Next Hop: IPsec

Source: 172.16.102.2 12346 Destination: 172.16.21.2 Color: mpls

tloc-list

BR2-vEdge-1# show policy service-path vpn 1 interface ge0/3 source-ip 10.1.102.1 dest-ip 0.0.0.0 protocol 1 app facebook all

dest-ip 0.0.0.0 protocol 1 app facebook all

Number of possible next hops: 1

Next Hop: Blackhole  <<<<<<<<<Traffic drop

SDWAN - DEFAULT ROUTE ADVERTISE HUB to REMOTE SITE

CONDITION 

We need to advertise default route from HUB as we have Firewall/Internet , So any Unknown Traffic should go to HUB first.

Backhauling moves the traffic to a datacenter where firewalls are deployed and a secure Internet access is available

Lets start 

From SITE - 100 HUB site , We adevertise the Default route in OMP 

Check BGP advertise Default from SITE 100 Router 

Now Check On vEDGE SITE 100 and see the Default route in Adevrtise from vEDGE 

OMP Routes 

Now check on SITE 300 , We have seen the Default route and notice this deafult route advertise by vSMART 

vSMART - System IP - 1.1.1.30

Now Open Route and see the Originator for default route.

Thanks will continue with Next blogs

SDWAN - BGP SERVICE VPN CONFIGURATION - USING TEMPLATE

 CONDITION 

Configure Service VPN with BGP for Remote Site communication 

Configuration Parameter

1. SDWAN Control plan and Data plan already preconfigured for connectivity

2. BGP between vEDGE and Router 

3. BGP AS Number 10 

4.Loopback1 Advertise in BGP 

5.Create BGP Template in Service VPN 

TOPOLOGY LAB

LETS START LAB - 

STEP 1 - To Create Feature Template BGP in SERVICE VPN 

The Below paramater select based on requirement 

BGP -

 Shutdown - No (Enabled BGP)

 AS Number - Device specific - It ask during Template push to Device 

 Router ID - Device specific 

 Other Parameter make Default 

Provide Redistribution OMP in BGP to get the Routes from OMP to BGP 

Now Lets configure BGP Neigbour - Put all Device Specific - will fill during apply on Device.

Now Feature BGP Template ready to call in Template , I have already below Template apply on Device 

Now Got to section Service VPN and Call BGP Feature Template here

And also got to feature template VPN 1 and enable BGP to OMP redistribution 

Now attached the template on device 

Attached Template with Device Specific Values 

Now Validate the Configuration 

First to Validate the Template enable on Device 

BGP Neigbour Status on VEDGE 

Router BGP status and Prefix learning 

Remote Site - 300 Subnet Recevied on SITE - 100

VEDGE 04 SITE 300 

SITE - 100 To SITE - 300 Communication check 

Will Continue with maniputaion in Next Blogs :)

EAP TYPE EXPLAIN

 EAP (Extensible Authentication Protocol) is an authentication framework used in wireless networks, VPNs, and other network access protocols. It supports various authentication methods to establish secure connections between clients and servers. Here are some commonly used EAP methods:

1. EAP-TLS (Transport Layer Security): EAP-TLS uses digital certificates for both the client and the server. It provides strong mutual authentication and secure key exchange. This method is widely used in enterprise networks where security is a top priority.

2. EAP-TTLS (Tunneled Transport Layer Security): EAP-TTLS is an extension of EAP-TLS that provides a way to securely transmit legacy authentication protocols over TLS. It allows for a variety of inner authentication methods, such as PAP (Password Authentication Protocol) or MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2).

3. PEAP (Protected Extensible Authentication Protocol): PEAP is designed to provide a secure authentication method within an encrypted tunnel. It encapsulates EAP methods, such as EAP-MSCHAPv2 or EAP-GTC (Generic Token Card), within a TLS tunnel. PEAP is widely supported by various operating systems and is commonly used in enterprise wireless networks.

4. EAP-FAST (Flexible Authentication via Secure Tunneling): EAP-FAST is an EAP method that provides a secure tunnel for transmitting credentials. It is designed to be more lightweight and efficient compared to other EAP methods. EAP-FAST uses a pre-shared key or a password to establish a secure tunnel between the client and the server.

5. EAP-SIM (Subscriber Identity Module): EAP-SIM is primarily used in mobile networks and relies on the SIM card in a mobile device for authentication. It leverages the security features of the SIM card to authenticate the user.

6. EAP-AKA (Authentication and Key Agreement): EAP-AKA is another EAP method used in mobile networks. It is based on the AKA algorithm used in the Universal Mobile Telecommunications System (UMTS) network. EAP-AKA provides mutual authentication between the client and the network.

7. EAP-MD5 (Message Digest 5): EAP-MD5 is a legacy EAP method that provides basic authentication using a shared secret key. It is considered less secure compared to other EAP methods and is not recommended for use in secure networks.

These are just a few examples of EAP methods. The choice of EAP method depends on the specific requirements and security considerations of the network deployment. It is important to select an EAP method that provides the desired level of security and compatibility with the client devices and authentication servers.

Large EAP-TLS Packet Problem

 When dealing with large EAP-TLS packets that are not authenticating wireless clients, there could be several potential causes for the issue. Here are some troubleshooting steps you can try:

1. MTU Size: Check if the Maximum Transmission Unit (MTU) size is properly configured on both the client and server sides. Large EAP-TLS packets may exceed the default MTU size, causing fragmentation issues. Ensure that the MTU size is set to accommodate the larger packets.

2. Fragmentation and Reassembly: Verify if fragmentation and reassembly are properly supported and enabled on both the client and server sides. Some devices or network configurations may not handle fragmented EAP-TLS packets correctly, leading to authentication failures.

3. Network Path: Verify that the network path between the client and the authentication server is not causing any packet loss or corruption issues. Use tools like packet captures or network monitoring tools to analyze the traffic and identify any abnormalities.

4. Certificate Issues: Check if the client and server certificates are properly configured and valid. Ensure that the certificates are correctly installed and trusted on both sides. Any certificate-related issues, such as expired or mismatched certificates, can prevent successful authentication.

5. Firewall or ACL Restrictions: Ensure that there are no firewall rules or access control lists (ACLs) blocking the EAP-TLS traffic. Check both the client and server sides for any restrictive policies that might be interfering with the authentication process.

6. EAP-TLS Configuration: Review the EAP-TLS configuration on both the client and server sides to ensure that all necessary parameters, such as certificate names, authentication methods, and cipher suites, are correctly configured and compatible.

7. Debugging and Logging: Enable debugging and logging features on both the client and server sides to gather more detailed information about the authentication process. Look for any error messages or warnings that might provide insight into the cause of the authentication failure.

If the troubleshooting steps above do not resolve the issue, it may be necessary to involve the network and system administrators or consult the documentation and support resources specific to the wireless infrastructure and authentication server being used.