Cisco Offline Password 7 Decryption

Create a .html file with the following content:

 

Synology Festplatten upgrade – alte Platte einlesen

Die zwei neuen Platten einbauen. Mit dem Synology Installation Assistant die NAS einrichten. Anschließend kann man eine alte Platte per USB an die NAS anschließen.

In der Weboberfläche muss noch SSH aktiviert werden.

Anschließend ssh root@NAS_IP

Assumptions

  • You know how to login as Admin on the NAS to which you are going to connect the USB disk
  • The USB Disk you are adding is already preformatted with either ext2 or ext3 (Synology products format internal drives as ext3). If the drive is not formatted or formatted as NTFS the procedure should be similar but you may need to vary some of the commands.
  • The Synology NAS to which you are connecting the USB Disk is working normally.

Procedure

  1. Ensure the NAS is powered up and running normally
  2. Connect the USB enclosure containing the Hard Disk to the NAS
  3. Enable the Command Line Interface (Telnet or SSH)
  4. Login into the Command Line Interface as „root“
  5. Check what you already have mounted in the system by entering the command „df“.
  6. Now we check that the new drive is being recognised, enter the command „fdisk -l“ thats a lower case L not a 1. You will see each installed disk (installed internally and via USB) listed and each partition on the disk listed. For instance your internal hard disks on a multi-bay NAS will be listed as „Disk /dev/sda“ for internal disk 1 and „Disk /dev/sdb“ for internal disk 2 etc. At the bottom of the list will be any externally mounted disks (e.g. via USB). On my system the UsB disk was listed as „/dev/sdk“. As the disk was from another Synology NAS it had the three synology created partitions on it: sdk1, sdk2 and sdk3. But most disks will probably only have one partition „/dev/sdk1“.
  7. Now we need to map the required partition of the USB disk to a directory on the NAS root („/“). For windows users, the Linux „mount“ command makes data on the mounted partition appear in a directory in the operating system root directory, Linux doesn’t use drive letters, disk are mounted as a directory instead. Before we can mount the drive we have to create the directory the mounted drive will be attached to. For temporary mounts we can create a directory under the „/mnt“ directory. Hence create the directory „/mnt/usb“ by entering the command „cd /mnt“ and „mkdir usb“.
  8. Now we mount the required partition on the USB disk (for most people it will be „/dev/sdk1“) to the directory „/mnt/usb“. Enter the command „mount -t ext3 /dev/sdk3 /mnt/usb“ (if your disk is ext2 formatted then use ext2 instead of ext3). If your USB disk is from a working RAID1 configuration see the section „How to mount a USB enclosure containing a RAID1 disk“ below.
  9. Finished, you can now use the cp or other commands to copy/move data
  10. You only created a temporary mount so if you reboot the NAS you will need to re-use the same mount command again.
  11. If you want to mount the Disk permanently you need to modify the „/etc/fstab“ file using vi using the command „vi /etc/fstab“. For the example above, i.e. we want to mount the usb disk you will need to add an entry like „/dev/sdk /mnt/usb ext3 defaults 0 0“. If you need help using vi see Basic commands for Linux VI Editor. Note in the fstab file we are describing the format and way we want the OS to handle the disk, so you don’t specify the partition numbers. After modifying the fstab file. You use different options in the mount command, i.e. without the „-t“ and „ext3“ options. Hence enter something like „mount /dev/sdk1 /mnt/usb“ making sure you use the exact correct nomenclature for your circumstances as described previously.

How to mount a USB enclosure containing a RAID1 disk

If the disk in the USB enclosure was from a working RAID1 configuration you will need to use the mdadm command to attach the USB drive to an available md array before your can mount the md array.

  1. Follow the procedure above up to the point where it says to come to this section
  2. Check md identifiers of the partition you want on the USB disk are intact, e.g. enter the command „mdadm –examine –scan /dev/sdk3“. mdadm should report back a single line, something like „ARRAY /dev/md2 level=raid1 num-devices=2 UUID=db7c8f07:6f0f4570:852c2e22:a378fec9“. Don’t worry about the „/dev/md2“ this is just where it was last used. If you get an error message and are certain the disk was from a RAID1 array you won’t be able to use this procedure untill you repair the partitions md identifiers. You will have to search elsewhere for how to repair identifiers.
  3. Check what md arrays are already defined using the command „mdadm –detail –scan“. Alternatively for a bit more info use „cat /proc/mdstat“. All multi-bay synology servers will have md0 (the OS), md1 (the swap file space), md2 (/volume1). If you have other volumes you may also have md3 (/volume2) etc.
  4. We will use the next available md array number, e.g. if the last one on the list produced in the previous step was md2 then we will attach your usb disk to „md3“. Use the command „mdadm -A –verbose –run /dev/md3 /dev/sdk3“. The –run option forces the making of the attaching of the array when only 1 of the original 2 RAID1 disks are available.
  5. You can now mount the „md3“ array to „/mnt/usb“ using the command „mount /dev/md3 /mnt/usb“.

Try with a command like „lvm vgscan“ if it can detect the volumes contained there.
If that succeeds, you’ll need to activate it „lvm vgchange -a y <volumegroupname>“
then „vgdisplay“ will tell you about logical volumes names, and finally you
should be able to run something like „mount /dev/<volumegroupname>/<logicalvolumename> /t“

 

Kompletten Netzwerk-Traffic durch SSH tunneln

I’ve recently been visiting China and have been caught out by their Firewall.  This hasn’t be too bad but Google Mail and Google Drive is really slow or intermittent.  Also you can’t access YouTube or the BBC IPlayer.   The final straw for me was for some reason they have blocked the Ubuntu Dropbox repository – so you can’t install Dropbox either.

I don’t have VPN account but we do have some servers.  Therefore, I decided to route all the network traffic through one of our server.

I tried various options and final settled on sshuttle because I needed to route everything and not just Firefox. Sshuttle is a transparent proxy server that forwards over a SSH connection and sets up a proxy by running Python scripts on the remote server.  I’m assuming your are running Ubuntu on both the client and the remote server.  You will need administrative privileges on the client.

sudo apt-get install sshuttle

To route all traffic through sshuttle (except DNS):

sshuttle -r username@sshserver:port 0/0

You will then need to enter your password on your client and then the password for the remote machine.  To help debug run sshuttle in verbose mode with the -v flag.  The -r flag is  the remote host (and username).   The port 0/0 is short for 0.0.0.0/0 that represents the subnets to route over the VPN.  The usage of 0/0 routes all the traffic except DNS requests to the remote server.  If you need to tunnel your DNS too then add the -H flag.

The project website is https://www.stunnel.org/index.html

Happy Tunnelling.

Routing Information Protocoll – RIP Timers

Sometimes its the simple things that are struggled with. RIP is one of those. Most CCIE candidates understand that we can change the interface or global parameters for updates, unicast, multicast, etc. What does take some time, is figuring out the global timers, especially if a person is not sure how they interact.

In this post, we will address the RIP process level timers for update, invalid, hold down and flush. I don’t want you to sleep during this, so we will save that one for later.

Timers Basic, all in seconds:
Update: how often to send updates in seconds
Invalid: how many seconds, since seeing a valid update, to consider the route invalid, and placing the route into hold down
Hold Down: Once in hold down, how long (in seconds) to “not believe” any equal or less impressive (worse) route updates for routes that are in hold down
Flush: how many seconds, since the last valid update, until we throw that route in the trash (garbage collection for un-loved non-updated routes)

Here is our topology.  Keep your attention on R2, and that will be the focal point for this lesson.

rip-hold-down2

Let’s set up some unique values, so we can see the results.
Defaults are:

Update: 30
Invalid: 180
Hold Down: 180
Flush: 240

We will use 30,  40, 10 and 90 respectively.

We can see the results of our changes with show ip protocols.

We can see that R2 is learning 2 routes from R3, the 10.33.0.0/24 and 10.77.0.0/24 R2 received the last update 7 seconds ago, based on the output.

Let’s enable debugging so we can see the play by play.

Here is an update from R3. Notice the time stamp of 1:24:23. This will be the last one sent from R3. (Because we’ll configure R3 to go passive in a moment). Also, notice that we are sending and update as well. An update schedule of 30 seconds, based on the RFC for RIP, may be 30 seconds, + or – 5 seconds, to avoid synchronization. Let’s focus on the learned 10.77.0.0 network with a hop count of 8.

After the update from R3, learned on Fa0/0, I used the passive-interface default command on R3 inside of the router rip process.   While we wait for the invalid time to occur, due to the missing routes, we can entertain ourselves by seeing  updates being sent from R2, at 30 second intervals.

It has been 40 seconds since the last updates from R3, and 40 seconds was our invalid timer setting. (Our last update was 1:24:23, and now it is 1:25:03). The routes enter hold down, which means the router will not believe any new updates regarding these routes. Hold down is intended to assist in avoiding inaccurate routing by rumor information while the network converges. The exception would be if a route with a better (lower) metric was received by R2  for the 10.77.0.0, R2 would use it. (In our example, 10.77.0.0 had a metric of 8. If R2 learned about the 10.77.0.0 with a metric of 7 or lower from a neighbor, it would use it if learned during the hold down.)

R2 advertises a poisoned route for the networks in hold down. This is a triggered update, and not based on the normal 30 second update timer.

R1, sends us a poison-reverse update, regarding the same networks. This intentionally overrides the split horizon rule which is in place on Ethernet interfaces by default.

Another normal update, being sent by R2, including the poisoned routes.

While the routes are in hold down, the router still forwards packets to those networks, based on the last information that it last learned about how to reach those networks. The routes will show up as “possibly down”.

So were is the removal of the hold down. The timer was only 10 seconds? Better late than never. Even though the hold down timer was set to 10 seconds, the hold down timer has to expire and then the next poisoned route received causes the routes to be removed from hold down. Our routes went into hold down at 25:03, it is now 25:36. Regardless of the hold down timer setting, if we didn’t receive any poisoned updates from neighbors, the hold down would stay until the flush timer removes the route completely.

Even though the routes are done with their hold down, R2 still will show the route as possibly down, and will continue to do so until the flush timer expires.

Another update clicks off, and then we approach the 90 second flush timer

Based on the last valid update of 1:24:23, and now that it is 1:25:53, 90 seconds are up (flush timer) and the routes are deleted.

Now the routes don’t show up in the routing table either.

If we use context sensitive help, we find one more parameter for the timers:

Quelle: http://blog.ine.com/2010/04/15/how-basic-are-rip-timers-test-your-knowledge-now/

Veröffentlicht unter CCNA

Spanning Tree Protocol

In most networks larger than your typical SMB switched networks, there will be path redundancy. While most people like the effects of redundancy, the redundancy can cause problems at Layer 2.

If you were to have a network with 2 or more switches inter-connected without Spanning Tree Protocol (STP),  you would have switching loops. Why would you have switching loops? Unlike Layer 3 which has “Time to Live” (TTL), Layer 2 broadcasts never time out.

The Spanning Tree Protocol (STP), defined by IEEE 802.1d, prevents switching loops from occurring. It does this by placing ports along the most desirable path into forwarding mode. The ports along less-desirable paths are placed in blocking mode.  By doing this a switching loop cannot occur.

If a problem arises with the available path, STP will run the spanning-tree algorithm to recalculate the available path and determine the best path.

Ports along the new best path will be brought out of blocking mode and into forwarding mode, while ports along less-desirable paths are placed in blocking mode. Again, the only path will be available.

How Does Root Bridge Election Work

STP must first determine a root bridge for every Virtual LAN (VLAN). Please note… it needs to do this for EACH VLAN.

When each switch is turned on they all believe they are the “chosen one”. To figure out the “chosen one” they need to hold an election. While we use ballots to vote for people, the switches vote use a thing called “Bridge Protocol Data Units” (BPDU). The Switches continually send BPDUs. Pretty much every other network device does not send BPDUs. Examples of networking devices that DON’T send BPDUs are:

  • Hubs
  • Repeaters
  • Routers
  • Servers
  • Computers
  • etc

What Does the BPDU Contain?

The BPDU contains 3 main pieces of data. They are:

1 – “Bridge ID”:

  • The Bridge ID or BID is a combination of the bridge’s priority and MAC address.
  • If it is at the beginning of an election, because the switch believes it’s a the Root Bridge, the BID will be it’s own BID. Once the election is over, all Non-Root Bridges will send.
  • The bridge with the lowest BID will be the root bridge.
  • The default value is 32768+VLANID for ALL switches
  • Typically by default the root bridge with the lowest MAC address will become the root bridge
  • Example of a bid: 32768+[VLANID]:00-0b-be-2d-42-61b (Note priority is listed first then the MAC address)
  • To find out the MAC address of the switch type: “show version” or “show int vlan 1
  • To find out the priority and Mac address of the switch use the command “show spanning-tree vlan 1

2 – Cost to Reach Root From this Bridge:

  • STP considers the path to have the lowest cost to be the best path.
  • Every port is assigned a cost relative to its speed.
  • The Higher the speed, the lower the port cost.

3 – BID of the BPDUs Sender:

  • This simply identifies which switch sent the BPDU.

When a switch receives a BPDU, the switch compares the root BID contained in the BPDU against it’s own BID.

  • If the incoming root bridge BID is lower than that of the switch receiving it. The switch starts announcing that device as the root bridge.
  • If the incoming BID is higher than that of the receiver, receiver continues to announce itself as the root. This process continues until EVERY switch has agreed on the root bridge.

Once STP has converged, every port on the switched network will be in either blocking or forwarding mode. There are several intermediate states:

  1. BLOCKING – Frames are not forwarded, but BPDUs are accepted
  2. LISTENING – Frames are not forwarded, and the MAC address table is not yet built.
  3. LEARNING – Frames are not forwarded.  Mac Addresses are being learned and the MAC address table is being built.
  4. FORWARDING – Frame ARE forwarded. Mac Addresses are still being learned.
  5. DISABLED – Disabled ports cannot accept BPDUs.

Let’s look at a 2 switch setup

Using a straight through cable, I’ve connected port s1/port 23 to s2/port 23. I’ve also connected s1/port 24 to s2/ port 24.

image

It’s important to note that once STP has converged, one port and one port only will be in a blocking mode. The other 3 will be in forwarding mode. The picture above shows which port is in blocking mode by using a orange dot.

The first thing you should really do is see what VLANs are running on the devices. You do this by running the command:

show vlan brief

Please see the screenshot

image

As you can see all the ports are on VLAN1.

The next thing you should do is check if you have any trunking ports. Don’t worry if you don’t know what that is right now.

image

It will most likely come back clean.

Now that we have a fairly clean switch let’s check the SPANNING Tree information. To do this we will need to issue the command:

show spanning-tree VLAN 1

I’m first going to run it on switch “s1”. Here’s an example of the output:

image

Please note, I’ve made several sections by surrounding them with a particular color.

  • Red – This line will only be displayed when the switch has been elected “root bridge”. You can also tell if a switch if the root bridge by comparing the RID and BID. If the RID and BID are the same you will also know that the bridge is the root.
  • Orange – The “Root ID(RID)” shows us the BID information for the Root Bridge.  The Bridge ID (BID) section shows us the local switch’s BID.
  • Blue – This is essentially showing you what ports are connecting to another switch. It also tells you if the port is in Forwarding (FWD) or Blocking Mode (BLK). The cost is also listed here.
  • GREEN – Note the Priority is 32768+Sys-id .

Here’s an example of the output on switch “s2”.

image

Please note, just like “s1” I’ve added some colored areas to help direct your attention:

image

  • RED – It does show the cost needed to get to the “RID”. You can also tell that it is using “FA0/23” to get to it.
  • ORANGE – The RID and BID should be different. Because of this you should be able to tell that this is not the “root bridge”.
  • GREEN – Based on the RED section you might have guesses that both of these sections should NOT match.
  • BLUE – Again this shows us what ports are in use. This switch has on in FWD and BLK mode.

By Default the switch with the lowest BID will be elected. Let’s look at our two switches:

  1. s1 BID = 32769:0001.6461.D488
  2. s2 BID = 32769:0002.17CE.CB64

Let’s look at a 3 switch setup

Ok. Let’s look at the setup. Here are 3 Cisco 2960 switches. Each switch has had nothing done to them except the changing of their hostname to reflect the screenshot.

image

On each switch let’s run the command “show version” to see what the Mac address is off each of the switches and see if we can predict which switch will become the root bridge.

  • s1 Mac address = 00D0.FFB0.8961
  • s2 Mac address = 00E0.F73A.847B
  • s3 Mac address = 000D.BD87.AD9B

What else do we know about this setup without running any other commands?

  • It looks like “s3” has the lowest valued Mac address. “s1” is next and “s2” has the highest value. Right away we should know that STP should make “s3” the root bridge.
  • We know that the priority of each switch will be the default 32768+1=32769. Because the priority is the same on every switch the priority will have absolutely no effect on this example.
  • Because we will only be ports with the speed of 100Mb/sec,  all ports will have a STP cost of 19. Because the link between “s2” and “s3” will have the highest STP cost from the root bridge, we know that one of the two ports on this link will be put into blocking mode.
  • From the first point we know the “s1” has a lower valued Mac address then “s2”. Because of this we should know that the port on “s2” will be put in BLOCKING mode.This will essentially kill the link between “s2” and “s3” and prevent network loops.

image

Let’s talk about network segments, Port Roles and Port Status.

image

How many network segments are in this network? There are 3. Each link between switches is considered it’s own segment.

There are going to be several port roles on the network:

  • Root Ports – It’s important to figure out the root ports first. Each nonroot switch considers the port with the least administrative cost between itself and the root switch a Root Port (RP). All Root Ports are in a Forwarding state.
  • Designated Ports – Designated ports can never be root ports. The lowest cost STP switch ports are classified as designated Ports.
  • Alternative Ports – This port is essentially there waiting for something to happen on the network. If something does happen it can spring to life in a moments notice to provide an alternative path.

image

Port Status

All Ports that are Root Ports or Designated Ports will be put in Forwarding mode. Any port in Alternative mode will be put into a BLOCKING state.

image

How does Port cost effect the STP Topology.

Let’s say we used Gigabit connections in segments 1 and 3. What would happen?

  • The cost to go from “s3” to “s2” using top most path would = 4 + 4 = 8.
  • The cost to go from “s3” to “s2” using the single bottom path would still be = 19

Because 8 is < 19 STP should recalculate the paths. This is how the network would look:

image

Notice the ports on the “s2” have now reversed themselves because it’s actually faster to reach “s2” using the top most route.

Quelle: http://jaredheinrichs.com/cisco-ccna-spanning-tree-protocol-tutorial.html

Port Security

Port security is a layer two traffic control feature on Cisco Catalyst switches. It enables an administrator configure individual switch ports to allow only a specified number of source MAC addresses ingressing the port. Its primary use is to deter the addition by users of „dumb“ switches to illegally extend the reach of the network (e.g. so that two or three users can share a single access port). The addition of unmanaged devices complicates troubleshooting by administrators and is best avoided.

Enabling Port Security

Port security can be enabled with default parameters by issuing a single command on an interface:

Although only a single interface is used for illustration in this article, port security, if configured, is typically configured on all user-facing interfaces.

We can view the default port security configuration with show port-security:

As you can see, there are a number of attributes which can be adjusted. We’ll cover these in a moment. When a host connects to the switch port, the port learns the host’s MAC address as the first frame is received:

Now, we disconnect the host from the port, connect a small switch or hub, and reconnect the original host plus a second, unauthorized host so that they both attempt to share the access port. Observe what happens as soon as the second host attempts to send traffic:

Inspecting the status of port security on the port again, we can see that the new MAC address triggered a violation:

By default, a port security violation forces the interface into the error-disabled state. An administrator must re-enable the port manually by issuing the shutdown interface command followed by no shutdown. This must be done after the offending host has been removed, or the violation will be triggered again as soon as the second host sends another frame.

Tweaking Port Security

Violation Mode

Port security can be configured to take one of three actions upon detecting a violation:

shutdown (default) ; The interface is placed into the error-disabled state, blocking all traffic. protect ; Frames from MAC addresses other than the allowed addresses are dropped; traffic from allowed addresses is permitted to pass normally. restrict ; Like protect mode, but generates a syslog message and increases the violation counter.

By changing the violation mode to restrict, we are still alerted when a violation occurs, but legitimate traffic remains unaffected:

Unfortunately, violating traffic will continue to trigger log notifications, and the violation counter will continue to increase, until the violating host is dealt with.

Maximum MAC Addresses

By default, port security limits the ingress MAC address count to one. This can be modified, for example, to accommodate both a host and an IP phone connected in series on a switch port:

One also has the option to set a maximum MAC count for the access and voice VLANs independently (assuming a voice VLAN has been configured on the interface):

MAC Address Learning

An administrator has the option of statically configuring allowed MAC addresses per interface. MAC addresses can optionally be configured per VLAN (access or voice).

The configured MAC address(es) are recorded in the running configuration:

Obviously, this is not a scalable practice. A much more convenient alternative is to enable „sticky“ MAC address learning; MAC addresses will be dynamically learned until the maximum limit for the interface is reached.

After a MAC address has been learned, it is recorded to the configuration similarly to as if it were entered manually:

MAC Address Aging

By default, secure MAC addresses are learned (in effect) permanently. Aging can be configured so that the addresses expire after a certain amount of time has passed. This allows a new host to take the place of one which has been removed. Aging can be configured to take effect at regular intervals, or only during periods of inactivity. The following example configures expiration of MAC addresses after five minutes of inactivity:

After five minutes of inactivity, we can see that the address has been purged:

At this point, the old address will be re-learned the next time a frame is sent from that host, or a new host can take its place.

Auto-recovery

To avoid having to manually intervene every time a port-security violation forces an interface into the error-disabled state, one can enable auto-recovery for port security violations. A recovery interval is configured in seconds.

Ten minutes after a port was error-disabled, we can see that the port is automatically transitioned back into operation:

This is a great way to automatically clear port security violations after the user has been given an opportunity to remove the offending host(s). Note that is the cause is not cleared, the violation will trigger again after the port comes back up, re-initating the auto-recovery cycle.

Footnote

Although a deterrent, port security is not a reliable security feature, as MAC addresses are trivially spoofed, and multiple hosts can still easily be hidden behind a small router. IEEE 802.1X is a much more robust access edge security solution.

 

Source of the article: http://packetlife.net/blog/2010/may/3/port-security/

How to Configure DHCP on Cisco IOS Devices

The Dynamic Host Configuration Protocol (DHCP) is considered to be an evolution of the Bootstrap Protocol (BootP).

DHCP is literally build upon BootP, and BootP remains an internal part of DHCP. Both protocols have been created to provide IP addresses to clients when needed.

The difference between them is that while BootP provides an IP address to a client according to the client’s hardware address on the BootP server table, DHCP by default provides an IP address automatically to the client from a pool of IP addresses.

Besides an IP address, the DHCP server can provide the client a lot of information, such as DNS server IP address, Default gateway IP address, Domain name and much more.

A Cisco IOS device can be configured to act as:

  • a DHCP server – by providing IP addresses when requested to do so
  • a DHCP client – when it requests an IP address
  • a DHCP relay agent – when it captures IP requests from clients, adds extra information to the request for user identification purposes, and forwards the request to the DHCP server

Cisco IOS devices can be configured to act as all of the above and even in combinations of two or three of roles. In this article I will investigate the operation of Cisco routers under all of the above roles.

Cisco IOS Router Acting as a DHCP Server

Let’s start by investigating the process of IP address assignment when a DHCP client requests an IP address from a DHCP server. The messages exchanged between client and server can be seen in the diagram below:

configure-dhcp-cisco-1

The above diagram presents the DHCP message sequence. Here’s how it all goes down:

  1. The client sends a DHCP Discover message to locate a DHCP server – this is a broadcast message
  2. The DHCP server responds with a DHCP Offer unicast message – this message includes the IP address offered to the client, default gateway address and lease time for the IP address offered; it may also include DNS servers, TFTP server, and other information
  3. The client responds with a DHCP Request message which is a formal request for the IP address offered by the server – this is again a broadcast message
  4. Finally the server responds with a DHCP Ack unicast message confirming that the IP address has been leased to the client

Below is a list of the most important commands to enable a Cisco router to emulate a DHCP server:

configure-dhcp-cisco-table

Now let’s use the above commands in a real scenario. A Cisco router is configured to provide DHCP functionality as follows:

  • Router(config)# ip dhcp excluded-address 172.16.1.1 172.16.1.3
  • Router(config)# ip dhcp pool DATA
  • Router(config-dhcp)#network 172.16.1.0 255.255.255.0
  • Router(config-dhcp)#dns-server 172.16.1.1 172.16.1.21
  • Router(config-dhcp)#default-router 172.16.1.1
  • Router(config-dhcp)#lease 7

Based on the above configuration let’s see the messages exchanged as captured from Ethereal application. A screen shot of the messages can be seen below:

configure-dhcp-cisco-2

Details on the DHCP Offer message sent by the Cisco router can be seen below. Make a note of the client’s offered IP address (172.16.1.5), option 3 – default router’s address, option 51- IP address lease time, option 6 – IP addresses of DNS servers.

configure-dhcp-cisco-3

Cisco IOS Router Acting as a DHCP Client

A Cisco router can be configured to act as DHCP client and obtain dynamically an interface address by using the command ip address dhcp in interface configuration mode. Issuing this command causes the router to transmit DHCP Discover messages on the specific interface.

Cisco IOS Router Acting as a DHCP Relay Agent

By default routers do not forward broadcasts. In internetworks, most of the times, a DHCP server is located on a different network than the majority of its clients.

For DHCP messages to be able to reach the server, configuration of IP helper addresses is required. IP helper address [DHCP server IP address] interface command instructs a router to intercept DHCP broadcast messages and forward them as unicasts to the DHCP server hence providing “relay” functionality.

DHCP relay agents provide extra security to the network by hiding the server’s IP address from the clients. The client knows only the IP address of the relay agent.

The image below shows a common scenario where IP helper address is required.

configure-dhcp-cisco-4

The next image shows an IP DHCP Offer message as received on the client.

Note the IP address of the relay agent specified in the message. The client with the help of IP helper address on the relay agent is able to receive its IP address and all other information options provided.

configure-dhcp-cisco-5

Telecom companies use the services provided by DHCP relay agents extensively. Specifically the ip dhcp relay information option global configuration command which enables the DHCP relay agent to include information about itself to the DHCP requests sent from clients to DHCP server.

This is very useful for telecom operators when ATM routed bridge encapsulation (RBE) is used so that ATM interface and PVC over which the DHCP request came in is transmitted to the server from the relay agent. This information can be used to authenticate the client and help the DHCP server to apply the appropriate policy decisions.

The image below shows schematically the DHCP relay information option concept.

configure-dhcp-cisco-6

Summary

  • DHCP functionality can be reliably configured on Cisco IOS devices. Cisco devices can be configured to act as DHCP servers, DHCP clients, or DHCP relay agents or even a combination of these.
  • DHCP options like DNS servers, Domain name, lease time, etc. can be configured on Cisco devices.
  • IP helper address activates the DHCP relay agent functionality on Cisco devices.
  • DHCP relay agent options can be activated on Cisco devices so that supplementary services such as RBE functionality could be effective.

Quelle: http://www.trainsignal.com/blog/cisco-dhcp

 

Veröffentlicht unter CCNA | Verschlagwortet mit

Wiederherstellung Cisco IOS mit Xmodem

Solltet ihr bei eurem Router/Switch das IOS zerschossen haben, oder den Flash gelöscht haben, wir das Gerät nicht mehr starten. Damit das Gerät wieder ein IOS laden kann, muss wieder eins in den Flash geladen werden. Als erstes solltet ihr ein ordentliches Terminalprogramm herunterladen. Ich empfehle TeraTerm (Download). Mit “show flash” könnt ihr euch den Inhalt des Flash-Speichers anzeigen lassen. Das geht natürlich nur wenn noch ein IOS drauf ist, wie in meinem Fall. Ich lösche jetzt meinen Flash mit “erase flash:”. imageNach einem Neustart des Routers findet er kein IOS mehr. Es erscheint eine Fehlermeldung “boot: cannot open flash:”. Mit der Eingabe von “confreg” erscheint die Konfigurationszusammenfassung. Wir ändern nur die “Boud rate” damit wir das Image schneller kopieren können. Anschließend tippen wir “reset” um die neue Konsoleneinstellung zu laden. Jetzt über TeraTerm “Einstellungen/Seriellen Port einrichten” die Boud rate anpassen.image

Im nächsten Schritt sagen wir welches Cisco IOS er laden soll. In meinem Fall “xmodem c2600-ipbase-mz.123-9b.bin”. Nachdem wir das eingegeben haben werden wir gefragt “ Do you wish to continue?” wir bestätigen das mit Y. Jetzt müssen wir das IO-Image noch mit TeraTerm an den Router senden. Über “Datei/Transfer/Xmodem/Senden” wählen wir das IOS-Image aus. Das kopieren dauert etwas.

Nach einem Neustart lädt der Router/Switch das eingespielte IOS. Wichtig ist, dass ihr die Boud rate wieder auf 9600 zurück setzt.
Router(config)#line con 0
Router(config-line)# speed 9600
Router(config-line)# exit

Überprüfen könnt Ihr die IOS-Version mit “show version”

Bei einem Switch ist der Ablauf etwas anders. Den “Mode” Knoopf gedrückt halten und den Switch an Strom anschliessen, Knopf gedrückt halten.

switch: flash_init (Falsh initialisieren)
switch: BAUD 115200 (Baud-Rate erhöhen)
switch: copy xmodem: flash:c2960-lanbasek9-mz.122-55.SE1.bin (Mit xmodem über Terminalprog. senden)
switch: set BOOT flash:c2960-lanbasek9-mz.122-55.SE1.bin (Boot-Parameter anpassen)
switch: set BAUD 9600 (Baud-Rate wie auf Standard)
switch: boot (IOS booten)

Quelle: http://www.r33net.de/wiederherstellung-cisco-ios-mit-xmodem/