simulating a voice call

Please re Cisco Doc 24121:
Measuring Delay,Jitter,and Packet Loss with Cisco IOS SAA and RTTMON
http://www.cisco.com/warp/public/126/saa.html

VoIP typically tolerates delays up to 150 ms(RTT) before the quality of the call is
unacceptable.
Voice call can tolerates as much as 6% packet loss before the quality of the call is
unacceptable.


Deploying Delay and Jitter Agent Routers
Where to Deploy
Delay and jitter can be measured by deploying Cisco routers 17xx or higher with Cisco IOS
software code version 12.05T or higher, and configuring the Cisco IOS SAA features. The
routers should be placed in the campus networks next to hosts. This provides statistics for end-to-end connections.


Simulating a Voice Call

One of the strengths of using SAA as the testing mechanism is that a voice call can be
simulated. For example, imagine you want to simulate a G.711 voice call. You know that it
uses RTP/UDP ports 14384 and above, it is approximately 64 kb/s, and the packet size is
200 bytes {(160 bytes of payload + 40 bytes for IP/UDP/RTP (uncompressed) }.You can
simulate that type of traffic by setting up the SAA Delay/Jitter Probe as shown below.

The jitter operation needs to do this:

Send the request to RTP/UDP port number 14384.

Send 172 byte packets (160 payload + 12 byte RTP header size) + 28 bytes (IP + UDP).

Send 3000 packets for each frequency cycle.
(it takes 20ms to send one packet.In one second,you can send 50 packets.To simulate one
minute call,you have to send 3000 packets.got it?)

Send every packet 20 milliseconds apart for a duration of 60 seconds and sleep 10 seconds before starting the next frequency cycle.

Those parameters give 64 kb/s for 60 seconds.

((3000 datagrams * 160 bytes per datagram)/ 60 seconds)) * 8 bits per byte = 64 kb/s

The configuration on the router appears as follows:

rtr 1
type jitter dest-ipaddr 10.2.2.20 dest-port 14384 source-ipaddr 10.14.2.8 num-packets 3000
request-data-size 172
tos 184 (DSCP 46)
frequency 70
rtr schedule 1 life forever start-time now

Note: IP+UDP is not considered in the request-data-size as the router adds them automatically to the size internally.

On 12.4+,the configuration appears as follows:

ip sla monitor 1
type jitter dest-ipaddr 10.2.2.17 dest-port 14384 source-ipaddr 10.14.2.1 codec g711alaw
codec-numpackets 3000
tos 184 (DSCP 46x4)
frequency 70
ip sla monitor schedule 1 life forever start-time now

Note:you need to enable "rtr responder" or "ip sla monitor responder" on the remote router.


Sample Data Collections

The data can be viewed using the Cisco IOS show command at the command line on the delay and jitter probes.

R1#sh rtr collection-statistics 1

On Cisco IOS 12.4:
IDL286312#sh ip sla monitor collection-statistics 1

It only shows two hours stats.

how to filter vpns from mpls backbone backup path

below is from sp study group.ccstudy.com:

I have four routers linked in a row, let's say A-B-C-D, and a lower
bandwidth backup link between A and D. I have just added MPLS and set
up several VPNs, but I don't want all VPNs to generate traffic on the
backup link when it comes up. Any idea of how to do it?

here is a possible solution. I have put also the CCIE SP list on CC
since this is more a topic for there...

- create a second loopback interface on the pe-routers.

- add your second loopback interface into your igp so it is reachable

- filter your LDP so it is not assigning and distributing any labels
for this second loopback

- change the next-hop ip-address that bgp will advertise for the
VPN that you do not want to have on the low-bandwidth backup link

Example> Assuming Lo1 is the Loopback where you are not distributing labels
for:
!
ip vrf TWO
rd 2:1
route-target export 2:1
route-target import 2:1
bgp next-hop Loopback1
!

- at this point this VPN will not work anymore, because you have no
LSP to the new Loopbacks

- enable MPLS Traffic Engineering, use the new loopback ip as router-id
for mpls traffic engineering

- build mpls-te tunnels between the new loopback addresses. Use an
explicit path that excludes the ip addresses of the low-bandwidth
backup link.

- at this point the VPN will work again. LSPs are provided through
MPLS-TE. As soon as the main link between your PE routers goes
down the MPLS-TE Tunnel will also go down because they are not
allowed to signal a path through your low-bandwidth link.

hope the explanation is not too confusing.

Comments from Gopal:

below is from sp study group.ccstudy.com:

I have four routers linked in a row, let's say A-B-C-D, and a lower
bandwidth backup link between A and D. I have just added MPLS and set
up several VPNs, but I don't want all VPNs to generate traffic on the
backup link when it comes up. Any idea of how to do it?

here is a possible solution. I have put also the CCIE SP list on CC
since this is more a topic for there...

- create a second loopback interface on the pe-routers.

- add your second loopback interface into your igp so it is reachable

- filter your LDP so it is not assigning and distributing any labels
for this second loopback

- change the next-hop ip-address that bgp will advertise for the
VPN that you do not want to have on the low-bandwidth backup link

Example> Assuming Lo1 is the Loopback where you are not distributing labels
for:
!
ip vrf TWO
rd 2:1
route-target export 2:1
route-target import 2:1
bgp next-hop Loopback1
!

- at this point this VPN will not work anymore, because you have no
LSP to the new Loopbacks

- enable MPLS Traffic Engineering, use the new loopback ip as router-id
for mpls traffic engineering

- build mpls-te tunnels between the new loopback addresses. Use an
explicit path that excludes the ip addresses of the low-bandwidth
backup link.

- at this point the VPN will work again. LSPs are provided through
MPLS-TE. As soon as the main link between your PE routers goes
down the MPLS-TE Tunnel will also go down because they are not
allowed to signal a path through your low-bandwidth link.

hope the explanation is not too confusing.

--
comments from Gopal:

- you use 'bgp next-hop loop-1' for the VRFs whose
traffic shd not ride on the low BW link. Other Vrf's
do not need that command, hence use the default
bgp-nexthop, say loop-0. This is what Reinhold meant
to begin with.

I wd agree with Reinhold's solution for most part
except:

- "filter your LDP so it is not assigning and
> distributing any labels for this second loopback" --


* This doesn't serve any purpose. Though this will
make the VPN to fail on non-TE links, it will not save
the low BW link. The traffic will go over the low BW
link and be dropped at the egress PE.

- "add your second loopback interface into your igp
> so it is reachable"

* you should not advertise the loop-1 IP in OSPF. TE
will work fine without loop-1 IP in routing table. If
this IP is in routing table the problem is when the TE
tunnel is DOWN. When the TE tunnel is down, with IP in
routing table, it follows the IP routing table which
include the low BW link (when prefered link goes
down).

- in summary, you do everything except advertising the
loop-1 in IGP. So far I assumed your IGP is OSPF :-).
But if it is not, then it is easier.

- If your IGP is eigrp or RIP, then you don't need TE
tunnels. you may use distribute-list to stop taking
the loop-1 prefix over the low BW link.

- ACL tweaking is not possible(i wd guess) because
they are label packets.

the difference between RD and RT

What's the difference between (RD) Route Distinguisher and (RT) Route Target?

--the purpose of the RD is to assure uniqueness of the VPN prefixes in the VPNv4 network and that the RT is used to determine which VRFs will import these prefixes.

Why can't RD do that?

--RD could have fulfilled both purposes. The problem is with more complex scenarios, where only using the RD would set a major restriction. Just think of extranet scenarios, where you want to share specific routes between two VPNs. This could not have been achieved using just the RD since you would have been forced to use the same RD in the two VPNs, which would have caused overlapping routes from these two VPNs to overlap in VPNv4. This defeats the purpose of MPLS VPN.

Using two different entities to play two different roles was a way to keep it more flexible.

IPSec,routingprotocls & QoS

IPSec employs two methods of forwarding data across a network for both the AH and ESP protocols:
Tunnel mode
Transport mode

IPSec tunnel mode can completely encapsulate and protect the contents of an entire IP packet including the original IP header.Tunnel mode is generally used for IP unicast-based traffic.If there is a requirement to apply IPSec to multicast applications,non-IP traffic,or routing protocols that use multicast addressing,then the additional use of a GRE header is needed.

With IPSec and GRE working together in tunnel mode,support is available for multicast applications;routing protocols such as OSPF,RIPv2,EIGRP;and transport of non-IP traffic.

Transport mode for either AH or ESP protocol encapsulates the upper-layer payload,above the IP layer.These are typical Layer 4 and higher payloads such as TCP,UDP,BGP,and so on.This leaves the original Layer 3 IP header intact,because it might be needed for certain network services,such as appplications that need to use QoS classifications.(An encrypted original IP header can't be used for QoS applications.)

DCD,DSR,DTR,RTS,CTS

作者: balance,from ciscofan.com

DCD---线路载波检测
DSR---数据设备就绪
DTR---数据终端就绪
RTS---发送请求
CTS---发送清楚

DTR RTS是针对DTE的,而DCD RTS CTS是针对DCE的。

情况一(比较特殊,出现在背对背的时候,也就是路由器作为DCE的时候):
sh int s0/0
Serial0/0 is down, line protocol is down
..................
.................
21 carrier transitions
DCD=up DSR=up DTR=down RTS=down CTS=up

这种情况比较特殊,所有的DCE信号都是up,DTE信号的down,表明这台路由器是作为DCE连接到了一台关机了的路由器上。

情况二(常见):

sh int s0/0
Serial0/0 is down, line protocol is down
..................
.................
21 carrier transitions
DCD=down DSR=down DTR=up RTS=up CTS=down

DTR RTS是up,这两个信号是DTE生成的,此路由器为DTE。这种情况经常就是由于两个路由器之间的传输媒介或者CSU/DSU(可以理解为外接的Modem等设备)。如果是背对背连接表明作为DCE的对端路由器没开机。

the logic behind native VLAN

based on haseeb,Leon van Dongen,Pete Templin,tool shed ,milo_az ,and jitendra's discussion at routerie.com

What is native vlan and what is the purpose and why do we need it?

1.VLAN 1 is the native VLAN by default

2.All ports belong to VLAN 1 by default

3.If the native VLAN is changed from the default, the same should be done on all switches

In case of trunk failure/misconfiguration ports belonging to the same [native] VLAN can communicate with each other because they share the same VLAN ID.

If switch1 thinks VLAN1 is native and switch2 thinks VLAN2 is native, neither VLAN will actually properly pass between switches, and Bad Things will happen.

4.There are two trunking formats,Cisco's ISL (Inter-Switch Link) and IEEEs 802.1Q.
ISL encapsulates frames into a new header.
802.1Q tags frames adding both 802.1Q and 802.1P to the frame header.

5.only 8021q uses tagging
Frames that where originated at the native VLAN traverse 802.1Q trunks without being tagged.
Native vlans are used for untagged traffic. And the packets are NOT modified {dot1q specific}.
It's just the way 802.1Q implemented it. You can always have one VLAN not tagged, if you receive traffic in a trunk that's not tagged you know which VLAN it is.

6.it's mainly for security reasons.
We use a vlan on our trunks that are for that purpose only (native vlan for trunks). No clients, devices or layer 3. If for some reason a device transmits or a spoofed packet is sent that is not tagged, it's basically puts it into a vlan that doesn't go anywhere.

I could have sworn that only one of the two technologies actually sent the frames untagged, but again I need to study.

good network design:
1: Never use VLAN 1; leave it alone for L2 management internals.
2: Set an unused VLAN as your native VLAN, so untagged packets are "in jail".
3: Might also want to set a default access VLAN, so ports not actually assigned to a production VLAN are in a separate "jail".

One prime function of native VLAN can be used in Vlan hopping where the attacker injects traffic to another vlan and there by negotiating its port to become trunk( obviously talking DTP with the switch)
or crafting double tagged frames (externally taged with vlan id of where a traunk natively belongs to).The first case i would say is bi-directional communication and second one is uni-directional communication.The best solution to above problems i would say

a) disable DTP or only enable where necessary.

b) use of an exclusive native vlan for eack trunk

BGP-IGP redistribution

below is from the discussion of dbmack and pete templin at www.routerie.com
the common practice:

Use the bgp redistribute-internal command to enable redistribution of iBGP routes into IGP.

I'm looking for a detailed analysis of the pros & cons of redistribution of EBGP\IBGP into IGP protocols under special circumstances. The more prevalent school of thought is {never do it} & the other is, if you must do it under special circumstances, exercise caution {because of loops}.

For #1, IGPs (or CPUs) just aren't made to handle hundreds of thousands of routes. I and many other service providers have gone to an IGP core with iBGP as my "IGP" for reachability to my customers. As a result, my IGP doesn't see any activity when customer links go up or down, and stays rock-steady at ~205 routes total .

For #2, on the surface this one seems easy. BGP's loop prevention is only accurate to the AS level, not to the hop level. It relies on the IGP for that. Since all of the various BGP 'details' are lost, the IGP will struggle to stay stable.

The mere loss of information (AS path, local pref, MED, communities, etc.) would be enough to talk me out of wanting to do this.

A case study of why NOT:
===================================
On Friday morning, April 25 of 1997, a small ISP in Florida made a mistake in the configuration of the router that joined their small network to Sprint. This ISP, known by their AS number, 7007, allowed all the routes learned from Sprint using BGP to be exported back to Sprint as their own routes. This actually is easy to do, as BGP implementations can take routes from IGP and convert them into EGP routes. In this case, the IGP converted CIDR routes into classful routes.

The Sprint BGP speaker was not filtering properly either, and began sending out updates that added AS7007 as the correct route for a portion every CIDR block (essentially, the first class C, or 24 bit long, network prefix).

This misinformation first spread through Sprint's network, then to neighboring NSPs, including ANS, MCI, UUNet, and other NSPs. Many routers crashed, as their routing tables suddenly doubled in size (an additional route added for each CIDR block), and the routing instability spread throughout the Internet. Remember that when a router crashes, it drops its BPG connection with its peer, who then sends out an update withdrawing all the routes previous announced by the crashed router. It took over an hour for the Internet to gradually become stable again. Network managers added filters that blocked routes that included AS7007, fixing the problem until the ISP solved their local problem and Sprint reconnected them to the Internet.

And this was just an accident, caused by a misconfiguration that redistributed routing information learned from BGP, into an IGP, then back into BGP.
===================================


in some cases you might be forced to use non-BGP routers in your BGP transit network
– multi-vendor environment, old models
– IBGP scaling solutions are not available on intermediate routers
• if the IGP support route tagging, then you might have a chance to convert BGP information into IGP route tags and back
– however, exporting and importing BGP information must be done in a consistent way in the whole routing domain
– some limitations might exist on this conversion, but at least mandatory attributes should be converted and transited


The real key to BGP-IGP-BGP muckups is that the AS path is lost. Subsequently, the routes being originated out of BGP from IGP learned from BGP only have as their AS path. As a result, many other ASes tend to prefer these 'new' routes based on their shorter path.

Another key is that many ISPs place a higher local preference on customer routes than on peer/transit routes. If they accept a full table of short-AS-path routes from a customer and prefer them, they end up thinking the Internet is on the other side of the customer's link, rather than the myriad of interconnections they'd worked so hard to build.

(Confessional debugging moment) Typing that paragraph made me realize a unique design trick that can help prevent catastrophes: use the default local preference to your advantage. Currently, I assign local preference values of 110-300 for upstream routes and 100000-150000 for customer routes. The customer local pref is assigned in the same route map used to prefix and AS filter their announcements. If someone forgets the route map, customer routes inherit local pref 100, and therefore treats them with less preference than any other production route in place. I'd been considering restructuring my LP values, and this provides a constraint for stability.

As far as why TO do it, I'd have to say that reasons 1 and 2 are inexcusable. If your gear can't do BGP right, get rid of it. If your business plan doesn't support that expense, you don't deserve to be in business. For IBGP scaling solutions, the route reflector clients have no clue that they're involved in a scaling solution, so just design around that. Or heck, roll out MPLS and you don't need BGP on P routers

RFC 1268:

A.2.1 Propagation of BGP Information via the IGP

While BGP can provide its own mechanism for carrying BGP information within an AS, one can also use an IGP to transport this information,
as long as the IGP supports complete flooding of routing information(providing the mechanism to distribute the BGP information) and onepass convergence (making the mechanism effectively atomic). If an IGP is used to carry BGP information, then the period of desynchronization described earlier does not occur at all, since BGP information propagates within the AS synchronously with the IGP, and
the IGP converges more or less simultaneously with the arrival of the new routing information. Note: that the IGP only carries BGP information and should not interpret or process this information.

A.2.2 Tagged Interior Gateway Protocol

Certain IGPs can tag routes exterior to an AS with the identity of their exit points while propagating them within the AS. Each border gateway should use identical tags for announcing exterior routing information (received via BGP) both into the IGP and into Internal BGP when propagating this information to other border gateways within the same AS. Tags generated by a border gateway must uniquely identify that particular border gateway--different border gateways must use different tags.

MPLS TE tunnel loadsharing

Below is from Pete Templin's post at www.routerie.com

Logical interfaces can go down. Only loopbacks and null0 don't go down unless administratively shut down.

In the case of TE tunnels, if the tunnel can't signal a path to the tunnel destination with the requested resources (X bandwidth for the configured tunnel priority with the configured tunnel affinity), it WILL go down. In the case of the TE tunnels shown, it will try to signal a path (using make-before-break if the tunnel is currently up) over the configured path-options in increasing numerical order.

As far as the load sharing, it won't be exactly 4:1. CEF has 16 buckets per destination. Those buckets can each have a single exit interface, and all 16 buckets must have an assigned exit interface. 13:3 is perhaps the closest ratio to 4:1 that fits the 16 bucket criteria. Additionally, the flows will be split across the buckets in the ratio selected; if some flows are higher bandwidth than others, the resulting load sharing may appear to be mismatched when looking at bandwidth.

QoS on 3550

Below is from pramodctl ,#14864,www.routerie.com

Since VoIP traffic requires special treatment throughout the network, a carefully designed end-to-end QoS policy is required in a network utilizing voice over data. In order to facilitate in creating this policy, QoS must extend down to the access layer. Traffic marking at the access layer is supported through layer 2 Class of Service (CoS) values.

On the assumption that ur using 3550 series switch:-
By default the 3550 does not process CoS values, and rewrites all frames with a CoS value of zero. To enable the processing of CoS, QoS must be enabled globally by issuing the mls qos global configuration command. Once QoS is enabled you must decide how the switch will process frames that already have a CoS value set. Typically you would want to set the switch to trust the CoS value that is coming from the IP phone. This is accomplished by issuing the "mls qos trust cos" interface level command.

In order to prevent the device attached to the phone from getting better service throughout the network and interfering with VoIP traffic, the Cisco IP phone by default will re-tag all frames received from its extension with a CoS value of zero. To tag them with a different value or to leave them untagged, use the interface level command
"switchport priority extend [ trust | cos value) ].
In the above case all traffic received from the PC attached to the IP phone is remarked with a CoS value of one.

Since ports on the 3550 series switch default to dynamic mode, installing Cisco IP Phones into the network is a very straightforward process. When a phone is connected the 3550 will automatically form an 802.1q trunk to the phone. Traffic destined for the PC attached to the IP phone will be carried in the access VLAN. Voice traffic destined for the phone itself will be carried in the voice VLAN. These VLANs are defined with the "switchport access vlan" and "switchport voice vlan" command respectively.

Note:-

Unlike a data VLAN a voice VLAN will not automatically be created when it is assigned. Be sure to create the voice VLAN in the VLAN
database before assigning it.

Sorry for the lengthy reply but I hope that u will get a very good idea from my explanation.
--------------------------------------------------------------------------------
below is from ChrisL ,# 18270,www.routerie.com

A minor correction (I'm sure you meant it this way anyways). The default configuration does not have mls qos globally enabled. In this configuration CoS and DSCP are left untouched. It is only when MLS QoS is globally enabled that the switch (in the absence of any trust state configuration) will re-mark all CoS and DSCP to zero.

exact prefix match

Below is from p190,Routing TCP/IP,Vol 2,Jeff Doyle

“Access-list 101 permit ip host 192.168.192.0 host 255.255.248.0

The usage of access list 101 might be a bit strange. Normally,the first address specifid in an extended ip access list is the source address,and the second address is the destination . In this application,however,the first address is the route prefix,and the second address is the prefix’s mask.

The reason such an odd access list is necessary is because the exact prefix must be identified. If access-list 1 permit 192.168.192.0 0.0.7.255 were used,it would match both the aggregate 192.168.192.0/21 and the more-specific route 192.168.192.0/24.”

2900/2500 switch QoS FAQ

DSCP conversions


A brief look at the Diffserv field and performing Conversions

By Christopher Larson – CCIE #12380
Superior Technology Networks Corp.