Hi,
I have a question regarding matching certain types of modems (vendor / macadr ) in a UsPacketClass.
The purpose is to separate traffic into two serviceflows. The default serviceflow will go through one VRF and the traffic I'm trying to match through another VRF.
I can make it work by matching a specific MAC address (see below), but that would mean making A LOT of config files.
Instead I'm looking for a way to match a certain type of vendor or a mask of macaddresses.
I'm kind of stuck at this so any suggestions would be welcome
UsPacketClass {
ClassifierRef 2;
ServiceFlowRef 2;
RulePriority 20;
ActivationState 1;
LLCPacketClassifier { SrcMacAddress 00:08:B9:11:87:83; }
}
Regards
Torgeir
This looks very complicated to achieve. I just spent 1 hour thinking about it, but came with no answer.
The MAC address is not the way to go, at least as long as you do not know anything about the two clients which connect behind the modem.
My understanding is that you have N where N>1 clients behind the modem and you want M clients on US SF1 and P clients on US SF2 where M+P=N
What can you tell us about the clients. If there is no way to make a difference between the clients, most probably it will be impossible.
Questions which could help:
- do you know the MAC address of the clients?
- do you know the IP of the clients?
- do you know the interface on which they connect?
- is the traffic they send marked in any way?
There must be something different between the clients, but you did not mention what that is. It looks similar to the CommunityWiFi problem and the difference there was a different SSID for some clients.
Looks interesting, let me know how can you differentiate the clients or what do you know about that traffic.
TLV 22.10.2 does not support a mask, only 22/23.10.1 which is DstMacAddress. I just realized that and it looks weird from MULPI spec perspective. Again, CableLabs specs are weird in many ways so nothing to worry about.
Thanks for the reply xsimio.
Sorry about the late answer.
To elaborate this..
I have a set of STB (set-top-box) with known MAC-addresses. These boxes get a fixed range of IP-adresses (10.18.x.x)
I want all traffic from those MAC/IP's to go the SF2.
The customer also have the ability to connect a CPE-unit to the STB and will get a offical IP-address that will go to SF1 (default)
They all connect on Bundle 1.1 today.
The traffic is not marked in any way that we can distinguish.
CMTS
\_ STB
. |_ Modem mgmt IP
. |_ STB-IP (10.18.x.x)
. \
...\___ Customer CPE
...... \__ Official IP
The problem as you describe is in the lack of support for a mask in TLV 22.10.2, which would have solved the problem.
Unless I am missing something....
Why don't you create a USClassifier by ip for the STBs instead of by known mac?
like so this is what we do for our MTAs same concept
UsServiceFlow
{
UsServiceFlowRef 2;
QosParamSetType 7;
ServiceClassName "U_STB";
}
UsPacketClass
{
ClassifierRef 100;
ServiceFlowRef 2;
ActivationState 1;
IpPacketClassifier
{
IpProto 257;
IpSrcAddr 10.18.0.0;
IpSrcMask 255.255.0.0;
IpDstAddr 0.0.0.0;
IpDstMask 0.0.0.0;
}
RulePriority 1;
}
If you need to give those settops different IPs based on MAC address or mac prefix (first 6 digits), this is usually best achieved with your dhcp server.
is that we're sending the different SF to different VRF's.
So when the STP asks for a IP (in multicast), it will go through the default SF and default VRF. When the IP is acquired it will try to send a ACK package to the DHCP-server (unicast), but this time, it will go through the SF we classified to those IP's and through another VRF. So the ACK will never reach the DHCP server and we can't finish the initial setup.
Gotcha...
Then will adding the destination address and mask to the Packet classifier help? i.e. traffic from 10.18.0.0/16 destined to 10.18.0.0/16 gets new SF
like so?
UsPacketClass
{
ClassifierRef 100;
ServiceFlowRef 2;
ActivationState 1;
IpPacketClassifier
{
IpProto 257;
IpSrcAddr 10.18.0.0;
IpSrcMask 255.255.0.0;
IpDstAddr 10.18.0.0;
IpDstMask 255.255.0.0;
}
RulePriority 1;
}
Classifier by destination IP can be the answer if the video traffic is SPTS unicast. Which is a good idea to be, I do like that design.
If the video traffic is multicast, the classifier by IP might not work as expected.
Are you doing Multicast traffic via Downstreams?