11

In essence we purchase a 80/20 line from the carrier who provides the transport between the customer premises & the local exchange where the carrier terminates into our PE.

(Juniper PE) <--> [Carrier interconnect in Exchange <---> NTE in customer property] <---> (Cisco CPE - 881,1921,1941,2921))

The circuit between the customer property and the local street cabinet is still copper and therefore as the noise/distance increases the speed reduces.

the actual line speed negotiation is taking place on the carriers NTE not our CPE.

how can I ensure that when the link is saturated priority packets don't get dropped , without actually knowing what the line speed has authenticated to ? can something be done with ipsla ?

DrBru
  • 1,619
  • 3
  • 16
  • 33
  • Are you talking about QoS config on the CPE, for the upload direction? – Baldrick Jul 25 '13 at 14:10
  • @javano bi-directional really , currently the only option available to me is to shape the traffic at both sides to an avg just like you recommend in you answer , I am trying to establish if there is any other way this can be done more accurately. – DrBru Jul 25 '13 at 14:52
  • You can't really solve this without making overly conservative guess of what rate will always be met. Research into terminating the connection directly into your Cisco CPE by removing the NTE. Then the Cisco CPE interface will know linerate. – ytti Jul 25 '13 at 19:30
  • @ytti Thanks , presently its financials driving us to use the carrier as intermediate & fttc is still VERY new here. – DrBru Jul 25 '13 at 19:41
  • 1
    @IanK yes but if it's DSL or something like that, can't you just replace the modem entirely and use only your own CPE? Then you could apply QoS to the interface which is aware of the rate. – ytti Jul 25 '13 at 19:43
  • @ytti , i will do some research on VDSL2 termination on Cisco ISR's but at this stage of the project thats not a option. – DrBru Jul 25 '13 at 19:51
  • @IanK As ytti has said, you need to use the Cisco ISRs as the CPE and NTE. They can terminate VDSL2. Is youe PE/LNS device passed the sync speed value from the intermediary carrier (PPP or Radius attribute), if not, how are you going to QoS the download? – Baldrick Jul 26 '13 at 09:15
  • @IanK, would you mind posting output that shows how you see the negotiated speed on the router? If there is a way to do this with EEM, then perhaps that would help get an answer. – Mike Pennington Aug 26 '13 at 04:53
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Jan 03 '21 at 04:43

1 Answers1

1

One possibility is if you want to QoS traffic upstream toward the CPE's gateway is to shape the traffic outbound, and then prioritise important traffic within that shaping bandwidth.

If this is an 80/20 line and you know the average up speed is say 15Mbps, you could shape the outbound traffic to 15Mbps and prioritise voice within that 15Mbps. If sync speed drops a couple of Mbps it won't make a huge amount of difference. If sync speed rises up to 17Mbps, they will be short of a couple Mbps of upload bandwidth.

I use a config like the blow on some EFM lines. The EFM speed can vary due to line conditions, once installed though they seem to be very consistent. So in this example, this CPE is connected to 20/20 EFM line that actually reliably syncs at 10/10, the upload is shaped to 10Mbps.

class-map match-any CM-VOICE-TRAFFIC
 match access-group 100
!
policy-map PM-PRIORITISE-VOICE
 class CM-VOICE-TRAFFIC
   set ip dscp ef
   priority 1000
 class class-default
   fair-queue
!
policy-map PM-SHAPE-10M
 class class-default
  shape average 10000000
  service-policy PM-PRIORITISE-VOICE
!
interface FastEthernet0/1
 Description WAN Interface
 bandwidth 10000
 service-policy output PM-SHAPE-10M
!
access-list 100 remark Priority IP Destinations
access-list 100 permit ip 1.2.3.0 0.0.0.255 any

It's important that we shape here not rate-limit or police, so that traffic isn't dropped, it's "shaped" to the bandwidth available. Have a read of this Cisco page for some additional info.

Baldrick
  • 5,300
  • 7
  • 38
  • 79
  • 2
    I don't think this works, OP's problem is that he does not know where to shape the connection. If you shape it to 10Mbps you MUST be able to pass 10Mbps to keep 'CM-VOICE-TRAFFIC' contract. – ytti Jul 25 '13 at 19:29