Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On Thursday, April 04, 2013 08:46:07 AM Per Granath wrote: > That sounds like classification, not rewrite... No, that is rewrite. Classification would be "then forwarding-class". 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
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On Thursday, April 04, 2013 09:16:44 AM Antti Ristimäki wrote: > "then forwarding-class" would be classification, right? That's right. 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
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On 2013-04-04 09:46, Per Granath wrote: > > > On Monday, April 01, 2013 02:49:02 PM ashish verma wrote: >> Ingress ipv6 marking is supported on MX. You need to use 'then traffic >> class'. > > That sounds like classification, not rewrite... "then forwarding-class" would be classification, right? antti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On Monday, April 01, 2013 02:49:02 PM ashish verma wrote: > Ingress ipv6 marking is supported on MX. You need to use 'then traffic > class'. That sounds like classification, not rewrite... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On Monday, April 01, 2013 02:49:02 PM ashish verma wrote: > Ingress ipv6 marking is supported on MX. You need to use > 'then traffic class'. Yes, quite right. Now all we need is EXP and we're golden. 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
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
Ingress ipv6 marking is supported on MX. You need to use 'then traffic class'. On Apr 1, 2013 2:25 AM, "Mark Tinka" wrote: > On Monday, January 14, 2013 10:55:11 AM Per Granath wrote: > > > On egress you may apply a rewrite rule to a class (on an > > interface). Essentially, this means you cannot rewrite > > on ingress. > > On IQ2 and IQ2E PIC's, you can remark on ingress with the > ToS Translation Tables feature. > > On the MX running Trio line cards, you can remark on ingress > with an ingress firewall filter, but sadly, this doesn't > support EXP or IPv6 DSCP bits. > > I like the ToS Translation Tables, but it's limited to > platforms that run those line cards (which is not to say > that an IQ2 or IQ2E PIC in an MX-FPC will work - never > tried). > > Mark. > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On Monday, January 14, 2013 10:55:11 AM Per Granath wrote: > On egress you may apply a rewrite rule to a class (on an > interface). Essentially, this means you cannot rewrite > on ingress. On IQ2 and IQ2E PIC's, you can remark on ingress with the ToS Translation Tables feature. On the MX running Trio line cards, you can remark on ingress with an ingress firewall filter, but sadly, this doesn't support EXP or IPv6 DSCP bits. I like the ToS Translation Tables, but it's limited to platforms that run those line cards (which is not to say that an IQ2 or IQ2E PIC in an MX-FPC will work - never tried). 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
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
Correction: - on MX960, a firewall filter can set FC in ingress and then match on it either on ingress or egress. Thanks Alex - Original Message - From: "Per Granath" To: "John Neiberger" Cc: Sent: Monday, January 14, 2013 3:33 PM Subject: Re: [j-nsp] Confusion about DSCP marking and rewrite rules On egress the (stateless) firewall filter is processed before rewrite/marking. The filter can assign forwarding-class (normally on ingress), but not match on it (on egress). So, this is where you need to re-design your (IOS) logic. Start with a clean sheet, and design a new filter that you can use on egress - or block traffic on ingress. From: John Neiberger [mailto:jneiber...@gmail.com] Sent: Monday, January 14, 2013 5:15 PM To: Per Granath Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Confusion about DSCP marking and rewrite rules That makes perfect sense. I'm not sure what my mental block was with that. lol How does Juniper handle situations where you do need to mark a packet on ingress so that you can match on the new marking on egress? If there is a rewrite rule, does the rewrite happen before any egress firewall filters are evaluated? On the Cisco 7600, we have to add a command to basically recirculate a packet through the ingress interface logic twice to actually re-mark the packet instead of just classifying it. For example, an ingress packet may need to be marked as cs2 and then the same router might have an egress filter facing some interface that only allows cs2. If the marking happens after the egress filter is evaluated, that traffic would be dropped. How does this work in Junos on the MX series? Thanks! John On Mon, Jan 14, 2013 at 1:55 AM, Per Granath mailto:per.gran...@gcc.com.cy>> wrote: Note that "marking" is not word used in Junos... On ingress you do "classification", and on the class assigned you do queuing, etc. The class does not change any bit in the packet header - the class is assigned "outside" the packet header internally in the router. On egress you may apply a rewrite rule to a class (on an interface). Essentially, this means you cannot rewrite on ingress. So, your IRB "marking filter", which in Junos is called "multi field classifier", does not change any bit in the packet headers - it only assigns the internal class - when packets ingress on the IRB. The rewrite rules on the IRB only rewrite bits when a packet egress on the IRB. On some other vendor you may be used to doing rewrite/marking on ingress... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
On egress the (stateless) firewall filter is processed before rewrite/marking. The filter can assign forwarding-class (normally on ingress), but not match on it (on egress). So, this is where you need to re-design your (IOS) logic. Start with a clean sheet, and design a new filter that you can use on egress - or block traffic on ingress. From: John Neiberger [mailto:jneiber...@gmail.com] Sent: Monday, January 14, 2013 5:15 PM To: Per Granath Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Confusion about DSCP marking and rewrite rules That makes perfect sense. I'm not sure what my mental block was with that. lol How does Juniper handle situations where you do need to mark a packet on ingress so that you can match on the new marking on egress? If there is a rewrite rule, does the rewrite happen before any egress firewall filters are evaluated? On the Cisco 7600, we have to add a command to basically recirculate a packet through the ingress interface logic twice to actually re-mark the packet instead of just classifying it. For example, an ingress packet may need to be marked as cs2 and then the same router might have an egress filter facing some interface that only allows cs2. If the marking happens after the egress filter is evaluated, that traffic would be dropped. How does this work in Junos on the MX series? Thanks! John On Mon, Jan 14, 2013 at 1:55 AM, Per Granath mailto:per.gran...@gcc.com.cy>> wrote: Note that "marking" is not word used in Junos... On ingress you do "classification", and on the class assigned you do queuing, etc. The class does not change any bit in the packet header - the class is assigned "outside" the packet header internally in the router. On egress you may apply a rewrite rule to a class (on an interface). Essentially, this means you cannot rewrite on ingress. So, your IRB "marking filter", which in Junos is called "multi field classifier", does not change any bit in the packet headers - it only assigns the internal class - when packets ingress on the IRB. The rewrite rules on the IRB only rewrite bits when a packet egress on the IRB. On some other vendor you may be used to doing rewrite/marking on ingress... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
That makes perfect sense. I'm not sure what my mental block was with that. lol How does Juniper handle situations where you do need to mark a packet on ingress so that you can match on the new marking on egress? If there is a rewrite rule, does the rewrite happen before any egress firewall filters are evaluated? On the Cisco 7600, we have to add a command to basically recirculate a packet through the ingress interface logic twice to actually re-mark the packet instead of just classifying it. For example, an ingress packet may need to be marked as cs2 and then the same router might have an egress filter facing some interface that only allows cs2. If the marking happens after the egress filter is evaluated, that traffic would be dropped. How does this work in Junos on the MX series? Thanks! John On Mon, Jan 14, 2013 at 1:55 AM, Per Granath wrote: > Note that "marking" is not word used in Junos... > > On ingress you do "classification", and on the class assigned you do > queuing, etc. The class does not change any bit in the packet header - the > class is assigned "outside" the packet header internally in the router. > > On egress you may apply a rewrite rule to a class (on an interface). > Essentially, this means you cannot rewrite on ingress. > > So, your IRB "marking filter", which in Junos is called "multi field > classifier", does not change any bit in the packet headers - it only > assigns the internal class - when packets ingress on the IRB. > > The rewrite rules on the IRB only rewrite bits when a packet egress on the > IRB. > > > On some other vendor you may be used to doing rewrite/marking on ingress... > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Confusion about DSCP marking and rewrite rules
Note that "marking" is not word used in Junos... On ingress you do "classification", and on the class assigned you do queuing, etc. The class does not change any bit in the packet header - the class is assigned "outside" the packet header internally in the router. On egress you may apply a rewrite rule to a class (on an interface). Essentially, this means you cannot rewrite on ingress. So, your IRB "marking filter", which in Junos is called "multi field classifier", does not change any bit in the packet headers - it only assigns the internal class - when packets ingress on the IRB. The rewrite rules on the IRB only rewrite bits when a packet egress on the IRB. On some other vendor you may be used to doing rewrite/marking on ingress... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Confusion about DSCP marking and rewrite rules
I'm still learning how Junos handles DSCP marking and I ran into a question based on something I saw in production. Let's assume we have an irb, and in that irb is an ae, and the ae has two physical ports in it. If I want to mark traffic on ingress, does it matter on which interfaces I configure the marking filter and rewrite rules? My guess is that if you only apply them to a single interface, only traffic on that interface will be marked. If you apply it to the ae then all interfaces in that ae bundle will be marked, but other interfaces in the irb wouldn't be marked. If you apply it on the irb then everything goes through the marking filter. Is that about right? This is on an MX960. Are there some nuances on this platform that might affect the decision on where to apply these filters and rules? The odd thing on the interface I'm looking at is that the irb has the ingress marking firewall filter but it does not have the rewrite rules associated with it. Instead, the ae interface has the rewrite rules associated with it. So, on ingress, a frame travels through an ae interface with rewrite rules added to it, but no filter to specify any markings. That doesn't happen until the frame hits the irb, which doesn't have rewrite rules applied. I'm a little confused about why this is working. I would have expected to see the rewrite rules applied to the same L3 interface that has the ingress firewall filter applied. Thanks, John ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
