Sunday, December 12, 2010

Cisco Network Assistant

Automatic Topology Creation via CDP
So today I've finally played around with Cisco Network Assistant which is essentially the same as the Cisco Configuration Assistant that's used to configure the UC500 device. For all the people studying for the CCNA:Voice, I'm sure you're well aware that Cisco Configuration Assistant is mentioned quite a bit during the UC500 chapter. It was good to get at least somewhat exposed to the software as I didn't want to shell out the money to buy a UC520 just to learn the few basics of configuring it.

Configuring Switch Port Settings through 2D GUI


I went through all the various tabs i could find and I will admit that it's a lot more feature rich than what i expected, especially if you're connecting a a compatible CCA Cisco device to it, such as the UC520. Tomorrow's lab will consist of configuring FXS connectivity using the following lab diagram:

Verifying FXS Connectivity Lab 5-1


I will say that the IP Telephony CME Labs are quite handy as it's teaching me different ways to manipulate the CME features in different environments.

Tuesday, December 7, 2010

Be careful of the IP Route command on a Switch Pt. II

As I was making a frozen pizza (don't laugh!) it hit me that I believe the reason I couldn't ping any of the other VLAN's was because the ip route command turned my switch into a L3 capable device. I didn't tell my switch how to get to the other subnets via a static route/dynamic route since it was now basically a router as well. It could reach the router still because it was on the same subnet 10.1.0.0 /24.

I didn't have time to test this theory but I'm 90% positive this was the issue!

Be careful of the IP Route command on a Switch

Well I decided to tear down my current voice lab and rebuild it as i work my way through the "IP Telephony Using CallManager Express Lab Portfolio" workbook. One of the labs I was working on required me to create RoAS (Router on A Stick) and I had everything configured and for some strange reason I couldn't ping between the other VLAN'S. This was due to having the ip route command configure by accident on my switch. I'll be honest and admit that I'm not quite sure how this effects routing quite yet, if you know feel free to leave a comment.

A colleague at my current job ran into the exact issue as he was making some IP address range changes on one of our remote sites. He was lucky and was able to have someone on site connect a console cable for him to connect back to the switch to remove the command. While all the devices stayed up he lost connectivity to the switch completely.

In other news I FINALLY scheduled my CCNA:Voice test for January 4th! I really need to pass on the first go round as the cut off date for IIUC is Febuary 28th and then it switches to the ICOMM series.

Saturday, November 27, 2010

Creating Voip Dial Peers

Well I figured I would make use of the extra T1 ports that I had on both my 1760 routers and create some voip dial-peers since I had the dial-peer pots working really well. While I have one T1 broken out as a simple CAS connection for making a PSTN type connection. I created the other one as a data T1 with IP addresses on each end to simulate a WAN network. Here's a small snippet of my 1760 that's acting as a remote router's running config:

This is configured to be a simple CAS T1
controller T1 0/0
 framing esf
 linecode b8zs
 ds0-group 1 timeslots 24 type e&m-wink-start


This is configured to be a WAN T1 connection
controller T1 0/1
 framing esf
 linecode b8zs
 channel-group 0 timeslots 1-24

This dial-peer is configured to send calls out of the CAS T1
dial-peer voice 1001 pots
 description outbound calls to x1001
 destination-pattern 915551001
 port 0/0:1
 forward-digits 4

This dial-peer is configured to send calls out of the WAN T1
dial-peer voice 8008 voip
 description outbound calls to x1001 using IP
 destination-pattern 915551001
 translate-outgoing called 1
 session target ipv4:69.1.1.1

Obviously I don't have both T1's up at the same time, I did this however to experiment with the different things that will happen depending on how the call is sent out of the gateway. This type of configuration will be useful for the CCNP:Voice I bet, I can have certain calls forward out through the WAN and others out of the PSTN. Or I can create some type of configuration in CUCM that'll allow for calls to be forwarded out of the PSTN if the WAN connection fails!

Friday, November 26, 2010

UCCX Holiday Scripting....Doh!

My current employer is a medium sized call center with IPCC Express used for their contact center solution currently. I'm still learning my way around UCCX but I'm getting there, I can program basic scripts and troubleshoot basic issues. We use over 40 different queue scripts that all calls out to the same default holiday script. This script then points to a very simple XML file that lists calender dates that is edited with notepad. If the holiday condition is met, the original script then inputs the variable set (usually set to change to the "closed" setting).

There was one queue that was supposed to be open today (oops) so I had to create a duplicate script called "holiday_Alternate" that called out to a similar XML file except it didn't have today's date (11/26/2010) listed therefore the original queue script was set to open instead of closed.

Thursday, November 25, 2010

Configured My First ASA this Week

I configured my first ASA this week and what a mess it was! Oh well it was a good intro to getting hands on with some of the security side of things. When one of our remote sites was initially built, there wasn't any internet availability in the area due to it being in a more rural location. To remedy this, all internet traffic was delivered over our MPLS and then out of our corporate site to access any external website. Recently the area finally offered simple business DSL connectivity (that was more than enough for this location) and we asked for this service pretty quickly.


Well of course we didn't want to just connect a non-secure DSL connection to our network so we needed a simple firewall aka ASA 5505 to provide a buffer between our remote sites network and the outside world. Once all was said and done/configured it was actually pretty simple but I ran into many bumps along the way. The first thing was that the new ASA had NO configuration whatsoever on the device, not even the factory-default settings. The device was asking for a username and password which wasn't configured so after about 3 hours of mucking around I ended up finally getting in by using the ROMMON mode and changing the configuration register to 0x41. This tells the ASA to ignore the saved start-up configuration, from there I entered the command configure factory-default which put the right factory default settings on the device it should of had to begin with.

The only thing I could think of is that maybe they forgot to throw this command on the device before shipping it out lol. After that fiasco now I had to figure out to configure it finally! It wasn't to bad but I ran into some weird things mainly due to the silly DSL modem itself. The DSL provider configured the modem to work in "pass through" mode so it didn't do anything besides provide a bridge between the ISP and the ASA, it took me a while to realize that. So I had to battle NAT configuration, IP Addresses, and ASA port configuration.

What confused me the most was how I had to tell the ASA what it should and shouldn't know. The ASA had no problems reaching the internet or the internal network. However internal devices could only reach the ASA and not the external world, not even the ASA's outside interface. At first I thought this was due to access-lists I had configured. Turns out it was because NATing wasn't configured all the way and I hadn't specified the internal network IP range the ASA should know about.

I used ASDM and even a little CLI to finally get the thing working. Commands I'll never forget is the route inside and route outside which is similar to the ip route command used on routers and L3 switches.

Sunday, November 21, 2010

CME Music On Hold

Ever since I've read past the CCNA:Voice section regarding Music on Hold (MOH) I've been trying to get it working ever since. The problem I ran into is that I couldn't get MOH to work when I placed a call from one IP Phone to another in my internal network, just dead silence. After some research, apparently this a known issue depending on how you configure MOH. In order for this to work between IP Phones in your internal network, you're supposed to use multicast rather than the default method. Even with multicast configured and every option I could think of, I still couldn't get this working.

Well after completely forgetting about MOH and eventually setting up my remote network weeks later, I was reviewing a few CBT's when it hit me that MOH should work when putting external callers on hold. I placed a call to the analog phone on the remote network and then put them on hold, sure enough it worked! I will admit though that the quality wasn't great because I was using the G.729 codec across my WAN and I'm betting that this analog phone is at least 15 years old!

Thursday, November 11, 2010

The Smart Business Communications System

I finally knocked out the book for the CCNA:Voice this evening, the last two chapters were based on the Smart Business Communications System (SBCS). To be honest both chapters felt like one huge sales pitch but there was some useful information that I'm sure will be on the exam. As far as I understand, the SBCS suite is based around the Cisco UC500 product family and how they interconnect between each other.

The main player within the SBCS is the UC520 ISR which is pretty slick within itself, especially if you're a non-Cisco person. It enables you to have a router, firewall, POE switch, PBX, Wireless, and many other features within one small device. The UC520 itself seems fairly straightforward, especially with the web based GUI tool called Cisco Configuration Assistant (CCA). Now that I finish these last few chapters it's time to review over the next few weeks and then exam time!

Monday, November 1, 2010

Cisco Unity Express Hardware Limits


It's important to know that you're limited with voice mail size limits based on the Cisco Unity Express hardware itself. Below I have listed the four different hardware size's and their limitations that I'm assuming will be on the exam:
  • Cisco Unity Express Advanced Integration Module (AIM-CUE)
50 mailboxes
14 hours of storage
4-6 ports for voice sessions depending on the router model

  • Cisco Unity Express Network Module (NM-CUE)
100 mailboxes
100 hours of storage
8 ports for voice sessions

  • Cisco Unity Express Network Module with Enhanced Capability (NM-CUE-EC)
250 mailboxes
300 hours of storage
16 ports for voice sessions

  • Cisco Unity Express Enhanced Network Module (NME-CUE)
250 mailboxes
300 hours of storage
24 ports for voice sessions

Sunday, October 24, 2010

Complete Voice Network


Today I wrapped up the last bit of configuration I needed to do to complete my CCNA:Voice lab setup (besides Unity Express). I am now able to place calls not only internally but also to my remote site via a PSTN connection. I have four more chapters to go and then it's time to review and prepare for the test. I want to take and pass the exam sooner than later because the certification is being completely revamped and I only have until February 28th to take to current version. I already feel pretty confident, especially after I was able to finally dig into dial-peers and the many ways you can manipulate them.

Saturday, October 16, 2010

VoIP Trunking Protocols

With most business that integrate VoIP into their network, they not use VoIP technology within their own LAN but also across WAN's to remote sites, other businesses, ISP's, etc. There are a few popular voice trunking protocols to pick from and I'm starting to learn the history and details behind each. There are four voice gateway protocols that I hear and see configured quite a bit in the voice networks I've seen so far.

1. H.323: This is a pretty mature and older voice protocol that was created primarily for connecting to other networks using the ISDN connection. This doesn't surprise me as I see this used mainly on PSTN connections to ISP's. While the protocol is pretty stable, there are a lot of features newer protocols handle better along with being easier to manage. When I run the debug command debug isdn q931 on a gateway, the information is usually pretty cryptic and hard to undertstand.

2. MGCP: I see this protocol used all the time in the Cisco VoIP networks, apparently Cisco is really the only vendor that uses this protocol even though it's an open standard. MGCP is a centralized based configuration.

3. SCCP: Again this is only on Cisco VoIP networks because this is Cisco's proprietary protocol. This protocol is used specifically for communication with Cisco IP Phones and other Cisco endpoints such as ATA's.

4. SIP: This is the new kid on the block and it's still being developed constantly. SIP is basically a lighter and more feature rich version of H.323. Except that it is based on VoIP instead of ISDN, it uses a lot of the same standards that HTTP uses which makes it a lot simpler to develop. I haven't touched SIP yet but I've heard a LOT about it. There's actually a forum that is very involved with this new protocol, check it out at www.sipforum.org

Sunday, October 3, 2010

First Hands on With QoS


As I dive deeper into the VoIP world, I'm starting to learn just how important QoS (Quality of Service) is in a network. QoS is a complicated topic and for good reason, not only because the configuration can be quite involved, but also their can be a lot of corporate politics involved. QoS comes into play when a network is congested, instead of having a router just drop random packets that it can't route you can prioritize which specific packets should be sent from most important to least important. With the least important being sent to the "bit bucket (gone forever)" most likely. With this said RTP voice traffic is very time sensitive, when there is latency it upsets the way it is sent to the receiving end and in turn usually upsets the end user as it can cause echoing, dropped calls, and a plethora of other issues.

You should prioritize voice and video traffic before other traffic in most environments...well unless the CEO steps in and demands that his e-mail and internet traffic is more important than any other traffic! There are essentially 3 steps to configuring QoS:

1. Identify and match packets with the class-map command
2. Prioritize traffic with the policy-map command
3. Assign the QoS policy to the impacted interface with the service-policy command

You can see a sample configuration in the picture above that I was messing around with in GNS3.

The Many CME Phone Features


Over the last few weeks I've been reading and toying with the many different phone feature settings that you can configure through CME. While there are still many options I haven't covered quite yet such as Intercom, Music On Hold, and Paging, I've learned a lot about what you can do using the ephone commands on the CME gateway. By far the most confusing part for me has been the configuration of hunt groups and how to route and stop the calls within hunt groups and to other hunt groups. It's a lot easier to understand when you're looking at a full Call Manager GUI rather than from ephone-dn commands!

Sunday, September 19, 2010

DHCP IP Exclusion Command


As I was reading one of the CCNA:Voice chapters I noticed that my phones were picking up the wrong VLAN IP addresses. I spent hours and hours today working the issue until I realized what it was. My DHCP router has two dhcp pools to pick from when handing out IP address, one named VOICE for my IP phones (172.16.1.0 /24) and one named DATA (172.16.2.0 /24) for PC's and everything else simply enough. I like to exclude a small range of IP's from being handing out becuase you'll see this in most real world environments. So I excluded 10 IP's on both dhcp pools, 172.16.x.1 - 10 which allows me 20 IP addresses for servers, future routers, etc. Well what I didn't pay attention too was that I accidentally excluded the range 172.16.1.1 to 172.16.2.10 instead of this:

172.16.1.1 to 172.16.1.10 (10 spare IP's on the VOICE VLAN)
172.16.2.1 to 172.16.2.10 (10 spare IP's on the DATA VLAN)

I didn't notice that this was causing the issues because it was still handing out IP's but only from 172.16.2.11 on up obviously. Once I caught the error and typed this command:

ip dhcp excluded-address 172.16.2.1 172.16.2.10
ip dhcp excluded-address 172.16.1.1 172.16.1.10


Sure enough both phones picked up the right IP addresses, well after I restarted the phones from the voice router that is.

Sunday, September 12, 2010

Internal VoIP Network

I'm finally back from traveling and had some downtime to begin studying once again. I was able to finish setting up my internal VoIP network and I can place calls between both phones now. The configurations for the phone settings is done through the router CME using ephone commands. I assigned one phone extension 1001 and the other 2002. Once I get a little further in my studying I'm going to configure the T1 connections between my two 1760's to simulate placing calls to a remote site over a WAN link. I'm planning on taking the CCNA:Voice test before the end of the year so I can begin ramping up for the CCVP a little after April once I'm in my new place.

Monday, August 30, 2010

Uploading CME Files


I spent most of this evening trying to upload the full featured Call Manager Express (CME) tar files to my Voice router. I was doing very well until I realized that I didn't have enough Flash memory to support the full version! Thankfully I was able to find the basic version which should be enough to get me through the studying and the test.

It was very time consuming deleting all the old files but I did learn a new command which I've never heard of, it's called the squeeze command. It's for sure one the weirdest command names in the Cisco IOS. Here's how it works, by default when you delete a file from flash, it really doesn't delete it rather it marks it as deleted so you're not gaining your flash memory space back by just typing the delete flash: command. The squeeze command however goes through the entire flash directory and removes any files marked as deleted, it works fairly well but is time consuming also.

Sunday, August 29, 2010

Beginning The Setup of My Voice Network



I've been really busy over the last few months with this one being the busiest with me working 16-22 hour days. This is due in part of me installing and bringing up new networks for a few of our remote sites that's growing in size. I'll be in St. Paul MN this Wednesday and won't be back until Tuesday of next week if all goes well. I finally had a little downtime to get some studying in. After about 1 month of researching and about $700 later I had purchased everything I needed for my CCNA: Voice lab.



After I plugged everything in I did some of the initial configuration based on the CBTNuggets CCNA: Voice videos. I ran into an issue that stumped me for a long time however which was due to none of my phones or PC was receiving an IP address from the DHCP server I configured on my 2620 router. It turns out that my 7960 and 7940 didn't like the simplified vlan configurations much on my switch.

I had the following configured at first:

switchport mode access
switchport access vlan 50
switchport access voice vlan 10

I had to change the configuration to the old way:

switchport trunk encap dot1q
switchport mode trunk
switchport trunk allowed vlan 10,50
switchport access vlan 50

Once I added this all my devices starting picking up IP addresses. The only thing I can think of at this point is that maybe the older IP Phones don't accept the new way of switch vlan configuration but I'm sure I'm wrong and may be missing something.

Sunday, August 15, 2010

Learning The Analog World


Before I begin digging deep into the VoIP part of my studies I spent the last 3-4 weeks studying more about the PSTN world. Mainly how analog voice signals is converted into electric and eventually binary signals. This process is called Pulse Amplitude Modulation (PAM) if your converting analog to electrical values and Pulse Code Modulation (PCM) when you're converting the PAM values to binary.

An engineer named Dr. Harry Nyquist noticed that human voice only uses between 20-9000 Hz. He figured out if you take samples of the voice signals at twice it's frequency rate, you can accurately send the signal over a medium and play it back without any noticeable sound distortion.

The problem with that if you sampled the highest frequency range that a human can reach (18,000 digital samples per second), it would require a lot of bandwidth for each voice call. To remedy this he lowered the frequency range to 4000 Hz (8,000 samples per second) since rarely do humans ever speak above this range and if they did it would probably be pretty annoying.

With that said, the 8000 sample rate per second plays nicely with the digital world. The rule states that each sample is 8 bits (1 Byte).

Therefore 8000 samples * 8 bits = 64,000 bps (64 kbps)

Does 64 kbps sound like a familar term you hear? It should as 64 kbps equals the same size as one ds0 channel in a T1. Remember a T1 has twenty four 64 kbps ds0 channels that makes up the entire T1 speed of 1.536 Mbps (24 * 64,000 bps = 1,536,000 bps) with T1 framing signaling the T1 size is actually 1.544 Mbps.

Saturday, August 7, 2010

CCNA: Voice

So I'm finally preparing for the voice certifications, I've been reading a lot of material over the last few months but I'm officially getting into study mode again. I started going through the CCNA Voice CBTNugget videos and taking notes along with ordering the CCNA:Voice study guide. I'm still finishing up pricing out my lab but I'm hoping to spend less than $800 total on it. I have phones I can use at work along with some other hardware probably so that should help. I'm going to use one of the lab guides from techexams.net to help determine what I do and don't need. I plan on going after the CCVP straight after that and then who knows maybe CCIE Voice!

I have to travel quite a bit for work over the next month so I probably won't really dig into my studies until the end of September hopefully.

Saturday, July 10, 2010

Internal Router Switching



Something that's over looked during CCNA/CCNP studies is the actual switching that's done on the router. Of course the switching a router does and the switching done on an actual switch is completely different. When speaking of switching on a router it deals with the process of forwarding a packet from one interface on the router to another interface on the same router. This process can be extremely CPU intensive for the router to do. However with the use of certain router switching tecnologies such as "Fast Switching" and Cisco Express Forwarding (CEF) you can significanlty decrease the amount of work the router's CPU has to do.

In the lab I created, I told the internal router to ping the "website" router with 1000000 packets (to simulate traffic). While doing this I disabled CEF and Fast Switching note what happened below:


Note that each exclamation point means that the packet was successfully forwarded and that each period means that the packet was dropped. Looking near the end of the picture you can see when I disabled CEF and the packets were too processor intensive for the router to handle and queue so it started dropping packets to keep up with demand. For testing purposes I increased the packet size to help bog down the router so that you can see the example shown.

Saturday, June 26, 2010

Configuring HSRP Protocol


I spent a little time this morning learning about the HSRP (Hot Standby Router Protocol) and how to configure it in a real world environment. This is something that I might think about implementing in our networking system actually. It works by creating redundancy between two routers in case one router loses internet connectivity, the other router can take over. The configuration was rather simple and easy to understand. You're basically creating a virtual IP (VIP) that your internal network will use rather than the routers actual Ethernet IP address. I have including a sample configuration below:

Router_A#sh run int fa0/0
Building configuration...

Current configuration : 166 bytes
!
interface FastEthernet0/0
ip address 192.168.100.2 255.255.255.0 (actual IP address)
duplex auto
speed auto
standby ip 192.168.100.1 (VIP address configured on Router B as well)

standby preempt (Tells the router to try and become primary when circuit is back up)

standby track Serial0/0 10 (decrements HSRP priority, router with highest is primary router)

end

Sunday, June 20, 2010

Creating GRE Tunnels


Today was a pretty simple lab, I went through the configuration of GRE Tunnels between two different remote locations. GRE configuration is very simple and consists of the following commands on both device:

1. Create the logical tunnel interface on both remote devices:

interface tunnel X

2. Assign an IP address to the tunnel interface:
ip address X.X.X.X subnet mask

3. Point the tunnel towards the source interface:

tunnel source interface

4. Point the tunnel towards the destination interface:
tunnel destination X.X.X.X (remote device ip)

One thing to note when creating tunnels is that the remote destination must be in the routers ip table. That's about it though, you should see your tunnels come right up once everything is configured on both ends. Remember that GRE tunnels are unencrypted so it's best to route the tunnels through some type of security device such as an ASA or even a dedicated VPN concentrator.

Saturday, June 19, 2010

Preventing Redistributed Routing Loops


Today I ran over a quick lab of something you may experience in the real world, routing loops due to redistribution. As shown in the picture above, both the routers R1 and R2 are redistributing the same networks both ways. Because of Administrative Distance, each router would think the best route to EIGRP were through each others OSPF interfaces and vice versa which would cause a routing loop.

To circumvent this, I have created a route-map and assigned tags to both routing networks to prevent redistributed routes to be learned in both directions:

(Running Configurations on Both R1 and R2)
router eigrp 1
redistribute ospf 1 route-map OSPF-to-EIGRP
network 20.0.0.0
default-metric 100000 100 255 1 1500
no auto-summary
!
router ospf 1
log-adjacency-changes
redistribute eigrp 1 subnets route-map EIGRP-to-OSPF
network 10.0.0.0 0.255.255.255 area 0
default-metric 100
!
route-map EIGRP-to-OSPF deny 10
match tag 90
!
route-map EIGRP-to-OSPF permit 20
set tag 110
!
route-map OSPF-to-EIGRP deny 10
match tag 110
!
route-map OSPF-to-EIGRP permit 20
set tag 90

I'm going to be learning about GRE tunnels shortly as well, hopefully it isn't to complicated to grasp, VPN's and tunneling always confused me because I have a habit of over complicating things!

Sunday, June 6, 2010

Lab Portfolio Case Study 1


It took a while but I was able to finally finish the first case study presented in the CCNP Lab Portfolio book. I was rusty on a few topics but I was able to complete the following:

1. Enable EIGRP 1
2. Summarize the 5 loop back address on R2 (not presented in above image)
3. Inject a default route into the EIGRP network pointing towards R3
4. Configure OSPF between R3 and R4
5. Redistribute OSPF into the EIGRP network
6. Inject a default route into the OSPF network pointing towards R3
7. Configure DHCP on the R2 router in order for R3 to gain an IP address on its LAN (Fast Ethernet) interface.

All in all not to bad and it allowed me to brush up on the topics that I always forget! I'm digging pretty deep into my voice studies already. This morning I read through a lengthy overview on the history of Call Manager and VoIP in general. I'll probably finish that up by going through some white papers on IPCC along with the network warrior book.

Friday, June 4, 2010

IPv6 Challenge Lab


I finished today's lab which was a challenge lab, which basically makes you configure the network without any instructions besides IP configuration information. I was able to complete all required tasks successfully which included:

1.Enabling IPv6 EUI-64 between the R3 and R4 routers 2.Enabling EIGRP without auto summarization 3.Creating a manual IPv6 tunnel between the R1 and R3 router 4. Enabling OSPFv3 on all routers using IPv6 (R1,R3,R4)

While I'm about finished with the portfolio book, I'm about to dig even deeper into voice shortly, especially IPCC for my new job. I also picked up the network warrior book and reallly wished I would of had this a year ago, it gives some very good information how a live network operates and what happens in the real world instead of just topics you see on the CCNA.

Saturday, May 29, 2010

IPv6 6to4 Tunnels


Today I configured another type of IPv6 tunnels used to alleviate the headaches of switching to an entirely different IP format in a network! It's called a 6to4 tunnel and it does exactly what the name says. It encapsulates a Ipv6 address within a IPv4 packet so that it can use the IPv6 address locally and still travel across a IPv4 network. Do to the nature of this type of tunnel, it doesn't need to be configured on both ends of the tunnel since it's not considered a point-to-point link. To configure a 6to4 tunnel I used this simple command:

First I configured the logical tunnel:


R1 (config)# interface tunnel 0
R1 (config-if)# tunnel mode ipv6ip 6to4
R1 (config-if)# ipv6 address ipv6 address
R1 (config-if)# tunnel source interface
R1 (config-if)# exit

Second I configured a static route to point towards my tunnel:

R1 (config)# ipv6 route ipv6 address tunnel 0

This tells the router to send this particular IPv6 address out tunnel 0 and tunnel 0 routes this interface out of the source interface.

Monday, May 24, 2010

Using IPv6 Tunnels


Today's study session consisted of creating a Ipv6 Tunnel connection between two routers. OSPF IPv6 was also configured for the loopback interfaces on routers R1 and R3 to talk to each other. This lab was fairly straightforeward and allowed for me to play around with tunnel interfaces a little bit. I come across tunnel interfaces quite a bit in my current job role so it was good getting some practice in with configuring them even if they were IPv6 tunnels which aren't to common yet in most networks! My next IPv6 lab will be on configuring 6 to 4 tunnels which is a tunnel that allows you to encapsulate IPv6 address into a IPv4 packet to traverse over a network. This is particularly useful in networks that haven't migrated to IPv6 completely yet (which is most networks).

Sunday, May 23, 2010

Configuring OSPF for IPv6


I'm finally on the last chapter in the CCNP Portfolio book which covers IPv6 topics. Today's lab was dealt with configuring the many types of IPv6 address (link-local, EUI-64, etc). The lab ended with configuring OSPF over IPv6 along with a challenge lab. The challenge lab consisted of summarizing two IPv6 addresses over OSPF. All in all it was very straight foreword, when it comes to configuring IPv6 I noticed that it's very similar to it's older brother IPv4 except the order you place commands and the way you implement them on your router device. I was very surprised honestly that it worked over the switch as well, I figured the GNS3 switch wouldn't understand how to interpret the IPv6 address in its MAC table but I was wrong thankfully.

Saturday, May 22, 2010

Multilinks Revisted


So I wasn't able to work through one of my CCNP Portfolio labs this morning so I subsituted with something I deal with commonly..multilinks. I've posted on this topic before and it's really straight forward to configure. Basically your load-balancing data across all of your T1 links in a simple but effective manner. You do this through the use of the PPP protocol and a logical interface called a Multilink (go figure). Say you have a business that wants to use 3 Mb of data rather than the standard 1.5 Mb, you can take their 2 serial interfaces and bundle them into one with two simple commands:

ppp multilink
ppp multilink group


You also have to create the multilink interface and assign the multilink the designate IP address as shown above. Thanks to GNS3-labs and Evil Routers for today's lab.

Monday, May 10, 2010

Multicasting Dense Mode


I spent a good part of my morning working my way through the second multicast lab in the CCNP portfolio book the best I could. Since I didn't have a real switch that could emulate SVI (I don't think) I had to use GNS3 the best I could for the IGMP snooping. Multicast is by far the hardest topic for me so far and I still don't understand it honestly. I know enough to get by but it's still very confusing and works differently then any of the routing protocols. I did understand a little more about how the multicast tree is built however using other routing protocols are RPF (reverse-path forwarding). this will for sure be a topic I'll have to spend extra time on understanding, tomorrow is another multicast lab using PIM sparse mode instead of dense mode.

Thursday, May 6, 2010

BGP Policy Based Routing


I had a lot of trouble with this lab and was very confused and overwhelmed quickly trying to get the BGP routes to traverse correctly through the main SanJose router. The SaneJose2 router was supposed to be the back T1 and all traffic coming in and out should only flow through the main SanJose router. While I was able to get mostly everything working, I had problems getting the local preference settings to work right and I had RIB failures on top of that in my routes which is never a good thing lol. I'll have to come back to this lab or work through some other BGP labs to figure out what I was missing or doing wrong.

Wednesday, May 5, 2010

BGP AS_PATH Attribute


I've been working through the BGP section in the CCNP Lab Portfolio book over the past week. This morning I went over a short lab regarding the AS_PATH Attribute. It's kind of strange that the BGP labs have been the shortest labs so far, you would've thought BGP would of been a pretty big section.

As other people mentioned, this chapter has a lot of mistakes and it makes the configuration of the labs confusing. You don't know if it's you not configuring the routers right or the book giving the wrong information.

Even still I managed to get through this chapter which consisted of created a special BGP access list with the use of "regular expressions".

I configured the following regular expression access list on the ISP router:

ISP(config)#ip as-path access-list 1 deny ^100$
ISP(config)#ip as-path access-list 1 permit .*

ISP(config)#router bgp 300
ISP(config)#neighbor 172.24.1.18 filter-list 1 out

Tomorrow's BGP lab seems to be longer than the other labs so we'll see just how much material I'll have to work through. I shouldn't be able to finish a full BGP lab in 15 minutes...not yet anyways :)

Friday, April 30, 2010

DHCP Router Configuration


I spent this morning reviewing DHCP router configuration and the many options that you have as a DHCP server. From what I've seen in real networks most routers won't utilize DHCP configuration unless it's for a smaller network using a Cisco 1841 or something similar. The bigger enterprise routers are usually deployed in bigger environments where there are already dedicated DHCP server(s) in place. I did learn a command that would of helped me tremendously during my CCNA studies.

To all the people studying for the CCNA try out this command on a router and you'll get a nice surprise:

Router# show ip port-map

Yup that's right, you get a complete list of the most common TCP and UDP ports used, very handy for the CCNA exam or just for a quick reference!

Saturday, April 17, 2010

IS-iS over Frame Relay


I knocked out the last of the IS IS topics in the CCNP Lab Portfolio finally. One interesting caveat about IS-IS and NBMA (Non-Broadcast Multi Access) networks is that it can only perform as point-to-point connections. Which is very different from OSPF that can use different NBMA technologies such as multi-point. Tomorrow I begin the different routing manipulation topics that's a HUGE part of the exam I hear.

Saturday, April 10, 2010

CCNP Portfolio IS-IS Labs


I'm about half way through the CCNP lab portfolio book finally. I started on the first IS-IS lab presented in the book and it refreshed my memory on a lot of the IS-IS topics which I can honestly say that I forgot. The lab was focused on the basics and the end goal was to setup an IS-iS lab where the core network was running as an IS-IS level 2 network. The other goal was to implement security measures to prevent rouge outside networks/routers from trying to create an adjacency to the current IS-IS network which was pretty straight forward. I plan on completing the IS IS portion of this book within the next week or two, I'm working overtime at the NOC this upcoming week so we'll see how far will get by this time next week rolls around!

Tuesday, April 6, 2010

Finished the OSPF CCNP Portfolio Labs



All of this studying and labs (lots and lots of labs) are starting to pay off. I'm finally starting to grasp many of the CCNP routing topics without having to reference a book or look up how to configure certain commands. I went through the OSPF challenge lab and was able to knock it out in about 20 minutes which is pretty good. One thing about troubleshooting networks is that you can gain a lot of information just from looking at the running configurations and the ip routing table. Looking at the device log (show logging) helps you determine what happened and when, this is very helpful in real world environments. Next up is IS-IS and then the redistribution chapters which is gonna teach me a lot of new techniques I bet!

Saturday, April 3, 2010

OSPF Over Frame Relay


Today worked through the CCNP Portfolio lab 3-4 which has to do with OSPF over frame relay. This lab was mostly review for though. I did finally bit the bullet and learn how to setup a Cisco router as a frame-relay switch finally. I always used the frame relay icon in GNS3 for all of my frame relay studies. It was fairly straight forward, just mainly pointing the DLCI's where they need to go and configuring the serial interfaces for frame DCE connections was all that was needed really. I also went through some of the different type of OSPF NBMA topologies you can configure, such as point-to-multipoint or creating neighbor connections through the OSPF configuration.

Sunday, March 28, 2010

CCNP OSPF lab Portfolio


I finally finished up the EIGRP section and I'm now moving through some of the OSPF labs. Right now the labs are just going over basics but I have learned a few new things that I never thought about when it came to OSPF. When configuring loopbacks with IP addresses and using OSPF as your routing protocol, If their aren't any specific Router ID's (RID) set, OSPF will use the Loopback address as the RID.

For example if I configured the loopback 1 interface with the IP address 192.168.1.1 255.255.255.0, the router would use this as the RID as well. So when you run the show ip route command, it shows up as 192.168.1.1 /32 instead of the 192.168.1.1 /24 that you have actually configured on the lo1 interface. to circumvent this, you should type in the interface command ip ospf network point-to-point which tells the router to treat the loop back interface as routing destination rather than a routing ID.

Wednesday, March 24, 2010

Multicast Protocol Overview

Multicasting enables data to be sent over networks to a group of destinations in the most efficient way. The data is sent from the source as one stream; this single data stream travels through the network. Other network devices only replicate the data through the network if they have other members on their interfaces that are apart of this destination group.

Multicast groups are identified by Class D IP addresses, which are in the range from 224.0.0.0 to 239.255.255.255. Muticast uses the Internet Group Management Protocol (IGMP) and Cisco Group Management Protocol (CGMP) for determining which network devices require the multicast data stream. Protocol Independent Multicast (PIM) is used for determining the best way to route multicast traffic.

There are many differences between Multicast and Unicast packets. Unicast duplicates a packet for each reciever that it needs to send the data too (one copy for each reciver). Multicast sends one packet stream as mentioned previously, downstream routers replicate the packets only on links where receiving hosts exist. Multicast provides the following advantages over unicast:

  • Enhanced efficiency
  • Optimized Performance
  • Support for distributed applications
The disadvantage of multicast is that it uses UDP (User Datagram Protocol) as it's transport protocol. This means that packets are only sent on "best-effort" delivery and that packets aren't sent reliably. In order to cut down on unreliable packets, the multicast applications them selves may need to provide some sort of reliability mechanisms to prevent huge data lost. This could mean more processing power needed on the hosts them selves.

Shawn Moore invites you to follow my study progress at http://shawnmoorecisco.blogspot.com/. I also invite you to download my free CCNA eBook lab book at: http://www.configurethenetwork.com.

Article Source: http://EzineArticles.com/?expert=Shawn_Moore

Sunday, March 21, 2010

EIGRP Challenge Lab


I did my best to get through all of the tasks for the EIGRP Challenge Lab but I was unable to complete two tasks because I wasn't sure what they we really wanting me to do. The first was to filter a specific network from advertising out of a routers interface. The other task was to filter a network from entering a routers interface. I wasn't sure if I was just supposed summarize the network or create access-lists, route-maps, etc to deny the traffic. Besides that I managed to finish every other task successfully.

I had to change EIGRP settings such as manual summarization, change hello timers, and implement MD5 authentication which was all pretty straight forward. The weirdest task preventing EIGRP from sending multicast updates between the neighbors R1 and R2 (As shown above). I think I figured it out by entering the following command under my EIGRP AS 1

Router 1
router eigrp 1
neighbor 172.16.12.2 s0/0

Router2
router eigrp 1
neighbor 172.16.12.1 s0/0

If any one has any better suggestions on how to limit multicast addresses or if my method was completely wrong, please let me know haha!

Saturday, March 20, 2010

A Few Different CCNA Lab Simulation Options


As all of us Cisco certified and future Cisco certified professionals know, the key to passing the CCNA is knowing your hands on configuration like the back of your hand. This presents a challenge to many of us who's budget is limited from buying the latest and greatest Cisco equipment that could cost anywhere from hundreds to thousands of dollars to create a decent lab!

Fortunately many simulation programs are out there to help replicate the hardware and software needed to pass the exam. Even newer to the Cisco world and in my opinion closer to the real thing is emulation software that uses the actual IOS to simulate working on a Cisco router.

Simulation programs provide a very affordable way to create labs to possibly pass the CCNA exam with the bare minimum requirements. There are many simulation programs to choose from. In particular you would want to look for something that has many different Cisco devices to play with along with being updates with the newest IOS commands.

This is something you should note because it's not uncommon for different IOS versions to use a slightly different set of commands to accomplish the same task. Before choosing a simulation program it is also valuable to note that you won't have access to every feature available with a real router and equipment so many commands will not be available to you.

There's also the option of using emulation software such as GNS3 which allows you to completely emulate a Cisco device without the actual hardware. You can also do cool things such as connect to a real Cisco device from the emulator program to help cut down on cost if you already have a few Cisco devices but not enough to create a full CCNA lab. There are a few downsides though as well. The main downside is that as of today, you aren't able to emulate Cisco Switches due to the way Cisco switch hardware works.

However emulators such as GNS3 has a simple Ethernet switch built in that you could use or you can connect your emulated network to an outside world to connect to your Cisco switches. The other downside is that you must have access to actual IOS images in order to use any of the emulator device. This can be particular hard to acquire unless you are a vendor or a CCIE with credentials to access these images from Cisco directly. There are many choices out there but always remember that nothing beats actual equipment and hardware!

Check Out My CCNA Lab Book At: http://www.configurethenetwork.com That Features Over 15 Scenario Based Real World Labs!

Article Source: http://EzineArticles.com/?expert=Shawn_Moore

Thursday, March 18, 2010

EIGRP Configured on a Frame Relay Network


I spent a little time this afternoon going over the next EIGRP lab in the CCNP Lab Portfolio. I learned some useful types regarding EIGRP and how it works over Frame. For the most part you can configure EIGRP as normal but EIGRP works off of split-horizon rules. Split horizon pretty much tells a router not advertise a route out of the same interface that it learned the route from to begin with. There for in the diagram router West and East didn't know about each other due to not being able to advertise the same route back to HQ. To get past this, I had to turn of split horizon on the HQ router with the following command:

no ip split-horizon eigrp 1

Once I entered this command under the EIGRP configuration, sure enough all routes came right up!

Thursday, March 11, 2010

EIGRP Configuration, Bandwidth, and Adjacencies


I was able to tackle the second lab in the BSCI Lab Portfolio and I can already say with confidence that this book will help me greatly with my studies. I learned a few things between this lab and he first lab that I wouldn't of ever known or thought about. Last week was a very simple two router lab with basic static route configuration. However I learned something that I didn't even know these Cisco routers could do, and that's programming scripts. The Lab Portfolio goes over a neat little script that allows you to test ping configurations without having to go through and ping every interface over and over on each router to verify connectivity. Check out a preview of the script I used for the first lab below, it's called TCL Script and you can access it by typing the tclsh command when you are in enabled mode:

foreach address { 10.1.1.1 10.1.2.1 10.1.3.1 10.1.4.1 10.100.12.1 10.2.1.1 10.2.2.1 10.2.3.1 10.2.4.1 10.100.12.2 } { ping $address }

It pretty much says for each IP address listed, ping it, as simple as that!


I finished my first EIGRP lab today and picked up some cool new commands such as the ping ip address repeat number of times command. Which you can ping an IP address as many times as needed, an example would be ping 10.1.1.1 repeat 1000. This tells the router to ping 10.1.1.1 1000 times, great for testing experiments with routing protocols while packets are being sent across the network!.

Check Out My FREE CCNA Lab Book Available At

Friday, March 5, 2010

Route Reflectors For BGP


BGP specifies that routes learned using Interior BGP should never be learned by other IBGP peers. Because of this rule, BGP requires that all IBGP networks to be complety fully meshed as shown in the picture above. Therefore if you had just 13 routers in your AS running IBGP, you would need 78 total connections in order for all 13 routers to connect to every other router! This causes a big problem with bandwidth due to sending redundant data across all of the routers at the same time.

To over come this, the creation of Route Reflectors (RR) were created. Route Reflectors allows an AS that's running IBGP to not have to use a complete full-mesh topology. Instead you can creat whats called clusters which can group sets of routers together. You can think of a cluster as a mini network that sits inside of your AS. But instead of a full-meshed topology, the cluster is designed in a hub and spoke fashion with one router being designated the Route Reflector (Hub) and the other routers being the spokes that connect to the RR. The Route Reflector then passes its updates to the AS, other clusters, or even other AS's depending on the configuration. This saves on the number of BGP TCP sessions that must be maintained and and also reduces the BGP routing traffic!

Check Out My FREE CCNA Lab Book Available At

Monday, March 1, 2010

BGP Communities


If we used just prefix-lists and distribute lists to filter BGP updates it would be a very manual intensive job due to the size of most BGP networks and the fact that you would have to configure each router one at a time! Today I learned that you can group routers running BGP into groups that can share the same filtering information. Therefore you would only need to configure one of the routers in the group for all of the other routers to know what updates should be filtered and what shouldn't.

"BGP communities function allows routers to tag routes with an indicator (the community) and allows other routers to make decisions (filter) based on that tag. BGP communities are used for destinations (routes) that share some common properties and that, therefore, share common policies; routers, therefore, act on the community, rather than on individual routes. Communities are not restricted to one network or autonomous system, and they have no physical boundaries."

the community attribute is considered an optional transitive attribute. If a router receives an update with community attribute information but doesn't use that attribute, it will ignore it but pass it along to other BGP neighbor peers. The community attribute consists of 32-bits, 16 for the Autonomous System number (AS) and the other 16 identifies the community number.



Don't Forget To Check Out My CCNA Lab Book Available At
www.configurethenetwork.com
This Is The LAST Day That It's Going To Available For The $9.95 Price!

Sunday, February 28, 2010

Creating Prefix-Lists for BGP Routing 2


I spent this early afternoon finishing up the BSCI BGP Appendix section on prefix-lists for BGP, I mainly created a lab that specifies that that the network 172.30.0.0 /24 in the AS 65500 only shows as the supernet 172.0.0.0/8 in the AS 65000 BGP table as shown above. Tomorrow I will learn a little bit about BGP communities and go over what I've learned!






Don't forget to check out my CCNA Lab Book available at www.configurethenetwork.com, it's only going to available for the $9.95 price for another 2 days!

Saturday, February 27, 2010

Creating Prefix-Lists for BGP Routing


I spent a good bit of my morning learning and configuring BGP prefix-lists which I will wrap up tomorrow most likely. Prefix-lists provide greater flexibility over access-lists due to the fact you're allowed more granular control of where you want input your statements inside the prefix list. This differs from the standard access-list where one no command on the ACL requires you to recreate the access-list completely! I'm still not entierly sure how prefix-lists differ from ip access-list commands which allows you to enter sequence number states like prefix-lists. I do know that you can control exactly how you want a neighbor BGP autonomous sysstem (AS) to know about external routes by using the le and ge commands.

The le and ge values are used in a prefix-list statement to create a range of the prefix length to be matched more specifically compared to the network/length commands used in the prefix-list statements. Prefix lists do provide the advantage of being less performance intensive due to not requiring the amount of route lookup processing sometimes required by large access-list tables.

As you can see in the above lab I worked earlier, the prefix list tells AS_65000 to only let AS_65002 know about the 172.16.0.0 /16 external network instead of the more specific 172.16.10.0 /24 and 172.16.11.0 /24 routes.


Don't forget to check out my CCNA Lab Book available at www.configurethenetwork.com, it's only going to available for the $9.95 price for another 3 days!

Tuesday, February 23, 2010

Configure the Network CCNA Lab Book is Here!!


WANT TO KNOW FOR SURE THAT YOU'RE READY TO TAKE AND PASS THE CCNA EXAM?

Don’t you want to verify that you’ve covered every main topic listed on the Cisco CCNA Exam? Wouldn’t it be great if there was a way to know if you’re ready for the hands on material that’s going to presented as simulations on the actual exam? Instead of another “How To” guide, wouldn’t it be cool to go through actual scenario based CCNA labs that’s used in the real world?

You’re in luck! The only Cisco CCNA Lab book you’ll ever need to verify if you’re ready or not for the CCNA Exam is right here. I promise it will help you solidify your CCNA Hands On Configuration Skills, to ensure that you’re ready tackle and obtain your CCNA Certification!


My CCNA Lab Book Includes the following:

- Over 15 Fully Featured CCNA Labs Based on Real World Scenarios

- Hints and Tips That are Helpful for Both the Exam and the Real World

- Web Links Within Each Lab For Additional Study Material And Tips

- Easily Accessible PDF File with Click-able Web Links and Shortcuts


The Full Version of the Configure the Network CCNA Lab Book is a $40 Value But For a Limited Time I'm Releasing This Book For Only the Low Price of $9.95!


3D Ebook

The Low Price of $9.95 Will Only Be Available For a Limited Time!buy now


"Testimonial"



Monday, February 22, 2010

BGP Summary and Aggregated Routes


I spent this morning briefly covering how to summarize routes in BGP using CIDR Aggregated Routes. BGP specifically uses the Atomic Aggregate attribute which is considered one of the well-known discretionary attributes. BGP also uses the optional transitive attribute called an Aggregator which specifies the BGP ID and the AS that performed the aggregation in BGP updates. If you aren't careful when planning which routes to summarize your AS could easily claim routes that it really doesn't own which could upset other AS's in the BGP system! AS's doesn't really use aggregation as much as they could because some are multihomed to many ISP's and would rather make sure that all of the routes that own are being advertised without being summarized into one route.

Sunday, February 21, 2010

Policy Based Routing 2


This morning I created another PBR lab that I was able to wrap my head around a lot easier than yesterday. As you see in the above image, there are 3 routers in which specific LAN traffic from Router C should be routed out of Router A's Serial 0/0/1 interface. It was good to get some more hands on with route-maps the past few days. I'm going to work some more labs throughout the day most likely on BGP. My lab guide book should be here in another weeks so you should be seeing a ton of new labs from me here shortly!

Saturday, February 20, 2010

Policy-Based Routing


Now that I finished the main book for BSCI, I'm now reviewing everything I learned and will spend most of my time creating labs and touching up the details. But before I do to much, Cisco was kind enough to include 5 extra Appendix PDF files to learn about some technology in even more detail. This is mainly appendixes on how to manipulate packets and even more BGP no surprise! I hear that in order to fully be perpared for the BSCI you have to dig even deeper than what the Self Study Guide book provides. This includes everything from reading white papers, CBT's, and creating labs for pretty much ANYTHING related to the exam.

Today I learned a little bit about Policy Based Routing (PBR) which is basically route-maps on steroids. Similar to how there are access-lists and then extended access-lists (access-list on steroids), PBR allows you to maniplulate routes in a more granular manner. Tomorrow I'll be finishing this appendix up and moving to the last few that are left.

Don't forget to download my FREE CCNA Lab book for the ICND1 course at www.configurethenetwork.com while it's still available. The full version of the lab book is FINISHED and ready to sell, I'm just working on some things on the back end. The full lab contains 17 scenario based CCNA labs that will test your theory on every topic included in the CCNA