Skype For Business Online - Signal and Media Traffic Flow - LAN Users

Skype For Business Online - Signal and Media Traffic Flow

Hope you have already gone through the brief about types of traffic and protocols used in Skype for business.

If not, here is the link to have a look https://sjohnonline.blogspot.com/2018/12/skype-for-business-online-types-of.html.

Here we are going to see about how the traffic flows when you initiate a Skype call/sharing session in a LAN network.

Skype signalling and media traffic flow between LAN users

Skype uses ICE protocol to establish the communication between peers, let me take you through the  process happening in the background.

Step 1 SIP Registration and Candidate discovery

SIP Signalling initiate user authentication and registration with MRAS server in O365 cloud and identify the IP addresses, ports and protocols used by caller, in our case caller is user01

Step 2 invitation with SDP Candidates of caller.

User01 invites user02 by sharing the details of IP addresses, ports and protocols used by user01.

Step 3 Invitation acceptance with SDP Candidates of callee

User02 accept the invitation and share the details of IP addresses, ports and protocols used by user02 with user01.

During this time caller can hear the ring tone which indicates that the connection establishment is in progress.

Step 4 Candidate exchange and connectivity check (Candidate validation)

Caller and callee exchange their IP addresses and ports details with each other and try to check connectivity between the users via all possible routes available.

In our case the details of Candidate is as follows (Candidate - IP addresses, and ports).

 User01 

Local IP address - 192.168.10.44

NAT IP address/Public IP - 106.23.110.116  (Also called as reflex IP address)

Relay server IP address - 52.112.132.73 (Also called as relay IP address)

User02

Local IP address - 192.168.1-.125

NAT IP address/Public IP - 106.23.110.116 Also called as reflex IP address)

Relay server IP address - 52.112.132.65 (Also called as relay IP address)

Here the reflex IP addresses (NAT IP's) are same for both users as they both belongs to same LAN network

Connectivity checks are performed to find out the most direct media path possible between endpoints using STUN protocol.

As UDP is preferred for audio/video communication, the connectivity checks start with UDP 

a) First try to check connectivity between local IP's 192.168.10.44 & 192.168.10.125 over UDP

b) Then try to check connectivity between reflex IP's 106.23.110.116 over UDP

c) Finally try to check connectivity between relay IP's  52.112.132.65 & 52.112.132.73 over UDP

d) If all the above checks failed then start the connectivity check using TCP.

Step 5 Connection establishment 

After the connectivity checks, STUN protocol will evaluate the routes identified and find out most direct route to establish connection between the users.

In this scenario connection establishment between users will be via local IP's 192.168.10.44 & 192.168.10.125 as both belongs to same LAN networks, so the shortest route and NAT IP's are same.

If both the users are on same LAN network and using different internet connections, then the connection may establish via reflex/NAT IP's.

Since the clients are behind a NAT device direct communication may fails and connection established using Reflex IP addresses 52.112.132.65 & 52.112.132.73.

As mentioned if none of the above connectivity method is possible, connection will be established using the relay server in O365 cloud and which may effect quality of communication.

So if you are calling your colleague who belongs to the same network, the voice, video and sharing session traffic will be exchanged between them through the local LAN network, that is via local cables and switches placed inside the office.

But always remember you need a internet connection for signalling traffic but it won't eat up the internet bandwidth.

Always follow and implement Skype network requirement best practices in your network and open necessary ports and protocols in the firewalls to get the good quality communication.

Hope this is informative for you.

Cheers 😊

Skype For Business Online - Types of traffic and Protocols

Skype For Business Online - Types of traffic and protocols

Skype for business in O365  - One platform for calling, conferencing, video, and sharing.

As per the current trend 70% of onprem lync/Skype servers are now migrated to the cloud service called Skype for Business online in O365.

All of us are using it in our daily life but do you think whether all media traffic are always send via internet to reach the other end ?  in-fact not always, it depends upon where you are and how you communicate.

In this article we will see a brief about the basics of Skype traffic and  protocols used in the Skype online communication.

Type of traffic

1) Signalling - Set of protocols that helps to establish connection between caller and callee.

2) Media - Audio, video, desktop/program sharing and file transfer are all examples of media traffic.

Types of protocols used in the Skype communications

ICE - Interactive Connectivity Establishment (ICE)is a technique used in computer networking to find ways for two computers to talk to each other as directly as possible in peer-to-peer networking using technique that uses SDP, STUN, and TURN to discover a network path between peers on the Internet.

SIP - The Session Initiation Protocol (SIP) is a communications protocol for signalling, for controlling multimedia communication sessions.

These are set of control signals to initiate and process communication connection establishment.

SDP - The Session Description Protocol (SDP) is a format for describing streaming media initialization parameters. (Candidates - IP addresses, ports & CODECS)

This protocol identify the IP addresses, ports and protocols used by the caller and callee.

STUN - Session Traversal Utilities for NAT To determine the most direct media path possible between endpoints

This protocol helps to identify the most direct path to send the media between caller and callee by analyzing SDP.

TURN - Traversal Using Relays around NAT

 Discovery of paths between peers and exchange of media stream packets using media relay server 

This protocol helps in case no direct connectivity is available between caller and callee, the media traffic exchange happens with the help of Skype Media Relay server in the cloud. This method is opted only when there is no direct path between the caller and callee.

Five Phases of ICE

1) During Sign-in: Requesting token from Media Relay Authentication Service (MRAS)

 Call establishment: 

2) Candidate discovery - Identify the IP addresses, ports and protocols between the peers

3) Candidate exchange - Exchange the identified IP addresses, ports and protocols between peers

4) Connectivity check - Check the connectivity between peers

5) Candidate promotion - Promote the shortest/direct path identified to reach the peer.

When User01 try to call User02, the signalling traffic will do the following.

Identify the unicast IP address of O365 cloud server and then request a token from Media Relay Authentication Service (MRAS) server in O365 cloud.

SDP Collects the details of IP addresses, ports and protocols used by User01 and collect the same details from the User02 upon the invite request received on callee's end.

These SDP details are then exchanged between the User01 and User02.

Establish direct path between User01 and User02 to exchange media traffic with the help of protocol "STUN".

Here both Users are in the same LAN network, hence the media packet exchange happens between them via locally, that is via local switches & LAN cables.

Signalling traffic is required to keep the connection but it is lightweight and not much consume your internet bandwidth.

In your infrastructure the Skype for business online calls happens with in the LAN will not eat up the internet bandwidth but internet connectivity is required to establish and keep the Skype communications.

In the next article i will explain more about how the Skype traffic flows when a user call from internet to LAN, internet to internet, WAN (VPLS/MPLS) networks and conference calls.

 Hope this is informative for you and thank you for reading.

Cheers😊

Network Switch Configuration Backup Automation

Network Devices Configuration Backup Automation 

In this article, I'm going to explain about how to automate network device configuration backup using PowerShell and TFTP.

Here we are going to automate HP ,Cisco switches and Fortigate UTM configuration backup.

Manual backup of network devices in an infrastructure is a time consuming task.Many licensed applications are available in the market for taking the configuration backup of network devices from a central console but you have to pay for the license.

Therefore, this automated network device configuration backup solution is useful for those who have not purchased network management software and also the network infrastructure consists of number of switches, routers and firewalls.

This PowerShell script will save the configuration backup of all devices into the TFTP server's defined location, so it is definitely a time saver.

Here we are going to use the new module introduced in windows PowerShell (WMF 5.0 or later) “Posh-SSH module”, which is loaded with SSH commands to access and execute commands on the network devices.

Pre-requisites  

  ü  Windows PowerShell version 5.0 or above

Open an administrative PowerShell and execute the below command to check your PowerShell version.

If it is below 5.0, update your PowerShell Version first.

Reference : https://docs.microsoft.com/en-us/powershell/wmf/5.1/install-configure

 ü  Posh-SSH module should be installed on windows PowerShell

Open an administrative PowerShell and execute the below command

Reference: https://www.powershellgallery.com/packages/Posh-SSH/2.0.2

 ü  Install and configure a TFTP Server (Refer Step 2)

 ü  SSH should be enabled on all network devices

 ü  All devices should be configured with same login credentials (Read only)

 ü  After logging in, the devices should be in "Enable" (Privileged #) mode

 ü  Network devices firmware should be in-line with industry standards

 ü  Add IP address of devices into hp.txt, cisco.txt and fortigate.txt into the “content” folder.

 ü  Not recommended to run on any servers installed with SCCM, WDS or any other tftp services.

 ü  Login credential need to be encrypted and saved in a text file Pass.txt. Copy the pass.txt file into the script “content” folder.

How to Convert

Open Administrative PowerShell window and execute the command below.

"Temp123*" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\pass.txt”.

Password – Temp123*

Output File – pass.txt in C drive

Note: In case if your password contains special characters like "$" make sure you input the password in below format. Otherwise while encrypting the password get altered.

Example:

Temp123$upp0rt

"Temp123"+"$"+upp0rt

How to use the script

 1)      Download the script “Network_switch_auto_backup.ps1” from the GitHub repository and extract it into any drive.

https://github.com/Sijoejohn/Network-Device-Configuration-Backup

 2)      Open tftpd64 folder under script root folder and run tftpd64.exe, note down the IP address and edit the following settings. It is a one-time job.

      

       2a)  Open Tftpd64 program, click on Settings button.

2b) Settings window will open as shown below. Put a check mark only to TFTP Server option. Remove check mark from all other options

2c) then next select TFTP tab. click on Browse button to specify Base Directory. You need to specify the Base Directory of the TFTP Server. Set your script root folder as the base directory.

Ex: H:\Network_switch_auto_backup

Where H = your disk drive where the script folder is extracted to. Network_switch_auto_backup is the script root folder.

2d) Under TFTP Security, select the option None

2e) A very important Step, Bind TFTP to this address: To set the IP address for TFTP server, please select the option Bind TFTP to this address then select the IP address available for you. You may get a different IP address, please use the IP address available in the drop down window.

You have to note down bonded IP address and write into the script line as mentioned in Step 3.

2f) once you have performed all the above steps, Click on OK. Now you will receive a window asking to restart Tftpd64 to apply the new settings. Click on OK.

2e) Reopen Tftpd64 program. Just ensure that you selected same IP address for Server Interface.              

Reference: http://techzain.com/how-to-setup-tftp-server-tftpd64-tfptd32-windows/

 3)      Edit the following portion in the script

 If user name to login to your device is not "manager”, change it to your user name.

$cred=New-ObjectSystem.Management.Automation.PSCredential ('manager',$securePassword)

Enter your TFTP server IP address (Bonded TFTP Server IP address – Step 2e)

$tftp_server="Enter your TFTP server ip address here" 

 4)      Open script root folder and navigate to “Content folder”

  Replace pass.txt with your encrypted device password key file

 Enter the IP address of HP devices into hp.txt

Enter the IP address of Cisco devices into cisco.txt

Enter the IP address of Fortigate devices into fortigate.txt


5)      Open a PowerShell (Administrative PS recommended) 

6)      Navigate and set path to script root folder

7)      If you want to backup HP devices configuration execute the below command

PS>.\Network_switch_auto_backup.ps1 HP

 8)      If you want to backup CISCO devices configuration execute the below command

  

 PS>.\Network_switch_auto_backup.ps1 cisco

8)      If you want to backup Fortigate devices configuration execute the below command

  

 PS>.\Network_switch_auto_backup.ps1 fortigate

9)      If you want to backup HP, CISCO and Fortigate devices configuration execute the below command.

 PS>.\Network_switch_auto_backup.ps1 All

                                                                                                             

 10)      Output will be saved in your script root folder

\2018\December\07122018\10.0.0.20\running-config.cfg

\2018\December\07122018\10.0.0.20\startup-config.cfg

Note : Fortigate devices backup will be saved into script root folder.

 11)      Logging is enabled on the script for troubleshooting, check “logs” folder under the script root folder if you come across any errors.

 12)      The script can be schedule using task scheduler to backup devices configuration as per the requirement.

How it works

1.      Script creates a folder at destination if it is not exist, folder structure as follows Year -> Date -> Switch IP.

2.       Get device IP addresses from the hp.txt& cisco.txt

3.       Import Posh-SSH module into PowerShell

4.       Create a SSH Session into each devices and save the configurations into the defined location one by one.

5.       Disconnect the SSH session.

Troubleshooting

1)  Logging is enabled on the script with run time, date and year, check the folder “logs”

Future Enhancements

1)  Expand functionality for larger pool of network devices.

2) Compare the startup and running config and remove running-config if both are identical.

Devices Tested

1) HP Switches (Procurve and Aruba)2) Cisco switches (iOS)3) Fortigate UTM

Hope this article helped you to automate the network switch backup.

Thanks for reading.

Happy Automation 

Cheers 😉

DHCP Failover Auto Config Sync (DFACS)

DHCP Failover Auto Config Sync (DFACS)

We have already gone through some limitations of DHCP Fail-over in windows server 2012, if you have missed my previous article here is the link 

https://sjohnonline.blogspot.com/2018/12/dhcp-fail-over-implementation-windows.html

Microsoft provided a solution to overcome some of the limitation, which is a PowerShell script which is detailed below in this article.

Anyway this limitations are not there in the windows server 2016 release 

DHCP Failover on windows Server 2012 is a good alternative for DHCP in a Windows failover cluster and Split scope DHCP. But If the user makes any changes in any property/configuration (e.g. add/remove option values, reservation) of a failover scope, he/she needs to ensure that it is replicated to the failover server. 

Windows Server 2012 provides functionality for performing this replication using DHCP MMC as well as PowerShell. But these require initiation by the user. 

This requirement for explicitly initiating replication of scope configuration can be avoided by using a tool which automates this task of replicating configuration changes on the failover server. DHCP Failover Auto Config Sync (DFACS) is a PowerShell based tool which automates the synchronization of configuration changes. This document is a guide to using DFACS.

Replication of scope configurations

The first time failover is configured on a server, the scopes involved are replicated to the failover/partner server. Post that, any changes in the configuration of these scopes on any one of the servers need to be replicated on the other by invoking the “Replicate scope” or “Replicate Relationship” action in DHCP MMC (Invoke-DhcpServerv4FailoverReplication cmdlet in DHCP PowerShell) in order to ensure that clients get the same configuration irrespective of the DHCP server that serves their request. The admin can automate this by using a tool that replicates scope configuration changes on a periodic or event driven basis.

DHCP Failover Auto Config Sync (DFACS)

DFACS is a tool which tracks any scope configuration changes and replicates them on the failover server. The tool uses the configuration change events logged by the DHCP server in the operational channel to determine if there has been a configuration change in any of the scopes of a failover relationship. 

If it finds any such change it replicates that change to the failover partner server. In addition to the configuration sync being triggered by configuration change events, the tool also periodically performs synchronization of configuration changes to the failover partner server. 

DFACS integrates seamlessly with the Windows Task Scheduler. 

This ensures the following:

·         An instance of DFACS is always running unless explicitly terminated. The Task Scheduler starts an instance of it at system startup.

·         DFACS can be provided suitable user credentials and can run even in remote server management scenarios where no users may login to the machine.

The tool can run in two modes:

·           Default Replication mode: The tool monitors and synchronizes configurations of all scopes of all failover relationships that the server is a part of.

·            Selective Replication mode: The tool monitors and synchronizes configurations of all scopes of only specified failover relationships that the server is a part of.

Note: The Selective Replication mode can be used to make exclusions only at the relationship level and not at the scope level.

DFACS, by its design, can be used only in cases where configuration changes for scopes in a failover relationship are always made on only one of the DHCP servers in the failover relationship. 

Running DFACS on both servers to cater to the same failover relationship will cause one of the instances of DFACS to terminate. Nevertheless, it can run on the two servers if it is configured to run in Selective Replication mode and to cater to different failover relationships on each of them. 

The Selective Replication mode can be particularly useful in topologies where the primary server can be in failover 

Fig. 1. Some failover setups where Selective Replication mode of DFACS can be useful

relationships with a number of servers and changes for only selective relations are to be considered. Some complex topologies where Selective Replication mode can come handy are shown below:

How to use the tool

DFACS comes as a packaged zip file and consists of two PowerShell scripts and an xml file. The xml file contains values for settings like periodic retry interval and name of the log file. 

Using the xml file, the administrator can also set the tool to run in a Selective Replication mode and specify the failover relations that are to be included/excluded in/from the sync process.

The procedure for installing and running DFACS has been described in the steps below:

1. Extract the contents of the tool package (DhcpFailoverAutoConfigSyncTool.zip) to a folder.

2. Ensure that the settings for DFACS in the xml file have been set as desired. (See Changing the settings of the tool for details)

3. Open Windows PowerShell in administrative mode by right clicking on PowerShell button and selecting “Run as Administrator” option.

4. Change current directory in PowerShell to the folder where the tool package contents have been extracted.

5. Ensure security is removed from both downloaded scripts ( install.ps1, DhcpFailoverAutoConfigSyncTool.ps1). To do this you can use PS command let “Unblock-File <FileName>” or right click on file, go to Properties and under Security click “Unblock”.

 6. Ensure the execution policy has been set to ‘unrestricted’. The status of the execution policy can be retrieved by executing Get-ExecutionPolicy. It can be set to ‘unrestricted’ by executing Set-ExecutionPolicy -ExecutionPolicy Unrestricted.

 7. Ensure the account running DFACS has permissions to modify the registry path:  HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\DHCPAutoSync and also account is part of group “WinRMRemoteWMIUsers__”

Run the script: .\install.ps1. This will install DFACS as a task in the task scheduler

Fig. 2. Installing DHCP Failover Auto Config Sync using PowerShell   1. To run the tool, start Windows Task Scheduler and navigate in the tree view of the navigation pane to Task Scheduler Library->Microsoft->Windows->DHCPServer. Refresh the folder in the navigation pane if the task scheduler is already running. The folder DHCPServer might be located at the bottom of the list

Fig. 3. A Task for DFACS created in the task scheduler

  1. Right click on the task DHCPFailoverAutoConfigSyncTool and click on Properties.

  2.   Under Security Options, in the General tab, select ‘Run whether user is logged on or not’. Click OK and provide the appropriate credentials when prompted.

     The account must be a part of the DHCP administrators group and have the required privileges to start the tool on the machine on system startup and to replicate the changes on the failover partner.

Fig. 4. Select ‘Run whether user is logged on or not’ in the General Tab of Properties

     1. Right Click on the task DHCPFailoverAutoConfigSyncTool and click Run.

     2. The tool logs the record of all the synchronizations done in the log file (by default created in the folder where the tool package was extracted). This can be useful in troubleshooting.

Changing the settings of the tool

The xml file can be used to configure some important settings of DFACS. The file along with the configurable settings has been shown below:

<PSDhcpAutoSync>

<! -- File where console logs are created -->

<LogFileName>.\DhcpAutoSyncLogfile.txt</LogFileName>

<!--

        Periodic Retry Interval (in minutes)

        This is the duration between two successive Failover Replication attempts

-->

<PeriodicRetryInterval>30</PeriodicRetryInterval>

<!--

Default Replication Mode:

            By default, the tool auto synchronizes the changes across all

     Failover relations on this server

Selective Replication Mode:

            If you choose to include only specific Failover relation(s) that

should be synchronized by this tool, do the following

            a) Uncomment <FailoverRelationships> node given below

            b) Add the Failover relationship names under <Include> node,

the ones you wish the tool should auto synchronize.

               [This means, all the other relationships will be ignored by the tool]

            c) Add the Failover relationship names under <Exclude> node,

the ones you wish the tool should Exclude from auto synchronization.

               [This means, all the other relationships will be

considered by the tool for auto synchronization]

-->

<!--

<FailoverRelationships>

<Include>

<Relation>FailoverServer1-FailverServer2</Relation>

</Include>

<Exclude>

<Relation>FailoverServer1-FailoverServerver3</Relation>

</Exclude>

</FailoverRelationships>

-->

</PSDhcpAutoSync>

The tags and the settings that can be used to configure are:

 <LogFileName>tag contains name/path of log file where all logs are dumped.

 <PeriodicRetryInterval> tag contains the frequency time in minutes at which the tool automatically synchronizes pending configuration changes. A very small periodic retry interval will lead to more CPU usage by the tool.

<Include> tag contains name of the relations to be included for consideration in automatic sync process on this server. If nothing is mentioned in 

<Include> tag, all relations other than the relations mentioned in 

<Exclude> tag will be considered.

Usage Guidelines

The configurations of the scopes involved should be in sync prior to starting the tool.

 Any change in the xml configuration file will require the tool to be restarted to take effect.

When running in selective replication mode where relationships to be excluded are mentioned; creation of a new failover relationship (which is intended to be included in the sync process) will require the tool to be restarted to take effect.

The task Scheduler can also be made to keep a history log of the operations of the task DHCPFailoverAutoConfigSyncTool task. This is a common setting for all the tasks in the Task Scheduler. Details can be found at http://technet.microsoft.com/en-us/library/cc722006.aspx.

Use DFACS only on one of the servers in a failover relationship. It is on this server that any changes in the configuration of the scopes involved must be made. Any attempt to run the tool on both the servers to synchronize scope configuration changes of their failover relationship will abort that instance of the tool which was started later. Use Selective Replication mode if DFACS is to cater to different failover relationships on the two servers.

DFACS uses the event log file of DHCP server. The size of this event log file should hence be large enough so that no change log gets erased before it is read.

 Go to ‘Event Viewer’ application.

In the left pane click on Applications and Services Logs > Microsoft > Windows > DHCP-Server.

Right click on “Microsoft-Windows-Dhcp-Server/Operational” log and click on “Properties”.

Change Maximum log size to around 10 MB i.e. 10240 KB and click Apply and Ok.

Ensure that PeriodicRetryInterval is not less than 1 minute as it can lead to a high CPU usage.

DFACS can also be run in a command shell window. To do this right click on the task DHCPFailoverAutoConfigSyncTool in the Task Scheduler and click on Properties.

 Go to the Actions tab and click on Edit. Delete the ‘-WindowsStyleHidden’ argument from the add arguments text box and click OK. End the DHCPFailoverAutoConfigSyncTool task and Start it again. This would make DFACS run in a visible window. Closing the visible window would terminate the tool.

·        

Fig. 5. By removing the ‘-WindowsStyleHidden’ argument, the tool can be made to run in a visible window

·      If DFACS is to be stopped on the current server for starting an instance of it on the failover server the following steps must be observed:

    The DHCPFailoverAutoConfigSyncTool task must be stopped on the current server.

    The registry entry for the tool must be deleted from the current server. The registry entry can be deleted using Registry Editor. It resides at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\DHCPAutoSync

    For the tool to continue functioning, any changes in the credentials being used by the tool must be manually updated in the credentials stored with the Task Scheduler.

   

    For eg. If the password of the credentials has to be changed due to expiry, the new password must also be provided to the instance of the tool in the Task Scheduler.

   

  

    For more information on the usage, use 

    ps>.\DhcpFailoverAutoConfigSyncTool.ps1 –h

             Download the Tool from

  

    https://gallery.technet.microsoft.com/scriptcenter/Auto-syncing-of-   configurati-6eb54fb0

Limitations - DFACS

DFACS has the following limitations which are important for consideration while using it:

·     It cannot be used in cases where configuration changes for scopes in a failover relationship are being made on either of the DHCP servers.

·      Following scope configuration changes are not instantaneously synchronized by the tool as there are no events logged for these changes in DHCP operational event log. However, these changes will get synchronized in the periodic synchronization process.

o   Scope IP range change in scope properties.

o   Activation/Deactivation of policies under scope.

o   Deletion of scope options.

    ·Configuration changes made to server level configuration (e.g. server level options, policies etc) are not synchronized by this tool.

     Those who are going to setup DHCP Failover need to configure this in the server to ensure the scope replications happens between the partner servers. In case if you already have a DHCP Failover in your environment configure DFACS to make your DHCP service error free.

     Hope this article helps

     Cheers😃