Re: [j-nsp] MX80 BGP performance after reboot
* Stacy W. Smith st...@acm.org [2013-02-12 01:18]: Do the KRT error messages go away if you unconfigure sampling? Any change in the KRT installation time with sampling turned off? I'll test that. I assume I will need to completely disable the sampling instance? This is the only MX80 where we use inline-jflow at the moment so it could very well be the problem. I also misread the output. I didn't identify sampled as a daemon but as a message that the pfe is sampling it's client (doh!). I'm also going to open a bug for it because it would make sampling almost unusable on the box. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
Which release do you use ? Experienced some mpls mtu issue on trio platform. Known PR... Envoyé de mon iPad Le 12 févr. 2013 à 22:17, Luca Salvatore l...@ninefold.com a écrit : I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
11.2R5.4 on all MX involved - this was the recommended release up to a few days ago. Any ideas on the PR number? Luca -Original Message- From: david@orange.com [mailto:david@orange.com] Sent: Wednesday, 13 February 2013 8:24 AM To: Luca Salvatore Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MTU problems over VPLS Which release do you use ? Experienced some mpls mtu issue on trio platform. Known PR... Envoyé de mon iPad Le 12 févr. 2013 à 22:17, Luca Salvatore l...@ninefold.com a écrit : I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
We use RSVP LSPs and set the Adspec attribute to autodiscover the LSP MTU hop by hop during the path setup. We also set the MTU on the PE-CE facing interface. Finally set the VPLS mtu in the routing-instance --- It has to match on all PEs that we run the VPLS instance, we do this to interop with Alcatel. HTH, Eduardo -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Luca Salvatore Sent: Tuesday, February 12, 2013 12:58 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] MTU problems over VPLS I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ 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] MX80 BGP performance after reboot
The PR number is 836197. The PDF is also online for anyone to view it. http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning2.steenbergen.juniper-slowfib.pdf Liam Hynes On Feb 11, 2013, at 6:59 PM, Jeff Wheeler wrote: On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: I noticed that a MX80 takes quite a long time after reboot to put all routes into the KRT. Is that normal for that box? It takes around 10 minutes after BGP is established to get all the routes into the KRT Yes, the routes taking a long time to install is normal, unfortunately. I feel like it has got worse since 10.4 but that might be my imagination. I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. I am hopeful that the move away from a single Junos release strategy to some segregation among different products will allow Juniper to be more flexible in how they allocate development resources to different platforms. If I had to guess, I'd say the ddos-related log messages you are reading are related to excessive need to generate ttl_exceeded packets because of routing loops while BGP is announcing to neighboring routers but the routes are not actually installed in the FIB yet. Even if I am wrong about the specifics here, I am certain it is only a symptom of the problem which is unrelated to the ddos-protection feature. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ 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] MX80 BGP performance after reboot
Interesting... MX80 running 11.4R6.5 - takes about 5-7 minutes to come online, load BGP tables and fully converge as a reference point: inet.0: 446697 destinations, 609039 routes (446678 active, 13 holddown, 17 hidden) Direct: 21 routes, 21 active Local: 20 routes, 20 active OSPF: 2324 routes, 2306 active BGP: 606641 routes, 444309 active Static: 3 routes, 3 active IGMP: 1 routes, 1 active Aggregate: 10 routes, 4 active RSVP: 19 routes, 14 active inet.3: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) RSVP: 14 routes, 14 active mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) MPLS: 3 routes, 3 active RSVP: 8 routes, 8 active L2VPN: 4 routes, 4 active VPLS: 4 routes, 4 active inet6.0: 79743 destinations, 83769 routes (79741 active, 1 holddown, 5 hidden) Direct: 18 routes, 11 active Local: 16 routes, 16 active OSPF3: 82 routes, 82 active BGP: 83653 routes, 79632 active bgp.l2vpn.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) BGP: 4 routes, 4 active I don't recall ever seeing any errors though as you describe... Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian Wiesinger Sent: February-11-13 6:50 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX80 BGP performance after reboot * Paul Stewart p...@paulstewart.org [2013-02-12 00:36]: What version of JunOS? Just one full table or many? 11.4R6-S1 Combined Full-Table from a few iBGP peers and around 70k routes from an IXP. Approx. 700k Routes in RIB. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] Are these temps high enough to cause any issues?
Here's from an MX-10 in a 68F ambient room with pretty good airflow through the chassis. This node also has a 2x10Gbps in the box generating some additional heat. root@lab-MX# ...cs optics | match temperature | except high | except low Module temperature: 29 degrees C / 85 degrees F Module temperature: 27 degrees C / 81 degrees F On Feb 11, 2013, at 5:31 PM, Morgan McLean wrx...@gmail.com wrote: Here is the output of a few commands (bolded). In the past two weeks, one SFP from each of our border MX80's have failed. They were juniper 1gig sx modules. I'm not sure if this is coincidence, or if its heat related. According to the thresholds, things seem to be OK, but I figured I should ask. For instance, the warn threshold for the modules are like 180deg F, not sure what it is for the chassis or individual chips. * * *someuser@somehost.somewhere* *show interfaces diagnostics optics |match temperature |except high|except low * Module temperature: 50 degrees C / 122 degrees F Module temperature: 50 degrees C / 122 degrees F Module temperature: 48 degrees C / 119 degrees F Module temperature: 47 degrees C / 117 degrees F Module temperature: 49 degrees C / 120 degrees F Module temperature: 51 degrees C / 124 degrees F *someuser@somehost.somewhere show chassis environment * Class Item Status Measurement Temp PEM 0 OK PEM 1 OK RE 0 IntakeOK 48 degrees C / 118 degrees F RE 0 Front Exhaust OK 51 degrees C / 123 degrees F RE 0 Rear Exhaust OK 48 degrees C / 118 degrees F Routing Engine OK 55 degrees C / 131 degrees F Routing Engine CPU OK 66 degrees C / 150 degrees F TFEB 0 QX 0 TSen OK 51 degrees C / 123 degrees F TFEB 0 QX 0 Chip OK 61 degrees C / 141 degrees F TFEB 0 LU 0 TSen OK 51 degrees C / 123 degrees F TFEB 0 LU 0 Chip OK 66 degrees C / 150 degrees F TFEB 0 MQ 0 TSen OK 51 degrees C / 123 degrees F TFEB 0 MQ 0 Chip OK 58 degrees C / 136 degrees F TFEB 0 TBB PFE TSenOK 48 degrees C / 118 degrees F TFEB 0 TBB PFE ChipOK 59 degrees C / 138 degrees F TFEB 0 TFEB PCIE TSen OK 53 degrees C / 127 degrees F TFEB 0 TFEB PCIE Chip OK 69 degrees C / 156 degrees F Fans Fan 1 OK Spinning at high speed Fan 2 OK Spinning at high speed Fan 3 OK Spinning at high speed Fan 4 OK Spinning at high speed Fan 5 OK Spinning at high speed -- Thanks, Morgan ___ 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] MLPPP CHAP Issues
Hi Guys,
I've got a requirement to run LFI (Link Fragmention Interleaving) on an ADSL
Interface on an SRX - this requires the use of MLPPP even though there is only
a single interface.
The customer has a Cisco 877 doing exactly this and it works fine.
With my configuration as it stands, if I switch to just using atm-ppp-vc-mux
and move the address-negotiation back to the at-1/0/0 interface, the SRX
connects just fine, which validates that the CHAP authentication details are
correct.
When I switch over to atm-mlppp-llc however, CHAP starts failing with
Config-NACK messages, which include the MRRU option (currently 1504).
bdale# show interfaces lsq-0/0/0
unit 0 {
encapsulation multilink-ppp;
fragment-threshold 640;
minimum-links 1;
family inet {
negotiate-address;
}
}
[edit]
bdale# show interfaces at-1/0/0
description ADSL Interface to ISP;
per-unit-scheduler;
encapsulation atm-pvc;
atm-options {
vpi 8;
}
dsl-options {
operating-mode itu-dmt;
}
unit 0 {
encapsulation atm-mlppp-llc;
bandwidth 512;
vci 8.35;
ppp-options {
chap {
default-chap-secret $9$4coDk5T39tOFn; ## SECRET-DATA
local-name test@isp;
}
}
no-keepalives;
family mlppp {
bundle lsq-0/0/0.0;
}
}
Meanwhile, my traceoptions for PPP look like this over and over again (might be
slightly out of order as I was testing with CHAP passive and active):
Feb 14 01:05:08 at-1/0/0.0: Received 38 byte PPP packet: 0xc0 0x21 0x01
Feb 14 01:05:08 at-1/0/0.0: In LCP, Config-Request, id 7, len 11
Feb 14 01:05:08 Magic Num: 2938319195
Feb 14 01:05:08 at-1/0/0.0: Out LCP, Config-Nak, id 7, len 4
Feb 14 01:05:08 MRRU: 1504
Feb 14 01:05:08 at-1/0/0.0: Sent 12 byte (4 data bytes) PPP packet: 0x21 0xc0
0x07 0x03
So a couple of questions:
My understanding of Config-NAK is that any options that are included in the NAK
message are ones either missing or incompatible with the sending device (so in
this case, the SRX is not receiving, or not receiving the correct MRRU value) -
is this a fair summary?
Does anyone have a working MLPPP configuration on ADSL that includes PAP or
CHAP authentication? None of the limited Juniper documentation includes any
authentication - I just want to sanity check what I have deployed.
Does anybody have MLPPP working in the lab on the their BRAS (MX/ERX) and could
sling me some traceoptions/debug output? I'd be keen to see what CHAP Options
are passed/required normally to bring up a link and it MRRU is required under
normal operation (this might be an SRX oddity).
If I was to guess what is wrong here, it looks like the SRX offers an MRRU
value to negotiate during CHAP, and when the upstream BRAS doesn't return a
value, it NAKs the CHAP config.
Any pointers appreciated.
Cheers,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On Mon, 11 Feb 2013, Jeff Wheeler wrote: I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. It looks like I've beaten him to reply. It's PR836197. http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning2.steenbergen.juniper-slowfib.pdf -- Brandon Ross Yahoo AIM: BrandonNRoss +1-404-635-6667ICQ: 2269442 Schedule a meeting: https://doodle.com/brossSkype: brandonross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
I was there for that lightning talk (and very recently seen that feature actually happening) but what's getting described here by the OP doesn't seem to be the same maybe I'm misunderstanding. Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler Sent: February-11-13 6:59 PM To: Juniper NSP Subject: Re: [j-nsp] MX80 BGP performance after reboot On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: I noticed that a MX80 takes quite a long time after reboot to put all routes into the KRT. Is that normal for that box? It takes around 10 minutes after BGP is established to get all the routes into the KRT Yes, the routes taking a long time to install is normal, unfortunately. I feel like it has got worse since 10.4 but that might be my imagination. I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. I am hopeful that the move away from a single Junos release strategy to some segregation among different products will allow Juniper to be more flexible in how they allocate development resources to different platforms. If I had to guess, I'd say the ddos-related log messages you are reading are related to excessive need to generate ttl_exceeded packets because of routing loops while BGP is announcing to neighboring routers but the routes are not actually installed in the FIB yet. Even if I am wrong about the specifics here, I am certain it is only a symptom of the problem which is unrelated to the ddos-protection feature. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ 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] CWDM optics support on EX4500
On Wed, Feb 13, 2013 at 7:26 AM, JP Velders j...@veldersjes.net wrote: Date: Mon, 11 Feb 2013 16:19:16 -0600 From: Chris Wopat m...@falz.net Subject: [j-nsp] CWDM optics support on EX4500 I tried some 3rd party Cisco coded optics and oddly they're detected as SFP+. Dumb question: did you set the port to 1g speed ? Yep. I got a few replies off-list about this and others have had no issues. It definitely appears to be due to these being Cisco and not Juniper coded. --Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Is Juniper moving features to AFL on EX Series in 12.3?
Sort of unrelated, but a quick question in regards to AFL's. I'm looking to run BGP on a EX4500/4200 mixed mode VC (2 x 4500's, 2 x 4200's for 4 switches total) with the EX4500's as the RE and backup RE (preprovisioned). Do I only need to purchase the AFL's for the EX4500's or all members of the VC? Any other caveats I should be aware of? On Fri, Feb 8, 2013 at 2:46 PM, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Ahh sorry, didn't see it. Excellent to know. Someone was trying to scare us ;-) ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net We are the bridge between business and technology Juniper - Cisco - Cloud On Fri, Feb 8, 2013 at 1:21 PM, Caillin Bathern caill...@commtelns.com wrote: Hi Skeeve, This has already been discussed in the Junos 12.3 Release Date thread and a Juniper employee has stated that this is a documentation error that will fixed. Cheers, Caillin -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Skeeve Stevens Sent: Friday, 8 February 2013 1:05 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Is Juniper moving features to AFL on EX Series in 12.3? All, Something has just been pointed out to me, and I'd like to get the communities take on it. It seems that Juniper has moved features to the Advanced Features License in 12.3. *This is the link for the EX License Overview on 12.2* http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/ex-series -software-licenses-overview.html#jd0e146 Features Requiring a License on EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Switches To use the following features on Juniper Networks EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Ethernet Switches, you must install an advanced feature license (AFL): - Border Gateway Protocol (BGP) and multiprotocol BGP (MBGP) - Intermediate System-to-Intermediate System (IS-IS) - IPv6 protocols: OSPFv3, RIPng, IS-IS for IPv6, IPv6 BGP - MPLS with RSVP-based label-switched paths (LSPs) and MPLS-based circuit cross-connects (CCCs) --- *This is the link for the EX License Overview on 12.3* http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/ex-series -software-licenses-overview.html#jd0e146 Features Requiring a License on EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Switches To use the following features on Juniper Networks EX3200, EX4200, EX4500, EX4550, EX6200, and EX8200 Ethernet Switches, you must install an advanced feature license (AFL): - Border Gateway Protocol (BGP) and multiprotocol BGP (MBGP) - Generic Routing Encapsulation (GRE) - Intermediate System-to-Intermediate System (IS-IS) - Multicast Listener Discovery version 1 and 2 (MLDv1 and MLDv2) - MPLS with RSVP-based label-switched paths (LSPs) and MPLS-based circuit cross-connects (CCCs) - Multicast Source Discovery Protocol (MSDP) - RIPng (RIP next generation) - OSPFv1/v2 (with four active interfaces) - OSPFv3 - S-VLAN - Unicast reverse-path forwarding (RPF) - Virtual routing and forwarding (VRF) - Virtual Router Redundancy Protocol (VRRP) Doesn't this increase the cost of these switches by a ton of money if you want features you used to get for free? I would have thought that IPv6 would have been something that would have started to be in the base license since everyone is starting to need it as standard. This sounds a little opportunistic in my opinion. This looks like these layer 3 switches are becoming more and more like Layer 2 dumb switches the higher the Junos version goes. Maybe 13.x will have IPv4 in AFL? ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/networkceoau ; blog: www.network-ceo.net We are the bridge between business and technology Juniper - Cisco - Cloud ___ juniper-nsp mailing list juniper-nsp@puck.nether.net 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 juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
On Tuesday, February 12, 2013, Luca Salvatore wrote: I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). hi can you put configuration ? you cam tune up mtu for vpls rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX3600 port buffers
Hi, I looking some info about buffers size in this model ? Are they configureable ? thanks for info regards Piotr ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
How does one send back an ICMP please-fragment-this Message when you're emulating a blue wire? No router in the middle to send back to the customer. it's an L2 service. You're transparent to them IP-wise. No IP interface anywhere inside their bridge to source a packet from. - Ck. On 2013-02-12, at 5:57 PM, Luca Salvatore l...@ninefold.com wrote: I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ 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] CWDM optics support on EX4500
Date: Mon, 11 Feb 2013 16:19:16 -0600 From: Chris Wopat m...@falz.net Subject: [j-nsp] CWDM optics support on EX4500 I tried some 3rd party Cisco coded optics and oddly they're detected as SFP+. Dumb question: did you set the port to 1g speed ? Kind regards, JP Velders ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
We hit this PR but should be fixed in your release. Double check with JTAC if there is no regression or corner case? David Problem Report Number PR568550 Title With default settings,4 bytes lesser ip payload can be sent when MX-80 is acting as P router compared to M7i Release Note MPLS MTU was reserving 3 labels length apart from the MPLS labels that come in the packet. So due to this the packets were getting dropped in P router when ping packet size was 1456B for physical MTU of 1514B(excludes CRC). SeverityMajor Status Closed Last Modified 2012-09-11 23:47:31 PDT Resolved In 10.4R5 11.1R3 11.2R1 11.3R1 Operating SystemJunos Product MX-series Functional Area software Feature Group Platform and Infrastructure Workaround Set higher MTU i.e.(X+12Bytes) in order to allow X bytes. Triggers* Trio platform * sending packet more than 1455B Envoyé de mon iPad Le 12 févr. 2013 à 22:25, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com a écrit : 11.2R5.4 on all MX involved - this was the recommended release up to a few days ago. Any ideas on the PR number? Luca -Original Message- From: david@orange.commailto:david@orange.com [mailto:david@orange.com] Sent: Wednesday, 13 February 2013 8:24 AM To: Luca Salvatore Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MTU problems over VPLS Which release do you use ? Experienced some mpls mtu issue on trio platform. Known PR... Envoyé de mon iPad Le 12 févr. 2013 à 22:17, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com a écrit : I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___
Re: [j-nsp] Is Juniper moving features to AFL on EX Series in 12.3?
Nice domain. http://www.juniper.net/techpubs/en_US/junos/topics/concept/ex-series-software-licenses-overview.html For a Virtual Chassis deployment, two license keys are recommended for redundancy-one for the device in the master role and the other for the device in the backup role You do not need additional license keys for Virtual Chassis member switches that are in the linecard role -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Andrew Jones Sent: Tuesday, February 12, 2013 5:26 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Is Juniper moving features to AFL on EX Series in 12.3? Sort of unrelated, but a quick question in regards to AFL's. I'm looking to run BGP on a EX4500/4200 mixed mode VC (2 x 4500's, 2 x 4200's for 4 switches total) with the EX4500's as the RE and backup RE (preprovisioned). Do I only need to purchase the AFL's for the EX4500's or all members of the VC? Any other caveats I should be aware of? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] FPC sending flows with wrong time?
My security guys informed me they are getting flows with weird times from our SRX3600 that I'm having export flows to one of their security boxes. Time seems to be correct on the routing engine, we use NTP etc and I can't remember if its possible to log into an FPC directly. The FPC that the flows are coming from is of course the SPC. Any good places to start? Off, like september of 2012 for a flow from yesterday. -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 12.3 Release Date
On Thu, Feb 7, 2013 at 12:03 PM, Rajesh Narang nar...@juniper.net wrote: It is a documentation error that is being corrected and link will be updated soon. Updated: http://www.juniper.net/techpubs/en_US/junos12.3/topics/concept/ex-series-software-licenses-overview.html Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
Luca Salvatore l...@ninefold.com writes: I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? VPLS presents a layer 2 link. There is no way for a L2 link to send ICMP messages. Fix your VPLS core to present a 1500 byte (or preferably much higher) MTU or tell the servers what the actual MTU is. /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
Thanks for the info. I have managed to fix it by tweaking the MTU on my 10Gb interfaces between P routers. I set the interface MTU to be 1548 Then set the family mpls MTU to be 1522 This seems to have helped. Luca From: david@orange.com [mailto:david@orange.com] Sent: Wednesday, 13 February 2013 8:33 AM To: Luca Salvatore Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MTU problems over VPLS We hit this PR but should be fixed in your release. Double check with JTAC if there is no regression or corner case? David Problem Report Number PR568550 Title With default settings,4 bytes lesser ip payload can be sent when MX-80 is acting as P router compared to M7i Release Note MPLS MTU was reserving 3 labels length apart from the MPLS labels that come in the packet. So due to this the packets were getting dropped in P router when ping packet size was 1456B for physical MTU of 1514B(excludes CRC). Severity Major Status Closed Last Modified 2012-09-11 23:47:31 PDT Resolved In 10.4R5 11.1R3 11.2R1 11.3R1 Operating System Junos Product MX-series Functional Area software Feature Group Platform and Infrastructure Workaround Set higher MTU i.e.(X+12Bytes) in order to allow X bytes. Triggers * Trio platform * sending packet more than 1455B Envoyé de mon iPad Le 12 févr. 2013 à 22:25, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com a écrit : 11.2R5.4 on all MX involved - this was the recommended release up to a few days ago. Any ideas on the PR number? Luca -Original Message- From: david@orange.commailto:david@orange.com [mailto:david@orange.com] Sent: Wednesday, 13 February 2013 8:24 AM To: Luca Salvatore Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MTU problems over VPLS Which release do you use ? Experienced some mpls mtu issue on trio platform. Known PR... Envoyé de mon iPad Le 12 févr. 2013 à 22:17, Luca Salvatore l...@ninefold.commailto:l...@ninefold.com a écrit : I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged
Re: [j-nsp] MTU problems over VPLS
Hi Luca, I believe this is expected behaviour. Your VPLS infrastructure only supports max MTU of 14xx (1500- MPLS/VPLS/TE etc overhead). If your Layer 3 CPE device connected to the VPLS cloud sets default MTU of 1500 then it will try to send those 1500 byte packets, without knowing that they will get dropped by the first node in the VPLS cloud. Since this first VPLS device is not one of your layer 3 devices along your IP path, it can not send back an ICMP Fragmentation Needed message back to the source. It does not even care to do it either. Therefore MTU path discovery protocol breaks!!! You can get MTU path discovery works by setting MTU on interfaces on any layer 3 CPEs facing VPLS to the actual MTU that the transport link between them can support ( in your case 1500- overheads for the interfaces facing VPLS cloud). Alternatively, increase the MTU on physical interfaces in your VPLS infrastructure to catter for overheads you introduce. Hope it helps. To Others, pls correct if my understanding is wrong. Cheers, Huan On 13/02/2013, at 8:24 AM, david@orange.com wrote: Which release do you use ? Experienced some mpls mtu issue on trio platform. Known PR... Envoyé de mon iPad Le 12 févr. 2013 à 22:17, Luca Salvatore l...@ninefold.com a écrit : I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ___ 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] QFX3600 port buffers
On Tue, Feb 12, 2013 at 2:39 PM, Piotr piotr.1...@interia.pl wrote: I looking some info about buffers size in this model ? Are they configureable ? It is the same chip as the QFX3500 and has similar 10MB buffer for the whole chip, which is similar to other products in this segment. It is configurable. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CWDM optics support on EX4500
* Chris Wopat I got a few replies off-list about this and others have had no issues. It definitely appears to be due to these being Cisco and not Juniper coded. Yep, I've sometimes had weird issues with that were due to coding. For example, a while back I got some Juniper-coded DAC cables for use between a EX4500 and Cisco Nexus 5K. No problems in the Cisco end, but they showed up as GE interface in on the EX. The fix was to get them reprogrammed as Cisco cables, ironically enough. -- Tore Anderson ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
Couldn't RPD just reduce the TCP window size for BGP sessions to reduce the rate at which it can receive routes from neighbouring routers? This would mean that your FIB would always be synched to your RIB and other routers would not blackhole by sending traffic to the router in question (who's FIB is lagging behind its RIB), no? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, 12 February 2013 12:43 PM To: 'Juniper NSP' Subject: Re: [j-nsp] MX80 BGP performance after reboot I was there for that lightning talk (and very recently seen that feature actually happening) but what's getting described here by the OP doesn't seem to be the same maybe I'm misunderstanding. Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler Sent: February-11-13 6:59 PM To: Juniper NSP Subject: Re: [j-nsp] MX80 BGP performance after reboot On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: I noticed that a MX80 takes quite a long time after reboot to put all routes into the KRT. Is that normal for that box? It takes around 10 minutes after BGP is established to get all the routes into the KRT Yes, the routes taking a long time to install is normal, unfortunately. I feel like it has got worse since 10.4 but that might be my imagination. I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. I am hopeful that the move away from a single Junos release strategy to some segregation among different products will allow Juniper to be more flexible in how they allocate development resources to different platforms. If I had to guess, I'd say the ddos-related log messages you are reading are related to excessive need to generate ttl_exceeded packets because of routing loops while BGP is announcing to neighboring routers but the routes are not actually installed in the FIB yet. Even if I am wrong about the specifics here, I am certain it is only a symptom of the problem which is unrelated to the ddos-protection feature. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On 2/13/13 10:42 PM, Caillin Bathern wrote: Couldn't RPD just reduce the TCP window size for BGP sessions to reduce the rate at which it can receive routes from neighbouring routers? This would mean that your FIB would always be synched to your RIB and other routers would not blackhole by sending traffic to the router in question (who's FIB is lagging behind its RIB), no? as an aside, When we're doing a maintence we generally let the router converge with our route-reflectors prior to bringing up the transit/peer neighbors. so that routes learned from the transits are replacing existing fib routes. that also has a salubrious interaction with our loose rpf check. spontaneous reboots aren't quite adjustable like that. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, 12 February 2013 12:43 PM To: 'Juniper NSP' Subject: Re: [j-nsp] MX80 BGP performance after reboot I was there for that lightning talk (and very recently seen that feature actually happening) but what's getting described here by the OP doesn't seem to be the same maybe I'm misunderstanding. Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wheeler Sent: February-11-13 6:59 PM To: Juniper NSP Subject: Re: [j-nsp] MX80 BGP performance after reboot On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: I noticed that a MX80 takes quite a long time after reboot to put all routes into the KRT. Is that normal for that box? It takes around 10 minutes after BGP is established to get all the routes into the KRT Yes, the routes taking a long time to install is normal, unfortunately. I feel like it has got worse since 10.4 but that might be my imagination. I am sorry I missed Richard Steenbergen's lightning talk at NANOG, which was something like if you want your routers to install routes, call Juniper and reference PR#whatever because they do not want to fix this bug. I am hopeful that the move away from a single Junos release strategy to some segregation among different products will allow Juniper to be more flexible in how they allocate development resources to different platforms. If I had to guess, I'd say the ddos-related log messages you are reading are related to excessive need to generate ttl_exceeded packets because of routing loops while BGP is announcing to neighboring routers but the routes are not actually installed in the FIB yet. Even if I am wrong about the specifics here, I am certain it is only a symptom of the problem which is unrelated to the ddos-protection feature. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts ___ 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 -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ 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
