Re: [j-nsp] mx240 vs asr 9006
Pro JUNOS: I would add that JUNOS I think has much better automation features. Also there are some interesting features on the MX that make deploying appliance-in-the-cloud setups easier to deploy (BGP capable appliance between MPLS LERs). I generally think VPLS is easier in JUNOS. Pro Cisco: MPLS/VRF aware foo. Like NAT, SSL, IPSec/GET, and just a load of other features. Although I'm not sure how much of this applies to the 9k.. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Mark Tinka mark.ti...@seacom.mu To: juniper-nsp@puck.nether.net Sent: Sunday, May 20, 2012 2:51 PM Subject: Re: [j-nsp] mx240 vs asr 9006 On Wednesday, April 25, 2012 03:54:56 PM Phil Bedard wrote: Yes thanks for mentioning that. My opinion would be to use a MX480 like someone else said just due to the increased slot capacity, over the 9006 or 240. For me, the extra 2x slots on the MX480 wouldn't be a compelling-enough reason to choose it over the ASR9006. Like someone mentioned earlier, chassis pricing is so negligible that it makes more sense to go for an MX480 over an MX240 like it would to go for an ASR9010 over an ASR9006. In our case, it's mostly come down to how much we want to scale in the space that we (don't have), which is why an MX240 has never made any sense to us, just like the ASR1004. Moroever, both the MX and ASR9000 chassis' are shipping faster line cards that mean you can pack more bandwidth into a single slot by the time you think about scaling across the entire chassis. Having operated both platforms in the same network, while I'll always have both vendors in my network as principle, my reasons to choose one over the other would be: o I'd prefer an ASR9000 over the MX because of the more intuitive ingress packet marking on the Cisco. Juniper can now do it on the Trio line cards with firewall filters, but it doesn't support marking of EXP bits. If only Juniper - despite the numerous times I've asked - could implement the ToS Translation Tables feature that they do for the IQ2 and IQ2E PIC's for the M- series routers, on the MX line, it would bring them inline with Cisco on this platform (Juniper's classic egress marking/rewriting has always been awkward, IMHO). o I'd prefer the MX because it implements NG-MVPN, while Cisco are still mucking about, re-enacting the LDP vs. BGP fiasco of old. o I'd prefer the the Cisco if I had to mix the classic and newer line cards in the same chassis, as (at least for a long while), mixing DPC's and MPC's was problematic. Word is that this is no longer an issue - I'm due to test. o I'd prefer the Juniper because Cisco make you pay for ridiculous licenses just to deploy l3vpn's on the ASR9000. You get the point... but: o Either router would be fine for basic IPv4, IPv6 and MPLS services. o Either router would be fine for PE Aggregation scenarios in Metro-E networks. o Either router would be fine if I wanted to add non-Ethernet line cards to it (the MX is now sporting these, even though I'm wary it may not be mature yet). o Either router would be fine if I wanted to run 100Gbps Ethernet ports. Hope this helps. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX
10.4R9? This makes me very happy... I thought they were going to stop at R8. I think they really need/want a golden release for the MX and R8 was supposed to be it. R9 will be good... we hope. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Paul Stewart p...@paulstewart.org To: juniper-nsp@puck.nether.net Sent: Monday, January 30, 2012 5:12 AM Subject: Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX Hey Chris yeah, that just showed up about 2 weeks ago (at least that's when I noticed it). Since JTAC isn't supposed to provide you with recommended releases on M/T/MX, at least this KB is a reference point... also nice to see them update the MX recommended release ;) Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chris Kawchuk Sent: Monday, January 30, 2012 3:54 AM To: juniper-nsp@puck.nether.net Subject: [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 ___ 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] Internet routes in MPLS network, global table or own VRF?
I didn't think the design was that complicated. Need to get default route into customer VRFs. Need to support firewall-in-the-cloud. Done. With reporting and tiered bandwidth. Agree with Mark's points below, however. We started off like wee! when it came to MPLS-TE... but then decided to just use LDP by default and MPLS-TE as the exception. Also, we could have put the internet into an LSYS. In fact... now I'm thinking we should do that. For stuff in the same data center as the internet pipe, we are seeing ~1ms of delay from edge-to-edge. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Mark Tinka mti...@globaltransit.net To: Pavel Lunin plu...@senetsy.ru Cc: Sent: Thursday, January 26, 2012 9:21 PM Subject: Re: [j-nsp] Internet routes in MPLS network, global table or own VRF? On Friday, January 27, 2012 03:48:23 AM Pavel Lunin wrote: What the VRF-based Internet users will definitely notice is (looks like RAS is tired of telling this story) is ICMP tunneling and consequent hard to interpret delay values. People are very suspicious to the numbers. This is almost impossible to explain, that the numbers, traceroute shows, have nothing to do with their kitty-photos-not-loading problem. One of the reasons we: o Don't disable TTL propagation across our MPLS network. o Avoid, as much as possible, running MPLS LPS's that differ, greatly, from IGP routing (i.e., LDP vs. RSVP) for Internet traffic. This issue is massively exacerbated if you're running FA's, which is why if we have to send traffic down RSVP LSP's, we prefer IGP Shortcuts (Autoroute Announce). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Internet routes in MPLS network, global table or own VRF?
http://packetpushers.net/internet-as-a-service-in-an-mpls-cloud/ Check that out... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Mark Smith gggla...@gmail.com To: juniper-nsp@puck.nether.net Sent: Thursday, January 19, 2012 9:05 AM Subject: [j-nsp] Internet routes in MPLS network, global table or own VRF? Hi How should the global Internet routes be organized in IP/MPLS network? Should they be put into global (inet.0) routing table or in their own VRF (e.g. internet.inet.0)? Assume same P/PE routers are used to route internet and VRFs. What are the pros and cons of these approaches? Pointers to good materials are appreciated. (please excuse me if this is in the series of stupid questions ;) 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] Unit ID's and q-in-q
You can do this with a properly constructed XPath expression... I will look at this later in the lab Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX VPLS Trunk with VLAN rewriting
I don't have the answer immediately for you, so I apologize.
But I wanted to chime in with a THIS IS WHAT I'M TALKING ABOUT comment. The
MX is super flexible and has loads of features with respect to
VLANs/BRIDGING/VPLS/PBB etc, but its confusing as shit and the documentation is
not the greatest.
There really ought to be an entire book *just* about this topic. Written in a
tutorial fashion. Covering Q-in-Q, VPLS, PBB, VLAN tag manipulation, bridging
features, etc. All on the MX specifically. It needs to cover the various
encapsulation types, family bridge, etc.
The MX solution guide isn't making it happen.
Still, I heart the MX immensely. Especially now that we are finally seeing
quality code on it... or better quality code anyway.
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://packetpushers.net/author/dwinkworth/
From: Sebastian Wiesinger juniper-...@ml.karotte.org
To: Juniper NSP juniper-nsp@puck.nether.net
Sent: Thursday, December 22, 2011 8:34 AM
Subject: [j-nsp] MX VPLS Trunk with VLAN rewriting
Hi,
I'm trying to setup a VLPS Trunk (many VLANs - one VPLS instance) on
MX960 (Trio MPC) where each site has different local VLAN-IDs which
should be bridged over VPLS.
Example:
Site 1 VPLS Site 2
LAN1: vl100 vl10 vl200
LAN2: vl301 vl11 vl201
I did the following config:
Site1:
interfaces {
ae2 {
unit 100 {
encapsulation vlan-vpls;
vlan-id 100;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 301 {
encapsulation vlan-vpls;
vlan-id 301;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.100;
interface ae2.301;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 1;
interface ae2.100;
interface ae2.301;
}
mac-flush {
any-interface;
}
}
}
}
}
Site2:
interfaces {
ae2 {
unit 200 {
encapsulation vlan-vpls;
vlan-id 200;
input-vlan-map {
swap;
vlan-id 10;
}
output-vlan-map swap;
}
unit 201 {
encapsulation vlan-vpls;
vlan-id 201;
input-vlan-map {
swap;
vlan-id 11;
}
output-vlan-map swap;
}
}
routing-instances {
test-service {
instance-type vpls;
vlan-id all;
interface ae2.200;
interface ae2.201;
vrf-target target:65000:10003;
protocols {
vpls {
no-tunnel-services;
site local-ce {
site-identifier 2;
interface ae2.200;
interface ae2.201;
}
mac-flush {
any-interface;
}
}
}
}
}
When I try to commit this config I get an error:
[edit routing-instances test-service interface]
'ae2.100'
interface with input/output vlan-maps cannot be added to a routing-instance
with a vlan-id/vlan-tags configured
JunOS version is 11.2R4
When I remove vlan-id all from the VPLS instance the config commits
but no bridge is formed, the clients on each site cannot reach each
other.
Any idea what to do? Our Juniper consultant said it would be possible
to do this.
Regards
Sebastian
--
New GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
Old GPG Key-ID: 0x76B79F20 (0x1B6034F476B79F20)
'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
-- Terry Pratchett, The Fifth Elephant
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unit ID's and q-in-q
Just do it sequentially and then write an op script that takes the vlan(s) as an argument to show you the interface info you are looking for... Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX
Scratch that, it was bigger tx/rx buffers for sockets... internal sockets. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Derick Winkworth dwinkwo...@att.net To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tuesday, December 6, 2011 7:45 AM Subject: Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX FWIW, some socket related changes were made in 10.4 (I believe)... Bigger windows by default. I haven't verified with Wireshark, but this is what I've heard. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Paul Stewart p...@paulstewart.org To: 'Alexandre Snarskii' s...@snar.spb.ru Cc: juniper-nsp@puck.nether.net Sent: Monday, December 5, 2011 9:23 AM Subject: Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX Thanks - that actually makes a lot of sense ;) We don't see any load to speak of on our side but it does typically occur when a BGP session is reset and we're sending out a full table to a customer... Appreciate it, Paul -Original Message- From: Alexandre Snarskii [mailto:s...@snar.spb.ru] Sent: Monday, December 05, 2011 10:09 AM To: Paul Stewart Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Resource Temporarily Unavailable - Juniper MX On Mon, Dec 05, 2011 at 07:48:22AM -0500, Paul Stewart wrote: Can anyone shed some light on these log messages? Nov 30 04:48:21 core2.toronto1 rpd[1359]: bgp_send: sending 19 bytes to xx.xxx.52.50 (External AS x) blocked (no spooling requested): Resource temporarily unavailable We get these every so often .. Presuming it has to due with load on the system for a short period of time? More possibly it's caused by remote system load (or link congestion or whatever other reason for remote system not able to receive updates fast enough). Then, when socket buffer is full with unacknowledged data, your system tries to send another update/keepalive message and it results in write(2) syscall returning EAGAIN error (actually, not an error, just and indication of 'no data sent, try again later'), which translates to Resource temporarily unavailable message. Platform is Juniper MX boxes running 10.0R3.10 Thanks, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- In theory, there is no difference between theory and practice. But, in practice, there is. ___ 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] Does a L3VPN RR require routing-instance for each VRF?
You don't need to define any VRFs. I'll post a config later. You don't need static routes for each PE either, you can just have a default route to discard in inet.3 and it'll work. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth/ From: Phil Mayers p.may...@imperial.ac.uk To: Keegan Holley keegan.hol...@sungard.com Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tuesday, November 29, 2011 7:06 AM Subject: Re: [j-nsp] Does a L3VPN RR require routing-instance for each VRF? On 29/11/11 12:55, Keegan Holley wrote: Do you have family inet-VPN configured in the group stanza? All the Yes. I also have routes in the inet.3 table matching the next-hops (to reply to the many people who unicasted me off-list). I have tried both a static and LDP. routes are reflected from the bgp.l3vpn.0 table. You don't have to This does not occur unless I define a routing-instance. In fact, with no routing-instance defined, the bgp.l3vpn.0 table is simply absent. define each vrf. If you already configured the address family it sounds like it doesn't like your ext. communities for some reason. Where would the ext. communities come from if I haven't defined a routing-instance? ___ 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] End host mapping tool
If you enable LLDP on all your switches/devices... and you have an all Juniper
network... you could write a JUNOScript that would do this... *and* do the OUI
lookup too.
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://blinking-network.blogspot.com
From: Chris Kawchuk juniperd...@gmail.com
To: Dale Shaw dale.shaw+j-...@gmail.com
Cc: juniper-nsp juniper-nsp@puck.nether.net
Sent: Sunday, November 27, 2011 8:40 PM
Subject: 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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] OpenFlow Symposium on the 26th...
There are four tickets left for the OpenFlow Symposium on the 26th. Its at the Doubletree hotel in San Jose, California on the 26th (this Wednesday). http://openflowsymposium.eventbrite.com/ Just thought I might bring this up since there has been some OF discussion here on the list. Juniper will be there and as some of you know there has been some experimentation on the MX with an OpenFlow instance type. See http://networkingnerd.net/2011/10/23/info-about-open-flow/ for more info on the event and some links to blog posts (including my own) about OpenFlow. Derick Winkworth (@CloudToad) CCIE #15672 (RS, SP), JNCIE-M #721 http://www.packetpushers.net/author/dwinkworth ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS 10.4R7
Anyone get a chance to run it through some tests? Put it in production yet? We've been busy here so I haven't had much time to play. Just got back from EBC and they talk a good game on this release and 10.4R8... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] general question on VRFs and FIBs...
All: I actually received quite a few responses off-list to this question. We have to deal with many different audit/compliance agencies each with their own guidelines. One of their guidelines is that security zones should reside on physically separate switches. However, in an MPLS based on environment they allow for VRF/VSI separation on the same physical device. The reason is that each instance has its own RIB and its own FIB structures. At least, this is what I've heard now from multiple auditors over the last 6 or 7 years while working for different companies. I'm questioning this in general because we are looking at OpenFlow. In particular, the question came up Are separate structures really necessary? What if the FIB lookup was entirely hash-based (source-port included) and each entry in the hash table had a mask-structure associated with it (for src/dst mac and IPs?). I previously blogged that a (totally hypothetical) multi-tenant network built entirely with PBR or FBF would not pass audit because of a lack of separate RIB and separate FIB structures for each tenant in the network. Why wouldn't this pass audit? OpenFlow is similar. In this potential OpenFlow design there would still be separate VRFs on the controllers, but ultimately the forwarding would be compiled into this single hash table structure. So I'm questioning a basic assumption here: Are separate FIB structures for each VPN required? What I am hearing is mainly ASIC/NPU/FPGA design/performance concerns. Robert expressed some concerns over one VPN potentially impacting other VPNs with something like route instability or table corruption of some kind.. crashing was the word he used :-). I did spray a few lists with this question, but they are lists where the right people generally lurk... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://packetpushers.net/author/dwinkworth From: Robert Raszuk rob...@raszuk.net To: Gert Doering g...@greenie.muc.de Cc: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net; cisco-...@puck.nether.net cisco-...@puck.nether.net Sent: Tuesday, September 27, 2011 3:58 AM Subject: Re: [c-nsp] general question on VRFs and FIBs... Hi Gert, address first, VRF second. Well no one sane would do that ;) I believe what Derick was asking was why not have incoming_interface/table_id - prefix lookup. And while in software each VRF has separate RIB and FIB data structures for reasons already discussed on L3VPN IETF mailing list in actual hardware on a given line card however this may no longer be the case. Also side note that most vendors still did not implement per interface/per vrf MPLS labels (even in control plane) so all labels are looked up in a global table with just additional essentially control plane driven twicks to protect from malicious attacks in the case of CSC/Inter-AS. Cheers, R. Hi, On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote: I'm trying to find an archived discussion or presentation discussing why exactly the industry generally settled on having a separate FIB table for each VRF vs having one FIB table with a column that identifies the VRF instance? I'm not finding it, but I'm guessing its because of performance issues? Lookup would fail for overlapping address space if you lookup address first, VRF second. How do you find the right entry if you have 10.0.0.0/8 vrf red 10.0.0.0/16 vrf green 10.0.1.0/24 vrf blue and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which is tagged vrf blue. Alternatively, you'd need to explode the /8 entry for vrf red if *another* VRF adds a more specific for that /8. gert ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX RE how fast is slow
there is nothing subjective about your assessment of the ASR RP1. Cisco should not be selling this junk in the first place. Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Experiences - Was: JUNOS 10.4S6 for EX8200 - PR/676826
1. Have you opened tickets? 2. Did you look in the Defect Search tool? We have SRXs in our environment and there has been some issues, but thus far all have been identified and resolved over time. Months actually rather than years. At least for us, Juniper has been quick to resolve issues. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Stephan Tesch step...@tesch.cx To: juniper-nsp@puck.nether.net Sent: Friday, September 2, 2011 5:29 AM Subject: Re: [j-nsp] SRX Experiences - Was: JUNOS 10.4S6 for EX8200 - PR/676826 Am 01.09.2011 23:06, schrieb Scott T. Cameron: I have 2x chassis cluster with SRX3400s. ALGs will destroy your soul. Avoid at all costs. Additionally, they don't work when firewalling over two virtual routers (which I did need for a setup on a chassis cluster). The ports then get only open for one of the involved zones, the zones for the other virtual router don't seem to care for the opened ports, or the ALG just doesn't open the ports for that zones, ones it has been processed. Very uncool... Regards, Stephan ___ 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] Running OSPF to manage loopbacks, only have trunks
What platform is this? If its an MX, you can change the encapsulation of the physical interface to flexible-ethernet-services and then you can add a unit with family inet on it. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Morgan McLean wrx...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tue, August 30, 2011 9:55:02 PM Subject: [j-nsp] Running OSPF to manage loopbacks, only have trunks So for example, if I have a meshed layer 2 network with switches and I would like to be able to maintain device reachability using something like OSPF, how would I go about doing this? Everything already had two connections to its upstream etc, but they are in the form of trunks. Junos won't let me add a unit when there is already a unit set as ethernet switching and port mode trunk. Is there any way I can create an addressable interface just for point to point ospf neighbor relationships, and maintain my ethernet trunks? What I don't want to do is run additional cables between everything. I already run two uplinks from every access switch into my core switches. 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. I could maybe make private vlans between each link, but again thats bad because I'll eventually run out of tags! This is just me getting creative at this point, lol. Thanks, Morgan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Multi-tenant VMWare using the MX platform...
http://blinking-network.blogspot.com/2011/08/multi-tenant-vmware-with-junipers-mx.html Using VLAN normalization on the MX to overcome VLAN overlap, and using Juniper's vGW product with VMWare port-groups to provide secure network path isolation all the way to the VM. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NAT on M120 with MS-PIC
You need two rules actually, you have a rule for the input direction, you
need
a rule for the output direction as well...
nat {
pool 87 {
address 41.72.x.86/32;
}
rule test-out {
match-direction output;
term t1 {
from {
destination-address {
41.72.y.254/32;
}
}
then {
translated {
source-pool 87;
translation-type {
destination static;
}
}
}
}
}
}
it'll look something like that... then add that rule to the service-set...
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://blinking-network.blogspot.com
From: Mauritz Lewies maur...@three6five.com
To: juniper-nsp@puck.nether.net
Sent: Sun, August 14, 2011 4:05:22 PM
Subject: [j-nsp] NAT on M120 with MS-PIC
Hi
I have a M120 with Junos 10.4 R5.5 and a MS-PIC.
I'm trying to get one-one static NAT working, but alas no success.
This is the relevant config:
root@ZMT-ZM-LMY-MSE-001-RE1 show configuration chassis
redundancy {
routing-engine 0 master;
routing-engine 1 backup;
failover {
on-loss-of-keepalives;
on-disk-failure;
}
graceful-switchover;
}
fpc 5 {
pic 3 {
adaptive-services {
service-package layer-3;
}
}
}
{master}[edit services]
root@ZMT-ZM-LMY-MSE-001-RE1# show
service-set test {
nat-rules test;
interface-service
service-interface sp-5/3/0
}
nat {
pool 86 {
address 41.72.y.254/32;
}
rule test {
match-direction input;
term t1 {
from {
source-address {
41.72.x.86/32;
}
}
then {
translated {
source-pool 86;
translation-type {
source static;
}
}
}
}
}
}
root@ZMT-ZM-LMY-MSE-001-RE1 show configuration interfaces ge-2/0/1.111
vlan-id 111;
family inet {
sampling {
input;
output;
}
service {
input {
service-set test;
}
output {
service-set test;
}
}
address 41.72.x.26/30;
}
{master}
But then this output:
root@ZMT-ZM-LMY-MSE-001-RE1 show services nat mappings summary
Total number of address mappings: 0
Total number of endpoint independent port mappings: 0
Total number of endpoint independent filters: 0
{master}
root@ZMT-ZM-LMY-MSE-001-RE1 show services nat mappings summary
Total number of address mappings: 0
Total number of endpoint independent port mappings: 0
Total number of endpoint independent filters: 0
{master}
root@ZMT-ZM-LMY-MSE-001-RE1 show services nat statistics interface ge-2/0/1.111
{master}
root@ZMT-ZM-LMY-MSE-001-RE1 show services nat statistics
Interface: sp-5/3/0
error: This command is not supported on sp-5/3/0 interface
{master}
Any help?
Regards,
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NAT on M120 with MS-PIC
no, thats normal... actually if sessions are always being initiated from outside in this case then he doesn't need the input direction rule... Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] LLDP on M series ?
good question... you'd think this would not be a platform specific feature... sometimes when a feature like this is announced for T-series devices, it shows up on M devices too... Sent from Yahoo! Mail on Android ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] tag-protocol-id matching in vlan-tags
I wonder if you had the frame egress a trunk if you would see it dual tagged
with 100/100, the expected outer-tag TPID, and the 0x8100 on the inner tag...
Derick Winkworth
CCIE #15672 (RS, SP), JNCIE-M #721
http://blinking-network.blogspot.com
--- On Thu, 7/28/11, David Ball davidtb...@gmail.com wrote:
From: David Ball davidtb...@gmail.com
Subject: Re: [j-nsp] tag-protocol-id matching in vlan-tags
To: Addy Mathur addy.mat...@gmail.com
Cc: Juniper-Nsp juniper-nsp@puck.nether.net
Date: Thursday, July 28, 2011, 10:27 AM
Ah, so I'm potentially not crazy (at least not for this reason).
See below, and thanks...
David
--- JUNOS 10.0R3.10 built 2010-04-16 07:14:00 UTC
{master}
me@router show interfaces ge-1/1/0
Physical interface: ge-1/1/0, Enabled, Physical link is Up
Interface index: 173, SNMP ifIndex: 250
Link-level type: 52, MTU: 9192, Speed: 1000mbps, BPDU Error: None,
MAC-REWRITE
Error: None,
Loopback: Disabled, Source filtering: Disabled, Flow control: Disabled,
Auto-negotiation: Disabled,
Remote fault: Online, Speed-negotiation: Disabled, Auto-MDIX: Enabled
Device flags : Present Running
Interface flags: SNMP-Traps Internal: 0x4000
CoS queues : 8 supported, 8 maximum usable queues
Current address: 00:22:83:75:69:9c, Hardware address: 00:22:83:75:69:9c
Last flapped : 2011-07-26 15:43:39 MDT (1d 17:08 ago)
Input rate : 978417760 bps (96149 pps)
Output rate : 988075168 bps (96491 pps)
Active alarms : None
Active defects : None
Logical interface ge-1/1/0.100 (Index 113) (SNMP ifIndex 170)
Description: 0x88A8 TPID test
Flags: SNMP-Traps 0x4000 VLAN-Tag [ 0x88a8.100 ] In(pop) Out(push
0x88a8.100)
Encapsulation: VLAN-CCC
Input packets : 14161344641
Output packets: 14161304171
Protocol ccc, MTU: 9192
Logical interface ge-1/1/0.32767 (Index 114) (SNMP ifIndex 171)
Flags: SNMP-Traps 0x4004000 VLAN-Tag [ 0x.0 ] Encapsulation: ENET2
Input packets : 0
Output packets: 0
Protocol multiservice, MTU: Unlimited
Flags: None
{master}
me@router
On 28 July 2011 04:54, Addy Mathur addy.mat...@gmail.com wrote:
On Wednesday, July 27, 2011, David Ball davidtb...@gmail.com wrote:
MX running 10.0 (DPCE-R-20GE-2XGE for int in question)
Should I expect that a logical unit configured with 'vlan-tags outer
0x88A8.100' would also permit frames using TPID 8100 and VLAN ID 100 ?
I kinda expected not (since it doesn't 'match'), yet if I change my
test set to send normal 0x8100.100 frames, they're still accepted by
the interface (config below) and stuffed into the associated VPN.
[edit interfaces ge-1/1/0]
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
gig-ether-options {
no-auto-negotiation;
ethernet-switch-profile {
tag-protocol-id 0x88A8;
}
}
unit 100 {
encapsulation vlan-ccc;
vlan-tags outer 0x88A8.100;
input-vlan-map pop;
output-vlan-map push;
}
Are my expectations that specifying the TPID in the vlan-tags
statement would ONLY match frames with that TPID wrong? Practice
would indicate that I'm wrong, but I guess I'm wondering if this is
expected behaviour.
David: I don't believe your expectation is incorrect. Could you please post
the exact JUNOS release (including minor version) and the output of show
interface ge-1/1/0?
TIA,
David
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNIPER-COS-MIB support in open source monitoring tools
We look at this these items now in Vitalnet. Its an Alcatel-Lucent product I think. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Dale Shaw dale.shaw+j-...@gmail.com To: Juniper-Nsp juniper-nsp@puck.nether.net Sent: Mon, July 25, 2011 5:10:47 PM Subject: [j-nsp] JUNIPER-COS-MIB support in open source monitoring tools Hi all, Is anyone aware of any effort to wrangle JUNIPER-COS-MIB support into open source monitoring tools such as MRTG, cacti etc.? Are there any commercial network monitoring/management packages that understand this MIB? I'm looking for something to allow us to graph/present things like utilisation, bps, pps, and drop rates *per forwarding-class*. If you've done this in your shop, could you please let me know? I'm willing to have a go at getting something happening, preferably with cacti. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS Scaling
Not to mention the use of dynamic profiles for the application of filters and tag-manipulation policies on VPLS LSIs... Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Stefan Fouant sfou...@shortestpathfirst.net To: tim tiriche tim.tiri...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Sun, July 24, 2011 9:55:33 AM Subject: Re: [j-nsp] VPLS Scaling On 7/23/2011 8:47 PM, tim tiriche wrote: Does Juniper support VPLS with 802.1ah? Has anyone deployed this? Hi Tim, On the MX Series devices, there is extensive support for (MAC) tunneling and bridging of Ethernet frames across Provider Backbone-Bridges which include the use and integration with VPLS as a transport mechanism. You'll find extensive per-port VLAN tag manipulation and normalization features which include support for 802.1ad (Q-in-Q) and 802.1ah (MAC-in-MAC). Take a look at the MX Solutions Guide which covers a lot of this in great detail - http://www.juniper.net/techpubs/en_US/junos11.1/information-products/topic-collections/solutions-guide-mx-series/mx-solutions-guide.pdf HTHs. Stefan Fouant JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI Technical Trainer, Juniper Networks http://www.shortestpathfirst.net http://www.twitter.com/sfouant ___ 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] [c-nsp] Firewalls as-a-service in an MPLS infrastructure...
From Fortinets website: # Chassis-based models can support up to 3000 VDOMs # Talked to Fortinet rep and confirmed it. its not that they recommend 250, its just that beyond 250 there is no support for some of the advanced features Fortinet considers their special sauce (e-mail scanning, etc). I'm pretty sure the actual maximum number of allowed VRs/zones on a 3k SRX is 1000. Or it will be soon. I'll verify that later this evening. The number of LSYS is in fact 32. However you don't get all those zones/vrs/nats/FW rules per lsys, those are just spread out across the LSYS... The ASA I think can support up to 500 contexts now, but with contexts enabled I'm hearing there is no crypto support. I'm not sure this is an impediment for us but I can see it being an issue for folks. Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721 http://blinking-network.blogspot.com From: Matthew M North matthew.no...@gmail.com To: Chandler Bassett cbass@gmail.com Cc: dwinkwo...@att.net; juniper-nsp@puck.nether.net; cisco-...@puck.nether.net Sent: Thu, July 7, 2011 9:57:21 PM Subject: Re: [c-nsp] Firewalls as-a-service in an MPLS infrastructure... Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... Thousands-no. They do 250 VDOMs on the high end units (3000 series), 500 VDOMs I heard on the 5001B (with some special licensing, haven't see or tested yet, they recommend max 250). Juniper SRX you can use VRs security zones. On Junos 10.4+ get 250 VRs. 5800 you can get 500 VRs. Have gotten # for lsys yet. On Thu, Jul 7, 2011 at 2:35 PM, Chandler Bassett cbass@gmail.com wrote: I thought the ASA blade was for the 6500's? On Wed, Jul 6, 2011 at 11:47 AM, Derick Winkworth dwinkwo...@att.netwrote: Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Firewalls as-a-service in an MPLS infrastructure...
Thoughts on this blog entry? I wonder if Cisco will support BGP on ASA soon.. I know people have been asking for it. It would be nice if it had something Netconf on it too... The new ASA blade is coming out for Nexus I hear, anyone know how many virtual-firewalls it will support? Juniper's SRX will do LSYS soon.. 32 per box. That seems like a low number. Fortinet does thousands of thier VDOMs (virtual-firewalls) on a single unit... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] strange packet loss without impact
In regard to #2 are you routing same-interface by chance? ICMP redirect disabled or is something not paying attention to them? I know some of your show command output might rule out some of these questions but there are two things I've learned never to have absolute faith in: (1) Marketing numbers and (2) show command output. --- On Mon, 7/4/11, Derick Winkworth dwinkwo...@att.net wrote: From: Derick Winkworth dwinkwo...@att.net Subject: Re: [j-nsp] strange packet loss without impact To: Matthias Brumm matth...@brumm.net, Christian cdebalo...@neotelecoms.com Cc: juniper-nsp@puck.nether.net Date: Monday, July 4, 2011, 8:58 PM 1. Have you thought of running your ping tests *thru* the box rather than *at* it? 2. I see you have pretty symmetrical in/out here, could you be experiencing something like a DDOS (router pushing out too many ICMPs)? 3. Packet capture at all? 4. 19k pps... is this high/normal/low for this interface? Do you have services enabled on it? J-Series is software router... From: Matthias Brumm matth...@brumm.net To: Christian cdebalo...@neotelecoms.com Cc: juniper-nsp@puck.nether.net Sent: Mon, July 4, 2011 10:25:38 AM Subject: Re: [j-nsp] strange packet loss without impact no, that is not the problem. I have looked into the Juniper definition and we have one discard routing entry, which should be responsible for this entry. the complete output: show pfe statistics traffic Packet Forwarding Engine traffic statistics: Input packets: 586522987655 19925 pps Output packets: 585165208482 19866 pps Packet Forwarding Engine local traffic statistics: Local packets input : 1228194454 Local packets output : 713668140 Software input control plane drops : 0 Software input high drops : 0 Software input medium drops : 13059 Software input low drops : 0 Software output drops : 0 Hardware input drops : 0 Packet Forwarding Engine local protocol statistics: HDLC keepalives : 0 ATM OAM : 0 Frame Relay LMI : 0 PPP LCP/NCP : 0 OSPF hello : 0 OSPF3 hello : 0 RSVP hello : 0 LDP hello : 0 BFD : 0 IS-IS IIH : 0 LACP : 0 ARP : 513852055 ETHER OAM : 0 Unknown : 0 Packet Forwarding Engine hardware discard statistics: Timeout : 0 Truncated key : 0 Bits to test : 0 Data error : 0 Stack underflow : 0 Stack overflow : 0 Normal discard : 557514914 Extended discard : 0 Invalid interface : 0 Info cell drops : 0 Fabric drops : 0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error : Input Checksum : 132684 Output MTU : 34 2011/7/4 Matthias Brumm matth...@brumm.net Hello! show pfe statistics traffic is the first command, showing some errors: Packet Forwarding Engine hardware discard statistics: Timeout : 0 Truncated key : 0 Bits to test : 0 Data error : 0 Stack underflow : 0 Stack overflow : 0 Normal discard : 557491798 Extended discard : 0 Invalid interface : 0 Info cell drops : 0 Fabric drops : 0 Is Normal discard an error or something Normal, as the name would say. Matthias 2011/7/4 Christian cdebalo...@neotelecoms.com ** If in doubt run show system processes summary to check for busy process during your peak time. Also you can have some interesting stats with a show pfe statistics traffic Christian Le 04/07/2011 15:33, Matthias Brumm
Re: [j-nsp] strange packet loss without impact
1. Have you thought of running your ping tests *thru* the box rather than *at* it? 2. I see you have pretty symmetrical in/out here, could you be experiencing something like a DDOS (router pushing out too many ICMPs)? 3. Packet capture at all? 4. 19k pps... is this high/normal/low for this interface? Do you have services enabled on it? J-Series is software router... From: Matthias Brumm matth...@brumm.net To: Christian cdebalo...@neotelecoms.com Cc: juniper-nsp@puck.nether.net Sent: Mon, July 4, 2011 10:25:38 AM Subject: Re: [j-nsp] strange packet loss without impact no, that is not the problem. I have looked into the Juniper definition and we have one discard routing entry, which should be responsible for this entry. the complete output: show pfe statistics traffic Packet Forwarding Engine traffic statistics: Input packets: 58652298765519925 pps Output packets: 58516520848219866 pps Packet Forwarding Engine local traffic statistics: Local packets input : 1228194454 Local packets output:713668140 Software input control plane drops :0 Software input high drops :0 Software input medium drops :13059 Software input low drops:0 Software output drops :0 Hardware input drops:0 Packet Forwarding Engine local protocol statistics: HDLC keepalives:0 ATM OAM:0 Frame Relay LMI:0 PPP LCP/NCP:0 OSPF hello :0 OSPF3 hello:0 RSVP hello :0 LDP hello :0 BFD:0 IS-IS IIH :0 LACP :0 ARP:513852055 ETHER OAM :0 Unknown:0 Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard :557514914 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Packet Forwarding Engine Input IPv4 Header Checksum Error and Output MTU Error : Input Checksum : 132684 Output MTU : 34 2011/7/4 Matthias Brumm matth...@brumm.net Hello! show pfe statistics traffic is the first command, showing some errors: Packet Forwarding Engine hardware discard statistics: Timeout:0 Truncated key :0 Bits to test :0 Data error :0 Stack underflow:0 Stack overflow :0 Normal discard :557491798 Extended discard :0 Invalid interface :0 Info cell drops:0 Fabric drops :0 Is Normal discard an error or something Normal, as the name would say. Matthias 2011/7/4 Christian cdebalo...@neotelecoms.com ** If in doubt run show system processes summary to check for busy process during your peak time. Also you can have some interesting stats with a show pfe statistics traffic Christian Le 04/07/2011 15:33, Matthias Brumm a écrit : Hello! At the moment I am monitoring it with top on UNIX shell, do you have another suggestion? In top this process is idleing. Regards, Matthias 2011/7/4 Christian cdebalo...@neotelecoms.com Hi, Try to monitor the fwdd process - when running high it causes packet to drop on these pc's. Christian Le 04/07/2011 13:11, Adam Leff a écrit : I realize this will sound silly, but have you checked for half-duplex on your interfaces? Those onboard J6350 interfaces are actually 10/100/1000, so if you don't have the speed and link-mode hardcoded, do a show interfaces extensive ge-0/0/# and check the link
[j-nsp] SQL*Net and firewalls..
New blog post I hope others find helpful... http://blinking-network.blogspot.com/2011/06/sqlnet-aka-oracle-tns-and-firewalls.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOScript IP Tools
New Blog Post: http://blinking-network.blogspot.com/2011/06/ip-tools-in-junoscript.html Feedback appreciated! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
Thats a very good point. Vyatta is a solid product. From: Keegan Holley keegan.hol...@sungard.com To: Richard A Steenbergen r...@e-gerbil.net Cc: juniper-nsp@puck.nether.net Sent: Friday, June 3, 2011 12:44 PM Subject: Re: [j-nsp] MX80 Opinions 2011/6/2 Richard A Steenbergen r...@e-gerbil.net On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. And then there was Vyatta ___ 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] Fw: MX80 Opinions
- Forwarded Message - From: Derick Winkworth dwinkwo...@att.net To: Richard A Steenbergen r...@e-gerbil.net Sent: Thursday, June 2, 2011 9:14 PM Subject: Re: [j-nsp] MX80 Opinions Amongst other things. Like a GDOI Server, or a JUNOScript jump box complete with development environment. So many things they could install on a Juniper-labeled PC... From: Richard A Steenbergen r...@e-gerbil.net To: jnprb...@gmail.com jnprb...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Thursday, June 2, 2011 9:10 PM Subject: Re: [j-nsp] MX80 Opinions On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] mpls question
You could use the EX to do this. However, you will need additional EXs to connect to the existing switches with the RVIs. Terminate your WAN into a WAN EX (assuming its ethernet handoff) and then connect this EX into your existing infrastructure via ethernet trunk. You have two options on the WAN EX: 1. Q-in-Q 2. Pseudowires A more robust and feature-rich options would be the MX. Then you could provide VPLS and Layer 3 services at the edge of your data center of your L2 WAN... - Original Message - From: Johan Borch johan.bo...@gmail.com To: juniper-nsp@puck.nether.net Cc: Sent: Thursday, May 12, 2011 6:31 AM Subject: [j-nsp] mpls question Hi, I have a question regarding MPLS on ex-series. I have a situation where i need to connect several data centers together. I have never worked with MPLS before but my idea is to use MPLS to transport VLANs between the data centers. An example: a customer is located in it's own VRF and we use VLAN/RVI for servers and client networks, now I wan't to connect my core in DC1 to my core in DC2, is MPLS the right way to go? The data centers will be connected with multiple connections. I read somewhere that I can't use family ccc if the vlan has an RVI, is that correct? 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] MX480 troubles.
hahahahahaha... I wasn't being sarcastic or ironic or whatever the word is either. I'm being quite serious. We've had outstanding support from Juniper. We have had a couple duds in the TAC, but I guess I've been beaten down in that regard by so many vendors that I just accept this will happen. From: Richard A Steenbergen r...@e-gerbil.net To: Derick Winkworth dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net Sent: Wed, April 13, 2011 1:08:52 PM Subject: Re: [j-nsp] MX480 troubles. On Wed, Apr 13, 2011 at 10:48:30AM -0700, Derick Winkworth wrote: They don't 1.? immediately just blame you or 2.? just tell you to upgrade and sit and do nothing until you do 3.? or tell you that you should have known that with some very narrow set of unlikely circumstances after two or three weeks?some bug will occur.? I don't know what 7 leaf clover you picked to have that kind of luck, but all 3 of the above describe nearly every one of my (many, many) JTAC cases. I'd also throw in: 4. Repeatedly fail to read/comprehend anything you say in the ticket, sometimes for months (or even years) on end. Just the other day I had an exchange with ATAC which went something like this: Me Hi, when this bgp neighbor flaps it sometimes doesn't syslog the event correctly, and instead records garbage messages. ATAC The bgp neighbor is flapping, that is why you are logging the neighbor down, can I close this case? I couldn't make this stuff up if I tried. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 - restricted bundles and disabled 10G ports.
Argh! Please tell me this is a joke! From: David Ball davidtb...@gmail.com To: Juniper-Nsp juniper-nsp@puck.nether.net Sent: Tue, April 12, 2011 9:46:45 AM Subject: [j-nsp] MX80 - restricted bundles and disabled 10G ports. A question almost too obvious to ask, but can someone with one of the restricted MX80 bundles (which disables 2 of the 10G ports) confirm that ports 0/0/0 and 0/0/1 are the ones left enabled? I don't have a restricted one yet, and am trying to finish a standards doc. Thanksjust trying to avoid assumptions here. g David ___ 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 and microbursting...
All: I have a Cisco 7206VXR w/NPE-G2 attached to an MX. The issue I am seeing is ignored packets on the 7200. It turns out, the 1G interfaces on the NPE-G2 have 128 packet rx-rings and this is not a tunable thing. I have tuned up buffers and hold-queues on the 7200 and this has drastically reduced the number of dropped packets, but still there is this rx-ring limitation. This is actually a fairly well known issue as I understand it. Is there anything I could do on the MX to control the microbursting outbound towards the 7200? Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX and microbursting...
I was thinking of just applying a shaping-rate at the port level. As it stands not more than 300m or so could ever pass through this interface (based ultimately on the sum of the interfaces the traffic is routing to at the WAN edge). It turns out actually there is an EX-4200 between the MX and the 7200. So I'm thinking of just applying a port-level shaper on the EX at 400m or 500m. Flow-control is a no go. From: sth...@nethelp.no sth...@nethelp.no To: dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net Sent: Mon, April 11, 2011 1:13:08 PM Subject: Re: [j-nsp] MX and microbursting... I have tuned up buffers and hold-queues on the 7200 and this has drastically reduced the number of dropped packets, but still there is this rx-ring limitation. This is actually a fairly well known issue as I understand it. Is there anything I could do on the MX to control the microbursting outbound towards the 7200? You might be able to do something with Ethernet flow control - I don't remember if the NPE-G2 can send pause frames. However, most likely you have to do shaping on the MX. Shaping can buffer and smooth out bursts. Obviously, to do this it has to *delay* some packets. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX and microbursting...
We've done that. Its the rx-ring on the controller in the NPE-G2. That is not
tunable. A show controller indicates we are basically microbursting 128 or
more
packets at a time (faster than the next cycle to pull packets off the ring).
Increasing the permanent buffers and the hold-queue definitely reduced the
number of dropped packets significantly, but still over the last 8 hours
(business day) I see about 10k drops. Granted, its over 1.2 billion packets.
I
just don't like seeing 10k drops during the business day.
I will apply traffic-shaping as per previous post.
From: Chris Evans chrisccnpsp...@gmail.com
To: sth...@nethelp.no
Cc: juniper-nsp@puck.nether.net
Sent: Mon, April 11, 2011 3:15:59 PM
Subject: Re: [j-nsp] MX and microbursting...
You can adjust buffers on the 7200. It is not an interface parameter tho.
On Apr 11, 2011 2:56 PM, sth...@nethelp.no wrote:
{master}
show configuration class-of-service fragmentation-maps
DO_NOT_FRAG_RT-768
forwarding-class {
RT {
no-fragmentation;
}
BE {
fragment-threshold 768;
}
SG {
fragment-threshold 768;
}
}
Eh? He said GigE. According to
http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-services/fragmentation-maps-edit-cos.html
fragmentation-maps is for link service IQ interfaces only.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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] VPLS scalability question.. OTV answer?
Do you have a link for documentation about the 10G interfaces? I was under the impression you weren't really stealing a 10G interface.. if you enable tunnel services on a 10G interface then you lose an interface, but with no-tunnel-services I thought you didn't need to do that... From: Chris Evans chrisccnpsp...@gmail.com To: juniper-nsp@puck.nether.net Sent: Sun, March 27, 2011 5:53:14 PM Subject: [j-nsp] VPLS scalability question.. OTV answer? All the communication that we've received from Juniper is that they perceive MPLS and VPLS to be their answer to Cisco's OTV. I've been researching VPLS on the Juniper platforms and I cannot find any definite information as to how much it can scale performance/bandwidth wise. VPLS requires either a VT interface or a LSI interface on that hardware. The VT interfaces can only be obtained by hardware that can do tunnel services, and the LSI interface is only on the MX platforms from what I can read. As tunnel PICs have limited performance and LSI interfaces 'steal' physical 10Gig interfaces on the 10Gig MX blades (I know it won't on the GigE blades) how does Juniper expect to be able to provide high bandwidth VPLS while still providing high port density? The TRIO cards have some inline services, but does they offer these services? It seems like Juniper is expecting to throw another half baked solution out there to compete with Cisco and I'm not sure how they're going to scale the infrastructure. The Cisco solution uses the built in ASIC hardware to do this and do not require ports to be stolen, etc.. It really bothers me that you have to lose interfaces and/or install special hardware to do inline services, which only increases the cost of the platforms drastically. Anyone have some insight? Thanks Chris ___ 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] 10.0 or 10.4?
We are running 10.0S9 right now. 10.0S10 introduced a bug that leaves the CPU running at 100% on our M-series, and this bug is resolved in 10.0S13 which I think is out already. We haven't put 10.0S13 in production yet, but I suspect that this will be as close we will get to a bug-free release for the time being... From: Richard A Steenbergen r...@e-gerbil.net To: Chris Kawchuk juniperd...@gmail.com Cc: juniper-nsp juniper-nsp@puck.nether.net Sent: Tue, March 15, 2011 11:14:06 AM Subject: Re: [j-nsp] 10.0 or 10.4? On Tue, Mar 15, 2011 at 07:43:25PM +1100, Chris Kawchuk wrote: 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 hear people make this argument a lot, but in many cases it seems to be more of a knee-jerk reaction than a logical decision. The EEOL branches are definitely interesting once you get into the post-R4 timeframe, but I question the sensibility of trying to deploy it in the R2 timeframe just because it is the EEOL train. Honestly, in many cases the code doesn't even begin to get stable until it reaches R4 and EOL status. The problem we run into is that we almost always discover at least one serious bug in every R4, no matter how well-intentioned the development efforts, but because R4 marks the end of engineering status we're constantly chasing the next branch to get a bugfix for things introduced in the previous branch. Of course what that really means is we discover all new brokeness in the new branch, and the cycle starts all over again. EEOL releases can end up being a lot more stable since you aren't introducing any new features (though anyone who tells you they don't introduce a ton of new bugs just doing service releases is completely full of it :P), so they're a good thing. But, what is the real benefit to deploying 10.4R2 now, as opposed to say 10.3R3? Either way you'll have to do an upgrade later on, so until you get to 10.4R4 there is no difference in 10.4 being the EEOL branch. We recently spent a fair bit of time trying to decide between 10.3R3 and 10.4R2 for a lot of MX960 and EX8200 upgrades, and came to the conclusion that 10.4R2 was significantly buggier. Why JTAC is recommending it I can't even begin to guess, I really think they have the recommended version page hooked up to a random number generator some days, but in our testing it wasn't even close. Which isn't to say 10.3R3 is perfect, but it's definitely on the less broken than ever side of things. So far we haven't had any issues with Trio hardware or snmp problems that we saw in 10.2R3 or 10.3R2, and if you carry a large number of BGP routes with communities you'll see some significant performance gains in policy evaluation which can improve convergence times quite a bit. Off the top of my head some issues we've seen with 10.3R3 so far are: * Syslogging of BGP messages seems quite broken, in many cases not logging state changes correctly at all. * ISIS packets inside a l2circuit are eatten by MX's when vlan-mapping is configured on the endpoint vlan-ccc. * EX8200 power supplies will think they're running in 1200W 110V input power mode if you reinsert them after a reboot, even if fed with 220V power which should run them in 2000W mode. This will cause cards to power down if the chassis thinks there is insufficient power, so you may not have proper power supply redundancy. No doubt there are plenty more too, but at least in a core service provider role it's been a lot less bad (lets just say its nice to not have to hard clear bgp neighbors to make policy changes take effect :P). 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. Actually it's the opposite, 10.3 and 10.4 were both nobody touch anything that isn't essential no-feature releases, to try and bring the development framework into a more manageable state. I'll confirm that they're less broken than 10.2, but that certainly doesn't take much. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] Qfabric
Also integrated L2/L3 forwarding so that you don't hairpin traffic through a node where the L2/L3 pieces meet (like VPLS to a node where the IRB interface is..) From: Doug Hanks dha...@juniper.net To: Chris Evans chrisccnpsp...@gmail.com; Stefan Fouant sfou...@shortestpathfirst.net Cc: Juniper-Nsp List juniper-nsp@puck.nether.net Sent: Thu, February 24, 2011 11:15:53 AM Subject: Re: [j-nsp] Qfabric A lot of our customers require low latency: financial, higher education, HPC environments and utility. Juniper has taken the time to solve more than just the low latency problem. We're trying to solve larger problems such as how do you manage an entire campus or data center as one logical device; that's able to scale; and delivers performance and low latency. Doug -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chris Evans Sent: Wednesday, February 23, 2011 8:55 PM To: Stefan Fouant Cc: Juniper-Nsp List Subject: Re: [j-nsp] Qfabric Low latency is a buzz word. Who really needs it? Very few applications really need it. I work in the financial industry and the only place we have a use case for low latency is in the investment bank context.. its like 20 switches out of the thousands we have. retail, treasury, card etc. Couldnt care. Also keep in mind that Juniper is one of the last to meet the low latency game.They are talking the game finally and people are buying into it. Everyone else is or has already built lower latency switches than even these boxes already using the same merchant silicon. All in all I sure hope juniper gets this one right. The ex platforms still have a lot of catching up to do just to match Cisco and brocade features.. I don't care about latency I care about the features that I need to run my business. On Feb 23, 2011 10:11 PM, Stefan Fouant sfou...@shortestpathfirst.net wrote: Remember, a key differentiator is that TRILL solutions still require forwarding table lookups on each node; as such, end-to-end latencies are much higher. Another thing to point out is that QFabric allows exponential scaling in that each device added to the fabric contributes additional switching capacity, whereby we can achieve n^2 scaling benefits. It is interesting to see the n-squared problem turned on its head - usually meshes are complex and cumbersome - here, it only makes things better :) Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB4C956EC -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Ben Dale Sent: Wednesday, February 23, 2011 9:41 PM To: Juniper-Nsp List Subject: Re: [j-nsp] Qfabric My understanding of the Brocade VDX is that they use their own proprietary flavour of TRILL in order to handle the management of the switches? Happy for someone to correct me on this though. As Stefan pointed out - where the TRILL-based solutions fall down is controlling oversubscription - for every customer-facing revenue port, you need uplink(s) of equal capacity on *every* switch between point A and point B, which gets a bit hairy when your customer wants 10GB. Even on it's own though, the QFX looks like a pretty sweet box, but I don't think I've ever seen a Juniper Data Sheet with as many roadmap asterisks ; ) It'll be interesting to see if Juniper offer a half-sized QFabric down the road once they realise that not everyone wants / needs 128x 40GB attached switches Interesting times! On 24/02/2011, at 12:11 PM, Keegan Holley wrote: I think Brocade released nearly the same technology a couple of months ago in their VDX product. Cisco can't be far behind. Although, their solution will most likely be proprietary. As far as the technology I think spanning-tree and the current way of doing ethernet has not been ideal for some time. On Wed, Feb 23, 2011 at 9:04 PM, Stefan Fouant sfou...@shortestpathfirst.net wrote: It's more than just a competitive offering to compete with the likes of the Nexus switches from Cisco, and its also quite a bit different from Cisco's FabricPath or other similar TRILL offerings. With FabricPath and TRILL we solve the problem of wasted revenue ports associated with complex 3- Tier architectures and blocked Spanning Tree ports, but you still have a forwarding table lookup taking place on each node along the path. With QFabric we have a set of devices which combine to form a singular unified fabric, all sharing a single control plane and managed via a single pane of glass, but more importantly achieving reduced latency as a result of a single forwarding table lookup taking place on the ingress node. With such a configuration we can achieve end-to-end Data Center latency on the order of 5 microseconds. There is a lot more to it which is obviously covered in the
[j-nsp] VPLS questions and also lt interface questions...
All: When you configure 'no-tunnel-services' under VPLS, does the router still steal bandwidth from the PFEs in various line cards to support VPLS? It seems to me it does. A show interface terse shows logical interfaces dedicated to VPLS. From the PFE shell, these are ifls created for VPLS lsis: ### ADPC2(TL-MX240-A vty)# show xeth-pic 0 PIC Information pic name : XETH(2/0) port count : 10 ifd count : 10 debug flags : 0x0 mac db instance id : 1 num of dest filters : 3 macdb isr invoke count : 1636 link isr invoke count : 21 periodic poll : TRUE mac poll : TRUE num vpls lsi ifls : 1 num mf entries : 0 separate l2-l3 scheduler : FALSE Not the num vpls lsi ifls. On a 40 port 10/100/1000 blade if we fully populate the 10 ports associated with this PFE, then adding VPLS ifls on top of that means we are effectively oversubscribing the PFE, correct? 2. In the MX solution guide there is an example where you can connect L2 instances with L3 instances using lt interfaces. You need to enable tunnel-services on the PIC to do this, and in that configuration you specify a bandwidth of 1G on the 40 port 10/100/1000 card. The documentation says this is a reservation. What does this mean? That traffic tied to tunnel services is guaranteed 1G of bandwidth on the PFE but can use more if available? Or does it mean tunnel-services traffic will be policed at 1G? 3. (a) If I use no-tunnel-services in VPLS and I also decided to connect an L2 instance to an L3 instance using an lt interface pair and (b) the VPLS lsi ifl happens to be on the same PFE as the lt interface pair, does that mean traffic could potentially hit the same PFE twice? Thanks! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] NAT Redundancy on Juniper routers
Keep in mind that if you haven't already done so, you will need to have both an 'inside' and 'outside' rule for your NAT translation since the junos-ip ALG is unidirectional. From: Alex alex.arsen...@gmail.com To: Gökhan Gümüş ggu...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Mon, January 10, 2011 7:18:25 AM Subject: Re: [j-nsp] NAT Redundancy on Juniper routers Then you are in a better position than I thought :-) Just change your NAT rule(s) to include match on junos-ip ALG which skips L4 checks like TCP 3WHS being complete, and test. Let us know the test results please. Rgds Alex - Original Message - From: Gökhan Gümüş To: Alex Cc: juniper-nsp@puck.nether.net Sent: Monday, January 10, 2011 1:01 PM Subject: Re: [j-nsp] NAT Redundancy on Juniper routers Actually i am doing Static-Nat 1:1 :( Rgds, Gokhan On Mon, Jan 10, 2011 at 1:55 PM, Alex alex.arsen...@gmail.com wrote: Actually on a second thought I reckon You might be able to achieve physical-box NAT redundancy using static NAT and IP-ALG but: 1/ it is not scalable (static NAT is 1:1) 2/ I never tried this myself :-) Where the port translation is involved the sequence of events is as I described below. Rgds Alex - Original Message - From: Gökhan Gümüş To: Alex Cc: juniper-nsp@puck.nether.net Sent: Monday, January 10, 2011 12:46 PM Subject: Re: [j-nsp] NAT Redundancy on Juniper routers Hi Alex, Thanks for the response. So there is nothing i can do at this moment :( Regards, Gokhan On Mon, Jan 10, 2011 at 1:43 PM, Alex alex.arsen...@gmail.com wrote: Hello Gokhan Gumus, AFAIK this is not possible at the moment since flows are not shared between MSDPCs even inside same MX box let alone different physical boxes. So if R1 goes down the: 1/ TCP flows need to reestablish starting from 3-way handshake 2/ UDP flows with ALG need to reestablish starting from scratch (every ALG has different procedures) 3/ non-ALG UDP flows _can_ continue as if nothing happened depending on protocol, e.g. p2p UDP flows will resume from last xferred piece 4/ ICMP flows continue as if nothing happened If you need physical-box-redundant NAT I'd suggest to use SRX cluster. HTH Rgds Alex - Original Message - From: Gökhan Gümüs ggu...@gmail.com To: juniper-nsp@puck.nether.net Sent: Monday, January 10, 2011 12:15 PM Subject: [j-nsp] NAT Redundancy on Juniper routers Hi all, I am trying to achieve redundancy on Juniper routers while performing NAT. I have two Juniper MX960 router on the backbone with VRRP setup.I am configuring NAT on R1 successfull.Same NAT rules are existing on the other router but on R2,static route which is pointing sp interface is deactivated.Is there anyway to achieve automatic failover capability on NAT?In other words if something happened on R1, can R2 handle all NAT process without doing anything? Kind regards, Gokhan Gumus ___ 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
[j-nsp] fpc2 message...
Anyone know why this would be happening with an ms-400 service-pic? Its running at 2-4% CPU and less than one 1% memory utilization... # Dec 20 10:05:15 galaxy-01 fpc2 Transient flow-control asserted by MAC on sp-2/2 for 1 seconds Dec 20 10:05:16 galaxy-01 fpc2 Transient flow-control asserted by MAC on sp-2/2 for 2 seconds Dec 20 10:05:17 galaxy-01 fpc2 Prolonged flow-control asserted by MAC on sp-2/2 Dec 20 10:05:20 galaxy-01 fpc2 MAC flow-control cleared on sp-2/2 # ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] fpc2 message...
GRE, IPSec, and NAT. It is L3 mode. From: Nilesh Khambal nkham...@juniper.net To: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Mon, December 20, 2010 12:09:26 PM Subject: Re: [j-nsp] fpc2 message... Derek, What is the PIC being used for? Is it in L2 mode or L3 mode? Thanks, Nilesh. On 12/20/10 9:18 AM, Derick Winkworth dwinkwo...@att.net wrote: Anyone know why this would be happening with an ms-400 service-pic? Its running at 2-4% CPU and less than one 1% memory utilization... # Dec 20 10:05:15 galaxy-01 fpc2 Transient flow-control asserted by MAC on sp-2/2 for 1 seconds Dec 20 10:05:16 galaxy-01 fpc2 Transient flow-control asserted by MAC on sp-2/2 for 2 seconds Dec 20 10:05:17 galaxy-01 fpc2 Prolonged flow-control asserted by MAC on sp-2/2 Dec 20 10:05:20 galaxy-01 fpc2 MAC flow-control cleared on sp-2/2 # ___ 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] GRE Tunnel bet JUNIPER and CISCO
Is this an encrypted GRE tunnel over the internet? The recommended MTU is 1400 bytes on both ends. Use the clear-dont-fragment-bit knob on the juniper side, and do ip tcp mss-adjust 1360 on the Cisco side. Also on the Cisco side, ingress interfaces should have a route-map applied to clear the df bit of the packets similar to the following: route-map clear-df-bit permit 10 set ip df 0 interface fa0/0 ip policy route-map clear-df-bit Note that crypto ipsec clear df on the Cisco side does not work for traffic passing through GRE tunnels, and you should not have this command enabled if you are doing encrypted GRE tunnels. Similarly on the Juniper side, under the ipsec-vpn rule you should not configure the clear-dont-fragment-bit option (I forget the exact knob name, but its there). The reason for this is that if you configure path-mtu-discovery these options will break it. As noted below, you may have to lower the MTU or the tcp-adjust depending on the ciphers you are using. As much as possible, you want to avoid fragmenting and reassembling GRE or IPsec packets. I would lower the MTU and tcp mss-adjust until you stop seeing GRE and IPSec fragmentation. There are some odd bugs related to the clear-dont-fragment-bit option on the Juniper end. If you are doing packet classification ingress on the router, all packets must be classified with a loss-priority of low. Otherwise packets will get blackholed if the next-hop is over the GRE tunnel. I think this is fixed in 10.0S8, but not in 10.0R4. Probably is fixed in 10.2R3, but I haven't tested. From: Linder, Todd t...@onenet.net To: giulian...@uol.com.br; juniper-nsp@puck.nether.net Sent: Wed, November 3, 2010 9:15:02 AM Subject: Re: [j-nsp] GRE Tunnel bet JUNIPER and CISCO I recently had and a similar issue between a Juniper and a Cisco router, I resolved some of those symptoms by adjusting the tcp maximum segment size. You may have to play with this setting until it yields the best result. I use the ip tcp adjust-mss 1300 and applied it to the interfaces used. This size seemed to yeild the best results for my scenario. Todd Linder Network Support Engineer OneNet Oklahoma's Telecommunications Network -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Giuliano Cardozo Medalha Sent: Wednesday, November 03, 2010 8:04 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] GRE Tunnel bet JUNIPER and CISCO People, We are trying to close a GRE tunnel between juniper and Cisco routers without success. We have tried a lot of MTU configurations but the traffic is suffering a lot ... sometimes slow, sometimes do not open some pages. Have you ever configured something like this before ? Any tip ou configuration related to best practices ? Thanks a lot, Giuliano ___ 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
[j-nsp] VPLS issue...
All: We have a two site VPLS setup using virtual-switches. Site A has an IRB in the bridge-domain in the virtual-switch configuration. All is good when the two PEs have a BGP session and the LSPs are up between the two PEs. However, when Site B becomes unreachable, then the IRB and local interface at site A go down and the customer can no longer route out using the IRB. I need this irb and the local interface to stay up so Site A can still route out the IRB even if Site B goes down... I tried the connectivity-type irb knob, but it doesn't help. Running 10.0S8 on MX240s... Any thoughts? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VPLS issue...
- Forwarded Message From: Derick Winkworth dwinkwo...@att.net To: Daniel Hilj daniel.h...@ipnett.se Sent: Thu, October 21, 2010 1:24:12 PM Subject: Re: [j-nsp] VPLS issue... I need the local interface to remain up too. From: Daniel Hilj daniel.h...@ipnett.se To: Derick Winkworth dwinkwo...@att.net Sent: Thu, October 21, 2010 11:26:49 AM Subject: Re: [j-nsp] VPLS issue... Hi, To get around the fact of not having a local interface UP that you need for the IRB to be UP you can configure an lt-interface and add it to you instance. Best Regards/Med vänliga hälsningar Daniel Hilj 21 okt 2010 kl. 18:22 skrev Derick Winkworth dwinkwo...@att.net: All: We have a two site VPLS setup using virtual-switches. Site A has an IRB in the bridge-domain in the virtual-switch configuration. All is good when the two PEs have a BGP session and the LSPs are up between the two PEs. However, when Site B becomes unreachable, then the IRB and local interface at site A go down and the customer can no longer route out using the IRB. I need this irb and the local interface to stay up so Site A can still route out the IRB even if Site B goes down... I tried the connectivity-type irb knob, but it doesn't help. Running 10.0S8 on MX240s... Any thoughts? ___ 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] VPLS issue...
I found three ways to keep the local interface up so it can hit the irb interface even if all remote PEs for the VPLS instance are lost: 1. Use two physical ports to the PE from the CE, one for VPLS and one for L3. You could put a switch in front of your PE to accomplish this. I think this is the cleanest way. 2. Plug a cable into two ports on the same PE (both ends of cable going into same box). Build a bridge-group for the VLAN. Put one end of the cable into the bridge group. In the same bridge-group put the VLAN coming in from the CE. The other end of the cable put into the VPLS switch instance. Traffic coming from CE will be bridged to the one end of the cable then come back around into the VPLS instance. The irb interface is specified in the bridge-group. The irb interface can exist in any routing-instance. 3. Make an lt-x/x/x interface pair. Build a bridge-group for the VLAN, put the VLAN coming from the CE into the bridge-group. Put one of the lt interfaces into the bridge group. This lt interface should be encapsulation vlan. The other lt interface should be encapsulation vlan-vpls and put this into the VPLS instance. The irb interface is specified in the bridge-group. The irb interface can exist in any routing-instance. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Strange BGP behaviour on 10.0R3
Also you could statically configure the correct MAC address to see if that works too... From: William Jackson wjack...@sapphire.gi To: juniper-nsp@puck.nether.net Sent: Tue, October 12, 2010 4:48:09 AM Subject: [j-nsp] Strange BGP behaviour on 10.0R3 Hi We are seeing some strange behavior on an MX with 10.0R3. We have an Ethernet link to a switch where we have multiple eBGP peers. We and the peer are seeing the session come up and then expiring with hold-time received messages, other peers on the same segment work 100%. When doing a pcap we are seeing the following happen: Setup and establish session BGP session. Once established our router then starts to send the updates to the correct IP address but a different MAC. The pcap doesn't show any strange ARP behaviour, the MAC address that is suddenly used belongs to another peer. The session then obviously times out, we haven't seen messages or indicators as to why this is happening. JTAC are looking at it but don't seem to know why either. Anyone else seen this type of behavior? ___ 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] Study books.
http://www.onfulfillment.com/JuniperTrainingPublic/Category.aspx?d=44sid=323sm=d44 There is this too, the official courseware. You can order the courseware without the course. It can be expensive. If you have an SE or RE that can log into this, they can get the books much cheaper... you might be able to work something out with them. From: Keith kwo...@citywest.ca To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tue, September 21, 2010 1:27:56 PM Subject: [j-nsp] Study books. Hi. We just purchased an MX480 to replace our aging 7206vxr-G1. We spent a few months going back and forth, C or J. In the end J worked harder for our business and ended up with a redundant MX480. Our only experience was with an M10i five years ago so we are green. My coworker and I need some new books. Looking at Amazon, most of the books are at least five years old. Are any of them still relevant enough to warrant purchasing them? Anyone have books they want to recommend? Thanks, Keith ___ 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] 10.0S8 on MX...
Anyone try this yet or do any testing with it? I'm hearing that this is the version to go to for MX... Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Centralized scripts and copying to redundant routing-engines..
http://www.juniper.net/techpubs/software/junos/junos103/junos-xml-ref-oper/html/summary-oper-request107.html#2093716 You can write a script that will do it for you automatically You can copy files between the REs from the CLI... From: Chris Evans chrisccnpsp...@gmail.com To: juniper-nsp@puck.nether.net Sent: Thu, September 9, 2010 8:31:55 PM Subject: [j-nsp] Centralized scripts and copying to redundant routing-engines.. I have a question, hopefully someone has an answer.. I have setup centralized stored commit scripts, however I'm running into issues with devices (EX and MX) that have redundant routing-engines. The files have to be on both RE's to successfully commit as I use commit sync. How do I get the files on both RE's when using a central server?? The documentation says this: If a platform has dual Routing Engines, you need to refresh the commit scripts on both Routing Engines. The commit synchronize command does not refresh the commit scripts between Routing Engines. That is a very vague statement and gives no options on how to do it.. Also the backup RE has no connectivity to the network, only the primary does.. So how am I supposed to copy the files over? Thanks Chris ___ 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 POLICER
You need to put it all in the same term. From: Giuliano Cardozo Medalha giulian...@uol.com.br To: juniper-nsp@puck.nether.net Sent: Thu, September 2, 2010 11:07:08 AM Subject: [j-nsp] JUNOS POLICER People, We are trying to configure policers to logical interfaces created under IQ2E PIC. All policers are using firewall filters. One of them is a different situation ... we cannot rate all interface but only 3 IPs that pass thought the interface. But the policer is not worlink correctly: set firewall policer teste if-exceeding bandwidth limit 10m burst size 1000 set firewall policer teste then discar set firewall family inet filter policer term 10 from source-address 192.168.10.35/32 set firewall family inet filter policer term 10 then accept set firewall family inet filter policer term 10 then policer teste set firewall family inet filter policer term 20 from source-address 192.168.10.36/32 set firewall family inet filter policer term 20 then accept set firewall family inet filter policer term 20 then policer teste set firewall family inet filter policer term 30 from source-address 192.168.10.37/32 set firewall family inet filter policer term 30 then accept set firewall family inet filter policer term 30 then policer teste set firewall family inet filter policer term 40 then accept set interface ge-0/0/0 unit 100 vlan-id 100 family inet filter input policer The problem is ... the 3 chosen IPs are exceeding 10m. Sometimes 12, sometimes 18 Mbps. We need to use some special command for it ? Like - logical interface under policer ? What is the correct manner to use it ? Or we need to put it all in the same term ? Thanks a lot, Giuliano ___ 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] Netflow / JFlow questions
Its not possible on an M... Its one or the other, IPv4 or MPLS... http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/configuring-active-flow-monitoring-using-version-9.html You can define a version 9 flow record template suitable for IPv4 traffic, MPLS traffic, or a combination of the two. However, you can sample packets from only one type of family (inet or mpls) at the same time. From: Chris Evans chrisccnpsp...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tue, August 31, 2010 8:01:44 PM Subject: [j-nsp] Netflow / JFlow questions Have a few questions for some folks who have implemented JFlow.. I have a working jflow setup with basic ipv4 and ingress collection on a m7i with a services pic and also on a MX platform with the MS-DPC blade. #1 - Is egress netflow supported? It appears that only ingress is supported. #2 - Why do all examples that I can find say to use a firewall filter to sample traffic, I have successfully used the 'set interface xx-x/x/x unit xx family inet sample' command. This appears to be the new way of doing it. #3 - In my lab I have a MPLS VPN setup and am trying to netflow interfaces within the VRF. As it appears the device can only do ingress netflow I also need to sample the mpls interface. Does anyone have an example of how to gather netflow stats from both the vrf and mpls pe p interfaces? Thanks Chris ___ 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] Netflow / JFlow questions
You can configure a single template to export either IPv4 or MPLS flow data with. However, when you actually configure sampling to send packets to the service-pic (or ms-dpc), you can not simultaneously sample and send both mpls and ipv4 packets to the pic/dpc. So its either or. Either you are sampling on the CE/VRF side (IPv4) or the core side (MPLS). From: Chris Evans chrisccnpsp...@gmail.com To: Derick Winkworth dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net Sent: Wed, September 1, 2010 8:48:53 AM Subject: Re: [j-nsp] Netflow / JFlow questions Hrm.. That documentation is very wishy/washy, like usual. ARGH so frustrating to always deal with Juniper vague documentation.. If I can configure both templates, then what does it exactly mean that I cannot sample at the same time? It it documented anywhere that the M cannot do what I'm asking?? I'm guessing the answer is no? On Tue, Aug 31, 2010 at 10:33 PM, Derick Winkworth dwinkwo...@att.net wrote: Its not possible on an M... Its one or the other, IPv4 or MPLS... http://www.juniper.net/techpubs/software/junos/junos94/swconfig-policy/configuring-active-flow-monitoring-using-version-9.html You can define a version 9 flow record template suitable for IPv4 traffic, MPLS traffic, or a combination of the two. However, you can sample packets from only one type of family (inet or mpls) at the same time. From: Chris Evans chrisccnpsp...@gmail.com To: juniper-nsp@puck.nether.net Sent: Tue, August 31, 2010 8:01:44 PM Subject: [j-nsp] Netflow / JFlow questions Have a few questions for some folks who have implemented JFlow.. I have a working jflow setup with basic ipv4 and ingress collection on a m7i with a services pic and also on a MX platform with the MS-DPC blade. #1 - Is egress netflow supported? It appears that only ingress is supported. #2 - Why do all examples that I can find say to use a firewall filter to sample traffic, I have successfully used the 'set interface xx-x/x/x unit xx family inet sample' command. This appears to be the new way of doing it. #3 - In my lab I have a MPLS VPN setup and am trying to netflow interfaces within the VRF. As it appears the device can only do ingress netflow I also need to sample the mpls interface. Does anyone have an example of how to gather netflow stats from both the vrf and mpls pe p interfaces? Thanks Chris ___ 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] 10.3 on MX960 with MPC only?
### I'm not even going to mention that IGMP-Snooping isn't support on trunk interfaces which blows my mind. wow! ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.3 on MX960 with MPC only?
Is this in documentation somewhere? I just did a quick pass through the IGMP snooping docs and I did not see it stated anywhere in there... maybe I missed it. From: Derick Winkworth dwinkwo...@att.net To: Chris Evans chrisccnpsp...@gmail.com; Gavin Tweedie g...@narx.net Cc: juniper-nsp@puck.nether.net Sent: Tue, August 31, 2010 7:13:37 AM Subject: Re: [j-nsp] 10.3 on MX960 with MPC only? ### I'm not even going to mention that IGMP-Snooping isn't support on trunk interfaces which blows my mind. wow! ___ 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] 10.3 on MX960 with MPC only?
Its not supported is the wrong phrase. Its broken is more appropriate. Whatever design choices that were made in the past that led to this, as you said, mind-blowing caveat, Juniper needs to go backwards and fix it. On Tue Aug 31st, 2010 8:01 AM CDT Chris Evans wrote: Try configuring an irb, igmp, igmp-snooping and a trunk port on 10.x code. It will tell you its not supported. It's never been supported per JTAC. Also as per jtacs comment they put that statement in newer code as they didn't know it wasnt supported before. I asked jtac to update the documentation. Is this in documentation somewhere? I just did a quick pass through the IGMP snooping docs and I did not see it stated anywhere in there... maybe I missed it. From: Derick Winkworth dwinkwo...@att.net To: Chris Evans chrisccnpsp...@gmail.com; Gavin Tweedie g...@narx.net Cc: juniper-nsp@puck.nether.net Sent: Tue, August 31, 2010 7:13:37 AM Subject: Re: [j-nsp] 10.3 on MX960 with MPC only? ### I'm not even going to mention that IGMP-Snooping isn't support on trunk interfaces which blows my mind. wow! ___ 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] 10.3 on MX960 with MPC only?
You know, just as this thread popped up on this list, we were dealing with a multicast related issue... On an MX if you statically map a unicast IP address to a multicast mac address, you have to specify a single l2 interface to forward that traffic out of. It essentially defeats the whole purpose of creating the mapping in the first place. So I thought, what if we connect to ports on the same box together? This worked. Essentially you create a logical interface on one end of the cable and you move your layer 3 config to it for that particular VLAN, then the other end of the cable is just a trunk port. This might resolve your issue. From: Chris Evans chrisccnpsp...@gmail.com To: Derick Winkworth dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net Sent: Tue, August 31, 2010 11:45:58 AM Subject: Re: [j-nsp] 10.3 on MX960 with MPC only? Agreed if they offering the mx as an Ethernet switch this should be supported. Nag your account team. I had them put in an enhancement request but who knows if they are listening. Its not supported is the wrong phrase. Its broken is more appropriate. Whatever design choices that were made in the past that led to this, as you said, mind-blowing caveat, Juniper needs to go backwards and fix it. On Tue Aug 31st, 2010 8:01 AM CDT Chris Evans wrote: Try configuring an irb, igmp, igmp-snooping and a trunk port on 10.x code. It will tell you its not supported. It's never been supported per JTAC. Also as per jtacs comment they put that statement in newer code as they didn't know it wasnt supported before. I asked jtac to update the documentation. Is this in documentation somewhere? I just did a quick pass through the IGMP snooping docs and I did not see it stated anywhere in there... maybe I missed it. From: Derick Winkworth dwinkwo...@att.net To: Chris Evans chrisccnpsp...@gmail.com; Gavin Tweedie g...@narx.net Cc: juniper-nsp@puck.nether.net Sent: Tue, August 31, 2010 7:13:37 AM Subject: Re: [j-nsp] 10.3 on MX960 with MPC only? ### I'm not even going to mention that IGMP-Snooping isn't support on trunk interfaces which blows my mind. wow! ___ 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] New 16port 10G Card and new MPC with 4x10G MIC Cards - coexistance of old DPCs and new Cards in same chassis -- looking for experience feedback
Has this always been the case with the SCBs? Will there not be newer SCBs that can run faster? I've always heard that the MX series could potentially run 240gbps per slot but would require SCB upgrade and newer line cards... We're not there yet, but I'm wondering if its true. it sounds like below that we are talking about existing SCBs which means the MX is limited to 120G per slot. From: Richard A Steenbergen r...@e-gerbil.net To: Pavel Lunin plu...@senetsy.ru Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Sun, August 29, 2010 1:39:18 AM Subject: Re: [j-nsp] New 16port 10G Card and new MPC with 4x10G MIC Cards - coexistance of old DPCs and new Cards in same chassis -- looking for experience feedback On Sun, Aug 29, 2010 at 02:29:29AM +0400, Pavel Lunin wrote: My hypotheses is MQ can actually do twice as much: 65 Mpps from the interfaces to back-plane and 65 backwards. Otherwise you'll never get 30 Gbps FD with MPC1. But this knowledge is too burdensome for sales people, because if you don't know it, you can just multiply 65 by the number of chips in a box and get the right pps number. One could hardly understand that each MQ actually does twice as much work but each packet passes two MQ and you need multiply and than divide by 2 accordingly. I got some replies off-list which helped shed some light on the Trio capabilities, so with their permission I will summarize the major points for the archives: * Each Trio PFE is composed of the following ASICs: - MQ: Handles the packet memory, talks to the chassis fabric and the WAN ports, handles port-based QoS, punts first part of the packet to the LU chip for routing lookups. - LU: Lookup ASIC which does all IP routing lookups, MAC lookups, label switching, firewall matching, policing, accounting, etc. - QX: (optional) Implements the fine grained queueing/HQoS stuff. NOT included on the 16-port 10GE MPC. - IX: (optional) Sits in front of the MQ chip to handle GigE ports. * The Trio PFE is good for around 55Mpps of lookups, give or take, depending on the exact operations being performed. * The MQ chip can do around 70Gbps, give or take depending on the packet size. Certain packet sizes can make it all the way to 80Gbps, inconvenient packet sizes can bring it down below 70G by the time you figure in overhead, but the jist is around 70Gbps. This limit is set by the bandwidth of the packet memory. The quoted literature capacity of 60Gbps is intended to be a safe number that can always be met. * The 70G of MQ memory bandwidth is shared between the fabric facing and WAN facing ports, giving you a bidirectional max of 35Gbps each if you run 100% fabric-wan traffic. If you do locally switched wan- wan traffic, you can get the full 70Gbps. On a fabricless chassis like the MX80, that is how you get the entire amount. * The MX960 can only provide around 10Gbps per SCB to each PFE, so it needs to run all 3 SCBs actively to get to 30Gbps. If you lose an SCB, it drops to 20Gbps, etc. This is pre cell overhead, so the actual bandwidth is less (for example, around 28Gbps for 1500 byte packets). * The MX240 and MX480 provide 20Gbps of bandwidth per SCB to each PFE, and will run both actively to get to around 40Gbps (minus the above overhead). Of course the aforementioned 35Gbps memory limit still applies, so even though you have 40Gbps of fabric on these chassis you'll still top out at 35Gbps if you do all fabric-wan traffic. * Anything that is locally switched counts against the LU capacity and the MQ capacity, but not the fabric capacity. As long as you don't exhaust the MQ/fabric, you can get line rate out of the WAN interfaces. For example, 30Gbps of fabric switched + 10Gbps of locally switched traffic on a MX240 or MX480 will not exceed the MQ or fabric capacity and will give you bidirectional line rate. * I'm still hearing mixed information about egress filters affecting local switching, but the latest and most authorative answer is that it DOESN'T actually affect local switching. Everything that can be locally switched supposedly is, including tunnel encapsulation, so if you receive a packet, tunnel it, and send it back out locally, you get 100% free tunneling with no impact to your other capacity. I think that was everything. And if they aren't planning to add it already, please join me in asking them to add a way to view fabric utilization, as it would really make managing the local vs fabric capacities a lot easier. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___
Re: [j-nsp] New 16port 10G Card and new MPC with 4x10G MIC Cards - coexistance of old DPCs and new Cards in same chassis -- looking for experience feedback
so the possibility does exist that with a combination of newer fabric and newer line card (a line card with better MQ memory bandwidth), that MX might be able to push more traffic per slot... From: Richard A Steenbergen r...@e-gerbil.net To: Derick Winkworth dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Sun, August 29, 2010 1:34:00 PM Subject: Re: [j-nsp] New 16port 10G Card and new MPC with 4x10G MIC Cards - coexistance of old DPCs and new Cards in same chassis -- looking for experience feedback On Sun, Aug 29, 2010 at 07:03:59AM -0700, Derick Winkworth wrote: Has this always been the case with the SCBs? Will there not be newer SCBs that can run faster? I've always heard that the MX series could potentially run 240gbps per slot but would require SCB upgrade and newer line cards... We're not there yet, but I'm wondering if its true. it sounds like below that we are talking about existing SCBs which means the MX is limited to 120G per slot. Until now each PFE has only needed 10G total bandwidth (per I-chip, * 4 per DPC), so the fabric has been more than sufficient while still providing N+1. My understanding is that even with a new fabric card you'll still be limited to the 35G from the MQ memory bandwidth limit (just like you are with MX240/MX480), so the only difference will be a) you'll get fabric redundancy back, and b) you'll get support for future cards (like 100GE, etc). Another thing I forgot to mention is that the old ADPC I-chip cards can still only talk to the same number of SCB's that they did originally (2x on MX960, 1x on MX240/480). This means that when you're running mixed I-chip and Trio cards in the same chassis, in say for example an MX960, all traffic going to/from an I-chip card will stay on 2 out of 3 SCBs, and only the Trio-to-Trio traffic will be able to use the 3rd SCB. If all of your traffic is going between a Trio card and other I-chip cards, this will obviously bottleneck your Trio capacity at 20G per PFE (minus overhead). Supposedly there is an intelligent fabric request/grant system, so hopefully the Trio PFEs are smart enough to use more capacity on the 3rd SCB for trio-to-trio traffic is the first 2 are being loaded up with I-chip card traffic. You can also use the hidden command show chassis fabric statistics to monitor fabric utilization and drops. The output is pretty difficult to parse, you have to look at it per-plane, and it isn't in XML so you can't even easily write an op script for it, but it's still better than nothing. Hopefully Juniper will add a better fabric utilization command, ideally with something that tracks the peak rate ever seen too (like Cisco does), for example: cisco6509#show platform hardware capacity fabric Switch Fabric Resources Bus utilization: current: 13%, peak was 54% at 08:47:31 UTC Fri Jun 25 2010 Fabric utilization: IngressEgress Module Chanl Speed rate peak rate peak 1 020G1%6% @21:14 06Apr101% 10% @20:14 13Feb10 2 020G 10% 33% @21:15 21Mar100% 31% @20:10 24May10 2 120G2% 52% @03:48 30Apr10 14% 98% @10:20 09Jun10 3 020G 19% 40% @20:38 21Mar10 14% 25% @01:02 09Jul10 3 120G4% 37% @10:42 09Jan101% 61% @02:52 20Dec09 4 020G 27% 51% @20:30 14Jul101%9% @17:04 03May10 4 120G2% 60% @12:12 13May10 34% 82% @01:33 29Apr10 5 020G0%5% @18:51 14Feb100% 21% @18:51 14Feb10 6 020G2% 17% @03:07 29Jun10 19% 52% @17:50 14Jul10 6 120G0% 42% @10:22 20Apr100% 73% @02:25 28Mar10 7 020G6% 33% @10:20 09Jun10 26% 58% @02:25 19Aug10 7 120G 35% 51% @19:38 14Jul101%6% @16:55 03May10 Or at least expose and XML-ify the current one so we can script up something decent. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Provisioning and managing TE and L2/L3 vpns
A lot of shops use custom tools. EMC makes a multi-vendor MPLS management tool. http://www.emc.com/products/detail/software/mpls-manager.htm From: Ethan Whitt ethan.l.wh...@gmail.com To: juniper-nsp@puck.nether.net Sent: Wed, August 11, 2010 2:00:07 AM Subject: [j-nsp] Provisioning and managing TE and L2/L3 vpns We operate a dual vendor network and am looking for recommendations on provisioning and managing TE, layer 2 vpns, and layer 3 vpns for Juniper routers. Today we use Cisco IP solution center for these functions on our Cisco routers. We have had mixed experiences with IP solution center, so we would consider a dual vendor tool. Any lessons learned from real world experiences on either topic would be appreciated. thanks. ~elw ___ 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] Managing MX480 fxp0
We put a router in place to do NAT for the local subnet of the fxp. Alternately, you can just put static routes in for specific management subnets pointing out the fxp port... From: Serge Vautour sergevaut...@yahoo.ca To: Chen Jiang iloveb...@gmail.com; Jim Devane jdev...@switchnap.com Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, July 8, 2010 10:26:24 AM Subject: Re: [j-nsp] Managing MX480 fxp0 Putting fxp0 in a LS works from a routing perspective but it breaks NSR GRES - at least it does in 10.0R2. I have a JTAC case pending. Serge - Original Message From: Chen Jiang iloveb...@gmail.com To: Jim Devane jdev...@switchnap.com Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, July 8, 2010 4:54:15 AM Subject: Re: [j-nsp] Managing MX480 fxp0 You cannot put fxp0 into VRF but could put it into a logical system. And logical system also have a seperate routing table other than inet.0. On Thu, Jul 8, 2010 at 3:16 AM, Jim Devane jdev...@switchnap.com wrote: Hello, I need some ideas/help on a scenario I am sure comes up a lot but having problems with. I have an MX480. I want to be able to manage this MX from an internal (1918) network through the fxp0 port. The internal network is not flat but routed and there are several subnets which may contact the MX for management/polling. I was thinking/hoping to set up a VRF for this port and set routes/default route for the VRF to connect. It turns out I am not able to put fxp0 into a routing-instance. (errors on config checkout) So I put everything production in to a logical system leaving the fxp in the master instance and installing a default route for the master instance. This works, but now the MS-DPC will not export flows if it is in a logical system. So the logical system is out b/c the MS-DPC has to be in the master instance. But I can't but the fxp0 into a logical/routing instance. What is the BCP/recommended method for managing this box if fxp0 is not a public routed interface? Unfortunately, I don't have another port to place into a VRF besides the fxp0 (all other ports are 10G) Thanks for any help/ideas! Jim ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- BR! James Chen ___ 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] JUNOS and MX Trio cards
# 6 years by my count. The weird thing is I'm constantly running into plenty of really smart competent people at Juniper who do want to help, they just have no idea that things are really this broken, or they aren't empowered to do anything about it. I guess you could call that they don't care at a corporate level. ## Yeah, let me just say I work with a number of supremely competent people at Juniper who care immensely about the customer and the product. I can't emphasize that enough. I think Juniper does care, actually, I think that there is paradigm shift that is happening there with respect to how code is produced. I understand things will get much, much better in 10.3 thru 10.5. In the meantime, 10.0r3 / r4 will likely be our production code releases. Knock on wood, these will do at the moment... The folks we are working with at Juniper are putting some effort into making sure these are solid releases for us. ## Does anyone in systest actually do anything any more? ## I have actually heard there is some frustration there. See comment above about paradigm-shift. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS and MX Trio cards
hahahaha nice! From: Andrey Zarechansky zor...@fr.kiev.ua To: juniper-nsp@puck.nether.net Sent: Wed, June 30, 2010 3:26:50 AM Subject: Re: [j-nsp] JUNOS and MX Trio cards On Tue, Jun 29, 2010 at 06:50:49PM -0700, Derick Winkworth wrote: [dd] How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco could care less about code quality. surely some networking vendor must give a sh*t. Small brief from our ALU equipment evaluation: BGP:4-byte ASN unsupported, BGP:PE-CE protocol unsupported, IOM2 can forward traffic for detached neighbour for 30 min Do you still wonder they can do better? -- ZA-RIPE||ZA1-UANIC ___ 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 and MX Trio cards
When you say 'transit session' what do you mean exactly? Also disappointed to hear about the bugs. Is the stuck-in-pending issue easily reproducible? I have read some of your past posts, but recently it sounds like this can be reproduced without a lot of effort? From: Richard A Steenbergen r...@e-gerbil.net To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tue, June 29, 2010 3:05:55 AM Subject: [j-nsp] JUNOS and MX Trio cards For all those who were wondering about code stability for Trio cards, I have my first experience to report. We just got our first shipment of MPC2 cards, and tested it out in an MX960 running 10.2R1 with MPC2 cards only, no classic DPCs. When I went to commit the config of the very first routed port with a firewall filter (IMHO a fairly simple config, about a dozen terms, but making use of chained filters), the FPC the port was on promptly crashed. Every time the FPC would reboot and come back up, it would immediately crash again. Moving the interface config with the filter to a different FPC caused that FPC to crash as well. Disabling the firewall filter caused the crashing to stop. But, the box didn't fully recover on its own. Following the crash, some packets forwarded through that box were being blackholed. After doing a GRES/NSR switchover, the blackholing cleared briefly, but started again the exact instant the backup RE came back online. I tried disabling the GRES/NSR config, but the blackholing still didn't go away. A complete PFE restart was required to clear the blackholing. Oh and BTW, the pending route BGP stall bug is worse than ever in 10.2. On a MX960 with RE-S-2000 and a BGP config consisting of nothing more than an IBGP mesh (28 sessions) and a SINGLE TRANSIT SESSION, it took just over 12 minutes before a single route from the transit session was successfully installed to hardware. So far things aren't looking good. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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 and MX Trio cards
So basically, this stalled route issue has been going on for so long, that its truthful to say that Juniper probably doesn't think its important to fix? or they don't care? I wonder what their official line is. Might be similar to their official line with respect to the manufacturing issue with the EX series, where so many ASICs are just bad... I think they have some code in JUNOS now that detects the bad ASICs and just resets them when the failure detected. How unfortunate. I wonder of Alca-Lu can do better. Lord knows Cisco could care less about code quality. surely some networking vendor must give a sh*t. From: Richard A Steenbergen r...@e-gerbil.net To: Derick Winkworth dwinkwo...@att.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tue, June 29, 2010 2:59:55 PM Subject: Re: [j-nsp] JUNOS and MX Trio cards On Tue, Jun 29, 2010 at 08:37:20AM -0700, Derick Winkworth wrote: When you say 'transit session' what do you mean exactly?? Also disappointed to hear about the bugs.? Transit (n): An EBGP session where an external ASN sends you a full copy of the global routing table, usually in exchange for money. :) Is the stuck-in-pending issue easily reproducible?? I have read some of your past? posts, but recently it sounds like this can be reproduced without a lot of effort? Trivially reproducable here, all that seems to be required is a decent number of BGP sessions that you have to send the update to. Just last night I noticed it took over 6 minutes to remove the routes and stop forwarding traffic to a ebgp session I shut down on a 9.6R4 router (which was mostly cpu idle before starting), and EX8200s running 10.1 have taken 5-7 minutes to start installing or exchanging routes with nothing more than 2 IBGP RR feeds and a local transit session. Usually the problem is worst after a fresh reboot, where it can take 10-20 minutes to actually install the routing table into hw, but on newer code it seems to be happening on an otherwise stable router with just a single BGP session flap. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling, etc...
after the classification portion of the filter but before the default-accept.
I would use a rewrite rule to modify DSCP on egress, so that its consistent
across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Setting forwarding-class in firewall filter, non-match behaviour
i wonder what the real world performance implications are on an ASIC forwarding
platform... We really haven't seen any issues with the way we are doing it.
I think I prefer the flexibility for later
From: Richmond, Jeff jeff.richm...@frontiercorp.com
To: Addy Mathur addy.mat...@gmail.com
Cc: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net
juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 11:18:40 AM
Subject: Re: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
I agree. One thing that we do fairly often is create a multifield classifier
like this to just accept a couple of values to place into the appropriate
forwarding-class, then for a default action reset to BE forwarding-class for
all non-matching traffic. This works well in situations where you may not want
to use a BA classifier as you don't trust the markings or you want them
rewritten on egress.
Regards,
-Jeff
On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:
I personally think Dale's firewall configuration is better. The
config allows for a packet to exit fw filter evaluation once a match
condition is met, by being subjected to a single action. Derick's FW
filter forces a packet to traverse all terms regardless of a match,
and is subjected to at least two actions via two different terms
(fwd-class + next-term AND accept). And there's no real need for the
latter.
Regards,
Addy.
On 6/20/10, Derick Winkworth dwinkwo...@att.net wrote:
This is probably better:
term BEST-EFFORT
thenforwarding-class best-effort
next-term
term DSCP-EF
fromdscp ef
thenforwarding-class expedited-forwarding
next-term
term default-accept
thenaccept
You can insert additional terms later to modify loss-priority, sampling,
etc... after the classification portion of the filter but before the
default-accept. I would use a rewrite rule to modify DSCP on egress, so
that its consistent across platforms.
From: Dale Shaw dale.shaw+j-...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Sun, June 20, 2010 3:59:12 AM
Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
behaviour
Hi all,
Re: setting the forwarding-class of a packet through a firewall filter.
Many (almost all) of the examples I've looked at do not include a
catch-all term to handle packets not matched by any explicitly-defined
terms. At the risk of exposing myself as a J-noob...
Is it safe to assume that, if the desired result is that packets NOT
matched by explicitly-defined terms are permitted, a catch-all term
must be configured with an 'accept' (or some other non-terminating)
action?
Using this input filter example:
(stolen from
http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
firewall {
filter filter1 {
term 1 {
from {
dscp 2;
}
then {
dscp 0;
forwarding-class best-effort;
}
}
term 2 {
from {
dscp 3;
}
then {
forwarding-class best-effort;
}
}
}
}
I read this as:
- if the packet is marked DSCP 2, set DSCP to 0 and place in
'best-effort' forwarding class and accept the packet.
- if the packet is marked DSCP 3, place in 'best-effort' forwarding
class and accept the packet.
- discard all other packets
Am I missing something?
I think what I really want, to avoid dropping traffic, is something like:
firewall {
filter FILTER1 {
term TERM1 {
from {
dscp ef;
}
then forwarding-class expedited-forwarding;
}
term DEFAULT {
then forwarding-class best-effort;
accept;
}
}
}
...then rewrite DSCP bits on egress based on the forwarding-class, or
do it all within the firewall filter (depending on platform).
(I know I don't strictly need the 'accept;' command in the DEFAULT
term, but for the sake of clarity, I think it's a good option)
Cheers,
Dale
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
--
Sent from my mobile device
___
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] clear-dont-fragment bit in firewall filter...
It would be awesome if we could clear the DF bit in a FW filter... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ?
Cisco does support this on the Nexus and in the next rls of XE. From: Peter Krupl peter.kr...@siminn.dk To: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Fri, June 4, 2010 12:41:16 AM Subject: RE: [j-nsp] GRE Bridging, is it possible with a Juniper box ? Hi Group, Well I have a slight confession to make. When I initially asked the question, it was based on the assumption that Cisco provided this. But they don't. I had played with bridging over frame relay way back, and somehow this became GRE in my mind. Sorry about the mistake. So now im looking into L2TP as an alternative. But the One-Access 1221 1424 are supporting ethernet over GRE. Kind Regards, Peter Krupl -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth Sent: Friday, June 04, 2010 4:58 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ? This sounds like what Cisco is doing with OTV. They are using ethernet over GRE w/multicast to transport ethernet... It is being marketed as a better alternative to VPLS. From: Pekka Savola pek...@netcore.fi To: Patrik Olsson d...@webkom.se Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, June 3, 2010 4:59:26 AM Subject: Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ? On Thu, 3 Jun 2010, Patrik Olsson wrote: Have you tried looking for L2TP with PPP over BCP intestead PPP over IPCP? If you want to encapsulate the whole ethernetframe and send over a GRE tunnel so you get a bridged enviroment, is it called Ethernet over IP (EOIP). Dont remeber the rfc, but is not supported by Juniper. Only supported by a small Latvian vendor I think... I wonder if you refer to rfc3378. I recall support for it was recently added in Linux as well. But I don't see why encapsulaitng whole ethernet frames in GRE could not work if vendors just chose to support it. Then as 'ether type' in GRE header you could put 0x6558 or 0x8100 (IEEE 802.1q VLAN-tagged frames *). The former is also supported in Linux [http://lwn.net/Articles/303062/] *) http://www.iana.org/assignments/ethernet-numbers -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ 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] GRE Bridging, is it possible with a Juniper box ?
This sounds like what Cisco is doing with OTV. They are using ethernet over GRE w/multicast to transport ethernet... It is being marketed as a better alternative to VPLS. From: Pekka Savola pek...@netcore.fi To: Patrik Olsson d...@webkom.se Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, June 3, 2010 4:59:26 AM Subject: Re: [j-nsp] GRE Bridging, is it possible with a Juniper box ? On Thu, 3 Jun 2010, Patrik Olsson wrote: Have you tried looking for L2TP with PPP over BCP intestead PPP over IPCP? If you want to encapsulate the whole ethernetframe and send over a GRE tunnel so you get a bridged enviroment, is it called Ethernet over IP (EOIP). Dont remeber the rfc, but is not supported by Juniper. Only supported by a small Latvian vendor I think... I wonder if you refer to rfc3378. I recall support for it was recently added in Linux as well. But I don't see why encapsulaitng whole ethernet frames in GRE could not work if vendors just chose to support it. Then as 'ether type' in GRE header you could put 0x6558 or 0x8100 (IEEE 802.1q VLAN-tagged frames *). The former is also supported in Linux [http://lwn.net/Articles/303062/] *) http://www.iana.org/assignments/ethernet-numbers -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 questions
The bug situation is getting better though, I think... We have EX-4200s in our environment and aside from an earlier aggregated-ethernet bug and a hardware issue, they have been rock-solid. In our environment they are L2 Q-in-Q only, no routing. We have MPLS licenses for the units in our lab and we have labbed RSVP and OSPF on these units (as 'P' nodes) and we didn't have any issues. As stated, every release has new features. The upside is that the platform is maturing, the downside is bugs. But like I said, I think Juniper is getting a handle on that... From: Chris Evans chrisccnpsp...@gmail.com To: Bernhard Schmidt be...@birkenwald.de Cc: juniper-nsp@puck.nether.net Sent: Fri, May 14, 2010 6:58:17 AM Subject: Re: [j-nsp] EX4200 questions It sounds like the EX4200 would be a fit for you if you're only doing l2, as you mentioned it doesn't have a big FIB for a large amount of routes.. You said that 16k routes would suffice for you, so perhaps you are doing L3 but you're not importing full route feeds in this network area. I somehow remember only testing to 14K and it started to complain about the FIB being full.. I would double check that capacity limit, I think it changed on versions of code. My company is a huge Cisco shop and we've been trying out the EX4200s in pockets. They seem to work well when you don't require a feature or run into a bug. The EX's are feature-poor compared to a 6500. Code wise, the later the better, which is different than the other JUNOS platforms. Juniper is adding much needed switching features to later releases, expect bugs though. I personally think the bug issue has flipped sides.. Cisco's code seems very stable to me compared to JUNOS, we've found glaringly huge bugs in JUNOS lately. We're running 10.x on our EX's and 9.6 on our MX/M series. As for SPT, you could use VSTP (and use Rapid-PVST on Cisco side) or MSTP. MSTP inter operates correctly, VSTP does 99%. VSTP works fully except for VLAN1. Cisco listens to the IEEE 802.1D MAC-Address for this VLAN, but VSTP on JUNOS only sends to the Cisco proprietary MAC so its messages get ignored. I hope you aren't using VLAN 1 and are pruning it from your trunks. If you do this you will be okay.. VSTP operates exactly like Rapid-PVSTs in that there is a tree built for every VLAN. JUNOS also uses the newer IEEE format of spanning-tree pathcosts, so on the Cisco box you should do 'spanning-tree pathcost method long' as it defaults to the older 'short' method. 32bit value vs 16bit. All in all I'm sure it would work sufficiently for you. The EX4200-24F has a nice price point and performance value. On Fri, May 14, 2010 at 7:32 AM, Bernhard Schmidt be...@birkenwald.dewrote: Hi, we are a small ISP with a Cisco-only core at the moment, consisting of two 6500 series and a couple of Cat2960G aggregation switches. We are looking into deploying to a small IX in the area, which is at the same location as two of our upstreams. So we are going to throw a second fiber to the location and put up a small device that can switch GE linerate for the upstreams and route a couple of 100M to/from the IX into the backbone. We have been considering the Cisco ME6524 series but are now looking at the EX4200-24F as well. Since I don't have much experience with Juniper in general (and with recent devices like the EX especially) I have a few questions I could not find answered in the datasheets. - How is the interoperatibility with Cisco PVSTP+ on L2? I found http://www.juniper.net/us/en/local/pdf/implementation-guides/8010002-en.pdf which briefly mentions VSTP as being basically the same (and thus fully compatible), but then talks in length about how to get standard STP or MSTP interoperating with Cisco. Does VSTP just work as it does in Cisco, plug the device in as you want to and every VLAN gets its own tree? - Datasheet says 16k IPv4 routes and 4k IPv6 routes, I assume this is shared space and an IPv6 route just takes four times the resources of an IPv4 route? - Apart from the small FIB, is there any reason why the EX would not be suitable for this application? Basically we run a fully-dualstacked network, OSPFv2/OSPFv3, BGP, some MPLS/L3VPN (but probably not at this location for the time being). I expect at most 30-40 BGP peers with total prefix count safely within the limits of the hardware. Thanks for your answers, Bernhard ___ 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] Junoscriptorium patches?
Speaking of this, I wrote an XSLT library for binary functions, and then an IP library on top of that uses the binary library to do fun stuff like adding a decimal number to an IP address... to help automate provisioning. Anyone interested in this? How could I contribute to junoscriptorium? From: Tima Maryin t...@transtelecom.net To: Cougar cou...@random.ee Cc: juniper-nsp@puck.nether.net Sent: Wed, May 12, 2010 2:01:32 AM Subject: Re: [j-nsp] Junoscriptorium patches? Bah!... :-/ Thanks! Cougar wrote: What is your JUNOS version? Are you sure you didn't mess up when you copied this script from webpage to file? The best way to copy it is to select view source tab and then copy from there. md5sum dom.slax 372140186b2b865902565ac466fab566 dom.slax ___ 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] MX240
The MX80 is relatively inexpensive and has excellent port density. With such a simple config, I'm not even that worried about it being deployed with the JUNOS it requires. You really have three choices I think at release time: 10.1R1, 10.1R2, and 10.2R1. But man, a 48-port copper 10/100/1000 box with 4 built-in 10G ports. Thats nice. If the numbering for the model follows past convention, then this box is an 80G box right? So this box is significantly oversubscribed.. but its 80gbps. Plus it has dual power supplies built in. It kind of makes you wonder what the point of the MX240 is. I guess with the new 3D cards you can get more capacity out of the 240, but why not just buy more MX80s? Its only 10k for the RQ license on the MX80 (I think, I heard... but verify that). The RQ cards on the 240/480/960 are still very expensive. I see many MX80s in our future, personally. Derick From: Mark Tinka mti...@globaltransit.net To: Keith kwo...@citytel.net Cc: juniper-nsp@puck.nether.net Sent: Wed, May 12, 2010 3:28:54 AM Subject: Re: [j-nsp] MX240 On Wednesday 12 May 2010 03:58:40 am Keith wrote: Yea, but would you like two ASR1002s over one MX240? :) Depends on the situation. If I need only one edge router, the MX240 will be better. If I'm peering and I need no more than a couple of Gbps per router from multiple partners in a PoP, I can spread my risk across two routers. That helps me sleep at night :-). It really all depends on the application. MX80 is a suggestion. Be interesting to see what the sales guys can do for us on price for two MX80 instead of one 240. Let us know how that goes. Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] 10.0R3 VSTP on EXs...
Anyone find that making a physical loop with two or more EXs automatically results in a forwarding loop when you use VSTP? We are seeing this right now... I wonder if it affects the MX too. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper IPSEC VPN
Can you share a sanitized config? From: Nick Ryce nick.r...@lumison.net To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Fri, April 30, 2010 4:08:21 AM Subject: [j-nsp] Juniper IPSEC VPN Is there a default speed that a juniper ipec tunnel runs at? We have an asa5510 and an 1812 where the ipsec tunnel was running near full speed on a 10 meg link. We swapped the 1812 with a 2320 running 9.6R2.8 and we are seeing lost packets and slow throughput. The tunnel does not drop once established but packets continue to be lost. Any ideas? Nick -- Nick Ryce Network Engineer Lumison 0845119 P.S. do you love Lumison? Why not take a moment and vote for us? http://bit.ly/Vote_Lumison -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ 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] What's the latest code you're running on a mx?
Ahh, so 10.1 is needed then for the MX80 I'm guessing... We'll be testing those soon in a POC where they will run VPLS, RSVP, COS, BGP, and L3VPNs... From: Richard A Steenbergen r...@e-gerbil.net To: Bj?rn Tore b...@paulen.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Fri, April 30, 2010 3:01:38 PM Subject: Re: [j-nsp] What's the latest code you're running on a mx? On Fri, Apr 30, 2010 at 09:55:23AM +0200, Bj?rn Tore wrote: We're running 10.0R2.10 on MX. Works quite well. We just tested 10.0R3 on MX and it was a giant hot steaming mess. Among other problems, they broke | last in cli, isis overload timeout no longer functions (would never time out, stayed overloaded forever), and there was some as yet undetermined issue with RSVP/call admission where LSPs could not transit through the 10.0R3 device even though there was plenty of bandwidth available and no policy preventing it. We ended up downgrading back to 9.6S5 (which instantly solved all of the above), where the biggest problem we've had so far is a chassisd bug which causes this false warning every time you commit: chassisd[1305]: %DAEMON-3-UI_CONFIGURATION_ERROR: Process: chassisd, path: [edit groups BASE-FORWARDING forwarding-options hash-key family], statement: inet6, Could not retrieve the route-accounting setting Which would just be annoying/log filling, if not for the fact that netconf interprets it as a hard error and rolls back the remotely triggered commit. Considering you need 10.1 to run the new MX Trio cards, and 10.2 to make them interoperate with older DPCs in the same chassis, I expect a lot of people are going to be very unhappy very soon when they're forced to upgrade. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 vs. C4948
Don't forget dual power supply in the box. Thats nice. 10.0r3 is coming and we will be moving all of our EXs to it when it arrives. As far as egress policing, it isn't there today. However, you could configure a port-level or queue-level shaping-rate. You could then change the default transmit-rate (or buffer-size) parameter for the best effort queue to 0 percent. This would effectively accomplish the same thing as policing, I think. Unless you are marking traffic egress based on egress utilization, then I don't think there is a way to accomplish that. From: Pavel Gulchouck g...@gul.kiev.ua To: Bill Blackford bblackf...@nwresd.k12.or.us Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Tue, February 23, 2010 1:38:42 PM Subject: Re: [j-nsp] EX4200 vs. C4948 From my point, EX4200 now has almost all features of cat3750G/cat3750E importance for NSP: ingress policing, stp (incl. pvstp and rapid-stp), lacp, qinq, bpdu tunneling (in 10.x); L3 features: ospf, vrf, limited bgp (with license)... But in addition to this EX4200 has: - working firewall counters; - junoscripts (incl. event scripts); - vlan translation (in 10.x, not tested by me); - pseudowires (not tested by me); - ipv6 (not sure, not tested by me). And as for me JunOS is better then IOS (commit, rollback, commit confirmed etc.). On Tue, Feb 23, 2010 at 08:37:15AM -0800, Bill Blackford writes: There is an interesting thread on the C list right now discussing the benefits of a l3 switch platform (OP started asking about 3550). I am budgeting to replace some 3560G and 3750G customer aggregation devices (OSPF, BGP) with devices that will scale better, have redundant power, can do service policies both input and output and yes it would be nice if it can handle V6 in hardware (last point not an issue yet as V4 is all I support at this time). I am not budgeted for nor do I have environment that requires MX series or a cat6.5/7.6k in this role. It's gonna have to be fixed switches. Does the EX4200 support firewall policer that can be applied both input and output? (equiv to C service policy). My tests on a EX3200 9.5R2.7 seem to indicate that I cannot use a policer on egress. I have no 4200's to test this with. It would be nice to see a feature comparison. Not wanting to start a holy war over vendor preference, but has a discussion comparing these two products occurred on this list? -- Pavel ___ 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] Finally...
Finally, indeed. My finally moment will arrive in 10.2R1 for the SRX. But in 9.5R4, you get tcp-mss adjust for packets passing through GRE and IPsec tunnels, and clear-dont-fragment-bit now works with CoS on M-series. I see in 10.0 there is a feature called packet-based IPSec services on M-series... anyone know what this is? I'm trying to figure that out.. From: Richard A Steenbergen r...@e-gerbil.net To: Mark Tinka mti...@globaltransit.net Cc: juniper-nsp juniper-nsp@puck.nether.net Sent: Sat, February 20, 2010 10:26:08 AM Subject: Re: [j-nsp] Finally... On Sat, Feb 20, 2010 at 10:13:27PM +0800, Mark Tinka wrote: It's out: JUNOS 9.5R4.3 Woohoo. Now if only it didn't take several hours to download all of the half-dozen images you need to get for every platform, at a whopping 250KB/s, one at a time, using lynx. The slow speeds of ftp.juniper.net wouldn't be so bad if you didn't have to use a full web browser to login and fetch each image, i.e. if you could just fire off a wget and use http or ftp authentication to download them in the background in parallel. Alas the software download features of all router vendors seem to be limited to the lowest common denominator, some guy clicking Save As in their IE6 browser on their Windows desktop. Would a sftp server you could actually do bulk gets from really be that hard? -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 Q-in-Q
This is not possible until 10.0 on the EX. From: Kevin Wormington kw...@sofnet.com To: juniper-nsp@puck.nether.net Sent: Mon, December 28, 2009 2:29:15 PM Subject: [j-nsp] EX4200 Q-in-Q Hi All, I'm fairly new to EX4200s and am running 9.6R1.13 on a three member stack. Unfortunately, I already have live traffic on this so it somewhat limits my ability to test. I would like to be able to configure a trunk port to have some vlan members that are single-tagged and some that are double-tagged (q-in-q). I was wondering if anyone has successfully done this? Thanks, Kevin ___ 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] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there is no
allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and you
should put a weight of 9 as a start.
From: Scott Berkman sc...@sberkman.net
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example interface:
ds-2/2/0:1:1:1 {
scheduler-map VOIP-MAP;
unit 0 {
classifiers {
dscp DSCP-CLASS;
}
}
}
I also tested with the following scheduler and still saw the drops:
be-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority high;
}
ef-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
___
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] RED Drops with Qos
Enable extended buffer size..
q-pic-large-buffer
also under chassis/pic configuration.
From: Scott Berkman sc...@sberkman.net
To: Derick Winkworth dwinkwo...@att.net; juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:58:45 PM
Subject: RE: [j-nsp] RED Drops with Qos
Derick,
FYI after making your suggested changes I am still seeing drops:
show configuration chassis fpc 2 pic 2
red-buffer-occupancy {
weighted-averaged {
instant-usage-weight-exponent 9;
}
}
show interfaces queue ds-2/2/0:1:5:1
Physical interface: ds-2/2/0:1:5:1, Enabled, Physical link is Up
Interface index: 165, SNMP ifIndex: 79
Description: Test-1
Forwarding classes: 4 supported, 4 in use
Egress queues: 4 supported, 4 in use
Queue: 0, Forwarding classes: be
Queued:
Packets : 290 0 pps
Bytes:375596 0 bps
Transmitted:
Packets : 268 0 pps
Bytes:346908 0 bps
Tail-dropped packets : 0 0 pps
RED-dropped packets :22 0 pps
Low, non-TCP: 0 0 pps
Low, TCP:22 0 pps
High, non-TCP : 0 0 pps
High, TCP : 0 0 pps
RED-dropped bytes: 28688 0 bps
Low, non-TCP: 0 0 bps
Low, TCP: 28688 0 bps
High, non-TCP : 0 0 bps
High, TCP : 0 0 bps
Thanks,
-Scott
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Derick Winkworth
Sent: Monday, December 21, 2009 4:41 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] RED Drops with Qos
By default, in JUNOS, there is no weighted average for RED. Queue-depth is
evaluated in an instantaneous fashion. This means, of course, that there is
no allowing for transient bursts.
Under the chassis/pic hierarchy you must enable weighted-average RED and you
should put a weight of 9 as a start.
From: Scott Berkman sc...@sberkman.net
To: juniper-nsp@puck.nether.net
Sent: Mon, December 21, 2009 3:11:40 PM
Subject: [j-nsp] RED Drops with Qos
Hi All,
I'm fairly new to Juniper, and I am trying to get our QoS
setup right on a M20 running JunOS 8.3 being used for T1 aggregation.
The PIC is an IQ-enabled ChOC12 card, and the interfaces are
channelized T1's. We seem to be classifying traffic into the 4 queues
correctly, but no matter what I change in the settings I am still seeing RED
drops on TCP/Low traffic.
Please find below the base configuration sections I am starting with. I
have tried some different percentages, and tried defining specific
drop-policies based on some suggestions in the achieves from this list, but
no matter what I still see the drops in the same place.
Are there any good best-practice guides to QoS on JunOS? I
see lots about how the different settings effect the flow, but nothing in
terms of what works well for others. Also is there anything obviously wrong
below?
Thanks in advance for any help,
-Scott
classifiers {
dscp DSCP-CLASS {
forwarding-class ef {
loss-priority low code-points 101110;
}
forwarding-class af {
loss-priority low code-points [ 011000 011010 ];
}
forwarding-class be {
loss-priority low code-points 00;
}
forwarding-class nc {
loss-priority low code-points 111000;
}
}
forwarding-classes {
queue 0 be;
queue 1 ef;
queue 2 af;
queue 3 nc;
}
scheduler-maps {
VOIP-MAP {
forwarding-class be scheduler be-sched;
forwarding-class ef scheduler ef-sched;
forwarding-class af scheduler af-sched;
forwarding-class nc scheduler nc-sched;
}
}
schedulers {
be-sched {
transmit-rate percent 10;
buffer-size percent 10;
priority low;
}
ef-sched {
transmit-rate percent 80;
buffer-size percent 80;
priority strict-high;
}
af-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
nc-sched {
transmit-rate percent 5;
buffer-size percent 5;
priority high;
}
}
Example
Re: [j-nsp] Stealing from MX firewall jtree space
## To allocate more memory for routing tables, include the route-memory-enhanced statement at the [edit chassis] hierarchy level: [edit chassis] route-memory-enhanced; ## You have to restart the FPC once you do this... From: Richard A Steenbergen r...@e-gerbil.net To: juniper-nsp@puck.nether.net Sent: Wed, December 16, 2009 1:26:55 PM Subject: [j-nsp] Stealing from MX firewall jtree space Anybody know the command on MX to steal unused memory from the firewall rldram segment to use it for routing data? I remember reading about this, I just can't remember the actual command. Last night I was trying to fire up a routing-instance and it ran out of fib memory much sooner than I expected, at around 750k routes total: Dec 16 07:42:14.831 re1.xxx. fpc3 RSMON: %PFE-4: Resource Category:jtree Instance:jtree2-seg0 Type:free-dwords Available:104576 is less than LWM limit:104857, rsmon_syslog_limit() With a main and logical-system each holding full v4/v6 routing tables it seems to have less than 4MB free on segment 0, but plenty left available in segment 1. ADPC3(re1.xxx. vty)# sh jtree 0 memory Jtree memory segment 0 (Context: 0x4430cfe0) --- Memory Statistics: 16777216 bytes total 10233192 bytes used 6539472 bytes available (3949056 bytes from free pages) 4032 bytes wasted 520 bytes unusable 32768 pages total 17138 pages used (2574 pages used in page alloc) 7917 pages partially used 7713 pages free (max contiguous = 693) Jtree memory segment 1 (Context: 0x4438ec20) --- Memory Statistics: 16777216 bytes total 4611728 bytes used 12162792 bytes available (12161024 bytes from free pages) 2664 bytes wasted 32 bytes unusable 32768 pages total 9007 pages used (9005 pages used in page alloc) 9 pages partially used 23752 pages free (max contiguous = 23743) Context: 0x42302f70 ADPC3(re1.xxx. vty)# sh jtree 0 summary Protocol Routes Bytes Used - -- -- IPv4 303043 4363344 IPv62533 46112 MPLS 1 16 Multi-service 1 16 Also bonus points if anyone can tell me how to accomplish the following without having to do a virtual-router routing-instance, and protocol bgp under that. I'm trying to take in ~150k of routes from a bgp neighbor, install ~50k of them into inet.0 with one policy, and install ~100k of them into another routing-instance with another policy. I can't just import the ones I want out of a single routing-instance, since instance-import only pulls the active routes. I also can't inject the routes into a particular rib w/rib-groups, since the rib-group requires inet.0, and won't let you do a per-rib policy only a per-rib-group policy. The best solution I could come up with was to make a routing-instance type virtual-router solely for the neighbor in question, run the protocols bgp under that routing-instance, and then instance-import the 50k routes I want from that rib into inet.0, and instance-import the other 100k routes I want into another routing-instance. There are two problems with this, #1 it burns memory to have a routing-instance that exists solely so I can import routes from there into other routing-instances, and #2 it is a major pain in the $%^ for my groups and commit scripts to deal with the protocols bgp config under a different hierarchy. I'm thinking I could at least block the installation of the routes to fib with a forwarding-table export policy term (from instance provider-vr, then reject), since I'm not forwarding with that rib, but I'm hoping there is a cleaner solution out there that I'm not aware of, like some way to inject the routes from one bgp neighbor directly into the ribs I want without an extra adj rib in holding rib. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] MX960 JunOS recommendations
How about some debugs or traceoptions? From: Tima Maryin t...@transtelecom.net To: kszarkow...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Wed, November 11, 2009 8:11:56 AM Subject: Re: [j-nsp] MX960 JunOS recommendations Uhm, i see your point here. We indeed have cisco - cisco - Jun - Jun setup My cisco interface mtu = ip mtu = mpls mtu =9000 But i raly doubt that bgp keepalive packet size can come close to that mtu. On Juniper i set interface mtu = cisco mtu +14 and it works fine! And! As you say, it reports different mpls mtu value: show interfaces xe-1/0/0 | match MTU Link-level type: Ethernet, MTU: 9014, LAN-PHY mode, Speed: 10Gbps, Loopback: None, Source filtering: Disabled, Protocol inet, MTU: 9000 Protocol mpls, MTU: 8988 Protocol multiservice, MTU: Unlimited As far as i understand default mpls mtu term (not sure that i _fully_ understand it though) it seems, Juniper supposes 3 labels maximum. I dont see any reasons for device to drop packets which has 1 or 2 labels and bigger than mpls mtu, but still ok from interface mtu point ov view. As per your logic, device should drop all traffic that match such criteria but it seems only bgp session keepalives and i didn't see any other problems But still, i made an experiment on Juniper and cisco which has bgp session between them. cisco: #sh mpls interfaces g 0/0 detail | i MTU MTU = 9000 #sh ip int g 0/0 | i MTU MTU is 9000 bytes #sh run int g 0/0 Building configuration... Current configuration : 212 bytes ! interface GigabitEthernet0/0 description --- to 7606-2 --- mtu 9000 ip address 10.3.13.2 255.255.255.0 load-interval 30 duplex full speed 1000 media-type gbic no negotiation auto tag-switching ip end If i set mtu 9000 under family mpls and commit it, it looks like this: show interfaces xe-1/0/0 | match MTU Link-level type: Ethernet, MTU: 9014, LAN-PHY mode, Speed: 10Gbps, Loopback: None, Source filtering: Disabled, Protocol inet, MTU: 9000 Protocol mpls, MTU: 9000 Flags: Is-Primary, User-MTU Protocol multiservice, MTU: Unlimited and problem still persists please let me know if you have any other ideas :) p.s. Its the same effect if i set tag-sw mtu 8988 on cisco and leave it 'default' (=8988) on juniper Krzysztof Szarkowicz wrote: Let me guess. Your network is multivendor network (JNPR and CSCO) and some transit devices are CSCO? CSCO and JNPR uses different algorithm to calculate default MPLS MTU (if MPLS MTU is not explicitely configured) which results in 4 byte difference between CSCO side and JNPR side of the same link for MPLS MTU (the IP MTU is equal on both ends, so no problem with OSPF). If on JNPR side your MPLS MTU is say 1500 and on the CSCO side the MPLS MTU is 1504, when the CSCO device send an BGP update packet towards JNPR device with size 1502, this packet is dropped by JNPR device (as it is to big), and TCP ACK is not sent back. CSCO is keeping by resending this 1502 long packet, and JNPR is constantly dropping. Thus, after hold timer expires, the Notification message is sent. I assume that with 9.3.R3.8 you didn't catched the '1502' packet sizes. Could you check with some show commands, what is the MPLS MTU on both ends of the link (which is terminated on CSCO on one side and JNPR on other side)? //Krzysztof -Original Message- From: Tima Maryin [mailto:t...@transtelecom.net] Sent: Wednesday, 11 November, 2009 9:57 To: kszarkow...@gmail.com Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX960 JunOS recommendations What did you mean by inappropriately configured ? There are the same mtu settings everywhere and traffic passes quite well. And ospf session goes up without problems. And how comes that inappropriately configured IP and MPLS MTU work well on 9.3R3.8 ? Krzysztof Szarkowicz wrote: It is not a nasty bug, but problem of inappropriately configured IP and MPLS MTUs on transit nodes. //Krzysztof -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tima Maryin Sent: Wednesday, 11 November, 2009 8:28 To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX960 JunOS recommendations 9.3R4.4 has a nasty bug which occures in setup when you have bgp session over chain of few routers/links with ospf/ldp bgp session occasionally goes down with notification timeout. Even when there is no traffic at all and no physical errors rollback to 9.3r3 helps though JTAC still not confirmed it, but it easlily can be reprodused in lab ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net
Re: [j-nsp] destination nat, 8 rule limit
Upgrade to 9.6. You can have many more rules per rule-set... From: Christopher M. Hobbs ch...@altbit.org To: juniper-nsp@puck.nether.net Sent: Tue, November 3, 2009 10:08:13 AM Subject: [j-nsp] destination nat, 8 rule limit If I try to set up more than 8 rules per rule-set on our SRX240 boxes, Junos gets cranky. Here's the error I receive: --- cho...@ss0101# commit check [edit security nat destination rule-set mail] 'rule' number of elements exceeds limit of 8 error: configuration check-out failed: (number of elements exceeds limit) --- I can't break our rules out into different rule sets because it complains of context at that point (which I believe is tied to the destination address?): --- cho...@ss0101# commit check error: Destination NAT rule-set mail and test have same context. [edit security nat destination] 'rule-set test' Destination NAT rule-set(test) sanity check failed. error: configuration check-out failed --- All of our incoming addresses exist on the same subnet and the majority of our destination addresses are on the same subnet as well, so I clearly can't split up our rules to work around this issue if the context is based on either the incoming or destination addresses. I've read a couple of threads concerning a similar issue and the fix was to upgrade to 9.6, which I did. The upgrade didn't appear to solve anything at all. Does anyone know why this restriction is here other than just poor programming? How can I get past this limitation? Thanks for your time! -- C.M. Hobbs, http://altbit.org ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-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] juniper trinity
http://www.amazon.com/Network-Processors-Architecture-Programming-Implementation/dp/0123708915/ref=sr_1_1?ie=UTF8qid=1256469141sr=8-1 Not to stray too off topic, but this book looks interesting... From: Nahrux M nah...@gmail.com To: Richard A Steenbergen r...@e-gerbil.net Cc: Juniper-Nsp juniper-nsp@puck.nether.net Sent: Sunday, October 25, 2009 1:00:49 AM Subject: Re: [j-nsp] juniper trinity Please have look at the below link EZchip Talks Juniper http://www.lightreading.com/document.asp?doc_id=179122 http://www.lightreading.com/document.asp?doc_id=179122 On Sat, Oct 24, 2009 at 11:19 PM, Richard A Steenbergen r...@e-gerbil.netwrote: On Sat, Oct 24, 2009 at 06:38:53PM +0200, magno wrote: I repeat, Trinity has nothing to do with ez-chip. My advice is to stop elucubrating around any ez-chip whatever. Ez-chip proved to be quite limited for some qos functions, so I really don't think juniper wants to be qos feature limited by a third-party chip anymore. I believe the original question was do the new asics integrate the functionality of ezchip, thus eliminating the need for it, and from what I've heard I believe the answer is yes. That is why we're talking about the ezchip in the first place. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] [c-nsp] juniper trinity
You are mistaken. They use the ez-chip in non Q cards as well for the MX. I think you only need to look at what the Q card does and you will see it does not marry up very well to the traffic management feature of the ez-chip... I think the previous poster was correct. Ethernet framing and MAC lookup is all they are used for. From: Roger Gabarit roger.gaba...@gmail.com To: Richard A Steenbergen r...@e-gerbil.net Cc: Juniper-Nsp juniper-nsp@puck.nether.net; cisco-...@puck.nether.net Sent: Saturday, October 24, 2009 5:56:18 AM Subject: Re: [j-nsp] [c-nsp] juniper trinity On Fri, Oct 23, 2009 at 12:54:40PM -0700, Marlon Duksa wrote: This Trio or Trinity, whatever they call it is internally grown technology...a combination if EZChip + I-chip functionality. Plus I don't think it is a good strategy for Juniper to use third party vendors as this will not give them differentiation... I've heard people make this argument, but it is absurd. The only thing EZChip is used for on the MX is basic Ethernet framing and MAC lookup. No doubt it was much cheaper and easier for Juniper to use an off the shelf chip for this than to spin their own just to do this. To go from there to claiming that the rest of the forwarding/queuing/etc will be the same as a Cisco platform is absolutely insane, the only thing they have in common is the Ethernet frame. I'm sorry not to agree on this one. Unless you can prove me that I'm wrong :) - Juniper uses the chips on the MX series only in -Q- Line Cards. So when you use something only in advanced QoS line cards, there's something related to QoS, definitely. - Check the description of EZChip NPs on their website ( http://www.ezchip.com), they are built to provide the Ethernet framing and MAC lookup AND traffic management). Neither Cisco nor Juniper would buy a chip to have it do only 20% of what it could do. Cisco uses the chip in the ES+/ES40 and in ASR 9k cards. Quote : EZchip’s NP-2 is a highly-flexible network processor with integrated traffic managers providing wire-speed packet processing and advanced flow-based bandwidth control. The NP-2 offers the speed of an ASIC combined with the flexibility of a programmable microprocessor. It provides the silicon core of next-generation Carrier Ethernet Switches and Routers (CESR). Through programming the NP-2 delivers a variety of applications such as L2 switching, Q-in-Q, PBT, T-MPLS, VPLS, MPLS and IPv4/IPv6 routing. The integrated traffic management provides advanced QoS for flow-based service level agreements (SLA) and enabling triple-play services (voice, video, data). All that stuff makes me think that the 2 vendors will not release any 100G ports (*with advanced QoS*) on MX or ASR until the EZChip NP4 is produced (not only prototypes). That gives by the way 2 years advance to Alcatel-Lucent from that point of view, because their 100G NP has been ready since last year. Funny market :) But well, let's wait for Juniper's next week announcement. Roger ___ 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] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960
Good thread... 1) We are testing 9.3r4 on MX right now to get the hell off 9.2r2. Can't wait to be done with that lemon release.. 2) We put no stock in vendor testing from anyone, including Juniper. When you start poking and prodding for details, you start hearing.. Well this is the thing... and About that, yeah, basically that isn't exactly... and then you realize in every case that these tests are total bullsh*t. Indeed, they rig the tests to make their products appear more favorable. 3) We are going to test back-to-back ASRs as a NAT solution. It will be the first time we test these boxes for a specific application. I believe these boxes will be serious competitors once they mature. Having said that, we have been burned by crappy coding so many times (from all vendors) that when they told us they are loading 100s of features a month into these boxes... we just couldn't believe it. There is no way we are putting any stock in that until its baked a little while. Not to mention they had trouble getting the ASR to boot and function very early on in our lab. It just didn't leave us with a good impression. But I'll say it again... I'm certain these boxes will be serious business in the next 12-24 months. Lets face it, services in M-series boxes are a little kludgy... Even if you are OK with many of the configuration restrictions (source NAT stinks, one dynamic IP IPsec profile per public IP, no GDOI yet or any multipoint encryption solution), then you are limited by the throughput of the services PIC.. and those are awfully expensive these days compared to the SRX or a low-end ASR which are more fexible and have better throughput for the price (for services...). From: Stefan Fouant sfou...@gmail.com To: mti...@globaltransit.net Cc: juniper-nsp@puck.nether.net Sent: Sunday, September 27, 2009 9:58:08 AM Subject: Re: [j-nsp] Miercom Competitive Performance Testing Results: Cisco ASR9000 vs Juniper MX960 On Sun, Sep 27, 2009 at 10:52 AM, Stefan Fouant sfou...@gmail.com wrote: You'd think that eventually Cisco would realize the gig was up, and at least get some other hired guns to do their testing in the future so they could keep the charade going for a few more years. One other thing I'd like to point out... in talking to my Cisco reps, it appears the ASR9000 isn't even something you can order at this point, and won't be generally available for quite some time (I've heard general availability won't be for at least 12 months at the least). I find it odd they'd compare something that isn't available to something that's been tried and proven in networks for years... Has anyone on-list managed to get your hands on an ASR9000? -- Stefan Fouant ___ 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] Two IPSec questions...
Using next-hop style service-sets. 1) Is there any kind of observable event/log entry that occurs when a plain IPSec tunnel goes down (remote endpoint has static IP)? When a tunnel goes down at one site, we would like to redirect traffic to another site that also has a tunnel to the same remote network... RRI doesn't work for remote static IPs. Also you can not have more than one ISAKMP access profile applied to a single public IP. I cant seem to get the router to generate any kind of event when DPD detects loss of peer. 2) Dynamic routing over IPSec using BGP... solutions (preferably without GRE)? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DMVPN on Juniper
Juniper really doesn't have a JUNOS based any-to-any type encryption solution. The sad part is that if they supported NHRP and GDOI, then they would have a solution that would be compatible with Cisco DMVPN is really just GRE w/NHRP and some propriety hooks into IPSec... take those propriety hooks out and its just GRE w/NHRP... now put GDOI on the WAN interface... and you have a far better any-to-any encrytion solution. NO per-tunnel encryption state. In fact, if you push the next-hop cache down to the spokes, then potentially there is no setup time at all for spoke-to-spoke communication... You would think that would be a great way of getting an existing Cisco customer to try a Juniper box if they have an any-to-any encryption requirement. Surely there are lots of these customers since ethernet WAN and MPLS WAN services are so prolific now... From: Dale Shaw dale.shaw+j-...@gmail.com To: David Prall d...@dcptech.com Cc: juniper-nsp@puck.nether.net Sent: Friday, July 17, 2009 10:13:54 PM Subject: Re: [j-nsp] DMVPN on Juniper Hi David, On Sat, Jul 18, 2009 at 1:08 PM, David Pralld...@dcptech.com wrote: The feature is called Auto Connect VPN http://www.juniper.net/solutions/literature/app_note/350126.pdf Thanks, but as I said in my original post (perhaps not very clearly, looking back at it now), my preference is for a solution using JUNOS. Anyway, have you used AC-VPN? and if so, how many sites? Is it reliable? Any tricks/traps? cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] JUNOS not compliant with RFC 3392?
All: We are establishing a BGP session between an M120 and a Checkpoint firewall. The Checkpoint does not support 4-byte ASs. It is sending the Notification to the M120 indicating so, but the M120 keeps sending the capability code everytime it trys to reestablish. Doesn't that make JUNOS non-compliant with RFC 3392? A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. In this case the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. # In the meantime, we used the hidden command disable-4byte-as. to establish connectivity. Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS not compliant with RFC 3392?
I just re-read this and realized that it says the speaker SHOULD try again without the code. It doesn't say MUST. So technically, its compliant. If Juniper chooses not to follow the recommendation of trying again without the code, then why is the disable-4byte-as command hidden? From: Derick Winkworth dwinkwo...@att.net To: juniper-nsp@puck.nether.net Sent: Monday, March 30, 2009 3:13:35 PM Subject: JUNOS not compliant with RFC 3392? All: We are establishing a BGP session between an M120 and a Checkpoint firewall. The Checkpoint does not support 4-byte ASs. It is sending the Notification to the M120 indicating so, but the M120 keeps sending the capability code everytime it trys to reestablish. Doesn't that make JUNOS non-compliant with RFC 3392? A BGP speaker determines that its peer doesn't support capabilities advertisement, if in response to an OPEN message that carries the Capabilities Optional Parameter, the speaker receives a NOTIFICATION message with the Error Subcode set to Unsupported Optional Parameter. In this case the speaker SHOULD attempt to re-establish a BGP connection with the peer without sending to the peer the Capabilities Optional Parameter. # In the meantime, we used the hidden command disable-4byte-as. to establish connectivity. Derick ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Build a GRE tunnel on VRRP routers
This will have to change if they really want to take a significant portion of the enterprise market. From: Richard A Steenbergen r...@e-gerbil.net To: Stefan Fouant sfou...@gmail.com Cc: juniper-nsp@puck.nether.net Sent: Monday, February 23, 2009 11:41:37 PM Subject: Re: [j-nsp] Build a GRE tunnel on VRRP routers On Mon, Feb 23, 2009 at 09:08:51AM -0500, Stefan Fouant wrote: GRE Keepalives are *still* not supported? I remember asking for this in an enhancement request almost 5 years ago... geez... Unless your name is ATT, you can pretty much assume that any of your requests or ideas are gonna fall on deaf ears. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] Juniper switching book...
All: I see this in the description on amazon and oreilly: # JNCIA-EX, JNCIE-X, and JNCIE-EX # Anyone care to elaborate on the those E level certs? D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Build a GRE tunnel on VRRP routers
VRRP was designed really for having two routers on a LAN and providing default gateway redundancy for hosts on the LAN. You should not mix your GRE tunnels with VRRP. Just build two tunnels and use a routing protocol over them for redundancy. Fatiha HOUACINE wrote: Hi, I would like to configure a GRE tunnel between two couples of VRRP redundant routers , The problem is that, I can't Use the Virtual IP to build on the tunnel. How can I build my GRE in this case, to detect faillure and interact with the VRRP mecanism. O __O VRRP *GRE*__VRRP O O ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.2/1965 - Release Date: 02/21/09 15:36:00 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SNMP issue...
#
Feb 20 17:44:54 snmpd[4d88b0c2]
Feb 20 17:44:54 snmpd[4d88b0c2] Get-Next-Request
Feb 20 17:44:54 snmpd[4d88b0c2] Source: 10.254.0.33
Feb 20 17:44:54 snmpd[4d88b0c2] Destination: 10.254.23.2
Feb 20 17:44:54 snmpd[4d88b0c2] Version: SNMPv2
Feb 20 17:44:54 snmpd[4d88b0c2] Request_id: 0x4d88b0c2
Feb 20 17:44:54 snmpd[4d88b0c2] Community: testcommunity
Feb 20 17:44:54 snmpd[4d88b0c2] Error: status=0 / vb_index=0
Feb 20 17:44:54 snmpd[4d88b0c2]OID : mib_2
Feb 20 17:44:54 snmpd[4d88b0c2]
Feb 20 17:44:54 SNMPD_AUTH_FAILURE: nsa_initial_embedcomm: unauthorized SNMP
community from 10.254.0.33 to unknown community name (testcommunity)
###
and here is the config...
[edit snmp]
juni...@bd-bottom-m120# show
community testcommunity {
authorization read-only;
routing-instance RDI;
}
routing-instance-access;
traceoptions {
file snmp;
flag all;
}
The traffic is coming in on the RDI routing-instance, which is what we want...
Any ideas? The community string is valid.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SNMP interface index change after upgrade to 9.2
I'm late jumping into this conversation, but are you using virtual-chassis by chance? Did the order of the individual units change when you upgraded? Chris Adams wrote: Once upon a time, Tore Anderson t...@linpro.no said: * Chris Adams Never used Cisco I guess? I have. As Steinar haug has already pointed out, IOS supports keeping ifIndexes static. Fortunately someone had the good sense to enable that feature, so they've never caused me any problems. I guess I had already switched to Cricket (where it didn't matter) before they added that option, and then we ditched Cisco for Juniper. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.10.23/1953 - Release Date: 02/14/09 18:01:00 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX-series automation, NETCONF woes
xpath wildcards? Ross Vandegrift wrote: On Wed, Jan 28, 2009 at 11:17:11AM -0800, Derick Winkworth wrote: xpath notation can help you find junos-interface:interfaces no matter where its located. Can you do that without providing a map that maps the abbreviated namespace back to the fully-qualified namespace? If so, I'd love to know how. In my understanding, the XPath query .//junos-interface:interfaces [1] only matches http://xml.juniper.net/junos/9.3R2/junos-interface:interfaces if I can somewhere say that junos-interface = http://xml.juniper.net/junos/9.3R2/junos-interface;. That just moves the problem to one of making a namespace map. Ross [1] - that's the XPath to find the element named interfaces from the namespace that's been abbreviated junos-interface in any subtree. No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.15/1922 - Release Date: 1/28/2009 7:24 PM ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
