Re: [j-nsp] J-series
Alex, I have some Canadian ISP service providers using J4350's and J6350's for exactly this application. Works Well. I can supply you their details if you wish. They report no issues whatsoever, and are pleased to be using JunOS (finally) after years of IOS. Chris Kawchuk ([EMAIL PROTECTED]) Systems Engineering, Service Providers Juniper Networks Inc., Canada (866) 470-8174 toll-free -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Campbell Sent: Monday, May 07, 2007 11:08 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] J-series Hi all, I'm considering running a pair of J4350s on the border of a small hosting provider network. We'll be running VRRP, OSPF, some very basic ACLs, and taking 2 or 3 full BGP feeds. Expected traffic range is 50-100mbps total. If anyone has had any experiences running J4350s or J6350s in this sort of application, I would be most grateful to hear them on- or off- list. Alex ___ 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] Line modules
Yes, most of the modules are supported in both the ERX-310 and the ERX-1440. Check the detailed ERX Module guide to see which specific MODs/IOAs that are supported in both platforms at http://www.juniper.net/techpubs/hardware/erx/junose82/hw-erx-module/nofr ames-collapsedTOC.html PDF version: http://www.juniper.net/techpubs/hardware/erx/junose82/bookpdfs/hw-erx-mo dule.pdf Cheers. - Chris. Chris Kawchuk ([EMAIL PROTECTED]) Systems Engineering, Service Providers Juniper Networks Inc., Canada local: +1 (403) 470-8174 toll-free: +1 (866) 470-8174 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of M.Mihailidis Sent: Thursday, November 01, 2007 2:19 AM To: Juniper-Nsp Subject: [j-nsp] Line modules hello all i was wondering can i install a line module from a erx-1440 to a erx-310? ___ 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 board memory expansion on M7i
Hi Rubens, JunOS 9.0+ will require 256MB of RAM on the routing engines to load properly. JunOS 9.0 is expected to be released in Q1 2008. Notes from the Juniper PSN: --- PSN Issue: The RE-400-256 Routing Engine contains only 256MB of main memory. Beginning with JUNOS release 9.0, this is insufficient to run JUNOS software; the minimum supported main memory configuration for JUNOS 9.0 and above is 768MB. Solution 1: The RE-400-256 Routing Engine is replaced with the RE-400-768. This new Routing Engine model includes 768MB of main memory, which meets the new minimum requirement. Solution 2: Implementation Customers with RE-400-256 Routing Engines are strongly urged to upgrade those Routing Engines to RE-400-768 before installing JUNOS release 9.0 or higher. This upgrade is accomplished by installing two MEM-RE-256-S memory upgrade modules. --- Hence, you will need to upgrade your RE-400's to 768 Mb of RAM on a go-forward basis in order to load the newer JunOS images starting in 2008. On a side note, I *always* suggest loading any router with the maximum amount of memory, since the Global Internet routing table isn't getting any smaller =) - Chris. Chris Kawchuk ([EMAIL PROTECTED]) Systems Engineering, Service Providers Juniper Networks Inc., Canada local: +1 (403) 470-8174 toll-free: +1 (866) 470-8174 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Thursday, November 01, 2007 9:27 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] System board memory expansion on M7i Hi. M7i routers can be ordered with 256 or 512 MB RAM system board memory; any guidelines on what usage scenarios would make 512MB desirable or even mandatory ? Our need is a Internet router with 3 full-routing transit feeds and a bunch of peering connections that made us specify more memory for the routing engine, but that may or may not impact forwarding engine requirements. AS and J-Flow are already included in the RFP. Rubens ___ 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 board memory expansion on M7i
Gotcha, You are correct. cFEB can be either 128 or 256. Again, since the cFEB has all the actual forwarding routes for the router's ASIC's, you mya be able to get away with only 128M for now, but again, as the global routing table gets bigger and bigger, you may run into a limit. Likewise, if you start adding L3VPNs, and add more and more MPLS/VPN routes, you will run into the 128 Mb limit quickly. Hence, 256M is strongly recommended. - Chris. -Original Message- From: Rubens Kuhl Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 11:01 AM To: Chris Kawchuk Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] System board memory expansion on M7i Chris, I always intended to fill-up RE memory with 768MB or more. My question was about CFEB memory, not RE memory... I stated that it can be ordered with 256 MB or 512 MB, but it's actually 128 MB or 256 MB. The MEM-FEB-256-S is an upgrade to 256 MB, not a 256MB increase. Rubens On 11/1/07, Chris Kawchuk [EMAIL PROTECTED] wrote: Hi Rubens, JunOS 9.0+ will require 256MB of RAM on the routing engines to load properly. JunOS 9.0 is expected to be released in Q1 2008. Notes from the Juniper PSN: --- PSN Issue: The RE-400-256 Routing Engine contains only 256MB of main memory. Beginning with JUNOS release 9.0, this is insufficient to run JUNOS software; the minimum supported main memory configuration for JUNOS 9.0 and above is 768MB. Solution 1: The RE-400-256 Routing Engine is replaced with the RE-400-768. This new Routing Engine model includes 768MB of main memory, which meets the new minimum requirement. Solution 2: Implementation Customers with RE-400-256 Routing Engines are strongly urged to upgrade those Routing Engines to RE-400-768 before installing JUNOS release 9.0 or higher. This upgrade is accomplished by installing two MEM-RE-256-S memory upgrade modules. --- Hence, you will need to upgrade your RE-400's to 768 Mb of RAM on a go-forward basis in order to load the newer JunOS images starting in 2008. On a side note, I *always* suggest loading any router with the maximum amount of memory, since the Global Internet routing table isn't getting any smaller =) - Chris. Chris Kawchuk ([EMAIL PROTECTED]) Systems Engineering, Service Providers Juniper Networks Inc., Canada local: +1 (403) 470-8174 toll-free: +1 (866) 470-8174 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubens Kuhl Jr. Sent: Thursday, November 01, 2007 9:27 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] System board memory expansion on M7i Hi. M7i routers can be ordered with 256 or 512 MB RAM system board memory; any guidelines on what usage scenarios would make 512MB desirable or even mandatory ? Our need is a Internet router with 3 full-routing transit feeds and a bunch of peering connections that made us specify more memory for the routing engine, but that may or may not impact forwarding engine requirements. AS and J-Flow are already included in the RFP. Rubens ___ 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] load balancing between juniper routers for unequal cost path
Build 2 MPLS LSPs to the destination router, turn on OSPF on those
shortcuts, and use ECMP. JunOS will see them as 2 completely identical
paths to the end-device, and load-balance across them.
Enable ECMP load balancing:
routing-options {
forwarding-table {
export load-balancing-policy;
}
}
policy-options {
policy-statement load-balancing-policy {
then {
load-balance per-packet;
}
}
Note that load-balancing per-packet is a misnomer, and a holdover back
to the Internet Processor #1 on the original M40/M20. We actually do
per-flow load balancing when this is enabled; so as not to upset the
path/timings/order of things like VoIP RTP packets.
- Chris.
Chris Kawchuk ([EMAIL PROTECTED])
Systems Engineering, Service Providers
Juniper Networks Inc., Canada
local: +1 (403) 470-8174
toll-free: +1 (866) 470-8174
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hamid Ahmed
Sent: Wednesday, November 07, 2007 9:25 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] load balancing between juniper routers for unequal cost
path
Hi Everyone,
CAn anyone suggest me how to load balancing between juniper routers for
unequal cost paths.
BR//
HA
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.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] load balancing between juniper routers for unequal costpath
Hi Hamid, As both Chuck and Leigh have stated, you CAN use GRE tunnels to do this, however, you will run into MTU size issues by doing this. You will also need tunneling/Adaptive Services/MultiServices PICs (or ASM cards if it's an M7i were dealing with) to do gre tunneling. The far cleaner way here is to follow Andy's suggestions and build 2 x RSVP signalled LSPs with strict routing options (EROs) so that they take different paths across your network, but appear to be the same metric to OSPF, hence, they will load balance. The other wacky off the wall way of doing this, is to purpusely mess around with your OSPF Metric values on the longer path (by explicitly stating their metrics and overriding what OSPF is putting on them), thus making the OSPF calculation at the ingress router see both OSPF costs as the same... however, I do *NOT* suggest going down this rabbit-hole. - It leads to tears... (plus any time you adjust your network, youd have to manually re-balance all your metrics again. aka a Netork Capacity Planner's worst nightmare...) - Chris. Chris Kawchuk ([EMAIL PROTECTED]) Systems Engineering, Service Providers Juniper Networks Inc., Canada local: +1 (403) 470-8174 toll-free: +1 (866) 470-8174 BTW, Andy L is a Juniper-Networks Resident Engineer (RE) as well for a Major ILEC =) I tend to trust what he says. =) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hamid Ahmed Sent: Friday, November 09, 2007 7:47 AM To: Andy Lamontagne Cc: juniper-nsp Subject: Re: [j-nsp] load balancing between juniper routers for unequal costpath hi Andy, Thanks for the detailed email. However i could get a better understanding if u can send me configuration snapshot. My intended traffic will use MPLS in the future but for time being i need to know if i can deploy GRE tunnels to compensate for OSPF unequal cost paths and then try load-balancing my pure IP traffic. regards, HA Andy Lamontagne [EMAIL PROTECTED] wrote: Hi Hamid, To control (or engineer) where you want traffic to go, you simply introduce MPLS LSPs. The beauty of MPLS is its Traffic Engineering characteristics. You can decide EXACTLY where you want your traffic to go. So, if you have 2 unequal paths, and you wish to load-balance between the 2, you simply need make the more expensive path appear to be less expensive, by creating those Label Switched Paths (LSPs). For example. Let us say that you have 3 routers connected in series (Router A, B and C) and that all links are GigabitEthernet. Router A also has a direct path to Router C (also GigabitEthernet) - see ascii diagram below: Router A -- Router B -- Router C |--| Now, with default settings, the shortest path from Router A is the direct link to Router C. The other link from Router A through Router B, then Router C is also a valid path, but at a higher cost. We have 2 unequal paths from Router A to Router C. You are looking to load balance between these 2 paths. To do so, you create an RSVP Signaled LSP from Router A to Router C (RSVP so that you can force the path of the LSP to use Router B as opposed to going directly from Router A to Router C) When you create this new LSP, it appears in the routing table inet.3. To be able to use this new route with OSPF, you must export it to the inet.0 routing table. Once the LSP is in inet.0, there will be 2 different, equal paths from Router A to Router C. At this point, you follow Chris' config to do the load balancing and your good to go. You're on the right track when you the talk about using 2x GRE tunnels, but do this with MPLS instead. I can still send you the config examples if you need it :-) -Andy On Nov 8, 2007 11:39 AM, Hamid Ahmed [EMAIL PROTECTED] wrote: Hi Andy, Thanks for your reply. 1) Can u send me a sample configuration of what u are saying with a brief explanation of your scenario? 2) You are giving the explanation for equal cost paths. However in my case there are two unequal cost paths. So my question still how can u do that in using unequal cost paths ? 3) Please explain when u say the following: What you will need to do is create 2 different RSVP Signaled LSPs towards the router which you want to add more traffic, then you need to export these 2 LSPs in OSPF (not turn OSPF off!) so that the routing protocol can see and use these 2 new paths. In the end, you will have 2 equals paths going in 1 direction, and a single path in the other. If you need to move more traffic, then simply add a 3rd, 4th, etc LSP. 4) The above discussion is for when we are doing work within MPLS. Now in my case my intended traffic (Voice) does not use MPLS(however MPLS is enabled but for some other traffic like sigtran and O/M). OSPF is there as IGP and i need to load balance my intended traffic using the unequal cost path. I
Re: [j-nsp] load balancing between juniper routers for unequalcostpath
Hi Paul, Agreed, however, with the load-balancing export mentioned earlier, JunOS does per-flow balancing, hence, any particular session (such as a VoIP call and a stream of UDP packets) will always use the same path; thus they will still arrive in the same order at the destination router. =) Different TCP or UDP sessions will indeed have ordering problems, assuming you are trying to co-ordinate multiple flows for the same set of services on different port numbers. However, each individual TCP-connection and/or UDP flow will indeed take the same path by the hashing algorithm. Good catch.! - Chris. -Original Message- From: Paul Goyette Sent: Friday, November 09, 2007 11:29 AM To: Chris Kawchuk; 'Hamid Ahmed'; 'Andy Lamontagne' Cc: 'juniper-nsp' Subject: RE: [j-nsp] load balancing between juniper routers for unequalcostpath As both Chuck and Leigh have stated, you CAN use GRE tunnels to do this, however, you will run into MTU size issues by doing this. You will also need tunneling/Adaptive Services/MultiServices PICs (or ASM cards if it's an M7i were dealing with) to do gre tunneling. The far cleaner way here is to follow Andy's suggestions and build 2 x RSVP signalled LSPs with strict routing options (EROs) so that they take different paths across your network, but appear to be the same metric to OSPF, hence, they will load balance. If the metrics reflect true costs and latency, then this could easily result in packet sequencing problems. The specific set of packets which would experience problems will depend on what how set the load-balancing hash-key fields. Just pointing this out in case you care... :) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cflowd ASN lookup
Ensure your stanza looks something like this:
forwarding-options {
sampling {
input {
family inet {
rate 10;
run-length 10;
max-packets-per-second 7000;
}
}
output {
cflowd 172.28.1.14 {
port 9996;
source-address 10.2.1.11;
version 5;
no-local-dump;
autonomous-system-type origin;
}
}
}
}
You may be missing the autonomous-system-type origin entry.
- Chris.
Chris Kawchuk ([EMAIL PROTECTED])
Systems Engineering, Service Providers
Juniper Networks Inc., Canada
Aden Bos wrote:
Hi,
I have configured cflowd on an m7i, but the flow data doesn't seem to
include the source or destination ASN (shows ASN0), apart from when I
am the source or destination. Any ideas what could cause this?
Thanks,
Aden
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Problem with firewall m-series
Hi Tom,
Try this:
term 1 {
from {
destination-address {
192.168.100.0/23;
}
protocol tcp;
destination port 8935;
}
then {
count good-traffic-to-192-168-100-0-23;
accept;
}
}
term 2 {
from {
destination-address {
192.168.100.0/23;
}
}
then {
count bad-packet-going-to-192-168-100-0-23;
log;
reject;
}
}
term 3 {
then {
accept;
}
}
First of all, match the traffic you want to allow, and let it through.
Then, match any other traffic going to that subnet and reject it,
3rdly, allow all other traffic. The terms are evaluated in order.
- Chris.
On 28-Jul-09, at 7:40 AM, Tom Mayer wrote:
Hi,
I just started with an m10 and setting up some firewall rules.
I know that default deny and permitting each individual service
seems the best way to go. But my problem is the following filter:
term 1 {
from {
destination-address {
192.168.100.0/23;
}
protocol-except tcp;
destination-port-except 8935;
}
then {
discard;
}
}
term 2 {
then accept;
}
I want on this link subnet 192.168.100.0/23 only tcp traffic on port
8935 allowed.
On all other subnets, any traffic should be allowed.
It seems that udp traffic on port 8935 to subnet 192.168.100.0/23 is
allowed when applied this filter.
May anybody tell me the right syntax for: traffic to
192.168.100.0/23, only tcp on port 8935 allowed. everything else for
this destination is discarded. everything else on this link is
allowed.
I am applying the filter on the downlink interface as output.
Thanks, Tom
___
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] monitor interface rate
You can override the SNMP-reported bandwidth of an interface by the
following:
interfaces {
ge-1/3/0 {
vlan-tagging;
unit 101 {
bandwidth 100m;
vlan-id 101;
family inet {
address x.x.x.x/x;
}
}
The bandwidth line is what will be reported as the SNMP interface
bandwidth of say, a VLAN interface. Note the original interface is 1G,
and all VLAns will also be reported as 1G. However, since I know this
interface eventually connects to a 100M LAN switch, I can set it
lower. Your SNMP manager will then read this during it's interface
collection/sweep, and do the calculation to see if it exceeds some pre-
defined threshold (50%, 70%, 90%) etc. Cacti does it (and can raise an
alarm), network-weathermap does it (and email you), etc...
Commercially, I use Intermapper for this - does it out of the box:
http://www.intermapper.com/
Regards,
- Chris.
On 13-Aug-09, at 7:06 AM, harbor235 wrote:
To all,
I would like to monitor a juniper router interface via snmp, simple
enough.
However, I do not want bps, I want to monitor the interface as a
percentage
of it's total capacity. In the end I want to be notified if my
interface
exceeds 70%
of capacity so I can initiate capacity management planning.
I know I can on an interface by interface basis figure out 70% and
program
that into
each interface collection, however, that does not scale. Is there
anyone out
there
that knows of a MIB obect that does this?
thanx,
Mike
___
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] EX3200 Interface Strangeness
EX3200 - You can add 10G ports without losing the 1G ports on the main board... has to do with the internal architecture. EX4200 - No loss of ports anywhere. It has a 3rd PFE chip which can handle the extra capacity. The problem lies with the fact that the EX3200 only has 2 PFE chips, while the EX4200 has 3 PFE chips. There is literally not enough wires on the EX3200 in order to support 4 x GE on the expansion slot as well as all the internal ports. However, the EX3200 does have wires hard coded for 2 x 10GE going to the expansion slot. - Chris. On 17-Aug-09, at 8:52 AM, Brendan Mannella wrote: What happens if a 10g card is installed? Do you lose the last two ports? And is this behavior the same on the 4200? On 8/17/09 10:41 AM, Bill Blackford bblackf...@nwresd.k12.or.us wrote: That makes sense. I'm not at all happy with it, but it makes sense. I'm am using ge-0/1/0 which must correspond to ge-0/0/20. Thanks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper Netflow
Hi There,
sampling {
input {
family inet {
rate 1;
run-length 1;
max-packets-per-second 65535;
}
This part has me worried. It says, Sample every packet, and the next
packet too. You might want to try this instead for sakes of clairity:
sampling {
input {
family inet {
rate 10;
run-length 9;
max-packets-per-second 65535;
}
This says Sample every 10 packets, and the next 9 after it (meaning
100%) of the packets).
Also:
max-packets-per-second 65535;
You may be running into (1) A limitation of pps, or (2) if you're
doing RE-Based netflow sampling, there is a limit of 7000 packets per
second (in order not to overflow the internal traffic/conuncations
pathways between the DPC card and the RE on the MX).
See
http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/configuring-traffic-sampling.html
Regards,
- Chris.
(Heh, it's nice to see someone using my template!) =)
On 2009-09-03, at 5:54 AM, Servet wrote:
Hi Guys
i have a problem with juniper netflow traffic values, i think there
is no problem about the config and flow-analyser. If i use a cisco
device, the results of snmp polls and results of the flow-analyser
are similar
But in juniper; i get 180 mbit/s traffic value with SNMP requests
from my juniper MX-960 router, but netflow says me it is 120mbit.
Also my sampling rate is 1.
You can see config below, do you have any idea? why i can't get
similar results from snmp and netflow
Kind regards
sampling {
input {
family inet {
rate 1;
run-length 1;
max-packets-per-second 65535;
}
}
output {
cflowd x.x.x.x {
port 9996;
version 5;
autonomous-system-type origin;
}
flow-inactive-timeout 600;
flow-active-timeout 60;
interface sp-4/1/0 {
source-address y.y.y.y;
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JunOS J/SRX in packet-mode vs flow-mode (was Re: software version to use?)
Hi Ross, It's uniform across J and SRX series from what I can tell (same code base jinstall-jsr-9.6R1.13). http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-admin-guide/config-selective-stateless-chap.html - Chris. On 2009-09-16, at 10:41 AM, Ross Vandegrift wrote: On Wed, Sep 16, 2009 at 08:07:13AM -0600, Chris Kawchuk wrote: 9.6 Offers the possibility of doing mixed flow-mode and packet- mode based on protocol, filter, or interfaces; meaning you can take advantage of the Security based flow/services/ALGs etc. on a J, while also enabling regular packet-mode throughput for the majority of your traffic (thus not running into any scaling limitations in terms of the session/flow table). Wow - I've been wanting something like for a while now. Do you happen to have a handy link to JUNOS documentation on this topic? Is support uniform or is this only on the J-series? That could be a pretty compelling reason for me to consider 9.6 for some upcoming items. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Experience with J series
The purpose is to build a mission-critical Internet access with two ISP (one on each box running full table) and have a VRRP fault tolerance and with a small budget. It is not for pushing huge traffic, I expect around 1 to 3 Mbit average and some rare peaks at 8 - 10 Mbit during backup timeframes. No Problem. J2350's are capable of this easily. e/iBGP with full tables, VRRP on the inside interface. Processing 8-10mbit/sec would hardly sweat the box. The features I will be using are firewall ( 30 ACLs), BGP, OSPF (both IPv4 and IPv6) and maybe one VPN tunnel + QoS (?). Yep. 30 ACL's with no issues (assuming straightforward things). Full BGP Tables, OSPF area 0.0.0.0 inside, QoS, IPSEC. According to the technical datasheet, this gear supports 1 GB of DRAM and handle a maximum ~ 300k BGP routes. I've seen much more in 1 Gb of RAM.; however 300k routes is fine for the global routing table. (which is ~290k or so). You'd have room-to- spare. I have seen in some lists that these models now can be upgraded to 2 GB of DRAM with just no issue. Some people report having had successful experience handling 500k routes with these littles gears. Yes. I've worked with J4350's and J6350's with 2 Gb of RAM, holding 2 complete eBGP tables each and an iBGP table. for a total of 800k routes. Also seen it (by misconfiguration) hold 1.2 Million routes in BGP/inet.0. I am just looking after some experience with them in this kind of environment. By the way, does this box include any GUI software to maintain firewall ACLs? Full GUI supported (web-Gui on the box) - however, as always, the power is in the command line. JunOS is easy to use, easy to learn, and makes sense from a command-line configuration perspective. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vrrp groups
Hi. 255 Groups. It's not a Limit on the M10i, it's how VRRP works. VRRP creates a Virtual-MAC-Address to use as the MACIP for the VRRP address (i.e. the MAC address that's returned when a device ARP's for the address) The GroupID in the VRRP config is used as the least-significant byte on the MAC Hence values of 0x00-0xFF (0 to 255) only. Someone correct me here if i'm grossly mistaken. Regards, - Chris. On 2009-09-28, at 4:22 PM, luis barrios wrote: Hello .. Does anybody know how many vrrp groups can i config in a m10i router. Propably i will have 300 vlans in one interface in a router , and i need to configure vrrp group too. One vrrp group for each vlan. But i need to know the performance in this part of my juniper m10i. 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
Re: [j-nsp] Juniper Traffic Monitoring
I was wondering what the list recommends for traffic monitoring as far as software and which method is the most popular. Hi Brendan, If you don't mind spending a few pennies on a commercial system, I'd suggest Intermapper. Runs on pretty much any platform (Linux, FreeBSD, Windows, OSX, Solaris), uses a dedicated database, distributed polling/ collection and the like. Whats nice is it does real-time analysis of traffic, graphing, threshold alarming, trap collection, etc.. as well has Netflow/J-Flow/ Sflow collection integrated into 1 system. I've using it to monitor M7is, MX240s, J4350/6350's and SRX series; and is reasonably inexpensive based on what you get feature-wise. Regards, - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Network Liberation Movement???
As long as they don't attempt to Liberate my Network =P Regards, - Chris. On 2009-10-30, at 12:19 PM, Lynch, Tomas wrote: Only an idiot will make an important announcement on a Saturday. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Matlock, Kenneth L Sent: Friday, October 30, 2009 1:15 PM To: Drew Weaver; Derick Winkworth; Cisco NSP; juniper- n...@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Gibberish, and marketing speak. My guess is a linux-based 'router' they're trying to sell to unsuspecting mom-and-pop businesses. Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlo...@exempla.org -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Drew Weaver Sent: Friday, October 30, 2009 9:38 AM To: 'Derick Winkworth'; Cisco NSP; juniper-nsp@puck.nether.net Subject: Re: [c-nsp] Network Liberation Movement??? Just looks like a bunch of gibberish to me. -Drew -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Friday, October 30, 2009 10:23 AM To: Cisco NSP; juniper-nsp@puck.nether.net Subject: [c-nsp] Network Liberation Movement??? http://networkliberationmovement.net/ 15 hours some big announcement? Anyone know what this is? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ASR1002 Comparitive
Hi, We actually just completed an RFP for: 2-3 eBGP peers (full routes) smattering of iBGP 30k+ routes internal in OSPF Cisco pitched an ASR 1002. Juniper Pitched an SRX650. We went with the SRX650 - Better throughput and about 1/2 the price of the Cisco box. Regards, - Chris. On 2009-11-17, at 6:59 PM, Kris Amy wrote: Hi All, I’m just wondering what the J equivalent of a ASR1002 is? It seems an SRX240 is way under powered and an M7i quite a fair bit more expensive. Regards, Kris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] cflowd/netflow exporting broken (removed?) SRX series on JunOS 10.0R2.10
Hi All,
Anyone else's netflow simply stop working after they upgraded an SRX-series
to JunOS 10.0R2? (Specifically on an SRX650, but might appliy to any of the
srx-sme line, SRX240, etc...)
Worked fine under 10.0 R1. (shrug.. and 9.6R1, and 9.6 R2...etc...)
@CLGR01-CR01 show configuration forwarding-options
sampling {
traceoptions {
file sampling-log size 100m files 10 world-readable;
}
input {
rate 10;
run-length 9;
max-packets-per-second 7000;
}
family inet {
output {
flow-server 10.6.0.13 {
port 9996;
autonomous-system-type origin;
source-address 10.6.0.21;
version 5;
}
}
}
}
... nothing in the log file.. =P
and
interfaces {
ge-0/0/1 {
unit 0 {
family inet {
filter {
input packetmode-ipv4;
}
sampling {
input;
}
address removed.to.protect.the.guilty.x.x.x.225/29;
}
}
}
Yep.. sampling pretty much everything coming in...
(And yes, this box is in packet mode for the majority of it's interfaces...
using it as a nice JunOS BGP core router in the 1Gbps/sec range...)
- Chris.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Urgent reply required
What? this isn't JTAC? =) Regards, - Chris. On 2009-12-22, at 7:22 AM, Shane Short wrote: I don't know about anyone else, but I'd really appreciate it, if every post you posted wasn't 'urgent'. We're not here to serve you. -Shane On 22/12/2009, at 10:17 PM, chandrasekaran iyer wrote: Hi, I have following topology ospf Agilentrouter I am pumping type 5 ext LSA from agilent to the router. I observe in the ospf database, i am seeing Extern LSA, but i dont see it in the routing table. What could be the reason. Urgent reply is appreciated. Thanks with Regds, Shekar.B -- Thanks with regards Shekar.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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] telnet access
Telnet can be enabled on any/all IP interfaces. Simply add telnet as a services
under the [edit system services] stanza.
system {
services {
telnet {
connection-limit 5;
rate-limit 5;
}
}
}
This will allow telnet on every interface.
You might want to also enable the connection limit and rate limit variables,
to prevent people from brute-forcing password attempts on your device.
The example you may have been looking at, involves how to prevent The
Internet from telnetting to your router; by placing a filter on lo0 to
restrict who can make a telnet connection to your device; which involves
placing a [firewall filter] against interface lo0 unit 0. Interface lo0
represents the management of the device from the perspective of the transit
interfaces (i.e. every IP interface but fxp0).
By default, if you enable telnet in the [edit system services] stanza, anyone
can telnet to any of the IP addresses on your device. (ge-x/x/x.x interfaces,
lo0.x loopback interfaces, and the like).
I highly recommend disabling telnet and using ssh instead:
system {
services {
ssh {
root-login deny;
connection-limit 3;
rate-limit 5;
}
}
}
For more information on how to protect your router's in-band management from
being hacked, Team CYMRU has a nice document to assist you.
the document can be found here:
http://www.cymru.com/gillsr/documents/junos-template.pdf
Regards,
- Chris.
juniperdude at gmail.com
On 2010-01-28, at 5:54 AM, Taqdir Singh wrote:
Hi Team,
1) in case of juniper, telnet access restriction can only be configured on
loopback 0 unit 0 ?
2) does that mean, no one can telnet by default on any other phsyical
interface or any other loopbacks units ?
--
Taqdir Singh
Network Engineering
(+91) 991-170-9496 | (+91) 801-041-5988
One who asks is a fool for a moment, one who doesn't ask remains fool for
ever
___
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] J2320 as BGP router
As stated before, The Advanced BGP Licence is for Route-Reflector capability. The system does full i/eBGP out-of-the-box (normal JunOS). Also look at the SRX series - which are basically pumped up J's running the virtually same code. (and yes, you can kick an SRX into packet mode) - Chris. On 2010-02-18, at 8:41 AM, Shane Short wrote: I think the BGP licensing for JunOS is quite ridiculous.. I've been looking at upgrading our small network to some J series routers and simply haven't, because as you said-- the price of the license is almost as much as the unit itself. what gives? -Shane On 18/02/2010, at 11:28 PM, Tore Anderson wrote: * TCIS List Acct But don't you need the advanced feature license to do BGP on the EX3200 series? That license adds thousands to the cost.. There's also JX-BGP-ADV-LTU, «Advanced BGP License for J-Series», which almost equals the list price of the smallest J2320. I'm not sure what exactly would make a BGP setup advanced enough to require this license, though. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 ___ 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] Basic VLAN setup on a J2320
Do not include the ge-0/0/3 in each of your VLAN statements; as that
designates that port to be an access port per se.
You just need to have this:
vlans {
bgp {
vlan-id 12;
l3-interface vlan.12;
}
lan {
vlan-id 10;
l3-interface vlan.10;
}
wan {
vlan-id 11;
l3-interface vlan.11;
}
}
JunOS assumes that you have some trunk ports... somewhere... (as you have
declared under the [interfaces ge-0/0/3] stanza) for these VLANs if there's no
untagged ports associated with them.
Regards,
- Chris.
On 2010-04-08, at 4:05 AM, Morten Isaksen wrote:
Hi!
I am tryng to setup a vlan on a trunk port on 2 J2320 but I have some
problems to get it to work. The two J2320 are connected to each other
on ge-0/0/3. I can ping the local ip address on vlan 12 but not the ip
address on the other router.
tcpdump -n -i ge-0/0/3 show no traffic at all on the interface on both
routers.
Can you please help
The 2 configurations are here:
## Last commit: 2010-04-08 16:58:02 UTC by root
version 9.2R1.10;
system {
host-name bgp-1;
root-authentication {
encrypted-password XXX;
}
services {
ssh;
telnet;
web-management {
http {
interface ge-0/0/0.0;
}
}
}
syslog {
file messages {
any any;
}
}
}
chassis {
fpc 0 {
pic 0 {
ethernet {
pic-mode enhanced-switching;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 192.168.1.1/24;
address 10.253.254.101/24;
}
}
}
ge-0/0/3 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ bgp lan wan ];
}
}
}
}
vlan {
unit 10 {
family inet {
address 10.253.253.202/24;
}
}
unit 11 {
family inet {
address 178.21.248.2/26;
}
}
unit 12 {
family inet {
address 178.21.250.1/30;
}
}
}
}
security {
zones {
security-zone trust {
tcp-rst;
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
interfaces {
all;
}
}
security-zone vlan.12 {
host-inbound-traffic {
system-services {
ping;
}
}
}
}
policies {
default-policy {
permit-all;
}
}
alg {
dns disable;
ftp disable;
h323 disable;
mgcp disable;
msrpc disable;
sunrpc disable;
real disable;
rsh disable;
rtsp disable;
sccp disable;
sip disable;
sql disable;
talk disable;
tftp disable;
pptp disable;
}
forwarding-options {
family {
inet6 {
mode packet-based;
}
iso {
mode packet-based;
}
}
}
flow {
allow-dns-reply;
tcp-session {
no-syn-check;
no-syn-check-in-tunnel;
no-sequence-check;
}
}
}
vlans {
bgp {
vlan-id 12;
interface {
ge-0/0/3.0;
}
l3-interface vlan.12;
}
lan {
vlan-id 10;
interface {
ge-0/0/3.0;
}
l3-interface vlan.10;
}
wan {
vlan-id 11;
interface {
ge-0/0/3.0;
}
l3-interface vlan.11;
}
}
## Last commit: 2010-04-08 17:23:12 UTC by root
version 9.2R1.10;
system {
root-authentication {
encrypted-password XXX;
}
services {
ssh;
telnet;
web-management {
http {
interface ge-0/0/0.0;
}
}
}
syslog {
file messages {
any any;
}
}
}
chassis {
fpc 0 {
pic 0 {
ethernet {
pic-mode enhanced-switching;
}
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.253.254.102/24;
}
}
}
ge-0/0/3 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members bgp;
}
}
}
}
vlan {
unit 12 {
family inet {
address 178.21.250.2/30;
}
}
}
}
security {
Re: [j-nsp] Basic VLAN setup on a J2320
Seems to work fine with me, without any declared interface. Make sure your
actual trunk port is up. This is a config snippet from one of my SRX240s:
ge-0/0/0 {
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ vlan-10 vlan-99 ];
}
}
}
vlan {
unit 10 {
family inet {
address 10.20.0.1/30;
}
}
unit 99 {
family inet {
address 10.20.0.5/30;
}
}
}
vlans {
vlan-10 {
vlan-id 10;
l3-interface vlan.10;
}
vlan-99 {
vlan-id 99;
l3-interface vlan.99;
}
}
chr...@clgr01-fw03 show vlans
Name Tag Interfaces
default1
None
vlan-1010
ge-0/0/0.0*
vlan-9999
ge-0/0/0.0*
chr...@clgr01-fw03
- Chris.
On 2010-04-08, at 7:32 AM, Morten Isaksen wrote:
If I delete the interface section in the vlan stanza then the vlan is down.
/Morten
On Thu, Apr 8, 2010 at 3:23 PM, Chris Kawchuk juniperd...@gmail.com wrote:
Do not include the ge-0/0/3 in each of your VLAN statements; as that
designates that port to be an access port per se.
You just need to have this:
vlans {
bgp {
vlan-id 12;
l3-interface vlan.12;
}
lan {
vlan-id 10;
l3-interface vlan.10;
}
wan {
vlan-id 11;
l3-interface vlan.11;
}
}
JunOS assumes that you have some trunk ports... somewhere... (as you have
declared under the [interfaces ge-0/0/3] stanza) for these VLANs if there's
no untagged ports associated with them.
Regards,
- Chris.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Basic VLAN setup on a J2320
1. Check your security zone to ensure you're allowing ping on both devices, and
that the vlan.xxx interfaces are part of the zone:
i.e.:
security {
zones {
security-zone trust {
interfaces {
vlan.99 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
vlan.10 {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
2. Also check your policies on the trust zone (just to ensure its there);
policies {
from-zone trust to-zone trust {
policy allow-all {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
On 2010-04-08, at 9:26 AM, Morten Isaksen wrote:
I forgot the members [ ... ] part and that caused the vlan to be down.
But after I added the members line the vlan was up but I was not able
to ping bettween the two J2320, so same result.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] equal-cost multipath using two DS3s
Hi,
Per packet load balancing is actually per-flow load balancing on an
M10i/M7i.
The command is a hold-over from the very old Internet Processor version that
did per packet on the M40/M20 etc... which Juniper has left as-is in JunOS.
It does tend to throw people for a loop when they see it (and raise the
objections to it's use by the statements you have described earlier).
So, have no fear to do the following:
policy-options {
/* Even though this says per-packet, it really means per-flow. Its a
throwback for command compatibility */
policy-statement Load-Balance-Per-Flow {
term enable-load-balancing {
then {
load-balance per-packet;
}
}
}
routing-options {
forwarding-table {
export Load-Balance-Per-Flow;
}
}
.. your videoconferencing and VoIP packets will indeed arrive in order.
Regards,
- Chris.
On 2010-04-19, at 3:29 PM, Justin M. Streiner wrote:
I have an M10i connected to an M7i at a remote location using two DS3s.
Attempts thus far to get traffic to share both links relatively evenly have
not gone well. All of the traffic will typically use only one of the links,
so it gets saturated while the second like is barely even touched. JTAC
suggested per-packet load-sharing, however I would like to avoid that because
of the possibility of packets arriving out of order which could make
latency/jitter-sensitive applications (IP video conferencing, etc) unhappy.
JTAC later suggested that per-packet load-sharing in JUNOS parlance doesn't
necessarily mean per-packet load-
sharing (naturally :) ).
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SYN Flood SNMP Filtering
I don't believe the SSG does SYN proxy'ing, correct? It does indeed support that. Check in the screen options for SYN flood limit, as well as enable SYN-Cookie under flow options. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange no memory issue on 10.0R3.10
If you use the router template, the Security requirements (i.e. needing policies between zones) is removed, however the device still operates in flow mode; unless you also specifically state that family inet is in packet mode; as well as using firewall filters on every interface and matching all transiting traffic with action packet-mode. See: http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-admin-guide/config-selective-stateless-chap.html Traffic to/from the RE still needs to be in flow mode for the device to operate properly (i.e. BGP sessions, SSH etc...) - Chris. On 2010-09-22, at 12:48 PM, Joe Goldberg wrote: Ah, I guess it would have been important for me to mention that I am running in router mode with all that flow stuff disabled. I started with the routermode template on the box. Sorry for any confusion. Joe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] BGP surveillance
We're using Intermapper, with the BGP Status Probe. When the NMS system receives a BGP down trap, it SNMP scans all known BGP sessions on the device; and looks for any that are not in the Established state. If it finds one (or more), it generates an alarm/page/email for each session that is down. (Just in case you had multiple BGP failures). It also periodically scans all sessions (30 seconds, 1 minute, 5 minutes, whatever you want to set it to), and refreshes it's alarm state. It's commercial, but relatively inexpensive (www.intermapper.com). - Chris. On 2010-10-15, at 5:30 AM, Johan Borch wrote: Hi, What do people use to monitor their BGP sessions on Juniper equipment? I've tried a couple of open source solutions, but my problem right now is that Juniper does not send which peer that went up/down in the snmp trap that get's generated. So I can configure an alarm that says BGP up/down but I can't tell which session it concerns. Regards Johan ___ 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 for MPLS
Simple Answer. Cost. The SRX650 can handle about as much traffic as an M7i, at less half the price. There's no equivalent J-series at that level. (J6350 would top out at 2Gbps). Likewise, J-series runs virtually the same code now as the SRX series (in terms of security), Which begs an answer to the question: Why not just buy a router? Answer: What router? There's only security devices below the M7. - CK. P.S. there was a huge previous discussion regarding J-series only-flow-based earlier, which I'm sure you remember. =) On 2010-10-23, at 12:46 AM, Chris Evans wrote: My question is what is the purpose of using a security device for pure routing purposes??? Why not just buy a router? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 JunOS Recommendation
We've now settled on 10.2R3 on our EX4200s, and EX2200s. When I tried to do upgrades to the JTAC recommended releases I managed to almost brick my EX2200's in the process. (i.e. when booting, they simply waited 15 mins for mgd to settle, amongst other nasty deadlocking situations in the boot process. Had to Ctrl-C the boot process a few times on a few different EX2200s and EX4200s on the Juniper's Recommended Releases. Again, this is just what is working for us There's a nasty known-bug with 10.2R3 on MXes, but that's not related to the EX line (I hope); as it's MPC/DPC related (and not just to Trio cards, ras =)). - Chris. From: Richard A Steenbergen r...@e-gerbil.net Date: November 9, 2010 6:59:13 AM GMT+11:00 To: Mehmet Akcin meh...@icann.org Cc: juniper-nsp juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX4200 JunOS Recommendation You'd have better luck picking good versions of code with a magic 8ball. Unfortunately I can't tell you specifically what works best for L2 on EX4200 because we use none of the first and very little of the second, but I can give you a very very long list of reasons why 10.2R3 is (at this exact moment) the best choice for EX8200 doing routing. On 2010-11-09, at 6:31 AM, Keegan Holley wrote: Greetings all, I'm looking for a code recommendation for EX4200's. I'm planning some network wide upgrades and I have an idea of what I want to run, but I was curious what the list would recommend. Most of the switches will be layer-2 only with, 10G or AE uplinks, VC of course. We've run into some pretty significant bugs in the past, just wondering what everyone else is running. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] how to measure traffic between ASs from an M7i box - [SPF] Sender is forged (SPF Fail)
forwarding-options {
output {
cflowd x.x.x.x {
autonomous-system-type origin;
}
}
}
}
http://juniper.cluepon.net/index.php?title=Cflowd_configuration
- Chris.
On 2010-12-10, at 6:44 AM, Correa Adolfo wrote:
Anybody knows how can I enable AS labeling at the jflow of an M7i?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
Just installed 14 x MX960s for a large Aussie Mobile company - The release train we've decided on is 10.4R2 for now, due to EEOL support; and the fact that 10.0 didn't support a few of the cards we added. (16x10GE Trio for example didn't come till 10.2). I have also hear that 10.4 also included a mass re-write/re-development of a lot of the JunOS code; trying to bring it back within a manageable framework. (Note how it went from 10.2R3 to 10.4, skipping a 10.3 release for some platforms). Hence, 10.4 is the new code base. I don't know if this is a good thing or a bad thing initially, but should only improve with time. I'd like to standardize all the other devices in my network to 10.4; once the suggest JTAC releases goes past 10.2R3 for things like SRX platforms. - Chris. P.S. JunOS may go to 3 releases per year now as well, so there may only be an 11.1/.2/.3 for 2011. On 2011-03-15, at 7:13 PM, Keegan Holley wrote: I know the subject of JunOS versions has been beaten to death, but I've never seen this specific question asked or answered. I'm trying to decide between 10.0 or 10.4 for a network of MX, M (10i, 120 and 40e) and J series routers. I'd like to choose a train with extended support. I'm trying to decide between the risk of undiscovered bugs in 10.4 and having to upgrade sooner when 10.0 goes EOS. We run L3VPN, with some L2VPN and a shrinking VPLS footprint. Most of the M's and MX's have a full table with some acting as regional route reflectors. Just wanted to get the general opinion of those running similar applications. ___ 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] In-band ssh access to Juniper EX
Should just work. Ensure me0.0 is not defined anywhere in the interfaces {}
stanza.
i.e.:
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching;
}
}
ge-0/0/2 {
unit 0 {
family ethernet-switching;
}
}
etc
vlan {
unit 0 {
family inet {
address your-management-ip-here/24;
}
}
}
}
routing-options {
static {
route 0.0.0.0/0 next-hop somewhere-useful-on-your-LAN;
}
}
vlans {
default {
l3-interface vlan.0;
}
}
- Chris.
On 2011-03-25, at 4:17 AM, Henri Khou wrote:
Hello,
I have a Juni EX-4200 with an out-of-band management interface configured. It
works like a charm.
Then I needed to connect to my switch through the Internet so I have treied
to connect via ssh to a l3-interface but I failed miserably.
Is there a limitation regarding l3-interace or a configuration statement that
prevent in-band access?
Thanks
Henri
___
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] Changing SSH port on EX switches, M routers
And last, but not least:
ssh {
root-login deny;
protocol-version v2;
rate-limit 3;
}
Rate limit it in the [system services] stanza. 3 unsuccessful tries and the IP
is ignored.
- Chris.
P.S. the 'ssh' services port is defined in /etc/services. Unsure if you adjust
the line, that it may move the listening port. Might be worth a try; but
naturally this would be a Juniper-unsupported configuration and will probably
be overwritten on a software upgrade. It may also affect your firewall filters
in the [from] stanza. YMMV.
chrisk@fw02.miller start shell
% grep ssh /etc/services
ssh 22/tcp#Secure Shell Login
ssh 22/udp#Secure Shell Login
On 2011-04-02, at 11:23 AM, Jesus Alvarez wrote:
Hi,
Is there a way to change the SSH port for managing the EX switches and M
routers? We normally avoid using the standard port 22.
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
Re: [j-nsp] Changing SSH port on EX switches, M routers
Agreed. A proper [firewall family inet] restricting ssh access with a packet filter is a far better solution. I assume that lo0.0 loopback filters finally work on an EX-series as of 10.4 (I think I saw that in the release notes for 10.4R3x). - Chris. On 2011-04-04, at 7:02 AM, Stefan Fouant wrote: I'm surprised by how many people on this list still think that 'Security through Obscurity' is an effective means of securing devices. Nmap or any other suitable scanner could isolate the SSH port in relatively no time at all. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Changing SSH port on EX switches, M routers
Ok, it may appear that I was advocating security by obscurity, hence here's
an example of a 'correct' way of doing things: =)
policy-options {
/* Put your known IPs here to allow them through */
prefix-list management-ips {
1.2.3.4/32;
2.3.4.5/32;
3.4.5.6/32;
}
}
firewall {
family inet {
filter protect-management {
term allow-my-ips {
from {
source-prefix-list {
management-ips;
}
protocol tcp;
destination-port 22;
tcp-initial;
}
then accept;
}
term deny-all-other-ips {
from {
protocol tcp;
destination-port 22;
tcp-initial;
}
then {
discard;
}
}
term allow-all-other-control-plane-traffic {
then accept;
}
}
}
}
interfaces {
lo0 {
unit 0 {
family inet {
filter {
input protect-management;
}
address 4.3.2.1/32;
}
}
}
}
Hope this helps
- Chris.
On 2011-04-04, at 7:02 AM, Stefan Fouant wrote:
-Original Message-
From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
boun...@puck.nether.net] On Behalf Of Chris Kawchuk
Sent: Sunday, April 03, 2011 4:48 PM
P.S. the 'ssh' services port is defined in /etc/services. Unsure if you
adjust the line, that it may move the listening port. Might be worth a
try; but naturally this would be a Juniper-unsupported configuration
and will probably be overwritten on a software upgrade. It may also
affect your firewall filters in the [from] stanza. YMMV.
I'm surprised by how many people on this list still think that 'Security
through Obscurity' is an effective means of securing devices. Nmap or any
other suitable scanner could isolate the SSH port in relatively no time at
all.
As a matter of practice I think that isolating the allowed IPs which might
avail of the SSH port or any other management service for that matter is a
much better overall solution.
Stefan Fouant, CISSP, JNCIEx2
www.shortestpathfirst.net
GPG Key ID: 0xB4C956EC
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Multiple LAG Groups / Common Layer3 Routing
Hi Paul,
Try this:
interfaces {
/* Repeat for all the physical ports you need to put into the respective
aeX LACP groups */
xe-0/2/0 {
description Connection to blah;
gigether-options {
802.3ad ae0;
}
}
ae0 {
aggregated-ether-options {
minimum-links 1;
lacp {
active;
}
encapsulation flexible-thernet-services;
unit 0 {
encapsulation ethernet-bridge; /* it may just be 'encapsulation
ethernet' - try both */
}
}
ae1 {
aggregated-ether-options {
minimum-links 1;
lacp {
active;
}
encapsulation flexible-thernet-services;
unit 0 {
encapsulation ethernet-bridge;
}
}
ae2 {
aggregated-ether-options {
minimum-links 1;
lacp {
active;
}
encapsulation flexible-thernet-services;
unit 0 {
encapsulation ethernet-bridge;
}
}
ae3 {
aggregated-ether-options {
minimum-links 1;
lacp {
active;
}
encapsulation flexible-thernet-services;
unit 0 {
encapsulation ethernet-bridge;
}
}
}
bridge-domains {
FLAT-LAN {
domain-type bridge;
interface ae0.0;/* tie all the ae's into one giant bridge domain /
Flat LAN */
interface ae1.0;
interface ae2.0;
interface ae3.0;
vlan-id 999; /* this is irrelevant, as it is untagged leaving the
ports - but is required */
routing-interface irb.999 /* L3 routed interface into the bridge-domain
*/
}
}
- Chris.
On 2011-04-05, at 11:34 PM, Paul Stewart wrote:
Hi folks..
Not sure if my subject line reads correctly or not. MX platform running
10.0R3.10
I have eight physical interfaces and want 4 LAG groups (2 interfaces X 4 LAG
groups) - LACP Passive mode.
All 4 LAG groups must belong to the same layer3 network.
I have tried to create AE interfaces with family bridge however it rejects
this but I know this should be something with bridge domains?
Thanks,
Paul
___
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] mitigating dos attack on Juniper M10i
Is firewall filter SAMPLER or BLOCK-FROM-INTERNET doing any type of then accept on the remainder traffic? If so, an accept is a terminating action, and no other filters (even filter-chains) are evaluated; hence filter all is never called. - Chris. On 2011-04-06, at 7:32 AM, kwarteng wrote: SAMPLER BLOCK-FROM-INTERNET ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Source address for DNS queries
You could try:
system {
default-address-selection;
}
This will try to source all router-initiated management traffic from your
loopback address.
- Chris.
On 2011-04-13, at 8:58 PM, Alexander Shikoff wrote:
Hello,
is it possible to specify source IP address for DNS queries in JunOS?
I see nothing that looks like that:
minotaur@br# set system name-server ?
Possible completions:
addressDNS name server address
[edit]
minotaur@br# set system name-server
Thanks in advance!
--
MINO-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
[j-nsp] MX-series Redundant RE - Unable to mask fxp0 down alarm
Forgive me if this is a known bugI seem unable to mask the fxp0 management
port down alarm for the Redundant RE - host 1. (works fine for the primary RE -
host 0).
Platform: MX480, JunOS 10.3R3.7
groups {
re0 {
chassis {
alarm {
management-ethernet {
link-down ignore;
}
}
}
}
re1 {
chassis {
alarm {
management-ethernet {
link-down ignore;
}
}
}
}
}
apply-groups [ re0 re1 ];
user@router show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-04-07 11:19:35 EST Major Host 1 fxp0 : Ethernet Link Down
Known issue? Need to reboot the backup RE for this to take effect?
Cheers.
- Chris.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX-series Redundant RE - Unable to mask fxp0 down alarm
Hi Paul..!
Yeah - I tried that as well initially with no luck (and just tried again
just now...)
me@wowter show configuration chassis
alarm {
management-ethernet {
link-down ignore;
}
}
user@wowter show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-04-07 11:19:35 EST Major Host 1 fxp0 : Ethernet Link Down
... Which now definitely leads me to suspect it's a bug in this release; as you
don't seem have this issue in 10.0 =)
Thanks! I'll ignore it for now, and see what happens when we do our 10.4
upgrade soon.
- Chris.
On 2011-05-02, at 10:42 AM, Paul Stewart wrote:
Hey Chris...
On MX480's running 10.0R3.10 we just have it setup as:
paul@core2.toronto1 show chassis alarms
No alarms currently active
paul@core2.toronto1 show configuration chassis alarm
management-ethernet {
link-down ignore;
}
Thanks,
Paul
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX-series Redundant RE - Unable to mask fxp0 down alarm
Heh. Good question! I just had to double check:
show config system
commit synchronize;
Thats in there.. OK let's try it manually.
ckawchuk@jmx480# commit synchronize and-quit
re0:
configuration check succeeds
re1:
commit complete
re0:
commit complete
Exiting configuration mode
{master}
ckawchuk@jmx480 show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-04-07 11:19:35 EST Major Host 1 fxp0 : Ethernet Link Down
Yeah... alarm still there. No worries - it's just an annoyance more than
anything.
- Chris.
On 2011-05-02, at 10:52 AM, OBrien, Will wrote:
Silly question... You did use commit sync, correct?
Will O'Brien
On May 1, 2011, at 7:51 PM, Chris Kawchuk juniperd...@gmail.com wrote:
Hi Paul..!
Yeah - I tried that as well initially with no luck (and just tried again
just now...)
me@wowter show configuration chassis
alarm {
management-ethernet {
link-down ignore;
}
}
user@wowter show chassis alarms
1 alarms currently active
Alarm time Class Description
2011-04-07 11:19:35 EST Major Host 1 fxp0 : Ethernet Link Down
... Which now definitely leads me to suspect it's a bug in this release; as
you don't seem have this issue in 10.0 =)
Thanks! I'll ignore it for now, and see what happens when we do our 10.4
upgrade soon.
- Chris.
On 2011-05-02, at 10:42 AM, Paul Stewart wrote:
Hey Chris...
On MX480's running 10.0R3.10 we just have it setup as:
paul@core2.toronto1 show chassis alarms
No alarms currently active
paul@core2.toronto1 show configuration chassis alarm
management-ethernet {
link-down ignore;
}
Thanks,
Paul
___
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] MX: bridge-domains and l2circuit
You'll need to declare your xe- port with flexible-ethernet-services, so you
can do per-unit encapsulations.
interfaces {
xe-1/0/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 20 {
encapsulation vlan-ccc;
vlan-id 20;
}
unit 100 {
encapsulation vlan-bridge;
vlan-id 100;
}
}
}
neighbor xxx {
interface xe-1/0/0.20 {
virtual-circuit-id 20;
...
...
}
}
On 2011-08-18, at 4:03 PM, Jonas Frey (Probe Networks) wrote:
Hello all,
i am trying to build a l2circuit on a MX. The problem is that the vlan
that needs to be included in the l2circuit comes via xe-1/0/0 which is
configured in bridge mode:
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 20 30 40 ];
}
I need to build this l2circuit with vlan 20.
However when configuring the l2circuit i do not have a interface to use
as the bridge doesnt create any subinterface for the vlan.
neighbor xxx {
interface ??? {
virtual-circuit-id 20;
I cant configure any subinterface on xe-1/0/0 (like unit 1) because
bridge mode prohibits that.
How can i get this to work?
Best regards,
Jonas
___
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] MX: bridge-domains and l2circuit
Ahh, slightly different issue then.
First off, once you use that flexible-ethernet-services, you should be
declaring each vlan separately and manually add them into the bridge-domain
config (i.e. bridge-domain VLAN20 interface xe-1/0/0.x). Anyways, that's not
what we're attempting to do here. =)
What you're looking for is to stitch an l2circuit into a bridge-domain (not
pick off a VLAN off an interface and turn that into a CCC/L2circuit - different
solution). Perhaps a logical-tunnel here may help. (i.e. lt-x/x/x.x interface).
I have stitched l2circuits/ccc's into VPLS domains before; I assume the same
theory holds true.
Have a look at using the tunnel-services on your MX DPC card. Apologies in
advance as I'm writing this in pseudo-code from memory (i.e. un-tested, more of
a general idea as to a direction to explore):
chassis {
fpc 1 {
pic 3 {
tunnel-services {
bandwidth 1g;
}
}
}
}
interfaces {
lt-1/3/10 {
unit 1 {
encapsulation vlan-ccc;
peer-unit 2;
}
unit 2 {
encapsulation vlan-bridge;
peer-unit 1;
}
}
bridge-domains {
VL20 {
domain-type bridge;
vlan-id 20;
interface lt-1/3/10.2;
.other access interfaces go here;
}
}
neighbor xxx {
interface lt-1/3/10.1 {
virtual-circuit-id 20;
...
...
}
}
- Chris.
On 2011-08-18, at 4:37 PM, Jonas Frey (Probe Networks) wrote:
Hi Chris,
that does not work...
edge# show interfaces xe-1/0/0
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 20 30 40 ];
}
}
unit 1 {
encapsulation vlan-ccc;
vlan-id 20;
}
If i do commit now, this fails as the vlan 20 is already used for the
bridge on unit 0. If i remove the vlan 20 from unit 0 then the vlan is
no longer member of the bridge (show bridge domain). But i need it to be
member of that bridge since that vlan goes out on other ports to local
switches.
edge# show bridge-domains testbridge
domain-type bridge;
vlan-id 20;
What i need to do is to get the VLAN 20 working locally on the bridge
(various ports) as well as getting it connected to a somewhat pseudo
interface to attached it as a l2circuit.
--
Mit freundlichen Grüßen / Best regards,
Jonas Frey
Probe Networks Jonas Freye-Mail: j...@probe-networks.de
Auf Strützberg 26D-3 Merzig
Tel: +(49) (0) 180 5959723* Fax: +(49) (0) 180 5998480*
* (14 Ct./min Festnetz, Mobilfunk ggf. abweichende Preise)
Internet: www.probe-networks.de Hotline: 0800 1656531
Diese E-Mail enthaelt moeglicherweise vertrauliche und/oder rechtlich
geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind
oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte
sofort den Absender und vernichten Sie diese Mail. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser Mail ist strengstens
untersagt.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the contents of this
e-mail is strictly prohibited.
--
Am Donnerstag, den 18.08.2011, 16:22 +1000 schrieb Chris Kawchuk:
You'll need to declare your xe- port with flexible-ethernet-services, so you
can do per-unit encapsulations.
interfaces {
xe-1/0/0 {
vlan-tagging;
encapsulation flexible-ethernet-services;
unit 20 {
encapsulation vlan-ccc;
vlan-id 20;
}
unit 100 {
encapsulation vlan-bridge;
vlan-id 100;
}
}
}
neighbor xxx {
interface xe-1/0/0.20 {
virtual-circuit-id 20;
...
...
}
}
On 2011-08-18, at 4:03 PM, Jonas Frey (Probe Networks) wrote:
Hello all,
i am trying to build a l2circuit on a MX. The problem is that the vlan
that needs to be included in the l2circuit comes via xe-1/0/0 which is
configured in bridge mode:
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list [ 20 30 40 ];
}
I need to build this l2circuit with vlan 20.
However when configuring the l2circuit i do not have a interface to use
as the bridge doesnt create any subinterface for the vlan.
neighbor xxx {
interface ??? {
virtual-circuit-id 20;
I cant configure any subinterface on xe-1/0/0 (like unit 1) because
bridge mode prohibits that.
How can i get this to work?
Best regards,
Jonas
___
juniper-nsp
Re: [j-nsp] best practices for cleaning the router for new deployment
I think request system zeroize is what you're looking for. - Chris. On 2011-08-22, at 9:45 AM, Martin T wrote: What are the best practices for cleaning the router in order to deploy it in some other site? I did set system root-authentication plain-text-password in order to have some sort of temporary root password. Then I set configuration file to defaults using the load factory-default. After this I did request system storage cleanup in order to delete all the log files and temporary files. How to clear show system commit output? Any additional suggestions for cleaning the router? regards, martin ___ 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] JUNOS 10.4S6 for EX8200 - PR/676826
MX'es - 10.4R5.5 - looking to move to 10.4R6 soon (and R7, and R8, etc...) EX'es - 10.4R3.4 - looking to move to 10.4R6 soon J's - 10.2R4.8 - end of the line due to 512M memory constraints - Chris. On 2011-08-31, at 1:28 PM, Jackson Jacobson wrote: I am curious about what version of junos people on the list run. If you're sticking way behind, why? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
I think that's precisely what he's trying to avoid. =) What we did is to use RVIs (vlan.xxx), but had a series of VLANs (VLAN 2000, 2001, 2002, 2003 etc..) setup as point-to-point /30s between the EXes inside a VLAN. Switch 1 to Switch 2 would be VLAN 2002. Switch 2 to Switch 3 would be VLAN 2003, etc. Just need to be careful to bridge the VLAN across the trunk link as necessary. (i.e. only bridge what you need - switch to switch - don't use 'vlan members all'). We could also re-use the same point-to-point VLAN IDs elsewhere in the network to link other switches together OSPF-wise (as the VLAN ID was only locally significant to a pair of switches). I could re-use 2001/2002/2003 elsewhere, perhaps in a different group of switches. Hence, on each switch, we turned on OSPF on those RVIs, allocated some private /30s between the switches, and exported lo0.0 into the ospf area. Ended up with something that looks alot like what you're trying to do. Nice thing is that you can discover the switched network topology easily via a simple traceroute. Makes reachability troubleshooting easy for my new guys; esp if you do the reverse DNS properly: traceroute loopback.switch5.mynetwork.net 1 10ms 10ms 10ms ge-0/0/22.switch1.mynetwork.net [10.222.1.2] 2 10ms 10ms 10ms ge-0/0/24.switch2.mynetwork.net [10.222.2.2] 3 10ms 10ms 10ms ge-0/1/0.switch3.mynetwork.net [10.222.3.2] 4 10ms 10ms 10ms xe-0/1/1.switch4.mynetwork.net [10.222.4.2] 5 10ms 10ms 10ms loopback.switch5.mynetwork.net [10.111.5.1] ^^ fake traceroute, but you get the idea of what's possible. each link between the switches is a /30. Map your reverse DNS appropriately to which interface is shared between the two switches. - Chris. P.S. If you want to get really fancy (or dislike burning a bunch of IP space for /30 connections), use IP unnumbered instead /30s on the vlan.x interfaces. OSPF will form an adjacency and learn. traceroutes will then show the loopback IPs of each switch as you trace through the network instead. I don't want to make a giant vlan and put all the devices loopbacks in it, one for scalability issues but also for broadcast related issues. Could you achieve what you want using RVIs rather than loopback interfaces? i.e. on your dot1q trunks, carry an extra management VLAN and attach a family inet RVI to it? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
On 2011-08-31, at 4:12 PM, Morgan McLean wrote: Well, part of good design is trying to avoid as many issues (whether likely or unlikely) wherever reasonably possible, right? Chris, thanks for the reply; thats what I was sort of leaning towards. I still think even that is sort of an ugly solution, and like I mentioned in my original email I thought that in a big enough network it still might not scale but...I think it might be nearly impossible to get to that point. Any other ideas? So far thats my #1 I think. Agreed - it's not pretty. Dale's idea is the simplest and the most straightforward. - VLAN800 is simply bridged everywhere, and every core/access switch has a vlan.800 RVI into that shared LAN. - Core switches run OSPF passive (to inject reachability of the management LAN IP Block) on vlan.800 - Core switches run VRRP between each other on vlan 800 (floating the proverbial '.1' out of the LAN) - Access switches default route to the VRRP .1 address anchored on the aforementioned core switches. - No need for loopback IPs / Router-IDs - No need to build an OSPF area, nor an OSPF database - All switches are 1 hop away, routing-wise. Assuming you already have some kind of loop-avoidance mechanism (RSTP, RTGs, LAG Groups, or combinations thereof...) you shouldn't run into any broadcast-related issues. You're just as likely to run into bridging loops on the rest of our VLANs as you are on this one. (This one is simply no different than any of the other VLANs in the Access Network). Downside is that it doesn't show you the undelrying topology if that's important to you. Anyways, we designed ours to scale to approx 700 switches total. (was a specific need we had for a specific access network in the wireless/mobility space. We'd never be putting in more than 700 switches due to geographical constraints - so we knew our maximum scale beforehand). - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Running OSPF to manage loopbacks, only have trunks
Chris, Could you elaborate on: Just need to be careful to bridge the VLAN across the trunk link as necessary. (i.e. only bridge what you need - switch to switch - don't use 'vlan members all'). What would be the problem if I did all? I might have say tag 2001 going to a switch that doesn't play on that vlan, but I wouldn't have problems necessarily would I? Thanks, Morgan You're right. It wouldn't necessarily be an issue. What I'm trying to avoid is bridging VLAN 2001 everywhere (and we're back to the original '1 giant LAN' problem). Switch 1 Switch 2 uses VLAN 2001 Switch 2 Switch 3 uses VLAN 2002 Switch 3 Switch 1 uses VLAN 2003 All inter-switch links declared 'family ethernet switching port-mode trunk members vlan all'. Agreed, if switch 3 doesn't have tag 2001 declared, it'll just ignore it / not pass it back to switch 1. However, if you're using a base RSTP topology (VLAN unaware), then one of those inter-switch links is going to block. You will not have routing/IP connectivity on one of the inter-switch links. However, this is not necessarily a problem If RSTP blocks between a pair of switches, OSPF will just lose the inter-switch adjacency - but not reachability of each switch in the OSPF database (The Type 1's are all still there). The traceroute simply follows the current RSTP forwarding topology. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RSVP reserve 100% of interface BW in Juniper while 75% in Cisco? !!
1. RSVP reservations are just that - reservations. They don't actually police/shape/take away available bandwidth on the interface for other traffic. LSPs ask for bandwidth reservations so that further/additional LSPs don't attempt to book their bandwidth on this interface if it's full. (See RSVP-TE) 2. Given no CoS on the LSP, and using the default JunOS Shapers; Network Control traffic (Queue 3 or Queue 7 depending on your device) will always have 5% of the available bandwidth/buffer space, regardless of the traffic on the LSP. This is the Juniper default. In other words, you can book the interface to 100% of line rate without having to worry about network control traffic getting starved. In fact, using the 'oversubscription' flag under RSVP, you can overbook the interface as much as you want (i.e. 400% = Sell 4Gig of services down a single 1G interface - and hope that all 4 LSPs don't try to use it at the same time). I don't see the advantage in keeping 2.5 Gigabit/sec of bandwidth for control plane traffic on a 10G link. =) - Chris. On 2011-09-13, at 3:42 PM, medrees wrote: Dear Experts I'm wondering from the default behavior of RSVP in Juniper routers (By default, RSVP allows 100 percent the bandwidth for a class type to be used for RSVP reservations.) while other vendors like Cisco by default reserve only 75% and keeps 25% for the control plane traffic (routing, L2 protocols messages..) giving them the highest priorities (Priority 6, or 7) and that is logic. so that what will juniper routers do for the control plane traffic if the RSVP consumed the full 100% of the links? Thanks in advance Best Regards, Mohamed Edrees ___ 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] RSVP reserve 100% of interface BW in Juniper while 75% in Cisco? !!
Please clarify more this statement (have 5% of the available bandwidth/buffer space) as I understood if the interface is completely utilized using LSP traffic the buffer will be utilized and may starving the control traffic (please correct me) You need to understand the difference between an RSVP bandwidth booking, and a CoS Queue. JunOS always has 2 forwarding classes (and hence HW queues) per interface as a default. JunOS CoS Queue defaults: Network Control - High Priority - 5% Everything Else - Low Priority - 95% (i.e. Your LSP) In your case - the best-effort queue buffer will be fully utilized. When traffic is queued for egress on an interface, the default schedulers always service the Network control traffic first, regardless of your RSVP LSP size, or how busy it is. An Interface completely utilized using LSP traffic, will always be able to send network control traffic. A low priority CoS Queue (The RSVP LSP) cannot starve a High Priority CoS Queue (Network Control Traffic). - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX100/2x0 as small MPLS CPE?
On 2011-10-26, at 9:03 PM, Leigh Porter wrote: Does anybody have any real test results of MPLS throughput on the SRX series? I've done some work with the SRX210 doing L2Circuits/EoMPLS (for E-LINE style ethernet), coupled with the new Gig-E SFP capable mPIM. The throughput numbers are quite good in one direction (800-900 Mbit), but bi-directionally, I couldn't get more than 425 Mbit/sec at 1518 byte Eth Frames (as the 'customer' EoMPLS payload). It's exacerbated by smaller (64 byte) Ethernet frames to be transported - this is due to a fixed PPS number on the SRX210. I don't think the hardware itself is running out of grunt - but more of a self-imposed packets-per-second limit on the SRX210. Another caveat is there's no 802.1p/DSCP CoS deep inspection on J/SRX family-ccc interfaces - so don't expect to be able to map 1p to EXP bits on the LSP to enforce any type of differentiated QoS on the EoMPLS circuit across the Metro. However, if you're looking for a cheap simple 100-400Mbit EoMPLS/L2CKT endpoint - then it's pretty awesome for that. - CK. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MC LAG experience ?
Any reason to use MC-LAG as the termination/CE-facing method out of a VPLS,
instead of using the standard VPLS primary/backup sites to prevent layer-2
looping?
Since MC-LAG generally is tricky (I've seen dumps as well), it made us re-think
our reasons for using MC-LAG for our MX-to-Layer2-Agg-Network VPLS Termination.
We ended up migrating away from it as a permanent solution, Instead, using
primary/backup (BGP) VPLS where possible.
Another solution to try: If you control the downstream (CE) switch and it's an
EX-Series, you can also move the loop-avoidance mechanism there, by using
Redundant Trunk Groups (RTGs). You can then pass more than just VPLS layer-2
traffic too from the redundant PEs.
However, this being said, and you need MC-LAG - we've tested it (using
vlan-vpls interfaces) on 10.3R4 through pretty much the entire 10.4-series
(we're up to 10.4R6 now). I'd be interested if anyone is running MC-LAG on
11-dot-anything on an MX at the moment.
- Chris.
On 2011-11-01, at 5:54 PM, David wrote:
Trying this now for a customer, running 10.2R3.3. Currently seeing an issue
with l2 subsystem crashing and throwing a core dump, got this issue
escalated to ATAC.
webnetwiz.
On Sun, May 29, 2011 at 2:32 PM, david@orange-ftgroup.com wrote:
Hi All,
Somebody has experience regarding MX LAG on Juniper MX in 10.2 ?
MC LAG in stanby-active for VPLS mode with LACP and ICCP configured ?
Does-it work ? Are-there any HW or SW requierements ? Some sample config
are welcome, too.
I tried to configure it with DPC combo card (20x1GE - 2x20GE). All the
configuration has commited but my LAG is still down.
Thanks for your help.
Regards
David
Hereafter my configuration :
On MX 1 :
ae0 {
encapsulation ethernet-vpls;
aggregated-ether-options {
link-speed 1g;
lacp {
active;
system-priority 1;
system-id 00:00:00:00:00:01;
admin-key 12345;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
chassis-id 0;
mode active-standby;
status-control standby;
}
}
unit 0;
}
ge-0/0/3 {
speed 1g;
link-mode full-duplex;
gigether-options {
802.3ad ae0;
}
}
iccp {
local-ip-addr 1.1.1.1;
peer 2.2.2.2 {
redundancy-group-id-list 1;
liveness-detection {
minimum-interval 1000;
}
}
}
On MX 2
ae0 {
encapsulation ethernet-vpls;
aggregated-ether-options {
link-speed 1g;
lacp {
active;
system-priority 1;
system-id 00:00:00:00:00:01;
admin-key 12345;
}
mc-ae {
mc-ae-id 1;
redundancy-group 1;
chassis-id 0;
mode active-standby;
status-control active;
}
}
unit 0;
}
ge-0/0/5 {
speed 1g;
link-mode full-duplex;
gigether-options {
802.3ad ae0;
}
}
iccp {
local-ip-addr 2.2.2.2;
peer1.1.1.1 {
redundancy-group-id-list 1;
liveness-detection {
minimum-interval 1000;
}
}
}
IMPORTANT.Les informations contenues dans ce message electronique y
compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s)
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine,
veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues
dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite
notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout
virus.
IMPORTANT.This e-mail message and any attachments are strictly
confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named
recipient(s), please immediately notify the sender and delete this e-mail
message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not
be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
Re: [j-nsp] Practical VPLS examples (SRX and J series)
In Juniper's BGP-based VPLS, you do not need to create pseudowires in-between the VPLS instances. As long as you have one master LSP (usuallyan RSVP one) in-between two PEs, BGP will then (by detecting which VPLS instance is announced from which device), automatically build an inner tunnel between the PEs to echange the VPLS traffic. In order to have this work automatically, we need to reserve a series of 'inner labels' (effectively) which can be used to differentiate sites and VPLS instances. (so when PE#1 sends traffic to PE#2, the latter devvice knows which VPLS domain it should go into). Contrast this with LDP-based VPLS, which requires manually configuring each neighbour in the VPLS domain by hand. - Chris. On 2011-11-12, at 7:01 AM, Jack Bates wrote: On 11/11/2011 11:42 AM, Mike Williams wrote: So. VPLS. Point-to-multiple-point. Virtual LAN. Brilliant! I haven't yet found any documentation that I can actually understand though. Note: The site range value must be greater than the largest site identifier. is especially confusing. Range is one number, bigger than any other, hmm. I believe this is because of the BGP auto-detection of sites. My guess is the logic actually runs up the numbers to range, so defining it to something reasonable speeds up the setup process. I'm still waiting on power for my lab to test vpls w/ BGP signalling, as it might screw up my production network and I'd like to see if I can shift to l2 signaling without dropping the peers. :) Jack ___ 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] MF Classifier on L2Circuit Endpoints?
On 2011-11-22, at 9:55 AM, Brad Fleming wrote: Is there any way to configure a multi-field classifier on an L2Circuit's local drop port? From what I've tested - Nope. Not on a J nor SRX for family ccc. (no sort of p-bit nor DSCP inspection possible). I do hope this changes in the future. I'm afraid the answer will be no but was hoping someone knows some magic. I'm working on an SRX240 but wouldn't mind knowing whether other platforms support it. EX3200/4200 can do DSCP and p-bit on an ccc port. See: http://www.juniper.net/techpubs/en_US/junos11.2/topics/example/mpls-cos-ex-series.html I've tested that under the 10.4 releases, it works... but since an EX can only do 1 label manipulation, you're stuck using kompella/RSVP based ccc's (no martini/L2circuits possible on EX, so no 'primary/backup' possible for something like an H-VPLS scenario to terminate on 2x different PEs for redundancy). However, if this is OK with you, this may be an option. Not supported on the EX2200 or EX2200C, since those smaller/less-expensive CPE-like boxes don't do MPLS. (Hi Dave! =)..) Assuming the answer is no: How do you guys provide QoS services on MPLS L2 services? You could do BGP-baed VPLS to a J or SRX series (that does work), and then do inspection on the customer-facing interface (as it's now family ethernet-vpls).. but now you've forsaken the simplicity of an L2circuit/CCC to your endpoint, and now require a full mesh of PEs. (Basically, we've moved the PE functionality to the CPE device, as opposed to just a 'dumb MPLS l2circuit endpoint' on the CPE. I'd also be interested in other's responses on this one - re QoS solutions for L2circuits. - Chris. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] End host mapping tool
Intermapper does this as part of it's Layer 2 discovery...
- Scans a Subnet to find all IP pingable/snmp poll-able devices in a range.
- Gathers all the MAC addresses off your EX switches,
- Looks at the MAC forwarding Table on the EX to see which MAC is out which
physical port
- Reads any ARP entries on any routers/switches to do the IP-MAC
conversion/lookup.
- Then connects the IP devices it found to the correct physical port on the EX
switch visually on the map (also in a easy-to-copy table view)
Commercial software, but pretty nifty. It at least 'gets it right' 90ish% of
the time. =)
- Chris.
On 2011-11-28, at 1:15 PM, Dale Shaw wrote:
Hi all,
Is anyone aware of open source or COTS software that provides MAC
address to switch port to IP address (and vice versa) mapping and
discovery? aka end user / end station tracking.
There are lots of them out there ('netdisco' being a popular open
source choice) but I haven't stumbled across one yet that properly
understands Juniper (JUNOS) bridging MIB(s) supported on EX-series
such that the MAC/L2 to IP/L3 resolution works properly.
I've personally tried the cacti 'MacTrack' plugin, as well as the
relevant module within Statseeker -- neither work as intended. In the
latter case, there is a product enhancement request logged but I'm
looking for something in the short term.
What are you using in your environment to do this?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Policy based (firewall filter) VLAN Tag Manipulation on EX
Hey j-nsp Folks,
I'm pretty much at wit's end trying to get policy-based VLAN Tag Manipulation
working on an EX in a nice/non-convoluted way.
As per JNPR's docs, you can do 1:1 swapping by using the mapping statement
against an interface in the vlan declaration, in conjunction with declaring
your interface as access. This works because it dovetails in with the Q-in-Q
abilities on the EX. ( kb.juniper.net/InfoCenter/index?page=contentid=KB16755
). Note, you can also 'push' an outer VLAN tag onto an incoming VLAN as well,
thus making it effectively QinQ; although there's easier ways of accomplishing
this.
i.e.:
interfaces {
ge-0/0/0 {
mtu 9192;
unit 0 {
family ethernet-switching {
port-mode access;
}
}
}
}
vlans {
customer {
vlan-id 100;
interface {
ge-0/0/0.0 {
mapping {
30 {
swap;
}
}
}
}
}
}
This successfully makes ge-0/0/0 a trunk port, looking for incoming VLAN 30,
and translates to VLAN 100 and dumps the frame into my customer VLAN. (and
vice versa for egress traffic.. it gets re-written as VLAN 30 on egress).
(Note: you don't actually need to declare 'dot1q-tunneling' in the VLAN
definition stanza for this to work.. as it's just a straightforward 'swap' as
per JNPR's own docs).
Caveat:
You need to declare a mapping for every VLAN you want to use on that port
(since it's basically an access port now).
- You cannot declare the port as being 'trunk', lets say, to allow some
non-translcated tags to pass, and selectively translate others.
- i.e. I have 200 VLANs on that trunk, and only need to swap one of them, I
actually have to swap all 200 of them, albeit most of then just 'swap' to the
same VLAN ID.
- result: Nasty convoluted config to handle 1 vlan translation as an exception.
_
Better way:
So, the JNPR docs mention the ability to do policy-based (i.e. 'firewall
filter based') translation instead (Of course, no examples given that I could
see).
(
http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/qinq-tunneling-ex-series.html
) - See the section on Firewall filters allow you to map an interface to a
VLAN based on a policy, which requires use of firewall filter to map to a
VLAN, the vlan option has to be configured as part of the firewall filter and
the mapping policy option must be specified in the interface configuration for
each logical interface using the filter.
Which works like this:
interfaces {
ge-0/0/0 {
mtu 9192;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members [ ];
}
filter {
input vlan-translations;
}
}
}
}
firewall {
family ethernet-switching {
filter vlan-translations {
term map {
from {
dot1q-tag 30;
}
then {
accept;
vlan customer; // you could also say 'vlan 100' here..
either works.
}
}
term accept-all-else {
then {
accept; // Unless you like black-holing traffic... =)
}
}
}
}
}
vlans {
customer {
vlan-id 100;
interface {
ge-0/0/0.0 {
mapping {
policy;
}
}
dot1q-tunneling; // this time you need to include it, or it doesn't
work
}
}
}
So, this method allows you to use, say, vlan and as 'normal' trunked
VLANs, and if the port ever sees VLAN 30 come in, it'll translate it to VLAN
100. This makes the configuration nice (as you can use a standard trunk port
now, and just call the input filter to translate the 'exceptions' you need).
This actually works, but alas, it seems to work only in one direction
Result:
- Incoming Tag 30 gets translated to Tag 100.
- Outgoing Tag 100 stays as Tag 100. (I though the whole point of declaring
'mapping policy' was to make the EX 'aware' that you needed bi-directional
translation)
- I assume I'm doing something Just Plain Wrong[tm]... i.e. the EX was never
meant to do bi-directional translation this way.
tcpdump:
Incoming: Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 30, p 0,
ethertype ARP, arp who-has 10.102.255.3 tell 10.102.255.1
Outgoing: ethertype 802.1Q (0x8100), length 60: vlan 100, p 0, ethertype ARP,
arp reply 10.102.255.3 is-at 50:c5:8d:a0:5d:15
Incoming: Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 30, p 0,
ethertype ARP, arp who-has 10.102.255.3 tell 10.102.255.1
Outgoing:
Re: [j-nsp] QinQ between Cisco/Juniper with layer2-tunneling and VPLS
1. EX4200 - I assume this following:
ethernet-switching-options {
dot1q-tunneling {
ether-type 0x8100;
}
}
vlans {
My-QinQ-VLAN {
vlan-id 1000;
dot1q-tunneling {
layer2-protocol-tunneling {
all;
}
}
}
}
2. Note that the EX4200's re-write the MAC Address when using QinQ (i.e. STP
MAC 01:80:c2:00:00:00 becomes PVST+ MAC 01:00:0c:cc:cc:cd, for example). Ensure
you are un-translating the MAC address at the far end MX or at the Cisco; else
you end up with a regular RSTP Packet with the wrong Destination MAC Address.
3. Alternatively, POP the outer Tag on Ingress at the MX; and do the MAC
destination re-write there (i.e. change it back to normal) before shoving it
into the VPLS.
- Chris.
On 2012-01-25, at 8:23 AM, Sebastian Wiesinger wrote:
Hi,
has anyone working QinQ between Cisco and Juniper running over VPLS
and with working layer2-tunneling? We have a setup like this:
EX4200 -- QinQ -- MX === VPLS === MX -- QinQ -- Cisco
We see that on both ends of the QinQ tunnel CTP/STP/LLDP Pakets are
encapsulated but on the other side nothing gets decapsulated.
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
[j-nsp] Recommended Releases now posted for MX, M, T, QFX
Just noticed this today - Seems JNPR has filled out the recommended release JunOS matrix for all the products now (incl M, T, MX, QFX) http://kb.juniper.net/InfoCenter/index?page=contentid=KB21476 - Chris. ... Riding the 10.4 MX Release Train. Next Stop, R9. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.4R9 on MX stable?
Hi Paul, Second that. Have it on a Lab MX240 with DPC-EQ Cards at the moment. Running IPv4/IPv6 (PE6), OSPF ABR, OSPF3, iBGP, MPLS, RSVP, LDP, L3VPNs, and BGP VPLS w/LDP VPLS Mesh Group Interworking. No issues so far. Haven't Tried with Trio/MPC cards yet - that'll be next week. I'll let you know. We want to push this out ASAP to fix other issues we've found in the 10.4 train with ae QoS bugs. - Chris. On 2012-02-18, at 5:21 AM, Serge Vautour wrote: We've had it loaded in the lab for a week now. Nothing seems broken yet. We're still testing. Serge From: Paul Stewart p...@paulstewart.org To: juniper-nsp@puck.nether.net Sent: Friday, February 17, 2012 12:18:02 PM Subject: [j-nsp] 10.4R9 on MX stable? Hey there. We need to upgrade from our 10.0R3.10 releases on MX platform. Up until a month ago we were ready to roll to recommended release 10.4R8 and well, we know that wasn't exactly a perfect solution ;) Has anyone got 10.4R9 running on MX platform in production yet? I'm looking for any feedback as JTAC is recommending we go to this release. Thanks, Paul ___ 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] Double-tagging on EX
You're out of luck. There's no way I've found to come in untagged and leave double-tagged; due to the EX's inability to handle 2 label operations per port. Same reason you can't support LDP MPLS L2CKT's (double-label) Martini CCCs, but you can support RSVP MPLS (single label) Kopella CCC's on the EX. (Someone pls. correct me here if I'm wrong!) The only way is to come in untagged on ge-0/0/0, leave (single) tagged on ge-0/0/1, to a loopback/wrap-around cable connected back into ge-0/0/2 (which is now an incoming single tag), and leaving ge-0/0/3 (double tagged) by using the QinQ access-port option on ge-0/0/2 access - ge-0/0/3 trunk. Fun times. Your mileage may vary on the EX8xxx series, since I believe those devices do support 2-label operations on a port. - CK. On 2012-02-22, at 11:20 PM, Alexander Frolkin wrote: Hi, We need to double-tag packets on an EX4200, i.e., untagged packets come in on one interface, and packets with two VLAN tags come out of another interface. So far, everything we tried has failed. Has anyone figured out how to do this? Juniper documentation is useless, as always. Thanks! Alex ___ 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] Double-tagging on EX
Whoa. Good idea...! /me scurries off to the lab to try it. although I don't know if you can even say native-vlan-id on a QinQ access port (or if it assumes that everything is native anyways). Worth a shot tho - even if it is a Dodgy Hack. =) - Chris. On 2012-02-23, at 5:04 AM, Kevin Wormington wrote: I have never tried this in a q-in-q application, but what if you put native-vlan-id on the access ports...will that add the inner tag when it goes out a trunk port? Might be worth a shot if you haven't tried it. Kevin ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Double-tagging on EX
Dang.
No dice on the native-vlan-id option. Makes sense, as an access port (even
though it's for a QinQ access port) isn't expecting tagged vs untagged(native)
- It just grabs everything (tags or not)
configgy:
ge-0/0/11 {
description TEST Input of QinQ Tagging using native-vlan-id to somehow
double-tag an incoming untagged packet as S:4000 C:100;
mtu 9192;
unit 0 {
family ethernet-switching {
port-mode access;
vlan {
members 4000;
}
native-vlan-id 100;
}
}
}
ge-0/0/12 {
description TEST - DoubleTagged output of QinQ test for V4000/V100;
mtu 9192;
unit 0 {
family ethernet-switching {
port-mode trunk;
vlan {
members 4000;
}
}
}
}
vlans {
V100 {
vlan-id 100;
}
V4000 {
vlan-id 4000;
dot1q-tunneling;
}
}
me@ex4200#commit check
[edit interfaces ge-0/0/11 unit 0 family]
'ethernet-switching'
Access interface ge-0/0/11.0 cannot have native-vlan-id
error: configuration check-out failed
show version
fpc0:
--
Model: ex4200-24t
JUNOS Base OS Software Suite [10.4R8.5]
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Decent J-Series software version
- 10.2R4.8 on J2320's 512M RAM; but in packet-mode (as I'm using it for an MPLS/CPE endpoint), which is the last version you can use without upgrading the CF/RAM. - 10.4R8.5 on J2320's 1Gb RAM, packet mode (same as above as MPLS CPE/endpoint) - I've had good luck with 10.4R8.5 so far though; but again, no sessions/flows. - 10.0R2.10 or 10.0R3.10 on J2320's w/1Gb RAM in Security/Flow mode, but no IPv6 Sorry couldn't be of any more help here. Haven't had a reason to run IPv6+Security yet; as we generally aren't using these J's for their fire-walling capabilities (MPLS CPE instead); or if we do (for a customer), it's for IPv4 only so far. - Chris. On 2012-02-29, at 10:23 AM, Yucong Sun (叶雨飞) wrote: any one? On Fri, Feb 24, 2012 at 5:43 PM, Yucong Sun (叶雨飞) sunyuc...@gmail.com wrote: Hi, I have two j2350, one with 9.3r4.4, and the other I am trying to find a good version to upgrade to, with security features. So far I have tried: 1) 10.1 - 10.2R4, those runs okay, but they only have half-ass ipv6 support. 2) 10.4R8, crash once a month or so, msut be manually rebooted, plus they basically just hose horribly under 20kpps or 200k sessions. 3) 11.X crash on boot directly they both are taking full BGP feeds, and I've upgraded them both to 2.5G ram, and I even upgraded on-board cpu to 3G model. anyway I'm about to give up on any hope to use non-packet mode on these routers, my money would have been much better spend if I just buy a decent dell server and good network cards, they all handles tons of tons more sessions just fine, any similar experiences? ___ 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 gui
I cant compare j-web performance between branch and DC series. Never used jweb on branch.. It's just as slow. - CK. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QOS (Network Control traffic Queue)
Here's the secret sauce you're looking for to remap NC to something else, as
well as change the DSCP value of any IP packet you generate from the RE:
/* Change the name of the original nc queue to Queue-3, and rename Queue-7 to
'Network-Control' */
forwarding-classes {
queue 7 Network-Control;
queue 6 Queue-6;
queue 5 Queue-5;
queue 4 Queue-4;
queue 3 Queue-3;
queue 2 Queue-2;
queue 1 Queue-1;
queue 0 Best-Effort;
}
/* Force our own traffic into queue 7 for egress, and DSCP mark it as 7 for
downstream honouring */
host-outbound-traffic {
forwarding-class Network-Control;
dscp-code-point cs7;
}
Naturally, you'd have to build new schedulers and DSCP mappings around this new
queue configuration.
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] FIB size at new ACX routers
Whoa. A hardened MPLS-to-the-edge box. w/1 and 10G SFP+ Optics. Thanks Juniper! We've been waiting for a box like this for a while. Any chance of a 1RU AC powered unit? (suitable as a Business CPE for L3VPN/VPLS/E-Line services) - CK. On 2012-03-19, at 8:53 AM, Robert Hass wrote: Hi I'm interested how big FIB (IP) / LFIB (for MPLS/LDP) size are supported on new ACX routers ? Rob ___ 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] Qos on branch SRX
1. Apply the QoS schedulers/queues to the at-1/0/0 interface that has the ppp
session. (Since the 'ppp' interface isn't real).
Queues are generally only associated with the physical interface hardware. This
is what we do for our managed xDSL connections:
class-of-service {
interfaces {
at-1/0/0 {
scheduler-map QoS;
}
}
}
show interfaces queue at-1/0/0
Physical interface: at-1/0/0, Enabled, Physical link is Up
Interface index: 146, SNMP ifIndex: 527
Description: ADSL 2+ Annex M - 20M/3M
Forwarding classes: 8 supported, 4 in use
Egress queues: 8 supported, 4 in use
2. VLANs - Not quite sure what you're after here. a 'vlan.xxx' interface isn't
physical either. (see #1 above)
It's only if the L2 VLAN associated with the L3 vlan.xxx interface egresses the
box on a physical port would you place your queues.
i.e. fe-0/0/2, fe-0/0/3 etc..
class-of-service {
interfaces {
fe-* {
scheduler-map QoS;
}
ge-* {
scheduler-map QoS;
}
}
}
- CK.
On 2012-03-31, at 6:47 AM, Thomas Eichhorn wrote:
But it seems I neither have classes (ingress or egress) on
vlan-interfaces nor on pp interfaces, eg.
te@gw.ber2 show interfaces queue pp0
Egress queue statistics are not applicable to this interface.
Maybe I am stuck with the concept, but how do I achieve to control
traffic leaving a pp0 interface? I have some DSL with PPPoE on this box
and would like to prioritize ssh.
Any tips?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX/Trio traffic-control-profile burst-size (controlling microbursts)
Howdy All,
I'm attempting to smooth out some traffic on an MX Gig Port on an MX80-T (Trio
Card) running 11.4R2.14 (Yeah, I'm being adventurous here).
The underlying Gig link is going via a carrier lease on one of those
Ethernet-over-SONET jobbies on the Carrier's side; which is limited to 150mbit
(STM-1/OC3); and their gear has notoriously small buffer sizes (meaning that
any bursts 4k are dropped.. yeah, great equipment...). Hence, I need to not
only shape, but control the burst size to get rid of any micro-bursting on the
port. (even a small 50m bursty stream will attempt to burst to line-rate, due
to the token-method that the shaper uses; thus flooding the Carrier's
EoSDH/EoSONET equipment and leading to packet drops).
So to do this, I did:
class-of-service {
traffic-control-profiles {
chrisk-test {
scheduler-map My-Standard-QoS;
shaping-rate 150m burst-size 4k;
}
interfaces {
ge-1/0/9 {
output-traffic-control-profile chrisk-test;
}
ge-1/0/9 is setup as a standard interface, no hierarchal, no-per-unit sched
just a plain-olde Gig Port. I'm using a tc-profile as it allows setting of a
burst-size; while the standard c-o-s { interfaces { shaping-rate }} does not.
However, upon testing, it appears that the burst-size is completely ignored.
(verified with a nice EXFO test set, generating some very bursty traffic).
I have also tried using the following (which are MX/Trio specific, thinking I
have the wrong commands):
shaping-rate-priority-high 150m burst-size 4k;
shaping-rate-priority-medium 150m burst-size 4k;
shaping-rate-priority-low 150m burst-size 4k;
... Also tried differing burst-sizes (4k, 8k, 16k, 32k, etc) and nothing seems
to take effect.
I will note that I did this on a DPCE-Q Card under 10.4Rsomething, and it works
fine in terms of controlling the microbursts. I can also somewhat solve this by
shaping at the per-queue level with a scheduler referencing a shaping-rate X
burst-size 4k and it also works; however, shaping every queue is not a solution
here. (I can explain more on this point if anyone needs...)
Hoping for some collective clue here (My next attempt will be to downgrade
to 11.2Rx - but I'm not expecting any love from that version either...)
I highly suspect I'm missing something obvious.
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best practice MTU?
I usually set the interface physical MTU as high as it goes (per device), but
manually set protocol inet to MTU 1500 (for things like OSPF to work). This
allows for as-large-as-MTU-as-MPLS-can-do. Other address families aren't that
picky about MTU matching.
ge-1/0/5 {
description LINK to another IP/OSPF/MPLS device - May or May not support
MTU 9192 on the physical but inet4/OSPF is 1500 so it works;
mtu 9192;
unit 0 {
family inet {
mtu 1500;
address 10.102.10.1/24;
}
family mpls;
}
}
- CK.
On 2012-04-27, at 7:32 AM, OBrien, Will wrote:
We've been pushing out jumbo frames across our new core lately. Right now
I've got multiple boxes from multiple vendors that all support different
maximum MTUs.
Example: Juniper MX960/480, Nexus 7009, Nexus 5k/2k, Catalyst 4900,
Nortel/Avaya 8600 All different maximums.
Anyone have suggestions for a best practice MTU? (That is over 9000?!)
Thanks!
Will
___
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] EX3200 vs. EX4200 MPLS
Yup. The EX3200 is basically an EX4200 minus the VC capability (and one less PFE from what I remember for the uplink ports/expansion thingy). Same single-label RSVP-style CCC's w/Optional QoS/Pbit inspection and EXP remarking. (Kompella style). No Martini/LDP though. *Officially Requires the Advanced Feat Licence (MPLS, BGP, IPv6, etc.) - CK. On 2012-04-30, at 1:06 PM, Skeeve Stevens wrote: Hey guys, I've tried googling and my foo is weak today. I am trying to confirm that the EX3200 and EX4200 have the same MPLS capabilities. Specifically around pseudo-wires (I think the term is). ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX3200 vs. EX4200 MPLS
I have yet to run into any limit. There probably is one, but would need to Lab it up and try to max it out. I've heard of people using EX3200/4200s as a pure MPLS CCC endpoint device (i.e. 1 LSP per physical port) as some kind of wacky olde-style M13 Mux like we used to do in the TDM days; so at least as many CCC's as there are physical ports on the box would be a minimum at my guess. You can do CCC per-VLAN as well, so your can get many more LSPs than just the # of physical IFDs. - CK. On 2012-04-30, at 1:33 PM, Skeeve Stevens wrote: Chris/Ben, How would I go about finding how how many CCC the EX3200/4200 can support? ...Skeeve ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Interface to be used for Trunking MPLS
On 2012-05-18, at 9:29 AM, Saba Sumsam wrote:
flexible-vlan-tagging;
encapsulation vlan-ccc;
unit 0 {
encapsulation vlan-ccc;
vlan-id-range 700-800;
family ccc;
}
unit 400 {
family bridge {
interface-mode trunk;
vlan-id-list 400;
}
Cant do that. Youve told the MX that this port is for VLAN-CCC's only.
You want:
#
ge-1/1/1 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services; allows different per-unit
encapsulations
unit 0 {
encapsulation vlan-ccc;
vlan-id-range 700-800;
family ccc;
}
unit 400 {
family bridge {
interface-mode trunk;
vlan-id-list 400;
}
}
#
or: (if youre on Trio with an Older JunOS release):
ge-1/1/1 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-ccc;
vlan-id-range 700-800;
family ccc;
}
unit 400 {
encapsulation vlan-bridge
vlan-id 400;
}
}
bridge-domains v400 {
interface ge-1/1/1.400
}
#
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS downloads
Using a unix shell, to download software directly to a router, which itself uses a unix shell..? Sorry - That's too clever (and hence; not allowed). =) - CK. On 2012-05-22, at 9:29 AM, Richard A Steenbergen wrote: the proceed button at the bottom of the EULA acceptance is non-functional in lynx or elinks if you're trying to download your JUNOS images via a unix shell. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Bridge Domain/IRB on MX80
Maybe logical tunnel into a bridge? Eg https://puck.nether.net/pipermail/juniper-nsp/2011-August/020891.html ^ Yup. I'm using this method right now to backhaul a VLAN off of an CPE generating a Martini L2CKT endpoint, stitched into an MX480 bridge-group. Works well. Caveat: You lose CoS stuff when things pass through an lt-*. I believe CoS classification/remarking on an lt-* is being addressed in a future JunOS release. (Although it may work now, haven't checked the latest Release Notes..) - CK. -Original Message- I am receiving VLAN550 on MX80 (PE) via an LSP I would like to create an L3 Interface on the MX for this VLAN. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CoS - DSCP Markings
You should be classifying on ingress.
Classification is only for 'internal' treatment. Then you do rewrite on
egress interface
Actually, You can apply multifield classifiers either at ingress or egress.
Either way works fine; unless the traffic itself is sourced from the RE (bug in
MX).
The config actually looks correct a first glance (filling in the missing pieces
in my mind, of the stanzas that I assume that are there, like a scheduler-map
against interface ae1 so you're not using the default 2-queues..), and assuming
this is transiting traffic.
Try doing a:
then {
loss-priority low;
forwarding-class FWDCLASS;
count matched-a-packet;
accept;
}
then show firewall to see if the counter increases (and hence you're actually
matching the correct source IP).
what does 'show interfaces ae1 extensive show' for forwarding class 5? (in
terms of byte counts). i.e. clear the counters first, then run some traffic
through it, and ensure the outgoing traffic gets queued up in fwding class 5.
Feel free to contact me offline as well.
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Netflow equivalent for MX5 11.4
JunOS Routing for all intents and purposes is stateless. It doesn't cache information concerning the IP lookup (CEF-Style), hence there's no concept of a 'flow' in JunOS; so nothing per se to 'show'. (each packet is processed 'atomically', meaning JunOS doesn't remember that this next packet belongs to the same src/dst/port as a previous packet it's already processed and forwarded). Each packet is basically unique according to how JunOS does things. (With no need to cache, as it does it all wire-speed, plus caching/remembering only slows things down when you're in ASIC-land, not speed them up). /end-marketing-blurb You can enable Netflow reporting (cough..cough.. J-Flow I mean =).. If want real/actual Netflow records to be created. JuNOS on MX supports inline netflow (sampling and creating flow records for flow export), but needs to be enabled and exported. - CK. On 2012-06-08, at 10:10 AM, Shannon Rigby wrote: Hi we have just moved over to MX5's running 11.4 for our BR's we regularly used Cisco command show ip cache flow to monitor traffic flows. Has anyone had any experience setting up an equivalent in Junos 11.4? Thanks in advance ___ 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] cable modem/dsl/ftth bandwidth limiting
Not costly at all; when you think about scaling it to 20,000/30,000 subscribers per box. BRAS's (xDSL, PPPoE, PPPoA) have massive numbers of hardware queues, and shape/queue per individual subscriber. These boxes are designed to do this. Examples: Juniper E-series, Cisco ASR-Series, Juniper MX-series w/the Q cards, Redback SmartEdge 400/800, etc... You still need something in the central network anyways to aggregate all these individual connections from every scubscriber. It's a natural to perform this function there; and not at the CPE. Usually it's the link between the DSLAM/CMTS/GPON to the Customer that's congested anyways - As Jerry mentioned, why transport it just to drop it? May as well rate-limit it upstream before it hits the narrow-bandwidth portion of the link to the customer. - CK. On 2012-06-20, at 3:19 AM, Chris Evans wrote: performing bandwidth limits on a central network device would be too costly to do. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cable modem/dsl/ftth bandwidth limiting
Layer-2 Cable is done at a BRAS (running in DHCP mode). Layer-3 Cable Plants shape at the CMTS. Layer-2 Optical/GPON/FTTH can be done at a BRAS (if DHCP or PPP), or can be done at the head end GPON device; assuming the GPON is reasonably 'smart', and understands each subscriber and their associated consumer profiles. Think VoIP. Need to shape from the network-side before it hits the last-mile, so that any SIP/IAD traffic (for a CPE device with a built-in IAD) never gets dropped as well. Toss IPTV into the mix, and yes, QoS/Shaping must happen prior to the last-mile. (unless you like pixelated TV when your bittorrent client is also going full blast =)..) Remember that Authentication also needs to happen (who's allowed on the network, either by PPP l/p or DHCP Mac); as well as traffic counters, so that those who do metered--billing (i.e. Australia) can get per-subscriber utilization. So, whichever device is holding the next hop gateway IP for the subscriber is also the device that is doing the downstream shaping; so that the utilization counters match what the subscriber has actually used. - CK. On 2012-06-20, at 6:46 AM, Chris Evans wrote: cable and ftth ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] cable modem/dsl/ftth bandwidth limiting
Downstream is Shaped, Definitely. The BRAS/CMTS/etc sets up Individual Hardware Queues for each traffic class per subscriber. (Hence why those boxes have 16,000-64,000 HW queues per blade, as each sub may use 2-8 queues depending on what you sell =)..) Generally 4 prioritized queues (NC, VoIP, Video, Best-Effort), where upper queue can generally starve the lower queue, and Tail-drop the BE queue when the buffer gets full. For upstream the local customer device would limit. Bingo. Usually limited by the actual physical upstream bandwidth given/negotiated/trained to the CPE device (xDSL upstream link, CMTS-back channel, GPON upstream timeslice/frequency etc.). Again, if multi-service, the CPE needs to be aware of the traffic classes as well. In Germany, the Telco provides the CPE and use different VLAN Tags to prioritize the traffic in each direction (Internet on 100, Voice on 200, Video on 300, etc.). Bit of a pain if you want to supply your own 'home gateway' in that neck of the woods, as their device does it all for you. (incl outbound NAT, etc..) Hope that all makes sense! - CK. On 2012-06-20, at 6:58 AM, Chris Evans wrote: Still, can someone answer if it's shaping or policing? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] snmp { filter-interfaces {}}; wildcard usage
Apologies, as my REGEX-fu is weak today.
I'm attempting to filter off certain interface from showing up via an SNMP
walk... i.e. interfaces that are internally generated which really serve no
purpose outside the JunOS box itself: (lsi.*, lo0.16384, etc)
I want to match any ge-x/x/x interface that has .32767 (which is the RE-to-PIC
communications interface that is created on many PICs/MPCs/DPCs - which only
serves to confuse my Ops guys as well as clutter up any MRTG-style graphs.)
This works (as an example) to suppress:
snmp
{
filter-interfaces {
interfaces {
lsi.*;
cbp*;
demux*;
pimd*;
pime*;
pip*;
tap*;
lo0.16384;
}
all-internal-interfaces;
}
But this does not (i.e. I cant find a good example of how to match 'any
interface' as long as it's unit 32767):
snmp
{
filter-interfaces {
interfaces {
*.32767;
*32767;
ge*.32767
ge*32767;
}
all-internal-interfaces;
}
Pointers/Suggestions/Example Stanza Appreciated. I will send you a Blueberry
Pie.
- CK.
P.S. Dear JNPR - any reason we aren't including xxx.32767, lo0.16384, etc.. as
part of the default all-internal-interfaces directive? Seems like a natural
to me.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Broadband Model suggestion?
Your Vendor's Sales Rep and Systems Engineer should be more than happy to help in this regard. =) - CK. On 2012-07-12, at 5:01 PM, Frank Norman wrote: Dear friends, I need suggestion for broadband network based on xDSL fiber based last miles (GPON/Metro technologies), Subscriber base upto 40-50 thousand customer, Requirement for subscribers will be; - Authentication authorization - Dynamic Rate-limiting policing (with Multi service support) - Session state monitoring - Session Accounting for Billing (prepaid/postpaid) and other policies in standard broadband networks. Now can someone tell me 1) what are the standard models (PPPoE or DHCP ? ) that are being used in such kind of broadband networks?? and which is more flexible?? 2) How is bandwidth management for subscribers is handled?? through the same BRAS or by installation of separate devices like packeteer, packetlogic etc 2) Which devices/vendors can handle these kind of requirements?? (We already have AAA radius expertise, so i am only concerned with network equipment side) Good Day! Frank ___ 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] SSH access and not working firewall policy
One possibility - They're coming from inside your own network =) Whats the source IPs on the attempts, and what device is this (EX? MX? J? QFabric?) - CK. On 2012-08-13, at 5:07 AM, Robert Hass wrote: Hi I have Juniper running 10.4R7 with RE filter applied to lo.0 but I still see bruteforce attacks to my SSH in log messages. . ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Tricks for killing L2 loops in VPLS and STP BPDU-less situations?
Hi Clarke, We pass through BPDUs through VPLS the MX'es- but yes, miscreant users / switches will always be a problem. We do the following to every customer-facing VPLS instance, but only #3 would help you here: 1. Mac Limiting per VPLS Interface (100) (i.e per 'site') 2. Mac Limiting per VPLS (500) 3. Limit Broadcast/Unknown Unicast/Multicast Traffic (5 Mbit) into the VPLS You can put on an input firewall filter which calls a 5 Mbit policer at [routing instances vpls-name forwarding-options family vpls ] to start limiting this type of traffic into the 'bridge domain' at any time. - CK. On 18/08/2012, at 1:08 AM, Clarke Morledge chm...@wm.edu wrote: We have had the unfortunate experience of having users plug in small mini-switches into our network that have the capability of filtering out (by-default) BPDUs while allowing other traffic through. The nightmare situation is when a user plugs in such a switch accidentally into two of our EX switches. Traffic will loop through the miscreant switch between the two EXs and without BPDUs it just looks like MAC addresses keep moving between the real source and the two EXs. In an MX environment running VPLS, this problem can happen easily as there are no BPDUs even to protect against loops in VPLS, particularly when your VPLS domain ties into a Spanning Tree domain downstream where your potential miscreant switch may appear. I am curious to know if anyone has come up with strategies to kill these loops for EXs running Spanning Tree and/or MXs running VPLS. Rate-limiting may help, but it doesn't kill loops completely. I am looking for ways to detect lots of MAC address moves (without polling for them) and blocking those interfaces involved when those MAC moves exceed a certain threshold via some trigger mechanism. Assume Junos 10.4R10 or more recent. 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] SRX MPLS
Err VPLS Implies Layer 2 only. Where is the VRP runninng in-between? Are you doing vlan-id inside the VPLS instance for normalization, then binding an irb.x into it? I dont think that works in SRX/J either. (l3 within VPLS). - CK. On 2012-08-23, at 6:39 PM, Johan Borch wrote: VPLS multihoming, which allows connecting a CE device to multiple PE routers to provide redundant connectivity, is not supported on J Series or SRX Series devices I'm going to have two SRX's on each site and using vrrp between them, will I hit this exception then? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX MPLS
Shouldn't affect it in the classical BGP active./backup sense; only 1 'vrf' is active in a multi-homing BGP setup. However, since the SRX/J doesn't do that, both will end up being active - You'll need a way to suppress one of them from getting any traffic. Perhaps think about using an EX4200 underneath using an RTG to each SRX at layer 2 to prevent the loop. Should have zero effect on vrrp/layer-3 stuff. - CK. On 23/08/2012, at 7:47 PM, Johan Borch johan.bo...@gmail.com wrote: Your'e right of course :) My question was more how the VPLS multihoming will affect this setup. Regards Johan On Thu, Aug 23, 2012 at 11:21 AM, Chris Kawchuk juniperd...@gmail.com wrote: Err VPLS Implies Layer 2 only. Where is the VRP runninng in-between? Are you doing vlan-id inside the VPLS instance for normalization, then binding an irb.x into it? I dont think that works in SRX/J either. (l3 within VPLS). - CK. On 2012-08-23, at 6:39 PM, Johan Borch wrote: VPLS multihoming, which allows connecting a CE device to multiple PE routers to provide redundant connectivity, is not supported on J Series or SRX Series devices I'm going to have two SRX's on each site and using vrrp between them, will I hit this exception then? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Errors on Juniper M7i
Got LSPs and RSVP/LDP paths in inet.3? - CK. On 2012-08-27, at 11:00 PM, Frank Norman wrote: Friends, i am getting following messages on my M7i Router which are causing problem with the MPLS VPN customers. Can someone explain me how to diagnose and resolve the issue??? Junos Version is 8.5 Aug 27 17:45:47 2012 R3-Atlanta /kernel: RT_PFE: NH IPC op 29 (CHANGE INDIRECT NEXTHOP) failed, err 5 (Invalid) Aug 27 17:45:47 2012 R3-Atlanta /kernel: RT_PFE: NH IPC op 7 (ADD UNILIST NEXTHOP) failed, err 5 (Invalid) Aug 27 17:45:47 2012 R3-Atlanta /kernel: RT_PFE: NH IPC op 29 (CHANGE INDIRECT NEXTHOP) failed, err 5 (Invalid) Aug 27 17:45:54 2012 R3-Atlanta cfeb NH: Failed to find nh (1327) for deletion Aug 27 17:45:54 2012 R3-Atlanta cfeb NH: Failed to find nh (262566) for deletion Aug 27 17:45:54 2012 R3-Atlanta cfeb NH: Failed to find nh (1314) for deletion Aug 27 17:45:48 2012 R3-Atlanta cfeb NH: Indirect nh (262579) with unknown target nh (262321) Aug 27 17:45:49 2012 R3-Atlanta cfeb NH: Unilist nh (262323) with unknown nh in list (1315) Aug 27 17:45:49 2012 R3-Atlanta cfeb NH: Indirect nh (262567) with unknown target nh (262323) Aug 27 17:45:49 2012 R3-Atlanta cfeb NH: Unilist nh (262325) with unknown nh in list (1313) Aug 27 15:51:15 2012 R3-Atlanta cfeb NH: Unilist nh (262430) with unknown nh in list (1641) Aug 27 15:51:15 2012 R3-Atlanta cfeb NH: Non-existant NH (1641:Unicast, 2) in generic change path Aug 27 15:51:15 2012 R3-Atlanta cfeb NH: Non-existant NH (1764:Unicast, 2) in generic change path Aug 27 15:51:15 2012 R3-Atlanta cfeb NH: Indirect nh (262466) with unknown target nh (262430) Aug 27 15:52:11 2012 R3-Atlanta /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP) failed, err 5 (Invalid) Aug 27 15:52:11 2012 R3-Atlanta /kernel: RT_PFE: NH details: idx 1766 type 2 ifl 125 Aug 27 15:52:11 2012 R3-Atlanta /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP) failed, err 5 (Invalid) Aug 27 15:52:28 2012 R3-Atlanta /kernel: RT_PFE: NH IPC op 28 (ADD INDIRECT NEXTHOP) failed, err 5 (Invalid) Aug 27 15:52:28 2012 R3-Atlanta cfeb L2RW: Fails to install L2 program Aug 27 15:52:28 2012 R3-Atlanta cfeb NH(nh_ucast_add): NULL l2rw_pgm_cptr Aug 27 15:52:28 2012 R3-Atlanta cfeb NH: Unilist nh (262426) with unknown nh in -Frank ___ 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 NIC Teaming
However, if the teaming you want to achieve is purely for redundancy, ..This can be enforced on the Server-side (in some type of active/passive control on the server's OS), and hence you can just make the SRX's use normal access ports. Weve done this for our VMWare clusters; as well as for individual servers which support this. The server controls which ethernet cable it forwards/listens to. Nothing much to do on the switch/srx/ex side of the equation. - Ck. On 2012-08-30, at 4:18 AM, Misha Gzirishvili wrote: Sorry, I misunderstood your question first time. Aggregating ports from different SRXes in cluster, do not works. Regards, Misha ___ 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 help for basic MPLS setup
I've always had troubles using an EX4200 as a P router.
The only way Ive gotten it to kinda work is to build an LSP with the endpoint
having protocols { mpls { explicit-null; }}, so any EX4200 in the middle
doesn't try to 'pop' the outer label if it happens to be the penultimate…
although my memory is sketchy on this… (I *think* I got it working across an
EX4200 as a P this way.. Your Mileage May Vary)
The only MPLS thing Ive ever seen in use is to make CCC's. i.e. think of using
an EX4200 device as an olds-style ATM Edge Device, where it turns ethernet
into a PVC/RFC1483..cough.cough.. I meant an LSP/CCC. Thats about the only
application I have found. LDP is a no-go as well, so L2CKT/Martini isn't
possible either…
- CK.
On 2012-09-25, at 5:51 PM, Phil Mayers p.may...@imperial.ac.uk wrote:
On 09/25/2012 03:16 AM, Tim Jackson wrote:
I'm pretty sure this is the case. EX4200 will not forward anything with 1
label.
Just... wow. What is MPLS even *for* on those boxes?
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Config help for basic MPLS setup
Really? Wow. ! That must be new that the EX4200 supports LDP. Which version of JunOS did they add LDP support into the 32/42 EX-series? Just tried checking the JNPR website and the data sheets. All I can find officially is RSVP/CCC support. Let me know where you spotted that. That opens up an entire avenue for Metro-E Deployments versus using MX or ACX series. - CK. On 2012-09-26, at 6:54 PM, Abdullah Baheer abdullahbah...@yahoo.com wrote: Actually Chris, in my experience, i think you must have LDP to run LSP/CCC on ex-4200, cough.. cough... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] CCC on EX, link state propagation
BTW, I also saw in the 12.2 Release Notes that LDP-based L2CKTs are now supported on the EX4500/4550. You can maybe use an l2circut/L2CKT instead of a CCC; using martini style status-tlvs to signal end-to-end availability. ...Haven't tried this in the Lab yet. Might be worth a shot to drop the interface ccc-style. - CK. On 2012-10-11, at 11:03 PM, Benny Amorsen benny+use...@amorsen.dk wrote: Benny Amorsen benny+use...@amorsen.dk writes: Can the EX series do that? I'm thinking of the EX4550 in particular, but information about other EX-switches is welcome as well. I hate to reply to myself, but according to http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/concept/ex-series-software-features-overview.html#mpls-features-by-platform-table the EX4550 cannot do CCC at all. That makes it all rather moot :) The EX4500 can, in 12.2. It looks like I will be doing q-in-q-tunnelling instead of CCC. /Benny ___ 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-CCC: Protocol Connection
You cannot tie 2 different connections/LSPs to the same interface, as CCC's are purely point to point Layer-2. You are attempting to do point-to-multipoint Layer-2 ethernet, hence VPLS is the solution here. - CK. On 2012-11-25, at 10:28 AM, Saba Sumsam saba+j...@eintellego.net wrote: Hi, I came across this post on Juniper NSP regarding VLAN-CCC: http://puck.nether.net/lists/juniper-nsp/1609.html I am stuck with the exact same issue. Was wondering if there is a way to achieve this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming
On 2012-11-28, at 9:36 AM, Luca Salvatore l...@ninefold.com wrote: So - my understanding is that VPLS multihoming is used to prevent layer 2 loops. How is this accomplished? Is it because the backup PE device does not forward any traffic (except for LDP stuff) and hence no loop is formed since backup PE is in a sort of 'blocking' state? The backup PE signals (to the rest of the network) that it isnt the designated PE for that particular site-identifier endpoint (due to the priority setting) via BGP. All the other PEs in the network simply don't forward traffic to it, nor does that 'backup' PE forward any CE traffic into the network. Ergo, no L2 loop. show vpls connections should reflect this state of affairs. - CK. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Multihoming
Correct (Assuming each PE only has 1 Link to the CE Network…) Chris - Chairman of the STP is evil and should be avoided if possible Committee. =) On 2012-11-28, at 1:24 PM, Luca Salvatore l...@ninefold.com wrote: Right, this is what I thought. Thanks for the info. So this type of configuration means that spanning-tree is not needed between CE and PE then? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] export OSPF routes as type 1
I'm trying to export some OSPF routes as type 1 external instead of the
default type 2 external.
I can't seem to find where it is done - I thought it would be done in the
policy map but I don't see an option.
policy-options {
policy-statement my-ospf-export-policy {
term static-and-direct-as-type-1 {
from protocol [ static direct ];
then {
external {
type 1;
}
accept;
}
}
}
}
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] netflow to Jflow
You have NTP enabled, and it's properly synced? - CK. On 2012-12-04, at 4:28 AM, Ali Sumsam ali+juniper...@eintellego.net wrote: The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS and QoS at penultimate hop ?
It was my understanding that the label was logically popped on Egress (in terms of how one would envision the packet flow); hence the outer label EXP bits were evaluated by the BA classifier on ingress properly. (Whether it's popped on ingress, yet evaluated prior-to-pop is a mechanics thing..) But yes, I have no documentation I can point to; off the top of my head that the above is indeed true. I would be interested to know for future information sake that the JNPR box is indeed doing the right thing so to speak… i.e. since the PIC/MPC pops the Layer-2 information as well, it needs to be able to read the 802.1P bits, if there is a 1p-VLAN tag BA applied to the interface. Hopefully we're also reading the outer EXP label at the same time; as this would make sense. i.e. if you're doing VLAN pop/swapping, you'd need to retain any BA-p-tag specific classification there as well, prior to any tag manipulation. 400 quatloos says it's done on ingress before the label is popped. - Ck. Simple question I'm not able to find answer for: what is the order of label pop operation and BA classification on penultimate router ? I have a gut feeling that label is stripped first and then BA classification is done on a naked packet, f.e., ipprec-based in case of IP packet, without taking (already stripped) EXP bits into account, but I can't find any documentation proving or disproving it... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MPLS and QoS at penultimate hop ?
*UNLESS* you use table-label in a l3vpn, then it gets re-classified after the
label POP.
Aha, Very true - Good ole vrf-table-label
So, to Alexandre for L3VPN, just do this:
class-of-service {
routing-instances {
all {
classifiers {
exp MY-CLASIFIER;
}
}
}
}
That'll take care of the vrf-table-label corner-case where the packet goes
in/out the vt.x/lsi.x interface.
This is in the Juniper Docs in either the COS manual or the MPLS VPN
Configuration guide; can't remember.. but remember looking this up just last
week.
- CK.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MTU problems over VPLS
How does one send back an ICMP please-fragment-this Message when you're emulating a blue wire? No router in the middle to send back to the customer. it's an L2 service. You're transparent to them IP-wise. No IP interface anywhere inside their bridge to source a packet from. - Ck. On 2013-02-12, at 5:57 PM, Luca Salvatore l...@ninefold.com wrote: I have a few sites connected via a VPLS core. The core devices are all MX 10 routers connected via 10Gb fibre. I'm having problems doing file copies (SCP between two Centos VMs). The issue is that the file copy never gets anywhere, on the Centos CLI it sits at 0% then says 'stalled' To fix this issue I have just set the MTU on the Centos machines to be 1400 - when this is in place the copy works and I get nice speeds. I don't believe I should have to modify the MTU though, shouldn't path MTU discovery take care of this? For example - I have done some TCPdumps, I can see the sender is sending traffic with the DF bit set, however I don't see any 'ICMP fragmentation needed' coming back from the MX saying the MTU is too big, I assume this should be the case. I haven't modified any of the MTU's on the MX, everything is just the default. I also have normal layer 3 running over the fibre between the routers and when I use that I don't see any issues, so it must be something to do with VPLS. Any thoughts would be greatly appreciated. Thanks Luca. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
