NAT Static

I wont talk about what NATing does in this article. However, I will show you some basic configuration of NAT to clarify everyone understanding.


Configuration example

Configuration

R2

interface FastEthernet0/0

 ip address 192.168.1.2 255.255.255.0

 ip nat inside

 ip virtual-reassembly

 duplex auto

 speed auto

!

interface FastEthernet0/1

 ip address 192.168.2.1 255.255.255.0

 ip nat outside

 ip virtual-reassembly

 duplex auto

 speed auto

!

router ospf 1

 log-adjacency-changes

 network 192.168.1.2 0.0.0.0 area 0

 network 192.168.2.1 0.0.0.0 area 0

!

ip http server

no ip http secure-server

!

ip route 2.2.2.0 255.255.255.0 192.168.2.2

// from inside to outside : route before translate

!

ip nat inside source static 1.1.1.1 172.16.1.1

ip nat outside source static 3.3.3.3 2.2.2.2

!

Providing route for R1 and R3 to pass the traffic through R2 to translate

R1

ip route 2.2.2.2 255.255.255.255 192.168.1.2

R2

ip route 172.16.1.0 255.255.255.0 192.168.2.1

Verify Configuration

R1#ping 2.2.2.2 source 1.1.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 12/66/176 ms

R1#

R3#ping 172.16.1.1 source 3.3.3.3

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:

Packet sent with a source address of 3.3.3.3

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 24/71/144 ms

R3#

R2#show ip nat translations

Pro Inside global      Inside local       Outside local      Outside global

--- ---                ---                2.2.2.2            3.3.3.3

icmp 172.16.1.1:2      1.1.1.1:2          2.2.2.2:2          3.3.3.3:2

icmp 172.16.1.1:8      1.1.1.1:8          2.2.2.2:8          3.3.3.3:8

--- 172.16.1.1         1.1.1.1            ---                ---

R2#

R2 debug ip nat

Mar  1 00:32:18.007: NAT*: s=3.3.3.3->2.2.2.2, d=172.16.1.1 [41]

*Mar  1 00:32:18.007: NAT*: s=2.2.2.2, d=172.16.1.1->1.1.1.1 [41]

*Mar  1 00:32:18.035: NAT*: s=1.1.1.1->172.16.1.1, d=2.2.2.2 [42]

*Mar  1 00:32:18.035: NAT*: s=172.16.1.1, d=2.2.2.2->3.3.3.3 [42]

*Mar  1 00:32:18.051: NAT*: s=3.3.3.3->2.2.2.2, d=172.16.1.1 [42]

*Mar  1 00:32:18.051: NAT*: s=2.2.2.2, d=172.16.1.1->1.1.1.1 [42]

*Mar  1 00:32:18.063: NAT*: s=1.1.1.1->172.16.1.1, d=2.2.2.2 [43]

*Mar  1 00:32:18.063: NAT*: s=172.16.1.1, d=2.2.2.2->3.3.3.3 [43]

OSPF nssa

Not-so-stubby-area

OSPF nssa is the area that prohibits the LSA type 5 into the area but instead allow LSA type 7 to the area for the external routes.

There are options added on to the nssa area
 - area x nssa no-summary
     This area does not allow also the LSA type 3 or above into the area.
 - area x nssa no-redistribute
     This command is used in the the router that acts both ABR and ASBR. This command will not allow redistributed routes LSA type 7 into the nssa area but still allow the type 5 LSA in the OSPF process in area 0 ( backbone area )

Example for the NSSA no-redistribute

From the network diagram above, R2 is working as both ABR and ASBR. It redistributes the network 2.2.2.2/32 into the OSFP domian. However we do not want the router to advertise LSA type 7 in to the nssa area. but it is acceptable to have LSA type 5 in the OSPF domain. Here is the configuration on the R2.


interface Loopback0
 ip address 2.2.2.2 255.255.255.255

router ospf 1
 log-adjacency-changes
 area 1 nssa no-redistribution
 redistribute connected subnets
 network 192.168.1.2 0.0.0.0 area 0
 network 192.168.2.1 0.0.0.0 area 1

Looking at the R1 routing table, we can see the 2.2.2.2/32 network in it.

R1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     2.0.0.0/32 is subnetted, 1 subnets
O E2    2.2.2.2 [110/20] via 192.168.1.2, 00:21:56, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
O IA 192.168.2.0/24 [110/20] via 192.168.1.2, 00:34:03, FastEthernet0/0
O IA 192.168.3.0/24 [110/30] via 192.168.1.2, 00:27:32, FastEthernet0/0

However R4 doesn't see the 2.2.2.2/32 network in its database and its routing table.

R4#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2

       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

       ia - IS-IS inter area, * - candidate default, U - per-user static route

       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     4.0.0.0/32 is subnetted, 1 subnets

C       4.4.4.4 is directly connected, Loopback0

O IA 192.168.1.0/24 [110/30] via 192.168.3.1, 00:29:46, FastEthernet0/0

O    192.168.2.0/24 [110/20] via 192.168.3.1, 00:29:46, FastEthernet0/0

C    192.168.3.0/24 is directly connected, FastEthernet0/0

So this illustrate how the nssa no-redistribute works.

Auto QoS Discovery

Auto-Discovery


Started with the command:
(config-if)# auto discovery qos [trust]

Trust mode 


auto-discovery trusts the DSCP values in the IP header and uses it to classify packets, collect bandwidth statistics, calculate traffic average and traffic peak rate, then passes the data to the template module.

Untrust mode
auto-discovery uses NBAR to detect application on the network to collect data and perform statistical analysis.

To show the data that has been collected:
# show auto discovery qos [interface [interface type]]

DHCP manually binding

<copy from http://www.cisco.com/en/US/docs/ios/12_0t/12_0t1/feature/guide/Easyip2.html#wp23682>

 The IP address of a client can be assigned manually by an administrator or assigned automatically from a pool by a DHCP server.


Manual bindings are IP addresses that have been manually mapped to the MAC addresses of hosts that are found in the DHCP database. Manual bindings are stored in NVRAM on the DHCP server. Manual bindings are just special address pools. There is no limit on the number of manual bindings but you can only configure one manual binding per host pool.

To configure a manual binding, first create a host pool, then specify the IP address and hardware address of the client or client identifier. The hardware address is the MAC address. The client identifier, which is required for Microsoft clients (instead of hardware addresses), is formed by concatenating the media type and the MAC address of the client. Refer to the "Address Resolution Protocol Parameters" section of RFC 1700, Assigned Numbers, for a list of media type

Example Configuration



ip dhcp pool DHCP-TEST
   host 10.1.2.10 255.255.255.0
   hardware-address c204.07d0.0001 ieee802
   default-router 10.1.2.1
   dns-server 10.1.2.1
!
ip dhcp pool DHCP-TEST1
   host 10.1.2.11 255.255.255.0
   hardware-address 1111.1111.1111 ieee802
!

Verify Configuration


R3#sh ip dhcp binding
Bindings from all pools not associated with VRF:
IP address          Client-ID/              Lease expiration        Type
                    Hardware address/
                    User name
10.1.2.10           c204.07d0.0001          Infinite                Manual
10.1.2.11           1111.1111.1111          Infinite                Manual