06-30-2007 01:58 PM - edited 03-03-2019 05:40 PM
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
06-30-2007 04:26 PM
And what are the symptoms of the problem ?
07-02-2007 06:47 AM
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.
07-02-2007 07:31 AM
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.
07-05-2007 03:36 PM
Hi,
I enables the commands that you suggest, but I don't get any positive result.
07-05-2007 03:47 PM
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).
07-05-2007 04:05 PM
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
07-05-2007 04:10 PM
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
07-05-2007 04:19 PM
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
07-05-2007 05:04 PM
Sundar,
Every PVC will inherit 1.5Mbps as the CIR. It defeats the purpose of per-pvc traffic shapping.
07-05-2007 06:08 PM
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
07-05-2007 06:30 PM
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.
07-05-2007 07:11 PM
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.
07-05-2007 08:06 PM
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
07-06-2007 04:41 AM
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)
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: