N E T V I R T E X P E R T

     Recently, I had very interesting scenario around NSX ALB (ex Avi Networks) setup with multiple networks, NAT's and no-NAT's, but more important routing requirement inside Customer environment. As you are aware of - NSX ALB Service engines have multiple NICs - to be more accurate there are 1 management + 9 data interfaces, which can be used with different configurations depending on actual needs and infrastructure. In my specific case, there were following assumptions which were successfully deployed across virtual service configuration: - external network (from NSX ALB perspective) - based on Cisco ACI SDN solution, where basically different L3-outs (specific ACI setup) for multiple NSX ALB needs were configured directly on Cisco platform. For this purpose, we will introduce VRF named XYZ, specifically created for connections mentioned above; - there is a need for multiple floating IP + BGP config in place on NSX ALB SE's, which can be found on this link  Defaul...

     Different scenarios are possible in terms of routing, NAT-ing and IP overlapping setups using VMware Velocloud SD WAN technology in Customer environments.      Recently I had an PoC with my Customer for the on-prem option with this VMware solution, where different use cases were interesting to show and demonstrate - one of them is something I would like to share and it relates to possibility of LAN-side NAT on Edge (branch) locations, with purpose to have IP overlapped on these setups. Next picture is showing typical Hub&Spoke setup where it can be possible to make this type of configuration: Picture 1. VMware SD WAN lab on-prem environment     Basically thing which needs to be accomplished is appropriate NAT solution for LANs on every branch Edge which are and needs to be the same (192.168.1.0/24 in this example) - as it is shown on Picture 1.      Honestly speaking, NAT is not one of so powerful things insi...

     As you maybe know SIP doesn't like NAT :)... especially for IOS/IOS-XE Cisco based devices (ASA for example handle that much, much better). For that reason you need straight config to make it work - for control and audio part of communication. These are required steps in UC CME environment with public SIP account for trunk PSTN access: - define 1 ACL for udp SIP traffic (port 5060) and RTP audio port match - very probably high value ports: ip access-list extended UDP_RTP  permit udp any any range 8000 65000  permit udp any any eq 5060 - define 1 route-map (for NAT) that uses previosly created ACL: route-map SIP_NAT permit 10  match ip address UDP_RTP - define  STATIC NAT  translation for your inside SIP voice interface (this example uses 192.168.12.x for that purpose): ip nat inside source static 192.168.12.x [YOUR-PUBLIC-IP] route-map SIP_NAT Adequate ACL for WAN access and SIP secure communication should be in place if you're using public S...