PacketCable Gates | docsis.org

You are here

PacketCable Gates

2 posts / 0 new
Last post
gorlok11
PacketCable Gates

Shouldn't I be seeing active packetcable gates when a eMTA is off hook or when a call is initiated? I see that we have multiple service flows configuring on the CM config (a set for data, and a set for NCS signaling). When a eMTA is picked up, I assume DQOS kicks in and builds the UGS service flows. I would assume CMS acts as policy enforcer to tell the CMTS/eMTA to build the UGS service flow. Am I wrong to assume that a packetcable gate should then be created? Is this because we have packetcable vanilla configured on the CMTS? Should I be concerned or is there a best practice not being followed?

Also, without having access to the CMS, is it possible to see if calls are getting tagged with session class/gate parameters. For instance during a emergency call shouldn't the CMS place a tag on the call for the CMTS to differentiate between 911 calls to toss in the "high priority calls".

cmt01#show cable modem calls

Cable Modem Call Status Flags:
H: Active high priority calls
R: Recent high priority calls
V: Active voice calls (including high priority)

MAC Address IP Address I/F Prim CMCallStatus LatestHiPriCall
Sid (min:sec)
acec.815e.c146 10.197.70.154 C5/0/0/UB 82 V -
e8ed.0555.b552 10.197.58.71 C5/0/1/UB 102 V -
0015.a354.5485 10.197.65.149 C5/0/1/U2 13 V -
001d.dda2.ad82 10.197.90.252 C5/0/2/UB 5618 V -
...
...

cmt01#show cable modem acec.815e.c146 qos
Sfid Dir Curr Sid Sched Prio MaxSusRate MaxBrst MinRsvRate Throughput
State Type
197 US act 82 BE 1 5500000 12500 8000 99
22058 US act 3297 BE 7 87000 3044 8000 0
23196 US act 3878 UGS 0 0 0 0 87275
198 DS act N/A N/A 1 66000000 96000 0 98
22059 DS act N/A N/A 6 64000 96000 8000 0
23191 DS act N/A N/A 5 87200 1522 87200 87347

cmt01#show packetcable gate sum
GateID i/f SubscriberID GC-Addr State Type SFID(us) SFID(ds)

Total number of gates = 0
Total Gates committed(since bootup or clear counter) = 0

cmt01#show packetcabl global
Packet Cable Global configuration:
Packetcable DQOS Enabled : Yes
Packetcable Multimedia Enabled : Yes
Element ID: 89132
Max Gates : 1100000
Allow non-PacketCable UGS
Default Multimedia Timer value -
T1 : 300000 msec
Persistent gate : 0 hour
Volume Limit : STOPPED
Default DQoS Timer value -
T0 : 30000 msec
T1 : 300000 msec
Client Accept Timer: Disabled
Client Accept Timer Expired: 0
Packetcable DQOS Gate Send SubscriberID Enabled: Yes

cmt01#show run | inc packetcable
packetcable element-id 89132
packetcable timer multimedia T1 300000
packetcable authorize vanilla-docsis-mta
packetcable gate send-subscriberID
packetcable gate maxcount 1100000
packetcable multimedia
packetcable

wittmann
packetcable vanilla == high speed for hackers

packetcable vanilla aka dQoS-Lite is a bad decision. With packetcable vanilla the CM can init DSx requests without authorisation. Sure, it's a cheap way to enable dQoS but on the other hands attackers can modify established service flows e.g. the primary service flows via DSx commands via a hacked or diagnostic firmware on its cable modem.

Log in or register to post comments