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/

Subnetting (CIDR und VLSM)

Einführung in Subnetting / IP-Berechnung

=========================================

Anfangs noch ein paar Übungsbeispiele unter: http://www.eex-online.de/informatik.html

Das Dokument zum herunterladen: Einführung in Subnetting

Rechner im Internet werden über IP-Adressen angesprochen, die eindeutig sind.

Eine IP-Adresse (IP) ist eine 32-bit-Zahl und enthält sowohl die Netzkennung als auch die Hostkennung eines Rechners.

In der kürzeren Dezimalschreibweise sieht eine IP zum Beispiel aus wie „192.168.0.1„, jede der 4 durch Punkte getrennten Zahlen repräsentiert eine 8bit-Binärzahl.

Sie wird auch als Oktett bezeichnet und kann Werte zwischen 0 (binär 00000000) und 255

(binär 11111111) annehmen.

Die zur IP gehörende Subnetmaske (ebenfalls 32bit) gibt an, welcher Teil der IP Hostkennung und welcher Netzkennung ist. Sie ermöglicht die Teilung eines Gesamtnetzes in mehrere kleinere Teilnetze.

Am besten ist dies in der Binärdarstellung der Netmask zu sehen :

Die Netzkennung ist (von links nach rechts betrachtet) der Teil der IP, bei dem die Bits der Netmask 1 sind.

Als Beispiel betrachten wir die häufig in privaten LANs genutzte IP 192.168.0.1 mit einer typischen Subnetzmaske von 255.255.255.0.

//Darstellung 1 : Dezimal- und Binärschreibweise von Subnetzmasken

IP(dez)  :        192                    168                  0                       1

SNM(dez) :     255                   255                  255                   0

SNM(bin) :     11111111        11111111       11111111        00000000

|<——– Netzkennung ——————->|      |<– Hostkennung –>|

Wie anhand der Darstellung zu sehen ist, befindet sich der Host im Subnetz 192.168.0. und

ist hat die erste Hostadresse in diesem Netz.

Da eine Subnetzmaske definiert, wie viele Bits zur Adressierung des Hosts, und wie viel zur

Adressierung des Netzes zur Verfügung stehen, legt sie die maximale Anzahl der Hosts und Netze

Fest.

Je mehr Bits für die Hostkennung verwendet werden, desto weniger stehen für die

Netzkennung zur Verfügung. Der gesamte IP4-Adressraum ist zwar relativ gross, aber begrenzt.

 

Auch die CIDR-Darstellung der Netzwerkmaske lässt sich an obiger Darstellung gut illustrieren.

Es handelt sich hierbei um eine Kurzdarstellung der Netzmaske, die die Anzahl der auf 1 gesetzten

Bits in der Subnetzmaske angibt. Ihr wird meist ein Slash („/“) vorangesetzt, so dass man an Stelle

unserer Darstellung

„IP : 192.168.0.1, SNM : 255.255.255.0“

in CIDR-Schreibweise auch „192.168.0.1/24“ schreiben kann. Dies gibt an, das die Subnetzmaske

24 Bits hat, die auf 1 gesetzt sind (siehe Darstellung 1).

 

Früher teilte man die IP-Adressen in Klassen ein, je nach Subnetzmaske. Gebräuchlich waren

die Subnetzmasken 255.0.0.0 („Klasse-A-Netze„), 255.255.0.0 („Klasse-B-Netze„) und

255.255.255.0 („Klasse-C-Netze„). Unsere IP 192.168.0.1/24 wäre also ein Rechner in einem

Klasse-C-Netz.

Man Beachte: Es spricht nichts dagegen, Subnetzmasken wie /21 oder /7 zu benutzen, bei denen

die Trennung von Host- und Netzteil in dezimaler Schreibweise nicht zwischen

den einzelnen Oktetten liegt. Dies war aber damals nicht notwendig und daher nicht vorgesehen. Lediglich /8, /16 und   /24 Netze (also Klasse A,B, und C) waren in Benutzung, man spricht daher von diesem Schema als klassenbasierte IP-Adressierung.

Man teile die das Internets also in Klasse A, B, und C-Netze auf und definierte

Adressbereiche für die einzelnen Netztypen :

klassenbasierte IP-Adressierung

Adressklasse Netzbits Hostbits Adressbereich* Anzahl Netze Anzahl Hosts Subnetmask
A 8 24 0- 126 126 16777216 255.0.0.0
B 16 16 128- 191 16384 65536 255.255.0.0
C 24 8 192- 223 2097152 256 255.255.255.0

 

* erstes Oktett der IP in Dezimalschreibweise

Man Beachte : Es spricht ebenfalls nichts dagegen, dass ein Rechner die Adresse

IP : 10.11.12.12 SNM : 255.255.255.0 besitzt, obwohl das erste Oktett der Definition nach ein Klasse A Netz sein sollte und somit eine SNM von 255.0.0.0 habe sollte. Dies widerspricht lediglich der damaligen Definition, ist aber möglich.

Beim Betrachten von Tabelle 1 ist auffällig, dass einige Adressbereiche nicht aufgeführt sind.

Diese Bereiche sind für besondere Aufgaben reserviert. Siehe dazu Anhang B.

Jeder, der öffentliche IP-Adressen benötigte, bekam ein (oder auch mehrere) Adressbereiche zugeteilt – je nach Bedarf an IP-Adressen ein Class-A, -B oder -C-Netz. Bald wurden die ~ 4 Milliarden IP-Adressen knapp, und es wurden Massnahmen zur Bekämpfung des Mangels eingeführt.

NAT (network address translation, Nutzung einer gemeinsamen öffentlichen IP durch viele Rechner

mit privaten IPs hinter einem Router) und die klassenlose IP-Adressierung das Ergebnis.

Man bezeichnet häufig Subnetze, die keine der SNMs von /8, /16 oder /24 haben, als klassenlose

Subnetze. Durch klassenlose Adressierung lässt sich die Anzahl der maximalen Hosts pro Subnetz

besser dosieren, weniger IP-Verschwendung ist die Folge.

Hinweis:

Eine längerfristige Lösung war die Einführung von IPv6, das die Adresslänge von 32 auf 128 Bit erhöht, und damit natürlich die Anzahl der zur Verfügung stehenden IP-Adressen dramatisch erhöht.

Bis heute ist aber IPv4 die mit Abstand am weitesten Verbreitete Adressierungsmethode, IPv6-Testnetze existieren aber seit geraumer Zeit, erste Produktionsumgebungen mit IPv6 bestehen ebenfalls.

Berechnen von Subnetzeigenschaften – kommentierte Beispiele

============================================================

Beispiel 1:

Gegeben sind eine IP und die dazugehörige Subnetzmaske in Dezimalschreibweise. Berechnen Sie die Netzwerkadresse des zugehörigen Subnetzes, dessen Broadcast-Adresse und die Anzahl  der Hosts, die maximal in diesem Subnetz untergebracht werden können.

Gegeben:    IP 113.8.66.42, Netmask 255.255.255.240

Schritt 1 -Umwandlung der dezimalen Netmask in CIDR-Schreibweise

Die dezimale Darstellung der Netmask ( hier z.B. 255.255.255.240) ist dem Verständnis

der CIDR-Schreibweise eher hinderlich. Also wird die SNM zuerst in binary umgewandelt,

daraus kann man die CIDR einfach ablesen:

dezimal         255             255             255              240

bin             11111111   11111111   11111111   11110000

Anzahl Bits 1 :     8      +    8                  +    8            +    4      =    28

CIDR            /28      –>            Die CIDR ist folglich 28.

 

Schritt 2 –maximale Anzahl Hosts pro Subnetz bestimmen

Mit Hilfe der CIDR kann die maximale Anzahl von Hosts berechnet werden, die in jedem             einzelnen der entstehenden Subnetzte untergebracht werden können :

Eine IP-Adresse hat 32 Bit, eine CIDR von 28 bedeutet, dass 28 Bit davon Netzkennung sind.

Folglich bleiben 4 Bit für die Hostkennung übrig. Wir könnten also theoretisch 2^4 Hosts pro Subnetz unterbringen. Die erste IP des Subnetzes ist jedoch als Netzwerkadresse des Subnetzes selbst reserviert, die letzte IP eines Subnetzes dient den Hosts des Subnetztes als Broadcast-Adresse. Daher müssen diese beiden Adressen von der theoretisch maximalen Anzahl subtrahiert werden.

Es ergibt sich in unserem Fall:

32 – 28 = 4          /* (Anzahl der Bits der IP-Adresse) – (CIDR) = (Anzahl Bits der Hostkennung) */

2^4 = 16             /* 2 hoch (Anzahl Bits der Hostkennung) = theoretische Maximalanzahl der Hosts */

16 – 2 = 14          /* 2 subtrahieren wegen Netzkennung und Broadcast */

Man kann folglich 14 Hosts pro Subnetz adressieren.

Schritt 3- Netzadresse des Gesamtnetzes bestimmen, in dem sich die IP befindet.

Die in Schritt 1 bestimmte CIDR zeigt, dass die von links gesehen ersten 28 Bit der IP-Adresse die Netzkennung sind und die von rechts gesehen ersten 4 Bit die Hostkennunng.

Das Umwandeln der IP in das Binärsystem ergibt folgendes:

IP (dezimal):     113.                    8.          66.           42

IP (binary):     01110001      00001000    01000010     00101010

Um die Netzwerkadresse zu bestimmen, beachten wir nur den Teil der IP, bei dem die SNM auf 1 gesetzt ist :

    SNM (binary):    11111111      11111111    11111111     11110000

Die Netzkennung lautet folglich in binary :

01110001      00001000    01000010     00100000

Beachten Sie, dass die letzten 4 Bits Null sind, da die Subnetzmaske  an diesen Stellen 0 ist, und diese Zahlen folglich nicht zur Netzkennung, sondern zur Hostkennung gehören!

Das Umwandeln ins Dezimalsystem ergibt:

113.         8.           66.          32

Folglich ist die Netzkennung 113.8.66.32.

Wenn man nun prüfen, will ob zwei IP Adresse im gleichen Subnetz sind, so muss man einfach die jeweilige IP Adresse binär mit der Subnetmask binär AND verknüpfen. Wenn beides mal das gleiche raus kommt-> so sind sie im gleichen Netz.

Schritt 4 – Bestimmen der Schrittweite der einzelnen Subnetze

Zuerst ist das erste Oktett der Subnetzmaske  zu bestimmen, dass nicht komplett aus Bits besteht, die auf 1 gesetzt sind. In der Dezimalschreibweise also von links nach rechts das erste Oktett, dass nicht 255 lautet.

In unserem Fall ist es das vierte Oktett, es lautet ‚240‘.

256 – 240 = 16

Die Schrittweite ist also 16.

Schritt 5 – Bestimmen der Start- und End-IP-Adressen der einzelnen Subnetze sowie deren Broadcast

Die Netzkennung des ersten Subnetzes lautet 113.8.66.32 (siehe Schritt 3).

Es wird nun das erste Oktett der IP benötigt, in dem die Hostkennung beginnt (also das von links gesehen erste, in dem die Subnetzmaske nicht 255 lautet). Dies ist in unserem Fall das vierte Oktett.

Nur dieses betrachten wir im Folgenden :

Die Netzkennung des ersten Subnetztes lautet im vierten Oktett 32, da die Schrittweite 16 beträgt (siehe Schritt 4), beginnt das nächste Subnetz bei 48, das darauf folgende bei 64, und so weiter.

Daraus ergeben sich die IP-Adressen in den jeweiligen Subnetzen – sie liegen zwischen den Netzkennungen der SUbnetze. Die Broadcastadresse ist jeweils die letzte IP vor der Netzkennung des nächsten Subnetztes. Es ergibt sich in unserem Fall:

Subnetz 1

Netzkennung:                  113.8.66.32

IP-Bereich:                        113.8.66.33 – 113.8.66.46

Broadcastadresse:          113.8.66.47

Subnetz 2

Netzkennung:                  113.8.66.48

IP-Bereich:                        113.8.66.49 – 113.8.66.62

Broadcastadresse:          113.8.66.63

Subnetz 3

Netzkennung:                  113.8.66.64

IP-Bereich:                        113.8.66.65 – 113.8.66.78

Broadcastadresse:          113.8.66.79

.

und so weiter

Damit sind wir fertig. Unser Host mit der IP 113.8.66.42 liegt im Subnetz 1, die weiteren Subnetze hätten wir nicht berechnen müssen, zur Verdeutlichung ist es hier aber geschehen.

Anhang

=======

Anhang A – Potenzen von 2 in dezimal und binary

————————————————

Das flüssige Rechnen mit Potenzen von 2 im binären Zahlensystem ist für IP- und Subnetzberechnungen sehr hilfreich. Die folgenden Werte sollten bekannt sein.

2^7 2^6 2^5 2^4 2^3 2^2 2^1 2^0
dezimal 128 64 32 16 8 4 2 1
binary 10000000 01000000 00100000 00010000 00001000 00000100 00000010 00000001
Addiert 128 192 224 240 248 252 254 255
Addiert 10000000 11000000 11100000 11110000 11111000 11111100 11111110 11111111

Anhang B – für besondere Aufgaben reservierte Adressbereiche

————————————————————-

1. loopback – 127.0.0.1

Das gesammte Netz mit der Kennung 127.0.0.0 ist nicht verfügbar, da 127.0.0.1 als sogenannte Loopback-Adresse definiert ist – jeder Rechner kann sich selbst unter dieser Adresse ansprechen und löst diese meist in den DNS-Namen ‚localhost‘ auf.

2. private IP-Bereiche

Als privat definierte Adressbereiche werden im Internet nicht geroutet und können somit problemlos von jedem in privaten Netzwerken verwendet werden, ohne sich um die Beschaffung einer öffentlichen IP kümmern zu müssen.

Hinweis:

Rechner mit IPs aus diesen Adressbereichen können nur über Router, die NAT ausführen, ans Internet angeschlossen                werden.

Folgende Adressbereiche sind als privat definiert :

10.0.0.0                bis          10.255.255.255      ( Class A )

172.16.0.0           bis          172.31.255.255      ( Class B )

192.168.0.0         bis         192.168.255.255    ( Class C )

3. diverse für Testzwecke reservierte Adressbereiche

Quellen

http://it.rcmd.org/networks/subnetting/subnetting.txt