Wednesday, June 11, 2008

IPV6

INTRODUCTION

This specification defines the addressing architecture of the IP
Version 6 protocol. It includes a detailed description of the
currently defined address formats for IPv6 [IPV6].

The editors would like to acknowledge the contributions of Paul
Francis, Jim Bound, Brian Carpenter, Deborah Estrin, Peter Ford, Bob
Gilligan, Christian Huitema, Tony Li, Greg Minshall, Erik Nordmark,
Yakov Rekhter, Bill Simpson, and Sue Thomson.

2.0 IPv6 ADDRESSING

IPv6 addresses are 128-bit identifiers for interfaces and sets of
interfaces. There are three types of addresses:

Unicast: An identifier for a single interface. A packet sent
to a unicast address is delivered to the interface
identified by that address.

Anycast: An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to an
anycast address is delivered to one of the interfaces
identified by that address (the "nearest" one,
according to the routing protocols' measure of
distance).

Multicast: An identifier for a set of interfaces (typically
belonging to different nodes). A packet sent to a
multicast address is delivered to all interfaces
identified by that address.

There are no broadcast addresses in IPv6, their function being
superseded by multicast addresses.

In this document, fields in addresses are given a specific name, for
example "subscriber". When this name is used with the term "ID" for
identifier after the name (e.g., "subscriber ID"), it refers to the
contents of the named field. When it is used with the term "prefix"
(e.g., "subscriber prefix") it refers to all of the address up to and
including this field.

In IPv6, all zeros and all ones are legal values for any field,
unless specifically excluded. Specifically, prefixes may contain
zero-valued fields or end in zeros.

Monday, May 26, 2008

Autonomous system (Internet)


In the Internet, an autonomous system (AS) is a collection of IP networks and routers under the control of one entity (or sometimes more) that presents a common routing policy to the Internet. See RFC 1930 for additional detail on this updated definition.
Originally, the definition required control by a single entity, typically an Internet service provider or a very large organization with independent connections to multiple networks, that adhere to a single and clearly defined routing policy. See RFC 1771, the original definition (now obsolete) of the Border Gateway Protocol (BGP). The newer definition of RFC 1930 came into use because multiple organizations can run BGP using private AS numbers to an ISP that connects all those organizations to the Internet. Even though there are multiple autonomous systems supported by the ISP, the Internet only sees the routing policy of the ISP. That ISP must have a public, registered ASN.
A unique AS number (or ASN) is allocated to each AS for use in BGP routing. With BGP, AS numbers are important because the ASN uniquely identifies each network on the Internet. The IANA has reserved ASN numbers 64512 through 65534 to be used for private purposes. The ASNs 0 and 65535 are reserved by the IANA and should not be used in a live environment.

BGW

Border Gateway Protocol


Jump to: navigation, search
The five-layer TCP/IP model
5. Application layer
DHCP · DNS · FTP · Gopher · HTTP · IMAP4 · IRC · NNTP · XMPP · POP3 · RTP · SIP · SMTP · SNMP · SSH · TELNET · RPC · RTCP · RTSP · TLS (and SSL) · SDP · SOAP · GTP · STUN · NTP · (more)
4. Transport layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
3. Network/internet layer
IP (IPv4 · IPv6) · OSPF · IS-IS · BGP · IPsec · ARP · RARP · RIP · ICMP · ICMPv6 · IGMP · (more)
2. Data link layer
802.11 (WLAN) · 802.16 · Wi-Fi · WiMAX · ATM · DTM · Token ring · Ethernet · FDDI · Frame Relay · GPRS · EVDO · HSPA · HDLC · PPP · PPTP · L2TP · ISDN · ARCnet · LLTD · (more)
1. Physical layer
Ethernet physical layer · RS-232 · SONET/SDH · G.709 · Optical fiber · Coaxial cable · Twisted pair · (more)
This box: viewtalkedit
The Border Gateway Protocol (BGP) is the core routing protocol of the Internet. It works by maintaining a table of IP networks or 'prefixes' which designate network reachability among autonomous systems (AS). It is described as a path vector protocol. BGP does not use traditional IGP metrics, but makes routing decisions based on path, network policies and/or rulesets.
BGP was created to replace the EGP routing protocol to allow fully decentralized routing in order to allow the removal of the NSFNet Internet backbone network. This allowed the Internet to become a truly decentralized system. Since 1994, version four of the protocol has been in use on the Internet. All previous versions are now obsolete. The major enhancement in version 4 was support of Classless Inter-Domain Routing and use of route aggregation to decrease the size of routing tables. From January 2006, version 4 is codified in RFC 4271, which went through well over 20 drafts from the earlier RFC 1771 version 4. The RFC 4271 version corrected a number of errors, clarified ambiguities, and also brought the RFC much closer to industry practices.
Most Internet users do not use BGP directly. However, since most Internet service providers must use BGP to establish routing between one another (especially if they are multihomed), it is one of the most important protocols of the Internet. Compare this with Signalling System 7 (SS7), which is the inter-provider core call setup protocol on the PSTN. Very large private IP networks can make use of BGP, however. An example would be the joining of a number of large Open Shortest Path First (OSPF) networks where OSPF by itself would not scale to size. Another reason to use BGP would be multihoming a network for better redundancy either to a multiple access points of a single ISP (RFC 1998) or to multiple ISPs.

Sunday, May 18, 2008

Router Configaration

//Router Configaration


version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname dude
!
memory-size iomem 15
ip subnet-zero
!
ip audit notify log
ip audit po max-events 100
!
!--- IKE policies.
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key cisco123 address 200.1.1.2
!
!--- IPsec policies.
crypto ipsec transform-set to_vpn esp-3des esp-md5-hmac
!
crypto map to_vpn 10 ipsec-isakmp
set peer 200.1.1.2
set transform-set to_vpn
!--- Traffic to encrypt.
match address 101
!
interface Ethernet0/0
ip address 203.20.20.2 255.255.255.0
ip nat outside
half-duplex
crypto map to_vpn
!
interface Ethernet0/1
ip address 172.16.1.1 255.255.255.0
ip nat inside
half-duplex
!
ip nat pool mypool 203.20.20.3 203.20.20.3 netmask 255.255.255.0
ip nat inside source route-map nonat pool mypool overload
ip http server
no ip http secure-server
ip classless
ip route 0.0.0.0 0.0.0.0 203.20.20.1
ip route 172.16.20.0 255.255.255.0 172.16.1.2
ip route 172.16.30.0 255.255.255.0 172.16.1.2
!
!--- Traffic to encrypt.
access-list 101 permit ip 172.16.1.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 101 permit ip 172.16.1.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 101 permit ip 172.16.1.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 101 permit ip 172.16.20.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 101 permit ip 172.16.30.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 101 permit ip 172.16.30.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 101 permit ip 172.16.30.0 0.0.0.255 192.168.50.0 0.0.0.255
!--- Traffic to except from the NAT process.
access-list 110 deny ip 172.16.1.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 110 deny ip 172.16.1.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 110 deny ip 172.16.1.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 110 deny ip 172.16.20.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 110 deny ip 172.16.20.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 110 deny ip 172.16.20.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 110 deny ip 172.16.30.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 110 deny ip 172.16.30.0 0.0.0.255 192.168.40.0 0.0.0.255
access-list 110 deny ip 172.16.30.0 0.0.0.255 192.168.50.0 0.0.0.255
access-list 110 permit ip 172.16.1.0 0.0.0.255 any
!
route-map nonat permit 10
match ip address 110
!
line con 0
line aux 0
line vty 0 4
!
end

How to connect VPN concentrator to CISCO Router

Introduction
This sample configuration shows how to connect a private network behind a router that runs Cisco IOS® software to a private network behind the Cisco VPN 3000 Concentrator. The devices on the networks know each other by their private addresses.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
The information in this document is based on these software and hardware versions:
Cisco 2611 router with Cisco IOS Software Release 12.3.(1)a
Note: Make sure that Cisco 2600 Series routers are installed with a crypto IPsec VPN IOS image that supports the VPN feature.
Cisco VPN 3000 Concentrator with 4.0.1 B
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Configure
In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool ( registered customers only) to find more information on the commands used in this document.

Monday, May 12, 2008

Nagios Version 3.x Documentation
http://www.nagios.org
Copyright © 1999-2007 Ethan Galstad
Last Updated: 03-20-2007
[ Table of Contents ]
Nagios and the Nagios logo are registered trademarks of Ethan Galstad. All other trademarks,
servicemarks, registered trademarks, and registered servicemarks mentioned herein may be the
property of their respective owner(s). The information contained herein is provided AS IS with NO
WARRANTY OF ANY KIND, INCLUDING THE WARRANTY OF DESIGN, MERCHANTABILITY,
AND FITNESS FOR A PARTICULAR PURPOSE.

Sunday, May 11, 2008

Nagious

Introduction
This document describes how you can monitor "private" services and attributes of Windows machines,
such as:
Memory usage
CPU load
Disk usage
Service states
Running processes
etc.
Publicly available services that are provided by Windows machines (HTTP, FTP, POP3, etc.) can be
monitored easily by following the documentation on monitoring publicly available services.
Note: These instructions assume that you’ve installed Nagios according to the quickstart guide.
The sample configuration entries below reference objects that are defined in the sample config files
(commands.cfg, templates.cfg, etc.) that are installed if you follow the quickstart.
Overview
Monitoring private services or attributes of a Windows machine requires that you install an agent on it.
This agent acts as a proxy between the Nagios plugin that does the monitoring and the actual service or
attribute of the Windows machine. Without installing an agent on the Windows box, Nagios would be
unable to monitor private services or attributes of the Windows box.
For this example, we will be installing the NSClient++ addon on the Windows machine and using the
check_nt plugin to communicate with the NSClient++ addon. The check_nt plugin should already be
installed on the Nagios server if you followed the quickstart guide.
17
Other Windows agents (like NC_Net) could be used instead of NSClient++ if you wish - provided you
change command and service definitions, etc. a bit. For the sake of simplicity I will only cover using the
NSClient++ addon in these instructions.