Tuesday, March 8, 2011

Cisco DSL Router PPPoA Configuration with a Static IP Address


Tasks to Perform

  • Design an IP addressing scheme for your private LAN.
  • Configure an IP address and subnet mask on the Cisco DSL Router Ethernet interface.
  • Configure the ATM interface (Asynchronous Digital Subscriber Line (ADSL) interface) of the Cisco DSL Router with an ATM permanent virtual circuit (PVC) and encapsulation.
  • Create and configure the Dialer interface of the Cisco DSL Router for Point-to-Point Protocol over ATM (PPPoA) with a static IP address.
  • For NAT: Configure NAT on the Cisco DSL Router to allow sharing of the static public IP address of the Dialer interface.
    • Optional: NAT Pool, if additional IP addresses have been provided by your ISP.
    • Optional: Static NAT, if Internet users require access to internal servers.
  • Configure each host PC with an IP address, subnet mask, default gateway, and Domain Name System (DNS) server(s).
    Alternatively, if you want the Cisco DSL Router to assign your PC clients' dynamic IP addresses, configure each PC to obtain an IP address and DNS server(s) automatically via DHCP.

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.

Configuration

Cisco DSL Router with a Static IP Address




!--- Comments contain explanations and additional information.


service timestamps debug datetime msec
service timestamps log datetime msec
ip subnet-zero
!

!--- For DHCP:

ip dhcp excluded-address <ip address of ethernet0>
ip dhcp pool <dhcp pool name>
 network <ip network address of ethernet0> <subnet mask>
 default-router <ip address of ethernet0>
 dns-server <ip address of dns server>
!
interface ethernet0
 no shut
 ip address <ip address> <subnet mask>

!--- For NAT:

 ip nat inside
 no ip directed-broadcast
!
interface atm0
 no shut
 no ip address
 no ip directed-broadcast
 no ip mroute-cache
 pvc <vpi/vci>
  encapsulation aal5mux ppp dialer 
  dialer pool-member 1 
 
!--- Common PVC values supported by ISPs are 0/35 or 8/35.
 !--- Confirm your PVC values with your ISP.

!
interface dialer1
 ip address <ip address> subnet mask <subnet mask> 
 no ip directed-broadcast

!--- For NAT:

 ip nat outside
 encapsulation ppp
 dialer pool 1
 ppp chap hostname <username> 
 ppp chap password <password> 
 ppp pap sent-username <username> password <password> 
!

!--- For NAT:

ip nat inside source list 1 interface dialer1 overload

!--- If you have a pool (a range) of public IP addresses provided 
!--- by your ISP, you can use a NAT Pool. Replace 
!--- ip nat inside source list 1 interface dialer1 overload

 
 

!--- with these two configuration statements:
!--- ip nat inside source list 1 pool <nat pool name> overload
!--- ip nat pool <nat pool name> <first ip address> <last ip address> 
!---  netmask <subnet mask>




!--- If Internet users require access to an internal server, you can 
!--- add this static NAT configuration statement:
!--- ip nat inside source static tcp <inside ip address of server> 
{80 or 25} 
!--- <outside well-known ip address of server> {80 or 25} extendable
!--- Note: TCP port 80 (HTTP/web) and TCP port 25 (SMTP/mail) are used 
!--- for this example. You can open other TCP or UDP ports, if needed.

! 
ip classless 
ip route 0.0.0.0 0.0.0.0 dialer1 

!--- For NAT:

access-list 1 permit <ip network address of ethernet0> <wildcard mask>

!--- In this configuration, access-list 1 defines a standard access list 
!--- that permits the addresses that NAT translates. For example, if  
!--- your private IP network is 10.10.10.0, configure 
!--- access-list 1 permit 10.10.10.0 0.0.0.255 in order to allow NAT to
 translate 
!--- packets with source addresses between 10.10.10.0 and 10.10.10.255.

!
end


CISCO DSL Router Configuration : Configuration of RFC1483


Introduction

Your Internet Service Provider (ISP) has assigned an RFC1483 Bridging connection.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Configure

Important: Before you begin, close all programs on the PC that might be monitoring your COM port. Devices such as PDAs and digital cameras often place programs in the system tray that will render your COM port unusable for configuring your Cisco Digital Subscriber Line (DSL) Router.

Connect the Cisco DSL Router and Your PC

A console connection is made with a rolled cable and connects the console port of the Cisco Digital Subscriber Line (DSL) Router to a COM port on a PC. The console cable that is included with the Cisco DSL Router is a flat light blue cable. For more information on the pinouts of a rolled cable, or the pinouts of an RJ-45 to DB9 converter, refer to Cabling Guide for Console and AUX Ports.
  1. Connect the RJ-45 connector on one end of a Cisco console cable to the console port of the Cisco DSL Router.
  2. Connect the RJ-45 connector at the other end of the console cable to an RJ-45 to DB9 converter.
  3. Connect the DB9 connector to an open COM port on your PC.

Start and Set Up HyperTerminal

Complete these steps:
  1. Start the HyperTerminal program on the PC.
  2. Set up your HyperTerminal session.
    1. Assign a name to your session, and click OK.
    2. From the Connect To window, click Cancel.
    3. From the File menu, click Properties.
    4. From the Properties window, in the Connect Using list, select the COM port where you connect the DB9 end of the console cable.
    5. From the Properties window click Configure and fill in these values:
      • Bits per second: 9600
      • Data bits: 8
      • Parity: None
      • Stop bits: 1
      • Flow Control: None
    6. Click OK.
    7. From the Call menu, click Disconnect.
    8. From the Call menu, click Call.
    9. Press Enter until you see a router prompt on your HyperTerminal screen.

Clear Existing Configurations on the Cisco DSL Router

Complete these steps:
  1. Type enable at the router prompt to enter privileged mode.
    Router>enable
    Router#
    
    !--- The # symbol indicates that you are in privileged mode.
    
    
  2. Clear existing configurations on the router.
    Router#write erase
    
  3. Reload the router so it boots with a blank startup configuration.
    Router#reload
    System configuration has been modified. Save? [yes/no]:no
    Proceed with reload? [confirm]yes
    
    !--- Reloading the router can take a few minutes.
    
    
  4. After the router has reloaded, enter enable mode again.
    Router>enable
    Router#

Configure the Cisco DSL Router

Complete these steps:
  1. Configure service timestamp to properly log and display debug output in the troubleshooting section.
    Router#configure terminal
    Router(config)#service timestamps debug datetime msec
    Router(config)#service timestamps log datetime msec
    Router(config)#end
    
  2. Disable the logging console on your Cisco DSL Router to suppress console messages that may be triggered while you are configuring the router.
    Router#configure terminal
    Router(config)#no logging console
    Router(config)#end
    
  3. Configure a bridge protocol and disable routing on your Cisco DSL Router.
    Router#configure terminal
    Router(config)#no ip routing
    Router(config)#bridge 1 protocol ieee
    Router(config)#end
    
  4. Configure a bridge group on the Cisco DSL Router Ethernet interface.
    Router#configure terminal
    Router(config)#interface ethernet 0
    Router(config-if)#bridge group 1
    Router(config-if)#no shut
    Router(config-if)#end
    
  5. Configure the ATM interface of your Cisco DSL Router with an ATM permanent virtual circuit (PVC), encapsulation type, and bridge group.
    Router#configure terminal
    Router(config)#interface atm 0
    Router(config-if)#bridge-group 1
    Router(config-if)#pvc <vpi/vci>
    Router(config-if-atm-vc)#encapsulation aal5snap
    Router(config-if-atm-vc)#no shut
    Router(config-if-atm-vc)#end
    
  6. Enable the logging console on the Cisco DSL Router, and write all the changes to memory.
    Router#configure terminal
    Router(config)#logging console
    Router(config)#end
    *Jan 1 00:00:00.100: %SYS-5-CONFIG_I: Configured from console by console
    Router#write memory
    Building configuration... [OK]
    Router#

Configuration

This is the configuration that results after you complete the procedures in this document.
Cisco DSL Router with RFC1483 Pure Bridging

!--- Comments contain explanations and additional information.


service timestamps debug datetime msec
service timestamps log datetime msec
!
no ip routing
!
interface ethernet0
 no shut
 no ip directed-broadcast
 bridge-group 1
!
interface atm0
 no shut
 no ip address
 no ip directed-broadcast
 no atm ilmi-keepalive
 pvc <vpi/vci>
  encapsulation aal5snap
 
!--- Common PVC values supported by ISPs are 0/35 or 8/35.
 !--- Confirm your PVC values with your ISP.

 !
 bridge-group 1
!
bridge 1 protocol ieee
!
end   

Verify

Your Cisco DSL Router should now be operational for Asymetric Digital Subscriber Line (ADSL) service. You can issue a show runcommand in order to see the configuration.
Router#show run
Building configuration...
The Output Interpreter Tool ( registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of showcommand output.

Configuring a Samba Server

The default configuration file (/etc/samba/smb.conf) allows users to view their home directories as a Samba share. It also shares all printers configured for the system as Samba shared printers. In other words, you can attach a printer to the system and print to it from the Windows machines on your network.

Graphical Configuration

To configure Samba using a graphical interface, use the Samba Server Configuration Tool.

The Samba Server Configuration Tool is a graphical interface for managing Samba shares, users, and basic server settings. It modifies the configuration files in the /etc/samba/ directory. Any changes to these files not made using the application are preserved.

To use this application, you must be running the X Window System, have root privileges, and have the system-config-samba RPM package installed. To start the Samba Server Configuration Tool from the desktop, go to the System (on the Panel) => Administration => Server Settings => Samba or type the command system-config-samba at a shell prompt (for example, in an XTerm or a GNOME terminal).


Note --

The Samba Server Configuration Tool does not display shared printers or the default stanza that allows users to view their own home directories on the Samba server.

Configuring Server Settings ::--

The first step in configuring a Samba server is to configure the basic settings for the server and a few security options. After starting the application, select Preferences => Server Settings from the pulldown menu. The Basic tab is displayed as shown.


On the Basic tab, specify which workgroup the computer should be in as well as a brief description of the computer. They correspond to the workgroup and server string options in smb.conf.


The Security tab contains the following options:

Authentication Mode — This corresponds to the security option. Select one of the following types of authentication.

ADS — The Samba server acts as a domain member in an Active Directory Domain (ADS) realm. For this option, Kerberos must be installed and configured on the server, and Samba must become a member of the ADS realm using the net utility, which is part of the samba-client package. Refer to the net man page for details. This option does not configure Samba to be an ADS Controller. Specify the realm of the Kerberos server in the Kerberos Realm field.
Note :: --
The Kerberos Realm field must be supplied in all uppercase letters, such as EXAMPLE.COM.
Using a Samba server as a domain member in an ADS realm assumes proper configuration of Kerberos, including the /etc/krb5.conf file.

Domain — The Samba server relies on a Windows NT Primary or Backup Domain Controller to verify the user. The server passes the username and password to the Controller and waits for it to return. Specify the NetBIOS name of the Primary or Backup Domain Controller in the Authentication Server field.

The Encrypted Passwords option must be set to Yes if this is selected.

Server — The Samba server tries to verify the username and password combination by passing them to another Samba server. If it can not, the server tries to verify using the user authentication mode. Specify the NetBIOS name of the other Samba server in the Authentication Server field.

Share — Samba users do not have to enter a username and password combination on a per Samba server basis. They are not prompted for a username and password until they try to connect to a specific shared directory from a Samba server.

User — (Default) Samba users must provide a valid username and password on a per Samba server basis. Select this option if you want the Windows Username option to work. Refer to Section 19.4.1.2, “Managing Samba Users” for details.

Encrypt Passwords — This option must be enabled if the clients are connecting from a system with Windows 98, Windows NT 4.0 with Service Pack 3, or other more recent versions of Microsoft Windows. The passwords are transfered between the server and the client in an encrypted format instead of as a plain-text word that can be intercepted. This corresponds to the encrypted passwords option. Refer to Section 19.4.3, “Encrypted Passwords” for more information about encrypted Samba passwords.

Guest Account — When users or guest users log into a Samba server, they must be mapped to a valid user on the server. Select one of the existing usernames on the system to be the guest Samba account. When guests log in to the Samba server, they have the same privileges as this user. This corresponds to the guest account option.

After clicking OK, the changes are written to the configuration file and the daemon is restarted; thus, the changes take effect immediately

Managing Samba Users
The Samba Server Configuration Tool requires that an existing user account be active on the system acting as the Samba server before a Samba user can be added. The Samba user is associated with the existing user account.

To add a Samba user, select Preferences => Samba Users from the pulldown menu, and click the Add User button. In the Create New Samba User window select a Unix Username from the list of existing users on the local system.

If the user has a different username on a Windows machine and needs to log into the Samba server from the Windows machine, specify that Windows username in the Windows Username field. The Authentication Mode on the Security tab of the Server Settings preferences must be set to User for this option to work.

Also, configure a Samba Password for the Samba User and confirm it by typing it again. Even if you opt to use encrypted passwords for Samba, it is recommended that the Samba passwords for all users are different from their system passwords.

To edit an existing user, select the user from the list, and click Edit User. To delete an existing Samba user, select the user, and click the Delete User button. Deleting a Samba user does not delete the associated system user account.

The users are modified immediately after clicking the OK button.


Adding a Share

To create a Samba share, click the Add button from the main Samba configuration window.


The Basic tab configures the following options:

Directory — The directory to share via Samba. The directory must exist before it can be entered here.


Share name — The actual name of the share that is seen from remote machines. By default, it is the same value as Directory, but can be configured.

Descriptions — A brief description of the share.

Writable — Enables users to read and write to the shared directory

Visible — Grants read-only rights to users for the shared directory.

On the Access tab, select whether to allow only specified users to access the share or whether to allow all Samba users to access the share. If you select to allow access to specific users, select the users from the list of available Samba users.

The share is added immediately after clicking OK.


THIS IS ONE OF thePROCESS also....in linux :::---



DHCP Server Configuration for Linux

What is & How DHCP works.... !!!


This below guide will help you setup a dhcp server to provide network configuration information to clients on the network. These instructions were written with Red Hat 5.x systems in mind but the basic concepts provided here can be applied to other distributions as well.

Instructions :: --


1. Download dhcp rpm package from Red Hat and install:

# rpm -ivh dhcp-2.0pl5-8.i386.rpm

2. Open file /etc/sysconfig/dhcpd and edit the first line as follows:

DHCPDARGS=eth1

Replace 'eth1' above with the network interface that you want to use for dhcp; this should be an internal network interface; denial of service attacks are possible if dhcp is running on an external interface.

3. Copy /usr/share/doc/dhcp-2.0pl5/dhcpd.conf.sample to /etc

# cp /usr/share/doc/dhcp-2.0pl5/dhcpd.conf.sample /etc/dhcpd.conf

This sample file is a good starting point for our /etc/dhcpd.conf file, which by default is not installed. Alternatively, copy the file from a working server.

4. Edit /etc/dhcpd.conf to suit your needs. An example file is included below for reference:

#################file begin######################
subnet 10.0.0.0 netmask 255.255.255.0 {
# --- default gateway
option routers 10.0.0.1;
option subnet-mask 255.255.255.0;

# option nis-domain "mydomain.com";
option domain-name "mydomain.com";
option domain-name-servers 216.227.56.120, 64.34.4.36;

option time-offset -28800; # Pacific Standard Time
# option ntp-servers 192.168.1.1;
# option netbios-name-servers 192.168.1.1;
# --- Selects point-to-point node (default is hybrid). Don't change this unless
# -- you understand Netbios very well
# option netbios-node-type 2;

range 10.0.0.50 10.0.0.254;
default-lease-time 604800;
max-lease-time 604800;

host test {
# option dhcp-client-identifier "test";
hardware ethernet 00:e0:18:90:28:b2;
fixed-address 10.0.0.10;
}
# we want the nameserver to appear at a fixed address
# host ns {
# next-server marvin.redhat.com;
# hardware ethernet 12:34:56:78:AB:CD;
# fixed-address 207.175.42.254;
# }
}
########################file end##########################


Notes : specific settings always override global settings; in the above, the range 10.0.0.50 to 10.0.0.254 have been set side for dynamic hosts; this allows anything between 10.0.0.1 and 10.0.0.49 to be set aside as static ips. In the example, host 'test' is given a static ip using its mac address. The option 'dhcp-client-identifier' may work as an alternative to mac address, but may require some additional configuration on the client. The max lease time of 604800 translates to 7 days. Lease times are automatically renewed by clients once 50% of the expiration date is reached. Because of this, very long lease times should be unnecessary. If a very long one is required, provide the client a static ip using the host declaration. Also, the option time-offset setting is in seconds according to the manual page; Red Hat's configuration document erroneously lists this setting in hours. Use option host-name "apex.example.com" in a host declaration to provide hostnames to clients.


5. Check that the lease database has been created; the rpm should create this file automatically; if not, create the file:

# touch /var/lib/dhcp/dhcpd.leases

The lease database is recreated from time to time so that it is not too large. First, all known leases are saved in a temporary lease database. The dhcpd.leases file is renamed dhcpd.leases~, and the temporary lease database is written to dhcpd.leases.

The DHCP daemon could be killed or the system could crash after the lease database has been renamed to the backup file but before the new file has been written. If this happens, there is no dhcpd.leases file that is required to start the service. Do not create a new lease file if this occurs. If you do, all the old leases will be lost and cause many problems. The correct solution is to rename the dhcpd.leases~ backup file to dhcpd.leases and then start the daemon.

6. Run 'setup' and check dhcpd to have it load at system boot

7. Start/restart the server

# service dhcpd start (restart)

Changes to the file /etc/dhcpd.conf require the dhcp server to be restarted

8. Test to make sure it works.

Sunday, March 6, 2011

How to Set Up VPN in Windows 7


VPN (Virtual Private Network) technology lets a computer using a public Internet connection join a private network by way of a secure "tunnel" between that machine and the network. The most common case is a business allowing its employees to connect to its work network from home or from the road.
There are two principal ways to configure VPN. The first and more-common scenario, called outgoing,is setting up a remote computer to call into the office network. The second scenario, called incoming,occurs on the network side, where a computer allows secure connections from other computers. Windows 7 comes preloaded with the Agile VPN client, which makes setting up either kind of connection relatively easy.

Step by Step: Connecting to a VPN (Outgoing)

Step 1 Click the Start button. In the search bar, type VPN and then select Set up a virtual private network (VPN) connection.
Step 2 Enter the IP address or domain name of the server to which you want to connect. If you're connecting to a work network, your IT administrator can provide the best address.
Step 3 If you want to set up the connection, but not connnect, select Don't connect now; otherwise, leave it blank and click Next.
Step 4 On this next screen, you can either put in your username and password, or leave it blank. You'll be prompted for it again on the actual connection. Click Connect.
Step 5 To connect, click on the Windows network logo on the lower-right part of your screen; then select Connect under VPN Connection.
Step 6 In the Connect VPN Connection box, enter the appropriate domain and your log-in credentials; then click Connect.
Step 7 If you can't connect, the problem could be due to the server configuration. (There are different types of VPN.) Check with your network administrator to see what kind is in use--such as PPTP--then, on the Connect VPN Connection screen, select Properties.
Step 8 Navigate to the Security tab and select the specific Type of VPN from the drop-down list. You may also have to unselect Include Windows logon domain under the Options tab. Then click OK and Connect.

Step by Step: Building a VPN (Incoming)
Step 1 Click the Start button, and, in the search bar, type Network and Sharing.
Step 2 Click Change Adapter Settings in the left-hand menu.
Step 3 Click File, and then New Incoming Connection.
Step 4 Select the users you'd like to give access to and click Next.
Step 5 Click Through the Internet and select Next.
Step 6 Select the Internet Protocol you'd like to use. (The default TCP/IPv4--the line highlighted in the screenshot below--will work fine.)
Step 7 Finally, click Allow access; you've now set up an incoming VPN connection.


Google Chrome OS Will Reshape Desktop Landscape


Google Chrome OS Will Reshape Desktop LandscapeSo Google is jumping into the operating system business, taking on not only nemesis Microsoft but also the idea that applications are typically made to run on the desktop. Here are some thoughts on how this might change the desktop landscape.

  • Watch out Apple. While much coverage of this news is focusing on the threat to Microsoft's desktop OS dominance, at the outset the biggest loser may be the Mac OS.

Those looking for a desktop OS alternative to Windows typically consider two options: Mac OS X or a traditional Linux flavor. Linux, despite advocates' claim to the contrary, is still daunting to most non power users due to issues like networking and peripheral drivers. Mac, meanwhile, has two chief drawbacks: fewer available applications (not an issue to many consumers) and costly hardware. It's no accident that Microsoft's most successful Windows ad campaign doesn't even talk about software anymore, but rather comparative hardware costs.
If there were a version of the Mac OS that ran on non-Apple hardware, I'm not sure Google would have seen the same market opening for a new operating system. But there isn't, and Google Chrome OS is likely to be targeting the same audience as Mac OS X -- those looking for a Windows alternative -- while offering a platform that runs on more affordable hardware.
  • Windows 7 pricing, terms likely to get more attractive. Expect Microsoft to think twice about how much it thinks it can charge for various versions of Windows 7, especially if Google's OS looks like it's gaining market traction. Expect Microsoft to be more receptive to complaints from Vista Ultimate usersthat they weren't given a better, less expensive upgrade path, and come up with some interesting terms for a Win 7 "family pack."
  • Netbooks are a wise beachhead for a Google OS. Power desktop users may initially balk at the idea of ceding application control to the cloud, but those same people might be less resistant on a netbook. Netbook users probably expect (and use) fewer apps, and getting rid of resource-hogging Windows antivirus software might be a welcome upside if the Google OS is, as promised, simple, secure and speedy.
  • Large companies are unlikely first customers, except as small experiments. I don't see major IT organizations happily ditching their Windows-based software in order to turn control of the desktop over to Google. While a Google OS is likely to gain entry in small numbers at large corporations as people check out the newcomer, large-scale adoption is unlikely unless and until the OS proves it has enterprise-class management capabilities. However, those small businesses with limited application needs might be more interested, especially if cost and maintenance are both low.
  • College students are a likely market. Today's students are mobile in ways that those even five years ago couldn't imagine, and they're less likely to be concerned whether an application is on their desktop or over the Web.
  • Sun flashback. It looks like Google is trying to bring to fruition that Sun Microsystems mantra, "the network is the computer."
  • Would Google dominance be any better than Microsoft's? In the short run, this announcement adds to the OS competitive landscape and is likely to encourage Microsoft to give better terms to those opting for Windows 7. Plus, it's unlikely Google can make a short-term dent in Windows' gargantuan desktop OS market share. However, Google already has a great deal of control over the search-engine market, and thus has become a prime director of traffic around the Web. Despite Google's now-cliched "do no evil" corporate mantra, the idea of a single company controlling the desktop, the application and the data is not without concern. It will be interesting to see whether the open-source community welcomes Google's entry into the OS arena or has concern about the company's growing reach.

Wireless Power Transmission


Wireless power transmission has been a dream since the days when Nikola Tesla imagined a world studded with enormous Tesla coils. But aside from advances in recharging electric toothbrushes, wireless power has so far failed to make significant inroads into consumer-level gear.

  • What is it? This summer, Intel researchers demonstrated a method--based on MIT research--for throwing electricity a distance of a few feet, without wires and without any dangers to bystanders (well, none that they know about yet). Intel calls the technology a "wireless resonant energy link," and it works by sending a specific, 10-MHz signal through a coil of wire; a similar, nearby coil of wire resonates in tune with the frequency, causing electrons to flow through that coil too. Though the design is primitive, it can light up a 60-watt bulb with 70 percent efficiency.
  • When is it coming? Numerous obstacles remain, the first of which is that the Intel project uses alternating current. To charge gadgets, we'd have to see a direct-current version, and the size of the apparatus would have to be considerably smaller. Numerous regulatory hurdles would likely have to be cleared in commercializing such a system, and it would have to be thoroughly vetted for safety concerns.

Assuming those all go reasonably well, such receiving circuitry could be integrated into the back of your laptop screen in roughly the next six to eight years. It would then be a simple matter for your local airport or even Starbucks to embed the companion power transmitters right into the walls so you can get a quick charge without ever opening up your laptop bag.