Re: [j-nsp] Packet mode mpls (was Layer 2 feature on srx)

Phil Mayers wrote: On 04/10/2012 06:17 AM, Doug Hanks wrote: In the context of packet-mode, the family mpls is analogous to inet. This is correct. Not sure I understand this. analogous implies what, here? That enabling packet-mode for MPLS implicitly enables it for IPv4? Yep. Same for

Re: [j-nsp] Layer 2 feature on srx

4/10/2012 Doug Hanks wrote: I suggest that the OP use set vlan name instead of set bridge-domain name Also use set interfaces vlan instead of set interfaces irb I'm not even sure why the SRX accepted this configuration. The MX-style L2 commands are supported on SRX (branch as well and

Re: [j-nsp] Layer 2 feature on srx

10.04.2012 20:13, Michael Still wrote: OP wanted to use the IRB ints as next hop for their respective networks. This is apparently not supported on the SRX platform in transparent mode: Yeah, I mentioned this as well. In my post I just wanted to explain why these (MX-style L2) commands were

Re: [j-nsp] CGN ob MX5?

Hi, Until Juniper realizes MS-MIC (I have no idea when it will happen) MX5–80 boxes really supports no NAT at all. What they call Inline NAT on Trio (recently realized) is by now… umm… sort of a patch for a particular customer or something like. It only supports 1:1 bidirectional static mapping,

Re: [j-nsp] Firewall best practices

I have a question regarding managing policies among multiple sets of firewalls. I don't know what industry standard / best practice is for managing rules among multiple devices. My two cents. When there is really no such a standard, things to keep in mind do exist. Here are some mistakes

Re: [j-nsp] IPv6 static default route in routing instance?

My guess is that the direct route to your next-hop :a500:0:2::1 is not in this instance. Check the interface address config for ge-1/1/0.503 and ge-1/1/0.504. 13.06.2012 09:48, Gordon Smith wrote: Hi, Just wondering if anybody's come across this before - default IPv6 static not appearing

Re: [j-nsp] SRX hardware acceleration caveats

18.06.2012 14:47, Phil Mayers wrote: This is interesting. I was not aware of the EZchip offload in the high-end stuff. As of the docs, it seems like the only advantage is reduced latency:

Re: [j-nsp] SRX hardware acceleration caveats

18.06.2012 15:22, Pavel Lunin wrote: easily pass a single 10G interface (and, consequently, NPC). NPU, to be precise. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX hardware acceleration caveats

18.06.2012 16:31, Phil Mayers wrote: However, the docs suggest that it might be possible to enable offload on a per-policy basis. This might be good for certain latency-sensitive flows, if true. Yep, as I understood, it's only per-policy based (please correct, if I'm not right), which is, I

Re: [j-nsp] SRX hardware acceleration caveats

2012/6/19 Benny Amorsen benny+use...@amorsen.dk To be honest, by now it looks like a feature for a particular customer. To me it seems like a feature for every customer... Without offloading, how would you do stateful firewalling at 10Gbps+? Em… isn't 10G+ possible on SRX HE without

Re: [j-nsp] SRX hardware acceleration caveats

19.06.2012 03:25, Benny Amorsen wrote: Em… isn't 10G+ possible on SRX HE without offloading? I don't know, that is part of what I am trying to find out :) Even 'independent tests' from Cisco's friends do not argue that SRX3k can do 20G+.

Re: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

I have a /24 I want to announce, but I don't actually have it anywhere on the network. I NAT some of its IP's on the SRX that has the BGP session with our providers. Static discard is really the best way. Aggregate/generate routes are also theoretically possible, but if you are not sure you

Re: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

This is exactly what happened. The session table filled up. One of our security guys took down our edge 650 cluster from a single unix box out on the net. This is what happens when you use a stateful box for an internet router. a router with a covering aggreate and some knowledge of the

Re: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.

25.06.2012 16:06, Scott T. Cameron: 1. First, sorry for writing this once again, but it's just not the case. Any more or less smart stateful device, whether SRX or anything else, must not create session states for packets falling under a discard route. And SRX does not,

Re: [j-nsp] Quick Question About HA Setup

Ben Dale worte: All told though, I think once ISSU/LICU is addressed there'll be very little reason not to cluster them. In general I disagree. What you describe is basically about firewalls. But the main issue with a multi-site cluster is the need to pool all your VLANs to both devices. So

Re: [j-nsp] SRX: rate-limiting source NAT sources

30.10.2012 01:55, Jonathan Lassoff wrote: Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states)

Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

Richard A Steenbergen r...@e-gerbil.net wrote: IMHO multi-chassis boxes are for people who can't figure out routing protocols When it comes to ethernet switching, routing protocols means what? :) ___ juniper-nsp mailing list

Re: [j-nsp] How reliable is EX multichassis? 3300 and 8200 switches

31.10.2012 10:38, joel jaeggli wrote: On 10/30/12 5:49 PM, Pavel Lunin wrote: When it comes to ethernet switching, routing protocols means what? :) spanning-tree/trill/l2vpn/NVO and so on. Right, but if we get back to the particular case of DC/enterprise core, consisting of two EX boxes

Re: [j-nsp] MX80 no more hash-key option in 12.2?

Sorry for replying an old thread but my two cents about LB on Trio. Please take into consideration that the engineers that designed TRIO LB decided to simplify the LB options traditionally available on other chipsets, so you may find missing ones under the enhanced-hash-key. TRIO LB

Re: [j-nsp] Weird SRX flow timeout issue

12.11.2012 15:55, James S. Smith пишет: after the first hour (on a brand new session) Session ID: 29151, Policy name: vpn-usa2-out-postgres/7, Timeout: 20, Valid In: 10.2.2.5/49214 -- 192.168.2.10/5432;tcp, If: vlan.3, Pkts: 3, Bytes: 180 Out: 192.168.2.10/5432 -- 10.2.2.5/49214;tcp,

Re: [j-nsp] Weird SRX flow timeout issue

Julien, what you talk about is an entirely different story. IIRC, SRX handles TCP RST differently than ScreeOS when a server closes a session. I don't remember all the details, but something like not passing TCP RST back to the user, just closing a session or something. On the user experience

Re: [j-nsp] ipv6 autoconfiguration and ::/0

How about a generated default route on r2? 08.11.2012 12:18 пользователь Lukasz Martyniak lmartyn...@man.szczecin.pl написал: Hi all Is it possible to configure router with ::/0 same way as hosts are configured with IPv6 stateless autoconfiguration ? This is what i would like to achieve:

Re: [j-nsp] Multihoming Using Juniper SRX 240

- Load balancing all traffic between 2 ISP connections, not sure if its possible or not? - Send/Receive traffic of some subnets through one ISP and for others through other ISP to maximum utilize both ISP links First thing I must say, in 100% of cases (I am assuming it's an enterprise

Re: [j-nsp] Distributing OSPF load on MX80

29.11.2012, Benny Amorsen wrote: Alternative, is BFD cheap on an MX80? If I turn on BFD, I could set the OSPF hello timers longer than the current 10 seconds. Of course that is no good if BFD just makes even more work for the already-busy routing engine. AFAIK, at least as of 11.something, BFD

Re: [j-nsp] JUNIPER AXC1100

Hi Giuliano, Does anyone has some experience using ACX1100 or any other router from ACX family ? We are looking for an aggregate router for our network and we are thinking to use ACX only with gig ports. There is some specific questions about this router: As what I know, many things are

Re: [j-nsp] Distributing OSPF load on MX80

2012/11/29 Saku Ytti s...@ytti.fi On (2012-11-29 20:34 +0400), Pavel Lunin wrote: AFAIK, at least as of 11.something, BFD was handled by RE on MX80, not the host-CPU like it is on the big MXes. Looks like it's because the host-CPU on MX80 is quite less quick (marketing way of reading

Re: [j-nsp] SRX, UDP traffic, routing asymmetry

03.12.2012 07:48, Dale Shaw wrote: Does the SRX do something special with asymmetric UDP flows? When I say UDP I mean UDP generically, because I'm aware of special cases like set security flow allow-dns-reply. I have an ever-growing suspicion that we are throwing packets on the floor in

Re: [j-nsp] Chassis cluster and forwarding performance

(This is for packet mode J-2350) I've been reading on chassis cluster, and noted that data plane is active/active mode, does that mean double PPS in general? As there is no flow state, there is no need for cluster in packet mode. And it is not supported. In general active/active data plane

Re: [j-nsp] EX Switch Question

Just don't go there. EX is in no way a metro SP switch. Very common case, we've been discussing it with many customers, who their-selves want a Juniper metro SP solution, maybe once a week since the EX series was launched. After all that I am 100% sure this is not what EX is all about.

Re: [j-nsp] EX Switch Question

So is there anything reasonably priced in the Juniper lineup for this kind of situation or do we look at Cisco/other? If a bunch of MX5's doesn't fit the price expectation, than, I would say, Cisco/other. Looks like Juniper just did not much care metro ethernet. BTW, it's sometimes said, that

Re: [j-nsp] VPN from SRX to CIsco with more than subnet locally

16.01.2013 20:46, Anton Yurchenko wrote: Juniper solution is to either set up multiple tunnels, one for each proxy-id, or to convert the remote side to route-based VPN. On the Cisco side it is implemented via VTI, for IPSec traffic have a tunnel interface like GRE tunnel and place traffic

Re: [j-nsp] RR cluster

While the aforementioned approach (unique IDs and vanilla iBGP in between) seems a reasonable baseline, the best way in practice depends on factors like what sort of network the the RRs serve, how much state they need to hold, whether they are on-line (do carry transit traffic) or off-line (are

Re: [j-nsp] RR cluster

I would strongly advise against the previous suggestion of not running iBGP between the routers. While the topology in particular may function without it, the next person to come along and work on the network may not expect it to be configured Hmm... really depends. I can easily recall

Re: [j-nsp] MX80 port numbering

Lol. Figuring out port assignments shouldn't be like re-living Advanced Calculus in high school. Thanks to the poster who provided the KB article, that was really helpful. Things are even worse on the MX80-48T chassis with its duodecimal notation (JNCIx test authors must appreciate) and

Re: [j-nsp] LLDP on LAG behaviour

27.03.2013 11:24, Riccardo S wrote: Indeed there is a media converter (fiber to copper), but do you think that could be the problem ? Most copper/sfp media convertors are essentially just two-ports switches with a sort of hard-coded dumb pass-though config inside. So they can easily consume

Re: [j-nsp] EX Switch Question

31.03.2013 18:18, Mark Tinka wrote: On Friday, January 11, 2013 01:41:47 PM Pavel Lunin wrote: Looks like Juniper just did not much care metro ethernet. BTW, it's sometimes said, that the reason is a lack of such a market in North America (where I've even never been to, thus can't judge

Re: [j-nsp] EX Switch Question

I couldn't agree more. Funnily enough when I saw the EX2200C-12 get released being both fanless and shallow depth the first use case I thought was ME NTU/Small PoP. Front-mounted power would have been nice, but hey, I'll deal. There are enough dot1q-tunnelling knobs built-in* for most

Re: [j-nsp] Clustering J-series across a switch

02.04.2013 20:47, Mike Williams wrote: I don't have the page to hand but there is an option to configure the control link in the old way, using (a?) VLAN (4094 IIRC), otherwise new clusters will use a special ether-type. Yes, as already mentioned its revertible with set chassis cluster

Re: [j-nsp] Best route reflector platform

2013/4/21 JP Velders j...@veldersjes.net There's also SRX-BGP-ADV-LTU for Advanced BGP License for SRX 650 only (Route Reflector), though I wonder how far it'll scale... In SP terms — almost not at all. 1. Branch SRX control plane runs on a single core of the Cavium Octeon, which is not

Re: [j-nsp] Problems with Link Aggregation

22.04.2013 12:16, Ivan Ivanov wrote: http://kb.juniper.net/InfoCenter/index?page=contentid=KB10926actp=searchviewlocale=en_USsearchid=136661818 Here is written that it uses layer 2,3 and 4 for load balancing hash algorithm. And yes, the forwarding-options hash is not configurable on

Re: [j-nsp] SRX3600 weirdness

2013/4/24 James S. Smith jsm...@windmobile.ca I found that a bit strange myself, but we log all traffic flows through the firewall and the only communication going on was on port 993. Traffic log is a bad clue for that sort of issues, really. You'd need to use flow traceoptions to check out 1)

Re: [j-nsp] Best route reflector platform

2013/4/24 Richard A Steenbergen r...@e-gerbil.net wrote: it either won't work at all, or won't survive for very long. And that's after taking a lot of steps to reduce core IBGP mesh route load. I haven't touched any of the virtual SRX stuff, does it run 64-bit JUNOS? I haven't either (it's

Re: [j-nsp] SNMP on logical-system fxp0

20.04.2013 01:45, Chip Marshall write: So, I have an MX5 with it's fxp0 management interface connect to one network, which I've placed in a logical-system so it can have it's own default route for out-of-band management. This is what I never understood. Why people want to use fxp0 (or any

Re: [j-nsp] SNMP on logical-system fxp0

2013/4/25 Brandon Ross br...@pobox.com Many operators have backbone routers with 10's of 10GbE ports and maybe even a few 40 or 100GbE ports at this point, perhaps a variety of SONET still, etc. Are you suggesting that they should purchase a 10/100/1000 copper card just for management? Or

Re: [j-nsp] SNMP on logical-system fxp0

an option. 25.04.2013 19:07, Brandon Ross wrote: On Thu, 25 Apr 2013, Pavel Lunin wrote: No, I propose to not even bother with copper, if you prefer. Just use a VLAN or any other type of virtual circuit inside those TerabitEthernet / SONET / FrameRelay / whatever. So you propose to do away

Re: [j-nsp] SNMP on logical-system fxp0

25.04.2013 19:04, Alex Arseniev wrote: Netflow does NOT require encryption as standard (SNMPv3 does). Netflow or stateful log export is very often not supported on fxp0 and analogues. Even if it is, high rate of those logs can easily overwhelm RE or the link between RE and data plane. (a)

Re: [j-nsp] SNMP on logical-system fxp0

2013/4/25 Brandon Ross br...@pobox.com But in my experience real OOB mgt is a too rare case in real life of the ISP world. We have very different experiences then. I'm not claiming it's a majority, but I will claim that many of the largest networks in the world do, indeed, have true OOB

Re: [j-nsp] SNMP on logical-system fxp0

2013/4/25 Alex Arseniev alex.arsen...@gmail.com Correct. Do you expect someone to attack fxp0 from within Your OOB network? Rogue NMS server perhaps? In a big enough network — anything. Broken NMS (it turns out to happen more often than I could think), malware on management PC, misconfigured

Re: [j-nsp] SNMP on logical-system fxp0

[AA] if You actually still dealing with such issues in Your customer networks, my condolences. Especially sad is the issue with management PC - do Your customers use commodity Windows PC with freeware Solarwinds version as NMS? Yes, my customers (and companies at all) are not always ideal

Re: [j-nsp] SRX1400 opinions

Hi James, So basically SRX1400 will do fine as BGP router + firewall? Yes, it will though using a stateful firewall as ASBR has implications: traffic must go symmetrically, meaning forward and reverse flow of a given session must always go through same ASBR. In practice, it means that either

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

22.05.2013 21:01, Phil Mayers wrote: How can I determine what the dropped packets are, and why they're being dropped? show interfaces extensive and check out Flow error statistics (Packets dropped due to): Another place to look at: show security screen statistics zone/iface.

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

27.05.2013 13:44, Phil Mayers wrote: show interfaces extensive and check out Flow error statistics (Packets dropped due to): Nothing in there corresponding to the numbers/rates I'm seeing on the show security flow statistics If users are complaining, try to understand what exactly they have

Re: [j-nsp] SRX 3600 dropped packets - how to debug?

24.05.2013 19:05, Alex Arseniev wrote: If You run any kind peer-to-peer apps (uTorrent, eMule, etc, also includes Skype) then You'll see that outside peers trying to establish LOADS of unsolicited connection to Your inside hosts. And all of them will be dropped unless You enable full cone

Re: [j-nsp] SRX Screen not working

30.05.2013 04:41, Luca Salvatore wrote: However, we recently had an attack on one of our customers where there was around 400,000 sessions to a single IP address, as shown: show security flow session summary destination-prefix 202.x.x.x node1:

Re: [j-nsp] SRX Screen not working

31.05.2013 01:50, Luca Salvatore wrote: Thanks for the info. The attack we recently saw was using IP protocol 3 (GGP) which is not specifically permitted so I'm unsure how it was allowed to create a session in the first place. The right way is to catch a sample attack packet with flow

Re: [j-nsp] routing instances - ospf - summarization

05.06.2013 09:57, n f wrote: I can export between routing instances, but I'd like to know if it was possible to export via ospf from RI2 to other physical routers a single route that summarizes all the local routes I have. (like 10.10.0.0/16, as all the routes I receive via ospf on RI2 from

Re: [j-nsp] I've got some bone head problem on an srx...but I don't see it.

12.06.2013 08:59, Morgan McLean wrote: I rolled back and ran a ping to a host out on the net. Heres the trace...is the fact that its coming from junos-self screwing things up? The trace shows no src nat happened: Jun 11 21:51:22 21:51:21.1472397:CID-1:RT:flow_first_routing: call

Re: [j-nsp] Juniper EX3200 and vrf lite

17.06.2013 15:03, Per Granath wrote: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#layer-3-protocols-features-by-platform-table Supported from 12.3R1, but without PIM, IGMP, multicast in the VRF. Looks like you confused

Re: [j-nsp] Juniper EX3200 and vrf lite

17.06.2013 13:40, Victor Sudakov wrote: Does EX3200 support the VRF lite feature? I have read the datasheet at http://www.juniper.net/us/en/products-services/switching/ex-series/ex3200/ and could not find VRF lite. Virtual Router is how VRF lite is called in Juniper's parlance.

Re: [j-nsp] SRX550 Mode Packet Based for BGP Full Routing

20.06.2013 21:37, Giuliano Medalha wrote: Has anyone used the SRX550 in packet based mode for border router with BGP ? Considering the datasheet it only supports 712k BGP routes. This is not a hard limit. Just an officially supported value. I have some customers who use SRX650 as an

Re: [j-nsp] BGP Multipath

19.07.2013 10:54, Mark Tinka wrote: Why not prepend the routes out of ur gigE? That way it becomes the backup link and u can turn down bgp anytime you want on the gigE without impact Because many ISP's LOCAL_PREF the hell out of customer routes, where prepending would be ignored. However, this

Re: [j-nsp] Filter-based VLAN membership

16.07.2013 04:21, Dale Shaw wrote: The desktop/end-user folks are looking at using Microsoft's MED-V platform to support legacy apps on a new Windows 7-based SOE. From what I can tell, MED-V is basically an instance of Windows XP running in Virtual PC. The desktop guys are telling me that

Re: [j-nsp] BGP Multipath

23.07.2013 16:16, Mark Tinka wrote: I'm afraid this explanation needs to be expanded a bit. High LP on the ISP side for customers' routes is a common practice, but this makes the perpended AS-PATH (and other BGP attributes) ignored only within the ISP AS. Yes, this is true. However, if your

Re: [j-nsp] SRX devices upgraded to 2GB ram

22.07.2013 19:09, Gavin Henry wrote: This is the info we got from our supplier in UK who is a Juniper Elite partner: It's the same functionality and operation, just comes with 2G memory. It's part of a general refresh of the line that Juniper are doing just now to support future applications.

Re: [j-nsp] SRX devices upgraded to 2GB ram

Not even remotely true - I have a 240H and a 240H2 clustered together on my desk right beside me - no issues.. Wow, thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX devices upgraded to 2GB ram

Not even remotely true - I have a 240H and a 240H2 clustered together on my desk right beside me - no issues.. Wow, thanks. Though I wonder if you can cluster SRX***B with and H2 one. They are not shipping to Russia yet, so I can't check myself.

Re: [j-nsp] IP Monitoring/Tracking (SLA) on high end SRX

(nothing really important). -- Pavel Lunin Senetsy, Moscow +7 495 983-05-90, ext. 109 http://www.senetsy.ru 2013/8/18 Morgan McLean wrx...@gmail.com I guess technically any protocol would help in this case...regardless of default advertisement. I'm guessing no protocols are possible? On Sun

Re: [j-nsp] Drawbacks when using QFX5100 and EX4300 in mixed VCF mode

19.08.2014 19:51, Sebastian Wiesinger wrote: --- Hardware Requirements for a Virtual Chassis Fabric A VCF can contain up to four devices configured as spines, and up to twenty total devices. All spine devices must be

Re: [j-nsp] layer 2 sp services

Aaron, just open "MPLS Enabled Applications" or/and "MPLS in the SDN era". Both are fantastic books. It's all there :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Many contributing routes

BTW, I personally think that even aggregate routes bring more headache than benefits, let alone generate. Classic case is using aggregate to generate your own public prefixes and at the same time having a loopback address out of this range. Or a static route. Or a connected subnet. Theoretically

Re: [j-nsp] EX4550 (Un-)known unicast flooding at session start for up to 100ms

Not sure this is specifically related to the OP but there is a known > hardware limitation/feature of some Broadcom chips used in many EX switches > of the previous generations (including EX4500). > As some you have already pointed out off-list, it's Marvell, of course, not Broadcom )

Re: [j-nsp] EX4550 (Un-)known unicast flooding at session start for up to 100ms

Not sure this is specifically related to the OP but there is a known hardware limitation/feature of some Broadcom chips used in many EX switches of the previous generations (including EX4500). They use a hash table to reduce MAC lookup length, which was too small in some older JUNOS versions,

[j-nsp] Inline IPFIX sampling rate

Hi list, It's been long time I didn't write here :) Does anyone know in details how sampling-rate works (if it does) for inline IPFIX on MX/Trio? AFAIR sampling rate config hadn't had any meaning for inline IPFIX until some version of JUNOS. It used to be always 1, no matter what you have in

Re: [j-nsp] Inline IPFIX sampling rate

2017-07-25 21:41 GMT+02:00 Scott Granados : > I can confirm the rate=1 regardless of behavior up through 13.2 up through > the PFE programming blocked by flow PR when that bug was addressed. > To be honest I didn't understand. You mean, the famous "rate is always 1

Re: [j-nsp] packet checksum error in input fab_stream

> I raised the same point to Joerg in another forum and suggested JTAC, > if I had to venture a guess, perhaps PFE_ID 128 is actually RE > injected packet? > > I though of this, but it shouldn't come through the fabric. JTAC is always an option but, as it is I-chip, it might be not supported.

Re: [j-nsp] packet checksum error in input fab_stream

+1 to Saku. This means your egress PFE, identified by FPC and ICHIP(), receives corrupted cells from the fabric. It might be caused by ingress PFE or fabric chips or even backplane lines. In this case you see it on different fabric streams, so it means that this is not caused by a single faulty

Re: [j-nsp] vlan-ccc between ACX5048 and EX4500

Try to add no-control-world under your l2circuit/neighbor/interface config on both sides (as well the VLAN push/pop on the ACX side). 2017-08-23 15:16 GMT+02:00 Jay Hanke : > No luck. Here is the config I tried > > unit 517 { > encapsulation vlan-ccc; > vlan-id 517; >

Re: [j-nsp] Moving onto EX2300

VRs on a basic enterprise access switch? You guys are really crazy. "Gustav Ulander" : Yea lets make the customers job harder partly by not supporting old features in the next incarnation of the platform (think VRF support) . Also lets not make them work the same

Re: [j-nsp] Moving onto EX2300

ove a feature and > not replace it with something similar” that gets me. It shows a lack of > commitment to ones customers. > > To be honest perhaps Juniper shouldn’t have added VRF support on the 2200s > at all and just point to 3300s or SRX line. > > > > //Gustav >

Re: [j-nsp] ACX5048 - 40 gbps ER 40 km optic

2017-10-05 1:00 GMT+02:00 Aaron Gould : > Thanks Pavel, Ok here it is. Does this mean it should work ? > > > > Lane 0 > > Laser bias current: 32.187 mA > > Laser output power: 1.135 mW / 0.55 dBm > > Laser receiver

Re: [j-nsp] Combining two MS-MIC in MX104 for CGNAT

Hi Aaron, Yes, I had a customer with 2× MS-MICs in an MX104 in production. No major issues with this so far. They use nor ams neither rsp, just old-good per source IP FBF with bit masks like this: from source address 10.0.0.0/255.0.0.1 then routing-instance CGN-1 /* 10.x.x.a, a is even */ from

Re: [j-nsp] QFX 5100 can you mix vlan-ccc + vlan-bridge on the same interface with 14.1X53-D43.7

I really doubt that it's supported on QFX5100. Not 100% sure though. But what's your problem? It does not work in this combination or does not work at all? IIRC, ex4600/qfx5100 do not support control word on pseudowires as well (like ex4500/4550). So if you have something like an MX on the other

Re: [j-nsp] logical system in production - MX960

Strongly agree with Ytti. Most LSYS deployments I've seen were really "deploy an LSYS to deploy an LSYS" kind of of thing. Some more or less viable use-case I know is BGP scaling: dedicated rpd in an LSYS for an off-path RR. It creates a dedicated 32-bit rpd, which can consume another 4GB of RAM.

Re: [j-nsp] vlan-ccc between ACX5048 and EX4500

d. 23 авг. 2017 г. 11:16 PM пользователь "Jay Hanke" <jayha...@gmail.com> написал: > Setting the control word worked right away. Is the issue lack of > support of the control word on one of the sides? > > On Wed, Aug 23, 2017 at 8:49 AM, Pavel Lunin <plu...

Re: [j-nsp] ACX5048 - 40 gbps ER 40 km optic

The command you are looking for is called "show interfaces diagnostics optics". 2017-10-04 21:20 GMT+02:00 Aaron Gould : > I put this into my ACX5048 in the lab today. actually 2 of them. > QSFP+-40G-ER4 (aka QSFPP-40GBASE-ER4) SMF 40 km 1310 nm optic > > > > Optic is seen in

Re: [j-nsp] Enhanced MX480 Midplane?

Is there anyone who can give more details about the enhanced midplane? > It's just more lines (wires) to provide more fabric bandwidth per-slot/PFE. And maybe more power as well, I am not sure though. It's been shipping for ages (since 2012 or something like). It had been supposed to be required

Re: [j-nsp] MPC5EQ Feedback?

cards in the same box, your FIB is limited by the "lowest common denominator". 2017-11-01 17:07 GMT+01:00 Pavel Lunin <plu...@gmail.com>: > > > There were two versions of MPC3: > > 1. MPC3 non-NG, which has a single XM buffer manager and four LU chips > (the old good

Re: [j-nsp] MPC5EQ Feedback?

There were two versions of MPC3: 1. MPC3 non-NG, which has a single XM buffer manager and four LU chips (the old good ~65 Mpps LUs as in "classic" MPC1/2/16XGE old trio PFEs). 2. MPC3-NG which is based on exactly the same chipset as MPC5, based on XM+XL. MPC4 is much like MPC3 non-NG though it

Re: [j-nsp] Enhanced MX480 Midplane?

Is this true about MX960? Does it have a midplane also ? > > Yes though particular numbers might be different. MX960 has less backplane capacity per slot / pfe than MX480. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net

Re: [j-nsp] Best practice for igp/bgp metrics

Reference bandwidth might however be useful for lags, when you may want to lower the cost of a link if some members go down (though I prefer ECMP in the core for most cases). And you can combine the role/latency approach with automatic reference bandwidth-based cost, if you configure 'bandwidth'

Re: [j-nsp] More power questions

> The NEMA 6-20 plug is very uncommon in a datacenter environment. I > don't know why Juniper sells those cords. > It's not Juniper, it's the reseller/partner who quotes the spec. For the MX series you don't have any default per-country power cord option, which is the case for the EX, branch SRX

Re: [j-nsp] Managing large route-filter-lists

Hi list, Anyone knows if this "ephemeral configuration" thing is just a new fancy hipster-ish name of the dynamic database feature, which has been in JUNOS since 9.x and never really been widely used in production by normal people? -- Kind regards, Pavel

Re: [j-nsp] Best practice for igp/bgp metrics

ething you cannot commercially promise, you need > strategic TE to move traffic on next-best-path when SPT is full. > > > On 25 October 2017 at 23:25, Pavel Lunin <plu...@gmail.com> wrote: > > Reference bandwidth might however be useful for lags, when you may want > to

Re: [j-nsp] l2circuit down one side/up another

No TE, no problem. Extreme knows how to do it reeeally wrong :) At least, last time I checked. But yes, at the basic level it works. Adjacency, LSAs etc. 20 окт. 2017 г. 6:39 ПП пользователь написал: > I had a hard time passing IS-IS thru Extreme Switch, give up after >

Re: [j-nsp] Unequal bandwidth on virtual chassis ports?

In fact, the ring is "required" for each type of links: 32/40g stacking ports, xe and ge separately. This comes from the underlying ISIS LFA aka VC fast reroute feature. Two alternative routes are installed into the FIB for each destination, if one link fails, the corresponding route is withdrawn

Re: [j-nsp] Understanding limitations of various MX104 bundles

Yes, it's generally like that with all the absurd licenses on the low-end > MX. Look at the price of an MX80, then look at the price of an MX5, > upgraded gradually to an MX80 over time. Pay as you grow, indeed. It's > actually cheaper to buy multiple other vendor routers entirely than to pay >

Re: [j-nsp] Experience with MX10003

Not that brand new. MPC7-like, which has been around for quite some time. What should be completely new in this box is the fabric. The main gotcha is that they are still not shipping it. Same for mx204. Respectively no software is available publicly for these platforms yet. It means that you'll

Re: [j-nsp] Prefix independent convergence and FIB backup path

Here (VPNv4/v6, BGP PIC Core + PIC Edge, no addpath as not supported in vpn > AFI) we can see that, when possible: > No need for add-path in a VRF in fact. You always had it "for free" with per PE route-distinguishers. ___ juniper-nsp mailing list

Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode

--> so then in a 2node VC one node is Master one node is backup > If they split the master will go down but the backup should survive as it > is > still half of the original cluster > > So this means you should make the part you want to survive to be the > backup-RE and not the master-RE > > ---

Re: [j-nsp] EX4200 virtual chassis problem, master going into linecard mode

> > in a virtual chassis you could add: > > > > set virtual-chassis no-split-detection > > > > This will ensure that if both VC ports go down, the master routing > engine carries on working. > > Are you referring to "Scenario B" in > https://kb.juniper.net/InfoCenter/index?page=content=KB13879 ? >

<    1   2   3   >