Re: [j-nsp] GRE packet fragmentation on j-series
Thanks for quick response, i had a hoped that this could be done in other whey.
I think jseries need extra license for IDP.
On Jan 24, 2012, at 11:35 PM, Alex Arseniev wrote:
My understanding is that GRE fragmentation should occur if egress interface
MTU is GRE pkt size.
For GRE reassembly, you need IDP policy, this means high memory SRX model.
IDP license is not needed.
Rgds
Alex
- Original Message - From: Lukasz Martyniak
lmartyn...@man.szczecin.pl
To: juniper-nsp@puck.nether.net
Sent: Tuesday, January 24, 2012 2:04 PM
Subject: [j-nsp] GRE packet fragmentation on j-series
Hi all
I have some problem with gre tunnels. I need to fragment packages in tunnel.
I run gre between two jseries (junos 10.4R6) and lunch MPLS on it. The
problem looks like that packages with MTU above 1476 are not
fragmented/reassembled and are dropped.
interfaces gr-0/0/0
unit 10 {
clear-dont-fragment-bit;
description Tulne to r1-lab;
tunnel {
source 10.200.0.1;
destination 10.200.0.2;
allow-fragmentation;
path-mtu-discovery;
}
family inet {
mtu 1500;
address 100.100.100.1/30;
}
family mpls {
}
}
Have someone have similar problem ? is there a simple way to fix this ?
Best Lukasz
___
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
[j-nsp] Network-control queue counter increases on ccc-configured interface
Dear all,
I have detected a strange behaviour on one of our ccc-configured gigabit
ethernet interface.
I have a P2P ccc service and at one end strangely network-control queue
counter is increasing as seen below.
There is no other ccc-configured service on the router is getting increment
on their network-control queue.
LON show configuration interfaces ge-2/0/4
apply-groups customer-template;
description Customer-A;
gigether-options {
no-flow-control;
}
unit 0 {
family ccc {
policer {
input 200m-bw-limit;
output 200m-bw-limit;
}
LON show configuration groups customer-template
interfaces {
* {
mtu 9188;
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
Queue counters: Queued packets Transmitted packets Dropped
packets
0 best-effort 2674026389
26740263910
1 expedited-fo 0
00
2 assured-forw 0
00
3 network-cont 832
8320
Is there anybody has such experience on Juniper MX switches?
Thanks and regards,
Gokhan Gumus
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On (2012-01-26 12:49 +0100), Gökhan Gümüş wrote: I have detected a strange behaviour on one of our ccc-configured gigabit ethernet interface. 'show class-of-service interface' should show you what classifier and what scheduler you are using. For IP interfaces, per default prec 0b110 and 0b111 are classified as EF rest BE and scheduler as 5% EF, BE 95%. If you want 100% BE, you need change your config. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper MX40 / MX80 as a edge aggregator
On Wednesday, January 25, 2012 10:25:48 PM Paul Stewart wrote: - the BRAS function seems quite cutting edge for me at this point to be honest. Our feelings are similar re: BRAS even for the chassis-based MX-series routers (MX480 in our case). We're having to run the very latest code as it comes off the line, literally, to make sure we have even the basic features from our old BRAS. 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] Internet routes in MPLS network, global table or own VRF?
On Thu, Jan 26, 2012 at 6:52 AM, Mark Tinka mti...@globaltransit.net wrote: Keeping it really stupid is what we're after :-). Mark. We run Internet in a VRF, but I have to agree with Mark's comments. Unfortunately, there are lots of Engineers/Vendors/Security Experts/Auditors who think that making it really complex is much better than keeping it really stupid. For that reason, Everything in a VRF (tm) is sometimes a useful thing to do. -- Tim: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Network-control queue counter increases on ccc-configured interface
Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
Dear Saku, For note, i have not got any qos configuration on my router. Kind regards, Gokhan On Thu, Jan 26, 2012 at 4:15 PM, Gökhan Gümüş ggu...@gmail.com wrote: Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
Well NC (network control) is a completely different queue than EF (expedited forwarding). This could be normal. Several things such as routing protocol updates are set to NC by default because it is network control traffic or part of the network control plane. Such traffic should be prioritized during congestion to keep the paths stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring out what it is. Is it possible that it's just a control protocol? I know most routing protocols mark their hello's as NC. Spanning tree BPDU's might do the same but I can't remember off the top of my head. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ 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] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Mark Tinka mti...@globaltransit.net: On Sunday, January 22, 2012 08:55:07 AM Derick Winkworth wrote: http://packetpushers.net/internet-as-a-service-in-an-mpls -cloud/ We also want to avoid putting too much reliance on MPLS for basic services like Internet access. We relegate MPLS-based services to those that MUST have it to work, e.g., BGP- MVPN's, l2vpn's, l3vpn's, VPLS, e.t.c. Anything else that doesn't really need MPLS lives on its own, e.g., IPv6 (no need for 6PE), Internet access, e.t.c. What do you use for signaling? It seems like overkill to keep one kind of traffic from using the MPLS operations if there are already LSP's between the source and the destination and L3/L2vpn traffic flowing between them. You also give up some of the MPLS knobs such as FRR and link/node protection. What do you gain by doing this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On (2012-01-26 16:15 +0100), Gökhan Gümüş wrote: How can i use %100 BE by changing my config in Juniper? You need to do two things to avoid 95/5 split. A) change classifier to make all code points BE B) change scheduler to give all BW to BE (this is strictly not needed, as when the 5% NC is not being used, it can borrow from BE). If or not you actually want to do this, or deploy more thought-out QoS strategy is another matter. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On (2012-01-26 10:52 -0500), Keegan Holley wrote: stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring Yet in INET facing router, jnpr default 95/5 split causes just that, any user in Internet can get special 5% of privileged capacity from your network. Which is strictly different from csco default, which is 100% BE. Now one could argue, that if you care about QoS enough to change the config, more planned approach than jnpr or csco default should be pursued. But at very least you'd probably want to to guarantee that transit and peering interfaces cannot inject arbitrary amount of traffic to your !BE queue. Given that I'd need to implement QoS strategy from scratch, and that I'd want to use only 8 values, so I can carry my QoS in EXP/801.1p, I'd do something like this in core (SP focused): 0 - normal INET (e.g. transit customer traffic) 1 - worse than normal (e.g. offsite tape backup) 2 - important INET(e.g. traffic to own ASN, instead of transit customer) 3 - normal VPN(e.g. 0 received from CPE is reset to 2) 4 - preferred (e.g. software required to work at office) 5 - priority (e.g. voice+video, [5 is default in many phones]) 6 - high demand (e.g. internal pstn trunks etc) 7 - network control (e.g. IGP, LDP, iBGP, MGMT) 0 received from INET customer CPE is reset to 2 0 received from VPN/ customer CPE is reset to 3 7,6 received from INET/VPN customer is reset to 5 2,3 received from iNET/VPN customer is reset to 4 Non-QoS customer is reset to 0, 2 or 3 depending on customer type. I'd never touch customer TOS byte and I'd never classify based on it, but would instead use 802.1p/EXP throughout the network. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
Thanks for the replies. I do not have any CoS configuration on my router. There is no Spanning-Tree is running between my device and customer device. I have no idea what is causing an increment in the network-control queue. Any ideas would be appreciated. Thanks and regards, Gokhan On Thu, Jan 26, 2012 at 4:52 PM, Keegan Holley keegan.hol...@sungard.comwrote: Well NC (network control) is a completely different queue than EF (expedited forwarding). This could be normal. Several things such as routing protocol updates are set to NC by default because it is network control traffic or part of the network control plane. Such traffic should be prioritized during congestion to keep the paths stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring out what it is. Is it possible that it's just a control protocol? I know most routing protocols mark their hello's as NC. Spanning tree BPDU's might do the same but I can't remember off the top of my head. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ 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] Network-control queue counter increases on ccc-configured interface
2012/1/26 Saku Ytti s...@ytti.fi: On (2012-01-26 10:52 -0500), Keegan Holley wrote: stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring Yet in INET facing router, jnpr default 95/5 split causes just that, any user in Internet can get special 5% of privileged capacity from your network. Which is strictly different from csco default, which is 100% BE. That's not exactly accurate. Cisco's kit also has some queuing setup by default. The details vary by platform. Every cisco router I've worked with defaults to trusting incoming markings rather then rewriting them to best effort. So the cisco default is vaguely similar. Also, in order for someone to take advantage of this queue they would have to get across you're upstreams which means they are doing the same thing. It would then be your fault for not remarking traffic on ingress. It looked like only 832 packets came in as network control so I doubt someone is being malicious. They look like periodic hello's from something which is why I cautioned against flattening the network. I would still hesitate to do a way with queueing all together on the interface. The NC queue doesn't use any bw when it's empty and it may save you from problems if there is congestion in the future. Admittedly, this practice was started when the world had much lower bandwidth links. Now one could argue, that if you care about QoS enough to change the config, more planned approach than jnpr or csco default should be pursued. But at very least you'd probably want to to guarantee that transit and peering interfaces cannot inject arbitrary amount of traffic to your !BE queue. I can't see this being a huge risk. Most of your upstreams will remark on ingress and not hand you traffic tagged with NC. If you are large enough not to have upstreams then you shouldn't be getting your QOS policy from a news group. I think marking most traffic down to BE and leaving the default queues would be fine for most networks unless you have a specific plan. Most networks should have a specific plan here, but ymmv. I would hesitate to flatten everything to BE though for the reasons stated above. Given that I'd need to implement QoS strategy from scratch, and that I'd want to use only 8 values, so I can carry my QoS in EXP/801.1p, I'd do something like this in core (SP focused): 0 - normal INET (e.g. transit customer traffic) 1 - worse than normal (e.g. offsite tape backup) 2 - important INET (e.g. traffic to own ASN, instead of transit customer) 3 - normal VPN (e.g. 0 received from CPE is reset to 2) 4 - preferred (e.g. software required to work at office) 5 - priority (e.g. voice+video, [5 is default in many phones]) 6 - high demand (e.g. internal pstn trunks etc) 7 - network control (e.g. IGP, LDP, iBGP, MGMT) 0 received from INET customer CPE is reset to 2 0 received from VPN/ customer CPE is reset to 3 7,6 received from INET/VPN customer is reset to 5 2,3 received from iNET/VPN customer is reset to 4 This is good for some, but it's hard to recommend a queuing policy to someone without understanding what they do with their network. I've made due in the past with only 4 queues, especially when juniper pic's only had 4. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interfaceL
On (2012-01-26 18:24 +0100), Gökhan Gümüş wrote: Thanks for the replies. I do not have any CoS configuration on my router. There is no Spanning-Tree is running between my device and customer device. I have no idea what is causing an increment in the network-control queue. This is default jnpr config and as such normal. On ingress IP Precedence values 0b110 and 0b111 are classified such that when egressing this interface, they'll get their own magic 5% of privileged capacity. And indeed it's named by default NC (thanks Keegan, not EF). Any ideas would be appreciated. My suggestion would be to device QoS strategy that supports your business. But if congestion in your network is never expected, and you want CSCO-like behaviour then you should change default classifier in interfaces so that all code-points would point to BE, then all traffic would get queued with equal priority on egress. (But I still like even big SPs using JNPR default, I can always get my own 5% in those networks when they're congested:) -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
You said this is a ccc interface. Is the customer connecting to this device through this interface or is this part of a L2 circuit that traverses this interface. If it is the latter, they could be running a protocol over the circuit that is being placed in your NC queue. Also, how long did it take to increment? If it only logged 832 packets in a few hours or days I'd ignore it. Reconfiguring qos without understanding the traffic flows may be worse. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Thanks for the replies. I do not have any CoS configuration on my router. There is no Spanning-Tree is running between my device and customer device. I have no idea what is causing an increment in the network-control queue. Any ideas would be appreciated. Thanks and regards, Gokhan On Thu, Jan 26, 2012 at 4:52 PM, Keegan Holley keegan.hol...@sungard.com wrote: Well NC (network control) is a completely different queue than EF (expedited forwarding). This could be normal. Several things such as routing protocol updates are set to NC by default because it is network control traffic or part of the network control plane. Such traffic should be prioritized during congestion to keep the paths stable. I wouldn't use the NC queue for other traffic if you can avoid it and I wouldn't make this traffic best effort without figuring out what it is. Is it possible that it's just a control protocol? I know most routing protocols mark their hello's as NC. Spanning tree BPDU's might do the same but I can't remember off the top of my head. 2012/1/26 Gökhan Gümüş ggu...@gmail.com: Dear Saku, Thanks for the reply. I checked the queues on the interface as seen below; LON show class-of-service interface ge-2/0/4 Physical interface: ge-2/0/4, Index: 158 Queues supported: 8, Queues in use: 4 Scheduler map: default, Index: 2 Logical interface: ge-2/0/4.0, Index: 216 How can i use %100 BE by changing my config in Juniper? Thanks and regards, Gokhan ___ 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] Network-control queue counter increases on ccc-configured interface
On (2012-01-26 12:32 -0500), Keegan Holley wrote: That's not exactly accurate. Cisco's kit also has some queuing setup by default. The details vary by platform. Every cisco router I've worked with defaults to trusting incoming markings rather then rewriting them to best effort. So the cisco default is vaguely similar. Also, in order for someone to take advantage of this queue No cisco router does this to my understanding, some cisco routers use TOS values in punt path by default in attempt for rudimentary CoPP. But no Cisco that I know or have tested has different transit scheduling per class network control so I doubt someone is being malicious. They look like periodic hello's from something which is why I cautioned against flattening the network. Either you control who can congest this class, or you shouldn't use it. As if it is not used, then dossing the service relying on the 5% NC is trivial, compared to all traffic being BE. I can't see this being a huge risk. Most of your upstreams will remark on ingress and not hand you traffic tagged with NC. If you are I know that we don't do it, we never touch or trust TOS, we view it as customer property and cleanly pass it over INET (maybe customer wants to use them inside their LAN and signal it still over INET). If you run MPLS network this is easy, if you don't have labeled forwarding, there is no option but to reset incoming TOS value in peering/transit, if you are doing any Qos (which in case of JNPR default you are). This is good for some, but it's hard to recommend a queuing policy to someone without understanding what they do with their network. I've made due in the past with only 4 queues, especially when juniper pic's only had 4. Yeah it maybe be more complex than absolutely needed, you can do lot with 4. And frankly if you need to start dropping in many classes, maybe you should just upgrade your links. Mainly what I'm driving for is that during INET sourced DoS most services continue work. So even two classes can be good for most. But then, maybe during this INET sourced DoS you want some INET stuff to continue working, and via SCU/DCU it's easy to use like bgp community signalled recolouring (say important/low risk customer will get better TOS and keeps working when low importance/high risk INET sourced DoS) -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote: What do you use for signaling? It seems like overkill to keep one kind of traffic from using the MPLS operations if there are already LSP's between the source and the destination and L3/L2vpn traffic flowing between them. You also give up some of the MPLS knobs such as FRR and link/node protection. What do you gain by doing this? We signal mostly by LDP, and scarcely by RSVP. One of the main reasons we allow Internet traffic to be forwarded by MPLS through the network is to enjoy a BGP-free core for IPv4. That's the only relation the global table has with MPLS. Otherwise, MPLS is used strictly for MPLS-based applications. We only use RSVP for p2mp LSP's for our BGP-MVPN Multicast (IPTv) services, and also for focused TE requirements, e.g., unequal cost paths within the core. As the TE is mostly for Internet traffic, we don't turn on FRR for that. We only enable FRR for the p2mp RSVP-based LSP's, and those are dedicated to IPTv. 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] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Mark Tinka mti...@globaltransit.net: On Friday, January 27, 2012 12:36:50 AM Keegan Holley wrote: What do you use for signaling? It seems like overkill to keep one kind of traffic from using the MPLS operations if there are already LSP's between the source and the destination and L3/L2vpn traffic flowing between them. You also give up some of the MPLS knobs such as FRR and link/node protection. What do you gain by doing this? We signal mostly by LDP, and scarcely by RSVP. One of the main reasons we allow Internet traffic to be forwarded by MPLS through the network is to enjoy a BGP-free core for IPv4. That's the only relation the global table has with MPLS. Otherwise, MPLS is used strictly for MPLS-based applications. I agree... I think. MPLS has a better forwarding paradigm and the IGP only core of P routers is a plus. We only use RSVP for p2mp LSP's for our BGP-MVPN Multicast (IPTv) services, and also for focused TE requirements, e.g., unequal cost paths within the core. As the TE is mostly for Internet traffic, we don't turn on FRR for that. We only enable FRR for the p2mp RSVP-based LSP's, and those are dedicated to IPTv. Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On (2012-01-26 12:32 -0500), Keegan Holley wrote: I can't see this being a huge risk. Most of your upstreams will remark on ingress and not hand you traffic tagged with NC. If you are I've not actually before tested how typically in INET would NC propagate, but I just ran ping -Q192 from 74 nodes around the Internet, and this is what I got back: % sudo tshark -i eth0 ip[1]==192 and dst host 194.100.7.227 -w prec5.pcap Running as user root and group root. This could be dangerous. Capturing on eth0 55 So 55/74 vantage points passed 0b101 to my server. Vantage points here: https://ring.nlnog.net/participants/ So you shouldn't trust others to do TOS resetting for you, if you do trust TOS and you do want to continue trusting it (instead of rewriting cos/exp value and trust it instead) you should reset it in peering/transit. Neat way to get your own 5% from congested default configured JNPR network -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
% sudo tshark -i eth0 ip[1]==192 and dst host 194.100.7.227 -w prec5.pcap Running as user root and group root. This could be dangerous. Capturing on eth0 55 So 55/74 vantage points passed 0b101 to my server. (192 obviously is 0b110, not 0b101) I tested 0b101/prec5 also and propagation was same for both. 0b111 had bit poorer propagation. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
That's not exactly accurate. Cisco's kit also has some queuing setup by default. The details vary by platform. Every cisco router I've worked with defaults to trusting incoming markings rather then rewriting them to best effort. So the cisco default is vaguely similar. Also, in order for someone to take advantage of this queue No cisco router does this to my understanding, some cisco routers use TOS values in punt path by default in attempt for rudimentary CoPP. But no Cisco that I know or have tested has different transit scheduling per class The 6509 and the other L3 switch platforms (not sure about the nexus) come to mind here. Not sure about the CRS and ASR-9k though. network control so I doubt someone is being malicious. They look like periodic hello's from something which is why I cautioned against flattening the network. Either you control who can congest this class, or you shouldn't use it. As if it is not used, then dossing the service relying on the 5% NC is trivial, compared to all traffic being BE. I agree it's best practice to control it. I was just saying it's not much of an attack vector. I can't see this being a huge risk. Most of your upstreams will remark on ingress and not hand you traffic tagged with NC. If you are I know that we don't do it, we never touch or trust TOS, we view it as customer property and cleanly pass it over INET (maybe customer wants to use them inside their LAN and signal it still over INET). You can't not touch and not trust traffic at the same time. You trust it, in which case you're doing the same thing you suggest the OP avoid, in that you can't control who's putting what traffic in your queues. If you don't trust then you have to remark to control what queues each type of traffic is placed in. You can also map all markings to a single queue but that would defeat the purpose of marking traffic in the first place. If you run MPLS network this is easy, if you don't have labeled forwarding, there is no option but to reset incoming TOS value in peering/transit, if you are doing any Qos (which in case of JNPR default you are). You can always re-write the QOS bits incoming no matter what protocol you use. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On (2012-01-26 13:47 -0500), Keegan Holley wrote: The 6509 and the other L3 switch platforms (not sure about the nexus) come to mind here. Not sure about the CRS and ASR-9k though. If you do 'mls qos' you magically turn on classification and scheduling in single command, but that is not default. I agree it's best practice to control it. I was just saying it's not much of an attack vector. I'm less confident. You can't not touch and not trust traffic at the same time. You trust it, in which case you're doing the same thing you suggest the OP I mean don't touch and don't trust TOS, never use it for anything always colour EXP/802.1p and trust them. You can always re-write the QOS bits incoming no matter what protocol you use. Yes, but if you use MPLS, you can do QoS without mangling TOS. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR for high loads is like sending trucks from a speedway to a narrow detour path through a village 10 miles away. Only effect is getting it jammed. The Internet users will also not notice a well-tuned IGP reroute or a head-end switchover to a pre-signaled backup LSP. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Pavel Lunin plu...@senetsy.ru: Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. FRRed traffic can follow very fancy routes eating bandwidth on the way. FRR for high loads is like sending trucks from a speedway to a narrow detour path through a village 10 miles away. Only effect is getting it jammed. The Internet users will also not notice a well-tuned IGP reroute or a head-end switchover to a pre-signaled backup LSP. I can see this happening in some corner cases, but generally speaking why would FRR LSP's take a route different than what the IGP would converge to. CSPF is roughly SPF over a different set of values. I'm asking because I've never seen this in the wild, but I'm usually switching from one speedway to another without the burden of narrow villages. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
why would FRR LSP's take a route different than what the IGP would converge to. Because FRR uses a path from a different entry (PLP) to probably a different exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) is a path from head-end to tail-end. Whether this happens often or rare, the need to care how your detours are calculated is itself a big enough headache. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. Absolutely. This is why in case of issues you should not waste time for explaining why your core router is 200ms away from the previous hop. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
2012/1/26 Pavel Lunin plu...@senetsy.ru: why would FRR LSP's take a route different than what the IGP would converge to. Because FRR uses a path from a different entry (PLP) to probably a different exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) is a path from head-end to tail-end. Whether this happens often or rare, the need to care how your detours are calculated is itself a big enough headache. That's not how FRR works at least for RSVP. It pretty much just re-runs cspf with something removed. So it's the same route your IGP would choose if said thing went dark. I don't have many obscure paths where I wouldn't want traffic to go so I can't really comment on your earlier idea. That being said I've never seen FRR choose a path worse than the path the IGP would choose. It's just preselects that path and pre-signals it. I'm sure there are failure scenarios though. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. Absolutely. This is why in case of issues you should not waste time for explaining why your core router is 200ms away from the previous hop. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On 01/26/2012 06:47 PM, Keegan Holley wrote: That's not exactly accurate. Cisco's kit also has some queuing setup by default. The details vary by platform. Every cisco router I've worked with defaults to trusting incoming markings rather then rewriting them to best effort. So the cisco default is vaguely similar. Also, in order for someone to take advantage of this queue No cisco router does this to my understanding, some cisco routers use TOS values in punt path by default in attempt for rudimentary CoPP. But no Cisco that I know or have tested has different transit scheduling per class The 6509 and the other L3 switch platforms (not sure about the nexus) come to mind here. Not sure about the CRS and ASR-9k though. I don't think the 6500 defaults to trusting incoming markings. It does setup queueing when you mls qos, but nothing goes into the new queues because the default port state is untrust. So it's sort of the opposite to what happens on JunOS, if I'm understanding this thread. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Reboot after panic
Dear All, Our M10 (7.4R.1.4) restarts every 5 minutes. During the boot process the output shows the following message: savecore: reboot after-panic: Loss of soft watchdog The only way to avoid reboots is typing the command / sbin / watchdog-off. Is there someone who has any idea about the problem ? or How can I know why the watchdog ?. Thanks and regards, Isidoro ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
On Jan 26, 2012, at 4:01 PM, Keegan Holley keegan.hol...@sungard.com wrote: 2012/1/26 Pavel Lunin plu...@senetsy.ru: why would FRR LSP's take a route different than what the IGP would converge to. Because FRR uses a path from a different entry (PLP) to probably a different exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) is a path from head-end to tail-end. Whether this happens often or rare, the need to care how your detours are calculated is itself a big enough headache. That's not how FRR works at least for RSVP. It pretty much just re-runs cspf with something removed. So it's the same route your IGP would choose if said thing went dark. I don't have many obscure paths where I wouldn't want traffic to go so I can't really comment on your earlier idea. That being said I've never seen FRR choose a path worse than the path the IGP would choose. It's just preselects that path and pre-signals it. I'm sure there are failure scenarios though. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. Absolutely. This is why in case of issues you should not waste time for explaining why your core router is 200ms away from the previous hop. ___ 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] Internet routes in MPLS network, global table or own VRF?
Because FRR uses a path from a different entry (PLP) to probably a different Ups, I meant PLR, of course. exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) is a path from head-end to tail-end. Whether this happens often or rare, the need to care how your detours are calculated is itself a big enough headache. That's not how FRR works at least for RSVP. It pretty much just re-runs cspf with something removed. So it's the same route your IGP would choose if said thing went dark. I don't have many obscure paths where I wouldn't want traffic to go so I can't really comment on your earlier idea. That being said I've never seen FRR choose a path worse than the path the IGP would choose. It's just preselects that path and pre-signals it. I'm sure there are failure scenarios though. Seems like you confuse FRR (aka local repair) with secondary LSP path. FRR path setup is initiated by P routers, when the primary and secondary LSP paths are initiated by head-end PE. FRR detour only holds until IGP recalculates a new path (doesn't much matter with or without TE), which can (and very probably will) not even include the P router, acted as a point of local repair after failure. http://www.juniper.net/techpubs/software/junos/junos94/swconfig-mpls-apps/fast-reroute-overview.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
I think Pavel is speaking of the case where the PLR is more than one hop from the ingress node. It is very topology dependent but you can end up with bypasses or detours taking a different path than the IGP especially when its a few hops from the ingress node. Also ring topologies introduce wrapping which can add congestion in the opposite direction. Partial mesh alleviates some of that but most networks have some kind of ring element somewhere. Phil On Jan 26, 2012, at 4:01 PM, Keegan Holley keegan.hol...@sungard.com wrote: 2012/1/26 Pavel Lunin plu...@senetsy.ru: why would FRR LSP's take a route different than what the IGP would converge to. Because FRR uses a path from a different entry (PLP) to probably a different exit (say, next-next-hop). When normal LSP (either SPF or CSPF calculated) is a path from head-end to tail-end. Whether this happens often or rare, the need to care how your detours are calculated is itself a big enough headache. That's not how FRR works at least for RSVP. It pretty much just re-runs cspf with something removed. So it's the same route your IGP would choose if said thing went dark. I don't have many obscure paths where I wouldn't want traffic to go so I can't really comment on your earlier idea. That being said I've never seen FRR choose a path worse than the path the IGP would choose. It's just preselects that path and pre-signals it. I'm sure there are failure scenarios though. What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. Hey kitty photos are serious business especially if you are facebook stalking the aforementioned kitty. Absolutely. This is why in case of issues you should not waste time for explaining why your core router is 200ms away from the previous hop. ___ 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] Network-control queue counter increases on ccc-configured interface
On Friday, January 27, 2012 01:32:16 AM Keegan Holley wrote: This is good for some, but it's hard to recommend a queuing policy to someone without understanding what they do with their network. I've made due in the past with only 4 queues, especially when juniper pic's only had 4. I've always thought 4 queues (including 'nc') were more than enough. Anything more than 4 is just a variation of the main 3 (be, ef, af), and only serves to create more complicated products that your sales folk can sell and make a little bit more money (sales guys don't care how complicated the network becomes, as long as they close the sale and guarantee their commissions - those 3AM calls in the morning are for you, not them). But is it really worth the effort? Maybe, maybe not, especially since trying to provide any kind of scheduling for Internet access is just a waste of time. If you take that aside, really, how much more do you need to carve out for VPN-type services? 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] Internet routes in MPLS network, global table or own VRF?
On Friday, January 27, 2012 02:30:35 AM Keegan Holley wrote: I agree... I think. MPLS has a better forwarding paradigm and the IGP only core of P routers is a plus. Well, I'm not so sure MPLS has a better forwarding paradigm per se. If you're talking about raw forwarding performance, hardware forwarding these days makes that a non-issue, but you already knew that :-). We like running it for Internet traffic because we can remove BGP (for v4) from the core. That's all. On the application side, we like running it because we can offer those cool services like IPTv, l2vpn and them. Why not FRR everything? The control plane hit is negligable even if your internet users wouldn't notice, care about, or even understand the improvements. We have a large-ish network, particularly in the Access (lots of Metro-E switches that are IP/MPLS-aware). Trying to run RSVP everywhere isn't feasible, when your customers are demanding lower and lower prices. Given the amount of effort required for this, we relegate RSVP-TE to: o Multicast for IPTv services (we'll be using mLDP for data-based Multicast services). We run FRR here too. o Unequal cost routing within the core, so we don't have idle links when others are full. Keeping it in the core only reduces state. o Specific requests from customers who want their traffic to take a specific path, or failover within a very short time (note I don't say 50ms). This we charge expensively to discourage customers from buying it, as it's hectic to maintain, and overall, the differences in latency across several points in the country is very, very negligible. Moreover, we've found failover times for BFD + our tuned IS-IS to be reasonable for most applications. All RSVP instances run Refresh Reduction for scaling, even if state is relatively low due to the above. 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] Network-control queue counter increases on ccc-configured interface
On Friday, January 27, 2012 03:00:44 AM Saku Ytti wrote: Yes, but if you use MPLS, you can do QoS without mangling TOS. But the problem with that, Saku, is traffic traversing from one customer to another on the same router will not be wrapped in MPLS. We remark on ingress for Internet traffic. We honour for VPN traffic (if agreed with the customer) or remark for VPN traffic (if agreed with the customer). 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] Internet routes in MPLS network, global table or own VRF?
On Friday, January 27, 2012 03:48:23 AM Pavel Lunin wrote: What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. One of the reasons we: o Don't disable TTL propagation across our MPLS network. o Avoid, as much as possible, running MPLS LPS's that differ, greatly, from IGP routing (i.e., LDP vs. RSVP) for Internet traffic. This issue is massively exacerbated if you're running FA's, which is why if we have to send traffic down RSVP LSP's, we prefer IGP Shortcuts (Autoroute Announce). 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] Network-control queue counter increases on ccc-configured interface
On (2012-01-27 11:17 +0800), Mark Tinka wrote: Yes, but if you use MPLS, you can do QoS without mangling TOS. But the problem with that, Saku, is traffic traversing from one customer to another on the same router will not be wrapped in MPLS. In JunOS you can classify packets based on incoming 802.1p without recolouring anything and then in egress match magically on the internally defined class. In IOS in devices you'd want to use today in edge, you can use 'qos-group' as temporary internal storage. So in neither case, you need to trust or mangle TOS. 7600/6500 is complex (in this matter too), however you can usually get even here what you want, due to internal DSCP. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On (2012-01-27 11:02 +0800), Mark Tinka wrote: Anything more than 4 is just a variation of the main 3 (be, ef, af), and only serves to create more complicated products that your sales folk can sell and make a little bit more money (sales guys don't care how complicated the network becomes, as long as they close the sale and guarantee their commissions - those 3AM calls in the morning are for you, not them). This is generally true, if all your customers are created equal, and in case of say Internet sourced DoS they all need to suffer equally. But if some your customers are more important than others 4 can be quite short amount. Consider you're getting DoS from INET, and it's very rarely towards your business INET users. But it will still sometimes be towards your business INET, so you cannot put VPN customes in same 'better INET' queue, as you must make sure L3 MPSL VPN continues to work for all INET sourced DoS. Now you already have three classes 1. normal inet (low margin, high dos risk customers) 2. priority inet (high margin, low dos risk customers) 3. vpn (to protect l3mpls vpn-l3mpls vpn, even when priority inet customer is dossed) Now you'd only have 1 left, which you'd probably want for NC. Then you'd need to put IPTV, VoIP and internal critical services such as PSTN in same class as VPN or NC. And you'd risk that if VPN customers network is compromised and is sourcing DoS that your priority services are down. If we exclude DoS as normal part of life or we treat all INET customers as equal 4 is easily enough. When it comes to customer QoS, 4 should be plenty. As typically single customer would only have need for 3 classes 1. normal traffic (web surfing, email, etc) 2. worse than normal (off-site backups, periodic mass transfers ec). 3. priority traffic (voip, telepresence, interactive applications) If you must congest even priority traffic, then the customer link is likely just too slow. Customer QoS need not (and probably should not) map 1:1 to core QoS. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Network-control queue counter increases on ccc-configured interface
On Friday, January 27, 2012 03:17:03 PM Saku Ytti wrote: In JunOS you can classify packets based on incoming 802.1p without recolouring anything and then in egress match magically on the internally defined class. Well, that is assuming the link toward your customer is Ethernet, 802.1Q, e.t.c., which may not be the case. In IOS in devices you'd want to use today in edge, you can use 'qos-group' as temporary internal storage. So in neither case, you need to trust or mangle TOS. Not all platforms in Cisco's arsenal support this feature. So it's not always reliable when new kit is coming out. We had to ask Cisco to re-spin certain ASIC's on new kit while they were still in the development stage (we were in their EFT program) in order to add functions such as these. 7600/6500 is complex (in this matter too), however you can usually get even here what you want, due to internal DSCP. The EARL7 (SUP720/RSP720) doesn't support 'qos-groups'. This was added in the EARL8. 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] Network-control queue counter increases on ccc-configured interface
On Friday, January 27, 2012 03:32:03 PM Saku Ytti wrote: 1. normal inet (low margin, high dos risk customers) 2. priority inet (high margin, low dos risk customers) The problem with trying to provide any kind of QoS to Internet access customers is that if you can do it, it will most probably only be possible in the egress direction, as QoS scheduling is mostly on the egress portion of router interfaces anyway. But the majority of Internet access customers are downloading from the Internet to their networks. Since you can't guarantee how Internet packets are marked as they come in, you can't really classify packets for preferred scheduling toward a specific customer this way. Yes, you could do things like DCU and QPPB, but this can get very complicated very quickly, particularly if you have very strong and dynamic peering, and you need to turn these features for only a sub-set of your customers and not all. And then when customers think you can sell premium Internet access, the can of worms that you'll have opened will be interesting. But I can't say that is either right or wrong. I won't deny, however, that DoS does introduce another puzzle into the equation. But different networks solve this in different ways depending on human resources, network size, tools, amount of money to throw at the problem, e.t.c. 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] Network-control queue counter increases on ccc-configured interface
On (2012-01-27 15:36 +0800), Mark Tinka wrote: Well, that is assuming the link toward your customer is Ethernet, 802.1Q, e.t.c., which may not be the case. Indeed. But it still does not change anything compared to customer being in same or different PE. If customer is directly attached to your PE, you must decide right there how to classify, if that is TOS or L3/L4 values or something else, in either case, you'd still remark the EXP and the internal class with same value Not all platforms in Cisco's arsenal support this feature. So it's not always reliable when new kit is coming out. We had to ask Cisco to re-spin certain ASIC's on new kit while they were still in the development stage (we were in their EFT program) in order to add functions such as these. Frankly, any edge device I'd want today from Cisco or Juniper does support 'internal storage' of QoS group. I don't view it as particularly exotic feature which limits my choices dramatically. HQoS and ingress shaping seem to be harder targets 7600/6500 is complex (in this matter too), however you can usually get even here what you want, due to internal DSCP. The EARL7 (SUP720/RSP720) doesn't support 'qos-groups'. This was added in the EARL8. Quite, as stated. However when packet ingresses 7600 you can decide how you colour internal DSCP. Then on egress you either rewrite internal DSCP to (802.1p, EXP, TOS, depending on encap) or you don't rewrite and leave them untouched. So while internal dscp isn't directly configurable like qos-group (I think technically it could be used so that you directly mark internal dscp and directly match on it in MQC, too bad not implemented like this), it can be used to a degree to accomplish same goals of not touching or using TOS. But I fully accept that in 7600/6500 you may have QoS demand which they cannot meet, they are not the most trivial platforms to run and to workaround their limitations. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
