Pete's Packet

Limitless

  • Catagories

  • Global visitors

    free counters
  • RSS CCIE Jobs – Metro NY area

Archive for the ‘IP Services’ Category

Nat notes from the doc cd

Posted by Peter Kurdziel on May 29, 2009

Determine how you will use NAT and how NAT will need to be configured.

1. Define NAT inside and outside interfaces by answering the following questions:

– Do users exist off multiple interfaces?

–Are there multiple interfaces going to the Internet?

2. Define what is trying to be accomplished with NAT by answering the following questions:

–Should NAT allow internal users to access the Internet?

–Should NAT allow the Internet to access internal devices such as a mail server?

–Should NAT redirect TCP traffic to another TCP port or address?

–Will NAT be used during a network transition?

–Should NAT allow overlapping networks to communicate?

–Should NAT allow networks with different address schemes to communicate?

–Should NAT allow the use of an application level gateway?

If you specify an access list to use with a NAT command, NAT does not support the commonly used permit ip any any command in the access list.

In a typical environment, NAT is configured at the exit router between a stub domain and backbone

NAT uses the following definitions:

Inside local address—The IP address that is assigned to a host on the inside network. The address is probably not a legitimate IP address assigned by the Network Information Center (NIC) or service provider.

Inside global address—A legitimate IP address (assigned by the NIC or service provider) that represents one or more inside local IP addresses to the outside world.

Outside local address—The IP address of an outside host as it appears to the inside network. Not necessarily a legitimate address, it was allocated from address space routable on the inside.

Outside global address—The IP address assigned to a host on the outside network by the owner of the host. The address was allocated from a globally routable address or network space.

NAT types include:

•Static Address Translation—Static NAT—allows one-to-one mapping between local and global addresses.

•Dynamic Address Translation—Dynamic NAT—maps unregistered IP addresses to registered IP addresses of out of a pool of registered IP addresses.

•Overloading—a form of dynamic NAT that maps multiple unregistered IP addresses to a single registered IP address (many to one) using different ports. This method is also known as Port Address Translation (PAT). By using PAT (NAT Overload), thousands of users can be connected to the Internet using only one real global IP address.

Inside Source Address Translation

  1. ip nat inside source static local-ip global-ip
  2. interface type number
  3. ip address ip-address mask [secondary]
  4. inside & outside nat interfaces

Configuring Dynamic Translation of Inside Source Addresses

  1. ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-length}
  2. access-list access-list-number permit source [source-wildcard]
  3. ip nat inside source list access-list-number pool name
  4. inside & outside nat interfaces

Allowing Internal Users Access to the Internet Using NAT

Inside Global Addresses Overloading

  1. ip nat pool name start-ip end-ip {netmask netmask| prefix-length prefix-length}
  2. access-list access-list-number permit source [source-wildcard]
  3. ip nat inside source list access-list-number pool name overload
  4. inside & outside nat interfaces

Posted in IP Services, NAT, Routing & Switching Lab | Leave a Comment »

Enabling Syslog for Logging NAT Translations

Posted by Peter Kurdziel on May 28, 2009

Enabling Syslog for Logging NAT Translations

SUMMARY STEPS
1. enable

2. configure terminal

3. ip nat log translations syslog

4. no logging console

Posted in IP Services, NAT, Routing & Switching Lab | 2 Comments »

VRF example – 6 hosts with the same IP address

Posted by Peter Kurdziel on February 25, 2009

connect-to-same-ip1
Solution =VRF/NAT

!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname NAT-TEST-ROUTER
!
boot-start-marker
boot-end-marker
!
logging buffered 51200 warnings
!
no aaa new-model
!
resource policy
!
!
!
ip cef
!
!
ip vrf VRF1
rd 1:1
route-target export 1:1
route-target import 1:1
route-target import 10:10
!
ip vrf VRF10
rd 10:10
route-target export 10:10
route-target import 10:10
route-target import 1:1
route-target import 2:2
route-target import 3:3
route-target import 4:4
route-target import 5:5
route-target import 6:6
!
ip vrf VRF2
rd 2:2
route-target export 2:2
route-target import 2:2
route-target import 10:10
!
ip vrf VRF3
rd 3:3
route-target export 3:3
route-target import 3:3
route-target import 10:10
!
ip vrf VRF4
rd 4:4
route-target export 4:4
route-target import 4:4
route-target import 10:10
!
ip vrf VRF5
rd 5:5
route-target export 5:5
route-target import 5:5
route-target import 10:10
!
ip vrf VRF6
rd 6:6
route-target export 6:6
route-target import 6:6
route-target import 10:10
!
ip vrf forwarding
!
no ip domain lookup
ip domain name chisa.com
!
!
crypto pki trustpoint TP-self-signed-2960199964
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-2960199964
revocation-check none
rsakeypair TP-self-signed-2960199964
!
!
crypto pki certificate chain TP-self-signed-2960199964
certificate self-signed 01
30820253 308201BC A0030201 02020101 300D0609 2A864886 F70D0101 04050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 32393630 31393939 3634301E 170D3039 30323034 31343439
30375A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D32 39363031
39393936 3430819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
8100C57A 835DB165 EB23A94E 6704CC51 B87A796C D2643BE4 83B2B162 7657F83A
EA44CC69 18DA39DA 195AFE6E 956BE381 DCA8C6EB 8B9CDDBD DF47B116 9483B8E3
705E44CB CA42373E 5412E437 46ABB4E1 87D9697A EF00DD36 17790D96 52B6E1BE
8C17122C B40A5305 319B31CA BA6AAD31 4AA11740 C7D8E7EE 5EF9C522 8F1497E2
C8250203 010001A3 7B307930 0F060355 1D130101 FF040530 030101FF 30260603
551D1104 1F301D82 1B434849 53412D52 4F555445 522E796F 7572646F 6D61696E
2E636F6D 301F0603 551D2304 18301680 140C6267 13F34BBB CFDF83D5 CCAB421E
EC723A56 0A301D06 03551D0E 04160414 0C626713 F34BBBCF DF83D5CC AB421EEC
723A560A 300D0609 2A864886 F70D0101 04050003 81810006 92D997B2 895060AD
FDBC3A73 87E2F775 F65DB489 F4F0CD7A 0FFF2AA3 FF8BAA04 FC9A694E F00037CD
ED920B27 AA72B01C 5FD27A45 B3433A45 AADC70CB 57AA2C5D 525FD44D 48AB5950
FEED164A F4686EB8 F1349CFD BE0BD959 979A9554 ED64A068 D9C18D3A 36740378
6ED96248 5DE4170F 330EFE2D 72D2A4E5 4425AACE 9253EE
quit
username cisco privilege 15 secret 5 $1$PLG6$Qhx0p8TuAy0.g.94LFvc2.
!
!
!
!
!
!
interface Loopback1
ip vrf forwarding VRF1
ip address 172.30.1.10 255.255.255.0
!
interface Loopback2
ip vrf forwarding VRF2
ip address 172.30.2.10 255.255.255.0
!
interface Loopback3
ip vrf forwarding VRF3
ip address 172.30.3.10 255.255.255.0
!
interface Loopback4
ip vrf forwarding VRF4
ip address 172.30.4.10 255.255.255.0
!
interface Loopback5
ip vrf forwarding VRF5
ip address 172.30.5.10 255.255.255.0
!
interface Loopback6
ip vrf forwarding VRF6
ip address 172.30.6.10 255.255.255.0
!
interface Loopback10
ip address 172.30.100.10 255.255.255.255
!
interface FastEthernet0
no ip address
duplex auto
speed auto
!
interface FastEthernet1
ip vrf forwarding VRF10
ip address 172.30.100.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet2
shutdown
!
interface FastEthernet3
switchport access vlan 16
spanning-tree portfast
!
interface FastEthernet4
switchport access vlan 15
spanning-tree portfast
!
interface FastEthernet5
switchport access vlan 14
spanning-tree portfast
!
interface FastEthernet6
shutdown
!
interface FastEthernet7
switchport access vlan 13
spanning-tree portfast
!
interface FastEthernet8
switchport access vlan 12
spanning-tree portfast
!
interface FastEthernet9
switchport access vlan 11
spanning-tree portfast
!
interface Vlan1
no ip address
shutdown
!
interface Vlan11
ip vrf forwarding VRF1
ip address 192.168.1.11 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Vlan12
ip vrf forwarding VRF2
ip address 192.168.1.12 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Vlan13
ip vrf forwarding VRF3
ip address 192.168.1.13 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Vlan14
ip vrf forwarding VRF4
ip address 192.168.1.14 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Vlan15
ip vrf forwarding VRF5
ip address 192.168.1.15 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Vlan16
ip vrf forwarding VRF6
ip address 192.168.1.16 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Async1
no ip address
encapsulation slip
shutdown
!
router bgp 1
no synchronization
bgp router-id 172.30.100.10
bgp log-neighbor-changes
no auto-summary
!
address-family ipv4 vrf VRF6
no synchronization
network 172.30.6.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 vrf VRF5
no synchronization
network 172.30.5.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 vrf VRF4
no synchronization
network 172.30.4.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 vrf VRF3
no synchronization
network 172.30.3.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 vrf VRF2
no synchronization
network 172.30.2.0 mask 255.255.255.0
exit-address-family
!
address-family ipv4 vrf VRF10
redistribute connected
no synchronization
exit-address-family
!
address-family ipv4 vrf VRF1
no synchronization
network 172.30.1.0 mask 255.255.255.0
exit-address-family
!
!
!
no ip http server
ip http access-class 23
ip http authentication local
no ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
ip nat inside source static 192.168.1.1 172.30.1.1 vrf VRF1
ip nat inside source static 192.168.1.1 172.30.2.1 vrf VRF2
ip nat inside source static 192.168.1.1 172.30.3.1 vrf VRF3
ip nat inside source static 192.168.1.1 172.30.4.1 vrf VRF4
ip nat inside source static 192.168.1.1 172.30.5.1 vrf VRF5
ip nat inside source static 192.168.1.1 172.30.6.1 vrf VRF6
!
!
!
!
!
!
!
control-plane
!

———————————————————————–
^C
!
line con 0
login local
line 1
modem InOut
stopbits 1
speed 115200
flowcontrol hardware
line aux 0
line vty 0 4
access-class 23 in
privilege level 15
login local
transport input telnet ssh
line vty 5 15
access-class 23 in
privilege level 15
login local
transport input telnet ssh
!
!
webvpn context Default_context
ssl authenticate verify all
!
no inservice
!
end

Posted in IP Services | Leave a Comment »

Using Extended Access-Lists In A Distribute-List

Posted by Peter Kurdziel on December 10, 2008

- Using distribute-list with extended ACL is a bit tricky, as different
routing protocols may interpret the exended ACL in different ways. This use is
very poorly docummented in DOC CD. Maybe, because this use is a legacy one,
and not recommended anymore.

There’s a good blog entry by Brian M. (from IE) on this topic at the following
URL:

http://blog.internetworkexpert.com/2008/01/04/using-extended-access-lists-in-
a-distribute-list/

Using Extended Access-Lists In A Distribute-List

Hi Brian,

I’m trying to create a distribute-list in RIP to allow only even routes to be received. I can do it successfully with a standard ACL, however if I use an extended ACL I can’t get any routes at all. I’ve heard that extended ACLs are better because they also check the netmask. What am I doing wrong?

Using an extended access-list with a distribute-list is supported, however the syntax can be a little confusing because it means different things for different applications. When using an extended ACL for a distribute-list in BGP it acts like a prefix-list. This means that you can match on both the address of the prefix and the subnet mask. In other words if you have prefixes 10.0.0.0/8 and 10.0.0.0/16 you can distinguish between them by saying not only must the address be 10.0.0.0 but the subnet mask must be /8. In prefix-list syntax this is very straightforward, as to match this prefix we would use the following:

ip prefix-list PREFIX1 permit 10.0.0.0/8

When using an extended access-list in BGP the syntax of the list changes in that we are not matching source and destination pairs, but instead are matching the address and netmask. In extended ACL syntax the above prefix-list would read:

access-list 100 permit ip host 10.0.0.0 host 255.0.0.0

This means that the address must be exactly 10.0.0.0 and the subnet mask must be exactly 255.0.0.0. By changing the “host” keyword to a wildcard mask we can do fuzzy binary matches. For example the following syntax means check any address that starts with “192.168” and has a subnet mask of /24:

access-list 101 permit ip 192.168.0.0 0.0.255.255 host 255.255.255.0

In other words this list matches 192.168.0.0/24, 192.168.100.0/24, 192.168.200.0/24, etc.

This extended access-list syntax can also be used in a route-map for redistribution filtering in both IGP and BGP. For example if we took the previous access-list 101 and matched it in a route-map as follows:

route-map OSPF_TO_RIP permit 10
 match ip address 100
!
router rip
 redistribute ospf 1 metric 1 route-map OSPF_TO_RIP

This syntax would say that we want to redistribute OSPF routes into RIP, but only those which are 192.168.X.X/24.

The confusion for this extended access-list implementation is that when it is called as a distribute-list in IGP the syntax changes. In the previous examples the normal “source” field in the ACL represents the network address, where the “destination” field represents the subnet mask. In IGP distribute-list application the “source” field in the ACL matches the update source of the route, and the “destination” field represents the network address. This implementation allows us to control which networks we are receiving, but more importantly who we are receiving them from. Take the following topology:

R1, R2, and R3 share an Ethernet network 123.0.0.0/8 that is running RIP. Both R1 and R2 are advertising the identical prefixes 10.0.0.0/8 and 20.0.0.0/8 to R3. Their configurations are as follows:

R1#show ip int brief | exclude unassigned

Interface                  IP-Address      OK? Method Status Protocol
FastEthernet0/0            123.0.0.1       YES manual up     up
Loopback0                  10.0.0.1        YES manual up     up
Loopback1                  20.0.0.2        YES manual up     up

R1#show run | begin router rip
router rip
 version 2
 network 10.0.0.0
 network 20.0.0.0
 network 123.0.0.0

R2# show ip int brief | exclude unassigned

Interface                  IP-Address      OK? Method Status Protocol
FastEthernet0/0            123.0.0.2       YES manual up     up
Loopback0                  10.0.0.1        YES manual up     up
Loopback1                  20.0.0.2        YES manual up     up

R2#sh run | begin router rip
router rip
 version 2
 network 10.0.0.0
 network 20.0.0.0
 network 123.0.0.0

R3#show ip route rip
R    20.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
                [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0
R    10.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
                [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0

From this output we can see that R3 has the two prefixes installed twice, once from R1 and once from R2. Now let’s suppose that prefix 10.0.0.0/8 we only want to receive from R1, while prefix 20.0.0.0/8 we only want to receive from R2. We can accomplish this with an extended access-list as follows:

R3#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

R3(config)#access-list 100 permit ip host 123.0.0.1 host 10.0.0.0
R3(config)#access-list 100 permit ip host 123.0.0.2 host 20.0.0.0
R3(config)#router rip
R3(config-router)#distribute-list 100 in Ethernet0/0
R3(config-router)#end
R3#clear ip route *
R3#show ip route rip
R    20.0.0.0/8 [120/1] via 123.0.0.2, 00:00:00, Ethernet0/0
R    10.0.0.0/8 [120/1] via 123.0.0.1, 00:00:00, Ethernet0/0

We can see now R3 only has one entry for each prefix, with the 10.0.0.0/8 coming only from R1 and the 20.0.0.0/8 coming only from R2. The disadvantage of this application however is that we cannot distinguish prefixes based on their netmask. For example we could not say that we want to receive prefix 172.16.0.0/16 from only R1 and prefix 172.16.0.0/24 only from R2. For this implementation in IGP we would use a prefix-list that is called from a distribute-list with the “distribute-list prefix” syntax under the routing process.

Reference: http://blog.internetworkexpert.com/2008/01/04/using-extended-access-lists-in-a-distribute-list/

Posted in IP Services | Leave a Comment »

 
Follow

Get every new post delivered to your Inbox.