Re: [j-nsp] Juniper publishes Release notes as pdf
I think the main story here is: Offer both/different versions! Once the content is there it should be very little effort to render multiple different outputs. In the days of ancient past you could just convert each section/page of the website (including Release Notes) into a PDF (documentation still has that at most locations) or get a properly authored PDF version which has use-cases e.g.: - searching it - offline availability (i have been in "offline" situations where help apropos did not cut it, bonus points during an outage) (Back than we even could download a full documentation PDF bundle/"CD" in one place which again is cool to have offline or to fullfill the "we want to have all documentation handed to us" tender knob :)) I am also not a big fan that the HTML based Release Notes have been changed month/years ago to have clickable section per subchapter (e.g. per feature family per platform) where it once was one bigger document. Want to scroll trough everything new on e.g. 22.1R1 for MX? https://www.juniper.net/documentation/us/en/software/junos/release-notes/22.1/junos-release-notes-22.1r1/topics/new-features/mx-new-features-22.1r1.html Nope, clicking dozens of times it is Want the same for 20.4? https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/20.4/topic-150554.html#jd0e7524 Just scroll (or ctrl+f) if i want a PDF i can click the button in the top right (as long as it is still there). regards Tobias Am 18.03.2024 um 16:59 schrieb Michael Hare via juniper-nsp: TLDR: Juniper: please keep the PDFs. I like control-F. I may need a lesson in remedial use of browsers, but I find the PDFs useful and I don't print them. Do people really have the time to navigate/click on all of these hyperlinks, or am I missing an obvious way to control-F the entire release notes in the web? Example: https://www.juniper.net/documentation/us/en/software/junos/release-notes/22.4/junos-release-notes-22.4r1/index.html -Michael -Original Message- From: juniper-nsp On Behalf Of Andrey Kostin via juniper-nsp Sent: Monday, March 18, 2024 7:37 AM To: Joe Horton Cc: Juniper Nsp Subject: Re: [j-nsp] Juniper publishes Release notes as pdf Thanks, Joe. Right, pdf only for SR releases has been a while, but not very long, the change happened just few months ago. My personal preference would be to read html that can adapt to screen size, etc. Imo the value of pdf is to be able to print a paper copy, but it's hard to imagine that somebody would print release notes in the present time. Kind regards, Andrey Joe Horton via juniper-nsp писал(а) 2024-03-15 21:36: Correct. SR releases – PDF only, and I think it has been that way a while. R release – html/web based + PDF And understand, I’ll pass along the feedback to the docs team. Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://urldefense.com/v3/__https://puck.nether.net/mailman/listinfo/junip er- nsp__;!!Mak6IKo!KwspzhVpA4H07DE07WwOX7O2Mcz02FfnRg1MEuPyGll8k uhy28xOFgROPz-6ojKOiKfVJ4bNsRh3o85dwy4jnaE8Nzc$ ___ 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] Juniper QFX5200-32c and QSFP28 channelized optics
Hi,
While it sometimes works to let 25G transceivers run at 10G (depending
on Transceiver and Device(s)) i think in this case you will need a
different transceiver.
See e.g. HCT for reference:
https://apps.juniper.net/hct/product/?prd=QFX5200-32C
the PSM only lists 25 and 100 as being supported:
https://apps.juniper.net/hct/model/?component=JNP-QSFP-100G-PSM4
For 10G SM Breakout something like
https://apps.juniper.net/hct/model/?component=JNP-QSFP-4X10GE-LR would
be the way to go.
regards
Tobias
Am 29.12.2023 um 02:38 schrieb Lee Starnes via juniper-nsp:
Hello everyone,
I am running into an issue on our QFX5200 switches where I have installed a
QSFP-100G-PSM4 optic. This can do 1G/10G/25G on the 4 channels. My issue is
that I am not able to get the interfaces to go to 10G even though I have
set them as such.
If setting all 4 channels to 10G only a single interface shows at 100G. If
I set them all to 25G, all 4 show as 25G. Then if I change one of the
channels to 10G, all 4 remain as 25G.
Is this an issue with how I am setting this up or an issue with the type of
Optic being used? Below is the config for the ports in the last state I
tested.
chassis {
fpc 0 {
pic 0 {
port 0 {
channel-speed 10g;
}
port 1 {
channel-speed 25g;
}
port 2 {
channel-speed 25g;
}
port 3 {
channel-speed 25g;
}
Thanks for any info or documents you can point me to.
Best,
-Lee
___
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] MX304 - Edge Router
Am 25.10.2023 um 14:25 schrieb Aaron1: Years ago I had to get a license to make my 10g interfaces work on my MX104 If we are going into the HW direction and not features. Yes, that is correct MX104 had some Port based licensing. There was also MX5 -> MX10 -> MX40 -> MX80 And some not so enforced things like "only MS-MIC in Slot X" etc. :) regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX304 - Edge Router
Am 25.10.2023 um 11:57 schrieb Xavier Beaudouin via juniper-nsp: So there are a couple of enforced licenses even on MX ... and they have always been enforced. Subscriber MGMT is one of these features. Well I remember wanted to use dhcp server on a MX204 for a local lan used only... for local administrators... that required some license I didn't have Well this thing was working like a charm on M7i (yeah this is attic I know), and it never asked me a license for spawning isc-dhcpd ... So no this is no more "honor based". They copy the worse part of Cisco with their license mess... It does not help, but this actually makes sense in a weird way :) local dhcp server on MX is considered a feature which sources in the Subscriber mgmt part of the code and hence depends on the subscriber mgmt features i mentioned above. And these were always enforced on MX. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX304 - Edge Router
Am 25.10.2023 um 08:01 schrieb Saku Ytti via juniper-nsp: On Tue, 24 Oct 2023 at 22:21, Aaron Gould via juniper-nsp wrote: My MX304 trial license expired last night, after rebooting the MX304, various protocols no longer work. This seems more than just honor-based... ospf, ldp, etc, no longer function. This is new to me; that Juniper is making protocols and technologies tied to license. I need to understand more about this, as I'm considering buying MX304's. Juniper had assured me multiple times that they strategically have decided to NEVER do this. That it's an actual decision they've considered at the highest level, that they will not downgrade devices in operation. I guess 'reboot' is not in-operation? I am surprised and it goes against everything i have seen and experienced so far on any MX (including MX304). So there are a couple of enforced licenses even on MX ... and they have always been enforced. Subscriber MGMT is one of these features. Also some form of encryption is typically enforced due to export regulations and other silly things. Also the rare use cases where external feeds (e.g. for stateful services on services cards) might expire. That being said, i have not yet seen any expired flex license on any MX as we typically play with perpetuals. But not having a license has never killed features like Routing Protocols, LDP or similar for me. We run the boxes in the lab without licenses regularly (because we are too lazy to (re)apply them between tests and/or wipes) including MX304 and Junos up to 23.2. I would be very surprised if there are actually code path that kill features in Junos on purpose yet (having seen the quality of the other parts of the license parser). So i would rather suspect some weird combination of misbehaviour and/or bug and not an intention to disable stuff for now. The flex license nagging comes in different stages and intensity depending e.g. in HW and sometimes card Generation, which makes license mgmt a lot of "fun" in chassis with cards that "need" a license and cards that "can have" a license and cards than "do not need" a license at all :) The SE teams (or your partner of choice) have access to the current plans of where license nagging and license installation is needed to stop the nagging and where it is optional. I will try to get my hands on a short live trial license to replicate that behaviour soonish to look into that now :) After all ... there is not much that surprise me any more on vendor licensing ... regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CVE-2023-4481
Hi, On 11.09.2023 19:55, Tom Beecher wrote: Which in theory opens a new attack vector for the future. What is the attack vector you foresee for a route sitting as hidden with the potentially offending attributes stripped off? It is theoretical, but if you do $something with a prefix and maybe even the "malformed" attribute and do not throw the prefix away completely $something in parsing and keeping the prefix further down the line could stumble over $whatever else makes the prefix special. This implies "problems"/bugs in the code parsing the prefix and its attributes, which can be assumed to not exist, but doing $something is more likely to hit a problem than not doing $something. By keeping the prefix and doing $something with it you do more than before and might hit a code path that was not hit before when the session was reseted or when the prefixes are just discarded. In an ideal world where all code and parsing is perfect all is fine. Do i think this is likely or a real world problem we will hit soon? Probably not. Do i think that it is a theoretic vector to hit problems not yet seen in the wild at some point? Yes I do. So, like with all features and knobs, you might want to consider whether it brings you any benefit to keep the prefixes in hidden state or "minimize" processing of things you will maybe never look at. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CVE-2023-4481
Hi,
Am 30.08.2023 um 18:09 schrieb heasley via juniper-nsp:
Tue, Aug 29, 2023 at 03:42:41PM -0700, David Sinn via juniper-nsp:
A network I operate is going with:
bgp-error-tolerance {
malformed-route-limit 0;
}
The thoughts being that there is no real reason to retain the malformed route
and the default of 1000 is arbitrary. We haven't really seen a rash of them, so
adjusting the logging hasn't proven needed yet.
It does seem arbitrary. retaining all seems like a better choice,
operationally. allowing the operator diagnose why a route is missing;
show route hidden.
Which in theory opens a new attack vector for the future.
As the update is malformed it could do $something to the handling in
e.g. RPD or other daemons by processing them somehow wrong. By not
holding or further process any of them that could (maybe, hopefully?) be
minimized.
Of course proper code and handling of malformed things would be even
better, but you know ...
regards
Tobias
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Converting QFX3600 from QF Interconnect to standalone mode
Hi, Its been age since we needed to convert one of them. AFAIR all 3600 Nodes can be converted. The bigger Interconnect Node had no option for that. They state a couple of warnings and pre requisites in the documentation: https://www.juniper.net/documentation/us/en/software/junos/qfx3000-g-deployment/topics/task/device-mode-converting.html e.g. "Always convert the device mode to standalone before you remove the component from the QFabric system. If you remove the component from the QFabric system before converting the device mode to standalone, the switch might not operate properly. For example, the output of the show chassis hardware command might display no FPCs or interfaces for the switch." Have you tried a complete usb reinstall already? I kind of remember we had to completely start from scratch for at least one of the boxes. regards Tobias Am 07.02.2023 um 00:16 schrieb Vincentz Petzholtz via juniper-nsp: Hi Daniel, Have you checked IF the device model in question is capable of running in "standalone" mode? As far as I remember there were models which did not support it (especially the ones used for IC in a jnp qfabric). Best regards, Vincentz -- Am 04.02.2023 um 23:21 schrieb Daniel Roesen via juniper-nsp : Hi, just trying to convert a couple of QFX3600 QFabric interconnet nodes to standalone mode via "request chassis device-mode standalone". They state "after next boot: standalone", but come up again in QF-IC mode, still stating "after next boot: standalone". JUNOS 13.1X50-D15.1 The conversion worked sorta fine with the QFX3500s, but all QFX3600 do fail... Anybody got a clue how to beat them into submission? Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] polishing an antique m7i
Hi, If you have any active support contract or a contact to an SE person they typically can provide access to old and no longer listed releases on demand as they do archive them internally. We recently had to request some 14.X code for a complicated VC upgrade procedure involving a failed member. Unfortunately the public download section seems to get automatically purged every now and than and releases older than X are removed. Especially for EOL platforms. regards Tobias Am 07.07.2022 um 21:45 schrieb Randy Bush via juniper-nsp: - old m7i with RE-B-1800X1-4G-S - currently running 14.2R7.5 - hard disk dying - have nice new 1tb sata ssd for it - juniper support download is pushing 15.1R7.9 at me - should i worry about increased memory use or license changes in 15? - if so, where the heck is 14? If 14 is missing from the repository, then it's probably because it is EoL. so is the m7i :) I can't find 14 for even the MX, so chances are Juniper stopped maintaining it a while ago. I recall debuting 14 into our network back in 2014, and it had tons of problems. I'd be surprised if Juniper are still actively supporting it. i am not expecting active support of 14 or the m7i. i am expecting an archive of historical releases just as application softwares have. For the M7i, chances are your memory footprint will bulge with 15 exactly my fear. it was running 14 successfully as the disk drive failed. i want to run 14 when the new drive is installed (in the next day or two). this seems a reasonable desire. - and with the support portal rearrangement, i can not find destructions for making a bootable usb stick from install-media-15.1R7.dms (on a mac or an rPi, of course:) `dd in=Desktop/ISOs/install-media-15.1R7.dms of=/dev/disk6 bs=1m` resulted in ryuu.rg.net:/Users/randy> sudo fdisk /dev/disk6 Password: Disk: /dev/disk6geometry: 979/255/63 [15728640 sectors] Signature: 0xAA55 Starting Ending #: id cyl hd sec - cyl hd sec [ start - size] 1: 04 880 0 1 - 879 0 1 [ 1893232 - 20480] DOS FAT-16 *2: A5 680 0 1 - 879 0 1 [ 680 -1892552] FreeBSD 3: 000 0 0 -0 0 0 [ 0 - 0] unused 4: 000 0 0 -0 0 0 [ 0 - 0] unused which is somewhat reassuring, though the start/size of #1 is a bit odd randy ___ 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] FlowSpec rules being installed, but not matching any traffic
Hi, I doubt that BGP Flow Spec is systested or supported on any QFX5k platform. Feature Explorer (while not perfect :)) does support me in that thinking: https://apps.juniper.net/feature-explorer/parent-feature-info.html?pFKey=1541=BGP+Flow+Specification regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] what's the difference between vMX and vMX evaluation?
Hi, On 22.10.2021 08:42, Chen Jiang via juniper-nsp wrote: I see there are 2 download links for vMX, one is vMX, one is vMX evaluation. What's the difference between the two? On Paper the Eval is for public Evals (https://www.juniper.net/us/en/dm/vmx-trial-download.html) and the regular Downloads are for the paid version. Image wise they are the same (down to the md5sum). The eval is quite old (18.2) by now and the default eval license you get will only work on the "old" image types (up until 19.1) as they changed the license format. I would anticipate a newer eval version (and license) soon as 18.2 is End of Engineering since June and will be end of Support in December. In the meantime your SE or maybe your VAR should also be able to provide newer images and working trial licenses if needed. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] upgrading an antique 240
Hi, On 15.07.2021 22:46, Randy Bush via juniper-nsp wrote: Good point! TSB16735 says last version of Junos to support SCB-MX960 is 16.2 Junos 17.3R3-S10 Junos 18.4R2-S5 Junos 19.3R3-S2 Junos 19.4R3-S3 so which steps to get from 14 to 16.2? 15.x 16.2? https://support.juniper.net/support/eol/software/junos/ Although the last supported Release is 16.2, you might want to run 16.1$latest. It feels like 16.2 was intended to be supported longer, but "16.1R7: EOE extended to 28-Jul-2020 and EOS extended to 28-Jan-2021." So the "newest" Release is most likely 16.1 as the End of Engineering was later and therefore more fixes/changes went into that than into 16.2. End of Services was extended for 16.2 as well: "16.2: EOS extended to 01-May-2021 for T4000, TX-3D, MX240/480/960, PTX3000 and PTX5000." But end of engineering was not. And as we are past both end of services now, it might make more sense to stick with the release that got more engineering. Most of our customers still holding onto RE2000 are on 16.1 Some managed to upgrade successfully even beyond that, but its not supported and might create interesting problems. Similar to when RE1300 was not intended to go past 14.2 but would still run on 15.X an newer often :) regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 Maximum Packet Rates
Hi, MX204 has some limitations in terms of pps rates for smaller packet sizes if inline-flow is configured compared to e.g. MX10003 not only but also related to the pfe/fabric layout (no fabric in 204). So even if they are the same pfe they might behave differently. The details are not public, so you might want to reach out to your partner/SE. regards Tobias On 20.05.2021 12:39, Peter Sievers wrote: Hi Leon, both MX204 und MX10003/LC2103 use eagle forwarding ASIC, LC2103 Linecard has 3xASIC, MX204 has 1xASIC, WAN Output Rate for eagle pfe is for 100G Interface ~110 MPPS. Assumption is, that you got the traffic on the MX10003 over more than one PFE/ASIC incoming. BR, .peter On 20.05.21 11:49, Leon Kramer wrote: Hello, during an approximate 240 Mpps / 80 Gbps UDP DDOS attack to one target IP we have experienced a massive and immediate packet loss at an MX204 router. The attack was coming in through MX10003 and MX204. The MX204 was not able to forward more than 120 Mpps during the attack. The MX10003 forwarded 180 Mpps without any issue. Both routers are running Juniper 18.4R2-S3. The MX204 has all 4 x 100 Gbps interfaces active in use. Any idea if 120 Mpps for Juniper MX204 is already the hardware limitation? This would equal to only roughly 41 Gbps of the attacks packet size of 43 bytes. We are certain that no policer or firewall filter lead to the packet drops. Anyone has a recommendation what could be done to increase performance? Kind Regards Leon Kramer ___ 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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 and QSFP+ breakouts
Hi, On 30.04.2021 23:21, Ross Halliday wrote: Do FS QSFP+ breakout DACs and AOCs work on this platform? Is there some magic sauce firmware I'm too daft to find? We had some troubles in 40G and 100G DACs on MX204 and MX10003. e.g. 40G DAC worked in $old versions and suddenly stopped in $newer versions. It seems it stopped working when 100G DAC support was officially introduced/supported. https://apps.juniper.net/hct/product/?prd=MX204 Officially they do not support 40G DAC (regardless of type), but 4x10G SR or LR Breakouts are supported and do work in our LAB. Sometimes it can make a difference whether or not the third party optics are coded to the correct SKUs. So it may help to play around with different codings, i think FS also offers a Box to change the programming? Juniper has specific SKUs where they support the 4x10G Breakout (e.g. QSFPP-4X10GE-LR and SFPP-4X10GE-SR), but so far Breakout also worked fine on other parallel optical transceiver we tried. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QSA modules and DDM/DOM readings
Hi, Am 05.03.2021 um 15:49 schrieb Karl Gerhard: I tried QSAs from two different vendors but to no avail. I wonder if anyone has succeded in getting DDM/DOM readings on a QSA adapter. Is it the QFX5100-48T's fault or is it the QSA+SFP Modules that are at fault? QFX5100 is not listed to officially support the QSA: https://apps.juniper.net/hct/model/?component=MAM1Q00A-QSA=sPlatforms Even on QFX5110 it was added as late as 19.4 While the QSA probably did work even before (never tried it in the QFXes) its likely that Code for DOM readings and such might not be in there on that platforms or in your release. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX204 port 1G
Hi,
Am 09.10.2020 um 13:12 schrieb Łukasz Trąbiński:
In Lab I'm trying to set up 1G port on MX204.
You might need to play around with autoneg options. we have a working 1G LX SFP
running on 18.4R1-S7 on MX204
in our case thats the gigether section:
gigether-options {
no-flow-control;
no-auto-negotiation;
speed 1g;
}
Not sure if the Flow Control stuff was mandatory, but without the
no-auto-negotation the link was not useable. It might also help to check
autoneg settings on the other end (if you have access).
--
Kind Regards
Tobias Heister
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to pick JUNOS Version
Hi, On 19.08.2020 16:42, Colton Conor wrote: How do you plan which JUNOS version to deploy on your network? Do you stick to the KB21476 - JTAC Recommended Junos Software Versions or go a different route? Some of the JTAC recommended code seems to be very dated, but that is probably by design for stability. https://kb.juniper.net/InfoCenter/index?page=content=KB21476=METADATA just for the record (some of you will already know) ... there is no longer a recommended release. The Article was renamed: "Suggested Releases to Consider and Evaluate" For any real recommendation you would have to buy a service which analyzes you configs and cross checks PRs. But in reality nothing much has changed, even before the rename the recommendation was not very strong anyway, just a general guideline. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ipfix is not accounting next-ip firewall actions properly
Hi, On 24.06.2020 12:28, Marcel Bößendörfer wrote: *Issue: *However, IPFIX is not considering the next-ip, instead it's acting like the next-ip would not exist at all. That means, traffic from 192.168.0.2 is reported to be egressing multiple interfaces like the router would handle it without the next-ip rule. So it seems that the sampling is taking place before the firewall rule is applied. This is a very unexpected behaviour. In reality traffic from that source IP is only egressing the interface that's related to 192.168.1.1. I have seen things like this with Flow Export on MX before. In my case it was filter based forwarding towards a different RI with different interfaces for TE purposes. In that case the flow export would match the "Original" destination before the FBF took place which lead to wrong flow statistics on $collector. This was years ago and i never checked back on that, seems like the behavior is still there. I kind of remember it happening for flow-spec drop/rate-loimit routes/filters as well. So Flow would still report the traffic ingressing the interfaces while the filters were already blocking them. Which in the Case of flow-Spec was a good thing, because you could keep the announcement active as long as the attack lasted. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 upgrade path 18.4R
Hi, On 14.06.2020 10:50, Robert Hass wrote: I have old MX80 running 10.4R14.2. I would like to upgrade it to 18.4R. But what upgrade I should use ? 10.4R -> 15.1R and to 18.4R ? There are probably official upgrade pathes taking a dozen intermediate steps (three LTS releases at a time or something like that is officially supported, and starting from $some version in the 16/17 all releases are considered LTS). As The MX80 takes ages to do just one upgrade this would take days. Also it could be quite hard to actually get intermediate releases for the older steps (JTAC typically has them on request) I would suggest to backup the config do a usb reinstall to the target release and reapply the config. -- regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX routers and DAC cables?
Hi, On 12.06.2020 20:39, Chris Adams wrote: Is anybody using DAC cables on MX routers? We have a customer with an MX10003 connected to EX4600 switches with 40G DAC cables (Juniper parts, not third-party). Upon upgrading the router JUNOS to 18.2R3-S3, none of the interfaces with a DAC cable would come up on the router end. JTAC's response was that no DAC cables are supported on any MX routers. That seems a little odd to me... I thought DAC cables are a part of the various specs, so saying they're not supported is saying those aren't actually Ethernet ports to me. DAC and AOC are transceivers, and officially only a specific set of transceivers are supported per platform. For MX10003 you can check here: https://apps.juniper.net/hct/product/#prd=MX10003 There are 40GE AOC supported for that box, but not 40GE DAC. For 100GE DAC are actually supported in later Junos version. That being said typically DAC worked in MX for 10G and even 40G on most noxes, but on MX10003 we had a lot of problems with 40G DACs and eventually replaced most/all of of them with optical transceivers. Even on 100GE you might need to set the FEC config depending on what and where you connect the other DAC end. While 10G mostly worked everywhere we had a fair share of trouble on 40 and 100GE on various vendors and platforms. -- regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP very slow on MX10003
Hi, On 25.05.2020 18:25, Leon Kramer wrote: If you think that SNMP is too slow, what alternative can you recommend for fetching interface counters? Probably the canonical answer these days is streaming telemetry which can be done directly from the PFE for a lot of counters. In a former life when SNMP got too slow we sometimes switches to screenscraping "show interfaces | display XML" via SSH/netconf. But this would only help if the data itself is presented fast enough. We had boxes where presenting thh data itself towards the cli/SNMP agent was the bottleneck so the method of pulling it made no difference. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Rate selectability on MPC7E-MRATE
Hi, On 06.05.2020 20:15, Vincentz Petzholtz wrote: That’s not true and you sad it yourself. You have 240G per PIC. With 2x100G ports enabled you can still set one remaining port to 40G on the same pic. And it also works just fine. Which part of my last mail is not true? Maybe i did not make myself clear enough? If you configure the PIC in per port mode/level, you can different modes per port and hence have 2x100GE and 1x40/4x10GE on the same PIC. See the first part of my last mail. https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-at-port-level If you configure the PIC in PIC speed mode/level 100GE you will only have 2x100GE and nothing else per pic, as described in the second part of my last mail https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-at-pic-level The later could make sense if you use e.g. SCBE2 and want 2+1/1+1 mode and not 3+0/2+0 to reduce the level of card to fabric/slot "oversub"as you only get up to 480G per Slot on that SCBE2 if all boards are active at the same time. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Rate selectability on MPC7E-MRATE
On 06.05.2020 18:24, Brian Johnson wrote: A wise man once told me… “Just because you can do something, doesn’t mean you should”. More specific, “Just because you can do it in the Junos config, doesn’t mean it’s supported.” Junipers licensing “honor system” required honorable intentions. ;) I would say it is supported. Even the documentation has an example where one port of the group is 100GE and two others are 10GE: https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-at-port-level Also with MPC7 its not like its honor based to only use 240G per PFE ... its a hard limit ;) If you run in PIC Mode with 100GE set, than in deed the other ports are disabled: "For example, if you choose to configure PIC 0 at 100-Gbps speed, only ports 2 and 5 of PIC 0 operate at 100-Gbps speed, while the other ports of the PIC are disabled." https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html#id-configuring-rate-selectability-on-mpc7e-multi-rate-to-enable-different-port-speeds I mean what else should it do, there are only two 100GE Ports per PFE anyway ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Rate selectability on MPC7E-MRATE
Hi,
On 06.05.2020 18:03, Chris Wopat wrote:
On Wed, May 6, 2020 at 9:41 AM Brian Johnson wrote:
So you have a 4x10G breakout and a 100G QSFP28 in the same group of 3
interfaces and they are all working? Just because I can install and configure
the optics, doesn’t mean they will function. This would conflict with what is
coming from Juniper Product teams.
To be clear, I realize that the ports do not “disappear” because you insert the
QSP28 into the port group, just that they will not work. :)
We've been this with MPC7s, works fine. You can squeeze the 240g out
of each PIC just fine, you simply cannot oversub.
fpc 7 {
pic 0 {
port 2 {
speed 100g;
}
port 4 {
speed 10g;
}
port 5 {
speed 100g;
}
}
}
ports 4 and 5 in same 'group of 3', et-7/05 up at 100g and
xe-7/0/4:[0-3] up at 10g.
I always wondered whether there is an explicit knob to disable a port in order
to prevent accidental wrong configs or transceivers inserts down the road. Of
course you can annotate the existing ports or the pic, but besides that. Also
what happens if somebody plugs in a transceiver into any of the remaining
ports? Will the setup just fall apart?
You have 6 Ports per PFE and if you do 100GE on two of them you will end up with
something similar to the above config (you can choose whether to do 40 or 10GE on one of
the ports). Which leaves three interfaces unconfigured or not listed in the config. In
fact whenever one port is configured to 100G you will "loose" at least one of
the ports and have to leave it not listed in config for things to work.
If at some point in the future somebody configures any of the remaining ports
for an invalid speed it will not work. Even worse default mode for MPC7E-MRATE
is to fallback to 10GE Mode on all ports on invalid config which could kill
your 100GE production ports. Luckily you have to bounce the PFE for speed
changes, which could be even worse if your wrong config hits you during your
next reboot if you do not mind the alarms ;)
"If rate selectability is not configured or if invalid port speeds are configured,
each port operates as four 10-Gigabit Ethernet interface"
"When you change an existing port speed configuration at the port level, you must
reset the MPC7E-MRATE PIC for the configuration to take effect. An alarm is generated
indicating the change in port speed configuration."
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/rate-selectability-configuring.html
So it would be great to have a config option to explicitly disable specific
ports and not just leave them unconfigured. Of course you can also misconfigure
any of the disabled ports into a unsupported speed combo, but it would be a bit
more visible that they are disabled by intention.
You probably could configure all ports and literally "deactivate" the configs
that you do not want to be enabled and annotate that, but it feels a bit clunky.
Especially on boxes like MX204 and MX10003 we would always explicitly configure
the ports into a valid config combination to prevent somebody from putting in
transceivers and the box trying to be smart and mess up your ports. I think you
cannot easily do that on the MPC7
--
Kind Regards
Tobias Heister
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Managing MX480 fxp0
Hi, On 22.11.2019 19:48, Dave Bell wrote: This is definitely not possible. You can’t jump from the data plane out of the fxp port. This is why things like jflow are only possible inband The official statement is that it is neither possible nor supported. It was even highly marketed as separation in the earlier days. But i have seen a couple of occurrences (including a network crippling looping and therefore amplification of traffic e.g. back in the M5i days) where some traffic leaked from fxp0 to data plane and/or vice versa. Even if it would work you would not want it as the CP/DP link is pretty "slow" and already tasked with lots of other things which it struggles with at times ;) -- regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Ramp up old MX480
On 28.08.2019 17:10, Brian Johnson wrote: Do you know if you have the enhanced mid-plane? If not, it’s a chassis upgrade to install MPC3 or better line cards. There is no need to upgrade the chassis even with old midplane. The worst you get is performance impact on MPC4/5E on SCBE2 or MPC10E on SCBE2/3. All MPCs will work on old midplane (some with reduced capacity) MPC7E and the already proposed 16 Port 10GE MPC (technically a quad MPC2 trio cramped into one card) work fine on the old mid-plane. You will loose support for some linecards when upgrading fabrics (e.g. no DPC from SCBE2 onward, and no MPC1/2E(non NG) from SCBE3 onward) If you only need some 10GE Ports you could just use the 16 Port 10GE Cards with the existing SCB and deactivate/use 8 of the ports. The cards are probably cheap enough on the second hand market to justify it. If you can get used SCBEs you can go up to 12 Ports (1+1 fabrics) or 16 Ports (2+0 fabrics) if memory serves well. For new cards cheapest per port price typically comes from MPC7E ... but overall costs depend on target number of 10GEs. Cooling/Filter and Power supplies will need upgrading as already mentioned from others. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] rib-groups && VPN reflection
Hi, On 18.04.2019 10:13, Adam Chappell wrote: But the abstraction seems to be incomplete. The method of copying routes to bgp.l3vpn.0 is similar if not identical, under-the-hood, to the initial rib-group operation I am performing at route source to leak the original inet.0 route and this route, as seen in the VRF.inet.0 table, becomes a Secondary route. As such, it apparently isn't candidate for further cloning/copying into bgp.l3vpn.0, and as a consequence the "leaked" route doesn't actually make it into the VPN tables of other PEs. Yes, L3VPN under the hood is more or less rib-groups in disguise. There is actually a command i forgot which shows you the internal rib-groups it uses to do the L3VPN magic. My question to others is, is this a well-known man-trap that I am naively unaware of? Is it simply the case that best practice to get reflection off of production VRF-hosting PEs is actually mandatory here, or are others surprised by this apparent feature clash? Can I reasonably expect it to be addressed further down the software road? Or is there another, perhaps better, way of achieving my objective? This behavior is probably deeply rooted in the architecture, so i would not expect it to change. I faced the same issue when building a DDoS Mitigation ON/OFF Ramp setup. My workaround was to bring up an lt-interface and run a routing protocol between VRF and inet.0 announcing all the routes you need. As i did not want to the actual traffic to forward over that lt interfaces (and stealing BW from the PFE) i created a policy to change the next-hop to a specific dummy next-hop IP. That dummy-next-hop IP used next-table XYZ and pointed directly into the table i wanted. Once the routes are learned and resolved the Forwarding table points directly into the other VRF/Table and i could not see any problems in terms of performance or similiar with this. The setup is running in production for a couple of years now. It is a bit ugly and violates the "4am Rule" where any on Call Engineer woken at 4am should immediately understand what is going on, but well it is what it is ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] fusion QFX5120 and MX204
Hi, Am 12.04.2019 um 22:10 schrieb Aaron Gould: Trying to do fusion from MX204 (AD) to QFX5120-48Y-8C (SD). but getting this message.. "Satellite image not available" Is a QFX5120-48Y-8C capable of being a satellite device in fusion ? Not yet. https://www.juniper.net/documentation/en_US/junos/topics/concept/fusion-components.html Fusion PE supports EX4300, QFX5100/5110 and QFX5200 Interesting side Note on QFX5200 being supported as Satellite and my favorite Fun Fact on Fusion PE. MX80 is supported as AD and QFX5200 is supported as SAT. This allows us to build the most useless router in the world with 248x100GE Interfaces (31x100GE on 8 QFX5200) + 24x10GE Interfaces (1x100GE broken into 3x10GE + 1x10GE for AD Connectivity) with a oversubscription factor of at least 2483:1 per SAT and MX80 control plane. The worst of all worlds! Similar Math applies to MX104 as AD. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Fusion using vMX and vQFX
Hi, On 12.04.2019 15:34, Aaron Gould wrote: Can I do Fusion using vMX and vQFX ? Will it work? Leaving aside the use case and what you would actually want/could to do with it this will not work. vQFX is basically QFX10k and QFX10k can not be used as Sat in any Fusion deployment (it can be AD in DC flavor). So even if Fusion would be supported and/or work on vMX (which i doubt) there would be no virtual SAT to connect. Also of course you would need a License for the AD in Fusion PE (which uses MX as AD) in order to use it. Even MX150 (which is vMX on NFX Appliance) is not supported as AD for fusion. -- regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4600 or QFX5110
Hi, Am 18.03.2019 um 19:57 schrieb Gert Doering: On Mon, Mar 18, 2019 at 06:50:26PM +, Giuliano C. Medalha wrote: EVPN-VXLAN in general is supported using PFL license (QFX) ... that is not too much expensive AFL license will support MPLS (L2circuit) and EVPN MPLS features in some platforms ... but is costs more. https://forums.juniper.net/t5/Enterprise-Cloud-and/Welcome-QFX5120-48Y/ba-p/329900 This is for QFX. The original question was "what license is needed on EX4600 to get EVPN with VXLAN"? You will need the AFL. There is no EFL or PFL for EX4600. https://www.juniper.net/documentation/en_US/junos/topics/topic-map/understanding_software_licenses.html#jd0e690 -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] inline-jflow monitoring
Hi, On 02.01.2019 13:18, sth...@nethelp.no wrote: From 16.1R1 and up you should also configure the ip flow table sizes as the default is 1024 entries for v4 if I'm not mistaken. Not sure if this is your current issue but is something to consider as well. Also check flex-flow-sizing as an option. Note that changing the flow table sizes has traditionally resulted in a reboot of the line card. https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/ipv4-flow-table-size.html "NOTE: Prior to Junos OS Release 16.1R1 and 15.1F2, any changes in the configured size of the flow table initiates an automatic reboot of the FPC, and we recommend that you run this command in a maintenance window." Whatever this means for now ;) I kind of remember that we changed that without reboot on 16.x and 17.x code on some routers. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] inline-jflow monitoring
Hi, On 02.01.2019 11:49, Saku Ytti wrote: Trio does IPFIX in HW, it can inspect each and every packet with no different cost. So if your flow table can survive it, do 1:1 and get more visibility. AFAIK not all Trio Generations and variants are able to do 1:1 at Line Rate. IIRC MPC5E and newer are very close to 1:1 in all scenarios while older MPC/TRIO were lower (in the 1:4 - 1:10 range worst case) I think it was one of the marketed benefits of MPC5 and MPC2/3-NG that they now can do 1:1 while the older stuff was not able to do so. Of course you can argue whether line rate 64k packets are actually a typical use case or not ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LSP's with IPV6 on Juniper
Hi, Am 27.08.2018 um 18:57 schrieb Olivier Benghozi: An yes, the MPLS control-plane uses only IPv4: (the intercos between routers are in IPv4, LDP uses IPv4, IGP uses IPv4, and IPv6 is really announced over specific AFI/SAFI (labeled unicast IPv6 for 6PE, VPNv6 for 6VPE) in IPv4 MP-iBGP sessions ; but it doesn't matter. There is LDPv6 on Juniper since a couple of releases (i believe 16.x) https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/configuring-ldp-native-ipv6-support.html So in theory you could run IPv6 only control Plane (IGP, LDP, BGP) with MPLS Data Plane. As there is no 4PE you either need to do v4 in MPLS VPN/VRF or run v4 and v6 Control plane in parallel to get v4 across. There is no v6 RSVP yet, but you might get your TE needs from SR/Spring. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper vs Arista
On 14.08.2018 08:34, Mark Tinka wrote: On 14/Aug/18 08:26, Gert Doering wrote: Mailman claims "there isn't yet", but if Jared would add one, I'd subscribe :-) https://puck.nether.net/mailman/listinfo/ As would I... +1 -- regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode
Hi, On 26.07.2018 09:06, Victor Sudakov wrote: I don't like to explain what others say but I think yes. It's been known behavior since always: in a two-member VC always disable split-detection. You can google for other threads on this in this list. It's always been kind of poorly documented. Last time I checked the docs, instead of just writing clearly that it must be disabled in two-members mode, they "don't recommend" it with some kind of hand-waving explanation that if you estimate that the backup RE failure probability is higher that a split-brain condition blah-blah-blah... Just disable split-detection, that's it :) Tomorrow we are planning a lab with and without split-detection. I hope this solves the issue for us, and if it does, I'm sure to make a note in my engineering journal. Yes, no-split-detection did help. I would like to add to that. My point of view is that you do not always disable split-detection in a two member VC. You can do so if you know what that implies. The reasoning for the remaining node going into LC mode is that only the portions of the VC having the majority of nodes stays up and operational. In a two member VC if for whatever reason one of the nodes looses connection to the other, we cannot have a majority so both sides go down. Even if it is the only node remaining. But imagine an error scenario where the second node does not crash, but for whatever reason both sides stay up, but the connection between them gets lost. With split-detection configured, both sides will go down and you have a controlled service outage. When no split-detection is configured both sides remain up and you might have interesting effects happening in your network with two switches with the same configuration and same "identity" being up and forwarding. I have seen that happening in DC scenarios doing stp to other devices and it is not pretty! So always check the implications of what the command are doing. If in your case an active/active split scenario (for worst case) works out better than a completely offline VC, that is perfectly fine. I have seen lots of scenarios where it would not be the expected or wanted behavior. But in my world a VC is no real redundancy method it is just stacking-NG for additional ports under one MGMT so i would have two VCs if i relay need redundancy in most setups. But that is just me ;) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Enhanced MX480 Midplane?
Hi, Am 16.11.2017 um 10:36 schrieb Sebastian Becker: this is the information out of the "Juniper Tech Club" in Cologne in June 2016. So not only provided to us. If needed I can verify that with Juniper. Feel free to do that. My informationen and recent verification from Juniper confirm my assumption (hence no speed difference between midplanes for MPC7 and only 480G in 3+0) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Enhanced MX480 Midplane?
Hi, Am 15.11.2017 um 09:13 schrieb Sebastian Becker: that’s not right. You need to differ between redundancy and non-redundancy-mode: With Fabric Redundancy in MX960 (SCBEs: 2 active, 1 spare): Premium2 Chassis (non-enhanced midplane): MPC5E205G MPC7E400G Premium3 Chassis (enhanced midplane): MPC5E240G MPC7E480G In the non-redundant mode (so all three SCBEs are online and active) you will not suffer from any limitation as long as all three are online. But if one dies you will have the limitations in a Premium2 chassis. So it depends on the model you want to use. We need a full redundant switching fabric so we have to calculate with these limitations. At least according to my information there is no difference in enhanced/non enhanced for MPC7 on SCBE2 in any MX. There is no way to get full 480G with 2+1 with SCBE2. You can get 480 in 3+0 mode. (both on MX960) The first SCB* with 2+1 and Linerate for MPC7 will be SCBE3. But hey, your version would make more sense but all my documents and information since the release of MPC7 say otherwise. On the other hand there are not many customers in DE who would/should know better :) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Enhanced MX480 Midplane?
Hi, Am 14.11.2017 um 13:27 schrieb Sebastian Becker: The enhanced midplane allows you already to use higher bandwidth with redundancy at least on the MX960. 205G per slot (not > enhanced) against 240G per slot (enhanced) So if you want to use a MPC5E-100G10G and populate every port (2x100G plus 4x10G) > you need the enhanced midplane and the SCBE2. Same for the MPC5E-40G10G and the Q-Versions of these cards. Otherwise you > overbook the midplane. Funny enough the MPC7 has no reduced Bandwidth with the non enhanced Midplane, so for now only MPC4/5 suffer from that old midplane. I always wondered why that is the case. Might be a combination of PFE/Trio Generation and frequency/speed per Serdes to Fabric connectivity. If somebody knows the details i am eager to know. We will see what SCBE3 might bring there (other than allowing us to run MPC7 at full speed with redundancy and pave the way for future MPC) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LACP on mixed virtual chassis QFX5100/EX4300
Hi, Am 03.11.2015 um 23:23 schrieb ThienDuc Nguyen: I was trying to create a LACP bundle between two ports : one on a EX4300, the other on a QFX5100. Both link have their speed negotiated at 1GE (but the interface name on the QFX is xe-, I can't force it to ge-, and their are no way to force the speed on the QFX). if I set the lacp speed to 1ge, the configuration can't commit because it sees the QFX interface as a 10G interface... Is their a special knob to activate it, or I need to create LACP on the same device family ? (the version is 14.1X53-D30.3) From what you wrote i would suspect that you use a QFX5100 copper version? If they behave anything like the EX45XX Copper Versions the interfaces will always be xe- regardless of them being only used with 1GE neighbors. Would be funny if the interface name would change when lower speeds are negotiated. Probably the config parser checks the physical interfaces and finds out that it is a 10G interface on QFX and 1G Interface on EX and will not commit as mixed speed AEs are only supported in later MX code. I do not know a way around that and do not have copper QFX at hand to check. Probably you will have hit one of these corner case situations that nobody thought about and nobody ever encountered and nobody ever asked about (at least if you ask jtac :)) -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] pfed downward spike received from pfe
Hi, Am 22.03.2015 um 10:36 schrieb Simon Frerichs: we see the following error on MX80 running BGP and IS-IS twice a day. Traffic forwarding seems to be uninterrupted. pfed: downward spike received from pfe for ibytes_reply:3684981055620 ibytes_record:3684981121451 for ifl:344 loc_id:00010002 https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR833091 These downward spike messages are informational and do not indicate that an error exists in the router. The message originates from the router's PFED (packet forwarding engine daemon) and indicates that information is being downloaded from a particular interface. Trigger: This problem will be seen if following condition is met: * This PFED message is reported when interface statistics received from the PFE are smaller than the previously fetched value from PFE (stored in the stats database). Just another Junos log message you could put into your syslog message filter which probably already is a mile long. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
Hi, Am 16.01.2015 um 20:49 schrieb Tom Eichhorn: I have found an answer why my rib-groups and everything is not working: All fiddling with RIB-groups is for PE-CE, and not for PE-PE. As the primary route is in bgp.l3vpn.0, I cannot leak from vrf.inet.0, which is the secondary table for the route. (If somebody asks why I can't do the leaking on the CE-PE router - there is non. The other side of the VPN is a contrail controller, which only speaks inet-vpn.). I also discussed with this my SE, and they didn't had a quick answer but have to discuss internally, but I hope that our community here maybe also has an idea howto leak routes received via inet-vpn to inet.0... From my research there is no way to leak routes that were learned via inet-vpn to inet.0 besides running routing protocols between instances. I did a dirty hack the other day where i needed to move routes from inet.0 to vrf.inet.0 and leaking was no option (do not ask) It is the other way around from your setup but the concept should be similar. I configured a static route (e.g. something from the documentation prefix or other bogus prefix) with next-table statement (in your case in inet.0 with next-table vrf.inet.0), setup BGP via lt- between the instances and used an import policy to change the next-hop to point to the prefix of the static route configured earlier. The BGP needs to be multihop or to have the accept-remote-nexthop knob configured because the next-hop is remote. You will need to be able to match the routes you want to leak/export via policy to do so. This way forwarding is done directly to/from inet.0 (without) using the lt- interface and all the bandwidth constraints it suffers. Also 1G tunneling is basically always free (on MX) even with DPCs so you will not loose any interfaces when activating tunnels. Maybe you can derive something from that for your setup. This will not work if there is already a static route with next table from vrf.inet.0 to inet.0 because the config parser will deny it for possible loops. But maybe you can use rib-groups or other leaking methods for that direction. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 SCB firmware issue
Hi, Am 23.12.2014 um 23:23 schrieb Dave Peters - Terabit Systems: 1 alarm currently active Alarm time Class Description 2014-12-23 21:50:13 UTC Major CB 0 FPGA Revision unsupported In looking over the Juniper documentation, there's a request system firmware command to update the SCB, but unfortunately, I'm not seeing that option (meaning request system ? doesn't reveal firmware as a possibility). I'm also not seeing any specific BIOS/firmware files in the download section of the Juniper MX Series portion of the Juniper website. It is a hidden command, so you have to manually complete it. After the firmware it starts to auto complete: request system firmware ? Possible completions: downgrade upgrade request system firmware upgrade ? Possible completions: fpc Upgrade FPC ROM monitor pic Upgrade PIC firmware vcpu Upgrade VCPU ROM monitor The output above is from an MX240 with SCB. I have never seen that error showing up but from what i have seen on similar situations the firmware should be embedded in junos and the firmware upgrade should just work without additional files. But SCB seems not to be a valid upgrade target on MX: request system firmware upgrade scb error: command is not valid on the mx480 tested on MX480 with SCBE Would you by any chance have bought SCBE2 (they would probably not been available in used condition) instead of SCB. Just asking because SCBE2 is supported starting from 13.something and does not work in 12.3 -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPC3E oversubscribe rate with two 10x10GE MICs
Hi, Am 01.12.2014 um 00:22 schrieb Robert Hass: I'm currently using MPC3E with one 10x10GE MICs in my MX480 and MX960 routers. I need to add 10GE ports, if I will put second 10x10GE MIC in existing MPC3E what will be oversubscribe rate ? I'm not sure but docs says about 200Gbps for MPC3E then It should be wire-speed if docs claims full-duplex or 1:2 if docs claims half-duplex. Afaik the MPC3E has one 130G Trio so two 10x10GE will be oversubribed 200:130 What is best solution (from price point of view) to have 16 x 10GE in 1 slot on MX480/MX960 ? MPC3E + 10x10GE MICs or something different ? The 16x10GE is line rate (with SCBE and higher) there is also the 32x10 MPC4E wich is oversubriced 320:260 on SCBE or line rate on SCBE2. So depending on your SCB and the need for linerate you have several choices. Then just do the math and calculate your per 10G oversub/line rate port price. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3 to the rack and L2 services over MPLS
Hi, Am 27.11.2014 um 08:59 schrieb Sebastian Wiesinger: Is there any switch in the portfolio that would give you the ability to do L3 to the rack and still have multipoint L2 services implemented over it? VPLS or even better EVPN as L2 MPLS service would be required. My perfect setup would be: L3 to the rack switch with BGP and MPLS on top. Then over that implement your standard MPLS services for L2. EVPN should come to the QFX5100 at some point. So maybe check with your SE about a time frame and maybe beta builds. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX IPv6 VRRP
Hi, Am 12.08.2014 um 23:36 schrieb ashish verma: /64 is not bad if it solves your problem and I guess most of the people use /64 as minimum. It might be really bad using /64 everywhere, for example have a look at http://inconcepts.biz/~jsw/IPv6_NDP_Exhaustion.pdf When talking about a security platform where everything is firewalled in the first place hopefully it will not come to any NDP actions at all (because the firewall killed all the inbound traffic before that), /64s might be a viable solution. But at least IPv6 VRRP (which also uses RAs, at least on Juniper) can work with prefixes /64 and will happily send RAs with smaller prefixes, so in theory you should be able to spread your default GW via RAs even with smaller prefixes. You will use the SLAAC capabilities, but depending on the deployment scenario it might be OK. That being said, i have no idea whether one can configure RAs on Juniper gear (besides from VRRPv6) which uses/announces smaller prefixes than /64. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX5 and MIC 2x10G
Hi, Am 06.08.2014 um 09:48 schrieb Robert Hass: Is 2x10G MIC supported in MX5 chassis ? I just need to have router with 2x10G interfaces, and best choice will be MX5-T + MIC2x10G for me. The MX5 supports every MIC (exception the MS-MIC which is only supported in the back slot) in its first slot. So yes you can use a 2x10G MIC in the MX5. There is a table of what is supported on which MX5-MX80 License Level in the Data Sheet http://www.juniper.net/us/en/local/pdf/datasheets/1000374-en.pdf I always think it is amusing that the on Board Ports get enabled after the MIC slots are enabled, but thats the way their business goes. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] move routes from VRF to inet.0
Hi,
I am trying to wrap my head around a (seemingly) simple l3VPN Setup with
internet access. I am labing this up right now and got stuck.
The setup is very simple:
CE1 -- PE1 -- PE2 -- CE2
We have a l3VPN between CE1 und CE2, routes are exchanged and all routes from
CE1 are seen by CE2 and vice versa. In this example CE-PE protocol is OSPF, but
it could be any protocol i guess. We do have a sham-link setup between the PEs,
so we do not need to redistribute the routes from BGP to OSPF on the PEs. Up to
here eveything works fine.
We now want to give the customer/VRF access to the internet at PE1. PE1 has a
full table in inet.0 so we configure a static default route on CE1 pointing to
table inet.0
static {
route 0.0.0.0/0 next-table inet.0;
}
On CE1 we redistribute that default route to ospf so that CE2 knows how to
reach the internet
CE2 can see the default route and will route all traffic to CE1
Now we need to let the Internet know how to reach the IPs of CE1 and CE2.
Lets assume they use public addresses and we do not need to use nat.
We can use rib-groups to move the interfaces routes for CE1 to inet.0 we can
also use a rib-group under protocols ospf in the routing instance on PE1 to get
the ospf routes into inet.0
## routing instance ##
routing-options {
interface-routes {
rib-group inet C1-internet;
}
}
protocols {
ospf {
rib-group C1-internet;
export C1-export-default;
}
}
## rib-group
C1-internet {
import-rib [ C1.inet.0 inet.0 ];
}
Afterwards we do have all the routes known via OSPF and all the direct routes
visible in inet.0
But what about the routes from CE2? They are only know as BGP routes imported
via the vrf-target configuration.
Is there any way to move these BGP routes to the inet.0 table in PE1?
I have tried a couple of things e.g. auto-export but it seems only to work on
the OSPF and direct routes, and i already have them covered with the rib-groups
from above. Simply putting an route with next-table VRF into inet.0 will not
work because we already have a route pointing back to inet.0 in this table and
the junos parser will not let that happen.
error: [rib inet.0 routing-options static]
next-table may loop
I also tried to find help in the documentation, but it seems that this scenario
is not covered. I also found a couple of older threads around the internet, but
none of them really has a solution.
There might be a couple of alternate solutions coming to mind:
1. move all internet Routes to the CE1 table and use static routes to point
back at the VRF with next-table from inet.0 which will not really scale beyond
a single l3vpn.
2. use a separate VRF for the internet routes and use auto-export, rib-groups,
vrf-import/export policy to move routes around. This would need a rework of our
network and is not really feasible right now.
Do i miss something, like an easy knob? Or am i asking the wrong questions?
--
Kind Regards
Tobias
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] m10 re-333 latest version of junos
Hi, Am 10.09.2013 21:49, schrieb N. Max Pierson: I have a couple of old m10s with re-333s in them and I would like to upgrade them to whatever the last version of Junos code they can run. These are lab routers and not production. Can someone point me in the right direction? I've seen a few folks say 10.4 will work, but I only see the m120, m160, m320 etc on the downloads page. I assume the m120 image would work in this case? We are currently running 10.4 (R9 i should upgrade them) on our lab M5s with RE2.0 or RE3.0. You can use the M-series, MX high end series T-series Install Package which is a universal image for all the m-series devices. In theory newer releases (11 or even 12) should work as well, but i have not tried it myself. It might be they removed support for EOL Hardware somewhere down the line. Depending on the release you come from you might need/want to use the M-series, MX high end series T-series Install Media if you do not want to perform a nearly endless upgrade chain. You might need additional compact flash to install the newer releases. We used off the shelf cf cards which just worked. If you can find some old memory it can be quite handy because the newer releases use lots of memory. This Router is currently idle with basically factory default configuration lab@LR2 show chassis routing-engine Routing Engine status: Temperature 36 degrees C / 96 degrees F CPU temperature 36 degrees C / 96 degrees F DRAM 384 MB Memory utilization 77 percent CPU utilization: User 0 percent Background 0 percent Kernel 1 percent Interrupt 0 percent Idle 98 percent Model RE-2.0 -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 and 3rd Party SFP-1GE-LX
Hi, Am 06.06.2013 14:30, schrieb Saku Ytti: On (2013-06-06 18:40 +0800), Joe Wooller wrote: This is basically what is happening (i think) the PFE becomes unusable until you reboot. Is there a way to see what ports are on what PFE? I'm not familiar with EX4550, I would expect it's single PFE. EX4550 seems to have single PFE as indicated by a show virtual-chassis protocol database which only lists one LSP. An EX4200 on the other hand has 3 PFEs which is reflected by the virtual-chassis protocol database listing 3 LSPs and is also mentioned in a couple of documents (e.g. the Reynolds switching book) regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Am I carrying this route or not ?
Hi All, Am 24.03.2013 00:26, schrieb Jeff Wheeler: Whoever that person is that said something about use next-hop-self in this context, either you misunderstood them, or you shouldn't listen to them anymore. That has nothing to do with looking to see if your router knows about a route. This sounds like the OP wants to help the cloudfare guys who send the following mail to DECIX/AMSIX (and probably other IX) yesterday. We're currently seeing a very large attack directed to our IP on AMS-IX (X). We request that all peers: 1) Don't carry this route (X/22) in your backbone. (you can set next-hop-self, etc). It'll save other security concerns and possible free transit you're giving away to others. 2) Filter any traffic within to the AMS-IX exchange fabric (again, X/22), except for your point to [multi]point BGP communications. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP ifIndex 0 on MX after ISSU
Hi, Am 08.03.2013 16:33, schrieb Jonas Frey (Probe Networks): did anyone ever notice problems with wrong/changed SNMP ifIndex settings after ISSU? We ISSU upgraded a MX from 10.4R9.2 to 11.4R7.5 and after this some of the ifIndex changed. We had that a couple of time with the MX series (with and without ISSU), the last time it happened from 9.6RX to 10.4RX on a couple of systems. We will soon go from 10.4RX to 11.4RX so i am expecting it to happen again. How do i get the ifIndex right? The workaround for EX doesnt help as there is no such process to restart on MX series. I am not aware of a way to fix that. We usually have to fix it in our NMS, which is really annoying every time it happens. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX Switch Question
Hi, Am 10.01.2013 14:03, schrieb Paul Stewart: Per port ingress and egress bandwidth control (rate limiting with burst) Per VLAN ingress and egress bandwidth control (rate limiting on a per VLAN basis with burst) As you mentioned this could be the problem or showstopper. We have not yet found an EX platform (tried 2200/3200/4200/4500/8200) which supported policing on egress (using Firewall filters and policing, never tried using QoS) Just tested it on en EX8216 running 10.4R9 Referenced filter 'test123' can not be used as policer not supported on egress I do not know if this is a hardware or software problem and if it may be solved in later releases (if software problem). The latest code we run is 11.4R1 on EX2200/3200/4200/4500 and there it is not possible. I kind of remember it being a hardware problem but i am not sure. We would have a couple use cases for this feature too so we would be interested in any findings. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange ARP issue on M7i
Hi Am 14.08.2012 15:12, schrieb Markus: Isn't that weird? Where did that arp entry come from and why was it saved on the Juniper for so long, and only got removed after I removed the static routing of that /24? We saw a similar thing a short time ago on an MX480 running 10.4R9 In our case it was a bgp route pointing to a no longer existing ip address as the next-hop. The arp entry for this ip address stayed active as long as there was an active route for it. Even clearing the arp cache witch clear arp hostname x.x.x.x did not do the trick. The next-hop ip was gone for several weeks and the arp entry had low timeout values left but never expired. After clearing the route the arp entry vanished as expected. I guess something keeps the arp entry from being deleted as long as there are or were forwarding entries in the fib for it at any time. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange ARP issue on M7i
Hi, Am 14.08.2012 22:09, schrieb Jonathan Lassoff: A dynamic routing protocol and BFD would be see this right away and move traffic, but this would break any static routes that rely on any dynamism with ARP and next-hops. Moral of the story, as I see it: avoid static routing. At least in our case it was a bgp route with a third-party next-hop (server) living on a connected LAN segment. So we could not be saved by BFD in this case, but i admit its a special setup. But it is funny that this behavior is present across platforms (M7i to MX with DPC) and junos versions (from 8.0 to 10.4) but this of course may have been coincidence. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE and BGP signaled lsps
-group {
inet interfaces;
inet6 v6-interfaces;
}
}
rib-groups {
interfaces {
import-rib [ inet.0 inet.3 ];
import-policy only-lo;
}
v6-interfaces {
import-rib [ inet6.0 inet6.3 ];
import-policy only-lo;
}
}
##R3
#bgp
group ibgp {
type internal;
local-address R3
family inet {
unicast;
labeled-unicast {
rib {
inet.3;
}
}
}
family inet6 {
unicast;
labeled-unicast {
rib {
inet.3;
}
explicit-null;
}
}
export nhs;
cluster R3
neighbor R1
neighbor R5
}
}
#policy
policy-statement nhs {
term one {
from {
rib inet.3;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
next-hop self;
accept;
}
}
term two {
from {
rib inet6.3;
route-filter ::/0 prefix-length-range /128-/128;
}
then {
next-hop self;
accept;
}
}
}
##R2/R4
only mpls + igp config no need to add anything ipv6 or bgp related
[1] http://www.juniper.net/us/en/local/pdf/design-guides/8020013-en.pdf
--
Kind Regards
Tobias Heister
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE and BGP signaled lsps
Am 24.07.2012 07:21, schrieb Antti Ristimäki:
On 2012-07-23 16:22, Tobias Heister wrote:
The document about scaling with labeled bgp [2] has a section about 6PE but
it does not help much. First of all the method explained to get interface
routes to inet6.3 does not work (at
least on 10.4R9 but I figured out the correct way myself) and then when I
try to follow the instructions and assign a ipv6 loopback manually and try
to advertise it via family inet6
labeled-unicast rib inet6.3 I get the following commit error: BGP: ribgroup
inet6.3 is not defined for this address family and nlri
Have you tried to configure a named rib-group where you specify inet6.3 as an
import RIB?
If I understood you correctly you want me to do something like this:
show routing-options rib-groups 6PE
import-rib inet6.3;
show protocols bgp group XXX family inet6
labeled-unicast {
rib-group 6PE;
explicit-null;
}
Unfortunately this gives a similar error: BGP: ribgroup 6PE: inet6.3 not a
valid primary rib for this nlri.
What is funny too is that the document about scaling with labeled bgp [1] does
not mention the explicit-null parameter in the family inet6- labeled-unicast.
But when removing it the router says: Missing mandatory statement:
'explicit-null' Also it states the parameter under labeled-unicast is rib and
not rib-group
I am starting to believe that this guide is for different JunOS Version where
they have changed the syntax and behaviour.
[1] http://www.juniper.net/us/en/local/pdf/design-guides/8020013-en.pdf
regards
Tobias
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 6PE and BGP signaled lsps
Dear All,
I am trying to wrap my head around this for some days now and it seems I am
stuck. Sorry for the lengthy post, bit I tried to give as much information as
possible.
I have 6 routers setup like this, currently all are logical-systems on a
MX80-48T running 10.4R9 in our lab.
/--- 9 --- 8 --- \
10 | | 5
\--- 3 --- 4 --- /
all routers in the same AS, the IGP is ISIS with a single level2, all loopbacks
visible on all routers via ISIS
routers 4, 8 and 5 are setup with a ldp lsp full mesh
routers 10, 9, 3, 4, 8 are setup with a rsvp lsp full mesh
The goal is to use labeled BGP to get a lsp up between routers 5 and 10 to use
for services ( 6PE, inet-vpn etc.) as we are not allowed to extend neither the
ldp nor the rsvp area to the other routers.
What I have done so far:
routers 4 and 8 are route reflectors for family inet unicast, family inet
labeled-unicast and family inet6 labeled-unicast
routers 5 and 10 are configured like this:
## routing-options:
interface-routes {
rib-group inet interfaces;
}
rib-groups {
interfaces {
import-rib [ inet.0 inet.3 ];
import-policy only-lo;
}
}
## bgp:
type internal;
local-address 5/10
import prefer-inet3-bgp;
family inet {
unicast;
labeled-unicast {
rib {
inet.3;
}
}
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export export-inet3-lo
neighbor 4
neighbor 8
## policy
policy-statement only-lo:
term one {
from interface lo0.10;
then accept;
}
term two {
to rib inet.3;
then reject;
}
term three {
to rib inet.0;
then accept;
}
policy-statement prefer-inet3-bgp:
from {
protocol bgp;
rib inet.3;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
preference 9;
accept;
}
policy-statement export-inet3-lo:
from {
protocol direct;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then accept;
routers 4 and 8 are setup like this:
## bgp:
type internal;
local-address 4/8
family inet {
unicast;
labeled-unicast {
rib {
inet.3;
}
}
}
family inet6 {
labeled-unicast {
explicit-null;
}
}
export export-agg;
cluster 4/8
neighbor 10
neighbor 9
neighbor 3
neighbor 5
## policy
relevant term from policy-statement export-agg
term inet3 {
from {
protocol bgp;
rib inet.3;
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
next-hop self;
}
}
As far is I understand everything is fine. I have lsps (or at least routes in
inet.3) to each other on routers 5 and 10
inet.3 on router 5
10.0.10.10/32 *[BGP/9] 1d 08:08:26, localpref 100, from 10.0.10.4
AS path: I
to 10.0.4.1 via ge-1/0/3.110, Push 300752
[BGP/9] 1d 08:08:27, localpref 100, from 10.0.10.8
AS path: I
to 10.0.4.13 via ge-1/0/3.107, Push 300272
inet.3 on router 10
10.0.10.5/32 *[BGP/9] 1d 03:02:33, localpref 100, from 10.0.10.4
AS path: I
to 10.0.0.6 via ge-1/0/4.101, label-switched-path R4
[BGP/9] 1d 03:02:33, localpref 100, from 10.0.10.8
AS path: I
forwarding for example from router 5 to a bgp prefix learned from router 10
uses this lsp and the labels show up in a traceroute just fine.
both lsps are going via router 4 (which as far as i understand) is normal in
this setup
now I want to use this lsp for 6PE and turned on ipv6-tunneling under protocols
mpls on both routers. family inet6 labled-unicast on the Route reflectors is
already in place (see above)
family inet6 on all core facing interfaces is also configured. Everything is as
expected for all the lsps inside the rsvp area and as well for all lsps inside
the ldp area. I have entries in the inet6.3 table (for the mapped v4 address)
and IPv6 Traffic is passing fine.
for example inet6.3 on R10
:::10.0.10.3/128
*[RSVP/7/1] 1d 10:08:33, metric 10
to 10.0.0.6 via ge-1/0/4.101, label-switched-path R3
Unfortunately the lsp (or better said the mapped address) signaled via bgp does
not show up in table inet6.3
I have read a bunch of documentation the last days and have not found a lot of
help for this situation. The 6PE Feature Guide [1] says This feature can be
implemented with label-switched paths (LSPs) using the Label Distribution
Protocol (LDP) or Resource Reservation Protocol (RSVP). I am not quite sure if
this means that it only can work with ldp/rsvp or if this is just a lack in
documentation.
The document about scaling with labeled bgp [2] has a section about 6PE but it
does not help much. First of all the method explained to get interface routes
to inet6.3 does not work (at least on 10.4R9 but I figured out the correct way
myself) and then when I try to follow the instructions and assign a ipv6
loopback manually
Re: [j-nsp] 6PE and BGP signaled lsps
Am 23.07.2012 16:14, schrieb Per Granath: Is there any reason why you are not running LDP-tunneling to/from R4/R8 and R10? This woule be a viable solution, but as mentioned per definition it is not allowed (or for a better term wanted) in this scenario to extend ldp beyond 4, 8 and 5 (not even via rsvp tunneling) routers 9, 3 and 10 are not allowed to run ldp on any interface. In a real world network i would probably consider ldp tunneling but this is more a can it be done this way scenario. regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 6PE and BGP signaled lsps
Am 23.07.2012 16:28, schrieb Per Granath: Am 23.07.2012 16:14, schrieb Per Granath: Is there any reason why you are not running LDP-tunneling to/from R4/R8 and R10? This woule be a viable solution, but as mentioned per definition it is not allowed (or for a better term wanted) in this scenario to extend ldp beyond 4, 8 and 5 (not even via rsvp tunneling) routers 9, 3 and 10 are not allowed to run ldp on any interface. In a real world network i would probably consider ldp tunneling but this is more a can it be done this way scenario. R10 would need to run LDP only on lo0 ... I know, but in this scenario any interface means any interface including lo0 :) or just to put it another way: no ldp process on router 10 regards Tobias ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
