Saturday, 22 August 2015

CCNA Training at your own place


Posted by at No comments:

Wednesday, 19 August 2015

Juniper NAT

The use of Network Address Translation (NAT) has been widespread for a number of years; this is because it is able to solve a number of problems with the same relatively simple configuration. At its most basic, NAT enables the ability to translate one set of addresses to another; this enables traffic coming from a specific host to appear as though it is coming from another and do it transparently. This article looks at some of the basic concepts that are used when configuring NAT and reviews the configuration steps required to get NAT working.
NAT Concepts
There are a number of different concepts that must be explained in order to really get a good understanding of how NAT operates, which ultimately makes the configuration of NAT increasingly simple. This section reviews these different concepts and begins with an understanding of how NAT can be used. Some of the main uses for NAT include:
  • Translation of non-unique addresses into unique addresses when accessing the Internet:
This is one of the most common uses of NAT today; almost every household that has a “router” to access the Internet is using NAT on this device to translate between internal private address and public Internet addresses.
  • Translation of addresses when transitioning internal addresses from one address range into another (this is common when the organization of addresses within a company is being changed):
This is often done when a company is transitioning their IP addressing plan; common scenarios include when expanding (and the IP addressing plan was not built sufficiently when the initial addresses were assigned) and when a company is merging with another with potential overlapping addresses.
  • When simple TCP load sharing is required across many IP hosts:
This is very common, as many highly used servers are not really a single machine but a bank of several machines that utilize load balancing. In this scenario, commonly, a single public address is translated into one of several internal addresses in a round robin fashion.
This is not a complete list of every possible way that NAT can be configured but simply a list of the most common ways that it is used in modern networks.
There are a couple of main concepts that also must be reviewed and understood before configuring NAT:
  • Inside and Outside Addresses
  • NAT types
Inside and Outside Addresses
In typical NAT configurations, interfaces are placed into one of two categories (or locations): inside or outside. Inside indicates traffic that is coming from within the organizational network. Outside indicates traffic that is coming from an external network that is outside the organizational network.
These different categories are then used to define different types of address depending on location of the address and how it is being “seen”. These different types include:
  • inside local address: This is the inside address as it is seen and used within the organizational network.
  • inside global address: This is the inside address as it is seen and used on the outside of the organizational network.
  • outside local address: This is the outside address as it seen and used within the organizational network.
  • outside global address: This is the outside address as it is seen and used on the outside of the organizational network.
NAT Types
Another important concept to be familiar with is the different types of NAT and how they are defined. On most networks there are three different types of NAT that are defined:
  • Static address translation (Static NAT): This type of NAT is used when a single inside address needs to be translated to a single outside address or vice versa.
  • Dynamic address translation (Dynamic NAT): This type of NAT is used when an inside address (or addresses) need to be translated to an outside pool of addresses or vice versa.
  • Overloading (Port Address Translation (PAT): This type of NAT is a variation on dynamic NAT. With dynamic NAT, there is always a one to one relationship between inside and outside addresses; if the outside address pool is ever exhausted, traffic from the next addresses requesting translation will be dropped. With overloading, instead of a one to one relationship, traffic is translated and given a specific outside port number to communicate with; in this situation, many internal hosts can be using the same outside address whil utilizing different port numbers.



NAT Configuration
There are few methods (and commands) that are used to configure NAT. The main three methods include one for static NAT, one for Dynamic NAT, and one for TCP load sharing.
Static NAT Configuration
There a few steps that are required when configuring static NAT; the number of the commands depends on whether there will be more than one static translation:
1
Enter global configuration mode.
router#configure terminal
2
Configure the static NAT translation (this command can be used multiple times depending on the number of static translations required). The overload keyword enables the use of PAT.
router(config)#ip nat inside source staticlocal-ip global-ip [overload]
3
Enter interface configuration mode for the inside interface.
router(config)#interface interface-id
4
Configure the interface as the inside NAT interface.
router(config-if)#ip nat inside
5
Enter interface configuration mode for the outside interface.
router(config-if)#interface interface-id
6
Configure the interface as the                  router(config-if)#ip nat outside
Outside NAT interface.                                                  
7
Exit configuration mode.                          router(config-if)#end













Static NAT Configuration Example
To ensure the configuration of static NAT is clear, let’s look at an example (Figure 1) that explains the concepts described above:
Figure 1
In this example, the inside host 192.168.1.20 will be translated to 172.16.1.5 when sending traffic out of interface f0/1.
Dynamic NAT Configuration
Dynamic NAT requires a few additional commands over a static configuration as the source of the traffic and the NAT address pool must be configured:






1
Enter global configuration mode.
router#configure terminal
2
Configure the dynamic NAT address pool.
router(config)#ip nat pool pool-name start-ip end-ip {netmask netmask | prefix-length prefix-length}
3
Configure a static access list to define the addresses to be translated.
router(config)#access-list access-list-number permit source [source-wildcard]
4
Configure the dynamic NAT translation. The overload keyword enables the use of PAT.
router(config)#ip nat inside source listaccess-list-number pool pool-name[overload]
5
Enter interface configuration mode for the inside interface.
router(config)#interface interface-id
6
Configure the interface as the inside NAT interface.
router(config-if)#ip nat inside
7
Enter interface configuration mode for the outside interface.
router(config-if)#interface interface-id
8
Configure the interface as the outside NAT interface.
router(config-if)#ip nat outside
9
Exit configuration mode.
router(config-if)#end

Dynamic NAT Configuration Example
To ensure the configuration of dynamic NAT is clear, let’s look at an example (Figure 2) that explains the concepts described above:
http://ptgmedia.pearsoncmg.com/images/art_wilkins_basicnatconcepts/elementLinks/fig2_wilkins_basic-nat-concepts.jpg
Figure 2
In this example, the hosts that have addresses from 192.168.1.1 through 192.168.1.254 will be translated to an address from the pool which includes addresses from 172.16.1.10 through 172.16.1.20; if a 12th host attempts to send traffic out of the f0/1 interface, the translation will fail.


TCP Load Balancing Configuration
The TCP load balancing feature enables the ability to assign a single outside address that is translated into one of a pool of addresses in order to balance the load of traffic over a number of different hosts. The following commands are used to configure TCP load balancing:





1
Enter global configuration mode.
router#configure terminal
2
Configure the NAT address pool that contains the list of real host IP addresses to load balance to.
router(config)#ip nat pool pool-name start-ip end-ip {netmask netmask | prefix-length prefix-length} type rotary
3
Configure a static access list to define the virtual address that will be used for outside communication.
router(config)#access-list access-list-number permit source [source-wildcard]
4
Configure TCP server load balancing.
router(config)#ip nat inside destination-list access-list-number pool pool-name
5
Enter interface configuration mode for the inside interface.
router(config)#interface interface-id
6
Configure the interface as the inside NAT interface.
router(config-if)#ip nat inside
7
Enter interface configuration mode for the outside interface.
router(config-if)#interface interface-id
8
Configure the interface as the outside NAT interface.
router(config-if)#ip nat outside
9
Exit configuration mode.
router(config-if)#end

TCP Load Balancing Configuration Example
To ensure the configuration of TCP load balancing is clear, let’s look at an example (Figure 3) that explains the concepts described above:

 In this example, all traffic that is addressed to 192.168.1.5 will be translated and sent to the hosts with addresses from 192.168.1.10 through 192.168.1.20 in a round robin fashion.
Summary

There are certainly many different situations where the functionality of NAT can be used. This article takes a look at some of the ways that NAT can be configured and offers examples of how the functionality can be implemented. Hopefully this article has made the concepts and configuration of NAT a little simpler to understand so that they can be implemented with little trouble or confusion.
Posted by at No comments:

How to Configure SRX Security Zones with Junos

You cannot manage the SRX Services Gateway as you would a router. The SRX is a locked-down device. You can’t even ping an interface on the SRX initially, even if it has a valid IP address. The SRX uses the concept of nested security zones. Zones are a critical concept in SRX configuration. No traffic goes in or out unless the security zones are configured properly on the SRX interfaces.
To configure a security zone, you need to associate the interface with a security zone, and then the security zones need to be bound with a routing instance (if there are multiple routing instances).
It sounds complicated, but it’s not. First, you configure the zones and then you associate the interfaces with the zones. Here, we're assuming that you’re using only one routing instance. You can configure a zone with more than one interface. However, each interface can belong to only one zone.
Now, establish two security zones for a simple SRX configuration. One zone is for a local LAN called admins (administration) on interface ge-0/0/0.0, and the other zone is for two links to the Internet called untrust with interfacesge-0/0/1.0 and ge-0/0/2.0:
root# edit security zones
[edit security zones]
root# set security zone admins
root# set security zone untrust
root# set security zone admins interfaces ge-0/0/0.0
root# set security zone untrust interfaces ge-0/0/1.0
root# set security zone untrust interfaces ge-0/0/2.0
Always configure zones from the perspective of the SRX you are configuring. Many other zones may be on the LAN (trust,accounting, and so on). But this SRX only links to admins anduntrust.
Now you can add services to the zones you just configured. Assume that inbound ssh, ftp, and ping traffic is permitted from the untrusted zone.
This is just an example. Before you enable any services at all on your SRX, make sure you truly need them. FTP in particular is often considered risky because FTP has no real security, and you just punched a big hole for it in your security zone.
[edit security zones]
root# set security zone untrust host-inbound-traffic ssh
root# set security zone untrust host-inbound-traffic ftp
root# set security zone untrust host-inbound-traffic ping
Your configuration now looks like this:
[edit security]
zones {
  security-zone untrust {
   host-inbound-traffic {
     system-services {
      ssh;
      ftp;
      ping;
     }
   }  
   interfaces {
     ge-0/0/1.0;
     ge-0/0/2.0;
   }
  }
  security-zone admins {
   interfaces {
     ge-0/0/0.0;
     }
   }

If you haven’t yet configured routing and applied licensing to your SRX, you will get a fetch error message when you try and commit the security configuration. This error will go away when configuration is complete.
Posted by at No comments:

Configuring External BGP Point-to-Point Peer Sessions

This example shows how to configure BGP point-to-point peer sessions.
·         Requirements
·         Overview
·         Configuration
·         Verification
Requirements
Before you begin, if the default BGP policy is not adequate for your network, configure routing policies to filter incoming BGP routes and to advertise BGP routes.
Overview
Figure 1 shows a network with BGP peer sessions. In the sample network, Device E in AS 17 has BGP peer sessions to a group of peers called external-peers. Peers A, B, and C reside in AS 22 and have IP addresses 10.10.10.2, 10.10.10.6, and 10.10.10.10. Peer D resides in AS 79, at IP address 10.21.7.2. This example shows the configuration on Device E.
Figure 1: Typical Network with BGP Peer Sessions
Typical Network with BGP Peer Sessions
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
set interfaces ge-1/2/0 unit 0 description to-Aset interfaces ge-1/2/0 unit 0 family inet address 10.10.10.1/30set interfaces ge-0/0/1 unit 5 description to-Bset interfaces ge-0/0/1 unit 5 family inet address 10.10.10.5/30set interfaces ge-0/1/0 unit 9 description to-Cset interfaces ge-0/1/0 unit 9 family inet address 10.10.10.9/30set interfaces ge-1/2/1 unit 21 description to-Dset interfaces ge-1/2/1 unit 21 family inet address 10.21.7.1/30set protocols bgp group external-peers type externalset protocols bgp group external-peers peer-as 22set protocols bgp group external-peers neighbor 10.10.10.2set protocols bgp group external-peers neighbor 10.10.10.6set protocols bgp group external-peers neighbor 10.10.10.10set protocols bgp group external-peers neighbor 10.21.7.2 peer-as 79set routing-options autonomous-system 17
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure the BGP peer sessions:
1.        Configure the interfaces to Peers A, B, C, and D.
[edit interfaces]user@E# set ge-1/2/0 unit 0 description to-Auser@E# set ge-1/2/0 unit 0 family inet address 10.10.10.1/30user@E# set ge-0/0/1 unit 5 description to-Buser@E# set ge-0/0/1 unit 5 family inet address 10.10.10.5/30user@E# set ge-0/1/0 unit 9 description to-Cuser@E# set ge-0/1/0 unit 9 family inet address 10.10.10.9/30user@E# set ge-1/2/1 unit 21 description to-Duser@E# set ge-1/2/1 unit 21 family inet address 10.21.7.1/30
2.        Set the autonomous system (AS) number.
[edit routing-options]user@E# set autonomous-system 17
3.        Create the BGP group, and add the external neighbor addresses.
[edit protocols bgp group external-peers]user@E# set neighbor 10.10.10.2user@E# set neighbor 10.10.10.6user@E# set neighbor 10.10.10.10
4.        Specify the autonomous system (AS) number of the external AS.
[edit protocols bgp group external-peers]user@E# set peer-as 22
5.        Add Peer D, and set the AS number at the individual neighbor level.
The neighbor configuration overrides the group configuration. So, while peer-as 22 is set for all the other neighbors in the group, peer-as 79 is set for neighbor 10.21.7.2.
[edit protocols bgp group external-peers]user@E# set neighbor 10.21.7.2 peer-as 79
6.        Set the peer type to external BGP (EBGP).
[edit protocols bgp group external-peers]user@E# set type external
Results
From configuration mode, confirm your configuration by entering the show interfaces, show protocols, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit]user@E# show interfaces
ge-1/2/0 {unit 0 {description to-A;family inet {address 10.10.10.1/30;}}}
ge-0/0/1 {unit 5 {description to-B;family inet {address 10.10.10.5/30;}}}
ge-0/1/0 {unit 9 {description to-C;family inet {address 10.10.10.9/30;}}}
ge-1/2/1 {unit 21 {description to-D;family inet {address 10.21.7.1/30;}}}
[edit]user@E# show protocols
bgp {group external-peers {type external;peer-as 22;neighbor 10.10.10.2;neighbor 10.10.10.6;neighbor 10.10.10.10;neighbor 10.21.7.2 {peer-as 79;}}}
[edit]user@E# show routing-optionsautonomous-system 17;
If you are done configuring the device, enter commit from configuration mode.
Verification
Confirm that the configuration is working properly.
Verifying BGP Neighbors
Purpose
Verify that BGP is running on configured interfaces and that the BGP session is active for each neighbor address.
Action
From operational mode, run the show bgp neighbor command.
user@E> show bgp neighbor
Peer: 10.10.10.2+179 AS 22     Local: 10.10.10.1+65406 AS 17  
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference PeerAS Refresh>
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 10.10.10.2       Local ID: 10.10.10.1       Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 0  
  BFD: disabled, down
  Local Interface: ge-1/2/0.0                      
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 22)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 10   Sent 6    Checked 1  
  Input messages:  Total 8522   Updates 1       Refreshes 0     Octets 161922
  Output messages: Total 8433   Updates 0       Refreshes 0     Octets 160290
  Output Queue[0]: 0

Peer: 10.10.10.6+54781 AS 22   Local: 10.10.10.5+179 AS 17  
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference PeerAS Refresh>
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 10.10.10.6       Local ID: 10.10.10.1       Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 1  
  BFD: disabled, down                  
  Local Interface: ge-0/0/1.5                      
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 22)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 12   Sent 6    Checked 33 
  Input messages:  Total 8527   Updates 1       Refreshes 0     Octets 162057
  Output messages: Total 8430   Updates 0       Refreshes 0     Octets 160233
  Output Queue[0]: 0

Peer: 10.10.10.10+55012 AS 22  Local: 10.10.10.9+179 AS 17  
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference PeerAS Refresh>
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 10.10.10.10      Local ID: 10.10.10.1       Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 2  
  BFD: disabled, down
  Local Interface: fe-0/1/0.9                      
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 22)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 15   Sent 6    Checked 37 
  Input messages:  Total 8527   Updates 1       Refreshes 0     Octets 162057
  Output messages: Total 8429   Updates 0       Refreshes 0     Octets 160214
  Output Queue[0]: 0

Peer: 10.21.7.2+61867 AS 79    Local: 10.21.7.1+179 AS 17  
  Type: External    State: Established    Flags: <ImportEval Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference PeerAS Refresh>
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 10.21.7.2        Local ID: 10.10.10.1       Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 3  
  BFD: disabled, down
  Local Interface: ge-1/2/1.21                     
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 79)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0    
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 28   Sent 24   Checked 47 
  Input messages:  Total 8521   Updates 1       Refreshes 0     Octets 161943
  Output messages: Total 8427   Updates 0       Refreshes 0     Octets 160176
  Output Queue[0]: 0
Verifying BGP Groups
Purpose
Verify that the BGP groups are configured correctly.
Action
From operational mode, run the show bgp group command.
user@E> show bgp group
Group Type: External                               Local AS: 17
  Name: external-peers  Index: 0                   Flags: <>
  Holdtime: 0
  Total peers: 4        Established: 4
  10.10.10.2+179
  10.10.10.6+54781
  10.10.10.10+55012
  10.21.7.2+61867
  inet.0: 0/0/0/0

Groups: 1  Peers: 4    External: 4    Internal: 0    Down peers: 0   Flaps: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 0          0          0          0          0          0
Verifying BGP Summary Information
Purpose
Verify that the BGP configuration is correct.
Action
From operational mode, run the show bgp summary command.
user@E> show bgp summary
Groups: 1 Peers: 4 Down peers: 0
Table          Tot Paths  Act Paths Suppressed    History Damp State    Pending
inet.0                 0          0          0          0          0          0
Peer                     AS      InPkt     OutPkt    OutQ   Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
10.10.10.2               22       8559       8470       0       0 2d 16:12:56 0/0/0/0              0/0/0/0
10.10.10.6               22       8566       8468       0       0 2d 16:12:12 0/0/0/0              0/0/0/0
10.10.10.10              22       8565       8466       0       0 2d 16:11:31 0/0/0/0              0/0/0/0
10.21.7.2                79       8560       8465       0       0 2d 16:10:58 0/0/0/0 
Posted by at No comments:
Subscribe to: Posts (Atom)