|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
|
|
Due to the volume of material all information about Solaris IP configuration is now moved to network configuration page.
|
|
While Solaris systems are capable of operating in an isolated, non-networked environment, Solaris is a strongly network-oriented operating system. It provides the following tools to support networking, both between hosts on a local area network and to the worldwide Internet:
A typical Solaris local area network will contain one or more servers, which provide network services to local clients. These clients can be other Solaris systems, but are just as likely to be Linux, Microsoft Windows, or other Unix systems. In some network designs, each major service is located on its own system, to prevent downtime on one system from disabling access to all services. This brand of server role diversification is taken one step further by the E10000 system, which can be logically partitioned to form 64 independent virtual servers, all physically located on the same machine. Thus, if one domain is taken offline for service, other domains are unaffected.
The numbers and types of services provided on a Solaris local area network are virtually endless, but a typical configuration would include the following service types:
Solaris provides the following services that implement these service types:
Once a server setup has been decided for the local area network, a number of other issues, such as assigning IP address ranges to individual subnets and IP addresses to individual hosts, must be addressed. (Details of how to assign these addresses are provided in Chapter 2.) A modern network is generally connected using 10/100M Ethernet cabling, where hosts on the same subnet are ultimately connected to a single router via a switch or a hub. Figure 4-2 shows a single local network, with the hosts chardon, blanc, riesling, and semillon connected via a central switch. If all hosts are cabled with 100M ethernet cable, all traffic on the network is transmitted at the 100M rate. Mixed mode cabling and packet transmission rates can be problematic and, since most Solaris network interface cards now support 100M, standardizing on this rate is preferable. This simple network has no gateway, does not connect to other networks or to the Internet, and does not require a router.
If a connection to another network is required, the switch may be connected through to a router.
This enables all packets to be passed from chardon, blanc, riesling, and semillon to the switch, and through to the "internal" interface of the router. Alternatively, one of the hosts, such as chardon, may have a modem attached to one of its serial ports, through which an Internet connection is established. If blanc, riesling, and semillon wish to have direct Internet access, without telneting to chardon, they have to register chardon as their gateway. The switch would ensure that the packets were delivered to the correct gateway.
In addition, multiple hubs and switches may be daisy-chained to connect remote rooms, floors, or buildings to the same network. No more than three "hops" should exist between a router and its remotest client; otherwise, the number of packet collisions will become unacceptably high.
Most sites start with a Class C network, then begin to host multiple Class C networks, which must be connected using a router. Before we examine how to install and configure a router, let's look at the configuration of individual network interfaces more closely.
Although the various Solaris installation programs will happily configure built-in network interfaces at installation, there are several situations where you may need to add another interface or modify the configuration of the existing interfaces. These situations include:
In order to enable a network interface under Solaris, several steps may be necessary. These include:
Device drivers are typically stored in /kernel/drv (or as defined in /etc/system) and listed in /etc/device_aliases. For example, the standard quad ethernet connector supplied by Sun has the driver /kernel/drv/qfe, and has its alias listed in /etc/device_aliases as qfe SUNW,qfe. Rebooting with the following command forces a reconfiguration reboot:
# touch /reconfigure; init 6Alternatively, from the OpenBoot PROM monitor, the following command can be used to force a reconfiguration boot:
OK boot -rAn IP address is assigned to the interface by inserting the IP address into a hostname file, located in the /etc directory. For a system with a single interface (e.g., /dev/eri0), such as the Blade 100, the hostname file is called hostname.eri0, where eri is the device name and 0 is the interface number.
Alternatively, a quad ethernet card (with devices
/dev/qfe0, /dev/qfe1,
/dev/qfe2, and
/dev/qfe3) would have four hostname files containing distinct
IP addresses: hostname.qfe0, hostname.qfe1,
hostname.qfe2, and hostname.qfe3.
These may be allocated sequentially, such as 192.64.18.1,
192.64.18.2, 192.64.18.3,
and 192.64.18.4, if the host is multi-homed, or distinctly,
where the system acts as a router rather than a multi-homed host.
A mulit-homed host allows data to be exchanged only on the local area network (including with the router defined for that network), while a router is responsible for conveying packets between networks. To prevent routing, a multi-homed host must touch the file /etc/notrouter. In addition, the default router for the local network should have its IP address inserted into the file /etc/defaultrouter.
You can create a hosts entry for each interface in the /etc/hosts file or by inserting a record into whatever distributed naming service is mandated by /etc/nsswitch.conf. For example, if the IP address contained in hostname.qfe0, hostname.qfe1, hostname.qfe2, and hostname.qfe3 were to be mapped to the hostnames www1, www2, www3, and www4, the /etc/hosts file would contain the following entries:
# cat /etc/hostswww1 192.64.18.1www2 192.64.18.2www3 192.64.18.3www4 192.64.18.4
Alternatively, if DNS is being used, the following entries would need to be made in the appropriate zone file:
www1 IN A 192.64.18.1 ;webserverwww2 IN A 192.64.18.2 ;webserverwww3 IN A 192.64.18.3 ;webserverwww4 IN A 192.64.18.4 ;webserver
The ifconfig command is used to plumb and configure each interface, so that it can pass and receive IP traffic. Once the interface has been enabled, the ifconfig command can be used to view all active interfaces:
# /usr/sbin/ifconfig -alo0: flags=1000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4> mtu 8232 index 1inet 127.0.0.1 netmask ff000000eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2inet 10.64.18.3 netmask ffffff00 broadcast 10.64.18.255lo0: flags=2000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6> mtu 8252 index 1inet6 ::1/128eri0: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2inet6 fe80::203:baff:fe04:a4e8/10
If an interface is configured incorrectly, the following error message will be displayed for each interface that is checked individually using ifconfig:
# ifconfig eri0ifconfig: status: SIOCGLIFFLAGS: eri0: no such interface
Assuming that the eri0 device is installed correctly, with the appropriate device drivers, the following ifconfig command should configure the device at the hardware level:
# /usr/sbin/ifconfig eri0 plumb
Once the device is plumbed, its runtime parameters, such as its IP address, can also be configured by using the ifconfig command:
# /usr/sbin/ifconfig eri0 10.64.18.3 broadcast 10.64.18.255 netmask 255.255.255.0
To bring up the interface, the up keyword must be used:
# /usr/sbin/ifconfig eri0 upAll of these individual commands can be combined into the following command, which configures the hardware, sets all parameters, and brings up the interface:
# /usr/sbin/ifconfig eri0 10.64.18.3 broadcast 10.64.18.255 netmask 255.255.255.0 plumb up
Depending on your local network configuration, it might be appropriate to create a point-to-point connection, rather than the previous generic connection. For example, if we want to restrict access to a secure database system, we might create a point-to-point connection that allows access to the database from only the host to which it is directly connected.
In order to determine whether the interfaces are being addressed correctly by other hosts on the local network, use the arp command to display all active connections between the localhost and other hosts:
# /usr/sbin/arp -aNet to Media Table: IPv4Device IP Address Mask Flags Phys Addr------ -------------------- --------------- ----- ---------------eri0 hp 255.255.255.255 00:50:ba:13:08:18eri0 austin 255.255.255.255 SP 00:03:ba:04:a4:e8eri0 224.0.0.0 240.0.0.0 SM 01:00:5e:00:00:00
This displays the ethernet address to IP address mapping for the local host. The flags displayed include:
Finally, it may be necessary to set some protocol transmission parameters manually to achieve optimal performance. Use the ndd command to set parameters for TCP, UDP, ARP, and IP. In addition, ndd can be used to display the list of all current parameter values relating to a specific protocol. For example, to display the parameters currently associated with TCP, use the following command:
# ndd /dev/tcp Once all network interfaces are configured as required, use the netstat command, which is responsible for gathering network statistics of various types, to verify their operational status. This data is gathered by using the interfaces on the local host.
netstat is able to gather statistics for the following types of data:
In the following sections, we'll review each of these data gathering operations and discuss how each is used to aid in troubleshooting and pinpointing performance issues.
The per-protocol statistics can be divided into several categories:
|
|
|
|
|
|
|
|
Each packet type has a specific set of measures associated with it. For example, RAWIP packets have counters that check the number of input (rawipInDatagrams) and output (rawipOutDatagrams) datagrams received since boot. UDP has a corrsponding set of counters that measure the number of input (udpInDatagrams) and output (udpOutDatagrams) datagrams received since boot. In addition to counters of normal events, netstat reports on error events, such as the number of UDP input (udpInErrors) and the number of UDP output (udpOutErrors) errors. These values should be monitored regularly to ensure that the ratio of error to normal conditions does not increase over time. For example, there are 293 tcpActiveOpens shown in the following listing, compared to only one tcpAttemptFails event. If the ratio of tcpAttemptFails to tcpActiveOpens increases over time for TCP traffic, the appropriate TCP parameters may need to be modified by using ndd, or a network error may need to be diagnosed. Here's a representative set of examples for understanding per-protocol errors for IPv6.
$ netstat -s
The per-address statistics can be divided into three categories:
The multicast statistics option provides an overview of interfaces
that are currently listening for multicast broadcasts on the
224.0.0.1 (ALL_HOSTS) address. This is so that packets
can be routed appropriately using the router discovery daemon (in.rdisc),
discussed in the next section, "Routing."
In the following example, both the IPv4 and IPv6 multicast groups are displayed:
$ netstat -gGroup Memberships: IPv4Interface Group RefCnt--------- -------------------- ------lo0 224.0.0.1 1eri0 224.0.0.1 1Group Memberships: IPv6If Group RefCnt----- ------------------------ ------lo0 ff02::1:ff00:1 1lo0 ff02::1 1eri0 ff02::202 1eri0 ff02::1:ff04:a4e8 1eri0 ff02::1 2
The kernel maintains a table of routes, constructed by the routing daemon, in.routed. The various routes that have been configured are always viewable by checking the routing statistics:
$ netstat -rRouting Table: IPv4Destination Gateway Flags Ref Use Interface-------------------- -------------------- ----- ----- ------ ---------10.64.18.0 austin U 1 5 eri0224.0.0.0 austin U 1 0 eri0localhost localhost UH 25 215051 lo0
Here, we can see there are two network routes available for packets
on the primary Ethernet interface eri0: the
10.64.18.0 network and the 224.0.0.0
multicast network. In addition, the loopback interface (lo0)
has the local host interface, which is commonly used for troubleshooting and testing.
These routes are all IPv4; however, IPv6 routing details are also displayed:
Routing Table: IPv6Destination/Mask Gateway Flags Ref Use If--------------------------- --------------------------- ----- --- ------ -----fe80::/10 fe80::203:baff:fe04:a4e8 U 1 0 eri0ff00::/8 fe80::203:baff:fe04:a4e8 U 1 0 eri0default fe80::203:baff:fe04:a4e8 U 1 0 eri0localhost localhost UH 5 28 lo0
STREAMS is a System V package that provides access to system calls, standard libraries, and the kernel for the purposes of writing network applications. Any application that uses STREAMS has a specific set of properties about which statistics can be collected, since the I/O operations are distinct from other networking APIs (such as the BSD-style socket API). netstat reports these statistics, including queues, which comprise the read/write operations that characterize a stream:
$ netstat -mstreams allocation:cumulative allocationcurrent maximum total failuresstreams 326 340 7634 0queues 938 962 18662 0mblk 1144 1651 7773 0dblk 1140 1729 2349590 0linkblk 11 169 18 0strevent 9 169 121739 0syncq 25 50 101 0qband 0 0 0 01646 Kbytes allocated for streams data
More details can be obtained by reading the manpage for streamio.
netstat also reports statistics obtained at the IP level. This includes the number of input and output packets counted, the number of input and output errors, and the number of packet collisions. Again, separate entries are shown for IPv4 and IPv6:
$ netstat -iName Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queuelo0 8232 loopback localhost 227695 0 227695 0 0 0eri0 1500 austin austin 2573 0 2130 0 0 0Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collislo0 8252 localhost localhost 227705 0 227705 0 0eri0 1500 fe80::203:baff:fe04:a4e8/10 fe80::203:baff:fe04:a4e8 2573 02130 0 0
Most administrators prefer to combine the information that netstat provides into a single report-style format. This can be achieved by using the combined route, socket, and interface statistics, as shown in the output in Example 4-1.
Example 4-1: Output of the netstat-a command
$ netstat -aUDP: IPv4Local Address Remote Address State-------------------- -------------------- -------*.route Idle*.* Unbound*.* Unbound*.sunrpc Idle*.* Unbound*.32771 Idle*.sunrpc Idle*.* Unbound*.32775 Idle*.32779 Idle*.32780 IdleRouting*.* Unbound*.32821 Idle*.32822 Idle*.32823 Idle*.name Idle*.biff Idle*.talk Idle*.time Idle*.echo IdleUDP: IPv6Local Address Remote Address StateIf--------------------------------- --------------------------------- ---------- -----*.* Unbound*.sunrpc Idle*.* Unbound*.32771 Idle*.32779 Idle*.* Unbound*.32821 Idle*.time IdleTCP: IPv4Local Address Remote Address Swind Send-Q Rwind Recv-Q State-------------------- -------------------- ----- ------ ----- ------ -------*.* *.* 0 0 24576 0 IDLE*.sunrpc *.* 0 0 24576 0 LISTEN*.* *.* 0 0 24576 0 IDLE*.sunrpc *.* 0 0 24576 0 LISTEN*.* *.* 0 0 24576 0 IDLE*.32775 *.* 0 0 24576 0 LISTEN*.32776 *.* 0 0 24576 0 LISTEN*.32782 *.* 0 0 24576 0 LISTEN*.32783 *.* 0 0 24576 0 LISTENTCP: IPv6Local Address Remote Address Swind Send-Q Rwind Recv-Q State If*.* *.* 0 24576 0 IDLE*.sunrpc *.* 0 0 24576 0 LISTEN*.* *.* 0 0 24576 0 IDLE*.32775 *.* 0 0 24576 0 LISTENlocalhost.32780 localhost.32775 32768 0 32768 0 CLOSE_WAIT*.32782 *.* 0 0 24576 0 LISTEN*.32791 *.* 0 0 24576 0 LISTEN*.ftp *.* 0 0 24576 0 LISTEN*.telnet *.* 0 0 24576 0 LISTENActive UNIX domain socketsAddress Type Vnode Conn Local Addr Remote Addr30000d03738 stream-ord 30000d1eb78 00000000 /tmp/.X11-unix/X030000d038e0 stream-ord 00000000 0000000030000d03a88 stream-ord 30000ce4a30 00000000 /tmp/jd_sockV630000d03c30 stream-ord 30000a62d78 00000000 /dev/kkcv30000d03dd8 stream-ord 30000a62f50 00000000 /dev/ccv
Some of the TCP messages shown in this output, for both IPv4 and IPv6, may be unfamiliar:
|
Message |
Description |
|---|---|
|
BOUND |
Socket is bound. |
|
CLOSED |
Socket is closed. |
|
CLOSING |
Socket is closing. |
|
CLOSE_WAIT |
Socket is waiting to close. |
|
ESTABLISHED |
Socket has connected successfully. |
|
FIN_WAIT_1 |
Socket is closing (local). |
|
FIN_WAIT_2 |
Socket is closing (remote). |
|
IDLE |
Socket is idle. |
|
LAST_ACK |
Socket will close after receiving last acknowledgment. |
|
LISTEN |
Socket is active and listening. |
|
SYN_RECEIVED |
Socket is being synchronized. |
|
SYN_SENT |
Socket is creating a connection. |
|
TIME_WAIT |
Socket is waiting to close. |
Imagine that you are a courier, and your run always starts at the local courier depot. You're given a list of addresses, which are associated with a set of packages, and your goal is to deliver them in as little time as possible, subject to the following constraints:
If this seems like a fairly trivial task for a courier, consider how much more difficult the job would be if the following conditions prevailed:
This scenario describes the difficulties faced by the emergence of the Internet and the massive interconnections between hosts and networks. In order for a packet of data to be transferred from host A to host B, a physical path must be identified for the packet to travel.
There is no central lookup service that decides how to route each packet between all possible combinations of two hosts on the Internet (i.e., between the sender and the receiver). This means routes must be generated dynamically. (The only exceptions to this rule are certain situations where a predictable static route may be installed.)
When transferring data around the Internet or between subnets, intermediate hosts must be responsible for transferring packets between networks; these hosts are called routers and are responsible for routing packets between hosts, which can be separated by single subnets or by entire continents. To gain insight into how many routers a packet transfer may involve, let's use the traceroute command to display the "hops" required to connect from a host in Sydney, Australia, to the Sun Microsystems web server:
$ traceroute wwwwseast.usec.sun.com/Tracing route to wwwseast.usec.sun.com [192.9.49.30]over a maximum of 30 hops:1 184 ms 142 ms 138 ms 202.10.4.1312 147 ms 144 ms 138 ms 202.10.4.1293 150 ms 142 ms 144 ms 202.10.1.734 150 ms 144 ms 141 ms atm11-0-0-11.ia4.optus.net.au [202.139.32.17]5 148 ms 143 ms 139 ms 202.139.1.1976 490 ms 489 ms 474 ms hssi9-0-0.sf1.optus.net.au [192.65.89.246]7 526 ms 480 ms 485 ms g-sfd-br-02-f12-0.gn.cwix.net [207.124.109.57]8 494 ms 482 ms 485 ms core7-hssi6-0-0.SanFrancisco.cw.net [204.70.10.9]9 483 ms 489 ms 484 ms corerouter2.SanFrancisco.cw.net [204.70.9.132]10 557 ms 552 ms 561 ms xcore3.Boston.cw.net [204.70.150.81]11 566 ms 572 ms 554 ms sun-micro-system.Boston.cw.net [204.70.179.102]12 577 ms 574 ms 558 ms wwwwseast.usec.sun.com [192.9.49.30]Trace complete.
Here, we can see that some 12 hosts are required to transfer packets between the sender and the receiver. In addition, the observed response times can be quite slow--often more than half a second. It is possible for attempted connections to time out. This can be very useful when trying to identify which intermediate host and/or network is having problems when your remote connection to a host half a world away suddenly dies!
In this section, we'll examine how Solaris solves a number of the classic routing problems.
Static routing typically involves creating a direct physical connection between two hosts, where the implementation of dynamic routing would be wasteful or a security risk. For example, if your local network has three subnets that need to share data, a static route could be created between each router and the other two routers in the network. The number of specific routes required to allow data to flow seamlessly between networks is directly proportional to the square of the number of routers on the network. Every time a change is made to the network topology, these routes will have to be modified manually. If that sounds like too much hard work, consider the situation where it might be desirable: a secure database server that can be accessible only by knowing the route to the host and is not publicly announced. Instead of permitting route discovery, a static route is an appropriate technique here. This could be implemented by creating a point-to-point configuration using ifconfig on a secondary interface, as discussed in the network interface configuration section.
The alternative to static routing is dynamic routing, which involves two daemons: the routing daemon proper (in.routed) and the route discovery daemon (in.rdisc). The in.routed daemon implements the Routing Information Protocol, and is responsible for updating and managing entries in the kernel's routing tables. It uses UDP (port 520) for performing routing operations and operates on all network interfaces that have been plumbed and are identified as up.
If the /etc/notrouter file does not exist, and given that two or more operational interfaces can be found, the host begins to act as a router. Data can then be exchanged between data received on one interface, destined to be transmitted from another interface. For a local area network, the interface that connects to all local hosts is usually known as the internal interface, while the interface that is visible downstream to an ISP or another subnet is known as the external interface. By using packet filtering, it is possible to specify a set of rules governing what type (TCP or UDP) of packets can be transferred between interfaces and on which ports. This is obviously important for protecting local networks, since services that are available to local hosts may not be appropriate for public access.
The route discovery daemon, in.rdisc,
implements the Internet Control Message Protocol (ICMP). In terms of route discovery,
in.rdisc running on host systems listens for multicast
broadcasts on the 224.0.0.1 (ALL_HOSTS) address. These
messages are prioritized, and the default router is selected based on its proximity
to the host. On routers, in.rdisc broadcasts its availability
using multicast on 224.0.0.1, and listens for requests
on 224.0.0.2 (ALL_ROUTERS). Hosts may request a router
directly by broadcasting on 224.0.0.2.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
Oct 23, 2019 | hardware.slashdot.org
Posted by EditorDavid on Sunday October 20, 2019 @02:34PM from the month-long-weekend-projects dept. Long-time Slashdot reader ttsiod works for the European Space Agency as an embedded software engineer. He writes: After reading an interesting article from an NVIDIA engineer about how he used a dirt-cheap field-programmable gate array board to code a real-time ray-tracer, I got my hands on the same board -- and "compiled" a dual-core SPARC-compatible CPU inside it... Basically, the same kind of design we fly in the European Space Agency's satellites.I decided to document the process , since there's not much material of that kind available. I hope it will be an interesting read for my fellow Slashdotters -- showcasing the trials and tribulations faced by those who prefer the Open-Source ways of doing things... Just read it and you'll see what I mean.
This is the same Slashdot reader who in 2016 reverse engineered his Android tablet so he could run a Debian chroot inside it. "Please remember that I am a software developer, not a HW one," his new essay warns."I simply enjoy fooling around with technology like this."
|
|
|
tutorial articles in this section describe TCP/IP and related protocols as sequence diagrams. (The sequence diagrams were generated using EventStudio System Designer 2.5).
[Dec 6, 2005] TCP-IP Stack Hardening
[Dec 6, 2005] Daryl's TCP-IP Primer Good and up-to-date primer...
[Mar 19, 2005] TCP-IP Protocol Sequence Diagrams
Articles in this section describe TCP/IP and related protocols as sequence diagrams.
(The sequence diagrams were generated using EventStudio).
WANdoc Open Source Perl=based
WANdoc Open Source is free software that generates interactive documentation for large Cisco networks. It uses syslog and router configuration files to produce summarized, hyperlinked, and error- checked router information. It speeds up the WAN troubleshooting process and identifies inconsistencies in router deployment.
SecuriTeam.com � (Archive) - Security News
Understanding
IP Addressing Everything You Ever Wanted To Know - By Chuck Semeria -- good
tutorial from 3COM. This white paper is now available
in the 3 pdf's below.
Pages 1 - 21
Pages 22 - 43
Pages 44 - 65
TCP/IP online books Free TCP/IP online books
AW � Professional - Networking Series Catalog Page Books from Addison Wesley, a respected name in technical publication.
Bill Stallings: Home Page Web Site for the Books of William Stallings
Douglas Comer This is the home page of Douglas Comer, the author of the book "Internetworking with TCP/IP".
Illustrated TCP/IP Online version of the book "Illustrated TCP/IP", by Matthew G. Naugle, published by Wiley Computer Publishing, John Wiley & Sons, Inc.
The Internet Companion Online version of the book "The Internet Companion". This book explains the basics of communication on the Internet and the applications available
Internetworking Multimedia This is a online book covering multimedia communication using the Internet
McGraw Hill Networking books A search on networking books published by McGraw Hill.
McGraw-Hill - Bet@ Books Free online prerelease versions of many new books on networking and other topics.
The Mechanics of Routing Protocols An online book published by Cisco Press.
The Network Book A comprehensive introduction to network and distributed computing technologies online
Network Reading List: TCP/IP,UNIX and Ethernet Compilation of links on the Internet relating to TCP/IP, Unix and Ethernet
Networking and Communications Prentice Hall Professional Technical Reference: Special Interests
Routing in the Internet A very comprehensive book on routing, written by Christian Huitema, from the Internet Architecture Board. A must read for those interested on routing protocols
Routing Information Protocols The Network Book, Chapter 3, Section 3. This document is part of the Network Book
TCP/IP and Data Communications Administration Guide An online book, in PDF format, explaining how to setup, maintain and expand a network using the Solaris implementation of the TCP/IP protocols
TCP/IP Network Administration, 2nd Edition Clearly written, this book is a good introduction to the TCP/IP protocols and practical applications.
Troubleshooting TCP/IP This is a sample chapter from the book "Windows NT TCP/IP Network Administration", published by OґReilly and associates which explains how to solve problems related to TCP/IP in a Windows NT environment
Understanding Networking Technologies Online course providing training on a host of networking topics.
Windows NT TCP/IP Network Administration O'Reilly publication covering TCP/IP and NT
Wireless Networking Handbook Online version of the book "Wireless Networking Handbook" by Jim Geier, and published by New Riders, Macmillan Computer Publishing
MCI Arms ISPs with Means to Counterattack Hackers
MCI Arms ISPs with Means to Counterattack Hackers [October 9] MCI introduced today a security product designed to help Internet Service Providers detect network intruders.
The networkMCI DoS (Denial of Service) Tracker constantly monitors the network and then once a denial of service attack has been detected, the product immediately works to trace the root of the attack.
The product is designed to eliminate the time technical engineers spend manually searching for the intrusion. MCI claims the product takes little programming knowledge to find the network intruder.
The DoS Tracker combats SYN, ICMP Flood, Bandwidth Saturation, and Concentrated Source, and the newly detected Smurf hacker attacks.
"Obviously, we can't guarantee the safety of other networks from all hacker activity, but we believe the networkMCI DoS Tracker provides ISPs and other network operators with a powerful tool that will help them protect their Internet assets," Rob Hagens, director of Internet Engineering.
The product is available for free from MCI's Web site.
| The Linux Network Administrators' Guide | FAME Computer Education TCPIP for Idiots Tutorial | RFC1180 | Introduction to the Internet Protocols |
Daryl's TCP-IP Primer Good and up-to-date primer...
Understanding IP addressing -- tutorial from 3Com
**** The Network Administrators' Guide -- the first several chapter contain good introduction to TCP/IP
Contents (fragment)
FAME Computer Education TCPIP for Idiots Tutorial
RFC1180 TCP/IP Tutorial by T. Socolofsky & C. Kale January 1991 (63 KBytes) -- old, but still decent is a tutorial (UK mirror RFC 1180)
TCP-IP and IPX Routing tutorial (mirror TCP-IP and IPX routing Tutorial )
Introduction to the Internet Protocols by Charles L. Hedrick. 3 July 1987 (Rutgers University). See also a mirror Introduction to TCPIP
Fast Guide to Subnets by Chuck Semeria (3Com)
Integrating Your Machine With the Network - good guide from USAIL
PC Magazine PC Tech (A Beginner's Guide to TCPIP)
An excellent collection of lecture notes at the University of Massachussetts. Detailed description of TCP and IP protocol design and implementation
Google matched content |
Internal
External
Useful links -- The Network Management Online Library
PC Connectivity - TCP-IP, Winsock & Dial-up Internet Access -- useful but outdated
Charm Net Personal IP Page -- a lot of useful links
TCP-IP, Index A GUIDE TO TCP/IP INTERNETWORKING
Integrating Your Machine With the Network - very good guide from USAIL
Doing remote computing by issuing commands through electronic mail
Old and broken links
***+ TCP-IP Tutorial and Technical Overview -- a pretty decent and up to date IBM Redbook PDF
Table of Contents (old version was in HTML, now only PDF is available from the IBM site)
Part 1. Architecture and Core Protocols
Part 2. Special Purpose Protocols and New Technologies
Part 3. Connection Protocols and Platform Implementations
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater�s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright � 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: June 13, 2021
