[j-nsp] BGP Policy - then accept == Route Reflector?

Hello, I want to restrict routes sent from one iBGP peer to another. Specifically I want routes with a private AS or with no AS (redistributed from static/connected) to be sent and nothing else. On a Cisco router I would match on as-path "^$" or the private range to achieve this. So in Juniper t

Re: [j-nsp] BGP Policy - then accept == Route Reflector?

* Richard A Steenbergen [2010-11-11 18:12]: > > But there is a gotcha there: Cisco WILL NOT send iBGP routes learned > > from other iBGP peers when I configure such a policy. An MX960 on the > > other hand WILL happly start to act like a route reflector and pass on > > all the other iBGP routes

Re: [j-nsp] BGP Policy - then accept == Route Reflector?

* Brad Fleming [2010-11-12 16:48]: >> the MX960 with 9.6R2.11 did that. I was quite surprised as I was >> expecting the behaviour you describe. > > Do you happen to have configurations saved from that situation? That > seems like either (a) a MASSIVE BGP bug or (b) configuration causing > unin

[j-nsp] junosscript call to get negotiated speed/duplex?

Hello, I'm trying to find a junosscript RPC call to get the negotiated speed/duplex on a link. I tried jcs:invoke( "get-interface-information extensive" ); which doesn't include the information. Oddly enough the CLI command "show interface extensive | display xml" does: complete

Re: [j-nsp] junosscript call to get negotiated speed/duplex?

* Phil Shafer [2011-01-21 22:37]: > Sebastian Wiesinger writes: > >jcs:invoke( "get-interface-information extensive" ); > > The string argument to jcs:invoke() can only be a method name, with > no arguments. You can pass arguments in two ways: you can give &g

Re: [j-nsp] junosscript call to get negotiated speed/duplex?

* Phil Shafer [2011-01-24 02:51]: > Sebastian Wiesinger writes: > >Okay thank you for that I didn't see the "rpc" parameter behind xml. > > This is a recent feature, but I'm not sure of the release. 10.3, IIRC. My 10.1 on ex2200 has the "rpc"

Re: [j-nsp] difference between "halt" and "power-off"

* Martin T [2011-06-15 00:30]: > What is the difference between "request system halt" and "request > system power-off" under JUNOS? Is there a possibility to completely > turn off the router remotely(for example in case of Cisco it's > impossible)? On MX "power-off" turns off the RE(s) but leaves

Re: [j-nsp] difference between "halt" and "power-off"

* Martin T [2011-06-20 11:13]: > Sebastian, > in case one executes "request system power-off" under MX platform, > then physical power-cycle is needed for the router in order to boot it > up again? Hi Martin, yes, as far as I know. A colleague mentioned that there is apparently a supersecret ke

Re: [j-nsp] JUNOS and 128.0.0.0 martian (JFYI)

* Tima Maryin [2011-10-10 14:41]: > Hello! > > > Recently RIPE NCC started to allocate addresses from 128/8 to end > users, example: > > https://apps.db.ripe.net/whois/lookup/ripe/inetnum/128.0.0.0-128.0.7.255.html > > > Junos software (upto and including 11.1) blocks those address by default

Re: [j-nsp] vpls loop avoidance

* Phil Bedard [2011-10-13 02:01]: > Coming soon to at least one platform, but haven't heard anything about > Juniper. The active/standby mechanisms work pretty well but active/active > using something like SPBM or TRILL would be nicer. One problem with active/standby is mac aging on the CE switc

Re: [j-nsp] vpls loop avoidance

* Phil Mayers [2011-10-21 00:03]: > I can think of a few ways vendors could solve this. Most simply, the > backup PE could briefly down the link, to trigger an FDB flush. > Hell, you could probably script this using EEM in cisco-land. Yes, I'm looking into scripting something like that with JUNOS

Re: [j-nsp] vpls loop avoidance

* Keegan Holley [2011-10-21 00:38]: > A spanning tree TCN would do it as well. It would be nice if configuring > STP at the edge caused the box to TCN when it gives up mastership. I > haven't tried it but I'm pretty sure it doesn't. Yes that would be nice and no it does not. The other way works

Re: [j-nsp] MC LAG experience ?

* David [2011-11-01 08:05]: > I meant to say 11.2R3.3, not 10.2. Hi David, do you have a PR for that? Regards Sebastian -- New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T

[j-nsp] MX VPLS Trunk with VLAN rewriting

Hi, I'm trying to setup a VLPS "Trunk" (many VLANs - one VPLS instance) on MX960 (Trio MPC) where each site has different local VLAN-IDs which should be bridged over VPLS. Example: Site 1 VPLS Site 2 LAN1: vl100 vl10vl200 LAN2: vl301 vl11vl201 I di

Re: [j-nsp] Junos 11.2R4.3 on MX

* Jeff Richmond [2011-12-21 21:39]: > Yes, doing a lab eval on it and it has a nasty mibd leak bug. > Running a daily 11.2 build at the moment that fixes it (precursor to > R5 coming out in January). So, I would wait for R5 if you plan on > doing any SNMP work at all on the box. Same goes for VP

Re: [j-nsp] MX VPLS Trunk with VLAN rewriting

* Serge Vautour [2011-12-22 17:28]: > Hello, > > Have you tried building this up from a very simple setup that works > and adding complexity as you go? I've done something like this with > the "vlan-id all" before but not with the VLAN tag manipulations at > the same time. Hi, yes I begun with

Re: [j-nsp] Junos 11.2R4.3 on MX

* Johannes Resch [2011-12-23 12:28]: > >* Jeff Richmond [2011-12-21 21:39]: > >>Yes, doing a lab eval on it and it has a nasty mibd leak bug. > >>Running a daily 11.2 build at the moment that fixes it (precursor to > >>R5 coming out in January). So, I would wait for R5 if you plan on > >>doing an

Re: [j-nsp] Junos 11.2R4.3 on MX

* Sebastian Wiesinger [2011-12-23 12:46]: > the PR is not public at the moment. We triggered it while changing > config in a VPLS instance (adding "vlan-id none" to it). After that > the VPLS broke (BGP Routes for the VPLS were withdrawn and not > readded). Oh and to fix it

Re: [j-nsp] MX VPLS Trunk with VLAN rewriting

* magno [2011-12-23 15:27]: > hi Sebastian, > > did you try to remove the vlan-id statement at all (I mean, no vlan-id > none but no vlan-id at all)? Hi, yes I have that now and it's not doing anything. I see no mac-adresses in show vpls mac-table. Regards Sebastian -- New GPG Key: 0x93A0B

Re: [j-nsp] MX VPLS Trunk with VLAN rewriting

* Humair Ali [2011-12-23 16:41]: > Sebastian, > > you should be able to achieve what you want by using Virtual Switch Routing > instance instead of VPLS routing instance. > > you can confirgure a Virtual Switch instance with protocol VPLS in it , and > create a bridge-domains to allow all vlans

Re: [j-nsp] Junos 10.4R8 on MX (PR 701928)

* Daniel Verlouw [2012-01-24 10:13]: > Hi, > > On Tue, Jan 24, 2012 at 08:25, Daniel Roesen wrote: > > Daniel (waiting for over a year now for a 10.4 without major bugs...) > > same here... > > Am I the only one who finds it extremely annoying and disturbing that > critical bugs get *introduce

[j-nsp] QinQ between Cisco/Juniper with layer2-tunneling and VPLS

Hi, has anyone working QinQ between Cisco and Juniper running over VPLS and with working layer2-tunneling? We have a setup like this: EX4200 -- QinQ -- MX === VPLS === MX -- QinQ -- Cisco We see that on both ends of the QinQ tunnel CTP/STP/LLDP Pakets are encapsulated but on the other side nothi

Re: [j-nsp] QinQ between Cisco/Juniper with layer2-tunneling and VPLS

* Chris Kawchuk [2012-01-24 22:54]: > 2. Note that the EX4200's re-write the MAC Address when using QinQ > (i.e. STP MAC 01:80:c2:00:00:00 becomes PVST+ MAC 01:00:0c:cc:cc:cd, > for example). Ensure you are un-translating the MAC address at the > far end MX or at the Cisco; else you end up with a

Re: [j-nsp] QinQ between Cisco/Juniper with layer2-tunneling and VPLS

* Chris Kawchuk [2012-01-25 00:10]: > Heh, then it's a different problem altogether. =) > > In your VPLS config, do you have any "vlan-id" settings set in the > routing-instance? It's a long shot, else I have no idea why she > ain't passing traffic... I have "vlan-id all" set in the instance and

Re: [j-nsp] QinQ between Cisco/Juniper with layer2-tunneling and VPLS

* Payam Chychi [2012-01-25 00:36]: > On 12-01-24 03:14 PM, Sebastian Wiesinger wrote: > >* Chris Kawchuk [2012-01-25 00:10]: > >>Heh, then it's a different problem altogether. =) > >> > >>In your VPLS config, do you have any "vlan-id" setting

Re: [j-nsp] QinQ between Cisco/Juniper with layer2-tunneling and VPLS

* Sebastian Wiesinger [2012-01-24 22:23]: > Hi, > > has anyone working QinQ between Cisco and Juniper running over VPLS > and with working layer2-tunneling? We have a setup like this: > > EX4200 -- QinQ -- MX === VPLS === MX -- QinQ -- Cisco > > We see that on both end

[j-nsp] EX4500 dot1q-tunneling layer2-protocol-tunneling (L2PT)

Hello, I finally succeeded in getting dot1q-tunneling with L2PT working over VPLS and a mixed Juniper/Cisco switch infrastructure. The switching path goes like this: test-server1 -- EX4200 -- MX960 == MX960 == MX960 -- EX4500 -- Cisco3560 -- test-server2 --- Q-in-Q Tunneling with L2PT === VPLS

Re: [j-nsp] EX4500 dot1q-tunneling layer2-protocol-tunneling (L2PT)

* Sebastian Wiesinger [2012-02-13 13:42]: > So I upgraded to 11.2R5.4 but still no success. The EX4500 wouldn't > forward the packets. > > The solution? > > I had to configure > > set vlans qinq-vlan dot1q-tunneling layer2-protocol-tunneling all > > on

[j-nsp] MX IPv6 firewall filter question

Hi, I'm using a lo0 IPv6 firewall filter to protect my RE (yes, I'm filtering IPv6). Hardware is MX960/Trio-MPC running on 11.2R5.4 I have a filter to accept all ICMPv6 that has to do with neighbor discovery etc.: term accept-nd { from { next-header icmpv6; icmp-type [ neighb

Re: [j-nsp] MX IPv6 firewall filter question

* Kari Asheim [2012-02-21 15:01]: > Hi, > > Do you have a filter on the interface? No, only on the RE. 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. -

[j-nsp] EX4200 RE firewall filter capabilities

Hi all, the EX4200 has really limited firewall capabilities for filters on lo0, at least when you try to port a filter from the MX platform. A few things I encountered: 1) input-list is not supported 2) "port" statement is not supported (only source-/destination-port) 3) Many features are not av

[j-nsp] EX interface-range and commit scripts

Hi, is there any way for a commit script running on the EX series to get the configuration *after* interface-ranges are applied? Right now the interface-range ist not expanded and the individual interface configuration is not visible for the commit script. I can manually display it with the "| dis

Re: [j-nsp] EX interface-range and commit scripts

* Phil Shafer [2012-03-15 15:35]: > Sebastian Wiesinger writes: > >is there any way for a commit script running on the EX series to get > >the configuration *after* interface-ranges are applied? Right now the > >interface-range ist not expanded and the individual interface &g

Re: [j-nsp] MX80-48T-AC

* d...@infiltr8.com [2012-04-18 12:51]: > Hi list, > > I have an MX80 in the lab for labbing purposes. The idea behind to use it > primarily for JNCIE-ENT/SP studies amongst feature testing. Do any of you > have any horror stories or recommendations on JunOS versions? Hi, you have to use a rela

[j-nsp] Design questions regarding MX960<->Cisco network

Hello, I'm testing a MX960 and coming from a Cisco background I'm having a few problems/design questions regarding integration with the Cisco network. I have the following setup: +-[MX960]-+ | | |Trunk MSTP Trunk| |

[j-nsp] IPv6 uRPF + VRRPv3 packets dropped

Hello, we're using IPv6 uRPF filter on a MX960 (IRB interface) and I noticed that it drops VRRPv3 packets (source fe80::/64, destination ff02::12). Is this expected behaviour? It makes sense to me to drop link-local packets but shouldn't packets that go the RE be excluded from that? It's easily f

Re: [j-nsp] MX5 to MX80 virtual chassis feature

* Craig Askings [2012-10-23 05:44]: > Junos Node Unifier > Junos Node Unifier is a platform clustering program for MX Series 3D > Universal Edge Routers that centralizes management and automates device > configuration to enable the connection of thousands of router and switch > ports attached to M

[j-nsp] instance-specific filters for VPLS BUM/flood filtering

Hello, is there a knob so that I can get instance-specific forwarding filters for the BUM/flood filter option in VPLS instances? I want to define one filter and apply it via apply-group but I need to generate separate filters for every instance it is applied to. I can't find documentation that su

Re: [j-nsp] instance-specific filters for VPLS BUM/flood filtering

* Per Granath [2012-11-05 10:33]: > http://www.juniper.net/techpubs/en_US/junos11.4/topics/usage-guidelines/vpns-configuring-firewall-filters-and-policers-for-vpls.html > > [edit routing-instances routing-instance-name forwarding-options family vpls] > filter input input-filter-name; Hello, I m

Re: [j-nsp] instance-specific filters for VPLS BUM/flood filtering

* Christopher E. Brown [2012-11-06 10:41]: > > And I have tested and seen exactly the opposite with 10.4R10 in both > MX80 and all trio MX960. > > > Create a policer and a vpls filter that matches unknown ucast, bcast and > mcast. > > Apply to VPLS forwarding table in 2 instances > > ... > >

Re: [j-nsp] MX80 MPLS L3VPN Fragment drops

* Leigh Porter [2012-11-06 00:46]: > A packet dump reveals that the TCP sender (FTP server) will send a > segment, the LTE core will encap this segment and fragment the > tunnel packet, these fragments enter into an MX80 and into a L3VPN > instance but then only the first half of the fragmented da

Re: [j-nsp] instance-specific filters for VPLS BUM/flood filtering

* Saku Ytti [2012-11-06 14:27]: > > Just to be sure, could you try to use the "interface-specific" keyword > > for your filter? > > You should have tried that, it won't commit. It was first thing I tried > when testing VPLS. Yeah, you're right. I remembered that it didn't matter but I was wrong.

Re: [j-nsp] MX80 MPLS L3VPN Fragment drops

* Leigh Porter [2012-11-06 15:54]: > > you might be hitting PR736749: > > In L3VPN scenario, transit packets which require fragmentation, traversing > over the > mpls core, might get dropped at the egress PE, if the egress PE?s, CE facing > interface > is on trio chipset cards. [PR736749: This

[j-nsp] inline-jflow on MX MPC (Trio) - experiences?

Hello, we're just setting up inline-jflow on MX Trio chipsets and I'm seeing a few odd things: 1) Why is inline-jflow sending so many packets instead of putting more then one flow in one udp packet? Every ~5 seconds I get a LOT of UDP packets at the same time, many of them only containing 1

[j-nsp] Problem with 802.1p/802.1q priority values and MX / EX4200

Hello, we're having a strange problem with 802.1p priority values: Packets are forwarded by VPLS. A MX960 (MPC/Trio) then forwards them onto an EX4200 virtual chassis from where they are forwarded to an external service provider (SP) as a VLAN tagged link. While testing the line we noticed that

Re: [j-nsp] Problem with 802.1p/802.1q priority values and MX / EX4200

* Sebastian Wiesinger [2012-11-22 16:45]: > I tried forcing all packets to best-effort/loss-priority low on the MX > but that didn't change anything. I'm currently suspecting the EX4200 > to be the problem. Okay, now I found a workaround but I'm still not sure abo

Re: [j-nsp] Problem with 802.1p/802.1q priority values and MX / EX4200

* Nick Kritsky [2012-11-22 18:15]: > Judging on previous experience, I would blame EX, not MX. :) > But just to be sure - can you add input counter filters to EX interface > connected to MX? Just to be 100% sure that packets are coming in without > weird 802.1p Hi, I did that (see my first mail)

Re: [j-nsp] inline-jflow on MX MPC (Trio) - experiences?

* Paolo Lucente [2012-11-22 18:24]: > > 3) The test collector is reporting missed flows. I'm not sure if that > >is a problem with the collector or if I'm really missing flows. > >Anyone else had this problem? > > It can be something else but i'm generically not surprised on this: > nearl

Re: [j-nsp] Problem with 802.1p/802.1q priority values and MX / EX4200

* Sebastian Wiesinger [2012-11-22 16:45]: > Hello, > > we're having a strange problem with 802.1p priority values: And hello again, a colleague from another company tested this and found out that packets that traversed his EX switch also got their 802.1p field messed up. So.. it

Re: [j-nsp] Problem with 802.1p/802.1q priority values and MX / EX4200

* Nick Kritsky [2012-11-22 22:45]: > sorry, misread the original email. > were you able to identify any pattern in which packets are remarked? No, I couldn't see any pattern. > also, can you share interface config for EX/MX? It's a trunk interface on the EX and on the MX its a vlan-vpls encapsu

Re: [j-nsp] jflow v9 - flow start timestamp not reset

* Andrew Jones [2012-08-12 05:32]: > Hi All, > There is a behaviour in jflow v9 which is frustrating me whereby once > flows reach the active timeout the flow is exported, the packet and byte > counters reset, but the flow remains in the flow table and the start time > is not modified. According t

[j-nsp] MX80 BGP performance after reboot

Hi, 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 and in the meantime we get messages like that every few seconds: /kernel: rt_pfe_veto:

Re: [j-nsp] MX80 BGP performance after reboot

* Paul Stewart [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 93A

Re: [j-nsp] MX80 BGP performance after reboot

* Jeff Wheeler [2013-02-12 01:03]: > On Mon, Feb 11, 2013 at 6:15 PM, Sebastian Wiesinger > 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 i

Re: [j-nsp] MX80 BGP performance after reboot

* Stacy W. Smith [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-j

Re: [j-nsp] MX80 BGP performance after reboot

* Sebastian Wiesinger [2013-02-14 08:06]: > * Stacy W. Smith [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 n

Re: [j-nsp] MX80 BGP performance after reboot

* Brandon Ross [2013-02-14 04:57]: > 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# because they do not want to > >fix this

Re: [j-nsp] MX80 BGP performance after reboot

* Sebastian Wiesinger [2013-02-15 00:55]: > I just tested this after talking to JTAC. Just for reference: > > I had ~70k routes from 40 peers that I deactivated. I then turned them > up again and measured with inline-jflow disabled and enabled. > > With inline-jflow ON: ar

Re: [j-nsp] MX80 BGP performance after reboot

* Sebastian Wiesinger [2013-02-19 10:20]: > So... ATAC says this is expected behavior for this platform. Nothing > wrong with the router. > > He even sent me lab tests that he did which proved that it takes them > the same time in the lab. > > I now sent him the NANOG sl

Re: [j-nsp] MX80 BGP performance after reboot

* Saku Ytti [2013-02-19 13:09]: > On (2013-02-19 10:54 +0100), Sebastian Wiesinger wrote: > > > Okay, so ATAC says that the NANOG PR has nothing to do with this case. > > This is a hardware limitation on MX and cannot be improved according > > to them. > > I th

Re: [j-nsp] MX80 BGP performance after reboot

* Sebastian Wiesinger [2013-02-19 13:57]: > Yes, I agree. But that's a design "decision" so ATAC is not > interested. I'll try to get this to Juniper trough my SE but I don't > know if that'll do any good. So Juniper is aware that this is a problem (at leas

Re: [j-nsp] MX80 BGP performance after reboot

* Sebastian Wiesinger [2013-02-21 10:31]: > There is also a NANOG discussion regarding this: > > http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html Sorry I just glanced at that. That's actually a post from this list. Regards Sebastian -- GPG Key: 0x93A0B9CE (

Re: [j-nsp] MX80 BGP performance after reboot

* Stacy W. Smith [2013-02-21 15:57]: > Sebastian, > > PR 836197 is a problem that some customers are seeing, but it is not > the problem that you reported in this thread. Your issue appears to > be (primarily) an issue with sampled. Yes, but the underlying issue seems to be RIB/FIB sync time. An

Re: [j-nsp] 11.4R6-S2 feedback ?

* david@orange.com [2013-02-27 17:36]: > Hi all > > Does anybody use this version in production ? if yes, did you experience some > SW issues with it? We're having -S1 in production and no major problems. We see a strange problem with RE firewall filters where packets are sporadically disca

[j-nsp] VPLS SNMP MIB - Remote sites signaled down?

Hello, I'm just testing the SNMP MIBs in 11.4 for VPLS. I have a VPLS PE with a connection table like this: Instance: CUSTOMER1-VPLS Local site: customer1-site3 (3) connection-site Type St Time last up # Up trans 1 rmt RD 2

[j-nsp] MX80 port numbering

Has anyone here an easily understandable graphic for port numbering on MX80 mic slot(s)? I can't get it right half of the time and support staff on-site never knows which port is which. Even the labels on the box are not really helpful. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 2

Re: [j-nsp] MX80 port numbering

* apurva modh [2013-03-15 12:03]: > Are you looking for this > > http://kb.juniper.net/InfoCenter/index?page=content&id=KB25588&actp=RSS YES! I am SO looking for this. This will be bookmarked until judgement day. Thanks! Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D

[j-nsp] MX - Input packet rejects

Hello, I'm a bit puzzled by the 'Input packet rejects' counter shown by 'show interface .. extensive'. What exactly does that counter count? I have this output: Filter statistics: Input packet count38435461 Input packet rejects 23759 Input DA reject

Re: [j-nsp] MS NLB multicast mode and EX 12.x new behaviour issues

* Tarko Tikan [2013-04-28 19:12]: > By 'mixed' you surely mean painful. E-s filters do not work for STP, > period. STP traffic is captured to RE first, bypassing all ingress > filters and is then sent out from RE to be flooded as normal > multicast. Hi, I can't confirm this. We have working bpdu

Re: [j-nsp] experience using 10G DAC (twinax) cables between EX and multi-vendor

* Andy Litzinger [2013-05-15 21:00]: > Has anyone used a 10G DAC/Twinax cable between an EX4550 and other vendor > gear? Did you use Juniper DAC cables or the other vendor cables? > > In particular I'm planning on linking a Cisco UCS Fabric Interconnect and > also an F5 BigIP 4200v to a VC of

[j-nsp] RPD queue stall, RIB/FIB programming time fixed in 11.4R8?

Hello, reading PR836197 and KB26792, it seems that the RPD queue starving/stalling was improved (even fixed?) in 11.4R8, 12.1X45-D10, 13.1R1 and 13.2R1. To quote from the KB: | Starving jobs are now added to a FIFO (first in-first out) queue. This | guarantees that a starving job is always servi

[j-nsp] BOOTP helper on MX vrf

Hello, as I'm hearing conflicting information regarding bootp helper on MX routers in a vrf routing-instance, has anyone a working configuration? What I need: Forward DHCP broadcast requests from one vrf interface to a central DHCP server in the same VRF (classical bootp helper functionality). I

Re: [j-nsp] BOOTP helper on MX vrf

* Mark Tinka [2013-06-13 13:24]: > On Thursday, June 13, 2013 01:03:04 PM Sebastian Wiesinger > wrote: > > > So any information regarding this is appreciated. > > This was my working configuration on an MX480 running Junos > 10.4: > > routing-i

Re: [j-nsp] BOOTP helper on MX vrf

* Mark Tinka [2013-06-13 13:39]: > On Thursday, June 13, 2013 01:25:34 PM Sebastian Wiesinger > wrote: > > > Okay, but for dhcp-relay you need a license which is > > really not something we want to do just for bootp > > helper. :) > > If memory serves, I think

Re: [j-nsp] BOOTP helper on MX vrf

* Saku Ytti [2013-06-14 09:51]: > Another problem with DHCP-relay is that, AFAIK, it causes _all_ dhcp > packets in every interface to be punted. So some transit DHCP packet > jetting through your router in unrelated interface gets punted. > I find this most unsatisfactory, but of course we're 'on

Re: [j-nsp] KRT queue stalls fixed in 11.4R8?

* Grzegorz Janoszka [2013-06-24 21:57]: > On 24-06-13 21:07, Rob Foehl wrote: > > According to the release notes for 11.4R8, the KRT queue stall issue > > (PR836197) has been marked as resolved. Has anyone had a chance to > > confirm this on a suitably session-heavy MX? > > You still have to wai

[j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

Hello, I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from the MX is: Take alle VLAN tagged frames on an Port (CE-facing) and switch them to another interface (Core-Facing). On the core-facing interface push VLAN 42 on the frames (Q-in-Q). When frames arrive on the core-facing IF,

Re: [j-nsp] Can I do "dumb" Q-in-Q switching on Juniper MX?

* Sebastian Wiesinger [2013-07-01 12:11]: > Hello, > > I need to do a sort of "dumb" Q-in-Q on a MX box. What I want from > the MX is: Hello, a follow up to my question. We decided to do MPLS CCC (as we have a MPLS enabled core). It works just fine with RSVP. I'l

Re: [j-nsp] flow sampling: what packets are chosen?

* sth...@nethelp.no [2013-07-25 01:21]: > > "When using inline IPFIX the only valid rate is 1. The option > > run-length isn't configurable, because there's no need to sample data > > from the perspective of the microcode in the Trio Lookup Block. Every > > packet will be inspected and is subjec

Re: [j-nsp] flow sampling: what packets are chosen?

* Michael Loftis [2013-07-25 23:54]: > Good to hear, I remembered reading that mostly because it seemed so > wrong. I don't think I'm missing any context from the book, and I > don't have any MPC/Trio based gear to test on myself. I also read it in dhanks book and I wrote him on IRC about it and

[j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

So, it's friday and there is PSN-2013-08-987. Am I overlooking something or is that only a problem for people who speak OSPF with other parties (customers, strangers,...)? I don't see the big attack vector in comparison to speaking OSPF with others in the first place... Regards Sebastian -- GPG

Re: [j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

* Cheikh-Moussa, Ahmad [2013-08-02 11:03]: > Hi Sebastian, > > it depends on the environment. On a PtP interface it is not an issue, on a > broadcast network, it could be an issue. > In general, it is always recommended to turn authentication ( md5) on and > protect the RE with a lo0 filter. H

Re: [j-nsp] PSN-2013-08-987 - OSPF Advisory - Impact?

* Chris Morrow [2013-08-02 11:12]: > > > On 08/02/2013 04:26 AM, Sebastian Wiesinger wrote: > > So, it's friday and there is PSN-2013-08-987. Am I overlooking > > something or is that only a problem for people who speak OSPF with > > other parties (customers, str

Re: [j-nsp] Config archive subtleties

* Ben Dale [2013-08-08 02:00]: > I haven't use this in anger for a while, so apologies if some of this > functionality is already available, but how about: > > - an option to disable compression of the config file > - an option to specify the naming convention used - eg: always back up to a > s

[j-nsp] IPv6 VRRP packets dropped?

Hello, I have two MX routers with a VPLS instance. The instance has an irb interface on both routers with IPv6 VRRP configured on it. On the backup router I see the VRRP mastership flap every few seconds. When I look at VRRP statistics I see that it receives much less packets than the other route

[j-nsp] AE loadbalancing with Ethernet CCC over L2VPN

Hello, I have the following setup: [CE] == AE(2 links) == [MX80] --- L2VPN --- [MX80] == AE(2 links) == [CE] The problem is that the MX80s both only send outgoing traffic to the CE on one link of the AE bundle. There is no hash-key/enhanced-hash-key configured on the boxes. The configuration i

[j-nsp] PCI ERROR when inserting MX-MPC1E-3D in MX960

Hello, I tried to take a MX-MPC1E-3D FPC online in a MX960 chassis in the lab. This produced PCI errors like this: Oct 10 13:38:41 /kernel: pic_listener_connect: conn established: mgmt addr=0x1b80, Oct 10 13:38:42 fpc11 CLKSYNC: master RE connection made Oct 10 13:38:42 fpc11 vrrp_db_i

Re: [j-nsp] RIB -> FIB filtering.

* Matjaz Straus Istenic [2013-11-10 16:27]: > Fat fingers, sorry: > > On 10. nov. 2013, at 09:07, Matjaz Straus Istenic > wrote: > > > If your upstream is using juniper gear, it would (technically > > speaking, of course) very hard for them to implement such a > > service. > ...it would _not_ b

[j-nsp] MACsec on EX switches

Hello, has anyone here experience with MACsec on EX switches (4550/4200)? Especially performance, caveats, problems with the required JunOS software (JunOS Controlled)? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE S

Re: [j-nsp] Enabling SSL support for JunosScript invocation

* Saku Ytti [2013-12-02 15:54]: > On (2013-12-02 09:17 -0500), Phil Shafer wrote: > > > JUNOS uses the "fetch" app under the covers, which lacks HTTPS > > support. We're moving to "curl", which does. I don't have an > > ETA on this support. > > I believe the problem is, domestic incorrectly ca

Re: [j-nsp] proposed changes to "clear bgp neighbor"

* Phil Shafer [2014-02-26 16:42]: > Juniper users, > > We've been asked to make a change the "clear bgp neighbor" command > to make the neighbor or "all" argument mandatory. The root cause > is the severe impact of "clear bgp neighbor" and the increasing > accidental use of this command without

[j-nsp] Multicast/Broadcast Packets going to EX CPU

Hello, I'm currently looking at an EX4500 setup that had a few problems related to multicast/broadcast packets going to the CPU (and sometimes preventing required packets like LACP reaching the CPU) of the switch. I assume this was because the queue between PFE and CPU was full (is there a way to

Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU

* Keegan Holley [2014-03-05 18:33]: > I agree. It’s more likely that you had an increase in packets that > the switch would process normally than the switch getting bored and > suddenly deciding to read packets off the wire. If there is an IP > interface on the network that the broadcast/multica

Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU

* Phil Mayers [2014-03-05 19:12]: > >Chris, can you elaborate on why low TTL on multicast frames will > >cause high CPU? > > > >Sebastien, as Chris pointed out anything in the 224.0.0.0/24 will hit > >the CPU, but so will a few other ranges that fall into the Link-Local > > There's no inherent re

Re: [j-nsp] router-jockeys and gui tools

* Phil Shafer [2014-03-05 19:36]: > [hijacking part of a thread from Keegan] > > Keegan Holley writes: > >My gut says this is as much a product of Space being new as the general > >skeptcisim most > >router-jockeys have towards GUI/WebUI based management tools. > > As the on-box CLI developer,

Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU

* Clarke Morledge [2014-03-06 16:42]: > Sebastian, > > No, you are not alone on this issue. > > For a little more context, I have seen the same type of behavior > associated with Apple Bonjour traffic related to > Multicast DNS reported on this thread in November, 2013: > > http://www.gossamer-

[j-nsp] MX - Stitching L2VPN into VPLS domain

Hello, I'm searching for a way to stitch a kompella L2VPN into a VPLS domain on MX routers. I want the L2VPN pseudowire to behave like a normal site in the VPLS. Has anyone here done this and knows how? I found the "Internetworking interface" (iw0) that does kind of what I'm looking for: http://

[j-nsp] Opportunistic ARP on Juniper MX?

Hello, does anyone know if Juniper MX does opportunistic ARP? Meaning, will it send out an ARP request by itself when an ARP entry expires (like Cisco does) or will it wait until it needs to resolve the ARP entry when a packet arrives? Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 2

Re: [j-nsp] Opportunistic ARP on Juniper MX?

* Mark Tinka [2014-05-26 09:18]: > On Monday, May 26, 2014 09:10:20 AM Sebastian Wiesinger > wrote: > > > does anyone know if Juniper MX does opportunistic ARP? > > Meaning, will it send out an ARP request by itself when > > an ARP entry expires (like Cisco does) o

Re: [j-nsp] mx240 - chassisd process takes whole cpu

* Piotr [2014-06-20 00:36]: > Hi, > > Since 13:50 i have very high cpu on routing engine, router doesn't > answer for some snmp request (re cpu, interface counters are ok) but > besides this, looks good - router pass traffic. It looks like > problem with chassisd process ( nanslp ?? state). I don

  1   2   >