More to the point I believe the original commenter was talking about packet marking, not queuing or classification :)
And here I believe that junos doesn't work well... If you have a link that carries both transit and newly injected traffic you are stuffed when you try to perform a rewrite to correctly mark ingress node traffic but also try to transparently pass through traffic from a trusted source using the same FC. Caillin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Doug Hanks Sent: Monday, 15 October 2012 2:35 PM To: Serge Vautour; Chris Evans; Gustavo Santos Cc: [email protected] Subject: Re: [j-nsp] WAN input prioritization on MX Yes, that's just what I said in so few words :-) Classification = ingress Queuing = egress From: Serge Vautour <[email protected]<mailto:[email protected]>> Reply-To: Serge Vautour <[email protected]<mailto:[email protected]>> Date: Sun, 14 Oct 2012 10:06:37 -0700 To: dhanks <[email protected]<mailto:[email protected]>>, Chris Evans <[email protected]<mailto:[email protected]>>, Gustavo Santos <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [j-nsp] WAN input prioritization on MX Humm. My understand, at least with the command sets I'm use to using, is that you do classification on ingress and then queuing and marking on egress. When you do classification, the packets are assigned to a "Forwarding Class (FC)" inside the box. This makes sure the box gives those packets proper treatment inside the box and that the packets get assigned to the proper egress interface queue. While the packets exit the queue (based on egress schedulers), the packet QoS headers are remarked. Basically, this diagram: http://www.juniper.net/techpubs/images/g017213.gif Packets travel through the box based on the outer boxes following the solid lines. The dotted lines all point to or from the FC to identify how the decision is made. Serge ________________________________ From: Doug Hanks <[email protected]<mailto:[email protected]>> To: Chris Evans <[email protected]<mailto:[email protected]>>; Gustavo Santos <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Sent: Sunday, October 14, 2012 12:09:53 AM Subject: Re: [j-nsp] WAN input prioritization on MX How is this weird? You can mark on ingress, but the queuing happens on the egress interface when it's to be transmitted. On 10/13/12 6:07 AM, "Chris Evans" <[email protected]<mailto:[email protected]>> wrote: >JUNOS does a weird way of marking packets.. It is done on the egress of >the box, not on ingress (there is an exception in a few newer modules >that can do this). So it is probably working as the other poster >mentioned. Make sure you take this methodology into consideration as >it can hinder your granularity of CoS with marking vs passing through >and you inadvertently remark traffic you didn't mean to. > >On Sat, Oct 13, 2012 at 8:21 AM, Gustavo Santos ><[email protected]<mailto:[email protected]>>wrote: > >> Doug and Hanks @juniper. I had to left the office and leave >>configuration as is. On monday I will update you after verify what >>you have pointed, >> >> What I can tell is that I didn't have made any modification on the >>systems default class of service / mapping configuration. >> >> Thank you! >> >> Gustavo Santos >> Analista de Redes >> CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER >> >> >> >> 2012/10/13 Harry Reynolds >> <[email protected]<mailto:[email protected]>> >> >> > Doug raises some good points. >> > >> > Also, for testing, perhaps add some counters to the terms to aid in >> > confirming matches. You may also want to show config | display >> > detail/inheritance to see if the prefix list is expanding as you >>expect. >> > >> > Regards >> > >> > >> > >> > -----Original Message----- >> > From: [email protected]<mailto:[email protected] er.net> [mailto: >> > [email protected]<mailto:juniper-nsp-bounces@puck >> > .nether.net>] On Behalf Of Doug Hanks >> > Sent: Friday, October 12, 2012 9:36 PM >> > To: Gustavo Santos; >> > [email protected]<mailto:[email protected]> >> > Subject: Re: [j-nsp] WAN input prioritization on MX >> > >> > I'm sure it's working just fine. Are you checking the egress >>interface to >> > see if the traffic is being marked and queued properly? A common >>mistake >> is >> > to check the ingress interface queues. >> > >> > >> > If this doesn't work, we would need to see your entire >>class-of-service >> > configuration. >> > >> > On 10/12/12 6:04 PM, "Gustavo Santos" <[email protected]<mailto:[email protected]>> wrote: >> > >> > >Hi, >> > > >> > >I'm new on Juniper class of service / shaping. I'm reading some >> > >tech docs from Juniper and a Juniper's MX book, but it's kind tricky. >> > >Today I get asked to do a pretty simple configuration, but I tried >>some >> > >settings but none of then worked. Any of you guys can help me with >>that? >> > > >> > >What I want to achieve is pretty (conceptualy speaking) simple. I >>have >> > >a Gig interface and want to rate limit the interface at 500Mbits , >>mark >> > >a destination subnet with expedited forwarding class, mark >> > >anything else with best effort. I tried the config below but it's not working. >> > >The rate-limit works but the prioritization isn't. >> > > >> > > >> > > >> > > >> > >gustavo@MX5-1> show configuration firewall family inet filter >> > >wan-control physical-interface-filter; term high-priority { >> > > from { >> > > destination-prefix-list { >> > > high-priority-dst; >> > > } >> > > } >> > > then { >> > > policer limit500; >> > > loss-priority low; >> > > forwarding-class expedited-forwarding; >> > > } >> > >} >> > >term else { >> > > then { >> > > policer limit500; >> > > loss-priority high; >> > > forwarding-class best-effort >> > > } >> > > >> > > >> > >( policer limit500) >> > >physical-interface-policer; >> > >if-exceeding { >> > > bandwidth-limit 480m; (set the value lower to check policer >> > >working.. >> > >but it wasn't as desired) >> > > burst-size-limit 625k; >> > >} >> > >then discard; >> > > >> > >then the filter was applied on the interface family inet filter >> > >input wan-control >> > > >> > >Gustavo Santos >> > >Analista de Redes >> > >CCNA , MTCNA , MTCRE, MTCINE, JUNCIA-ER >> > >_______________________________________________ >> > >juniper-nsp mailing list >> > >[email protected]<mailto:[email protected]> >> > >https://puck.nether.net/mailman/listinfo/juniper-nsp >> > > >> > >> > >> > >> > _______________________________________________ >> > juniper-nsp mailing list >> > [email protected]<mailto:[email protected]> >> > https://puck.nether.net/mailman/listinfo/juniper-nsp >> > >> > >> > >> _______________________________________________ >> juniper-nsp mailing list >> [email protected]<mailto:[email protected]> >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> >_______________________________________________ >juniper-nsp mailing list >[email protected]<mailto:[email protected]> >https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list [email protected]<mailto:[email protected]> https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
