Re: [j-nsp] Juniper vMX limitations
On 30 Jul 2015, at 11:11 pm, Chris Adams c...@cmadams.net wrote: Once upon a time, Phil Bedard phil...@gmail.com said: I’m sure they’ve had it running in VMWare, but it’s a little more difficult and you need the Enterprise Plus version of vSphere to get virtual serial ports. I’d be more comfortable running it under KVM myself. Just an FYI: if you are looking for a KVM-based virtualization setup that has more of the functionality of VMWare (not just CLI-based local VMs), check out oVirt http://www.ovirt.org/. And similarly ProxMox - https://www.proxmox.com/en/proxmox-ve - I haven’t tried vMX on it yet, but it’s a pretty nice ESX replacement for general purpose use -- Chris Adams c...@cmadams.net ___ 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] Proper Break of MPLS RSVP Ring
Hi Levi, On 17 Jul 2015, at 5:22 am, Levi Pederson levipeder...@mankatonetworks.net wrote: This is displaying it self in my output by not having an RSVP Neighbor (neighbor down hellos sent) between CD (and therefore sending my traffic inefficiently 3/4 way around the ring instead of the 1/4 hop it could. Last bit of information is that D sees C as a neighbor but is down. C does not even see D as a neighbor at all. This sounds like an L2 issue, or perhaps a misconfiguration - all nodes should be RSVP neighbours in order to be able to signal LSPs across those interfaces. Check your protocols rsvp config for the logical interfaces between D. Use monitor traffic interface D-C interface on D to confirm that RSVP is being sent out of the box. Check any control-plane filtering/firewall filters you have configured on C (though it seems to be receiving just fine from B). I'm wondering how RSVP breaks that link. All the documentation I can find are focused on LSP validation/creation and not on Link Breaks to stop layer 2 loops (is my assumption). If one of my intervening links goes own I would like to correct it and then move the break to the specified point. But the RSVP documentation is rather...limited to only LSPs if I am reading it correctly. RSVP won’t break the link to stop loops (the LSPs will carry service labels which may not even be L2 services), it will simply establish the LSP across the best/shortest path between endpoints (based on your TE settings), and if this becomes unavailable (and depending on your configuration) it will simply re-establish over any alternate path (which it sounds like is working well). Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Basic Implementation of VLAN/LogicalPort across MPLS
Hi Levi,
I've setup an MPLS ring and with your help it's running beautifully. With
it I can easily make port congruence across the MPLS ring with few issues.
For example send a single from one side of the MPLS ring to the other if
the signal lands on a port directly. I.E a physical interface.
Based on your previous email, I’m assuming your transport labels are all
RSVP-based.
Where I'm having trouble now is landing or starting from a logical
interface such as a VLAN.
For an aggregate interface, make sure you have flexible-ethernet-services
configure on the physical interface (or vlan-ccc, but if not all units are
going to be l2circuits, then stick with flexible-ethernet-services), and then
encapsulation vlan-ccc for all the sub-interfaces you wish to tunnel:
interfaces {
ae0 {
aggregated-ether-options {
lacp {
active;
}
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 10 {
encapsulation vlan-ccc;
vlan-id 10;
}
unit 20 {
encapsulation vlan-ccc;
vlan-id 20;
}
}
}
To bring up an l2circuit, it’s just a simple matter of assigning and ID to the
port, and mapping it to a remote PE:
protocols {
l2circuit {
neighbor 1.2.3.4 {— the far-side PE loopback where you want the
other end of the tunnel to come out
interface ae0.10 { — your local interface
virtual-circuit-id 10; — unique identifier
}
}
}
}
Cheers,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS Endpoint Discussion
On 3 Jul 2015, at 12:25 am, Levi Pederson levipeder...@mankatonetworks.net wrote: All, I've created simpler MPLS ring between a total of 6 MPLS 4550s. My questions what IP do I use for the Label Switched Path Endpoints. I can't seem to find a best practice. Specifically this code Obfuscated as I'm a little to literal with my descriptions set protocols mpls label-switched-path PE2-to-PE1 to 10.254.1.1 set protocols mpls label-switched-path PE2-to-PE3 to 10.254.1.6 set protocols mpls label-switched-path PE2-to-PE4 to 10.254.0.4 Do I use the /30 that exists between the Legs? Or should I use the LoopBack0 ? My thought would be Leg itself as it creates the path. But some documents state LoopBack. Always use loopbacks - if the link goes down (or the preceding node), the destination of the LSP goes with it - Junos will not maintain prefixes for downed interfaces. You mention this being a ring - if you target the LSP to a loopback, your IGP will provide an alternative path after a failure. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Log Message
Hi Mohammad, On 11 Jun 2015, at 4:32 pm, Mohammad Khalil eng.m...@gmail.com wrote: Hi all I have mx480 in place and I am having the below log messages Jun 8 18:23:10 CR01-A fpc5 NH: Failed to find nh (1657) for deletion Jun 8 18:23:10 CR01-A fpc5 NH: Failed to find nh (1629) for deletion Jun 8 18:49:25 CR01-A fpc5 NH: Failed to find nh (1627) for deletion Jun 8 18:49:25 CR01-A fpc5 NH: Failed to find nh (1437) for deletion Jun 8 18:49:25 CR01-A fpc5 NH: Failed to find nh (1433) for deletion Jun 8 18:49:25 CR01-A fpc5 NH: Failed to find nh (1344) for deletion Jun 9 00:04:20 CR01-A fpc5 NH: Failed to find nh (1354) for deletion Jun 9 00:04:20 CR01-A fpc5 NH: Failed to find nh (1309) for deletion Jun 9 06:23:23 CR01-A xntpd[1296]: kernel time sync enabled 6001 Jun 9 06:40:28 CR01-A xntpd[1296]: kernel time sync enabled 2001 Jun 9 08:05:51 CR01-A xntpd[1296]: kernel time sync enabled 6001 Jun 9 08:22:54 CR01-A xntpd[1296]: kernel time sync enabled 2001 Jun 9 10:22:22 CR01-A xntpd[1296]: kernel time sync enabled 6001 Jun 9 10:39:28 CR01-A xntpd[1296]: kernel time sync enabled 2001 I have tried to look for it in , but nothing useful Any ideas? Thanks in advance ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp This looks like you: https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR494528 Under certain circumstances we will report 'NH: Failed to find nh () for deletion' for child links of an aggregate. When an aggregate next-hop is deleted we delete all the children next-hops, if the child next-hop is not found then the messages is printed. However, this message is cosmetic since the child next-hop can be deleted earlier to aggregate next-hop delete. Resolved in 10.2R4 10.3R3 10.3R4 10.4R2 11.1R1 11.2R1 Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRx self-generated traffic
On 18 May 2015, at 11:21 pm, M Abdeljawad via juniper-nsp juniper-nsp@puck.nether.net wrote: Hello I have three questions related to SRX self-generated traffic 1- How to force the SRX self-generated traffic to get out to internet through certain link (suppose I have two internet connections)? Self-generated traffic will use inet.0 to determine the best path anywhere. I'm not aware of any way to perform policy-based routing on self-generated traffic, as FBF is applied on ingress. 2- Is it possible to carry the self-generated traffic over a VPN tunnel terminated on the SRX? Yes, however there are some caveats to this approach depending on the specific traffic you are generating. In general though, you want to have numbered interfaces (eg: your st0.x interface has an IP address assigned to it) so that the source IP of the traffic is something sane (traffic sourced from an unnumbered tunnel interface will otherwise select the underlying interface IP address, which may be public). Depending on what you are trying to do, you might find this useful: set system default-address-selection This sources all system-generated IP traffic from the loopback interface if one is defined. Depending on which zone your loopback is in, you can then configure policies to suit. 3-Can we proxy the self-generated traffic to some proxy server? In the case of traffic like syslog, DNS and software updates then yes this should be possible (for various definitions of proxy). Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] interoperation between MSTP and old STP
Hi Victor, On 15 May 2015, at 6:06 pm, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, I have several EX4200 switches with redundant links, all are running MSTP with a couple of MSTIs. If I include an older switch which can only run old-fashioned STP, will they interoperate and still keep the topology loop-free? What if it can run STP and RSTP, but not MSTP? They will interoperate, however there are key differences to be aware of: - STP/RSTP forms topology with STP bridges regardless of whether correct VLANs are trunked on ports - this can mean that topologies may form that isolate VLAN segments if you haven't configured trunked ports correctly on all links - STP/RSTP bridges will treat an MSTP network (regardless of how many switches it contains) as single contiguous bridge, so you may find that the ports that block in your RSTP network aren't quite where you expected them to be when simply counting the radius from the root bridge. A link to some good documentation is also appreciated. TIA for any input. I highly recommend Petr Lapukhov's work here: http://blog.internetworkexpert.com/2010/02/22/understanding-mstp/ The configuration and outputs are IOS-based and there are a few PVST+ interop discussions, but the supporting protocol description and break-down is truly excellent. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Passing Traffic over SRX Cluster Fabric
Hi Mahmoud, On 3 May 2015, at 10:27 pm, M Abdeljawad via juniper-nsp juniper-nsp@puck.nether.net wrote: Hi I have two SRX Cluster, and the design requires that the traffic pass through the fabric-link.but noticed some drop on the traffic when traffic pass through the fabric link. Is there a limitation for passing traffic over fabric link (the passing traffic size was around 500M, and the fabric link is 10G) RegardsMahmoud ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp If you're deliberately running a Z-mode traffic (and even if you're not) you need to check that you've set the MTU on the physical interfaces of the fabric link to be large enough to take the biggest frame you would receive on your reth/revenue interfaces plus overhead. The recommended/max values are 8900 for reth/revenue ports and 9014 for the fabric link. Reference Guide: http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/NT260/SRX_HA_Deployment_Guide.pdf Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX secure wire and layer 2 pdus
Hi Ross, On 29 Apr 2015, at 1:43 am, Ross Vandegrift r...@kallisti.us wrote: Hi all, The documentation for SRX secure wire has thrown me for a loop. It says: secure wire is a kind of transparent mode, and transparent mode interfaces pass all ARP and non-IP broadcast/multicast. So a secure wire should pass BPDUs and LACPDUs. I think that's a mistake. If both secure wire interfaces land on the same switch, RSTP/MSTP ought to block one of the interfaces. Separate switches won't help if both are multihomed to common distribution switches. The secure wire will look like two edge interfaces were cabled together, and RSTP/MSTP will block. I setup a test with two ex4200s and a secure wire between them. No BPDUs or LACPDUs make it across. Seems good, but now I'm nervous that the behavior doesn't match the documentation. Have I missed something? Case is open, but it stalled at the repeat the documentation stage. https://www.juniper.net/techpubs/en_US/junos12.3x48/topics/concept/layer-2-secure-wire-understanding.html Ross The doco needs a slight update (or better yet, a cross-reference) to the link below. In the documentation for Transparent Mode, it mentions the Layer 2 bridging exceptions on SRX that apply when using a bridge-domain for transparent-mode, which is the same method SecureWire uses for tying interfaces together. http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/layer-2/index.html?topic-52744.html You'll see there that xSTP is specifically called out. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX: Hardware-Down for an irb logical unit
Hi Chuck, On 29 Apr 2015, at 9:32 am, Chuck Anderson c...@wpi.edu wrote: What would cause an irb logical interface unit to stay in Hardware-Down? I'm using identical configs on 4 different routers (different IPs of course), and one of them won't come up. There is at least one physical interface in the BD that is up. The irb physical interface is up. There are many other irb logical units that are up and working fine, just this one unit that is down. This is usually caused because there are no physical interfaces up in the bridge-domain. I notice you've got an aggregated-ethernet interface in there - if you have LACP enabled, but no LACP partner, the physical link will stay up, but the logical interface will go down, thus taking down your IRB as well. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls question
On 27 Apr 2015, at 5:57 pm, james list jameslis...@gmail.commailto:jameslis...@gmail.com wrote: Well indeed OSPF is running also with customer peer in the other side of the MPLS cloud (CE2) and PE3/4 (still other side)... and it's due by customer requested design to have VPLS and OSPF on the PEs... So I understand that putting protocols vpls connectivity-type irb do not solve... I'm wondering why and the expected behaviour... If you have a VPLS with two PEs joining to one CE at each site, you've created two loops, one at each site. Standard behaviour is to define both PEs as a single site in the VPLS and use multi-homing and site-preference to keep one PE-CE interface inactive until such time as the other is required as already mentioned. You can't run OSPF across both links without bringing them both up, which will create an L2 loop - these things are mutually exclusive. The protocols vpls connectivity-type irb will keep the instance up if you have irbs defined and the PE-CE link goes down, but this doesn't really help you though. It might be time to break out the sock puppets and have a robust discussion with your customer. cheers James 2015-04-27 0:36 GMT+02:00 Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au: Hi James, On 27 Apr 2015, at 5:31 am, james list jameslis...@gmail.commailto:jameslis...@gmail.com wrote: Hi amarjeet Because if PE1 fails there is faster convergence to PE2 due to neighbor already established. Is there a reason you wouldn't consider using an L3VPN instead of a VPLS? It seems odd to me that you would be using L3 adjacencies to an L2 service. If it really is L2 fail-over you are chasing, then Amarjeet is correct - multihoming and site-preference are designed for exactly this purpose. If you customer requires L3 connectivity across your VPLS, you would be better off carrying their OSPF across the VPLS and let their CEs form adjacencies with each other - that way, you can take care of L2 fail-over, and the customer is responsible for L3. Cheers, Ben Cheers James Il 24/apr/2015 13:23, james list jameslis...@gmail.commailto:jameslis...@gmail.com ha scritto: I have a VPLS multi-homed environment with two MX routers (PE1 and PE2) connected to a single ethernet switch (CE1). I have PE1 configured with site-preference as primary and PE2 as backup. Behind the CE1 there is a router running OSPF with both MX (on irb interface). My goal is to have: 1)Multihoming to prevent loops 2)Let the router run two OSPF neighbor with both PE and not just one with the primary PE. I’m wondering if using: set routing-instances protocols vpls connectivity-type irb instead of the default (connectivity-type ce) could give me the option to reach my goal number 2) and if I can introduce any drawback. Or if there is another solution keeping 1). I don’t have a lab to test… Any help/feedback is really appreciated. Greetings James ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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] solution to a firewall question
Hi Vijesh, On 24 Apr 2015, at 1:18 am, Vijesh Chandran vij...@juniper.net wrote: Hi all, I am wondering if we have a solution to this issue. I need two firewall attached to an interface as input-list. e.g.: f1 and f2. Input-list [f1 f2] f1 to match a condition (all tcp port 80) and accept and count that packet. f2 to classify those packets based on code points and push to a forwarding class. Is this possible? -Thanks, Vijesh If f2 is only matching on code-points, is there any reason you can't just use a class-of-service classifier instead for this functionality? Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls question
Hi James, On 27 Apr 2015, at 5:31 am, james list jameslis...@gmail.com wrote: Hi amarjeet Because if PE1 fails there is faster convergence to PE2 due to neighbor already established. Is there a reason you wouldn't consider using an L3VPN instead of a VPLS? It seems odd to me that you would be using L3 adjacencies to an L2 service. If it really is L2 fail-over you are chasing, then Amarjeet is correct - multihoming and site-preference are designed for exactly this purpose. If you customer requires L3 connectivity across your VPLS, you would be better off carrying their OSPF across the VPLS and let their CEs form adjacencies with each other - that way, you can take care of L2 fail-over, and the customer is responsible for L3. Cheers, Ben Cheers James Il 24/apr/2015 13:23, james list jameslis...@gmail.com ha scritto: I have a VPLS multi-homed environment with two MX routers (PE1 and PE2) connected to a single ethernet switch (CE1). I have PE1 configured with site-preference as primary and PE2 as backup. Behind the CE1 there is a router running OSPF with both MX (on irb interface). My goal is to have: 1)Multihoming to prevent loops 2)Let the router run two OSPF neighbor with both PE and not just one with the primary PE. I’m wondering if using: set routing-instances protocols vpls connectivity-type irb instead of the default (connectivity-type ce) could give me the option to reach my goal number 2) and if I can introduce any drawback. Or if there is another solution keeping 1). I don’t have a lab to test… Any help/feedback is really appreciated. Greetings James ___ 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] SRX550 SRX-GP-8SERIAL
On 15 Apr 2015, at 9:22 am, Herro91 herr...@gmail.com wrote: Hi, Does anyone know how many 8 port serial GPIM's can be installed into an SRX550? http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/gpim-srx-series-overview.html seems to suggest up to 6 can be installed in the available GPIM slots Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Aggregate policer config
On 9 Apr 2015, at 10:22 am, Mark Tees markt...@gmail.com wrote: I would be curious to know if/how the aggregate behaviour works between different line cards/PFE. I was wondering this too, so I did a bit of digging - Page 198 of Doug Hanks' MX Series book suggests it doesn't - quoting: The same filter can be applied to multiple interfaces at the same time. By default on MX Routers, these filters will sum (or aggregate) their counters and policing actions when those interfaces share a PFE. I've only got MX80s here in the lab just now, which I think share a PFE for both FPC 0 and FPC1 - I can apply the same filter/policer to both a 10G and a 1G interface and get the aggregate bandwidth between interfaces to be dictated by the policer. Just to clarify here: set firewall policer POLICER-800M filter-specific set firewall policer POLICER-800M if-exceeding bandwidth-limit 800m set firewall policer POLICER-800M if-exceeding burst-size-limit 10m set firewall policer POLICER-800M then discard This should result in the policer/counter actions being created per the filter they are used in but still shared within that filter providing interface-specific is not used right? Yes, correct, however I suspect that the policer aggregate would again be per PFE. So, back to the OP's question - you *should* be able to use a single filter, provided both your customer's links are on an MPC1 or MPC3E with 1G / 10G MICs. If that's not the case, then stick with the per-interface 800M policer and just apply local-preference to your customers routes as you import them to ensure their traffic is always preferred via the 10G link (while it's up), and use MED/metric to encourage them to use the 10G link for their outbound. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Aggregate policer config
Aggregate policing should be the default behaviour for a *filter*, as long as you don't apply the interface-specific knob. Create a dedicated filter for this customer and apply it to both interfaces. set firewall family any filter CUST-A-800M term POLICE-800M then policer POLICER-800M set firewall family any filter CUST-A-800M term POLICE-800M then accept traffic over either interface will contribute to the filter counter. The policer itself can be generic/re-used by other filters as long as you *include* filter-specific. set firewall policer POLICER-800M filter-specific set firewall policer POLICER-800M if-exceeding bandwidth-limit 800m set firewall policer POLICER-800M if-exceeding burst-size-limit 10m set firewall policer POLICER-800M then discard Cheers, Ben On 8 Apr 2015, at 7:15 am, Matthew Crocker matt...@corp.crocker.com wrote: Hello, A customer with two connections to my mx240. I want to police their total bandwidth to 800mbps. Right now I have a 800mbps policer but that gives them 800mbps on each circuit. Customer Interface 1 is a VLAN on a 10G interface Customer Interface 2 is a VLAN on a 1G interface Each interface has its own /30 IP subnet with a BGP session on each customer IP Customer buys X bandwidth we want to give them X bandwidth over a pair of circuits. If one circuit goes down the policer needs to be set to the X bandwidth the purchased. Thanks -Matt -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 E: matt...@crocker.com P: (413) 746-2760 F: (413) 746-3704 W: http://www.crocker.com ___ 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] EX2200 LLDP Port Info
Hi Bill, On 27 Mar 2015, at 3:16 am, Bill Blackford bblackf...@gmail.com wrote: Seems to be undesired behavior. So, far I have not found anything in the release notes that would indicate a fix. any thoughts on this from the group? What you're seeing on the EX2200 changes from version to version 11.4R7 ignores the description and sends the logical interface name eg: ge-0/1/0.0 12.3R4.6 overrides the interface name with the description eg: Link to switchA - ge-0/0/0 In fact, the behaviour of LLDP from platform to platform across the whole range is pretty inconsistent: MX80 - 14.2R1.9 (shows ifIndex of neighbouring interface): Local InterfaceParent InterfaceChassis Id Port info System Name ge-1/1/2 - 40:b4:f0:49:98:f0 505 ACX1100 ge-1/0/0 ae0 5c:5e:ab:0e:7f:40 516 MX80-B ge-1/1/0 ae0 5c:5e:ab:0e:7f:40 526 MX80-B ge-1/1/5 - 5c:5e:ab:0e:7f:40 531 MX80-B ACX1100 - 12.3something (shows ifIndex of neighbouring interface, and has no Parent interface to identify aggregates) Local Interface Chassis IdPort info System Name ge-0/0/45c:5e:ab:0e:60:30 528 MX80-A ge-0/0/15c:5e:ab:0e:7f:40 517 MX80-B ge-0/0/05c:5e:ab:0e:7f:40 527 MX80-B I seem to recall older versions of MX code (11 or 12) used to send the description field as well. As for why - one example I know of is that there is a provider here that uses LLDP to send through the Circuit ID of their tails via Port Description, which is nice for operations staff on the remote end for ticket logging. Anyway, you can partially resolve this issue with the following: set protocols lldp port-id-subtype interface-name This means that the *sending* LLDP device will now send the interface name in the Port ID field instead of the ifindex. Unfortunately, the show lldp neighbors command will still only show the value of the Port Description field, which will get overridden by the interface description. Instead you'll need to use show lldp neighbours interface ifd to see it. BEFORE: bdale@GD-eng-22c# run show lldp neighbors interface ge-0/1/1.0 ... Neighbour Information: Chassis type : Mac address Chassis ID : b0:a8:6e:8d:5a:40 Port type : Locally assigned Port ID: 527 - Port description : Uplink to GD-eng-22c System name: GD-rck-22c AFTER: bdale@GD-eng-22c# run show lldp neighbors interface ge-0/1/1.0 . Neighbour Information: Chassis type : Mac address Chassis ID : b0:a8:6e:8d:5a:40 Port type : Interface name Port ID: ge-0/1/0 - Port description : Uplink to GD-eng-22c System name: GD-rck-22c To fix this though, I've put together an op script that behaves in a similar manner to show lldp neighbors except that it lists the Port ID field as well: https://github.com/dfex/DFEXjunoscripts/blob/master/show-lldp-neat.slax It works works on the EX22/42 okay, but the EX doesn't seem to support remote execution (eg: op url https://github.com/dfex/DFEXjunoscripts/blob/master/show-lldp-neat.slax) across any of the version I've tried: 11.4R7.5, 12.3R2.5, 12.3R4.6, 12.3R6.6, 13.2X51-D20.2. On the MX under 14.2R1.9, remote execution works, but the script is a bit borked as it seems to be trying to re-use the variable from the previous iteration in for-each - let me know if anyone has an better experiences. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] info VC QFX
Hi James, On 25 Mar 2015, at 1:35 am, james list jameslis...@gmail.com wrote: Hi folks, on QFX VC is there a way to configure VME interface to respond on each module of the VC instead to be redirected on the master RE ? If yes a little configuration example is appreciated. I can't speak for QFX VC, but on EX VC this isn't possible. If you need to get to a specific member (eg: 2), use: request session member 2 Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] next junos versions
On 10 Mar 2015, at 12:49 am, james list jameslis...@gmail.com wrote: Hi is there a way to know the expected delivery date of the next Junos releases ? I'd a look to the path finder but I found nothing You used to be able to set your watch by the four releases a year, now, not so much. The following table shows previous major version release dates (FRS Date). http://www.juniper.net/support/eol/junos.html From 12.x it moved to 3 major releases/year and as of 14.x I believe it's down to two now? Not counting all the Xversion feature releases for the various platforms. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX extended DHCP server static address binding
Hi Misak, I can successfully describe host 089 in Pool1 and it will get predefined IP address, but if I do the same for Pool2 to assign host IP address from that pool, host gets random address from Pool1. My guess is that DHCP server will never consider Pool2 configuration until all Pool1 addresses will be assigned. For me it's a clearly bug in that case. You are correct: http://www.juniper.net/techpubs/en_US/junos13.3/topics/task/configuration/subscriber-management-address-assignment-pool-linking.html linked pools won't be utilised until the primary pool is depleted, so not really a bug, but Please advise how I can assign IP address from Pool2 to host. Juniper MX480, JunOS 14.2R1.9 I don't think this is possible - if you move the host definition into Pool1 with it's correct IP address, it'll fail the network range bounds check. The only option I can see would be defining a network range that covers both Pools (if this is even possible) inside Pool1, then configure two separate range definitions inside that to cover your current address ranges. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX High-end Packet mode
Hi Mahmoud, On 18 Dec 2014, at 3:34 am, M Abdeljawad via juniper-nsp juniper-nsp@puck.nether.net wrote: I have three questions about packet mode on high-end SRX firewalls - Is it supported on SRX high-end firewalls to switch the firewall to packet mode altogether using the below command which supported on branch firewalls;(set security forwarding-options family mpls mode packet-based) Feature navigator seems to suggest they can support packet-based for IPv6 [1] (not MPLS) in 12.1X44, but the SRX Series Book (older) suggest packet-mode is branch-only [2]. - Is it supported on SRX high-end firewalls to partially convert some traffic to packet mode (selective packet forwarding using filters)? I don't believe so - Is it possible to operate MPLS on SRX high-end firewalls without enabling packet-mode? No Cheers, Ben [1] http://pathfinder.juniper.net/feature-explorer/ [2] https://books.google.com.au/books?id=2HSLsTJIgEQCpg=PA163lpg=PA163dq=srx+packet-mode+mplssource=blots=_fxiZyPIytsig=tIuoDMgJWzpRyHCiIXyMKU-KNdohl=ensa=Xei=tgqSVLDtIMv08QX9yIHACwved=0CCIQ6AEwATgK#v=onepageq=srx%20packet-mode%20mplsf=false ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Transfer some task from MX to VRR
On 2 Dec 2014, at 12:41 am, Robert Hass robh...@gmail.com wrote: I think vMX can forward data. vMX indeed will be full-featured router. But my questions was related to move part of control-plane (basically whole BGP part of rpd) to external server. Maybe OpenFlow somehow helps here ? How openflow take care of eBGP to customers ? Session should be on router or on OpenFlow controller ? OF v1.3 just has been implemented in JunOS 14.x releases for MX series. This is completely doable without the need for Openflow. The vMX is delivered as two VMs - a vRE and vPFE and logically they communicate in the same way as the RE and PFE do in an MX today eg: an internal ethernet switch sends control-plane information down to the forwarding engine. Whether this happens on a single host machine across a vSwitch, or across a physical network is now completely irrelevant, normal constraints not withstanding (congestion/loss etc). It's not a big stretch to imagine being able to one day ditch the vPFE and take a bunch of head-less MXs (hardware-based) acting as remote FPCs to a pair of centralised vREs - like JCS/TXM but on more commoditised server hardware, or even a Q-Fabric with MXs as nodes and commodity directors/interconnect. Given that control-plane traffic is pretty minimal, and with all the cool FIB localisation knobs coming down in 14.x, the scaling/design implications of this get pretty interesting. Heck - it should be possible to one day take the much-maligned MX80 RE and replace it with a remote intel-based monster, and get 64-bit Junos in the mix. Emulating the backplane for inter-FPC traffic is going to be a barrel of fun though! Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best design can fit DC to DC
I recommend you take a good long look at E-VPN: http://www.juniper.net/documentation/en_US/junos13.2/topics/concept/evpns-overview.html https://conference.apnic.net/data/37/2014-02-24-apricot-evpn-presentation_1393283550.pdf http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/whitepaper_c11-731864.html It is supported in one form or another on MXs, ASRs and ALU boxes and presents P2MP services just like a VPLS, only with control-plane based MAC learning, active/active multi-homing and a bunch of other goodness which will probably spell the end for OTV (which under the hood is essentially MPLS over GRE with some smarts), and maybe even replace VPLS and L2VPN/EoMPLS longer term. OTV limits you to a single platform (N7K only last I looked) from a single vendor and you have to anchor your tunnels on your Data Centre switch. Now your interconnect is tied to your DC fabric. How inconvenient. Stretching L2 domains over 1000km of wouldn't be my first suggestion either. I've had a bit of a play with VCF and it seems to work as advertised, but be aware of mixed-mode limitations if you need to bring in lots of 1GE ports (eg: EX4300) - they don't support TISSU. Putting 1GE SFPs into a QFX5100 is a slightly more expensive workaround though. Ben On 5 Nov 2014, at 12:06 pm, Oliver Garraux oli...@g.garraux.net wrote: I don't think L2 extension is a good idea, but if you have to, OTV is the way to do it IMO. Particularly since you have to support non virtualized infrastructure, and may have 2 sites in the future. OTV isn't going to have sub-second convergence (though I think it might support BFD in the future?) 35km isn't too bad latency wise. 1000km will be much trickier. Things like storage replication will be more difficult. And while OTV can easily isolate FHRP's to send outbound traffic out the local default gateway, traffic tromboning with inbound traffic might be an issue. (If inbound traffic is routed to the wrong data center, the extra latency from having to go across 1000km to get to the datacenter where the box actually is will suck). I think LISP in theory could help with this, but would involve changes to how traffic gets *to* your data centers. Also, in general don't overlook the integration of storage / network / system stuff. IE, if you lose all the links between the data centers, storage / networking / systems all need to fail over to the same place. If you can, do lots of disruptive testing before going into production. A previous organization I've been with discovered (and fixed) many issues with L2 extension through pre-production testing of everything. Oliver - Oliver Garraux Check out my blog: blog.garraux.net Follow me on Twitter: twitter.com/olivergarraux On Fri, Oct 31, 2014 at 9:41 AM, R LAS dim0...@hotmail.com wrote: Hi all a customer of mine is thinking to renew DC infrastructure and interconnection among the main (DC1) and secondary (DC2), with the possibility in the future to add another (DC3). Main goal are: sub-second convergence in case of a single fault of any component among DC1 and DC2 (not DC3), to have the possibility to extend L2 and L3 among DCs, to provide STP isolation among DCs, to provide ports on the server at eth 1/10Gbs speed. DC1 and DC2 are 35 km away, DC3 around 1000 km away from DC1 and DC2. Customer would like to design using Cisco or Juniper and at the end to decide. Talking about Juniper my idea was to build and MPLS interconnection with MX240 or MX104 in VC among DC1 and DC2 (tomorrow will be easy to add DC3) and to use QFX in a virtual chassis fabric configuration. Does anybody have these kind of config ? Is it stable QFX ? Any other suggestion/improvement ? And if you would go with Cisco, what do you propose in this scenario ? Rgds ___ 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] BRAS IPv4/IPv6 Combined Policer RADIUS Attributes
Hi Darren,
Our requirement is per below. For example, the bandwidth package is 5Mbps.
The IPv4 IPv6 should be policed jointly to bandwidth of 5Mbps rather than
individual IPv4 or IPv6 family policing. If policing is done individually
for IPv4 (5Mbps) and for IPv6 (5Mbps), the user is getting bandwidth of
10Mbps jointly which we tried to avoid.
Modify your PPPoE template so that you're applying the filter under
$junos-interface-unit rather than the address family:
PPPOE-IP-PROFILE {
interfaces {
pp0 {
unit $junos-interface-unit {
ppp-options {
pap;
}
pppoe-options {
underlying-interface $junos-underlying-interface;
server;
}
filter {
input 5m;
output 5m;
}
family inet {
unnumbered-address $junos-loopback-interface;
}
family inet6 {
unnumbered-address $junos-loopback-interface;
}
}
}
}
}
That will police regardless of the underlying address family.
Cheers,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] controlling the source IP for the Dns Proxy feature
Hi Andy,
I have come across this exact issue using the feature.
There was a good reason why we didn't use default address selection that
escapes me just now, but I had a slight advantage in that I was using
route-based VPNs, so I was able to number the st0 interface with a /32 from the
corporate range and source my queries from there.
Unfortunately policy-based VPNs are extremely limiting when it comes to things
like this. I can't think of too many scenarios where I'd even use them any
more. If you don't have too many sites, I'd seriously consider migrating them
across.
Cheers,
Ben
On 16 Oct 2014, at 1:28 am, Andy Litzinger andy.litzinger.li...@gmail.com
wrote:
Hello,
is anyone out there using the dns-proxy feature for the branch SRX? Are
there any clever tricks for specifying the source address the SRX uses to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can solve my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust zone.
users sit on the trust zone and receive dhcp from the SRX and use the SRX
as their default gateway and dns server. There is a policy based vpn that
connects from the untrust zone to our corp HQ. I have the dns-proxy config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
interface facing users;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
corp hq name server1;
corp hq name server 2;
}
}
}
the problem is without the 'default address selection' set the SRX tries to
use the untrust interface IP as the source IP to query our corp HQ name
servers, but the traffic doesn't enter the tunnel because it doesn't match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is junos-host- is it possible maybe to set up
a junos-host zone to untrust zone NAT when going to corp-hq IP space?
or is there another clever solution?
thanks!
-andy
___
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] controlling the source IP for the Dns Proxy feature
I've certainly had no issue with stability using route-based VPN.
As far as multiple subnet (proxy-id / traffic selectors) support, as of
12.1X46-D10 this is now native in Junos -
http://kb.juniper.net/InfoCenter/index?page=contentid=KB28820
and is dead simple to configure.
If you're a little gun shy on 12.1X code and are still running old-faithful
builds like 11.4RLate, then there are a couple of options:
- If your subnets are contiguous, just widen the mask to include them in a
single crypto-map on the Cisco side (even if that means widening the mask a LOT)
- If your subnets are arbitrarily selected from different RFC1918 blocks
(DOH!), then create separate P2 bindings for each subnet:
http://kb.juniper.net/InfoCenter/index?page=contentid=KB20543
just be aware that this will only work if the multiple subnets are on the Cisco
side (which seems to be true in your case)
There are a few other hacks out there using FBF as well. J-NET has some good
material:
http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on-route-based-VPN-with-multiple-local/td-p/172002/page/2
Cheers,
Ben
On 16 Oct 2014, at 8:35 am, Andy Litzinger andy.litzin...@theplatform.com
wrote:
I'd happily use route-based vpns if they are supported in my use case.
Based on Kbs and internet lore, it seemed policy based was the best bet
for stability.
My two tunnel endpoint devices are the SRX and a Cisco ASA.
On the SRX side I've got a single subnet but on the ASA side I've got two
subnets. I would happily use a simple policy on the ASA side like 'permit
ip any SRX side IP subnet SRX side mask' if i was confident I wasn't
going to have squirrely issues with connectivity.
What do you think?
-andy
On 10/15/14 3:22 PM, Ben Dale bd...@comlinx.com.au wrote:
Hi Andy,
I have come across this exact issue using the feature.
There was a good reason why we didn't use default address selection that
escapes me just now, but I had a slight advantage in that I was using
route-based VPNs, so I was able to number the st0 interface with a /32
from the corporate range and source my queries from there.
Unfortunately policy-based VPNs are extremely limiting when it comes to
things like this. I can't think of too many scenarios where I'd even use
them any more. If you don't have too many sites, I'd seriously consider
migrating them across.
Cheers,
Ben
On 16 Oct 2014, at 1:28 am, Andy Litzinger
andy.litzinger.li...@gmail.com wrote:
Hello,
is anyone out there using the dns-proxy feature for the branch SRX? Are
there any clever tricks for specifying the source address the SRX uses
to
query name servers? It does not appear to be a config option.
with the default config it appears to use the IP of the outbound
interface. If I add the config statement 'set system default address
selection' i can influence it to use the lo0.0 address, which can solve
my
issue, but not in a way i prefer.
my exact problem is the following:
I have an SRX 220H in a remote office. It has an trust and untrust zone.
users sit on the trust zone and receive dhcp from the SRX and use the
SRX
as their default gateway and dns server. There is a policy based vpn
that
connects from the untrust zone to our corp HQ. I have the dns-proxy
config
set up so that if a dns request is going to an intranet zone, e.g.
corp.example.com, then it should use DNS servers that live across the
tunnel in our corp HQ. If they are looking up anything else, they use
google dns servers.
here's the relevant config:
dns-proxy {
interface {
interface facing users;
}
default-domain * {
forwarders {
8.8.8.8;
8.8.4.4;
}
}
default-domain corp.example.com {
forwarders {
corp hq name server1;
corp hq name server 2;
}
}
}
the problem is without the 'default address selection' set the SRX
tries to
use the untrust interface IP as the source IP to query our corp HQ name
servers, but the traffic doesn't enter the tunnel because it doesn't
match
the vpn policy. And I can't change the policy to allow it because the
untrust interface IP is the endpoint of the tunnel. It looks like the
source zone of the dns query is junos-host- is it possible maybe to set
up
a junos-host zone to untrust zone NAT when going to corp-hq IP space?
or is there another clever solution?
thanks!
-andy
___
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] EX4200 VC Cabling
I've never had any issues doing it either way. It'll auto-detect the topology, even if you have only a single link. What I have seen though is a bunch of units (at least a couple of months back) coming out of the factory booting form the backup image (like the build image was corrupt), so it may have nothing to do with your VC build at all. Just upgrade to JTAC preferred, snapshot all members (and read a long novel while you wait for that to finish) and then reboot the whole chassis. On 1 Oct 2014, at 9:23 am, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Hi all, We're doing a bunch of 2 x EX4200 in VC. Once we connect the VC cables, one of the Junos seems to be corrupted. We're currently using the ring X cabling.. but I have seen another option for a 2 member stack of | | Anyone got any thoughts? * ** ** ** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE ** ** ** ** It is possible that the primary copy of JUNOS failed to boot up ** ** properly, and so this device has booted from the backup copy.** ** ** ** Please re-install JUNOS to recover the primary copy in case ** ** it has been corrupted and if auto-snapshot feature is not** ** enabled. ** ** ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering ___ 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] BGP Peer formatting
On 10 Sep 2014, at 11:32 am, Ben Dale bd...@comlinx.com.au wrote: Failing that, I just hacked up an op script to only show a summarised version from each peer - output here: https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.md Code here: https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax The script *should* sum all the prefixes from each RIB into a single summarised number per peer, but I haven't had a chance to test it too thoroughly yet. Feedback/Pull Requests welcome. Okay, looks like I managed to upload an incomplete non-working script instead of the one I was actually testing on my router. Thanks to those who pointed this out! Corrected version is now up on Github - tested on SRX, ACX and MX (all single RE) Hey Phil, when can we have git native in Junos?! ; ) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP Peer formatting
On 23 Sep 2014, at 5:57 am, Eugeniu Patrascu eu...@imacandi.netmailto:eu...@imacandi.net wrote: On Mon, Sep 22, 2014 at 4:24 PM, Phil Shafer p...@juniper.netmailto:p...@juniper.net wrote: Ben Dale writes: https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax Very cool! Hey Phil, when can we have git native in Junos?! ; ) How about: op url https://raw.githubusercontent.com/dfex/DFEXjunoscripts/master/show-bgp-neat.slax --- JUNOS 12.1X44-D35.5 built 2014-05-19 22:11:33 UTC op url https://raw.githubusercontent.com/dfex/DFEXjunoscripts/master/show-bgp-neat.slax error: ^ error: /var/tmp/tmp_opzhxmSf/...transferring.file.DdJl9A/show-bgp-neat.slax:35: error: /var/tmp/tmp_opzhxmSf/...transferring.file.DdJl9A/show-bgp-neat.slax:34: parse error, unexpected T_BARE before 'set': SNIP Okay, one small caveat to this script - it looks like the use of mutable variables (mvar and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's actually not going to work on older versions of Junos. I know 11.4 is the trusted choice for most people on MX at the moment, so when I get some time I'll attempt a mind-bending re-write using the older immutable var format. Stay tuned, and thanks again for all the direct feedback! Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP Peer formatting
On 23 Sep 2014, at 1:48 pm, Phil Shafer p...@juniper.net wrote:
Ben Dale writes:
Okay, one small caveat to this script - it looks like the use of mutable
variables (mvar
and set) was only introduced in SLAX 1.1 / Junos 12.2, so it's actually not
going to wo
rk on older versions of Junos.
I know 11.4 is the trusted choice for most people on MX at the moment, so
when I get som
e time I'll attempt a mind-bending re-write using the older immutable var
format.
In this case, you don't need the mvars. Let sum() do the iteration:
for-each ($neighbour-list/bgp-peer) {
output jcs:printf(%-20s%-15s%-12s%-10s%-10s%-10s%-10s%-5s,
peer-address,
peer-as,
peer-state,
elapsed-time,
sum(bgp-rib/active-prefix-count),
sum(bgp-rib/received-prefix-count),
sum(bgp-rib/accepted-prefix-count),
description);
}
Thanks,
Phil
Love your work Phil : )
That's a heck of a lot simpler/cleaner than the recursive monstrosity I've been
putting together!
Changes have been pulled into github, so if you're running 11.4 or earlier,
give it another try now.
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX9200 DHCP Relay
SELECTING means that an OFFER has been sent to the client (or at least the
switch thinks it has relayed it), but the REQUEST hasn't come back from the
client.
I have seen this in some instances where the client is expecting a Unicast
reply from the relay agent rather than a broadcast or vice-versa - fix with:
set forwarding-options dhcp-relay overrides layer2-unicast-replies
Nice tip on the route-suppression statement William - that one has been
annoying me for a while with JDHCPd on the SRX...
Cheers,
Ben
On 19 Sep 2014, at 12:01 am, Chris Jones ch...@sdnessentials.com wrote:
My DHCP clients are all stuck in SELECTING state. Has anyone ever seen that,
or maybe know what causes it?
root@DVT-EX9200 show dhcp relay binding
IP addressSession Id Hardware address Expires State
Interface
0.0.0.0 18 00:25:90:3d:76:34 0 SELECTING irb.30
0.0.0.0 19 00:25:90:3d:e5:13 0 SELECTING irb.30
0.0.0.0 17 00:25:90:6d:f0:c3 0 SELECTING irb.30
0.0.0.0 23 d4:be:d9:95:b6:4f 0 SELECTING irb.16
On Sep 16, 2014, at 3:13 PM, William McLendon wimcl...@gmail.com wrote:
this is a working DHCP config on EX9200s — make sure you include the
forward-snooped-clients all-interfaces statement, or any transit DHCP packet
that traverses an interface without DHCP relay configured will be eaten by
the EX9200 — its the most asinine thing in the world to have (a carryover
from MX some sort of DHCP security i’m sure), but its completely
undocumented it does this from what i’ve seen.
dhcp-relay {
forward-snooped-clients all-interfaces;
server-group {
CAMPUS {
192.168.168.168;
}
}
active-server-group CAMPUS;
route-suppression {
destination;
}
group LOCAL-NETS {
interface ge-5/0/0.304;
interface irb.9;
}
}
}
the route-suppression destination statement also prevents it from installing
access-internal host routes and permanent ARP entries for every DHCP lease.
will
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Chris Jones, JNCIE-ENT #272 / JNCIP-SP
SDN Engineer
www.sdnessentials.com
Cell: 858-888-0373
E-Mail: ch...@sdnessentials.com
___
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] VPN into M7i
No Panny, the only VPN support on M-Series is IPSEC. I would recommend a 3rd-party client like Shrewsoft On 17 Sep 2014, at 8:55 pm, Panny Malialis pa...@hotlinks.uk wrote: Hello, I'm looking for a simple example of a VPN into a Junos device with an ASII pic from a Mac or PC (L2TP/PPTP) but can't seem to find anything? Is this even possible? Many Thanks Panny Malialis ___ 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] BGP Peer formatting
On 10 Sep 2014, at 7:54 am, Scott Harvanek scott.harva...@login.com wrote: This is a silly/OCD question; I've faced this before and I can't recall how it was prettied up... If I recall there is a way to pretty up the formatting of show bgp summary; Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... XXX.XXX.XXX.XXX X4463666 120866 0 0 5w3d 9:31:20 Establ inet.0: 272410/510233/510233/0 To remove the line break / fix the table formatting. I've tried adjusting screen-width with no joy. Halp? There's a few ways to neaten it, but it's a case of which information you can live without: show bgp summary | except inet show bgp group summary | match l: Failing that, I just hacked up an op script to only show a summarised version from each peer - output here: https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.md Code here: https://github.com/dfex/DFEXjunoscripts/blob/master/show-bgp-neat.slax The script *should* sum all the prefixes from each RIB into a single summarised number per peer, but I haven't had a chance to test it too thoroughly yet. Feedback/Pull Requests welcome. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] rpm / ip-monitoring
Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link is a to an IP-VPN running BGP to the mpls cloud of a global operator. So, from there I get a default that I override with a static OR dynamic default to a local Internet connection that also serves as backup via IPsec (BGP on top of that too but peers with a HUB node and not the cloud). As the local internet is just a cheap line, I do not have the luxury of BGP and so must use some other metod like this one. What I would have want is to have the ip-monitor not actually disable the interface and just set the admin-distance for it to the worst level. That way the test would still work as it requests the packet be sent by the exact interface, but no other traffic would take this route unless all other options are down. //Mattias On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor darre...@outlook.commailto:darre...@outlook.com wrote: A small topology diagram would help so we could figure out exactly what this interface points to. Not sure if its in the path or not. If it is, then the below comments already state what the problem is. Thanks Darren http://www.mellowd.co.uk/ccie Date: Wed, 27 Aug 2014 17:52:02 -0700 From: gonna...@gmail.commailto:gonna...@gmail.com To: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] rpm / ip-monitoring Instead of disabling the interface, can you just alter routing to avoid that path, but RPM could still test since that interface would still be up? -Mike Gonnason On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen ty...@adap.tvmailto:ty...@adap.tv wrote: Good point. I glossed over that a bit. In that case, you won't even be able to test if it's working or not as you have disabled it (as Andrew points out). I suppose you could write a script that re-enables the interface every hour or twenty four hours or whatever interval, then the RPM probe would just shut it back down if it's not fixing, but that seems a bit of a hassle. --tc On Wed, Aug 27, 2014 at 4:35 PM, Andrew Jones a...@jonesy.com.aumailto:a...@jonesy.com.au wrote: Surely the test will never recover without
Re: [j-nsp] rpm / ip-monitoring
Okay, I'm still sure this can be made to work ; ) I'm still a little hazy on your setup though - based on your email: You have a local line which gets an address via DHCP and a default gateway with a preference of 12 You then also receive another default via BGP over an IPSEC tunnel over this same local line interface with a preference of 170 You then have an MPLS service/Native VPN which receives another BGP-sourced default route, presumably also with a preference of 170 If that is the case, configure a static with high preference (170) pointing to your MPLS service/Native VPN, and override this with the lower preference route via your ip-monitoring policy on local-line/Internet failure - it should still work exactly as described, unless I'm missing something else? Ben On 29 Aug 2014, at 7:42 pm, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: Ben Close but no cigar. The IPsec also receives a default via BGP so that works like a charm. No need for interface routing. The thing is that we use the local line for Internet use, so the primary default route goes out that way. The IPsec is there if the Native VPN line fails. So, what I want this ip-monitor/rpm to do is fail over the local internet to the Native VPN in case the local line is broken some how. Regards Mattias On Fri, Aug 29, 2014 at 12:59 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Hi Mattias, It is still possible to bend it to your will ; ) I may be misunderstanding your topology, but essentially you have a Primary link via a WAN circuit that receives a BGP-sourced default, and a backup ADSL connection that receives a default via DHCP/PPP, and has an IPSEC tunnel back to your head office. Are you trying to move the default route to your IPSEC tunnel interface, or the underlying cheap line? You could try the following: Set up a static default with a high metric (so that it will lose to both DHCP and BGP) via your IPSEC tunnel/underlying link. If the underlying link is not point-to-point (eg: you will need to know the far-side IP), you can point it down your IPSEC tunnel, or anywhere else - it should never actually get used): set routing-options static route 0.0.0.0/0http://0.0.0.0/0 next-hop at-1/0/0.0 set routing-options static route 0.0.0.0/0http://0.0.0.0/0 preference 190 Then in your ip-monitoring policy, you can override this dummy route with a better metric than both BGP and DHCP: set services ip-monitoring policy Local-Internet-Test match rpm-probe Internet set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0http://0.0.0.0/0 next-hop at-1/0/0.0 set services ip-monitoring policy Local-Internet-Test then preferred-route route 0.0.0.0/0http://0.0.0.0/0 preferred-metric 1 Now when your test fails (even if BGP does not): inet.0: 49 destinations, 51 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0http://0.0.0.0/0 *[Static/1] 00:13:15, metric2 0 via at-1/0/0.0 [Access-Internal/12] 00:21:45 to 192.168.1.2 via at-1/0/0.0 [BGP/170] 2d 21:51:10, localpref 100 AS path: 65500 I, validation-state: unverified to 172.30.3.2 via ge-0/0/3.0 Cheers, Ben On 29 Aug 2014, at 3:30 am, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: Even is the default routes are both from dynamic protocols (BGP and DHCP). For a regular static this is perfect. No such luck in this sollution. //Mattias On Thu, Aug 28, 2014 at 4:17 PM, Ben Dale bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote: Rather than making configuration changes, if you're running recent code (12.1) on branch SRX, have a look at the preferred-route option in ip-monitoring. You can override your default route dynamically based on the RPM failing, without having to override config. The day this is feature (and ip-monitoring in general) is merged back down to mainline Junos will be a glorious one... Cheers, Ben On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.semailto:matt...@gyllenvarg.se wrote: I have looked over these and they are the basis of the configuration I am using. The setup is advanced in some senses. The Primary link is a to an IP-VPN running BGP to the mpls cloud of a global operator. So, from there I get a default that I override with a static OR dynamic default to a local Internet connection that also serves as backup via IPsec (BGP on top of that too but peers with a HUB node and not the cloud). As the local internet is just a cheap line, I do not have the luxury of BGP and so must use some other metod like this one. What I would have want is to have the ip-monitor not actually disable the interface and just set the admin-distance for it to the worst level. That way the test would still work
Re: [j-nsp] rpm / ip-monitoring
Rather than making configuration changes, if you're running recent code (12.1)
on branch SRX, have a look at the preferred-route option in ip-monitoring.
You can override your default route dynamically based on the RPM failing,
without having to override config.
The day this is feature (and ip-monitoring in general) is merged back down to
mainline Junos will be a glorious one...
Cheers,
Ben
On 28 Aug 2014, at 9:00 pm, Mattias Gyllenvarg matt...@gyllenvarg.se wrote:
I have looked over these and they are the basis of the configuration I am
using.
The setup is advanced in some senses.
The Primary link is a to an IP-VPN running BGP to the mpls cloud of a
global operator.
So, from there I get a default that I override with a static OR dynamic
default to a local Internet connection that also serves as backup via IPsec
(BGP on top of that too but peers with a HUB node and not the cloud).
As the local internet is just a cheap line, I do not have the luxury of BGP
and so must use some other metod like this one.
What I would have want is to have the ip-monitor not actually disable the
interface and just set the admin-distance for it to the worst level.
That way the test would still work as it requests the packet be sent by the
exact interface, but no other traffic would take this route unless all
other options are down.
//Mattias
On Thu, Aug 28, 2014 at 10:50 AM, Darren O'Connor darre...@outlook.com
wrote:
A small topology diagram would help so we could figure out exactly what
this interface points to. Not sure if its in the path or not. If it is,
then the below comments already state what the problem is.
Thanks
Darren
http://www.mellowd.co.uk/ccie
Date: Wed, 27 Aug 2014 17:52:02 -0700
From: gonna...@gmail.com
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] rpm / ip-monitoring
Instead of disabling the interface, can you just alter routing to avoid
that path, but RPM could still test since that interface would still be
up?
-Mike Gonnason
On Wed, Aug 27, 2014 at 5:37 PM, Tyler Christiansen ty...@adap.tv
wrote:
Good point. I glossed over that a bit.
In that case, you won't even be able to test if it's working or not as
you
have disabled it (as Andrew points out). I suppose you could write a
script that re-enables the interface every hour or twenty four hours or
whatever interval, then the RPM probe would just shut it back down if
it's
not fixing, but that seems a bit of a hassle.
--tc
On Wed, Aug 27, 2014 at 4:35 PM, Andrew Jones a...@jonesy.com.au
wrote:
Surely the test will never recover without intervention, as the
interface
it uses gets disabled?
On 28.08.2014 02:28, Tyler Christiansen wrote:
I could be mistaken, but I believe it automatically reverts when the
test
is successful unless you specify no-preempt.
On Wed, Aug 27, 2014 at 12:50 AM, Mattias Gyllenvarg
matt...@gyllenvarg.se
wrote:
Dear List
I have a rpm /ip-monitor setup that is supposed to test the
function
of a
local internet line (ping internet destination).
And disable it if it is not responding.
This works fine BUT, how do I get it to re-enable when it is
working
again.
I need this to work with DHCP so I cannot work with a default
route.
**
services {
rpm {
probe Internet {
test PING-GOOGLE-DNS {
target address 8.8.8.8;
probe-count 5;
probe-interval 2;
test-interval 20;
thresholds {
total-loss 4;
}
destination-interface fe-0/0/3.0;
}
}
}
ip-monitoring {
policy Local-Internet-Test {
match {
rpm-probe Internet;
}
then {
interface fe-0/0/3 {
disable;
}
}
}
}
}
*
--
*Med Vänliga Hälsningar / Best Regards*
*Mattias Gyllenvarg*
___
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
--
*Tyler Christiansen | Technical Operations*
tyler http://adap.tv/@adap.tv http://adap.tv/ | www.adap.tv
*m :* 864.346.4095
___
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
Re: [j-nsp] Viability of EX4300 in a primarily l3 environment?
I believe this to be the case as well - when you run a mixed-mode virtual chassis (45/42) you end up moving the entire chassis to the lowest common denominator (45xx) and reducing your ARP table size down to 8K along with associated routing entries . There's a nice side-by-side of the whole range here: http://www.juniper.net/fragment.do?xmlPath=/cn/zh/products-services/switching/ex-series/modules/product-comparison.xmlxslPath=/shared/xsl/product-compare/compare.xslcompPP=trueheight=300 Ben On 7 Aug 2014, at 3:07 am, Tyler Christiansen ty...@adap.tv wrote: On Wed, Aug 6, 2014 at 6:59 AM, Paul S. cont...@winterei.se wrote: That lower arp limit is precisely why we're looking at the 4300, though. Which, by the way, does anyone happen to know if the arp limit stays the same when the 4200s are put into VC mode -- or do they increase at all? I believe ARP is handled by the RE, so in a virtual chassis, the ARP limit would be the same. I could be wrong, though. --tc On 8/6/2014 午後 10:31, Scott Granados wrote: +1 on the 4200. Had very good luck with the 4200 series. Also had good luck with the 4300 but there were some bugs. In a basic operation mode though they are quite stable. That being said I was really pleased with the 4200 and you might want to check them out assuming the lower arp limit isn’t an issue. On Aug 6, 2014, at 7:30 AM, Yucong Sun sunyuc...@gmail.com wrote: I used ex4200 to do exactly what you did before. ex4200 releases is pretty rock solid, feature extensive, although with lower arp entry limits. Given the price difference maybe you can connect each l2 domain to its own ex4200 and have them do ospf routing among selves, which maybe give you better failure tolerances compare to a single core. On Wed, Aug 6, 2014 at 6:35 PM, Giuliano Cardozo Medalha giuli...@wztech.com.br wrote: we are using ex4300 with the last release available the setup is pretty simple using virtual chassis, lag, L3 and poe it works pretty fine and we do not have any serious problems sometimes the poe controller goes down but we have a case oppened in jtac to try solve it Sent from my iPhone On 06/08/2014, at 07:15, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: * Paul S. cont...@winterei.se [2014-08-02 05:18]: Hi folks, We're considering the EX4300 to run routing (l3) for a few hypervisors of ours that are connected via l2. Primarily interested due to the rather massive arp limit (64, 000) on the switch, but we've been told (and searched for ourselves to find out) that the 4300 platform has been plagued by random issues since launch. I don't have hands-on experience but I looked at the EX4300 platform for a new deployment. If you look at the current release notes: http://www.juniper.net/techpubs/en_US/junos13.2/ information-products/topic-collections/ex-qfx-series/ release-notes/ex-qfx-series-junos-release-notes-13.2X51-D25.pdf There are a lot of (serious) bugs still getting fixed so I'm not sure how mature this platform is. One big reason for that is probably because EX4300 uses other chips than the rest of the 4xxx series (Broadcom). Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ 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 -- *Tyler Christiansen | Technical Operations* tyler http://adap.tv/@adap.tv http://adap.tv/ | www.adap.tv *m :* 864.346.4095 ___ 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] config msti vlan range?
Hi Victor, It's pretty straightforward: set protocols mstp msti 5 vlan [10-50 60-90] Cheers, Ben On 22 Jul 2014, at 1:22 pm, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, I have now the following configuration: admin@sw-km270# show protocols mstp msti 2 vlan [ management ENERGY NATEKS PASOLINK-Management MNCS ITSO ]; How do I replace the explicit list of vlans with a range like 10500 ? What's the configuration command syntax? I suppose it's a general Junos syntax question (using ranges of values) but somehow I cannot find the obvious. Thanks a lot for helping. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Could you pls clarify a bit about OAM for link fault management?
Hi Victor, Something like this should do the trick once you've configured it on both ends: set protocols oam ethernet link-fault-management action-profile UDLD event link-adjacency-loss set protocols oam ethernet link-fault-management action-profile UDLD action syslog set protocols oam ethernet link-fault-management action-profile UDLD action link-down set protocols oam ethernet link-fault-management interface ge-0/0/23.0 apply-action-profile UDLD We had a similar issue to solve at some sites connected via Free-Space Optics units. Cheers, Ben On 11 Jul 2014, at 12:45 pm, Victor Sudakov v...@mpeks.tomsk.su wrote: Colleagues, I have pairs of EX4200 switches connected via third party MUXes. When the actual physical medium goes down, the MUXes do not shutdown their Ethernet interfaces. So I need some sort of point-to-point L2 link fault management between the EX4200s. I thought OAM could be used for this purpose. However after reading http://www.juniper.net/techpubs/en_US/junos9.4/topics/task/configuration/lfm-ethernet-oam-configuring-ex-series-cli.html and references therein I am a bit confused. I don't need those remote-loopback and allow-remote-loopback features, profiles and other complicated stuff, do I? All I need from OAM is some kind of L2 keepalive. Do you have a good configuration example? Thanks a lot for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] warning: dhcp-service subsystem not running - not needed by configuration
Hi Victor,
There are actually two completely different DHCP daemons in Junos now - dhcpd
and jdhcpd.
When you configure statements under system / services / dhcp you are using
dhcpd and will need to use:
show system services dhcp server binding
restart dhcp
When you configure statements under system / services / dhcp-local-server you
are affecting jdhcpd and need to use:
show dhcp server binding
restart dhcp-service
The two are mutually exclusive (for obvious reasons).
Cheers,
Ben
On 7 Jul 2014, at 8:32 pm, Victor Sudakov v...@mpeks.tomsk.su wrote:
Dave Bell wrote:
As per
http://forums.juniper.net/t5/Ethernet-Switching/DHCP-service/td-p/14917
try running
'restart dhcp gracefully'
I have tried that, makes no difference:
admin@sw-km337 restart dhcp gracefully
Dynamic Host Configuration Protocol process started, pid 65064
{master:0}
admin@sw-km337 show dhcp server binding
warning: dhcp-service subsystem not running - not needed by configuration.
{master:0}
admin@sw-km337
From /var/log/messages:
Jul 7 17:29:30 sw-km337 mgd[65061]: UI_RESTART_EVENT: User 'admin'
restarting daemon 'Dynamic Host Configuration Protocol process'
Jul 7 17:29:30 sw-km337 init: dhcp (PID 65062) exited with status=0 Normal
Exit
Jul 7 17:29:30 sw-km337 init: dhcp (PID 65064) started
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
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] SRX FBR and destination nat
Hi Yuriy,
This exact configuration is documented quite thoroughly in Recipe 12 in the Day
One: Juniper Ambassadors' Cookbook for Enterprise found here:
http://www.juniper.net/us/en/community/junos/training-certification/day-one/networking-technologies-series/cookbook-for-enterprise/
Credit for this particular one (and the 5 different solutions provided!) goes
to Peter Klimai!
Cheers,
Ben
On 26 Jun 2014, at 11:39 pm, Yuriy B. Borysov yokod...@yokodzun.kiev.ua wrote:
Hello!
I have two connections to the ISP on SRX220H (12.1X45-D15.5).
ISP1 - 1.1.1.2 on my side, 1.1.1.1 - gw (int pp0.0)
ISP2 - 2.2.2.2 on my side, 2.2.2.1 - gw (int pp0.1)
Default gateway looks in to pp0.1
I need to do destination nat to host in lan PC (10.121.0.101) via non
default ISP1 (int pp0.0).
First of all, configure FBR for LAN network via pp0.0:
routing-options
interface-routes {
rib-group inet all;
}
.
rib-groups {
all {
import-rib [ inet.0 cat.inet.0 ];
}
.
cat {
instance-type forwarding;
routing-options {
static {
route 0.0.0.0/0 next-hop pp0.0;
}
}
}
..
firewall family inet filter cat
term route-to-cat {
from {
source-address {
10.121.0.0/24;
}
}
then {
routing-instance cat;
}
}
term default {
then accept;
}
.
interfaces ge-0/0/0.99
description cctv;
vlan-id 99;
family inet {
mtu 1500;
filter {
input cat;
}
address 10.121.0.200/24;
}
.
security policies from-zone cctv to-zone untrust
policy proxmox-inet {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
security policies from-zone untrust to-zone cctv
policy cctv-access {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
Everything looks OK, outgoing traffic goes via pp0.0
After that, configure dest nat:
pool cctv-rdr {
address 10.121.0.101/32;
}
rule-set cctv-rdr {
from interface pp0.0;
rule cctv-rdr {
match {
destination-address 1.1.1.2/32;
}
then {
destination-nat {
pool {
cctv-rdr;
}
}
}
}
}
Traffic comes through pp0.0 but returns through pp0.1
That breaks port forward (due to uplink urpf).
Where I'm wrong in my configuration?
Thanks!
--
WBR, Yuriy B. Borysov
YOKO-UANIC | YOKO-RIPE
___
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] Small P Router Recommendations
On 5 Jun 2014, at 12:00 pm, Geoff Crawford geoff.crawf...@cwct.ca wrote: Hi guys! I'm a Juniper fan too, but I'll take a non-Juniper answer today. Seems to be an MPLS heavily oriented list, so I figured you guys would know. I'm sure we'd all love an EX3200 take could run LDP, pack more than 1 label and do it over aggregated interfaces. Is anyone else making a box that can do that? If you're after a switch that'll do MPLS/L3VPN, check out the QFX5100. All 10/40G though which might not be what you're after. Need to aggregate a bunch of SRXs, and drag it back to the office. I was thinking, would there be any ill-effects to building a larger subnet and connecting all the SRXes together with a standard L2 switch, and then have the switch uplink to the closest P router? Sure would be nice for adding more boxes in the future, no need to touch the P. Why not just run another SRX as a PE and aggregate via that? The MPLS feature-set is pretty comprehensive - L2VPN, VPLS, L3VPN, L2Circuit etc. Oh, and have they got L3VPN/VPLS figured out on the ACX yet? L3VPN works just fine, but L2 services are coming soon. Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 with full BGP table problems
You can cool a Sandy/Ivy Bridge CPU in a laptop at +40C degrees in direct sunlight outside (e.g. Panasonic Thoughbook) and they can't cool the same type of CPU in a datacenter with ~20-22 degrees ambient temperature and very powerful fans that are present in a router? I doubt it that the Xeon versions of those CPUs produce much more heat. Factor in the fact that they can go all SSD and you can have a very small package that can act as a RE (think of a very mini mini version of Intel NUC). The 104s are rated for use in -40 to +65° C and based on the form-factor are designed for use in areas a little less comfortable than your average data centre (places where MX80s are not designed to go like de-mountables/cabinets). There has to be another reason for the crappy REs in these routers. Yeah, I'm kinda surprised the 104s maintained the same CPU, but I guess it meant much less code re-spin. Looking forward to the day when there is a commonish RE (eg: intel-based) for all REs across the fleet. You would think this would save a pile of development work... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX1xxx Images
Hi Skeeve, The ACX1100 AC units have dual PSUs built-in - there are two C16 sockets on the front left of the unit. I can send you a photo, but there is a nice drawing on Page 4 (and 43) of the hardware guide: http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/topic-collections/hardware/acx-series/acx1000/hwguide/acx1000-hwguide.pdf Cheers, Ben On 14 May 2014, at 8:56 am, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Hey all, I am trying to find a picture of the ACX1000 and ACX1100 so I can see how they do the redundant power that they claim in the sales information, but all the images on the Juniper Image Library and google are of DC units. If anyone could shoot me a couple of photos, that would be awesome. If someone could also confirm they do redundant power, that would be fantastic. ...Skeeve *Skeeve Stevens - *eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; http://twitter.com/networkceoau linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud - Consulting - IPv4 Brokering ___ 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] SRX Active/Passive cluster with redundant route based IPSec - connectivity to AWS VPC
Further to Morgan and Andrew's comments, the st0 interface will follow whichever interface you have bound to the external-interface in your IKE Gateway configuration (ge-0/0/0.0 in the AWS example), so if you bind this to a reth (and have the st0 interface in the same redundancy group) you'll be golden. On 6 May 2014, at 10:44 am, Morgan McLean wrx...@gmail.com wrote: Andy, Assuming you have your own IP space, you put a public address on the loopback. Whichever member is active for lo0 will handle the IPSEC if i recall. Theres some juniper docs on the details. ST0 will always be on which ever node is primary. Thanks, Morgan On Mon, May 5, 2014 at 5:37 PM, Andrew Jones a...@jonesy.com.au wrote: You don't need to do anything special to make the st0 interface redundant, it will always run on the active node. On 06.05.2014 08:38, Andy Litzinger wrote: Hi Morgan, I presume that with regards to the loopback you are referring to the external interface I use as my IPSec peer toward Amazon? what about the internal logical st interface that I need to create in order to route my internal traffic into the tunnel? How do I make that redundant? thanks! -andy On Mon, May 5, 2014 at 3:30 PM, Morgan McLean wrx...@gmail.com wrote: Use your loopback and put that in a reth. Thanks, Morgan On Mon, May 5, 2014 at 3:23 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi All, Two related questions. I have a pair of SRX 3400s in an Active/Passive cluster. They rely on an external gateway for internet access (i.e. my ISPs don't terminate on the SRXs). I am setting up redundant tunnels to an AWS VPC. Amazon has an example for J-Series ( http://docs.aws.amazon.com/AmazonVPC/latest/ NetworkAdminGuide/Juniper.html ), but I don't think it's for a cluster set-up. Here are my questions: 1 - If I want to set up a redundant secure tunnel interface (e.g. st0), should i bind it to an reth interface? 2 - Has anyone connected an Active/Passive SRX cluster to an AWS VPC? Any tips or tricks you care to share? regards, -andy ___ 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 ___ 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] apply-path regex for specific interface matching
On 7 Apr 2014, at 6:37 pm, Dave Bell
m...@geordish.orgmailto:m...@geordish.org wrote:
I'm not sure you can do exactly what you are interested in. I would use two
prefix lists as follows.
policy-options {
prefix-list list1 {
apply-path interfaces ae* unit * family inet address *;
}
prefix-list list2 {
apply-path interfaces ge-1/[01]/[0-5] unit * family inet address
*;
}
}
Thanks Dave and Tim - looks like multiple lists will have to do.
On 7 April 2014 02:45, Ben Dale
bd...@comlinx.com.aumailto:bd...@comlinx.com.au wrote:
Dredging up an old thread here, but I have a requirement for an apply-path that
matches ae* and ge-1/[01]/[0-4] unit * (for a prefix-list).
I must be missing something fundamental about the regex you can use in
apply-path though, because all combinations I've tried seem to fail.
About as close as I can get to something that actually gives me results is
interfaces [ae|ge-1/0/]* unit * family net address * which isn't all
that useful.
It doesn't look like apply-path supports any nesting of regexes either eg:
interfaces [ae|ge-1/[01]/]* returns no results at all
Any thoughts?
On 26 Feb 2014, at 1:48 pm, Michael Gehrmann
mgehrm...@macquarietelecom.commailto:mgehrm...@macquarietelecom.com wrote:
Hi Ben,
I believe this document on the juniper site is what you were looking for.
http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/junos-cli-wildcard-characters-configuration-groups-usage.html
Cheers
Mike
-Original Message-
From: juniper-nsp
[mailto:juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net]
On Behalf Of Ben Dale
Sent: Wednesday, 26 February 2014 9:43 AM
To: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
Subject: [j-nsp] apply-path regex for specific interface matching
Hi all,
I'm trying to generate a prefix-list for all CE-facing interfaces on a PE
(assume L3VPN).
As a test, I'm just trying to match all ge interfaces, but the following
returns no match at all:
prefix-list CE-LINKS {
apply-path interfaces ge-* unit * family inet address *; }
I've tried both ge*, ge-* but no luck either way, and as soon as I remove
ge-, I get all interface prefixes as expected.
I vaguely remember a post here on this a while back, but I haven't been able
to track it down and google/Juniper docs are not providing any info.
Is anyone aware of 1) a solution, or 2) any docs that go through what regex
is actually available in apply-path?
Thanks,
Ben
___
juniper-nsp mailing list
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Are IRB interfaces still not functional under SRX?
On the branch at least - if you configure an irb interface, the box will fail commit check unless it is in transparent mode and it is only useable for management On 3 Apr 2014, at 7:05 am, Per Westerlund p...@westerlund.se wrote: I'm offline right now, but last time I checked, IRBs with bridge domains (SRX in transparent/L2 mode) were only used for management, no forwarding of transit traffic possible. /Per 2 apr 2014 kl. 21:46 skrev Morgan McLean wrx...@gmail.com: Just double checking that IRB interfaces are not able to be used for routing under the SRX3k and 5k series? I have a customer asking to have cabinets uplink directly to the SRX3600 (no cluster), which means I'd have to use bridge domains. But, I don't think this will even work. Am I correct? Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best device to fit for a project
SRX550 is pretty much your only option in the branch if you require dual power supply, but is in every other way overspecced (and thus priced) for the remainder of your branch requirements. If you can do without the RPS, then I'd go with either an SRX220 or 240, which will easily handle the remainder of your requirements. Are you sure you want 7-10GBps of IPSEC? I'm not sure what market you're in, but I don't imagine a 10Gbps WAN port is particularly cheap from your carrier (since you list price as being important). If you absolutely need this much crypto though, then you'll be looking at somewhere between an SRX650 and an SRX1400 plus appropriate 10G XPM/IOC. As for scalability - no issues - the 650 will support up to 3,000 tunnels and the 1400 was good for about 15,000 last time I looked - it's probably gotten better since then. Ben On 1 Apr 2014, at 4:37 pm, R S dim0...@hotmail.com wrote: For a project (70 branch offices and 2 Headquarters connected in an hubspoke topology with IPSEC over MPLS among branch and HQ) I’m looking for the best device which cover the following items: Branch: Single device At least two Ethernet interfaces (WAN/LAN) Ipsec supporting 10-50-100 Mbs Routing protocols such as BGP-OSPF NAT Redundant power supply (some site not but in principle I need it) HeadQuarter: Single device with XE intf At least two Ethernet interfaces (WAN/LAN) IPSEC supporting up to 7-10 Gbs of IPSEC (the sum of branches) Routing protocols such as BGP-OSPF NAT Redundant power supply Firewall is not needed, MPLS will be runned by the carrier, the devices and IPSEC are on-top of MPLS. I’m looking for the best solution in terms of scalability and price (very important). Also any advice with experience for the decision is appreciated. Regards ___ 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] Best device to fit for a project
Check out AutoVPN as well: http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/security-autovpn-spoke-authentication-understanding.html It's hub-and-spoke (as opposed to full-mesh) and a little simpler than GDOI, but you do take the overhead of having to managing PKI across your fleet. Ben On 1 Apr 2014, at 6:17 pm, Per Westerlund p...@westerlund.se wrote: Another possibility is a cluster of units to take care of the dual PSU requirement. For the low end you can mount 2 SRX100 in a 1U tray, and make them a cluster. Will not handle 100Mbps IPsec, but will do 10 Mbps easily, perhaps 50 Mbps depending on how you count and configure (50 bidir is actually 100 in processing power etc). None of the branch SRX have crypto chip, all IPsec is done in CPU, have to watch that. Clustered 220/240 would take care of dual PSU for 100 Mbps IPsec, but unfortunately two boxes. I don’t have pricing available and don’t run any of these myself, but what about a small MX5 (or similar) with service-card (MS-MIC) for the hub site? It claims throughput of 9Gbps. Would that fit the bill instead of the bigger SRX boxes? /Per PS: With plain IPsec, no internet tunnel requirement, and SRX everywhere, you can use GDOI (Group VPN, Cisco: GET VPN), but unfortunately that does not work with clusters. Can’t have both right now, sorry. Saves lots of problems managing pre-shared keys etc. 1 apr 2014 kl. 09:36 skrev Ben Dale bd...@comlinx.com.au: SRX550 is pretty much your only option in the branch if you require dual power supply, but is in every other way overspecced (and thus priced) for the remainder of your branch requirements. If you can do without the RPS, then I'd go with either an SRX220 or 240, which will easily handle the remainder of your requirements. Are you sure you want 7-10GBps of IPSEC? I'm not sure what market you're in, but I don't imagine a 10Gbps WAN port is particularly cheap from your carrier (since you list price as being important). If you absolutely need this much crypto though, then you'll be looking at somewhere between an SRX650 and an SRX1400 plus appropriate 10G XPM/IOC. As for scalability - no issues - the 650 will support up to 3,000 tunnels and the 1400 was good for about 15,000 last time I looked - it's probably gotten better since then. Ben On 1 Apr 2014, at 4:37 pm, R S dim0...@hotmail.com wrote: For a project (70 branch offices and 2 Headquarters connected in an hubspoke topology with IPSEC over MPLS among branch and HQ) I’m looking for the best device which cover the following items: Branch: Single device At least two Ethernet interfaces (WAN/LAN) Ipsec supporting 10-50-100 Mbs Routing protocols such as BGP-OSPF NAT Redundant power supply (some site not but in principle I need it) HeadQuarter: Single device with XE intf At least two Ethernet interfaces (WAN/LAN) IPSEC supporting up to 7-10 Gbs of IPSEC (the sum of branches) Routing protocols such as BGP-OSPF NAT Redundant power supply Firewall is not needed, MPLS will be runned by the carrier, the devices and IPSEC are on-top of MPLS. I’m looking for the best solution in terms of scalability and price (very important). Also any advice with experience for the decision is appreciated. Regards ___ 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] system archival configuration and filenames
Hi Victor,
This was discussed here a little while back - in short there is no way to
archive them unzipped them except to have a server-side script monitoring the
directory you FTP to and doing it for you.
As for the naming, that is odd - the standard format for these files is:
router-name_juniper.conf.n.gz_MMDD_HHMMSS
Cheers,
Ben
On 2 Apr 2014, at 4:11 am, Victor Sudakov v...@mpeks.tomsk.su wrote:
Dear Colleagues,
I have configured the following:
admin@sw-us-parabel show configuration system archival
configuration {
transfer-on-commit;
archive-sites {
ftp://cfg@10.14.140.125/ password $9$WqR8X-4oGiHm24; ##
SECRET-DATA
}
}
on an EX4200 with JUNOS 12.3R3.4.
The files which end up on the FTP server look like this:
acc_transfer_link_3775
acc_transfer_link_3811
acc_transfer_link_3874
and they come gzipped.
How can I configure the archived configs to be a) plain text (not gzipped)
and b) somehow related to the name of the switch?
Thanks in advance for any ideas.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
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] SRX100 LDAP
It's been a long time since I've played with this, but it's not something
simple like:
set access-profile TPAD
is it? The Junos doco doesn't mention it, but for some applications you need
to specifically activate the access-profile.
On 18 Mar 2014, at 8:54 pm, Шепелев Андрей xamalon...@gmail.com wrote:
Hi All !
I`m trying to made a web portal auth with LDAP integration on SRX 100.
Here is the config:
## Last changed: 2014-03-11 05:44:05 UTC
version 11.2R4.3;
system {
host-name test-srx100.adm.n.tp.ru;
root-authentication {
encrypted-password $1$yo2A3wox$K/.Epl658XW1r4Z9BgDWm0; ##
SECRET-DATA
}
name-server {
10.60.0.5;
8.8.8.8;
}
services {
ssh;
telnet;
xnm-clear-text;
web-management {
http;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
}
max-configurations-on-flash 5;
max-configuration-rollbacks 5;
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
processes {
general-authentication-service {
traceoptions {
file auth-debug;
flag all;
}
}
}
}
interfaces {
fe-0/0/0 {
unit 0;
}
fe-0/0/1 {
vlan-tagging;
unit 101 {
description Users;
vlan-id 101;
family inet {
address 10.60.0.200/24;
}
}
unit 105 {
description Management;
vlan-id 105;
family inet {
address 172.20.0.200/24;
}
}
}
fe-0/0/2 {
unit 0;
}
fe-0/0/3 {
unit 0;
}
fe-0/0/4 {
unit 0;
}
fe-0/0/5 {
unit 0;
}
fe-0/0/6 {
unit 0;
}
fe-0/0/7 {
unit 0 {
description ISP1;
family inet {
address 46.250.34.22/24;
}
}
}
vlan {
unit 0;
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop 46.250.34.1;
route 10.60.0.0/21 next-hop 10.60.0.1;
route 172.20.0.0/24 next-hop 172.20.0.1;
}
}
protocols {
stp;
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
nat {
source {
rule-set trust-to-untrust {
from zone trust;
to zone untrust;
rule source-nat-rule {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
}
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
firewall-authentication {
pass-through {
access-profile TPAD;
web-redirect;
}
}
}
}
}
}
}
zones {
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
fe-0/0/1.101;
fe-0/0/1.105;
}
}
security-zone untrust {
screen untrust-screen;
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
interfaces {
fe-0/0/0.0 {
host-inbound-traffic {
system-services {
dhcp;
tftp;
}
}
Re: [j-nsp] Disable STP on a port with ELS?
I seem to recall reading that at least on the 4300 ELS, spanning-tree is now no longer implicitly enabled on every port, so disable is no longer required because it is the default state unless you have explicitly referenced the interface. Would love to confirm this with someone who has access to either 4300, 9200 or QFX5100 in front of them Ben On 9 Mar 2014, at 1:49 am, Chuck Anderson c...@wpi.edu wrote: Here is another Enhanced Layer 2 Software question. Is it possible to disable STP participation on a port? The disable command seems to be missing from these hierarchies, at least on 13.2X51 for QFX5100: protocols stp interface disable protocols rstp interface disable protocols mstp interface disable protocols vstp interface disable ___ 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] sshd log messages !!
If you're stuck with password-based login (rather than SSH keys), leave yourself one go at missing your password, then increase the backoff-factor up to 10 to put a 10-second wait for guess number 3: set system services ssh root-login deny set system login retry-options backoff-threshold 2 set system login retry-options backoff-factor 10 It won't stop a bot, but it will slow it down a bit. Phil - while you're at it with Junos enhancements - any chance of giving us a set system services ssh port 1024-65535 Yes it's security through obscurity, but it's also low hanging fruit.. Failing that, there is a: set system login deny-sources maybe an allow-sources might be a bit more useful in this instance? Less sophisticated users tend to shoot themselves in the foot with firewall filters quite regularly. Ben On 27 Feb 2014, at 8:21 am, Harri Makela harri_mak...@yahoo.com wrote: Hi There I am constantly getting these log messages for last few days:- sshd[21015]: Failed password for root from X.X.103.152 port 21067 ssh2 sshd[21016]: Received disconnect from X.X.103.152: 11: Normal Shutdown, Thank you for playing Are these indicating any brute-force attack ?Thanks HM On Wednesday, 26 February 2014, 21:15, juniper-nsp-requ...@puck.nether.net juniper-nsp-requ...@puck.nether.net wrote: Send juniper-nsp mailing list submissions to juniper-nsp@puck.nether.net To subscribe or unsubscribe via the World Wide Web, visit https://puck.nether.net/mailman/listinfo/juniper-nsp or, via email, send a message with subject or body 'help' to juniper-nsp-requ...@puck.nether.net You can reach the person managing the list at juniper-nsp-ow...@puck.nether.net When replying, please edit your Subject line so it is more specific than Re: Contents of juniper-nsp digest... Today's Topics: 1. Re: proposed changes to clear bgp neighbor (ryanL) 2. Re: proposed changes to clear bgp neighbor (Phil Shafer) 3. Re: proposed changes to clear bgp neighbor (Eric Van Tol) 4. Re: proposed changes to clear bgp neighbor (Jerry Dent) 5. Re: proposed changes to clear bgp neighbor (Brent Sweeny) 6. Re: proposed changes to clear bgp neighbor (Fernando Garcia Fernandez) 7. Re: proposed changes to clear bgp neighbor (ryanL) 8. Re: proposed changes to clear bgp neighbor (Jonas Frey (Probe Networks)) 9. Re: proposed changes to clear bgp neighbor (sth...@nethelp.no) -- Message: 1 Date: Wed, 26 Feb 2014 12:22:51 -0500 From: ryanL ryan.lan...@gmail.com To: p...@juniper.net Cc: Juniper for Network Service Providers juniper-nsp@puck.nether.net Subject: Re: [j-nsp] proposed changes to clear bgp neighbor Message-ID: cak_-tsayrdjhuatsnbokn2nrkcrjjgb3zwtr_cljizkuxcx...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 it's a nice-to-have, maybe? but this sounds more like an opportunity for you to sell some JNCIA courses. i mean, how long has junos been around now? On Wed, Feb 26, 2014 at 10:36 AM, Phil Shafer p...@juniper.net wrote: 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 a specific neighbor. In general, we avoid changing commands to add mandatory arguments, but my feeling is that the impact and severity of this specific command makes this an acceptable occasion for such a change. I'm looking for feedback about this change. My working assumption is that clear bgp neighbor is a sufficiently rare command and would not be used in automation/scripts, so the impact of making the neighbor/all argument mandatory would be minimal. Is this assumption accurate? Thanks, Phil [I've set reply-to to myself to avoid impacting the list] ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message: 2 Date: Wed, 26 Feb 2014 13:44:42 -0500 From: Phil Shafer p...@juniper.net To: ryanL ryan.lan...@gmail.com Cc: Juniper for Network Service Providers juniper-nsp@puck.nether.net Subject: Re: [j-nsp] proposed changes to clear bgp neighbor Message-ID: 201402261844.s1qiiggl031...@idle.juniper.net Content-Type: text/plain ryanL writes: it's a nice-to-have, maybe? but this sounds more like an opportunity for you to sell some JNCIA courses. i mean, how long has junos been around now? Not selling anything; just trying to solve a problem multiple customers have reported and escalated. I'm a software developer, working on the UI code (CLI, MGD, configuration, XML API, scripting) for 17+ years. JUNOS 3.0 (the first release with the ui code) shipped during the
[j-nsp] apply-path regex for specific interface matching
Hi all,
I'm trying to generate a prefix-list for all CE-facing interfaces on a PE
(assume L3VPN).
As a test, I'm just trying to match all ge interfaces, but the following
returns no match at all:
prefix-list CE-LINKS {
apply-path interfaces ge-* unit * family inet address *;
}
I've tried both ge*, ge-* but no luck either way, and as soon as I remove
ge-, I get all interface prefixes as expected.
I vaguely remember a post here on this a while back, but I haven't been able to
track it down and google/Juniper docs are not providing any info.
Is anyone aware of 1) a solution, or 2) any docs that go through what regex is
actually available in apply-path?
Thanks,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN's on EX4300 with 13.2X50-D15.3
On 20 Feb 2014, at 6:00 pm, Per Granath per.gran...@gcc.com.cy wrote: For the mixed VC, the options are EX42+EX4550 or EX43+QFX. For VC, the EX42 uses VCP-cables, while the EX43 uses QSFP-DAC-cables (assuming you do not want to waste your 10G ports). EX42 and EX43 has the same price. EX4550 is somewhat cheaper than QFX. A word of caution on the same price between EX42/43: If you want to use the EX4300 for L3 (and lets face it, that's probably everyone) you'll require the Enhanced Feature License for OSPFv2/3, IGMP v1/v2, PIM, VRF-Lite, QinQ and OAM. EX4200 includes all this in the base license. Both still require the Advanced Feature License for BGP, ISIS and MPLS. If you want to install the Advanced Feature License on EX4300 though, you need to buy both the EFL *and* AFL. All features are still available for testing without licenses, but you get the nag message every minute in syslog. All that said, being able to VC up to 5 of these things together with a dedicated 40G between any two is pretty darn cool. Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VLAN's on EX4300 with 13.2X50-D15.3
On 20 Feb 2014, at 11:22 am, Mark Tinka mark.ti...@seacom.mu wrote: On Wednesday, February 19, 2014 10:47:33 PM Aaron Dewell wrote: The main advantage of the 4300 vs. 4200 is 4x10G uplinks instead of 2, and 40G QSFP+ ports which can be either VC or routed. It's a lot more flexible platform and much more compatible with others (read: QFX5100) than the EX4200 will ever be. Can anyone speak to buffer sizes and whether egress policing is supported? Mark. From what I've been able to gather, there is a single PFE on them with 5MB shared. The feature guide suggests port/queue shaping is available and it mentions policing under Routing Policy/Packet Filtering features, but I suspect this is just the traditional filter-based stuff: http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#cos-features-by-platform-table Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Product against DDoS
So I had a tech session on the DDoS Secure product a while back and my takeaway was that it is targeted at the low'n'slow style of DDoS rather than volumetric attacks that products like Arbour et. al. assist with mitigating - at the end of the day, you position it logically in front of your servers/LB (it's a transparent bridge). In drastically simplified terms, it uses a truck load of heuristics and other magic™ to determine whether requests to your infrastructure are machine-based or interactive, and then depending on whether traffic flows are in profile or not (servers under load etc.), reacts. Webcrawlers and other legit machine traffic are also handled gracefully. The technology behind it looks quite interesting, and coupled with WebApp Secure/Mykonos it is certainly a different take on the typical mod_secure/WAF story for any content providers. It would be nice if product marketing had picked a slightly less evocative name though - when someone says DDoS, I'm sure most think instantly of pipe-filling packet storms. Ben On 19 Feb 2014, at 1:06 am, Benoit Plessis b.ples...@doyousoft.com wrote: Le 18/02/2014 15:46, Samol a écrit : Hi Experts, Does Juniper provide any DDoS solution ? would you please recommend the product line for this solution if there is? thanks, Hi, No expert here but there is the DDoS Secure appliance on there sales list, something from a company recently bougth (http://www.webscreen-technology.com/). It's a dell computer server hardware apparently, with a custom (up to where?) software. I should receive one shortly so shall see ... ___ 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] VLAN's on EX4300 with 13.2X50-D15.3
Hi Janusz,
You may want to read through this document too:
http://www.juniper.net/techpubs/en_US/junos13.2/topics/task/configuration/getting-started-els.html
there are quite a few changes to the way you're used to doing things with VLANs
and interfaces on EX4300s, which you'll find incredibly frustrating after using
any of the other EXs up until now.
Also, upgrade your code to 13.2X50-D18 right now. No, really. You'll thank me
later.
It's not actually available on the download page, but if you follow the link on
right where it shows JTAC recommended code which redirects you to the
password-protected KB Article on recommended versions, which you can then dig
through to find the link to the specific EX4300 software Technical Services
Bulletin, which lists the 13-odd critical PRs that seemed to make it out the
door and finally the link to the actual software...
or for Hitchhikers fans: It was on display in the bottom of a locked filing
cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of
the Leopard'.
https://download.juniper.net/software/junos/regressed/13.2X50-D18/jinstall-ex-4300-13.2X50-D18-domestic-signed.tgz
On 19 Feb 2014, at 1:44 pm, Janusz Wełna janusz.we...@gmail.com wrote:
Hi,
Why when I have below config:
ge-0/0/44 {
description test;
unit 0 {
family ethernet-switching {
vlan {
members vlan103;
}
storm-control default;
unit 103 {
description test;
family inet {
address 10.46.163.1/29;
vlan103 {
description test;
vlan-id 103;
l3-interface vlan.103;
I cannot ping from EX4300 10.46.163.1 and I cannot ping 10.46.163.1 from
server connected to ge-0/0/44
But when I add below:
irb {
unit 103 {
family inet {
address 10.46.163.1/29;
and delete :
vlan103 {
description SGI;
vlan-id 103;
l3-interface vlan.103
ping works correctly.
On EX3300, EX4200 and EX2200 I not need setup irb interface, why I need on
EX4300 ?
Br,
Janusz
___
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] VLAN sub-ints and VPLS
Hi Tom, Great, no more errors, try to commit again: # commit [edit interfaces ge-0/0/12] 'unit 0' vlan map ge-0/0/12: input-vlan-map and output-vlan-map are valid on untagged interfaces only for ethernet-ccc and ethernet-vpls encapsulations error: configuration check-out failed But you just told me I need to use tagging? And there is no ethernet-vpls encapsulation for units. wtf? Maybe its just not possible on an SRX, perhaps it doesnt have the smarts, or maybe Im just missing something really obvious. Any help appreciated. Cheers! Switch your physical interface encapsulation to vlan-vpls and try committing again Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF neig / SRX cluster / LACP
On 16 Jan 2014, at 11:22 am, Samol molas...@gmail.com wrote: I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are UP. Check it in layers: - is the reth interface on SRX-B definitely up when you have both links enabled show chassis cluster interfaces - is your LACP up between MX-B and the cluster - bearing in mind that you cannot have a single LAG between MX-B and your SRX (it will need to be a LAG to each cluster node) show lacp interfaces - if the neighbor is only down on one of the RIs, assuming you have a VLAN between the MX and the SRX to carry each RI - double check that the VLAN is actually tagged on both LAGs between the two boxes show bridge domain interface aex.0 Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF neig / SRX cluster / LACP
I'm surprised that this is even working at all.
http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html
Specifically:
Note: The redundant Ethernet interface LAG child links from each node in the
chassis cluster must be connected to a different LAG at the peer devices. If a
single peer switch is used to terminate the redundant Ethernet interface LAG,
two separate LAGs must be used in the switch.
From a single MX a single LAG should got to a single individual node from the
chassis cluster.
Can you paste the OSPF configs from each RI on the SRX and MX-B?
On 16 Jan 2014, at 2:51 pm, Samol molas...@gmail.com wrote:
what i'm doing is LACP (ae) from MX to LACP (reth) SRX where one link is on
Node0 and another is on node1. both link on SRX are member of Reth.
Admin@coolSRX# show interfaces reth1
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
passive;
periodic fast;
}
}
{primary:node0}[edit]
Admin@coolSRX# run show lacp interfaces reth1
Aggregated interface: reth1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout
Activity
ge-0/0/4 ActorNoNo Yes Yes Yes Yes Fast
Passive
ge-0/0/4 PartnerNoNo Yes Yes Yes Yes Fast
Active
ge-9/0/4 ActorNoNo Yes Yes Yes Yes Fast
Passive
ge-9/0/4 PartnerNoNo Yes Yes Yes Yes Fast
Active
LACP protocol:Receive State Transmit State Mux State
ge-0/0/4 Current Fast periodic Collecting
distributing
ge-9/0/4 Current Fast periodic Collecting
distributing
All interfaces are UP. Reth's on SRX are also up. ae interfaces on MX-A and B
are also UP.
Regards,
2014/1/16 Ben Dale bd...@comlinx.com.au
On 16 Jan 2014, at 11:22 am, Samol molas...@gmail.com wrote:
I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
UP.
Check it in layers:
- is the reth interface on SRX-B definitely up when you have both links
enabled
show chassis cluster interfaces
- is your LACP up between MX-B and the cluster - bearing in mind that you
cannot have a single LAG between MX-B and your SRX (it will need to be a LAG
to each cluster node)
show lacp interfaces
- if the neighbor is only down on one of the RIs, assuming you have a VLAN
between the MX and the SRX to carry each RI - double check that the VLAN is
actually tagged on both LAGs between the two boxes
show bridge domain interface aex.0
Ben
--
Samol Khoeurn
(855) 077 55 64 02 / (855) 067 41 88 66
Network Engineer
Cisco: CCNA/CCNP SP/CCIP/
Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
www.linkedin.com/in/samolkhoeurn
OSPF on SRX clustering.png
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] OSPF neig / SRX cluster / LACP
You'll see in Cooper's blog that both nodes are going back into a *single* EX
switch with *two* ae interfaces configured - one to each node.
These ae links have two ports allocated to them.
All LACP does is provide redundancy/balancing between ports to the primary node
- the secondary node will be down from a reth perspective, even if the LACP
shows as up.
On 16 Jan 2014, at 4:42 pm, Samol molas...@gmail.com wrote:
Hi Aaron,
LACP is running on the reth interface and reth's are up. below is the
configuration:
Admin@coolSRX# show interfaces reth1
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
passive;
periodic fast;
}
}
this link was successful for this. http://cooperlees.com/blog/?p=401
2014/1/16 Aaron Dewell aaron.dew...@gmail.com:
reth interfaces are for failover not for bundle. You can use two LAGs
within a reth interface (multiple interface on a single node in a LAG) but
not across both. It's up (probably) because you aren't running LACP. If
you turn on LACP, then various links will be down. I'm going to guess
that's why the OSPF session from the right MX is down - because the MX is
transmitting to the wrong node for that redundancy-group and it's being
ignored.
On Jan 15, 2014, at 11:52 PM, Samol wrote:
I can't access to the devices at the moment, but basically what we did
was under each routing instance, we just put the interfaces inside the
ospf area. very straight forward configuration of ospf. I have thought
of links LAG from MX should only connect to each node individually.
but it's interesting that LAG are running even though links are
connected two different nodes (this is for Reth interface). But I
tried to use AE interface on SRX cluster, the theory is true that we
can't bundle two links that land on different node. we just can't
commit. that is the reason we move to Reth.
Regards,
2014/1/16 Ben Dale bd...@comlinx.com.au:
I'm surprised that this is even working at all.
http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/interface-security-aggregated-ethernet-lacp-chassis-cluster-understanding.html
Specifically:
Note: The redundant Ethernet interface LAG child links from each node in
the chassis cluster must be connected to a different LAG at the peer
devices. If a single peer switch is used to terminate the redundant
Ethernet interface LAG, two separate LAGs must be used in the switch.
From a single MX a single LAG should got to a single individual node from
the chassis cluster.
Can you paste the OSPF configs from each RI on the SRX and MX-B?
On 16 Jan 2014, at 2:51 pm, Samol molas...@gmail.com wrote:
what i'm doing is LACP (ae) from MX to LACP (reth) SRX where one link is
on Node0 and another is on node1. both link on SRX are member of Reth.
Admin@coolSRX# show interfaces reth1
vlan-tagging;
redundant-ether-options {
redundancy-group 1;
lacp {
passive;
periodic fast;
}
}
{primary:node0}[edit]
Admin@coolSRX# run show lacp interfaces reth1
Aggregated interface: reth1
LACP state: Role Exp Def Dist Col Syn Aggr Timeout
Activity
ge-0/0/4 ActorNoNo Yes Yes Yes Yes Fast
Passive
ge-0/0/4 PartnerNoNo Yes Yes Yes Yes Fast
Active
ge-9/0/4 ActorNoNo Yes Yes Yes Yes Fast
Passive
ge-9/0/4 PartnerNoNo Yes Yes Yes Yes Fast
Active
LACP protocol:Receive State Transmit State Mux State
ge-0/0/4 Current Fast periodic Collecting
distributing
ge-9/0/4 Current Fast periodic Collecting
distributing
All interfaces are UP. Reth's on SRX are also up. ae interfaces on MX-A
and B are also UP.
Regards,
2014/1/16 Ben Dale bd...@comlinx.com.au
On 16 Jan 2014, at 11:22 am, Samol molas...@gmail.com wrote:
I got OSPF neighbor UP for all neighbors (RI: OUTSIDE and INSIDE) but not
for Routing Instance (RI) INSIDE between SRX and MX-B. and If I shutdown
interface on SRX-B (secondary) that connecting MX, all OSPF neighbors are
UP.
Check it in layers:
- is the reth interface on SRX-B definitely up when you have both links
enabled
show chassis cluster interfaces
- is your LACP up between MX-B and the cluster - bearing in mind that you
cannot have a single LAG between MX-B and your SRX (it will need to be a
LAG to each cluster node)
show lacp interfaces
- if the neighbor is only down on one of the RIs, assuming you have a
VLAN between the MX and the SRX to carry each RI - double check that the
VLAN is actually tagged on both LAGs between the two boxes
show bridge domain interface aex.0
Ben
--
Samol Khoeurn
(855) 077 55 64 02 / (855) 067 41 88 66
Network Engineer
Cisco: CCNA/CCNP SP/CCIP/
Juniper: JNCIA/JNCIS-ENT,SP,SEC/JNCIP-ENT
www.linkedin.com
Re: [j-nsp] NTP Reflection
On 14 Jan 2014, at 12:31 pm, Mark Tees markt...@gmail.com wrote: What I was referring to was a detailed ACL/Filter for lo0 that only allows traffic for enabled services on the routing engine. For example if Juniper posted a firewall filter template with all the possible services customers could then activate/deactivate what they need from the policy and log fails before discarding etc. What you think you're after is show system connections which is more or less netstat -an and shows all ports that are listening on your RE - you can now filter at will. Providing a list of every service for people to modify is not going to solve these problems - Oh hey, I'm using NTP, I'd better enable all those rules.. What you actually want is an ACL with ONLY the services you've actually configured and understand from the source/destinations you're using them from and deny all else - then you *mostly* don't need to worry about this sort of thing. If your employer is too tight to spring for the MX book (worth every cent and then some), the following free Day One books will provide everything you're after (sign up for a J-Net login if you don't already have one): http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/ http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/hardening-junos-devices-checklist/ http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/configuring-junos-policies/ Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] qfabric 1536k mac address?
At a guess I'd say it's because in Q-Fabric, the MAC-learning is performed by a similar to a VPLS instance per VLAN rather than traditional per-switch CAM tables. I imagine this allows for better scalability/optimisation. The switch CAM would then only need to worry about L2-adjacent QF nodes and adjacent hosts. On 2 Jan 2014, at 5:28 pm, giovanni rana superburri...@hotmail.com wrote: Hi, during the evaluation of a new data center architecture, how can qfabric support so many Mac addresses? The qfx3500 node supports only 128k Mac tables, how can they get 1536k as declared in the data sheet? Is it because of an optimized use of mac-vlan pairs? Thanks for any answer and happy 2014! ___ 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 MX104
That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++ytti ___ 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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ 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 MX104
MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell test-kit with some sort of 'per hours used' license. Lot of SPs have need for proper testing kit, but only will need them very irregularly. And renting is always such a chore. It's same thing there, BOM is nothing, but volume is even lower, so prices are ridiculously high, consequently proper testing is very rarely done by other than telco size SPs. It's one of those things where you work with account team. if the commercial terms don't work out for most potential buyers, then the product won't be successful and either things will change or they won't. -- ++ytti ___ 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 -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ 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] Juniper MX104
Yeah, my take on that is that MPC0 is pretty much anything built-in on the MX5/80 - eg: the front 10G ports are xe-0/0/0 My guess is that the rear slot is just another MIC slot (slot 1) MPC 0 so something like sp-0/1/0 or whatever designation gets used. The front MIC slots are ge-1/0/0-19 and ge-1/1/0-19 etc. On 13 Nov 2013, at 3:33 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Isn't that using the front MIC slot though? The rear 'Services Slot' is an MPC slot isn't it? Based on the following: MS-MIC 16G - MS-MIC with 16 GB of memory provides 9GB of service throughput, occupies single MIC slot on MX5, MX10, MX40, and MX80 3D Universal Edge Routers, as well as on the MPC1, MPC2, and MPC3 cards for the MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Router. MS-MPC-128 - MS-MPC with 128 GB of memory (32 GB per NPU), provides 60Gbps of service throughput, occupies a single slot in MX2020, MX2010, MX960, MX480, and MX240 3D Universal Edge Routers The rear picture of the MX80 at http://www.juniper.net/shared/img/products/mx-series/mx80/mx80-rear-high.jpg Says MPC 0 and MIC 1 in smaller writing under it. From front right slot is also called 1/MIC 1 I think we need further clarification. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 4:04 PM, Ben Dale bd...@comlinx.com.au wrote: MS-MIC is out for the MX5-80: http://www.juniper.net/us/en/local/pdf/datasheets/1000454-en.pdf doesn't look like there isn't a services port on the back of the 104 though: http://www.juniper.net/shared/img/products/mx-series/mx104/mx104-rear-high.jpg maybe you can use one of the front slots? On 13 Nov 2013, at 2:52 pm, Skeeve Stevens skeeve+juniper...@eintellegonetworks.com wrote: Does anyone know how many users the MX104 will be able to handle though? The 4000 user limit on the MX80 was quite low. Does the MX104 have the services port on the back like the MX80? I'm waiting for the CGN Services card which was supposed to be released around now. ...Skeeve Skeeve Stevens - eintellego Networks Pty Ltd ske...@eintellegonetworks.com ; www.eintellegonetworks.com Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellegonetworks ; linkedin.com/in/skeeve twitter.com/theispguy ; blog: www.theispguy.com The Experts Who The Experts Call Juniper - Cisco - Cloud On Wed, Nov 13, 2013 at 3:46 PM, Ben Dale bd...@comlinx.com.au wrote: That and I think a lot of the BRAS migration functionality (LNS/LAC etc) was late to the party after being told it wasn't going to happen for anything lower than the 240. On 13 Nov 2013, at 12:51 pm, Bill Blackford bblackf...@gmail.com wrote: My personal feeling is the MX80 wasn't widely adopted as a lower density subscriber box given the lack of redundant REs. The MX104 may find it's niche as a BRAS. On Tue, Nov 12, 2013 at 5:25 PM, Eric Van Tol e...@atlantech.net wrote: One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the built-in 10G ports do not do hierarchical QoS (per-unit scheduling). I'm confused as to why this is, considering they are Trio-based routers, but I digress. I personally don't think that the astronomical cost to enable the 10G ports on all the low-end MX routers is worth it, considering they can't even do per-unit scheduling. -evt -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of joel jaeggli Sent: Tuesday, November 12, 2013 4:00 PM To: Saku Ytti Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper MX104 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote: On (2013-11-12 20:14 +), Tom Storey wrote: Why so much just to enable some ports? How do they come up with that kind of price? Pluck it out of thin air? The hardware has been paid for, and I know thats only list pricing, but it still seems ridiculous. The question might have been rhetoric. But I'll bite. The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the volume you can sell them also is very very small, so the margins need to be very high to be able to design and support them. Licensing allows you to sell to larger group of people, people who normally would buy smaller/inferior box, now can afford it, which in turn allows you to reduce your margins, making you more competitive. I actually like it. I wish vendors like Agilent/Ixia, Spirent would
Re: [j-nsp] J-series, hoping packets between routing-instances
Hi Mike, First.. Yikes! Second - yes this is possible. It is perfectly legal to use FBF to bounce across routing instances and still match security policy - just ensure your security policy includes the source and destination zones for the *ultimate* destination of the flow is correct - whether it exists in the instance the traffic ends up in is ignored by the flow engine. On 8 Nov 2013, at 12:37 am, Mike Williams mike.willi...@comodo.com wrote: Hi all, I might have painted myself into a corner here, so I'm here looking for options from people far cleverer than I. Firstly, a bit of history. We're using J6350s, and SRX650s, as security devices on a stick. Our Ms and MXs punt packets into a routing instance on the security devices with firewall filters. Those routing instances purposely only use the most basic of static routes possible (10/8, 192.168/16, etc), so we can be certain what zones packets pass through so the policies match. That all works fine. We're also centralising our inter-site IPSec onto the Js and SRXs, but need OSPF there, so have a second routing-instance and a partial mesh of routed tunnels between them. Still, all good. Offices and what-not have tunnels tied directly to the IPSec routing-instances and OSPF metrics keep traffic flows sane. All hunky dory. Now the problem. I need to take traffic from servers behind an M/MX have it policy'd by the security routing instance, then encrypted by the IPSec routing-instance. If I punt traffic into security, let it come back to the router, then punt it back into ipsec, everything works as expected. However each packet has to pass across the M/MX-J/SRX link 4 times, in out, in out. Shake it all about. Obviously this would be better if we could shortcut the M/MX step in the middle and move packets from security to ipsec, and ipsec to security directly. As security doesn't run OSPF/BGP/ISIS/etc adding a static route next-table ipsec.inet.0 is fine. ipsec *does* run OSPF though, so I need to do FBF to override that. I've tried a then routing-instance security filter applied on output on the interface facing the M/MX, but my traffic get lost somewhere. Security policies from 'input-ipsec-zone' to 'output-security-zone' were added. I'm wondering if 'moving' packets from routing-instance to routing-instance on a flow-mode device simply screws up security policies. As one of the input or output interface don't exist in the routing-instance. So I figured *routing* packets from routing-instance to routing-instance would be better. Time for some logical tunnels! J-series devices don't support logical tunnels though. Argh! -- Mike Williams ___ 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] 100% CPU HIT on EX4200
You might want to share your Junos version too Being an EX, follow up Graham's suggestions with: show log messages (filtered down to times during the event) show spanning-tree bridge (check Time since last topology change/number of changes - this is usually a culprit in pegging CPU) On 8 Nov 2013, at 10:57 am, Graham Brown juniper-...@grahambrown.info wrote: Hi Sam, 'show chassis routing-engine' and 'show system processes extensive' are two commands to start with, when investigating this issue. The second command will show you what process is consuming resources etc. HTH, Graham On 8 November 2013 13:51, Samol molas...@gmail.com wrote: Hi All, CPU on EX4200 run up to 100% for a period of time and I have not yet found what caused this. Based on your experiences, what are the things that can cause this and what are the commands to check this ? Thanks, Sam ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Graham Brown Twitter - @mountainrescuer https://twitter.com/#!/mountainrescuer LinkedIn http://www.linkedin.com/in/grahamcbrown ___ 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] srx cluster - port channel - cisco switches - esx devices - 12.1x45-d15.5 some virtual machines can't be reached
On 24 Oct 2013, at 5:48 pm, pkc_mls pkc_...@yahoo.fr wrote: Le 24/10/2013 00:55, Ben Dale a écrit : Can you confirm that you have two active port-channels configured on the Cisco side, one into each SRX? From the docs I found I was assuming a single port-channel could handle all interfaces attached to the same reth on srx. For example, if ge-0/0/2, ge-0/0/3, ge-5/0/2, ge-5/0/3 are attached to reth0, can I connect all the ports to the same etherchannel on the stack ? No, there will be two sub-LAGs formed from the SRX - one on the active node, and one on the standby node. To downstream devices, these appear as distinct LACP bundles, even though they are part of the same reth interface on the SRX. There is a rather wordy explanation of it here, but the Note box in the middle of the page is probably a good summary: http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-interfaces/understand-lacp-in-cc-mode-section.html Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] srx cluster - port channel - cisco switches - esx devices - 12.1x45-d15.5 some virtual machines can't be reached
On 24 Oct 2013, at 1:12 am, pkc_mls pkc_...@yahoo.fr wrote: Hi all, I'm running a cluster of srx 240 connected to a pair of cisco 2960 switches with a port channel. ESXi servers are also connected to the same stack of cisco switches. vlan 1000 with ip 192.168.100.0 is used for out of band management and reachability. I'm using a dedicated virtual router to route the traffic from this vlan to other vlans. Some virtual machines can be reached but some others can't. I upgraded today to 12.1X45-D15.5, as I require vpn termination on loopback interface, and I suspect this release to have introduced weirdness into the configuration. Does anyone use a pair of srx devices with this release 12.1X45-D15.5 have some issues with this kind of configuration ? Are there any specific configurations to be used on the port channels connected to the srx on the cisco stack ? Best regards. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Can you confirm that you have two active port-channels configured on the Cisco side, one into each SRX? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Spanning Tree Inconsistent State
Hi Crist,
It is certainly possible to have blocked ports on a root bridge - consider a
case where the switch is patched to itself.
Having a root port is a little unusual though?!!.
Restarting RSTP is going to cause a topology change or two amongst your
neighbours so try to do it during low traffic.
It might be worth using LLDP to trace out physical connections too just to make
sure there isn't a cabling issue.
Ben
On 03/10/2013, at 9:50 AM, Crist Clark cjc+j-...@pumpky.net wrote:
I am a little confused about the spanning tree state on an EX4200 VC,
running 11.4R5.5.
{master:0}
cjc@dmz4200 show spanning-tree bridge
STP bridge parameters
Context ID : 0
Enabled protocol: RSTP
Root ID : 32768.88:e0:f3:77:53:81
Hello time: 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Message age : 0
Number of topology changes: 20
Time since last topology change : 3661899 seconds
Topology change initiator : xe-0/1/0.0
Topology change last recvd. from : 88:e0:f3:74:51:6a
Local parameters
Bridge ID : 32768.88:e0:f3:77:53:81
Extended system ID : 0
Internal instance ID: 0
{master:0}
cjc@dmz4200 show spanning-tree interface
Spanning tree interface parameters for instance 0
InterfacePort IDDesignated Designated PortState Role
port IDbridge ID Cost
ge-0/0/0.0 128:513 128:513 32768.88e0f3775381 2 FWDDESG
ge-0/0/47.0128:560 128:560 32768.88e0f3775381 2 FWDDESG
xe-0/1/0.0 128:609 128:609 32768.88e0f3775381 2000 FWDROOT
xe-0/1/2.0 128:611 128:611 32768.88e0f3775381 2000 FWDDESG
ge-1/0/0.0 128:625 128:625 32768.88e0f3775381 2 FWDDESG
ge-1/0/47.0128:672 128:672 32768.88e0f3775381 2 FWDDESG
xe-1/1/0.0 128:721 128:776 32768.50c58dac4c81 2000 BLKALT
xe-1/1/2.0 128:723 128:723 32768.88e0f3775381 2000 FWDDESG
So what I'm confused about is that the show spanning-tree bridge output
says that this switch is the root bridge, yet the per-interface output
indicates that there are ROOT and ALT ports. Also, the bridge ID for the
ROOT port is the switch itself? Whereas the ALT port is what I would
expect, except that it again seems to contradict the idea that this switch
is the root bridge.
I think my RSTP on this switch is in some messed up state? When I turn on
traceoptions for rstp, I see sucpicious stuff like,
Oct 2 11:26:59.532378 PISM: Port xe-1/1/0.0: IMPOSSIBLE EVENT/STATE
Combination Occured
Oct 2 11:26:59.532396 PISM: Event routine returned FAILURE
Oct 2 11:26:59.532414 MSG: RstPortInfoMachine function returned FAILURE!
Oct 2 11:26:59.532441 RECV: PortReceiveStateMachine Action returned
FAILURE!
Oct 2 11:26:59.532467 MSG: RstPortReceiveMachine function returned FAILURE!
Oct 2 11:26:59.532493 MSG: RstHandleInBpdu function FAILED!
Is there a low risk way to reset RSTP on a production switch?
___
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] SRX Command
Just blew the dust off it and it still works ; )
http://pastebin.com/xiszACPf
If you're applying this to a chassis cluster, you may need to replace the line:
for-each ($policies-list/security-context/policies) {
with
for-each ($policies-list/multi-routing-engine-item/security-context/policies) {
Enjoy,
Ben
On 24/09/2013, at 4:43 PM, Maarten van der Hoek maar...@vanderhoek.nl wrote:
Hi Ben,
Did you succeed in building that script ?
(e.g. do you have it somewhere ? ;-) )
We've been playing with exports and then import in Excel...but still not
very nice..
A better solution would be nice.
(we can't you Junos-Space / or so because most deployments are in separate
Small / Branch offices)
Brgds,
Maarten van der Hoek
-Oorspronkelijk bericht-
Van: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Namens Ben
Dale
Verzonden: dinsdag 24 september 2013 6:46
Aan: Edward Dore
CC: juniper-nsp@puck.nether.net; Harri Makela
Onderwerp: Re: [j-nsp] SRX Command
After I spent a bit of time building an op script to print policy matches
out in a nicely formatted table, I notice that this feature is now available
for all policies even without the then count action from 12.1:
show security policies hit-count
Cheers,
Ben
On 24/09/2013, at 8:45 AM, Edward Dore
edward.d...@freethought-internet.co.uk wrote:
You'll need to add the count action to the then statement on each
security policy if you want to track the number of times that the policy has
been matched.
Edward Dore
Freethought Internet
On 23 Sep 2013, at 23:08, Harri Makela wrote:
Hi All
Is there any command in SRX which I can use to check number of times FW
policy has been used. Actually I want to clear all FW policies which are
not being used for last 12 months or so. I don`t know much about scripting
but can try to get some help if I can think of a command which can be rung
through different zones combinations.
Thanks in Advance !
HM
___
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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Command
Harri,
As per the link below - add then count to all your policies (using the
following apply-group will do this quickly for you):
set groups COUNT-ALL security policies from-zone * to-zone * policy *
then count
set apply-groups COUNT-ALL
If you install the op-script provided and run it after a month or so, it will
show you pretty quickly which policies are being used, but if you don't want to
use an op script, try:
run show security policies detail | match Policy:|zone|lookups
Again - the lookups field will only be there if the policy has count enabled.
Cheers,
Ben
On 24/09/2013, at 10:37 PM, Harri Makela harri_mak...@yahoo.com wrote:
Thanks for lookup
We have JUNOS Software Release [10.4R5.5] and it doesn`t look like that we
have the option indictaed in last mail
admin@SRX-3600-P show security policies ?
Possible completions:
[Enter]Execute this command
detail Show the detailed information
from-zoneShow the policy information matching the given source
zone
policy-name Show the policy information matching the given policy
name
to-zone Show the policy information matching the given
destination zone
|Pipe through a command
{primary:node0}
admin@SRX-3600-P show security policies hit
^
I can capture all duplicate policies and delete which are not required for
same flow but the ones which are not being used and are there for nothing, I
would like to delete them. Not sure how I can accomlpish that with a JUNOS
command which I have to run in parallel with a shell script.
Looking forward to get some feedback.
Thanks
HM
From: Ben Dale bd...@comlinx.com.au
To: Edward Dore edward.d...@freethought-internet.co.uk
Cc: Harri Makela harri_mak...@yahoo.com; juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.net
Sent: Tuesday, 24 September 2013, 5:45
Subject: Re: [j-nsp] SRX Command
After I spent a bit of time building an op script to print policy matches out
in a nicely formatted table, I notice that this feature is now available for
all policies even without the then count action from 12.1:
show security policies hit-count
Cheers,
Ben
On 24/09/2013, at 8:45 AM, Edward Dore
edward.d...@freethought-internet.co.uk wrote:
You'll need to add the count action to the then statement on each
security policy if you want to track the number of times that the policy
has been matched.
Edward Dore
Freethought Internet
On 23 Sep 2013, at 23:08, Harri Makela wrote:
Hi All
Is there any command in SRX which I can use to check number of times FW
policy has been used. Actually I want to clear all FW policies which are
not being used for last 12 months or so. I don`t know much about
scripting but can try to get some help if I can think of a command which
can be rung through different zones combinations.
Thanks in Advance !
HM
___
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] SRX Command
After I spent a bit of time building an op script to print policy matches out in a nicely formatted table, I notice that this feature is now available for all policies even without the then count action from 12.1: show security policies hit-count Cheers, Ben On 24/09/2013, at 8:45 AM, Edward Dore edward.d...@freethought-internet.co.uk wrote: You'll need to add the count action to the then statement on each security policy if you want to track the number of times that the policy has been matched. Edward Dore Freethought Internet On 23 Sep 2013, at 23:08, Harri Makela wrote: Hi All Is there any command in SRX which I can use to check number of times FW policy has been used. Actually I want to clear all FW policies which are not being used for last 12 months or so. I don`t know much about scripting but can try to get some help if I can think of a command which can be rung through different zones combinations. Thanks in Advance ! HM ___ 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] Automation of EX code upgrade
If you're talking green fields (out-of-the-box) then there are a couple of ways depending on the current Junos release the switch is running: 12.2 - Automatic Software Download http://www.juniper.net/techpubs/en_US/junos/topics/task/configuration/ex-series-software-automatic-download-upgrading.html =12.2 - Zero Touch Provisioning http://www.juniper.net/techpubs/en_US/junos12.2/topics/concept/software-image-and-configuration-automatic-provisioning-understanding.html Try to stagger upgrades if you can, or learn the effects of having a hundred switches hitting a TFTP server for a ~110MB image file. Neither of these methods will display the success of the upgrades though. If your switches are already deployed, then a better way to do it is with Junos Space. The nice thing about the Space method is that you can upgrade smaller groups of switches at a time, pre-stage the images up to each switch and schedule the entire process. Each upgrade is given a Job ID and that Job ID will return success or failure depending on the outcome, even in the pre-staging if you don't have room on your flash for the image.. This functionality is built into the base Space platform too, which you can download and install with a 60(?)-day trial license. Cheers, Ben On 20/09/2013, at 8:04 AM, Mick Burns bmx1...@gmail.com wrote: Hey all, I am looking for ideas/previous experience in the best way to automate the upgrade of multiple (let's say about a hundred units) EX switches in large datacenters. Let's assume here they are a mix of 3200 and 4200 and all of them runs the same JunOS release. Any failure must be quickly identified for a manual upgrade. Any help or advice is much appreciated. Mick B. ___ 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] TCN guard on Juniper EX
Hi Dennis, The closest thing Junos has at the moment is root-guard, which would stop your Netgears assuming root for the topology, but AFAIK TCNs would still be accepted and acted upon. Are your netgear boxes manageable? You can't force ports into edge mode to stop this? On 11/09/2013, at 8:18 PM, Dennis Hagens r...@ipaddr.nl wrote: Hi All, Is there some way to filter out STP TCN BPDU's on a Juniper EX series switch? We have some old Netgears in our office environment (yes, I need to get rid of those) which send TCN's on edge port flaps. This causes a lot of reconvergence / mac table flushes on our datacenter switches, which are connected via layer 2 with the office. We currently hooked up an HP switch with TCN guard to mitigate this, but this introduces a SPOF. Any ideas? Thanks, Dennis Hagens ___ 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] how check MAG SA's cpu and memory
If you boot the device up with a console cable attached, you'll get the BIOS dump to serial. In the case of a MAG2600, it's running an Intel Atom @ 1.6Ghz and has 2GB of RAM: AMIBIOS(C)2006 American Megatrends, Inc. JPR-PICCOLO-2NBP (B150) V1.3 PN (10/18/2010) CPU : Genuine Intel(R) CPU N270 @ 1.60GHz Speed : 1.60 GHz The MCH is operating with DDR2-533/CL4 in Single-Channel Mode Initializing USB Controllers .. Done. 2040MB OK Cheers, Ben On 04/09/2013, at 4:26 PM, 徐见 xujia...@gmail.com wrote: Hi all: As the title said, I want to know SA and MAG’s cpu and memory information, I have a box, MAG2600, how do I get them, or where could I get them from internet? I have checked the datasheets, no message. ___ 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] QinQ termination on branch SRX
Hi Darren,
On 02/09/2013, at 7:34 PM, Darren O'Connor darre...@outlook.com wrote:
Does anyone know if this is supported on branch SRX devices yet? The only
thing I can find is a thread from two years ago stating 'we are working on
it' -
http://forums.juniper.net/t5/SRX-Services-Gateway/Terminating-q-in-q-on-a-SRX220h/td-p/104350
I'm trying to get the equivalent of the Cisco config:
interface gi0/1.10
encap dot1q 200 second-dot1q 10
ip address x.x.x.x
This came in 12.1X44D10:
http://www.juniper.net/techpubs/en_US/junos12.1x44/topics/concept/security-interface-vlan-tagging-configuring.html
You'll need something like this:
bdale@clx-bdr# show interfaces fe-0/0/4
flexible-vlan-tagging;
unit 50 {
vlan-tags outer 200 inner 10;
family inet {
address 172.17.17.1/24;
}
}
Cheers,
Ben
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPN tunnel between OpenSwan and SRX220
Hi Laurent. Is your ultimate goal to get the GRE running over IPSEC, or just a vanilla IPSEC tunnel? Your configuration will need to change either way: If you want GRE over IPSEC: You need to remove the /32 on the st0.0 interface and the Openswan rightsourceip and make them a contiguous subnet eg: 172.31.254.41/30 on the Juniper side 172.31.254.42/30 on the Openswan side Now adjust your GRE configuration to use these addresses for source and destination on both ends Now adjust your remote proxy-id on the SRX and leftsubnet on Openswan to match (just the IPs, leave the mask as /32). The logic behind this is that you will only encrypt traffic between 172.31.254.41/32 and 172.31.254.42/32 which will be your GRE tunnelled traffic (all other traffic will be wrapped up inside this GRE). As an aside - the last time I checked, the SRX seemed to only use the Proxy-ID to negotiate the tunnel and then promptly ignored it and allowed you to send and receive whatever traffic your routes and policy allowed. If you're just trying to do vanilla IPSEC tunnels: Again, change the /32s on the st0.0 and Openswan rightsourceip: 172.31.254.41/30 on the Juniper side (or leave it unnumbered) 172.31.254.42/30 on the Openswan side Now on the SRX change your proxy-id local to 192.168.123.0/24 and remote to whatever is sitting behind the Openswan box (eg: leftsubnet) On Openswan, change the right-subnet to 192.168.123.0/24 and left-subnet to whatever you're trying to tunnel across (or leave it as-is if it's just this host, or you're source-natting) Once you've got this in place and st0.0 comes up, you'll just need to point static routes on the SRX side to st0.0 or the Openswan next-hop (172.31.254.42) and vice-versa. If it's still not working, send through the output of: show security ipsec security-associations Cheers, Ben On 07/08/2013, at 1:55 AM, Laurent CARON lca...@unix-scripts.info wrote: Hi, I'm trying to establish a VPN tunnel between a SRX220 and an OpenSwan box. SRX is: Model: srx220h JUNOS Software Release [12.1X44-D20.3] OpenSwan: 2.6.37 Both are currently hooked on a test LAN. 192.168.0.18 = openswan box on lan 192.168.0.120 = juniper box on lan 172.31.254.41 = ipsec on juniper box 172.31.254.27 = ipsec on openswan box 172.31.255.27 = loopback on juniper box Not relevant for now: 10.254.2.33 = gre tunnel on openswan side 10.254.2.34 = gre tunnel on juniper side Here is the config on the Juniper side: set interfaces ge-0/0/0 mtu 1514 set interfaces ge-0/0/0 unit 0 family inet address 192.168.0.120/24 set interfaces gr-0/0/0 unit 0 tunnel source 172.31.254.41 set interfaces gr-0/0/0 unit 0 tunnel destination 172.31.254.27 set interfaces gr-0/0/0 unit 0 family inet address 10.254.2.34/32 set interfaces lo0 unit 0 family inet address 172.31.255.41/32 set interfaces st0 unit 0 family inet address 172.31.254.41/32 set interfaces vlan unit 0 family inet address 192.168.123.1/24 set routing-options static route 172.31.254.27/32 next-hop st0.0 set security ike traceoptions file vpn-debug-ike set security ike traceoptions flag all set security ike proposal ike_aes_128 authentication-method pre-shared-keys set security ike proposal ike_aes_128 dh-group group2 set security ike proposal ike_aes_128 authentication-algorithm sha1 set security ike proposal ike_aes_128 encryption-algorithm 3des-cbc set security ike proposal ike_aes_128 lifetime-seconds 3600 set security ike policy phase1_aes_128 mode main set security ike policy phase1_aes_128 proposals ike_aes_128 set security ike policy phase1_aes_128 pre-shared-key ascii-text pwd set security ike gateway RTR-SIEGE-001 ike-policy phase1_aes_128 set security ike gateway RTR-SIEGE-001 address 192.168.0.18 set security ike gateway RTR-SIEGE-001 no-nat-traversal set security ike gateway RTR-SIEGE-001 external-interface ge-0/0/0.0 set security ipsec proposal ipsec_aes_128 protocol esp set security ipsec proposal ipsec_aes_128 authentication-algorithm hmac-sha1-96 set security ipsec proposal ipsec_aes_128 encryption-algorithm 3des-cbc set security ipsec proposal ipsec_aes_128 lifetime-seconds 3600 set security ipsec policy phase2_aes_128 proposals ipsec_aes_128 set security ipsec vpn VPN_TO_SIEGE-001 bind-interface st0.0 set security ipsec vpn VPN_TO_SIEGE-001 ike gateway RTR-SIEGE-001 set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity local 172.31.254.41/32 set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity remote 172.31.254.27/32 set security ipsec vpn VPN_TO_SIEGE-001 ike proxy-identity service any set security ipsec vpn VPN_TO_SIEGE-001 ike ipsec-policy phase2_aes_128 set security ipsec vpn VPN_TO_SIEGE-001 establish-tunnels immediately set security flow traceoptions file vpn-debug set security flow traceoptions flag basic-datapath set security flow traceoptions flag packet-drops set security flow tcp-mss ipsec-vpn mss 1412
Re: [j-nsp] Config archive subtleties
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 single file-name rather than appending the date and let your existing version control handle the diffs - checking it into git/subversion rather than just copying it to upstream folder (hey, a guy can dream) On 08/08/2013, at 5:25 AM, Phil Shafer p...@juniper.net wrote: 7 aug 2013 kl. 18:03 skrev Phil Mayers p.may...@imperial.ac.uk: Recently this fell apart on us, as the SSH key on the server changed and the archival transfers started to silently[1] fail. Ick. Silence is deadly. This (and the other issues) is now PR 910647. All of which has me wondering if the feature is more trouble than it's worth. We definitely should be making it more robust and stable, but to me the value of catching each commit as a distinct delta is a win. It should also have the commit time, user, and commit comment, if given. Having this in a repo means one can ask questions like who has changed config in my network since last Friday? or when did this statement get added in the first place?. What else can we do to make this more worthwhile? Thanks, Phil ___ 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] LN2600: an 8SFP Branch SRX
I have one here on my desk and on paper, they're basically an SRX240 wrapped in 7kgs of heatsink (with SFP interfaces). Of note though is that they do stack up rather well against unmanageable honey badgers: http://www.flickr.com/photos/junipernetworks/9394081849/ Cheers, Ben On 03/08/2013, at 2:12 AM, Phil Fagan philfa...@gmail.com wrote: Makes sense; good to see Juniper...and SRX...in that field. On Fri, Aug 2, 2013 at 10:08 AM, Eduardo Barrios eduardo.barr...@lcra.orgwrote: Rugged means it's IEEE1613 compliant. For the electric utility companies these devices go in substations so they need to keep forwarding packets when introduced in those environments with higher temperatures and a lot of EMI (Electro Magnetic Interference) - can't blame it on the solar flare theory. ;-) Also utilities are beginning to run their protective relay protocols through IP networks so they are looking for reliability or risk blowing out $2mil transformers. I've been testing the LN2600 and yes it does run the SRX code. HTH, Eduardo Eduardo Barrios, EIT, JNCIS-SP IP/MPLS Telecommunications Specialist Lower Colorado River Authority | 3505 Montopolis Dr. | Austin, TX 78744 512.730.6332 ph -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Phil Fagan Sent: Friday, August 02, 2013 10:12 AM To: Julien Goodwin Cc: juniper-nsp Subject: Re: [j-nsp] LN2600: an 8SFP Branch SRX Where do these rugged devices usually get put? Just outdoors? On Fri, Aug 2, 2013 at 8:05 AM, Julien Goodwin jgood...@studio442.com.au wrote: Saw this come through on my RSS reader, it's worth a shout out as I'm sure more people than just me have been wanting a branch SRX with decent SFP density there's finally an option. http://www.juniper.net/us/en/products-services/routing/ln-series/ln2600/ I'm assuming it runs the same branch SRX image as the rest of the line as that's been true for the LN1000 and this looks like more of the same. It's 48v only which is a shame, and being a rugged device I'm sure it's reassuring expensive. Also hidden in the datasheet is a reference to an LN2800 which has not been announced, but is obviously a similar rugged 1ru box of some sort. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Phil Fagan Denver, CO 970-480-7618 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Phil Fagan Denver, CO 970-480-7618 ___ 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] EX4550 version
I believe 12.3R2 still has the bug where the syslog fills up with erroneous messages about one or both of the power supplies being removed (12.3R1 complains about the fan tray AND the power supplies). This is finally put to bed in 12.3R3 Cheers, Ben On 24/07/2013, at 7:56 PM, Pierre-Yves Maunier j-...@maunier.org wrote: I'll be deploying a couple of EX4550 doing mainly L3/MPLS stuff (ospf, bgp, l3vpn, l2circuit) and I'm going to roll out 12.3R3.4. Generally I prefer using at least an R3 release and as Juniper promised me that 12.3 would be 'the next 11.4' then I'm going for this one. 2013/7/24 Luca Salvatore l...@ninefold.com: Hi All, Just got a couple of new EX4550 switches... current recommended version is 12.2r2.5 But I just saw tha the 12.2 train is up release 5.3. Just wondering what the rest of you guys are running and if you have any horror stories. I'm not doing VC with these guys, they are going to be a pretty simple layer 2 aggregation type switch. Thanks. ___ 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] SRX devices upgraded to 2GB ram
On 24/07/2013, at 12:53 AM, Pavel Lunin plu...@senetsy.ru wrote: 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. Not sure how close those applications are. Some more UTM apps? That's true, but there is a caveat (apart from the minimal JUNOS version). Although I haven't asked local SE, I'm sure the -H2 models won't cluster with the old SRXes. So people planning to upgrade their already installed SRXes to clusters must either speed up or they will need to buy two boxes instead of one. EoL for old models is 31 Dec 2013 but the channels will obviously hold the new models as soon as they get rid of old stocks. Not even remotely true - I have a 240H and a 240H2 clustered together on my desk right beside me - no issues.. Unscientifically, the H2 does seem to boot faster so make it your primary when you can ; ) This transition isn't that big a deal - it's happened plenty of times in the past. J-Series with 256MB RAM and flash anyone? Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 version
I pulled one out of the box the other day and whatever it shipped with wouldn't bring up 10G DAC cables (Cisco branded) and the backlight on the LCD panel didn't work (?!!) until I upgraded it (12.3R3), which fixed both issues. On 24/07/2013, at 2:49 PM, Mark Tinka mark.ti...@seacom.mu wrote: On Wednesday, July 24, 2013 03:27:23 AM Luca Salvatore wrote: Just got a couple of new EX4550 switches... current recommended version is 12.2r2.5 But I just saw tha the 12.2 train is up release 5.3. Just wondering what the rest of you guys are running and if you have any horror stories. I'm not doing VC with these guys, they are going to be a pretty simple layer 2 aggregation type switch. We've been running ours since January this year, and back then, only 12.2R2.4 was available for the chassis. Nothing major on our end, just pure Layer 2 aggregation in the core. Haven't seen any problems yet, but our deployment isn't that interesting. I use them mostly for the port speed. Mark. ___ 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] limitation to vrrp-group inheritance on MX?
Hi Clarke,
Even though you have vrrp-inherit-from enabled, the interfaces are still
participating in VRRP, albeit at a much slower rate (just enough to keep
downstream ARP refreshed) so the MX is still allocating a specific VRRP MAC per
group and thus the 255 limit still applies per interface.
See
http://www.juniper.net/techpubs/en_US/junos11.4/topics/task/configuration/vrrp-inheritance-for-a-group-configuring.html
And in particular:
the groups that are inheriting the state do send out VRRP advertisements once
every 2 to 3 minutes so as to facilitate MAC address learning on the switches
placed between the VRRP routers.
Cheers,
Ben
On 23/07/2013, at 7:18 AM, Clarke Morledge chm...@wm.edu wrote:
It looks like there is a limitation as to the number of times you can inherit
settings from a particular vrrp-group on a single interface, but is this
correct?
Assume you have a single vlan with multiple IP subnets configured. However,
all you need is to have a single vrrp-group where all of the other IP subnets
can inherit vrrp config information from, let's say, the vrrp group with the
preferred address. For example:
[edit interfaces irb unit 100]
MX# show
family inet {
address 192.168.37.3/25 {
preferred;
vrrp-group 100 {
priority 125;
accept-data;
virtual-address 192.168.37.1;
}
}
address 192.168.38.3/25 {
vrrp-group 101 {
virtual-address 192.168.38.1;
vrrp-inherit-from {
active-interface irb.100;
active-group 100;
}
}
}
address 192.168.39.3/25 {
vrrp-group 102 {
virtual-address 192.168.39.1;
vrrp-inherit-from {
active-interface irb.100;
active-group 100;
}
}
}
}
For each IP address configured on the IRB interface (associated with one
particular vlan), you must have a DIFFERENT vrrp-group configured, even
though the inheriting addresses are only effectively using the vrrp-group
number as unique identifiers and place holders.
If you try to use the SAME vrrp-group number for each address; e.g. 100,
you get a configuration error upon commit:
Duplicate interface: irb unit: 100 vrrp-group: 100 for address:.
Vrrp has a limitation as to the nunmber of groups available per vlan, 255.
Granted, having more than 255 addresses per interface is a lot, but it seems
arbitrary that the MX limits you to only having 255 IP subnets per vlan that
can use VRRP.
Having a maximum of 255 VRRP active groups per vlan makes sense, as this is
what the VRRP standard specifies, but when you have a bunch of basically
inactive groups that inherit from one active group, it seems bizarre that
Junos says, NOPE, you can only have a maximum of 254 placeholders for
inactive vrrp groups per interface.
Am I misunderstanding something here?
Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones Hall (Room 18)
Williamsburg VA 23187
___
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] Advice on a 100Gbps+ environment
The QFX3600 is probably a little expensive for L2, but 64x 10GE ports in a 1RU ToR (or 16x 40GE, or a combination in the middle) is pretty solid. According to the docs they also support link aggregation up to 32 members[1]. Would be interesting to know if this allows 40GE ports to be used natively in an aggregated ethernet... [1] http://www.juniper.net/techpubs/en_US/junos12.3/topics/reference/general/qfx-series-software-features-overview.html#high-availability-features-by-platform-table On Tue, Jul 2, 2013 at 11:00 AM, Morgan McLean wrx...@gmail.com wrote: Wow, this thread snowballed into quite the MX80 debate. For the record, I run two in production where I am employed full time and they perform beautifully, though woefully underutilized. Using static routes and /32's as peering endpoints is a great option I skimmed over, I'll see if the upstream can do this...they should. Unfortunately, the customer signed the contract for bandwidth with inteliquent; we have existing 10G with telia and 10G with cogent along with a couple existing 10G from inteliquent, but I'm not sure if they'll stay. So I didn't really have much say...I think the price point was more important than the benefits of signing to a few carriers. In short, I'm working on that. This traffic should be mostly web. Sorry, I meant to say OSPF and ECMP. I would like to be able to run the VRRP at the end of row and extend L3 as far as I can, but I guess the customer wants to be able to spread machines in the same environments among multiple rows, which is understandable, but that means I need to run L2 from distribution to access. Each row needs 100gbps useable, so I suppose 4 x 40GBE LAGs would do the trick nicely. If my client doesn't want to spend the money in that area... Any good aggregation switch suggestions? Juniper is doesn't provide good ports for $ in the switching realmcustomer balked at the cost for a four port 40G blade on a 9200. Might check out brocade.. Thanks, Morgan On Tue, Jul 2, 2013 at 8:13 AM, Christian de Balorre cdebalo...@neotelecoms.com wrote: Slow control-plane. No RE redundancy. More limited rib fib than regular MX. Cryptic licensing scheme. Otherwise nothing really wrong. Christian Le 02/07/2013 15:55, Drew Weaver a écrit : And what is wrong with the MX80 as a peering/transit router for up to 80Gbps of traffic? Thanks, -Drew -Original Message- From: juniper-nsp [mailto:juniper-nsp-bounces@**puck.nether.net juniper-nsp-boun...@puck.nether.net] On Behalf Of Dobbins, Roland Sent: Tuesday, July 02, 2013 9:01 AM To: juniper-nsp Puck Subject: Re: [j-nsp] Advice on a 100Gbps+ environment On Jul 2, 2013, at 7:19 PM, Mark Tinka wrote: Says who? Doh - MX*480*, not MX*80*. My mistake. --**--** --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton __**_ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/**mailman/listinfo/juniper-nsp 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 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 https://puck.nether.net/mailman/listinfo/juniper-nsp -- Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] similar ASA feature (RRI) on SRX
On 25/06/2013, at 7:08 AM, OBrien, Will obri...@missouri.edu wrote: You can just point the route at the st0.x interface. When it's down, the route won't install in the table. Just watch this in 11.4R5.5 (and others nearby) - there was a bug introduced that kept the state of the tunnel sub-interface up even once the security associations were cleared. Fixed in 12.1R4 (at least). On Jun 24, 2013, at 3:57 PM, Alberto Santos wrote: Hi, it looks like a possibility, but the remote IP address keeps changing because it is dialup connection. can't monitor the next hop. BR Alberto Santos CCIE #26648 JNCIS-SP - ITIL-F ...Fix your DNS, make it dual-stack, take your mail server and make it dual-stack, take your web server and make it dual-stack... by Randy Bush/RIPE IPv6 On 24 June 2013 13:15, OBrien, Will obri...@missouri.edumailto:obri...@missouri.edu wrote: https://kb.juniper.net/InfoCenter/index?page=contentid=KB24362 On Jun 24, 2013, at 8:38 AM, Alberto Santos wrote: Hi there, I'm swapping a cisco ASA and I found myself stuck on how configure any similar to cisco RRI(reverse route injection) feature on junos,I'm load balacing with a BigIP between them and I need to know where the tunnel is active in order to advertise it on OSPF, has anyone experience any in the past? please send your thoughts, just keep in my that I can't run any IGP over the tunnel . BR/Alberto ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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] SRX to vshield lan2lan
Hi Klaus, I just had a quick peek in the vShield manual - it looks like it only supports IKEv2, so you'll need to add the following line to your config: set security ike gateway gw_lan_to_remote version v2-only Ben On 21/06/2013, at 4:35 AM, klauzi kla...@gmail.com wrote: Just wanted to double check that the interface is assigned to a zone at least. Did you try to enable the traceoptions under security ike to get more information? Best way is, that you are the responder in ike negotiation. Make sure that the other side initiates the ike traffic There is a document regarding vpn troubleshoooting: Search for: JSeries_SRXSeries_Route-based_VPN_to_ScreenOS_v13.pdf edit security ike traceoptions set file size 1m set flag policy-manager set flag ike set flag routing-socket commit Regards, Klaus On Thu, Jun 20, 2013 at 6:58 PM, bizza biz...@gmail.com wrote: Actually is assigned to WAN zone. Should I put it in LAN (where policies and other stuffs are)? Regards bizza On Thu, Jun 20, 2013 at 6:54 PM, Klaus Groeger kla...@gmail.com wrote: Did you assign the st0.x interface to a zone? -- bizza http://www.rm-rf.eu/ -- nil extimescere ___ 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] Share static routes between routing-instances on EX series
Hi Andy, On 19/06/2013, at 9:29 AM, Andy Litzinger andy.litzin...@theplatform.com wrote: SNIP I will try rib groups next, but I think I read somewhere that EX switches don't support importing static routes via rib groups. I suppose this could also be solved by Filter Based Forwarding, but I'd like to avoid that if possible; it just doesn't seem as clean. thanks in advance! -andy The normal way to do it would be to have your static route with a next-table action, however it doesn't look like the EX (12.3) gives you that option (SRX and MX - no problem). Which leaves you with either filter-based forwarding and the routing-instance action / rib-groups. Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BOOTP helper on MX vrf
It's also now available on the SRX as of 12.1X44D10. One to watch though - Mac OSX and most other non-windows clients will fail to get an address from the JDHCP daemon because they set the BOOTP Unicast flag on all requests, whereas Windows will fall-back to broadcast after 30 seconds. The following command will fix it even though the text of the knob says the complete opposite of what it seems to do: set system services dhcp-local-server group BLAH interface BLAH overrides no-unicast-replies (or under your routing-instance) Ben On 13/06/2013, at 9:03 PM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: 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 don't want bootp helper on *every* interface, just a few. So any information regarding this is appreciated. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] I've got some bone head problem on an srx...but I don't see it.
On 12/06/2013, at 11:29 AM, Morgan McLean wrx...@gmail.com wrote: I have an SRX cluster at an office with a single connection to the web at the moment. It has a couple ipsec connections out to our datacenters, and a couple local subnets hanging on RETH interfaces. For the life of me, I can't figure out why I'm unable to ping out from this system. Even if I try to ping the point to point between us and Verizon, a direct route, it won't work unless I specify the source address as our local interface address. Outbound nat from clients behind the SRX works fine. The loopback is in trust, and I have a couple zones + trust with a source nat rule using the verizon interface IP as the egress point. Destination nat rules work. So everything seems to work...except from the SRX. As a result, we cannot ping the SRX remotely...but again IPSEC works. Any great tips? None of our other SRX's behave like this...and its driving me nuts! Being a cluster, this isn't fxp0 interface shenanigans is it? Do you have the managemen function zone applied to fxp0? Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [OT] unit-level vs interface-level description
On 28/05/2013, at 12:58 AM, Nick Kritsky nick.krit...@gmail.com wrote: Hi fellow J-users, I hope I will not trigger some long-forgotten flame-war by that question. But I do wonder: what are the best practices for interface/unit descriptions? Do you put them on interface-level or unit-level? Especially when you have pure-L3 interface that only has unit 0 with family inet on it. Do you put description to interface level? Unit level? Or both levels? Or do you put it on both levels but different descriptions? I've seen people using different approaches, and I am just curious what's driving them. For external links I tend to roll with: set interfaces ge-0/0/0 description Connected to (Device X Port Y) set interfaces ge-0/0/0 unit 0 description Circuit ID / Carrier Description Where I'm talking to kit I control/where available, I tend to leave the physical stuff to something more accurate and self-updating like LLDP. On my to do list is writing an event-script that checks interfaces with LLDP neighbours every 24 hours or so and updates interface descriptions appropriately. Driving my approach is being 6 stanzas deep in a config and being able to run top show interfaces ? and getting a nicely summarised list of the ports I should be referencing. Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Maximum IPsec (st0) tunnels for SRX-series
As long as your tunnels don't breach the IPSEC Throughput numbers, you should be right™. I have a few SRX240s out there with upwards of 500 tunnels on them, some dynamic routing (3 core sites only), and they're sitting at around 50% CPU. They're all running DPD with intervals of 10 and 3 (which I think is as low as you can go). The scaling numbers I've seen for SRX1400s (for route-based VPNs) are the same as SRX3600s, and about double what the data sheet numbers currently show. Ben On 06/05/2013, at 10:02 AM, Dale Shaw dale.shaw+j-...@gmail.com wrote: Hi all, Just looking for some real-world experience with the maximum practical number of IPsec tunnel (st0) interfaces supported on SRX-series -- everything from low end/branch up to high end. The data sheets say: SRX100: 128 SRX110: 128 SRX210: 256 SRX220: 512 SRX240: 1,000 SRX550: 2,000 SRX650: 3,000 SRX1400: ? SRX3x00: 7,500 SRX5x00: 15,000 Those are some pretty hefty numbers as you move up the product family but as we all know, sometimes data sheets are pure fantasy, dreamt up by sales/marketing types after lavish and expensive liquid lunches. I just wanted to know if anyone's seen control planes turn into molten goop trying to wrangle, say, 100-150 tunnels. (I'm not worried about forwarding performance as all I'm looking at doing is fully-meshing an existing enterprise WAN where the SRX boxen are doing a great job shuffling packets (er, I mean flows) around.) cheers, Dale ___ 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] SSG20 PBR to Web Proxy
Hi Josh, I would recommend putting the proxy in it's own subnet and zone (even just a /30 off to the side). Then you can apply policy routing on your external interface for inbound traffic, and the LAN interface for your outbound traffic. If you let return connections go directly back to the client, I suspect that you're proxy won't end up being able to cache anything. Cheers, Ben On 01/05/2012, at 2:08 PM, Josh Farrelly j...@base-2.co.nz wrote: Hi guys. We have a customer who’d like to implement a transparent web proxy configuration using a Sophos Web Appliance. They sit behind an SSG20 that connects them to the Internet. I’m suggesting the proxy will have an IP in the LAN range. I’ve confirmed with Sophos that the proxy will correctly handle connections if we policy-route any packets matching a destination port of TCP 80 443 to it using the firewall, however I’m a little confused about how the return traffic should be handled. I don’t believe the proxy will rewrite the layer 3 address of the packets it sends out, so return traffic back from the external web servers will be (theoretically) sent back to the internal IP address, which is the client directly. Does anyone have any experience in implementing this, or any suggestions how we go about returning the traffic to the proxy and not directly to the end client? Any suggestions otherwise? Explicit mode on the proxy is not an option. Regards, Josh Farrelly Senior Project Engineer P +64 9 630 4095 M +64 21 919 885 E j...@base-2.co.nz PO Box 24666, Royal Oak, Auckland 1345. 126 Valley Rd, Mt Eden, Auckland 1024. www.base-2.co.nz image001.gif ___ 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] 3G/4G on SRX
Hi Jeff, To use the USB port on the branch SRX 100,110 or 210 as 3G/4G backup you need a sierra wireless modem. There are very few listed on Juniper's supported list, but at least here in Australia I've found that most available Sierra 3G modems tend to work including: USB306 SW312U AC326U AC310U SW319U 4G is a different story thanks to new chipsets/drivers and only the Sierra 320U seems to work. Depending on your carrier and the frequency that they operate at, you should be able to pick up unlocked SW cards on ebay or aliexpress pretty easily, then just drop your SIM in. The alternative is grabbing a Juniper CX111 wireless bridge (which is a Cradlepoint CBA750 OEM) - they support a much bigger range of cards and will work with pretty much any router. http://www.cradlepoint.com/compatibility Choose CBA750 in the Select Your Product menu on the right and you'll get the complete list: Ben On 02/05/2013, at 12:53 AM, Jeff Rooney jtroo...@nexdlevel.com wrote: Does anyone have any experience using a prepaid or month to month 3G/4G connection on a branch SRX? I am looking to replace a dial backup with a cellular connection, but the documentation is pretty weak and only references a Sierra Wireless AirCard. Any suggestions? Thanks. Jeff ___ 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] CoS Configuration
On 14/04/2013, at 1:32 PM, Giuliano Medalha giuli...@wztech.com.br wrote: Hi, Does anyone has some experience implementing CoS using Radius for MX Series with PPPoE License ? We are looking for a specific solution that: - Can allocate bandwidth of 1 Mbps for a subscriber user (PPPoE dynamic interface) for the first 1MB. - After the first 1MB we will need to reduce the bandwidth for 512 kbps. Witch mechanism or configuration we could use to do something similar to that ? Thanks a lot, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Hi Giuliano, Juniper's SRC platform will do this but if you just want something simple, standard RADIUS CoA on the MX will let you change CoS filters on the fly. You would simply trigger the CoA based on external events (such as accounting db information). To shape someone after only 1MB would mean that your accounting interval would have to be pretty short though. Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config changes on VC with member down
On 11/04/2013, at 10:08 PM, Luca Salvatore l...@ninefold.com wrote: HI, Quick question just for my own sanity :-/ If i make some config changes on a VC when one of the members is down, what happens to the config on the down member when it comes back up? I'm assuming it will just sync with the master right? That won't be a problem. Your Master and Backup REs keep the configuration for all members, so any changes will be pushed out when the down member is re-joined/replaced. Check this out if you need more detailed information on the process: http://www.juniper.net/techpubs/en_US/junos/topics/task/installation/virtual-chassis-ex4200-member-replacing-cli.html Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] port mirror on EX causing crash
Yep - listen to JTAC. The parity error is definitely a sign that the memory on your switch is flakey - I had an EX4200 completely lock-up and drop out of a VC after 6 months of flawless operation. Rebooted it and it came good, 24 hours later it dropped right back out again with the parity error again. RMA and everything is happy again. On 10/04/2013, at 2:50 PM, Luca Salvatore l...@ninefold.com wrote: Wondering if anyone has seen any issues with EX switches running port mirroring - specifically seeing the switch generate a 'parity error' and crashing? I have an EX4200 10.4r5.5, a few hours after turning on port mirroring the switch crashed. It threw some memory parity errors which JTAC tells me means the switch is faulty and should be replaced. The switch in question has been running fine for 3 years, but turning on a ingress and egress port mirror (on a single port) seems to make the switch have a bad day. The switch isn't busy, and the port that I'm mirroring has about 80 to 100Mb of traffic. I'm mirroring the port to an IDS and would like to keep it running for the foreseeable future. Any thoughts on this situation? Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 1000Base-T SFP shows Link Up without cable inserted
On 01/04/2013, at 5:55 AM, Mathias Sundman math...@nilings.se wrote: I've just upgraded two of my MX5-T boxes to 11.4R7.5 and after that my 3rd party 1000Base-T SFP (Transmode originals based on Finisar) started to show Link Up as soon as the SFP is inserted (no cable inserted). On 11.2R5.4 it worked as it should. 11.4R1.14 that the boxes came with was also broken. Bug or feature? Has anyone used any Juniper original 1000Base-T SFPs on the MX-5/10/40/80-T platform with JunOS 11.4? Both ; ) I've seen this a few times across various versions with different 3rd-party 1GBaseT transceivers. I don't know the specifics of why the issue is caused, but after swapping suppliers, and upgrading code, the issue appears to have gone away. I guess that is the risk of using 3rd party - I'm not sure how much luck you'll have logging a case ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
