There are different values you can set in the DSCP. It is a 6 bit field in the IP header while CoS is a 3 bit field between IEEE 802.1q or ISL-Links (only 8 different possible values).
How you mark your traffic (which DSCP number) depends on what you try to do.
Also, trusting the CoS or DSCP value depend on how you trust your endpoints or links. You should define a trusted boundary. For example ... If you don't trust your endpoints you could set the DSCP value according the traffic on an access switch.
"I have tried to find the different values (for example voice is 46), but cannot find what each number is associated to(what is 0? what is 8/)."
It's really up to you what you allocate to what value. As you say there are standards such as voice is mapped to DSCP EF which is value 46 but it doesn't have to be altho you will find that a lot of VOIP devices do this marking by default.
But a lot of the values are not preset ie. they are up to you to define which traffic falls into that value. Also bear in mind that there are a lot more DSCP values than there are CoS values so you can be much more granular in your classification with DSCP. If you then have to switch to CoS you will lose some of that granularity.
"Also, my understanding is that typically you trust cos for layer 2 and trust dscp for layer 3, correct?"
CoS = Layer 2
DSCP = Layer 3
IP Precedence = L3
Whether you choose to trust it or not depends on the device setting the markings. If the end device is a PC you wouldn't generally trust markings coming from a PC ie. would you really want a user to be able to mark all his traffic with DSCP EF and get priority treatment for his traffic ?
"What designates the ingress and egress port?"
Ingress and egress are merely directions on the port. Ingress is traffic coming into the port. Egress is traffic leaving the port. Note that typically a Cisco switch has more queues on egress than it does on ingress.
"Does a switch port have a total of four queues, two ingress and two egress?"
Totally dependent on switch architecture and on the modular switches eg. 4500/6500 on the individual line cards. Catalyst QOS is very dependent on the switch hardware because QOS is performed in hardware, unlike routers. So because routers perform QOS in software it is pretty much standard across all routers. However this is not the case for switches. Each switch supports certain features. Some of these features are supported by all switches but then some switches have more than this subset - 6500 is a good example.
A lot of what i have said is covered in much greater detail in the QOS SRND. It can be a long read but there is a section on Catalyst QOS that would give you a good idea.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...