Voice Lab Setup 17-1-09

I have started setting up my home voice lab with initial infrastructure using 3725 routers at HQ, BR1 and BR2. I have added wic-2T and nm-16esw cards in each router. The initial step include the frame-relay setup among above 3 routers using frame relay switch. We can ping each HQ > BR1 and vice versa and also From HQ > BR2 and vice versa.

The config snap and topology snap is attached for your review.

Next steps would be adding HQ to local LAN, configuring vlans, dhcp server and ospf.

MCSE log

Classes of IP addresses,

Class A : 1-126 : 1.0.0.1 to 126.255.255.254
Class B : 128-191 : 128.1.0.1 to 191.255.255.254
Class C : 192-223 : 192.0.1.1 to 223.255.254.254
Class D : 224-239 : 224.0.0.0 to 239.255.255.255
Class E : 240-254 : 240.0.0.0 to 254.255.255.254

pecial address ranges

Some addresses are reserved for special uses (RFC 3330).^[2]

Address range	CIDR Equivalent	Purpose	RFC	Class	Total # of addresses
0.0.0.0 - 0.255.255.255	0.0.0.0/8	Zero Addresses	RFC 1700	A	16,777,216
10.0.0.0 - 10.255.255.255	10.0.0.0/8	Private IP addresses	RFC 1918	A	16,777,216
127.0.0.0 - 127.255.255.255	127.0.0.0/8	Localhost Loopback Address	RFC 1700	A	16,777,216
169.254.0.0 - 169.254.255.255	169.254.0.0/16	Zeroconf / APIPA	RFC 3330	B	65,536
172.16.0.0 - 172.31.255.255	172.16.0.0/12	Private IP addresses	RFC 1918	B	1,048,576
192.0.2.0 - 192.0.2.255	192.0.2.0/24	Documentation and Examples	RFC 3330	C	256
192.88.99.0 - 192.88.99.255	192.88.99.0/24	IPv6 to IPv4 relay Anycast	RFC 3068	C	256
192.168.0.0 - 192.168.255.255	192.168.0.0/16	Private IP addresses	RFC 1918	C	65,536
198.18.0.0 - 198.19.255.255	198.18.0.0/15	Network Device Benchmark	RFC 2544	C	131,072
224.0.0.0 - 239.255.255.255	224.0.0.0/4	Multicast	RFC 3171	D	268,435,456
240.0.0.0 - 255.255.255.255	240.0.0.0/4	Reserved[3],[4],[5]	RFC 1166	E	268,435,456

[edit] See also

Configuring IP Netflow in Cisco 3725

Configuring IP Netflow in Cisco 3725



Disclaimer: Credit to Josh (Head Geek) www.solarwinds.com

PoE and PoE+(802.3at)

Since the original introduction of PoE, the IEEE has initiated a new project called 802.3at which is commonly referred to as PoE+. This project enhances PoE in a couple of very important ways. First, it provides up to 30W of power to a Powered Device (PD), 25.5 watts to the device and 4.5 for line loss, and allows this power to also run on cabling designed for 1000BASE-T. Secondly,
it provides a new mechanism for communicating power capability and requirements using the 802.1ab Link Layer Discovery Protocol (LLDP). This protocol addition allows PoE+ switches to deliver power more efficiently and thereby provide power to more devices for a given power supply capacity. The new standard is going to be a superset of the 802.3af because it provides all
the same functionality, and more. The table below shows the capabilities of 802.3af versus 802.3at.

In order for 802.3at to provide higher power, Class D (Cat5e) or better cables are required. 802.3at also increases the minimum output voltage of the Power Source Equipment (PSE) from 44 volts to 50 volts. For this reason, you may note that ProCurve PoE+ devices use a 54 volt power supply.

Note:
The detection and classification functions ensure that if two PoE sources are attached together, power will not be improperly applied.
Here are some reasons why you might want to do this:

■ Simplifies installation and saves space - only one set of wires to bring to your appliance.
■ Saves time and money - there is no need to pay for additional electrical power runs or to delay your installation schedule to make them.
■ Minimal disruption to the workplace - the appliance can be easily moved, to wherever you can lay a LAN cable.
■ Safer - no AC voltages need to be added for additional network devices.
■ As well as the data transfer to and from the appliance, you can use SNMP network management infrastructure to monitor and control the appliances.
■ Appliances can be shut down or reset remotely - no need for a reset button or power switch.
■ When implementing wireless LAN systems it simplifies the radio frequency (RF) survey task, as the access point can easily be moved and wired in.

Power Through the Cable:

A standard CAT5 Ethernet cable has four twisted pairs. Only two of these pairs are used for 10Base-T and 100Base-TX data; all four are used for 1000Base-T data. The specification allows two options for using these cables for power:
■ The spare pairs are used. The pair on pins 4 and 5 are connected together and form the positive supply, and the pair on pins 7 and 8 are connected and form the negative supply.
■ The data pairs are used. Since Ethernet pairs are transformer coupled at each end, it is possible to apply DC power to the center tap of the isolation transformer without upsetting the data transfer. In this mode of operation the pair on pins 1 and 2 and the pair on pins 3 and 6 can be of either polarity.




The 802.3af standard does not allow both pairs (spare and data) to be used - a choice must be made. The Power Sourcing Equipment (PSE) applies power to either set of wires. HP ProCurve Networking switches, as a PSE, supply PoE power over the “data pair” or, pins 1 and 2, and the pair on pins 3 and 6. The Powered Device (PD) must be able to accept power from both options
because mid-span equipment must (according to the specification) supply power over the “spare pair” or pins 4 and 5, and the pair on pins 7 and 8.

An obvious requirement of the specification is to prevent damage to existing Ethernet equipment. A discovery process, run from the PSE, examines the Ethernet cables, looking for devices that comply with the specification. It does this by applying a small current-limited voltage to the cable and checks for the presence of a 25k ohm resistor in the remote device. Only if the resistor is present, will the full wattage be applied, but this is still current-limited to
prevent damage to cables and equipment in fault conditions.Once discovered, a different voltage is applied, and based upon the current drawn, the class of device can be determined. This indicates how much power is to be drawn. The 802.3at standard provides both a physical classification and a logical classification, which is even more precise. The PD must continue to draw a minimum current. If it does not (for example, when the device is unplugged) then the PSE removes the power and the discovery process begins again.

General Considerations
The following is an example list of considerations during the planning phase no matter which series of switches are being installed:
■ How many devices need PoE power?
■ What devices will need PoE power?
■ How much power will each device require, in watts?
■ What is the total of all their wattages?
■ Will the devices be connected to a 2910al, 3500yl, 5400 or to a 8200zl
switch?
■ How many ports are needed?
■ How many ports are available?
■ Are the devices to be powered by PoE power supported?

Disclaimer: http://cdn.procurve.com/training/Manuals/PoEPlannngGuide-Oct2009-59918574.pdf

iACLs; A Service Providers Best Practice on your LAN

When I first started working on Cisco gear back in the early 18th century, ACLs were one the the biggest deployment problems I ran into on a day to day basis. On my first day of being introduced to ACL's was also my first day of introducing our user base to self inflicted Goober Admin Denial of Service attacks (GADOS).... Oh sure they made sense on the various certification exams and talking about them with other geeks over a Bawls Cola at Star Trek conventions. Hey it's just basic boolean logic right? If this variable AND that condition AND this direction MATCH=1 please proceed with instruction, if not drop into the bit bucket. And no I never fell for the old noob; "Time to empty the bit bucket" trick...more then once. But something happened between paper and practice that made me loathe ACL's more then a middle seat and vegetarian airline meal. Is it just me or do vegetarians have the worst farts ever?

anyway...

Any field engineer worth their salt knows that you have to know ACLs like you know where all the speed traps are on your way to work. It is true that you will certainly use them often but ACL theory enables a lot of other features like Flexible Packet Matching, QoS, MCQ, etc... As Yoda would say, Know them you must yes...hmmmm" I really learned ACL practical implementation by fire as a consultant for a major ISP. We used ACL's to the most minute level. As the security threats changed, large hard to follow ACL's had to change. They were eating up too much router resources, folks were afraid to edit them due to a possible outage and staff turnover not only meant the loss of a team member but a loss of the verbal history to understand why many configs were done they way they were.

The iACL came out of that casting forge. ACLs as a feature will not change because of their boolean logic they will only keep expanding to include more AND conditions and some OR conditions. And lets face it, the security threat is not going to get easier only more detailed. A new way of using ACLs was needed at the ISP level. iACLs are not a new feature or a product from Apple they are a new method to use ACL's at your Internet Edge. The "i" in iACL stands for Infrastructure. These entries are very detailed and very powerful. I was going to put in some pointless quote about power and the darkside of the Force but I have already quoted Star Wars once in this blog and that is the legal limit. So let's build out an iACL for my network here in the CodeCave(tm). My network internal address in 172.16.1.0 which is the same I am using on the Internet which is of course illegal which means I am of course lying for simplicity sakes!

Step 00x01: iACLs are as personal to your network as your own underwear is to you. With that is mind, most of us have a good idea what traffic is on the network and if not if you have a feature like NBAR and/or NetFlow this will help shape your initial ACL. To get started, lets build out a Discovery ACL to see what traffic we actually have. I would start out with this one:

access-list 222 permit tcp any any eq 22 log
access-list 222 permit udp any any eq syslog log
access-list 222 permit udp any any eq ntp log
access-list 222 permit ospf any any log
access-list 222 permit icmp any any log
access-list 222 permit tcp any any eq tacacs log
access-list 222 permit ip any any log

Place this ACL on the inbound interface. Remember this eats up router resources so leave this on only as long as you need it to get a good picture of your network. I normally do 3-5 days, however, your mileage may vary! Many things depend on this, number of connections, router size, etc.

Step 00x02:Now I monitor my logs to see what is hitting where. I can do this with the command:

TechWiseTVRTR#sh access-list 222

10 permit tcp any any log (55 matches)
20 permit udp any any eq syslog log (8 matches
..... you get the idea here.....but one more just for fun
70 permit ip any any log (73 matches)

What I am looking for is a small number of hits on my IP ANY ANY statement. A large number means I have stuff not being classified and I need to redefine my Discovery ACL just a bit or dig back into NBAR/NetFlow to see what is flowing thru this network and try again. Remove the Discovery ACL when I am finished.

Step 00x03:Test time! Time for the rubber to hit the road! This is the final step before we create the iACL. I will create a phone call ACL that is very specific. I know this ACL works if the phone in the support center does not ring...

access-list 222 permit ospf host 172.16.1.1 host 224.0.0.5
access-list 222 permit ospf host 172.16.1.1 host 224.0.0.6
access-list 222 permit icmp host 172.16.1.1 192.168.0.0 0.0.255.255
access-list 222 permit tcp host 172.16.1.1 eq 22 192.168.0.0 0.0.255.255
..... You get the idea...OK one more, but this is the last time
access-list 222 permit ip any any log

I put the IP ANY ANY at the end with a log statement to still monitor hits. Run this for a week or so then remove it and proceed to the iACL!!!

Step 00x04: This is it. All the training in a Russian barn in Winter, running up the snow covered hill...Oh sorry, I really need to turn the TV off. Built out the iACL. An iACL has four modules that make it up:

- Deny Special Use and Fragments
- Explicit Permit
- Explicit Deny to Protect the Infrastructure
- Expect Permit for Transit Traffic

Before we get started building out our iACL remember the two most coveted rules in network engineering:

- Never have a end user troubleshoot a network
- Always build out your networks for the next person that follows you.

PLEASE remember to comment out your ACL's, so your history does not leave when you do.

Module 01: Deny Special Use. This module of my iACL looks like this with dated comments:

!---- Module 1 iACL Dec09 Deny Special Use RFC 3330

access-list 222 deny ip host 0.0.0.0 any
access-list 222 deny ip host 127.0.0.0 0.255.255.255 any
access-list 222 deny ip host 192.0.2.0 0.0.0.255 any
access-list 222 deny ip host 224.0.0.0 31.255.255.255 any

***shortened for blog. Check out the table in RFC 3330 for more address***

!--- Module 1 Dec09 Deny RFC 1918 IP space

access-list 222 deny ip 10.0.0.0 0.255.255.255 any
access-list 222 deny ip 172.16.0.0 0.15.255.255 any
access-list 222 deny ip 192.168.0.0 0.0.255.255 any

Module Two:Explicit Permit This is where I allow only authorized external traffic to access internal devices. In this example I will allow routing protocols and SSH only. Basically, it is my control and management traffic.

!---- Module 2 iACL Dec09 Explict Permit

access-list 222 permit ospf host 172.16.1.1 host 172.16.1.2 eq ospf
access-list 222 permit ospf host 172.16.1.1 eq ospf host 172.16.1.2
access-list 222 permit ospf host ospf_neighbor host 224.0.0.5
access-list 222 permit ospf host ospf_neighbor host 224.0.0.6
access-list 222 permit tcp host 172.16.1.4 host 172.16.1.8 eq 22

Module Three: Explicit Deny to Protect the Infrastructure from external sources

!--- Module 3 iACL Dec09 Explicit Deny to Protect Infra
access-list 222 deny ip any 172.16.1.0 0.0.0.255

Module Four: Explicit Permit. This is my transit statement to let internal traffic move about.

!--- Module 4 iACL Dec09 Explict Permit for LAN traffic

access-list 222 permit ip any any

Now you may have noticed that I do not have the source address in many iACL entries. This is becuse I have IP Source Guard enabled at the edge ports and I am enforcing this validation there. This keeps my iACLs smaller and router processing more streamlined. More info in iACL can be found at http://www.cisco.com/go/safe This iACL example is for an Internet Edge router. You can also have a smaller iACL for the LAN as well. Give iACLs a try in your shake and bake lab. They may look a little tough, but it's kinda like eating crap food, breaking it down to smaller parts makes it much easier and that's the idea of modules!

Jimmy Ray Purser

Trivia File Transfer Protocol
Astronomers have long used the Light Year as a standard of measurement. Not to be left out Nuclear Physicists need a measurement standard as well but for much smaller distances. They use the beard second. Which is basically how fast an average (define that I dare you) Nuclear Physicists beard grows in one second, around 5 nanometers. Type in beard-second in Google to see it covert an inch into a beard second to see how small of a measure this really is.

Disclaimer: The article is originally written By JimmyRay, www.networkworld.com

Audio Codec Negotation

Cisco routers acting as voice gateways perform an important job in Unified Communications (UC) deployments. Digital signal processors (DSP) in voice gateways translate voice over IP real-time protocol (RTP) media to time division multiplexing (TDM) required for traditional telephony interoperability. A variety of audio codecs that have different audio quality and bandwidth requirements are used on the voice over IP (VoIP) call leg that determine call quality. Voip dial peers in Cisco routers default to the compressed G.729 audio codec, but codecs can be negotiated in SIP and H.323 gateways. MGCP gateways do not support any codec negotiation because Cisco Unified Communications Manager (CUCM) dictates the codec to the calling party as a result of the region configuration.

H.323 uses the H.245 protocol to provide audio, video, and data media negotiation. SIP leverages session description protocol (SDP) to provide the same information. Regardless of the protocol utilized, the configuration is the same in Cisco IOS of the gateway router. The router 1 voice class configuration below is applied to dial peer 900 with the will send out a listing of prioritized codec capabilities to 10.1.1.1.

ROUTER1:

Voice class codec 90
Codec preference 1 g729a
Codec preference 2 ilbc
Codec preference 3 g722
Codec preference 4 g711ulaw
!
Dial-peer voice 900 voip
Destination-pattern 15…
Voice-class codec 90
Session target ipv4:10.1.1.1

The receiving device will make the final codec determination via the local voice class codec negotiation. If a call is routed from router 1 to router 2, the voice class below will result in an audio codec of g711ulaw because both routers support the codec and it is the called party’s preferred audio codec.

ROUTER2:

Voice class codec 914
Codec preference 1 g711ulaw
Codec preference 2 ilbc
Codec preference 3 g722
Codec preference 4 g729a
!
Dial-peer voice 500 voip
Incoming called-number 15…
Voice-class codec 914

The following debugs can be used to verify the media negotiation in H.323 and SIP respectively. Update your resume before running debugs in production environments.

Debug h245 asn1
Debug ccsip messages

Disclaimer: the article is originally written By Dennis Hartmann, www.networkworld.com

10GE and Network Oversubscription Ratios

Lately I have seen many data center designs that contain 10 Gigabit Ethernet links at the access, distribution and the core hierarchy layers. Traditionally, the bandwidth increases as you reach the core of the network. Historically, networks were like trees. The access network "leaves" are smaller, the distribution network "branches" are a little bigger, and the core network "trunk" is thick. However, due to the prolific use of 10 GE interfaces traditional network design oversubscription ratios are not achievable.

When constructing a multi-tiered network design it is important to consider the bandwidth oversubscription ratios at every layer of the Ethernet switching hierarchy. The idea is that the upstream bandwidth at each layer of the hierarchy must provide adequate bandwidth for those downstream devices. However, statistics drive the ratios that make the total size of the uplink not need to sum to the total amount of the downstream links. This "oversubscription" ratio of downlinks to uplinks is what needs to be closely monitored so that at places in the network bottlenecks do not form that could be difficult to detect and provide poor network connectivity for downstream devices.

Common access-downlink to access-uplink ratios are 20:1 and distribution-downlinks to distribution-uplink ratios are 4:1. Below is a figure that illustrates this concept. This diagram below shows a 20:1 ratio between access-ports on an Intermediate Distribution Frame (IDF) switch and the uplinks to the distribution switch as well as a 4:1 ratio of distribution switch downlinks to its core uplinks. Traditionally, single Gigabit Ethernet links are used to connect servers, the uplinks are 10GE links, and the core is connected with four 10GE links.

A similar diagram can be found in the Cisco Enterprise QoS Solution Reference Network Design Guide (SRND) version 3.3.

Many newer servers and blade centers are coming with 10GE interfaces. The links between core devices are also using 10GE interfaces. Now we have a design where the leaves are as thick as the trunk of the tree. Therefore, 10GE is changing oversubscription ratios commonly used in network designs.

For example, if an IDF has 240 ports (5 switch stacks of 48 port 10/100/1000Mbps switches) then the total downstream bandwidth is 240Gbps. Therefore, the uplink bandwidth should be 1:20 of 240Gbps or 12Gbps. Those uplinks will probably be a pair of 10GE links. Then consider a set of distribution switches that support only four of those IDFs. Therefore, the total distribution layer downstream bandwidth would be 960Gbps. The uplink bandwidth should be 1:4 of 960Gbps or 240Gbps. However, since we lack the ability to deploy that amount of bandwidth then we are faced with probably using a set of four 10GE links from each distribution switch to each of the pair of core switches.

The second example is when we have servers with 10GE links. Let's say a Nexus switch has 32 10GE links to servers, clusters, and blade centers in the data center. The 20:1 rule would indicate that there would be 16Gbps of uplink bandwidth. That could be satisfied with a couple of 10GE uplinks to the distribution switches. Those distribution switches could only have a couple of these IDF switches downstream in order to require only a few 10GE uplinks to the core switches.

The distribution layer is getting squeezed out with the extensive use of 10GE interfaces within data centers and more organizations may be looking at a 2-tier model rather than the traditional 3-tier model. In the two-tier model, the only ratio used is the 20:1 from the access downlinks to the access uplinks to the core.

40GE and 100GE on the Horizon:

This oversubscription ratio problem won't remain like this for long. We can see already see 40 Gbps Ethernet and 100 Gbps Ethernet on the horizon. Earlier this year the NYSE announced plans to deploy 100Gbps Ethernet. Service providers like Qwest are planning early deployments of 100Gbps in their high-performance backbones. In fact, the some of the first 100Gbps links have already been sold. In my opinion, I agree with those who are proponents of skipping 40Gbps Ethernet and going straight to 100Gbps Ethernet. I also feel that 100Gbps Ethernet is going to gain wider industry adoption than OC-768. History has shown that you just can't beat Ethernet for simplicity, performance, and price.

Conclusion:

The use of 10GE interface for access, distribution, and core will cause network architectures that have leafs with the same bandwidth as the tree's trunk. In order to maintain oversubscription ratios the industry is looking toward using 100GE in the years to come. Network World published their "100G Ethernet cheat sheet" a few weeks ago. I encourage you to check out these articles and keep track of how 100Gbps Ethernet will affect how you design networks in 2010.

Scott

Disclaimer: The article is written by By Scott Hogg, www.networkworld.com