...

Wednesday, June 30, 2010

CCNA Voice 07

There are a few steps to set up a Cisco IP phone to work with your network. Like any other IP devices, the first step is to provide addressing. This provision comes in the form of DHCP. However there are several concepts that need to be in place first.
Take a look at the following diagram:


At this point it may seem confusing as to why the PC is connected to the phone instead of the switch. The reason why the PC is connected to the phone is because a Cisco IP phone is actually a 3-port switch! Internally it actually looks like this:


Switches speak the 802.1Q language of love, so it can tag its own packets. Packets originating from the IP Phone will be tagged with the VLAN number we'll be configuring later, and packets from the PC will be untagged, putting it in the native VLAN of the access port.

We'll first work on configuring the Voice VLAN from the switchport interface. Suppose that the IP Phone is connected to the F0/1 port of the switch, we'll have the configuration:
vlan 10
name CLIENTS
vlan 100
name IP_PHONES
in f1/0
sw m a
sw a v 10
sw voice vlan 100
span port


Now suppose that the router is connected to F1/15. The router here will be our Call Manager and DHCP, so we'll set the switchport as follows:
in f1/15
sw m t


And then we'll the following configuration on the router:
in f0/0.10
encap dot 10
ip add 10.10.10.1 255.255.255.0
in f0/0.100
ip add 100.100.100.1 255.25.255.0
encap dot 100
in f0/0
no shut


Now that the router is able to reach both the Clients and the IP Phone subnets, it's time to set up the DHCP:
ip dhcp pool CLIENTS
network 10.10.10.0 255.255.255.0
default-r 10.10.10.1
ip dhcp pool IP_PHONES
network 100.100.100.0 255.255.255.0
default-r 100.100.100.1
option 150 ip 100.100.100.1


Notice that we put in an option 150 for the IP_PHONES scope. Option 150 is used by Cisco IP Phones to contact the (TFTP) server for configurations and/or upgrades to successfully boot.

At this point I'll show you the full topology. This is what we'll be working with:


We'll now work to set up IP telephony services. To do this, we'll begin with the basic command to get into telephony prompt:
telephony-service

At this point, we would not be able to create ephones and ephone-dns because by default the maximum for both is set to 0. An ephone-dn is typically a number and an ephone is what the number is assigned to. An ephone represents a single physical phone and can be automatically assigned or assigned based on a specified MAC address. You can have multiple ephone-dns assigned to one phone in a variety of ways. To allow creation of ephones and ephone-dns, type:
max-ephones 10
max-dn 10


Right now you would be able to allow up to 10 IP Phones (ephones), and they can share as many as 10 numbers (ephone-dns). However, do not exit the prompt yet, we should have to set the Call Manager which phones need to communicate through Skinny with. To do this, we'll type:
ip source-address 100.100.100.1 port 2000

The port can be anything from 2000 to 9999. The default for Skinny is 2000 and we'll stick with that. Now we'll create a number (ephone-dn). We'll need to come up with a numbering plan. Everything in Site A will be using ranges 1001 to 1009, and anything from Site B will be 2001 to 2009. So we'll create a ephone-dn for our first phone like this:
ephone-dn 1
number 1001


Then we'll assign the number to the phone like this:
ephone 1
mac AAAA.AAAA.AAAA
button 1:1


The button command assigns the phone button to a DN. Cisco 7960 has 6 buttons which could be assigned numbers. In the example, the first button is assigned to ephone-dn 1. Pressing button 1 would pick up the 1001 line. Notice that a colon is used. There are actually other ways to assign numbers to buttons, like overlaying multiple lines to one number, but we'll do that next time. Right now, we'll stick with this.

Now, set up the other side in a similar fashion and you should end up with two sides. Suppose for the link connecting the two routers, RA has the IP of 50.50.50.1 and RB has the IP of 50.50.50.2. We'll need to find a way to route the calls over. Recall that in our scenario, Site A uses ranges 1001 to 1009, and Site B uses 2001 to 2009. We'll now have to route the calls to each other through dial-peers (exact same one we used in the previous article):
dial-peer voice 1 voip
destination-pattern 200.
session target ipv4:50.50.50.2


Do a mirrored configuration for the opposite router and the connectivity would be complete!

Tuesday, June 29, 2010

CCNA Voice 06

Gateways are equipment that connect a local device to a remote network possibly of a different medium. A voice gateway can connect to a PBX, PSTN or the internet. Analog gateways are gateways that have analog ports, while digital gateways have digital ones.
Analog ports are ports that connect to analog devices. These ports are:
FXS - Foreign Exchange Station - Used to connect to an end-station device.
FXO - Foreign Exchange Office - Used to connect to the central office.
E&M - Receive and Transmit - Used to terminate tie lines (circuits between two sites)

Digital gateways typically have three port types: PRI, BRI and CAS. They are typically used to connect a VoIP network to the PSTN, but can also be used to connect to the PBX.

A Call Leg is a logical connection between two VoIP devices. A phone connected to a router connected to another phone connected to another router has four legs. This is visualized using:

Phone A -leg- Router A -leg- Cloud -leg- Router B -leg- Phone B

When a call is received on a gateway, the call must be routed to either an IP address or a voice port. This is defined using a dial-peer. A POTS call is directed at a voice port, while a VoIP call is directed at an IP address.



In the above topology, an analog phone is plugged into an FXS port port 0/0/0. To create a dial-peer for it, we'll have to type:
dial-peer voice 1 pots
destination-pattern 0001
port 0/0/0


The Call Manager will create a Voice Dial-Peer (as opposed to data) with a tag of 1 for an analog port. When it matches traffic for number 0001, it will route it to port 0/0/0.

Now suppose that we have another Call Manager connected across the WAN like this:


To enable connectivity between the two sites, we must come up with some sort of numbering plan. Let's keep it simple: PhoneA's site will have numbers starting with 1xxx, while PhoneB's site will have numbers starting with 2xxx. Now assuming both routers have full connectivity with each other, let's set up the phones starting from CCMEA:
dial-peer voice 1 pots
destination-pattern 1001
port 0/0/0
dial-peer voice 2 voip
destination-pattern 2...
session target ipv4:2.2.2.1


From CCMAB, this is what you should have:
dial-peer voice 1 pots
destination-pattern 2001
port 0/0/0
dial-peer voice 2 voip
destination-pattern 1...
session target ipv4:1.1.1.1


If you dial 2001 from PhoneA, you would expect PhoneB to ring. This is because when the numbers are dialed in, the 2... wildcard patern is matched, so the data is sent over the WAN to session target 2.2.2.2. When CCMAB receives the call signaling, it checks that it's meant for 2001, so it routes to port port 0/0/0 which is PhoneB.

The Period is just one of the many wildcards available for use. A full list of wildcards available can be found here.

CCNA Voice 05

For a call to be set up, maintained, and torn down, a signaling protocol must work behind the scenes. There are various signaling protocols in use by VoIP systems. The industry standard signaling protocols are MGCP, H.323 and SIP. Cisco has its own proprietary protocol known as the SCCP.
Of the protocols, H.323 and SIP are peer-to-peer while MGCP and SCCP are client-server based. A peer-to-peer signaling protocol doesn't require a central server to communicate properly. On the other hand, the client-server signaling protocol requires a central server to communicate. A client-server protocol cannot directly communicate with another peer, and it has limited intelligence. The client acts as a dumb terminal and the server tells it what to do when it picks up the phone, and when it dials a number, and whether it should play a tone or start ringing. It does not have its own dial plan. On the other hand, peer-to-peer clients have their own dial plan and is intelligent enough to set up calls independently of a central server.

SCCP is a Cisco-proprietary client-server protocol that supports voice and video transmission. The messages are sent in TCP first. After the call is set up, RTP is used for the actual call.

H.323 is an ITU standard based on Q.931 (ISDN). It is peer-to-peer and uses a set of protocols for various tasks:
H.225 - Registration, Admission and Status as well as call signaling
H.245 - Exchange featuresets and open channels
RTP - Used to transmit the actual data

Like SCCP, H323 supports both Voice, Video and Data transmission.

MGCP is an IEFT standard that operates in a client-server fashion. Like SCCP, it requires the server to instruct the phone to perform every operation. MGCP does not have its own dialplan and it relies on the Call Manager to do routing.

Another IETF standard is the SIP. SIP is peer-to-peer and is easier to troubleshoot due to the ASCII messages sent between the peers. SIP can be used for voice, video, and data. SIP operates on port 5060 and can use either UDP or TCP. Like most other protocols, RTP is used for the actual transmission of voice once the call is set up. SIP has four major components:
User Agent - Endpoint devices such as phones that initiate sessions
Registrar Server - Stores the location of all User Agent
Proxy Server - Accepts requests and queries the Registrar
Redirect Server - Provides routing information for the clients

The CCME or CUCME supports only H.323, SCCP and SIP. It does not support MGCP. Only the non-express version supports it MGCP.

CCNA Voice 04

DSPs are used for a variety of purposes in Cisco Unified Communications. DSPs provide services like:Conferencing - Hardware-based voice conferencing which mixes multiple voice streams into one.
Transcoding - Allows conversion between compressed and non-compressed formats for compatibility.
Voice Media Termination - Acts as a voice termination point between sites.

Before compressed voice data can be sent into the internet, they must be packaged into IP packets. This packaging is done through the UDP-based RTP protocol which packages voice into 10ms samples. Usually two of this samples are packed into an RTP header. RTP stands for Real-Time Control Protocol, and just as its name suggests, is designed for real-time applications such as VoIP. RTP provide fields for:
Payload Type Identification - This identifies the payload the packet carries so it can be properly dealt by their respective applications.
Sequence Numbering - This number increments by 1 for each RTP packet sent (as opposed to each byte in TCP). The receiver can use this information to check for packet statistics.
Time Stamping - For synchronization to a linear clock and to allow jitter calculation.

RTP is typically assigned an even port from a known range between 16384-32766. This facilitates QoS features. But what about the odd numbered parts? They are actually assigned to another protocol known as RTCP. Real-Time Transport Control Protocol is used to provide feedback on the quality of the link. These include: Packet count, packet dela,y octet count, packet loss and jitter. The RTCP session is assigned a port that is 1 higher than the RTP session it's monitoring, which makes the port odd. RTCP packets are sent as a percentage of the actual link bandwidth, and it reports the NTP and RTP timestamps for the RTP session.

A typical RTP packet looks like this:
|L2|IP|UDP|RTP|Sample|Sample|

Up to layer 3, the header size would be 40-bytes (IP 20-bytes + UDP 8-bytes + RTP 12-bytes). Layer 2 would vary depending on the protocol used. Here are the common ones:
Ethernet - 18-bytes
MLP (Multilink Procedure) - 6-bytes
FRF.12 (Frame Relay) - 6-bytes
Multilink PPP - 6-bytes

G.711 and G.729 are the most commonly employed compression methods in Cisco Unified Communications. G.729 is based on the CS-ACELP (Conjugate Structure Algebraic Code-Excited Linear Prediction) compression algorithm. For 20ms worth of G.711 audio, you would need to take 160 samples per second, which results in 160-bytes of payload. G.729 provides an 8-to-1 compression ratio, effectively reducing the bandwidth requirements for 20ms worth of samples from 160-bytes for the G.711 to a mere 20-byte for the G.729.

The original G.729 is a highly complex algorithm but is extremely CPU-intensive. An alternative to G.729 is its Annex A variant which uses a medium-complexity algorithm. This results in a slightly lower audio quality but requires 25% less processing power (measured in MIPS).

Extra features like VAD and CNG can then be added to both original and Annex A variants by adding in Annex B features. The resulting codecs are G.729b and G.729ab. VAD stands for Voice Activity Detection and allows bandwidth to be saved by stopping the transmission of packets whenever there is silence. CNG on the other hand is used to locally generate white noise during times of silence to prevent users from feeling like the call has been dropped.

You'll notice that packets using G.729 codec actually have larger headers (40-bytes) than payloads (20-bytes). This effectively makes the Overhead : Payload ratio a bad 2 : 1. To remedy this, we can make use of cRTP which hashing the entire L3 header up till the payload. This effectively reduces the header size from 40-bytes to 2-bytes.

A calculation example is as follows:
Suppose you're using G.729a over Ethernet. Here is the size of a single packet carrying 20ms of samples:
Ethernet - 18
IP - 20
UDP - 8
RTP - 12
Sample 1 - 10
Sample 2 - 10

That would be a total of 60-bytes per 20ms. Multiply that by 50 to get 1 second, and you have 3000-bytes per second. Multiply that by 8 to get 24000bps.

Monday, June 28, 2010

CCNA Voice 03

Analog circuits provide enough bandwidth to enable users to make a single call per line. This, however, is not scalable. Digital circuits makes use of a single line to carry multiple calls through multiplexing.
One particular multiplexing method used by many technologies is the Time Division Multiplexing, otherwise known as TDM. TDM divides time into many slots and allocates each call a fair slice of time for transmission over a single line. The receiving end then demultiplexes the incoming data into separate lines.

An example of a technology reliant on TDM is the T1 line. A T1 line bundles 24 voice channels into a single digital circuit. Each voice channel, known as DS0, provides 64Kbps of bandwidth. Combined, you'll have a speed of 1.536Mbps for data. However, framing the data requires an additional 8Kbps, which results in a raw speed of 1.544Mbps.

T1 is framed through two different formats:
1) D4 is the original format where 8 bits are used to frame each of the 24 DS0s, resulting in 192 bits of framing. An additional 1 bit is used for termination, resulting in 193 bits. 12 groups of such frames results in a SF (SuperFrame)

2) ESF is the modern T1 framing technique which extends the 12 frames to 24 frames.

D4 framing circuits are configured to have AMI line coding, while B8ZS line coding is used on ESF circuits.

Similar to a T1, an E1 line is commonly found outside North America. It is the European version of the T1 circuit. E1 circuits make use of Channel Associated Signaling (CAS) which robs the lower order bit of the sixth time slice for signaling. E1 makes use of 32 DS0s, where the first and seventeenth channel is used for framing and signaling respectively. The raw bandwidth is 2.048Mbps.

E1 CAS uses R2 signaling to exchange caller information. Three methods to exchange are:
1) R2-compelled - When the tone pair is sent from the switch, the tone stays on until the receiving end replies with a tone pair.
2) R2-noncompelled - When the tone pair is sent from the switch, it is sent in pulses. The replies are also sent in pulses. This is the most common implementation.
3) R2-semicompelled - When the tone pair is sent from the switch, the tone stays on while the replies are sent in pulses.

Like E1, the T1 circuit described thus far is the CAS variant, which also uses robbed bits. Another type of T1/E1 circuit is the ISDN circuit, which uses CCS (Common Channel Signaling). CCS uses an entirely separate channel to provide signaling and this signaling is done through HDLC at Layer 1, Q.921 at Layer 2 and Q.931 and Layer 3. Two types of CCS circuits are PRI and BRI, which stands for Primary Rate Interface and Basic Rate Interface respectively.

PRI provides 23 channels for data, and 1 channel for signaling, which are referred to as 23B+D. The E1 PRI is common in European countries and is referred to as 30B+D. BRI on the other hand provides 2B+D, resulting in 144Kbps (2 DS0 + a 16Kbps signaling channel).

Before voice can be transmitted over the network, you would require a process to convert an analog sound wave into a digital representation of it. The sampling rate for digitizing analog signals is determined using Nyquist's theorem which states that the sampling (baud) rate should be equal to twice or more of the original sample. The human voice scales from 300Hz to 3300Hz, so it makes good sense to sample at 8000Hz to be on the safe side.

The next process is quantization. Quantization uses a logarithmic scale to quantize the samples. Using such a scale provides greater granularity for smaller signals which allows a high signal-to-noise ratio.

Encoding turns the quantized values into binary. Currently there are two encoding standards in use: mu-law and A-law. mu-law is used in North America while A-law is used everywhere else. The difference between them is that mu-law actually inverts the segment and interval before creating the binary value, while A-law simply takes the values as it is.

Finally comes compression. The world's standard for communication is the G.711 codec, which is a direct translation of an analog signal to a voice which takes up 64Kbps of bandwidth. In order to increase the number of calls a DS0 can carry, compression is used. Compression algorithms such as ADPCM details the change in the wave rather than the entire wave. Prediction can also further help reduce the variations between the original wave and the new wave. Another compression algorithm known as CS-ACELP is also widely adopted. Algorithms like G.729 make use of CS-ACELP technology.

Sunday, June 20, 2010

Misc 37

Today I'll cover the basics of setting up a Server Core installation of Windows Server 2008 Enterprise as a Active Domain Domain Controller by installing ADDS (Active Directory Domain Services). As a bonus, this post steps you through the steps required in finding the correct commands through context-sensitive help.
First of all, we'll need to set up the IP address. To do this, we'll need to make use of the "netsh" command. However, netsh is used not only for setting up your IP, but also for various other system configurations such as firewalls. We'll first begin netsh by invoking the command:
netsh

This would bring you into a netsh prompt that looks like:
netsh>
Right now, we'll need to see what options do we have available. Type ? and hit Return and you should be presented with the following list:
Commands in this context:
..             - Goes up one context level.
?              - Displays a list of commands.
abort          - Discards changes made while in offline mode.
add            - Adds a configuration entry to a list of entries.
advfirewall    - Changes to the `netsh advfirewall' context.
alias          - Adds an alias.
bye            - Exits the program.
commit         - Commits changes made while in offline mode.
delete         - Deletes a configuration entry from a list of entries.
dhcpclient     - Changes to the `netsh dhcpclient' context.
dump           - Displays a configuration script.
exec           - Runs a script file.
exit           - Exits the program.
firewall       - Changes to the `netsh firewall' context.
help           - Displays a list of commands.
http           - Changes to the `netsh http' context.
interface      - Changes to the `netsh interface' context.
ipsec          - Changes to the `netsh ipsec' context.
nap            - Changes to the `netsh nap' context.
netio          - Changes to the `netsh netio' context.
offline        - Sets the current mode to offline.
online         - Sets the current mode to online.
popd           - Pops a context from the stack.
pushd          - Pushes current context on stack.
quit           - Exits the program.
rpc            - Changes to the `netsh rpc' context.
set            - Updates configuration settings.
show           - Displays information.
unalias        - Deletes an alias.
winhttp        - Changes to the `netsh winhttp' context.
winsock        - Changes to the `netsh winsock' context.
Now, we are trying to configure the eth0 interface with an IP address. To do this, go into interface mode by typing:
interface

You should be in the interface prompt now:
netsh interface>
If you try to display context-sensitive help, you should see the following list of commands:
Commands in this context:
6to4           - Changes to the `netsh interface 6to4' context.
?              - Displays a list of commands.
add            - Adds a configuration entry to a table.
delete         - Deletes a configuration entry from a table.
dump           - Displays a configuration script.
help           - Displays a list of commands.
ipv4           - Changes to the `netsh interface ipv4' context.
ipv6           - Changes to the `netsh interface ipv6' context.
isatap         - Changes to the `netsh interface isatap' context.
portproxy      - Changes to the `netsh interface portproxy' context.
reset          - Resets information.
set            - Sets configuration information.
show           - Displays information.
tcp            - Changes to the `netsh interface tcp' context.
teredo         - Changes to the `netsh interface teredo' context.
Right now we want to set up the IPV4 address of the interface. To do this, we'll have to move into the ipv4 prompt:
ipv4

Over in the ipv4 prompt, we'll have these commands available:
Commands in this context:
?              - Displays a list of commands.
add            - Adds a configuration entry to a table.
delete         - Deletes a configuration entry from a table.
dump           - Displays a configuration script.
help           - Displays a list of commands.
install        - Install the IP protocol.
reset          - Reset the IP configurations.
set            - Sets configuration information.
show           - Displays information.
uninstall      - Uninstall the IP protocol.
What we want to do now is to set the address. So type "set" and look at the commands available:
Commands in this context:
set address    - Sets the IP address or default gateway to an interface.
set compartment - Modifies compartment configuration parameters.
set dnsserver  - Sets DNS server mode and addresses.
set dynamicportrange - Modifies the range of ports used for dynamic port assignment.
set global     - Modifies global configuration general parameters.
set interface  - Modifies interface configuration parameters for IP.
set neighbors  - Sets a neighbor address.
set route      - Modifies route parameters.
set subinterface - Modifies subinterface configuration parameters.
set winsserver - Sets WINS server mode and addresses.
We finally found it. Now just type "set address" and we should get an example that looks like:
set address "Local Area connection" static 10.0.0.9 255.0.0.0 10.0.0.1 1

We want to modify it to our specifications. For mine, it would look like this:
set address "Local Area connection" static 4.4.4.2 255.255.255.0 4.4.4.1

A non-interactive shortcut would be:
netsh interface ipv4 set address "Local Area connection" static 4.4.4.2 255.255.255.0 4.4.4.1

My IP is now 4.4.4.2/24 and 4.4.4.1 is my default-gateway. Now we'll change the computer name. To change the computer name, or to join a domain, we'll need to make use of the "netdom" command. Using similar methods, we'll find that the command to change the local computer name to "DC01" is:
netdom renamecomputer localhost /NewName:DC01

After confirming the change, the next step is to restart the computer:
shutdown /r /t 0

Now we'll finally begin setting up the system as a Domain Controller. To do this, we'll need to make use of the "dcpromo" command. In this case, we'll want to set up promotion to a DC. From context sensitive help, we'll find that to list all commands related to promotion, we'll need to type:
dcpromo /?:Promotion

We'll begin by specifying that we want a new domain through:
dcpromo.exe /ReplicaOrNewDomain:Domain

We'll soon realize that they want to know if it's a DC for a new or existing forest. Since it's a new forest, we'll refer to the command list again. This time, we'll type:
dcpromo.exe /ReplicaOrNewDomain:Domain /NewDomain:Forest

Now, it wants to know what the domain name should be. Again, from the command list, we can do this by typing:
dcpromo.exe /ReplicaOrNewDomain:Domain /NewDomain:Forest /NewDomainDNSName:syraxius.ath.cx

Now we have everything except the Safe Mode password. To do this, we'll specify it with /SafeModeAdminPassword. HOWEVER, we'll still need to specify it to install a DNS. Therefore we'll end up with:
dcpromo /ReplicaOrNewDomain:Domain /NewDomain:Forest /NewDomainDNSName:syraxius.ath.cx /SafeModeAdminPassword:User0000 /InstallDNS:Yes

This is the minimal command for setting up a DC with DNS through dcpromo in server core. It should restart automatically when it's done and you would have a DC.

Now you have a DC with no other roles. To install other roles, you'll need to make use of the "oclist" and "ocsetup" commands. However, you do need to configure it remotely. Future articles will take care of that.

Wednesday, June 16, 2010

Misc 35

Today we are going to do some SNMP graphing in Linux with Cacti. Cacti is known to be notoriously difficult to install in Windows, but in Linux we have a package which we can easily install:apt-get install cacti

For the installation, we'll choose to use "root" as the administrator. This account is required for creation of the tables. If you have a default installation, just type in "root" and proceed:


Now we'll enter the root password. It is "root" by default.


Next we'll create a cacti user for the database. This is the user would be the owner of the cacti table we would create in the next screen.


Enter the name of the table that cacti is going to use. The default should be good enough.


Now we'll choose apache2 to be the web server.


The rest of the process will be automated. Most of the configuration from now on will be done through the web interface at http://localhost/cacti/. Before we do anything with the server, we'll configure a Router to accept SNMP requests. The router will use the community-string of "HELLO" (without quotes) with RO:
en
conf t
snmp-server community HELLO ro


Now we can begin the configuration of Cacti. Log into the web interface and accept the license agreement (select New Install when prompted). When prompted for the versions of the tools, choose the highest from the list.

When prompted for the User Name and Password, use "admin" for both. You will then be asked to change the password. When you're done, you should be at this page:


Now at this point we would have to create a new host. To do this, click on "New Graphs" from the sidebar and click on "Create New Host":


I'll be using these settings. The ping settings doesn't need to be modified.



At this point you should be able to add some graphs. To do this, click on "Create Graphs for this Host":


In this example, I'm going to add a CPU utilization and an interface load graph


You are now ready to add the graphs into the tree. In Cacti, we work with a tree to organize the graphs. We'll keep it simple by adding the router to the root tree:


You would have to wait for some time for the router to have the "Up" status. Once it's up, you can browse over to the Graphs tab and you should see your Router listed.

Tuesday, June 15, 2010

Misc 34

Today we'll touch up a little on our Linux. We'll do a little bit of network monitoring through an open source monitoring system known as Nagios. Nagios would alert users when certain critical conditions are triggered and again when things become better. To install Nagios in Debian, use:apt-get install nagios3

Nagios is managed through a web interface. However, to log into Nagios's web interface, we'll need to create an account and make it an administrator. By default, the account named "root" would be administrator after it's created. However, to show you how to make another account an administrator, I'll use the account name of "kelvin". To create such an account, type:
htpasswd -c htpasswd.users kelvin

The -c parameter in htpasswd makes the tool create a new file. The file created is "htpasswd.users" and the user "kelvin" is created. After the command is typed, you would be prompted for a password. Enter anything you want and it would create a hash of the password in the htpasswd.users file. The htpasswd.users file is actually referenced from within /etc/nagios3/apache2.conf under the line:
AuthUserFile /etc/nagios3/htpasswd.users

Now, since "kelvin" is not an administrator, we'll need to browse into the configuration folder to make changes to some configuration file:
cd conf.d

The file we're interested in is the contacts_nagios2.cfg file. This file defines the contacts ("Administrative Users") which manage the Nagios system. This is so that we can easily manage what users are contacted when different events are triggered. Right now, we'll need to create a contact for Kelvin. To do this, we'll turn the root account's contact into a template. To do this, add in the "name" attribute as shown:
define contact{
name generic-contact
contact_name root
alias Root
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email root@localhost
}


Now that we've made the root contact as a contact template named "generic-contact", we can create the kelvin contact using the generic-contact. We do this by using the "use" parameter:
define contact{
use generic-contact
contact_name kelvin
alias Kelvin
email kelvin@localhost
}


Now that we have a contact for "kelvin", we'll need to put him under the administrators group. To do this, add him as a member in the "admins" contact group at the bottom of the file as shown:

define contactgroup{
contactgroup_name admins
alias Nagios Administrators
members root, kelvin
}


When you're done, do a restart of the nagios3 service as shown:
/etc/init.d/nagios3 restart

You should now be able to access the web interface through:
http://localhost/nagios3/

Now we'll do some simple monitoring on two systems called Kelvin-Laptop-1 and Kelvin-Laptop-2 at 192.168.1.151 and 192.168.159.1 respectively. We'll check if the systems are pingable. If they aren't, a notification will be sent to the emails of the contacts. We first need to specify a host. To do this, we'll need to add hosts into the generic-host_nagios2.cfg file. Notice that in the file we have a generic host template specified. This is the template we will reference when creating our new hosts. To create the two hosts, append these to the bottom of the file:
define host{
use generic-host
host_name Kelvin-Laptop
address 192.168.1.151
}

define host{
use generic-host
host_name Kelvin-Laptop-2
address 192.168.159.1
}


Now that we have the two hosts, it's time to explain how the services are applied to the hosts. Services can be applied to either hosts or hostgroups. Services are actually defined in services.nagios2.cfg. Notice that the services in there have a "hostgroup_name" parameter. This specifies which group of hosts the services should be applied to. The hostgroups are specified in hostgroups_nagios2.cfg. Another way to apply services is to apply it directly to a host. In this case, we use the "host_name" parameter instead, as shown in localhost_nagios2.cfg.

What we are doing now is that we want to apply the check_ping service to our hosts. If we scroll down, we'll notice that the check_ping service is applied to all hosts in the hostgroup "ping-servers". Therefore, we are now going to add our new hosts into the ping-servers hostgroup. To do this, modify hostgroups_nagios2.cfg as shown:
define hostgroup{
hostgroup_name ping-servers
alias Pingable Servers
members gateway, Kelvin-Laptop, Kelvin-Laptop-2
}


Take note that the "members" parameter refer to the "host_name" of the hosts and it is case sensitive. Do a restart on the nagios3 service and we should have the services coming up in the Service Details tab. If it all goes well, we'll see an OK beside each test. You can add services to the hosts by adding them into the appropriate groups.

Wednesday, June 9, 2010

Misc 33

Now we'll move into setting up an EzVPN server. EzVPN is Cisco's implementation of Remote-Access VPN through IPSec. We'll be using this topology as shown:


In this topology, we'll create simple access to the Left router by allowing clients to remotely VPN to the Outside interface of the ASA.

The Left router's configuration is simple. The interface is given an IP address, and a default route points to the ASA. Telnet access is also set up for testing purposes later on.

in f0/0
ip add 1.1.1.2 255.255.255.0
no shut
line vty 0 4
password cisco
ip route 0.0.0.0 0.0.0.0 1.1.1.1


Your computer and PIX's default gateway both point to the Right router which simulates the internet. Configuration is also quite simple for the Right router:
in f0/0
ip add 2.2.2.1 255.255.255.0
no shut
in f0/1
ip add 192.168.66.2 255.255.255.0
no shut
line vty 0 4
password cisco


Finally, we set up the ASA's interfaces:
in e0
nameif Outside
ip add 2.2.2.2 255.255.255.0
no shut
in e1
nameif Inside
ip add 1.1.1.1 255.255.255.0
no shut
route Outside 0 0 3.3.3.1


At this point, your computer should be able to ping the ASA's Outside interface. When you're ready we'll move on to setting up RAVPN. First we'll enable ISAKMP on the outside interface:
crypto isa en Outside

We'll then create an ISAKMP policy as we did before:
crypto isa pol 1
hash sha
auth pre
group 2
life 86400
encr aes


Similarly we'll create a transform-set:
crypto ipsec transform TRANSFORM esp-aes esp-sha-hmac

We'll then apply the transform set to a dynamic map:
crypto dynamic DYNAMIC 1 set transform TRANSFORM
crypto dynamic DYNAMIC 1 set reverse-route


Notice that we specified to create reverse-routes. Reverse-routes automatically injects routing information for connected RA clients. Now we'll create the crypto map using the dynamic map we have:
crypto map MAP 1 ipsec-isakmp dynamic DYNAMIC

At this point we can apply the map to the Outside interface:
crypto map MAP interface Outside

Now we'll begin setting up the tunnel parameters. First we'll create an address pool like this:
ip local pool POOL 4.4.4.10-4.4.4.20 mask 255.255.255.0

Next we'll create a user account:
user cisco pass cisco

We'll then create a tunnel-group as shown:
tunnel-group GROUP type remote-access

Now we'll set the pool and authentication-server-group in the general parameters for the tunnel-group:
tunnel-group GROUP general
pool POOL
authentication-server-group LOCAL


Finally we'll set the pre-shared-key for the IPSec negotiations:
tunnel-group GROUP ipsec
pre-shared-key cisco


At this point we would be able to connect to the Outside interface using the following parameters:
Host: 2.2.2.2
Group Authentication
Name: GROUP
Password: cisco
Confirm Password: cisco
Username: cisco
Password: cisco

We can also implement NAT if we wish. To do this, we'll begin with a basic NAT configuration:
nat (Inside) 1 0 0
global (Outside) 1 interface


Next, we'll create an access-list to match traffic that goes through the NAT. We'll use this list to perform an identity NAT.

access-list DENYNAT extended permit ip any 4.4.4.0 255.255.255.0
nat (Inside) 0 access-list DENYNAT


Now traffic going anywhere but to the RA clients would be NATted.

Tuesday, June 8, 2010

Misc 32

In this topology, we'll build on Site-to-Site VPNs. This time, we'll be using an ASA as one of the endpoints. Configuration should be so similar that you won't need any kind of reference if you know how to make use of the context sensitive help. We'll begin by going through the topology in this example, which looks like this:


In this topology, we'll establish a site-to-site VPN between the LeftOutside router and the ASA. I'll break down the interfaces as follows:
LeftInside
f0/0 - 1.1.1.2

LeftOutside
f0/0 - 1.1.1.1
f0/1 - 2.2.2.1

ASA
e0 - Outside - 2.2.2.1
e1 - Inside - 3.3.3.1

RightInside
f0/0 - 3.3.3.2

All network masks are /24. Suppose that LeftOutside and LeftInside is the HQ, and ASA and RightInside is the Remote Office. To protect the traffic between the two sites, we'll need to establish an IPSec tunnel between LeftOutside f0/1 and ASA e0.

For this setup I'll assume that routing is functional on both sides. The first thing we want to do is to set up IPSec on a familiar interface. We'll begin on LeftOutside:
crypto isa en
crypto isa pol 1
hash sha
auth pre
group 5
life 120
encr aes
crypto isa key 0 cisco add 2.2.2.2
crypto ipsec transform TRANSFORM esp-aes
ip access-l extended INTERESTING
permit ip 1.1.1.0 0.0.0.255 3.3.3.0 0.0.0.255
crypto map MAP 1 ipsec-isakmp
set peer 2.2.2.2
set transform TRANSFORM
match add INTERESTING
in f0/1
crypto map MAP


Note that I set the lifetime to 120. I usually set it to 60 but the lowest you can go on an ASA is 120 and so we must conform to that. Now we'll set up IPSec on the ASA. The commands are exactly the same, with some slight variations which you can iron out using the context sensitive help. We'll begin by enabling ISAKMP:
crypto isa en Outside

Now we'll set up the ISAKMP policy 1:
crypto isa pol 1
hash sha
auth pre
group 5
life 120
encr aes


Next, since authentication is set to PSK, we'll have to manually specify the key. Use this syntax:
crypto isa key cisco add 2.2.2.1

Now we'll create a transform set exactly like how you would on an IOS router:
crypto ipsec transform TRANSFORM esp-aes

Then we make an extended access-list permitting traffic from 3.3.3.0 to 1.1.1.0:
access-l INTERESTING extended permit ip 3.3.3.0 255.255.255.0 1.1.1.0 255.255.255.0

Finally we'll bring it together with a crypto map:
crypto map MAP 1 set peer 2.2.2.1
crypto map MAP 1 set transform TRANSFORM
crypto map MAP 1 match add INTERESTING


Now we'll apply the magical map to the interface:
crypto map MAP interface Outside

Monday, June 7, 2010

Misc 31

This is the followup of the previous article, and will use the same topology. As an example, we'll first begin by allowing the Perimeter router to telnet to hosts in the DMZ and User network. To do this, we'll need to make use of access-lists like in the IOS. The syntax is slightly different but you should be able to follow along just fine with the context sensitive help. We'll create two entries in the access-list allowing hosts in the 1.1.1.0 subnet to telnet to 2.2.2.0 and 3.3.3.0:access-list PERMITTELNET extended permit tcp 1.1.1.0 255.255.255.0 2.2.2.0 255.255.255.0 eq telnet
access-list PERMITTELNET extended permit tcp 1.1.1.0 255.255.255.0 3.3.3.0 255.255.255.0 eq telnet


For the list to work, we'll need to apply it. Since the traffic will be coming inbound from Outside, we use the following syntax:
access-group PERMITTELNET in int Outside

Try telnetting from Perimeter to User again. Lo and behold, it works! Here's another example for access-lists. Recall that we have a WebServer in the DMZ. We'll now allow web access from outside to the DMZ with yet another access-list:
access-list PERMITHTTP extended permit tcp any 2.2.2.0 255.255.255.0 eq www

Similarly, we apply the access-list to the outside interface to check on inbound traffic:
access-group PERMITHTTP in int Outside

At this point you can attempt to connect to the 2.2.2.2 server from the computer you have. You may need to create routing entries using the route add command like this:
route add 1.1.1.0 mask 255.255.255.0 192.168.1.1
route add 2.2.2.0 mask 255.255.255.0 192.168.1.1
route add 3.3.3.0 mask 255.255.255.0 192.168.1.1


At this point you should be able to have initiate a HTTP connection to 2.2.2.2 but not to 3.3.3.2. It is all working fine and dandy now!

Now that this is out of the way, we'll begin on NAT. NAT is set up using three commands. The syntax for specifying an INSIDE interface is:
nat (Inside) 1 0 0
nat (DMZ) 1 0 0


The syntax for specifying an OUTSIDE interface for PAT is:
global (Outside) 1 interface
global (DMZ) 1 interface


At this point there are a couple of things that would happen to traffic. Here is a breakdown:
Inside to DMZ - PAT to e1
Inside to Outside - PAT to e0
DMZ to Outside - PAT to e0

If we want the web server to be accessed from outside, what would we usually do on an IOS router? You guessed it, we would perform static NATting. Here's the third form of the NAT command:
static (DMZ,Outside) tcp interface www 2.2.2.2 www

This translates and redirects traffic directed at the Outside interface's www port to the web server's IP. However, the traffic would not be permitted. Why? This is because HTTP traffic directed at 1.1.1.2:80 would be denied even before it gets NATted. The solution? We'll need to add another entry into PERMITHTTP (and perhaps even remove the previous one if you have the time). To do this:
access-list PERMITHTTP extended permit tcp any 1.1.1.2 255.255.255.255 eq www
no access-list PERMITHTTP extended permit tcp any 2.2.2.0 255.255.255.0 eq www


Traffic pointed at 1.1.1.2 at this point would be redirected to 2.2.2.2. This wraps up basic firewall design. We'll now end this session with the setting up of basic management services. Telnet is the easiest to set up. To set up telnet, you simply specify the clients allowed to connect like this:
telnet 3.3.3.0 255.255.255.0 Inside
passwd cisco


To allow SSH, we simply generate a key with the crypto command, then specify the allowed users using the SSH command:
crypto key gen rsa
ssh 3.3.3.0 255.255.255.0 Inside


Now SSH should be set up. If you are logging into SSH without AAA, the username would be "pix" and the password would be whatever is specified in the passwd command. This concludes the PIX introduction.

Misc 30

I'll now do a quick run-through on the PIX7/ASA to set up a basic topology. The theory would not be covered in depth. This article will focus on getting you used to setting up PIX in a basic environment. The topology we'll be using is:


In this topology, I'll use routers in place of a User and a WebServer since a router can support both functions. The router named User will solely be used for inside to outside access, while the position marked You is where your physical computer will be, to test outside to inside connectivity.

First off we'll begin by describing the interfaces:
PIX7/ASA
e0 - Outside - 1.1.1.2
e1 - DMZ - 2.2.2.1
e2 - Inside - 3.3.3.1

Perimeter
f0/0 - 1.1.1.1
f0/1 - 192.168.1.1

WebServer
f0/0 - 2.2.2.2

User
f0/0 - 3.3.3.2

You
eth0 - 192.168.1.150

This topology uses a fixed subnet mask of /24.

Notice that the interfaces of the firewall are named. This actually is required when designing your firewall topology. PIX/ASA uses an algorithm coincidentally known as the ASA (Adaptive Security Algorithm) which manages stateful connections. A firewall being stateful means that it actually keeps the state table of connections. A stateful firewall dynamically allows return traffic from a connection originating from the inside network to go through, will blocking all connection attempts from outside by default.

PIX/ASA works around a security level system. Traffic going from a higher security interface to a lower security interface will be statefully permitted. This means that traffic originating from inside will be allowed and return traffic would be allowed once the connection is established. On the other hand, traffic going from a a lower security interface to one with higher or equal security will be denied by default.

We'll first begin by setting up basic connectivity. We'll start with the basic routers. We'll throw in OSPF to do routing for us. Hop on over to User and type:
en
conf t
ho User
in f0/0
ip add 3.3.3.2 255.255.255.0
no shut
line vty 0 4
pass cisco
router ospf 1
network 3.3.3.2 0.0.0.0 area 0


Next, hop on to WebServer and type:
en
conf t
ho WebServer
in f0/0
ip add 2.2.2.2 255.255.255.0
no shut
line vty 0 4
pass cisco
router ospf 1
network 2.2.2.2 0.0.0.0 area 0


Finally we set up the Perimeter router:
en
conf t
ho Perimeter
in f0/0
ip add 1.1.1.1 255.255.255.0
no shut
in f0/1
ip add 192.168.1.1 255.255.255.0
no shut
line vty 0 4
pass cisco
router ospf 1
network 1.1.1.1 0.0.0.0 area 0
network 192.168.1.1 0.0.0.0 area 0
passive f0/1


Now we'll focus on the PIX7/ASA. By default, the password is blank, so go ahead and move into privileged mode:
en

Now we'll set up the enable secret and hostname:
enable password cisco
ho ASA


For any connectivity to take place, we'll need to set up the interfaces. The process for setting up the interfaces is to first give it a name, assign it a security level and an IP, then turning it on:
in e0
nameif Outside
security 0
ip add 1.1.1.2 255.255.255.0
no shut
in e1
nameif DMZ
security 50
ip add 2.2.2.1 255.255.255.0
no shut
in e2
nameif Inside
security 100
ip add 3.3.3.1 255.255.255.0
no shut


At this point, Inside hosts can statefully exit to any interface. DMZ hosts can statefully exit to Outside. Outside hosts will require explicit authorization to enter the network.

Recall that we actually enabled the OSPF routing protocol on the routers. It's time to enable it on the PIX as well. OSPF is strikingly similar. The biggest difference is that you no longer deal with wildcard masks:
router ospf 1
network 1.1.1.0 255.255.255.0 area 0
network 2.2.2.0 255.255.255.0 area 0
network 3.3.3.0 255.255.255.0 area 0


It's time for some verification. To see the routing table similar to how "show ip route" in IOS works, type:
show route

For an equivalent of "show ip int br" in the IOS, type:
show int ip br

Now it's the first test of statefulness. We'll attempt to telnet from an inside host to an outside host. Coincidentally, we have User and Perimeter routers right for the job. Hop on to User and type:
telnet 1.1.1.1

The connection should go through just fine! Now, we'll try it the other way round. Hop on to Perimeter and type:
telnet 3.3.3.2

The router would be trying and failing! This is happening because inside-out connections are statefully allowed, while outside-in connections are all blocked! In the next article, we'll describe a few ways of allowing access outside-in and talk about NAT in the process.

Friday, June 4, 2010

Misc 29


Recall that GRE doesn't have its own encryption capabilities. In this case we would have to run GRE over IPSec. Configuration in this case is strikingly similar to the site-to-site VPN that is described in the VPN Introduction section. The biggest difference is that instead of using tunnel mode which is the default, we would have to switch to transport mode.

Recall that tunnel mode encrypts the entire IP packet including its header and encapsulates it in a new packet. Transport mode only encrypts the payload of a packet. Tunnel mode's operation is strikingly similar to GRE. In this case, we would use transport mode because GRE takes care of the outer IP encapsulation.

Let's begin on R1. As previously mentioned, the procedures are the same so you would need to read VPN Introduction if you need some revision on what the commands do. Head on to R1's console and enable ISAKMP:
crypto isa en

Next, create a policy map:
crypto isa pol 1
hash sha
auth pre
group 5
life 60
encr aes


Since authentication is pre-shared, we would have to specify a common key:
crypto isa key 0 cisco add 3.3.3.2

Now we would have to create the transport transform set. The only difference is that you would have to change the modes in the transform set prompt:
crypto transform TRANSFORM esp-aes
mode transport


Now we'll create the list of interesting traffic. Note that for traffic going through the tunnel, you would only have to specify the tunnel interface as interesting:
ip access-l extended INTERESTING
permit ip 1.1.1.2 0.0.0.0 3.3.3.2 0.0.0.0


Now we finally create the crypto map:
crypto map MAP 1 ipsec-isakmp
set peer 3.3.3.2
set transform TRANSFORM
match add INTERESTING


We do the same, mirrored, for R2:
crypto isa pol 1
hash sha
auth pre
group 5
life 60
encr aes
crypto isa key 0 cisco add 1.1.1.2
crypto transform TRANSFORM esp-aes
mode transport
ip access-l extended INTERESTING
permit ip 3.3.3.2 0.0.0.0 1.1.1.2 0.0.0.0
crypto map MAP 1 ipsec-isakmp
set peer 1.1.1.2
set transform TRANSFORM
match add INTERESTING


In this example, any traffic going through the GRE tunnel would be automatically encrypted by IPSec. If you need to specify more VPN endpoints, you would create a new set of interesting traffic list and use the command "crypto map MAP 2 ipsec-isakmp" to specify the alternate mappings to use.

Misc 28

There are times where you want to share routes across the internet using internal routing protocols such as OSPF. In this case, we would need to have a direct point-to-point link between the sites. However, this would mean that you would have to either purchase a private line of some sort.
Thankfully, all that is in the past. Cisco systems developed a tunneling protocol known as the Generic Routing Encapsulation that allows point-to-point links to be set up by encapsulating layer 3 protocols in IP packets.

In this example, we will be using this topology to demonstrate the concept:



Notice that the GRE tunnel has an IP address on each end. It's as if the router has another point-to-point interface through the internet. However, note that GRE is not encrypted by default so we will need to leverage on IPSec in the next article. This article will focus on setting up GRE and running OSPF through it.

First of all, I'll assume that you are able to ping across to the other side (e.g. ping 3.3.3.2 from R1 and ping 1.1.1.2 form R2). Now we'll start creating the GRE tunnel. We'll need to do this on both sides. First, on R1, type:
in tun 0
ip add 10.10.10.1 255.255.255.0
tunnel source f0/0
tunnel destination 3.3.3.2


Then on R2, we type:
ip add 10.10.10.2 255.255.255.0
tunnel source f0/0
tunnel destination 1.1.1.2


At this point if all goes well, you should be able to ping each other's tunnel interfaces. We'll begin with the routing protocols. First of all, we'll want to have some kind of routes to advertise. We'll make some loopbacks on R1 as shown:
in lo0
ip add 192.168.0.1 255.255.255.0
in lo1
ip add 192.168.1.1 255.255.255.0
in lo2
ip add 192.168.2.1 255.255.255.0
in lo3
ip add 192.168.3.1 255.255.255.0


We'll then start the routing process on R1:
router ospf 1
network 10.10.10.1 0.0.0.0 area 0
network 192.168.0.0 0.0.3.255 area 0


On R1, we'll do this:
router ospf 1
network 10.10.10.2 0.0.0.0 area 0


At this point, you should be exchanging neighbors. Test that you can ping the 192.168.x.x loopbacks from R2.
<