Free QoS Seminar

I recently found a great blog on Cisco advice and technology.  This particular blog sponsers (or is sponsored?) by a company called Internetwork Expert.

Recently, they held a webcast called “Catalyst QoS”.  This is not your standard 5-minute brief overview of QoS technologies.  This webcast actually goes into the details (along with showing you from a console) of using QoS on a Catalyst Switch.    It is almost 1 1/2 hours long, and is a fantastic webcast!

If you are ever wanting to expand on your QoS knowledge, or plan on using QoS at the Catalyst level, you MUST review this webcast.

I’m not sure how long it will stay archived, so check it soon.  Review the comments below the post, to view the archive location.

Cisco Policy Based Routing (PBR)

Okay, you may have noticed I have implemented a video conferencing system across the enterprise WAN. I had to do some network re-working, however, as the Watchguard Firebox does not play nicely with H.323 for internet-based traffic. However, I had a Pix Firewall that I had been meaning to implement.

Unfortunately, I cannot just remove the Firebox. It is doing web-blocking, SMTP proxying, and countless rules that would take time to rebuild on the Pix. I only wanted the Pix to firewall my H.323 gateway. So, I had to make sure both can play nice together.

Enter Policy-based Routing…..

Basically, I wanted my H.323 Gateway (say 172.16.1.25) to go through my Pix, but still allowing EVERYTHING ELSE (172.16.1.0/24) to go through the Watchguard Firewall. For now, anyway….. Here is a basic diagram:

(Click for larger image)

From here, you can see the flow. Since my default router (172.16.1.1) is in the middle, it will be the “Traffic Cop”. It is here, that we will place a policy on how it will route the packets.

First, we need to identify the packets. We do this by creating an access-list:

default_router(config)# access-list 10 permit 172.16.1.25

Next, we build a routing map that uses the access-list. We will also throw in some precedence, for soft-QoS identification:

default_router(config)# route-map VideoConf permit 10

default_router(config-route-map)# match ip address 10

default_router(config-route-map)# set ip precedence priority

default_router(config-route-map)# set ip next-hop 172.16.1.3

Okay, in our routing map, we are doing three things:

1). We see if it matches our access-list numbered 10

2). If it does, set the precedence bit to ‘priority’ (This is video, after all)

3). Route the packet to host 172.16.1.3 (That’s the PIX).

Once our map is complete, all we have to do is apply it to an interface. In our case, the packet is being received on the inside interface (FastEthernet 0/0).

default_router(config)# interface f0/0

default_router(config-if)# ip policy route-map VideoConf

Done! NOTE, you can only have one policy applied to an interface. This is where the ‘permit 10′ comes in, on the route-map definition. You can build multiple “groups” in a route map. For example, a ‘route-map newPolicy permit 20′.

Now, all packets NOT matching the access-list will still fall-back to the default route going to 172.16.1.2. If the traffic matches access-list 10 (i.e. host 172.16.1.25), it will be applied to the route-map VideoConf, which says to route it to 172.16.1.3.

All you have to do, is make sure 172.16.1.3 can handle the traffic (for example, the proper NAT, access-lists, etc).

Good Luck! Next, I’ll post the PIX rules needed for Polycom to receive inbound calls, and make outbound calls.

Technorati Tags: pbr, policy based routing, cisco

Powered by ScribeFire.

Stupid Helpdesk System!

Okay, it’s time to rant a little bit. Not too long ago, my company purchased a helpdesk system to help them track their trouble-tickets and trends. A great idea, and one that most business should be using.

Unfortunately, the product they chose is named Prop Web helpdesk. Why is this a problem. Well, for starters, I’ve just not been in the habit to use software for a LARGE and ENTERPRISE-grade business, that when you run a search for it, the top results comes from SHAREWARE sites. Don’t get me wrong, it will work great for those companies that have less than, say, 50 employees, but any greater than that, it SUCKS!

They have no idea what a normalized database structure is. They have the same field names in multiple tables, none of which, link to a common table. 3rd-party integration is completely out-of-the-question, unless their developers (I think they are up to 3 now) develop the interface. And reporting on it, just plain sucks. Oh, and if you want to run the software, you’ll have to invest in ColdFusion! Blehh.

Maybe if I have the time, I’ll post an addendum to this post, on the actual reasons for my thoughts ( I do have them, honest. I’m not just ranting for no reason) later, if I have the time. Right now, I just need to get things done.

To their defense, I am talking about PropWeb Helpdesk 6.x. Their 7.x screenshots seem to make it look better, but at this point, how good can it be, other than good eye-candy?

To be honest, I’m going to have a difficult time migrating our existing tickets and history to our Swedish helpdesk system, using AdventNet. It’s much better than PropWeb, and if you were following my NetFlow post comments prior to moving my blog, you’ll recall we discussed AdventNet’s NetFlow product too.

SIDENOTE: I’m not talking bad about those that made the decision to purchase it.  It’s a cheap software that gets the job done.  I’m talking bad about the company that created the product, and to release something better.