cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1101
Views
5
Helpful
14
Replies

Traffic Problem

angel.batista
Level 1
Level 1

Hi all,

I have the following escenario:

Main router is configured with Traffic Shapping, there is branch routers with VoIP configure, other no. The routers that has VoIp configure work fine, but the routers that doens't has VoIP, has traffic problem with traffic from de main router.

I attached the main router config

14 Replies 14

paolo bevilacqua
Hall of Fame
Hall of Fame

And what are the symptoms of the problem ?

The communication betwen central site comes slow and when you test with extend ping, the times goes very high, but the times between remote site and the central office are well ( this happend only with remote office without VoIP, the remote office with VoIP work fine) .

The problem is only in one direction and remote office without VoIP configuration.

Hello,

can you please enable "ip cef" and "ip route cache".

Then, please do not test with pings from router to router. Test with pings from a PC in the branch to a PC in the hub.

Hi,

I enables the commands that you suggest, but I don't get any positive result.

Edison Ortiz
Hall of Fame
Hall of Fame

When you enable traffic-shapping on a serial interface, all PVCs are automatically assigned 56kbps unless you create a map-class for it.

Please create a map class, without any rtp information, for PVC 35.

You can verify the allocated bandwidth on the PVC, by typing

show frame pvc dlci 35 (please post the results for us to see, thanks).

Angel,

As Edison stated when FRTS is enabled on the main interface any PVC that doesn't haven't it's own map class will start shaping at 56k. If you have too many PVCs, this could be true if it's the hub router, that doesn't have it's own map class then you can configure a map class like the one noted below and apply it on the main (physical) interface. This way any PVC that doesn't have it's own map class will inherit this map class setting.

map-class frame-relay test

frame-relay cir 1544000

int s0/0

frame-relay traffic-shaping

frame-relay class test

HTH

Sundar

Sundar,

I prefer going with per-pvc traffic-shapping.

map-class frame-relay general

frame-relay cir 128000

frame-relay mincir 64000

interface Serial0/0.35 point-to-point

description Conectado a SUC. NO-VOIP

ip address E.E.E.E 255.255.255.252

no ip directed-broadcast

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 35

class general

Edison,

If you read my previous post carefully I stated applying the map class on the main interface on the on the hub router if there are large number of PVCs that do not have it's own map class. I have seen networks terminating 100s of PVCs on the hub router and this is where my suggestion can be helpful. This would simplify the configuration and moreover I don't see any downside to doing it this way.

HTH

Sundar

Sundar,

Every PVC will inherit 1.5Mbps as the CIR. It defeats the purpose of per-pvc traffic shapping.

Not exactly. Remember we are only applying the map class (1.5mbps CIR) on PVCs that don't have any shaping enabled which get throttled down to 56k because of enabling FRTS on the main int. In other words the burst on those PVCs will be restored to the default setting of 1.5mbps which is how much the router would try to push data out those PVCs if no shaping was enabled at all.

HTH

Sundar

Well, that's what I meant, the Per-PVC FRTS under a sub-interface will take precedence over FRTS on the main interface. However, if you look at his config, it does no good assigning 1.5Mbps to subinterfaces - the hub will try to send information down to spokes at that speed (1.5Mbps) while the spokes only support 128kbps.

This is when you start seeing BECN at the spokes and FECN at the hub. As I said before, it defeats the purpose of per-pvc FRTS and it wouldn't help the OP per his config.

I'm not saying that they couldn't be situation where your example applies, but this case is different.

May be I am not following something here. The original post indicates that some remote sites have VOIP whereas the others have no VOIP. He has configured FRTS on the hub site for VOIP site and it affects the performance of non-VOIP remote sites. Both of us agree the reason for that being the bandwidth is restricted to 56k for those site that don't have their own map class. Where in the thread do you see the remote sites have a port speed of 128k. If anything the one thing I see in his config for the VOIP remote site the port speed is 1.5mbps.

If the port speed of the remote site is 1.5 mbps then yes, technically the hub router might be able to push data out at 1.5 mbps provided there's no congestion on the provider network. Moreover, the scenario you quoted, hub pushing more data than what the remote can handle, would cause FECNs register at the remote and BECNs register at the hub site.

I agree it's good to have precision in config but then we don't have all the information needed to make the exact recommendation.

This hub only has 2 spokes(per config). One site has VoIP while the other one does not. His config indicates the VoIP site was configured for 128kbps so the spoke is running at that speed.

Where do you see the VoIP as 1.5Mbps port speed ?

interface Serial0/0.40 point-to-point

description Conectado a la suc. VOIP

ip address D.D.D.D 255.255.255.252

no ip directed-broadcast

no ip route-cache

no ip mroute-cache

frame-relay interface-dlci 40

class VOIP-128

map-class frame-relay VOIP-128

no frame-relay adaptive-shaping

frame-relay cir 128000

frame-relay bc 1280

frame-relay mincir 64000

frame-relay fair-queue

frame-relay fragment 160

frame-relay ip rtp priority 16384 16383 24

Here you go.

controller T1 1/0

framing esf

linecode b8zs

cablelength short 133

ds0-group 0 timeslots 1-24 type e&m-wink-start ---> This is the port speed of T1 (1.5mbps)

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: