Tuesday, March 31, 2020

Aware Software Infrastructure (VASI) NAT on a Stick



Configuration:
>> CSR1

interface GigabitEthernet1
ip address 192.168.123.1 255.255.255.0
negotiation auto
end

ip route 0.0.0.0 0.0.0.0 192.168.123.3

>> CSR2

interface GigabitEthernet1
ip address 192.168.123.2 255.255.255.0
no ip redirects
negotiation auto
end

ip route 0.0.0.0 0.0.0.0 192.168.123.3

>> CSR3

vrf definition BLUE
address-family ipv4
exit-address-family

interface GigabitEthernet1
ip address 192.168.123.3 255.255.255.0
ip nat inside
ip policy route-map PBR
negotiation auto

interface GigabitEthernet2
ip address 34.34.34.3 255.255.255.0
ip nat outside
negotiation auto

interface vasileft1
ip address 6.6.6.1 255.255.255.0
ip nat outside
no keepalive

interface vasiright1
vrf forwarding BLUE
ip address 6.6.6.2 255.255.255.0
no keepalive

ip nat pool NAT-POOL 10.0.12.0 10.0.12.255 prefix-length 24
ip nat inside source static 192.168.123.2 34.34.34.2 no-alias
ip nat outside source list NAT pool NAT-POOL

ip route 0.0.0.0 0.0.0.0 34.34.34.4
ip route 34.34.34.2 255.255.255.255 192.168.123.2
ip route vrf BLUE 0.0.0.0 0.0.0.0 vasiright1
ip route vrf BLUE 10.0.12.0 255.255.255.0 6.6.6.1
ip route vrf BLUE 34.34.34.2 255.255.255.255 vasiright1 6.6.6.1

ip access-list extended NAT
permit ip 192.168.123.0 0.0.0.255 host 34.34.34.2
ip access-list extended PBR
permit ip 192.168.123.0 0.0.0.255 host 34.34.34.2
permit ip host 192.168.123.2 10.0.12.0 0.0.0.255

route-map PBR permit 10
match ip address PBR
set ip next-hop 6.6.6.2

>> CSR4

interface GigabitEthernet2
ip address 34.34.34.4 255.255.255.0
negotiation auto
end


https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html
at No comments:
Labels:

Implementing bidirectional source NAT on IOS-XE platform

Introduction


In few scenarios customers wish to implement Source NAT in a bidirectional way. It means they wish to perform Source NAT while going from Interface 1 to Interface 2 and vice versa.

Problem


Current Solution is to achieve the same using NVI feature on IOS and it works perfectly as port overload can be done in both directions. The other alternative is to use traditional nat inside and outside interfaces and configure NAT accordingly. However performing port overload while defining "ip nat outside source xxx"  is not supported.

Now in IOS XE NVI feature is not supported. Hence we are left with only traditional NAT feature but it is not an scalable solution as we can't do port overload. We need to define pool of "n" IP addresses if we want to perform outside to inside source translation for "n" sources.

Solution


This problem can be resolved by using VASI feature available on XE platform. We need to keep interfaces in different vrf. For instance "Interface 1" can be in vrf A and "interface 2" can be in vrf B or any one of them can be in Global Routing table. At end of the day intention is to keep both interfaces in different Routing Domain.

Please find an sample Configuration to achieve the same below :--

Prerequisite:  We need to enable License appxk9 and then only we can create Vasi interfaces.


Topology :--

192.168.1.0/24------Gi0/0/0   (IOS-XE Router)   Gi0/0/2-----10.10.10.0/24

We have binded Gi0/0/0 and vasileft1 in vrf A
Gi0/0/2 and vasiright1 in vrf B
Pool K1 is used to NAT traffic coming from vrf A 192.168.1.0/24
Pool K2 is used to NAT traffic coming from vrf B 10.10.10.0/24
We need Routing in both VRF to point to each other for source subnets. I have used default routes but it can be replaced with routes for post NAT source IP's.


vrf definition A
!
address-family ipv4
exit-address-family
!
vrf definition B
!
address-family ipv4
exit-address-family
!


license boot level appxk9

interface GigabitEthernet0/0/0
vrf forwarding A
ip address 192.168.1.10 255.255.255.0
ip nat inside
negotiation auto
!

interface GigabitEthernet0/0/2
vrf forwarding B
ip address 10.10.10.1 255.255.255.252
ip nat inside
negotiation auto
!

interface vasileft1
vrf forwarding A
ip address 172.16.1.1 255.255.255.0
ip nat outside
no keepalive
!
interface vasiright1
vrf forwarding B
ip address 172.16.2.1 255.255.255.0
ip nat outside
no keepalive
!
!

!
ip nat pool K1 11.11.11.11 11.11.11.11 prefix-length 24
ip nat pool K2 22.22.22.22 22.22.22.22 prefix-length 24
ip nat inside source list 100 pool K1 vrf A overload
ip nat inside source list 101 pool K2 vrf B overload



ip route vrf A 0.0.0.0 0.0.0.0 vasileft1
ip route vrf B 0.0.0.0 0.0.0.0 vasiright1
!
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 101 permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255

at No comments:
Labels:

Wednesday, March 18, 2020

Best Practice for Viptela SD-WAN Controller Sizing

Specs

vBond – If less than 1000 sites, recommend 2 CPU & 4 GB RAM. Else 4 CPU & 8GB RAM. No additional storage needed. Boot disk has all allocated.
vSmart – Recommend going with 8 CPU and 16GB RAM. No additional storage needed. Boot disk has all allocated.
vManage – MUST be 32 CPU and 64GB RAM. Additional storage needed for databases. Recommend 1TB+

Storage recommended to be on SSDs.


See the table below for scaling requirements. Assuming two regions for two set of controllers. Also assuming N+1 redundancy for the controllers.

# of vEdges
# vBonds
# vSmarts
# vManages (Active)
< 2000
2
2
1
<2700
4
2
3
<4000
4
6
3
<6000
6
6
5
<8000
8
8
5
<10000
10
10
7
at No comments:

Maintaining a Simplified CA for SDWAN

Prerequisites

If you’re on a Mac, please ensure you have XCode installed.
If you’re on a Linux machine, please ensure you have the necessary openssl dependencies installed.


Creating the Directories

Create a folder for your CA.
Inside this CA, create the following at command line:

mkdir newcerts private
echo '12345601' >serial    
touch index.txt


OpenSSL CA Configuration File

Copy the openssl.cnf file provided along with this document to the folder for the CA.


Generate the Root CA

Execute this command at the CLI in the folder where you have created the files and placed the openssl.cnf file.

openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.cnf -subj "/C=US/ST=California/L=San Jose/OU=vIPtela Test/O=vIPtela Inc/emailAddress=aliis@cisco.com" -passout pass:PASSWORD


Signing Certificates

Copy the CSR for the new appliance in to the directory where you have the cacert.pem file generated. Use this command to sign new certificates.

openssl ca -out signed-cert.pem -config ./openssl.cnf -passin pass:PASSWORD -infiles signing-request.csr


Verifying Certificates

In the folder where you have the signed certificate for the CSR generated from the appliance, run the following command to validate that the certificate has been signed.

openssl verify -CAfile ./cacert.pem -verbose signed-cert.pem
at No comments:
Subscribe to: Posts (Atom)