My CISCO Journal

Home » Posts filed under CCNA

Showing posts with label CCNA. Show all posts

CCNA- How to configure Cisco IOS Banners

Posted by Unknown Saturday, June 15, 2013 0 comments

Cisco IOS devices support a number of banners that are presented to users when they use the console line or when they connect remotely using telnet or SSH. They are often used to inform users about their legal rights. It might be a good idea to present a banner to users who are trying to connect to your device, here are some items you might want to think about:

To show that only authorized users are allowed to connect.
That all traffic will be monitored.
That there is no expectation of privacy.
Don’t use anything that says “welcome”.
Don’t add any contact information or information about the router in the banner.

here’s a good example on the website of the California Technology Agency that gives you more information about what a good banner should contain and some sample texts. Before you implement any banners, make sure to check your legal council first. Having said that, let’s look at the different banners…

Different Banners

Cisco IOS routers support a number of banners, here they are:

MOTD banner: the “message of the day” banner is presented to everyone that connects to the router.
Login banner: this one is displayed just before the authentication prompt.
Exec banner: displayed before the user sees the exec prompt.
Incoming banner: used for users that connect through reverse telnet.

We’ll take a look at how to configure these different banners now.

MOTD Banner

We’ll start with the message of the day banner that will be presented to anyone accessing the router:

R1(config)#banner motd #
Enter TEXT message.  End with the character '#'.
Authorized users only, violaters will be shot on sight! #

The # symbol is a start and stop character. You can use any other character if you want. This is what the MOTD banner looks like:

R1#exit

R1 con0 is now available

Press RETURN to get started.

Authorized users only, violaters will be shot on sight!

A nice and welcome banner that everyone will see…let’s move on to the login banner now.

Login banner

The login banner is presented to users that access the router remotely using telnet or SSH:

R1(config)#banner login $ Authenticate yourself! $

Let’s try it out:

R1#telnet 1.1.1.1
Trying 1.1.1.1 ... Open

Authorized users only, violaters will be shot on sight!  Authenticate yourself!

Above you see that the login banner is displayed after the MOTD banner. It would have been better if I added some empty lines so that the login banner would show up below the MOTD banner.

Exec banner

The exec banner is shown just before the exec prompt:

R1(config)#banner exec #
Enter TEXT message.  End with the character '#'.
You are connected to line $(line) at router $(hostname)
#

This time I added an extra line in the banner and I also used some operators like $(line) and $(hostname). Let’s see what that looks like:

R1#exit

R1 con0 is now available

Press RETURN to get started.

Authorized users only, violaters will be shot on sight!
You are connected to line 0 at router R1

As you can see it shows to which line I am connected (line 0 is the console) and the hostname of my router (R1). One more banner to go!

Banner incoming

The last banner is used for reverse telnet connections. Reverse telnet can be used to access the console of another device by connecting the AUX port of the router to the console port of another router. This allows you to ‘telnet’ into the console port of another router.

R1(config)#banner incoming $
Enter TEXT message.  End with the character '$'.
This is a banner for Reverse Telnet
$

We’ll have to configure the AUX port in order to test it:

R1(config)#line aux 0
R1(config-line)#transport input telnet

We will enable telnet on the aux port, now we’ll have to check what line our AUX port uses:

R1#show line 
*Mar  1 01:48:09.495: %SYS-5-CONFIG_I: Configured from console by console
R1#show line 
   Tty Typ     Tx/Rx    A Modem  Roty AccO AccI   Uses   Noise  Overruns   Int
*     0 CTY              -    -      -    -    -      2       1     0/0       -
     97 AUX   9600/9600  -    -      -    -    -      0       0     0/0       -
     98 VTY              -    -      -    -    -      2       0     0/0       -
     99 VTY              -    -      -    -    -      0       0     0/0       -
    100 VTY              -    -      -    -    -      0       0     0/0       -
    101 VTY              -    -      -    -    -      0       0     0/0       -
    102 VTY              -    -      -    -    -      0       0     0/0       -

Now we can reverse telnet to the AUX port like this:

R1#telnet 1.1.1.1 6097
Trying 1.1.1.1, 6097 ... Open

Authorized users only, violaters will be shot on sight! 
This is a banner for Reverse Telnet

As you can see it presents us the “incoming banner”. I hope this has been helpful to you to understand the banners!

This great, post has been taken from Rene Molenaar website. Please visit and do support his awesome and brilliant website: http://networklessons.com/network-management/how-to-configure-cisco-ios-banners/

CCNA- VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 2

Posted by Unknown Saturday, June 8, 2013 0 comments

VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 2:

Taking after are the parameters needed for the VTP gadgets to impart:

1-VTP Domain name

2-VTP Password: VTP uphold confirmation utilizing passed which is hashed as MD5 and utilized within VTP commercials over the system.

It would be ideal if you note that the Domain name and Password must match on the VTP empowered switches or VTP should not work giving Domain & Password jumble mistakes.

Alright at long last we are finished with the hypothesis. So how about we begin with our best, “The Configurations”.

VTP Configuration – The Fun Part

In this arrangement we are sure to utilize 4 switches with SWITCH-1 as the VTP server while the alternate 3 will serve as VTP clients. So we should begin then;

In the wake of joining the switches we need to prepare trunk mode on the switch nearby ports on account of it is essential for the traversal of VLAN traffic.

SWITCH-1(config)#inter fa 0/1

SWITCH-1(config-if)#switchport trunk encapsulation do

SWITCH-1(config-if)#switchport trunk encapsulation dot1q

SWITCH-1(config-if)#switchport mode trunk

Note: It is not needed to run the command to initiate the trunk on the alternate close of the connection for as much as it is auto initiated when prepared toward one side.

Not with standing actuate trunk on the greater part of the switches for VLAN movement stream with the above given command. In the wake of empowering trunk mode, we will arrange VTP-Server mode on SWITCH-1 and VTP-Client mode on the remaining switches.

Since the default VTP mode on the switches is ‘Server’, we don’t need to update any of the above SWITCH-1 for server mode:

SWITCH-1#show vtp status

The above command will display different VTP parameter status, whether they are enabled or not.

Now, we will enable client mode on the other switches and will move on to configure VTP Domain name, password and version.

And we will issue the above mentioned show vtp status command to check whether our switch has been configured as client switch or not.

Repeat the steps for all switches and enable VTP client mode of the switches. Now let’s make some change on the VTP server and check the results on the client.

Now let’s check the VLAN and VTP status on the VTP-clients and feel the magic:

This is all that you need to accomplish for VTP on our switches. Straightforward right? So attempt it and have a great time. Just keep one thing in mind , never try to plug any switch in your office cubicle to your live network, before knowing the complete detail about your network as this enthusiasm can cost you a lot. One other thing we must keep in mind, never to plug any switch from our corporate lab into our live network, as mostly we do different sort of experiments on these switches and if anyone of them have higher revision number and same domain unluckily then you will have to spend the whole weekend in office troubleshooting the network! So we have covered one of the major concept related to switching technologies, we will keep our journey on, will stay foolish and stay hungry.

CCNA- VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 1

Posted by Unknown Thursday, June 6, 2013 0 comments

VTP is an absolutely fascinating thought however meanwhile quite hazardous if not took care of with delicacy. I know you may be suspecting WHY? For your response and to perceive the notion wouldn't it be great if we could start then and I welcome you to the universe of VTP.

VTP in true is an update methodology. It gives an intend to make VLANs on associated switches as an assembly and it is particularly supportive in hefty organizes. Assuming that VTP is empowered on the sum of your Cisco switches, the production of another VLAN on one switch makes that VLAN ready on all switches with the same VTP administration area. Befuddled? Well don’t be.

Give me a chance to illustrate in straight forward statements, case in point, you have a huge system with different switches with VLANs, supporting diverse clients and suddenly you are asked to include more accommodates in the system on another switch(s) on numerous VLANs, With the augmentation of another switch(s) you need to arrange the sum of the VLANs again and trust me this is sure to require some serious energy. Anyhow don’t be startled, we have VTP to bail us out. At the point where VTP is prepared, it will do VLAN update on the switches for us and will make the unique included VLAN the sum of the switches. Energizing and jaw-dropping right?

Presently how about we check the perilous part. Envisage it is a marvelous day and you come to work and blissful to see the whole grid is working fine, you are asked to instate another switch in the arrangement which was a utilized one and you unequivocally add the switch to the system. Suddenly things are not the same as they were and this seems to be, Well! VTP is action. Why?

See you had VLANs on your grid as e.g. 1, 2,3,4,5 soon after the unique switch(s) were instated having VLAN we should state 3012. So what VTP is doing, it checks and discover that there is VLAN 3012 in the system now and all different switches are on VLAN:1,2,3,4,5 , it eradicates all of these 1,2,3,4,5 VLANs, makes VLAN:3012 and you lose your arrangement recognizing blackout till you track the issue.

VTP Versions

There are numerous adaptations of VTP.

VTP-v.1 and 2 are relative with the sole uniqueness that shape 2 incorporates back for token ring frameworks. VTP structure 3 is novel and is unequivocally exceptional to go ahead CatOS-8.1 or higher.

VTP Modes of Operation

Accompanying are the VTP modes of operation that are allotted to every VTP unit:

1-Server: The mechanism having the “Server” mode of operation is fit to design, include and erase VLANs as well as the design of VTP form, VTP pruning and confirmation.

Note: The default switch VTP mode is ‘Server’

2-Client: VTP clients are not ready to make any design updates noticing the VLANs. The client apparatus actually takes parameters from the server and executes it in the database.

3-Transparent: VTP transparent mode gadgets don't tune in VTP as the name states they are transparent. They actually promote VTP over the grid.

It is remarkably proposed not to keep more than one switch in server mode for VTP on the grounds that when you include increasingly server roles in the grid, you are expanding the danger element as anybody can update any VLAN information and it will be advertised over the network and you will end up forgetting the start and end point and this is where VTP becomes your enemy.

CCNA Advance- STP (Spanning Tree Protocol) : Part 2

Posted by Unknown Saturday, June 1, 2013 2 comments

STP- Enhancements

PortFast:

As for now we are well equipped with STP, now we turn to STP optimization techniques. STP optimization is necessary for fast convergence times in the network, as the standard 4 step convergence of STP can cause a lot of havoc in the real time network. In this article we would like to discuss STP: Port fast, Uplink fast, and Backbone fast.

When a switch powers up or when some device is connected to a switch, STP immediately comes into action. In the initial phase the port enters into a spanning tree listening state. Listening state is just like a network topology exploration, this state lasts for a certain time, and then the port transitioned into a learning state. After an STP forward timer threshold the port state changes into either blocking mode or forwarding mode. In a real time network, most of the time we can’t afford the switch port to transition through all these 4 stages. We want the port to immediately shift into a forwarding state, once a network is alive, to avoid un-necessary packet delays in the network. For this purpose we use an STP PortFast feature. Once PortFast is enabled on a switch/trunk port, the port skips the listening and learning phases and immediately shifts into the forwarding state. So one important point we need to remember is:

Only enable PortFast on End Stations, because it can create network loops if used carelessly (as it turns the port into a forwarding state immediately)!

So it was easy? Yes it was, now we move towards a new strange concept UpLink Fast.

UpLinkFast:

By using UpLink fast on a port, fast convergence is achieved via creating UpLink Groups. Once a topology change occurs, convergence is achieved using these UpLink groups, which activate the redundant links (ports) instantly. This redundancy is achieved without hassle of passing the redundant link through all STP transition phases (i.e. listening, learning), within 1-5 seconds: redundant link (port) is in forwarding state. An UpLink group consists of the root port and set of blocked ports. This UpLink group consists of alternate path if the active root port fails. Some of the worth remembering points regarding UpLink fast are:

It cannot be configured on a root switch.
When UF is enabled, it’s enabled globally and for all VLANs residing on the switch.
The designated port (root port) will retain its status once it detects that the failed link has been restored and fully operational.
The wait interval for the port to become root port again is determined by: (2 x FwdDelay) + 5 seconds.
UF will take immediate action to prevent the switch (on which UF is enabled) from becoming the root switch by: changing the switch priority to 49,152, making it the last option in a network topology for becoming a root switch. The STP port cost is increased up to 3000 making it least feasible part for any switch to use it to reach the root switch.

I think that much theory is enough, now we will do some configurations to solidify our concepts. For our example scenario we are using GNS3 and emulating C2961 router as a switch because packet tracer is not giving us much options to implement advance STP.

For complete article, please download it from below mentioned link and Enjoy:

http://www.mediafire.com/download/r69bzogi3g3lid8/STP-Enhancements_Part_1.pdf

Syslogs Part III

Posted by Unknown Thursday, May 30, 2013 0 comments

Now we are going to configure our SYSLOG server and will enable the router to send logs, upto severity level 7, to our SYSLOG server:

Great, now we can see the log messages coming to our SYSLOG server:

Isn't it interesting, that all the changes, critical warnings are available to you on a nice looking NMS interface. Such things are really useful in a Network Operations Center. This NMS can also be configured to send email to a group in case some warning arrives that match to our define thresholds. The kiwi SYSLOG manager is another good tool to monitor the log messages on an NMS. We will end our discussion by showing you all the stored logs in buffer on R1 by issuing the following command:

As can bee seen, all the log messages of our router are stored in the router buffer, we can track the history of any critical issue/outage and other many things from these SYSLOGS.

SYSLOGs

Posted by Unknown Sunday, April 28, 2013 0 comments

SYSLOG or system logging is one of many interesting concepts in Cisco world. Log messages monitoring and audit is one of the main parts of a network engineer life. Log messages are displayed in real time on the route, once we make some changes in the network, or if any issue happens to our network devices. We can also send these log messages from the router to a centralized NMS for monitoring in a Network Operations Center. IOS can log messages to :

Console
Monitor (VTY, AUX) usually enabled via terminal monitor command in global config mode.
Buffer
Trap (SYSLOG) to send logs to an NMS

One important thing to understand is the concept of logging levels. Logging levels simply specify the type of log messages we want to send to our desired logging buffer/terminal/server. Different logging levels can be set via logging console command:

Let understand severity level concept:

Severity level 3 means 0, 1 , 2, 3 ( severity level 0/1/2/3 enabled), and the router will send all corresponding severity level log messages to our desired destinations.

If we don’t want to mention the severity level # , we can specifity the name of the logging severity, for which we want the router to send all updates, for example if we want to send all Critical Condition logs, we can enable it via the following command :

R1(config)#logging console critical

The severity level command comes in handy, when we want to enable different types of logging in one go.

In the second part of this article, i will discuss the practical implementation of SysLog in GNS3.

SNMP: Simple Network Management Protocol

Posted by Unknown Saturday, April 27, 2013 1 comment

SNMP: Simple Network Management Protocol

SNMP is used for monitoring of network devices, collects logs and health statistics of different device nodes. SNMP data can be collected on a centralized NMS (Network Management System), the collected data can be plotted for a better representation of the overall network health. SNMP collects all of its data via SNMP Pooling and SNMP traps. Some famous SNMP supported NMSs are IBM Tivoli, PRTG and MRTG grapher. Many free SNMP based software is also available in the open source community.

Quick Facts about SNMP:

SNMP Poll uses UDP 161
SNMP Trap uses UDP 162
SNMPv3 allows username authentication and packet encryption
SNMP Inform requires packet acknowledgement, while SNMP Trap does not
SNMP versions: SNMPv1, SNMPv2c & SNMPv3

SNMP Configuration in GNS3

Suppose, we are setting in a NOC (Network Operations Center). Our network is up and running, our task is to configure an SNMP based NMS to monitor our Core Network Router (R1), which is critical for our network operations. We are using a very popular NMS, known as PRTG (Packet router traffic Grapher). PRTG is a very popular used NMS, very good, efficient and excellent graphical interface, which gives us a very remarkable view of our critical network elements.

The simple flow of the topology is as follows:

A 2691 router is connected to a cloud (in GNS3, Cloud is used to connect the router to our PC physical interface). PRTG NMS has been configured on PC1 (local host). The topology is given below:

The IPs used:

Fast Ethernet 0/0 ( R1) : 192.168.0.99/24
NMS PC1 IP : 192.168.0.100/24

SNMP enabled via the following commands on R1:

We need to configure a community string (community string is a sort of snmp password) for our snmp server on the router, in our case as we are using community string “PRTG” (using PRTG as the community string for simplicity):

snmp-server community PRTG RW

Above command, simply means that we have enabled PRTG as a password for our snmp-server. You need to use this password while configuring the SNMP settings on your NMS, in our case its PRTG. In the next step we are going to set our SNMP server host address:

Host means our SNMP server IP address, in our case it is: 192.168.0.101/24.

And you can also select which version of SNMP you want to use by:

We have done our configuration on PRTG server and have enabled the monitoring of Fast Ethernet 0/0 interface of R1. The NMS output can be shown as:

In the above example we have configured our NMS to monitor R1 Health and R1 Fast Ethernet 0/0 interface status. The sample outputs from NMS are:

Some more amazing graphs:

All the logs related to our above simple network are maintained:

SNMP Packets:

To check SNMP in action, we can use: debug snmp packets command. The sample debug output for above network is:

SNMP is the most interesting topic to study and configure, you can download many propriety and open source SNMP based NMS tools from internet to experiment with.

Shah Hussain (c)

DHCP : Dynamic Host Configuration Protocol

Posted by Unknown Saturday, March 23, 2013 0 comments

One of the many services that we mostly need in our network is DHCP. The Dynamic Host Configuration Protocol is used to dynamically assigned IP addresses and Default gateway information to the host on a network. In simple words, the DHCP functionality can be expressed as:

As can be seen, our host is acting as a DHCP client on the LAN, it will send DHCP Discover broadcast on the network, and all the relevant data will be provided like IP Address, Subnet Mask, Default Router, DNS Server, to the requesting host. DHCP discovery is a 4 leg process:

Discover
Offer
Request
Acknowledge

The client send a Discover message, the DHCP server send a Unicast Offer, the client then sends officially a Request Offer, and an ACK send by DHCP server. It seems ambiguous? Better explained by below diagram:

CISCO IOS can also be configured as a DHCP server and Client. A router can be configured as a

DHCP Server
DHCP Client
DHCP Proxy

Quick Facts about DHCP:

UDP 67 is server-side port
UDP 68 is client-side port

Redundancy can be created via DHCP safe fail over Protocol using a cluster of DHCP servers in which one server acts as a Primary Server and the second one act as Backup Server on which Backup address pool is configured which could be used in case of failover of the primary DHCP server. So far we have discussed the basic working of DHCP, its packet flow, and how to enable redundancy in DHCP. Now it is time to move into configuration.

Configuration:

We are going to configure DHCP in packet tracer. We have bunch of host connected to a switch, which is connected to a router. The router is acting as DHCP server and all the hosts in the network are assigned IP addresses from our defined IP pool for DHCP. The topology we will be using is as follow:

In the above network, we have enabled Routers0 interface as our DHCP and DNS server. The client are not configured with static IP, instead DHCP option is selected on each host, to get all configuration data from the DHCP server. Once the router is up and Clients are active, the client instantly updates their IP addresses and Default gateways by sending DHCP requests. We have configured a DHCP pool by name of LOCAL_LAN pool on our router; the IP addresses assigned to the hosts are leased from this IP pool. We have also mentioned some of the address which should not be assigned by the DHCP server, using

ip dhcp excluded-address , command as these addresses are already assigned or kept for future use.

The DHCP configurations done on R0 are:

The default router and dns server address is our routers Fast Ethernet 0/0 interface IP address. We have excluded the DHCP server IP and DNS IP from the list of IPs that is going to be assigned by DHCP server. To define router as proxy DHCP server, we use ip helper command under interface config mode, this just relay all DHCP requests to the mentioned DHCP server. Last thing, in dhcp options, we can also define lease time, the time duration till which the address is valid. The address will be renewed after the lease time is elapsed.

I hope you enjoyed this article. Please do let me know your feedback and comments.

CIDR II: A little more in depth explanation

Posted by Unknown 0 comments

PART II:

Suppose our ISP owns an address block: 200.24.0.0/16. What this means?

An address block comprises of different address that the ISP can allocate and sell to its customers. The IP address block 200.24.0.0/16 can represent 2^16 = 65, 536 IP addresses. Suppose from this block it wants to allocate 200.24.15.0/20 address block. So how many addresses is this in reality? Simple, 2^12 = 4096 or 16 /24s, how? The block size is /20 or in other words 255.255.240.0 so our block size can be calculated as 256-240 = 16 , this means the given /20 block comprises of 16 /24 addresses if we are considering a Class full environment.

200.24.15.0

200.24.16.0

200.24.17.0

200.24.18.0

200.24.19.0

200.24.20.0

200.24.21.0

200.24.22.0

200.24.23.0

200.24.24.0

200.24.25.0

200.24.26.0

200.24.27.0

200.24.28.0

200.24.29.0

200.24.30.0

Each address has the capacity to represent 255 addresses so 255*16 = 4096, as already mentioned above. So if the ISP distributes these among 3 organizations named A, B, C—the distribution would be as follows:

200.24.15.0

200.24.16.0

200.24.17.0 Block size of 4, 256-4=252 so the whole block would be 200.24.15.0/30

200.24.18.0 IPblock 200.24.15.0/30 will be assigned to the Organization A

200.24.19.0

200.24.20.0

200.24.21.0

200.24.22.0 Block size of 8. 256-8 = 248 so the whole block would be 200.24.19.0/21

200.24.23.0 IPblock 200.24.19.0/21 will be assigned to organization B

200.24.24.0

200.24.25.0

200.24.26.0

200.24.27.0

200.24.28.0Block size of 4, 256-4=252, so the whole block would be 200.24.27.0/30

200.24.29.0 IPblock 200.24.27.0/30 will be assigned to organization C

200.24.30.0

Believe me, by doing above process, we have cracked all the route aggregation and summarization at the Global, ISP and Organization level.

You will feel that CIDR has the same look like VLSM. Yes, it’s right to some extent. Both allow us to change the IP dynamics according to our requirements, but VLSM is invisible to the global internet. The VLSM can be felt only in our internal network topology. On the other side, CIDR is visible to the global internet. A global Internet Registry can assign any CIDR block or prefix block to any top level ISP, to a medium level ISP or to any private organization.

Okay now some interesting stuff. If you want to see all this CIDR, route summarization in action, visit MeritRADb the routing asset database online website. This website provides information related to all the routed networks and ASs on the internet up to this moment! For example if we want to dig this IP: 173.194.67.104, we will go to their website: http://www.ra.net/ and will query this IP using Query the RADb box. The output is quite interesting:

route: 173.194.67.0/24

descr: Google

origin: AS15169

notify: radb-contact@google.com

mnt-by: MAINT-AS15169

changed: radb-contact@google.com 20121119

source: RADB

This IP (173.194.67.104) is owned by Google incorporations!! Okay one more IP: 205.134.232.114

route:      205.134.224.0/19

descr:      Corporate Colocation, Inc.

origin:     AS17139

notify:     netops@mzima.net

mnt-by:     MAINT-CORPCOLO

changed:    noc@corporatecolo.com 20071108

source:     RADB

The above IP is somehow part of the major route shown in the RADb output. The Routing Asset Database website is one of a great place to spend your weekend time on!

Please remember that IANA or Internet Assigned Number Authority is the organization responsible for taking care of global IP address allocation and other IP related activities.

CIDR - Classless Inter-domain Routing

Posted by Unknown 0 comments

PART I:

CIDR (RFC: 4632): Classless inter domain routing. In simple words, CIDR is like supernetting route summarization and VLSM at the ISP end that’s why it is called Classless inter domain routing. Confusing? Okay let us discuss it via an example; it will help us picture the whole concept. As we learned in route summarization, instead of advertising each address, a router makes a block of addresses and advertise it, it minimizes load on routers and enhances network efficiency.

Instead of assigning addresses according to the Classful subnet boundaries, the ISPs begun to assign IP addresses in the form of blocks. Then it was the duty of the ISPs to assign smaller blocks to its customers from the Big block. In CIDR the routers were given the ability to process the IP addresses according to the classless subnet prefix instead of the starting 0 and 1s in each IP address. Or in the other words, the routers were programmed to understand the prefix through which it can decide to which domain (major block of IPs) these addresses are assigned.

If the a whole Class A, B or C address is assigned to an organization, there is a chance of the wastage of IP addresses, so IP address conservation was one of the main reasons behind CIDR development by IANA. IANA suggested assignment of IPs address ranges other than the conventional class paradigm. These policies not only helped in preserving the wastage of IP addresses but also reduced the load of the global routing tables. So the two goals behind CIDR creation by IANA were:

To reduce the global routing table size
To preserve the IP address space

Let understand the first point via an example. Suppose we have a block of addresses are below:

192.168.20.0/24

192.168.21.0/24

192.168.22.0/24

192.168.23.0/24

We can summarize this address as:

Our block size is 4, so our best subnet choice at 3^rd octet is 256-4 = 252, so we can summarize the above network IDs with following subnet IP:

192.168.20.0

255.255.252.0 OR

192.168.20.0/22

Have you noticed one interesting thing, we have moved backward from standard Class C boundary. We have an IP address 192.168.20.0 with the prefix 22 which represents a block of 4 IP addresses of 24 subnets. Now the router will only advertise with /22 addresses and the same process are repeated from our side to our ISP. Our ISP does the same route aggregation and advertises a single block to higher networks and the process goes on. Without this process we would have millions of routing tables for the global IP traffic! And how the IP addresses are conserved? Well they are conserved when a specific block of IP addresses is assigned to customers.

An ISP will never assign a Classful address to any corporation, as a lot of addresses will go waste and the ISP can’t take back the non-used addresses. For the solution of this problem, IP address Ownership an IP address Lending scheme was introduced but they are still in review amidst much heated debate on it.

Network Address Translation III

Posted by Unknown Thursday, February 21, 2013 0 comments

In this part we are going to configure Dynamic NAT on our gateway router ( R2). We will following the previously mentioned three steps to achieve this task like:

Labeling the interfaces
Configuring the ACL for hosts
Implementing the NAT from global config mode

So here we go, and you will see it’s not that difficult to implement it practically:

Dynamic NAT Configurations:

Suppose we want to configure Dynamic NAT on R2. For this purpose, we need a pool of global IP addresses that would be dynamically mapped with our local hosts. So we need to buy these addresses from our ISP J just assume, we bought the following IP pool form our ISP:

171.16.10.52 - 171.16.10.56

We will follow above mentioned three steps to implement dynamic NAT on our current network topology:

Step 1:

Labeling the interfaces:

interface FastEthernet0/0

ip address 192.168.1.2 255.255.255.0

ip nat inside

interface Serial1/0

ip address 171.16.10.1 255.255.255.0

ip nat outside

Step 2:

An ACL needed to be created for local hosts IPs that we want to translate:

ip access-list standard NAT_IPs

permit 192.168.3.0 0.0.0.255

permit 192.168.2.0 0.0.0.255

permit 192.168.4.0 0.0.0.255

Step 3:

Once ACL is created, we need to configure our IP pool and dynamic NAT from global configuration like:

ip nat pool Global_IP_Pool 171.16.10.52 171.16.10.56 netmask 255.255.255.0

ip nat inside source list NAT_IPs pool Global_IP_Pool

Our pool name is: Global_IP_Pool

ACL name is: NAT_IPs

Some of the other things done on R2 are: static route to ISP and RIP:

router rip

passive-interface Serial1/0 ( this commands is configured to stop RIP advertisements to our emulated ISP)

network 171.16.0.0

network 192.168.1.0

ip route 171.16.0.0 255.255.0.0 171.16.10.2

And we are done with our Dynamic NAT! that was quite easy and simple. Now some other fun commands. In order to check the IP NAT translations going on in the network, we just issue show ip nat translations command on R2 and see the result:

From R1 we ping our ISP:

R1#ping 171.16.10.2 source 192.168.3.1

We get successful ping results to 171.16.10.2. The source IP was changed on R2 during the process of pinging as we have configured NAT on R2.

Now let’s see what’s happening on R2:

Our ping request was originated from inside local: 192.168.3.1 and has been translated into 171.16.10.52 inside global address. One other interesting command for your geek mind:

I hope after going through all of the above commands, you will have confidence in yourself and will see how interesting it is to implement. Just remember one thing: if dynamic NAT is used, we can’t access our local hosts from outside the network, as the router will not be sure to where it has to route the packets and for this purpose Static NAT is recommended, which we will discuss shortly.

Okay, as an example, please perform some practice of dynamic NAT with following requirements:

The routing protocol running is EIGRP with AS # 4
The IP Pool Name is CORP-IP pool
ACL is allows only 192.168.3.0/24 network to translate

--to be continued--

My CISCO Journal

CCNA- How to configure Cisco IOS Banners

Different Banners

MOTD Banner

Login banner

Exec banner

Banner incoming

CCNA- VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 2

CCNA- VLAN Trunking Protocol (VTP) – The Good VS the Bad Part 1

CCNA Advance- STP (Spanning Tree Protocol) : Part 2

STP- Enhancements

Syslogs Part III

SYSLOGs

SNMP: Simple Network Management Protocol

DHCP : Dynamic Host Configuration Protocol

CIDR II: A little more in depth explanation

CIDR - Classless Inter-domain Routing

Network Address Translation III

About Me

Popular Posts

Network Engineers Must blog

Blog Archive

Labels