Task 7.3 - Prioritisation

Does the addition of the frame-relay mincir not break the requirements of q7.1?

Question 7.3 says to "help them out and decrease the latency of their packets" in reference to the gamers.

One should only need to prioritise their packets. The addition of frame-relay mincir 1536000 will affect the normal business hours traffic also on the link and therefore R5 will oversubscribe on the frame relay network with this setting included.

I think this solution fundamentally breaks the requirements of Question 7.1 which states that you are to "Configure FRTS to that all end points of the network CONFORM to the provisioned rate"

A mincir of 1536000 does not conform to the provisioned rate.

Is any body able to provide confirmation or clarification on this?

Additionally, as mentioned elsewhere, the ACL in this SG specifies the port on the destination side of the ACL statement..... it should be on the source side....
i.e.
Rack1R5#sh access-lists
... < output ommitted > ...
Extended IP access list QUAKE-TO-VLAN3
10 permit udp host 154.1.5.100 eq 27960 154.1.3.0 0.0.0.255
Rack1R5#

Comments

  • Hmm.. well, Qos questions are always a bit vague and definitely complicated!

    As you may know the affects of the setting MINCIR are two fold
    1) A minimum rate that FRTS will fall back to in the event of BECNS.
    2) The bandwidth which can be guaranteed during times of congestion.

    Since we have not set adaptive shaping in this question MINCIR will not be used as a minimum traffic-rate. The only affect will be (2) to assign bandwidth during times of congestion - which was requested in the question.

    It is complicated but I think the SG is correct in this aspect. Needless to say, I got it wrong the first time I did the question.

    cheers

    rich
  • Hi Rich,
    Thanks for the reply.

    I disagree however with your explanation regarding the behaviour of mincir.

    http://www.cisco.com/en/US/docs/ios/12_3t/wan/command/reference/wan_f2gt.html#wp1073460

    frame-relay mincir does not work only on the basis of becns being received.

    It specifies the minimum acceptable CIR of a given circuit. Frame-relay becns cause a back off on the sending rate to the minimum acceptable level which is the mincir. But mincir will be the setting regardless of receiving frame-relay becns.

    By setting mincir as has been done in the SG, we have now stipulated to the network that that is our minimum requirement for performance and the router will use the mincir level for transmission.



    Perhaps it would be useful to know, is sending the packets with prioritisation sufficient to meet teh requirements of the question? If so, then I would settle for that as the solution as it wouldn't break the earlier stated requirements. This is really all academic if the only requirement to be correct is that you prioritise. It doesn't say anything about prioritising the traffic and sending traffic at the line rate.
  • Hi Ronnie,

     Quote:
    By setting mincir as has been done in the SG, we have now stipulated to the network that that is our minimum requirement for performance and the router will use the mincir level for transmission.


    No, unless Frame-relay adaptive-shaping is set the MINCIR will not be used. Without adaptive-shaping the only rate that matters is the CIR.


     Quote:
    The Adaptive Frame Relay Traffic Shaping for Interface Congestion feature enhances Frame Relay traffic shaping functionality by adjusting permanent virtual circuit (PVC) sending rates based on interface congestion. When this new feature is enabled, the traffic-shaping mechanism monitors interface congestion. When the congestion level exceeds a configured value called queue depth, the sending rate of all PVCs is reduced to the minimum committed information rate (minCIR). As soon as interface congestion drops below the queue depth, the traffic-shaping mechanism changes the sending rate of the PVCs back to the committed information rate (CIR). This process guarantees the minCIR for PVCs when there is interface congestion.


    http://www.cisco.com/en/US/docs/ios/12_4...de_Chapter.html

    rich
  • The problem I have is that my traffic wants to flow thru r4. When I change f0/0's ip address to 150.1.5.100 and do a trace to 154.1.3.3 I get

    R5#trace 154.1.3.3 source f0/0 port 27960

    Type escape sequence to abort.
    Tracing the route to 154.1.3.3

    1 154.1.45.4 0 msec 0 msec 4 msec
    2 154.1.0.3 28 msec * 28 msec
    my config looks correct

    Serial0/0/0: DLCI 503 -

    Service-policy output: vlan3003

    Class-map: vlan3003 (match-all)
    0 packets, 0 bytes
    5 minute offered rate 0 bps, drop rate 0 bps
    Match: access-group name vlan3003
    Queueing
    Strict Priority
    Output Queue: Conversation 40
    Bandwidth 100 (%)
    Bandwidth 256 (kbps) Burst 6400 (Bytes)
    (pkts matched/bytes matched) 0/0
    (total drops/bytes drops) 0/0

    Extended IP access list vlan3003
    10 permit udp host 154.1.5.100 154.1.3.0 0.0.0.255 eq 27960(I've tried putting the eq 27960 afetr the host no joy on that either)

    The fact is that 150.1.3.0/24 is routed through f0/1 to R4 because of task 3.2 so no traffic will hit r5's s0/0/0.

    So any bottleneck is on the ethernet link between R5 and R4, because after that the traffic shares the same link vice versa for traffic coming back from vlan 3003

    Please feel free to show me the error of my ways

    PS I guess I could PBR the traffic from f0/0 to s0/0/0 in fact.... that wont work to set interface it must be P2P
Sign In or Register to comment.