Frame-relay and Bandwidth

[rkendrick_2]

Question:

We have a Frame-relay network with hub-n-spoke type topologies at various sites. I would like to know how I should be configuring the 'bandwidth' statements on my serial and sub point-to-point interfaces. Should I put the typical T1 bandwidth size of '1536' on the main serial interface and the PVC CIRs on the sub interfaces or should I have 1536 on the main interface with the remote site's port speed on the sub point-to-point? Ex: hub site has a T1 and remote has a 384k access port. The PVC between the 2 sites is only 64k. What should the configuration be on the hub's serial and sub-interfaces and what should the configuration be on the remote's serial and sub-interface

[Georg Pauwen]

Hello,

are you trying to implement a QoS policy, such as Frame Relay Traffic Shaping ? Or are you tring to configure the bandwidth in relation to routing protocol traffic and the percentage used by e.g. EIGRP ?

Regards,

GP

[rkendrick_2]

Right now, I am not trying to implement a QoS policy or traffic shaping. I am trying to configure in relation to routing protocol traffic. We do use EIGRP. Thanx.

[steveo123]

Fist of all the "bandwidth" statement has no effect on the overall speed of the frame relay sub interface circuit, Bandwidth statements is purely for routing path algorithms for upper layer protocols, My suggestion would be to configure the main T1 hub site with 1536 and configure the sub point to point interfaces with your ISP assigned CIR values (64K) . Configuring remote sites port speed of 384k does not mean that the point to point circuit will be available to burst traffic at 384K, anything above the assigned CIR will be marked as "discard eligibility (DE) bit " and will be dropped.

Regards,

Steve K.

[rkendrick_2]

Thanx for your reply. Will do...

[jroyster]

I'd set the bandwidth statements to the remote port speed. Modern frame networks just don't drop frames (not that I've seen with the major providers) provided you don't overflow the egress buffers on the lower speed side. this is best accomplished with traffic shaping.

For example - you have a T1 hub port and a 384 spoke port. Shape the traffic on that PVC to 384.

As far as what are the implications? The bandwidth statement affects your routing protocol/metrics, QoS and traffic shaping so its important to always put a correct bandwidth on an interface.

Some would recommend setting it to the CIR, but I prefer to burst all the time (running at full port speed constantly) instead of shaping to CIR.

[adnan]

You should have your serial inetrface on Hub configured for full T1 and the sub interfaces pointing to the spoke sites should be configured for 384k. On the spoke side serial interface for (bandwidth 384) and sub interface for 38k.

[adnan]

Sorry, I mean 384k

[rkendrick_2]

Thanx guys,

This was very helpful.

[Joseph W. Doherty]

Keeping in mind your subinterfaces are acting, I assume, as independent logical links, you'll want to set the bandwidth statement at the subinterface level. The bandwidth statment often informs the routing protocol of the provisioned bandwidth along a link. With frame-relay, in your example, this could either be the guaranteed bandwidth as defined by the purchased PVC's 64K CIR, or the maximum physical bandwidth, also in your example, of 384K access port at the remote site. Unless you shape or police less than port rate, I recommend using end-to-end maximum physical rate for the bandwidth value. I.e. 384 on both ends.

Although routing protocols usage of bandwidth is more important in a relative sense rather than an absolute sense, besides routing protocols, other higher level functions might use the bandwidth information. For instance, I've seen programs that show/graph link load as a percentage based on current load percentage over the maximum possible bandwidth. e.g. 192 on your PVC would show/graph as 50% load if bandwidth defined as 384 but 300% if bandwidth based on 64.