On Thursday, September 02, 2010 06:44:23 am Michel de Nostredame wrote: > It looks like can only perform the TOS bit to TOS bit > translation.
Not quite. My understanding (I can't test this yet) - and from my discussions with Juniper - is that the Translation tables actually rewrite the ToS field based on a user-defined value. So yes, ingress remarking is supported by this. > However the most useful function will need > to leverage firewall filter to perform the "TOS bit > marking" on the ingress. This is actually supported, but has a number of limitations: - the JUNOS firewall filters support then 'then dscp' action, but it's only works on the Trio- based line cards. - if your router has DPC-based line cards, you'd need to apply this to the Loopback interface, which means traffic is switched in software (not good - but haven't tried it to prove). - at this time, it looks like JUNOS only supports DSCP for IPv4 in the firewall filters; I don't see support for DSCP for IPv6 or EXP bits. - I know the M320 or larger supports remarking of ingress traffic, but only to DSCP 0; I'm uncertain whether newer code provides similar support for additional bit values as in the case of the Trio- based cards, or more importantly, which PIC's are supported with this enhancement. > It is very difficult to perform all those sophisticated > marking on the egress interface > by only leverage lame rewrite function. I agree - egress-based remarking (which is the classical way JUNOS has historically implemented this) is not terribly flexible. For cases where we've deployed boxes in a P/PE role, egress remarking is a real pain when interfaces act as transit links for both customer-sourced/destined and core traffic. Ingress remarking is more elegant here, as the different interfaces in a P/PE-based router are uniquely independent from a QoS marking and classification perspective. > For example, depends on PIC we have today, there are only > 4~8 forwarding-class can be used. 16 forwarding-classes, but yes, still 8 queues (can be a bit confusing for the uninitiated, since forwarding-classes and queues can many times be referred to as the same thing). > However, there are > more TOS type we can mark onto a packet. By leveraging > the policy statement together with egress firewall > filters, we can control > the bandwidth consumptions; if under some criteria (ex, > exceed usage), we can "re-mark" this packet to another > TOS (or drop it, or something else.) A lot of use-cases for being able to able to remark traffic as early as possible, i.e., on ingress. > What I requested to my Juniper SE is to make ingress > firewall filter able to "mark" > each packet TOS bit on the "then" section. See my comments as above. Beyond that, it doesn't look like Juniper are going to be doing much more than this, particularly because of the new Translation tables feature. I hope I'm wrong. My beef with Juniper on this is making the cards so "weirdly" that features that appear basic in nature can easily NOT be supported by the hardware when much-needed enhancements appear in later code. It boggles my mind, but could lend itself - in explanation - to the Services modules (MS-PIC, AS-PIC, MS-DPC) concept. Aaarggh, I dunno... > For those J series software router, it should be easy to > roll out these functions > compares to those hardware based box (theoretically...) Yes, theoretically - but then we still have to deal with all the Flow mode nonsense and all that, just to get new features. It's always something :-\. But I digress... Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp