Re: [j-nsp] MX480 filter options?

[Eric Van Tol]

I unicasted Matt, but for anyone else looking for the same:


https://store.filtrationgroup.com/UAF/electronics-cooling-air-filters-by-manufacturer-juniper

  -evt 

On 10/27/20, 9:00 AM, "juniper-nsp on behalf of Matthew Crocker" 
 
wrote:


I’d like to do some PM on my MX480s and replace the filter,   
FLTR-KIT-MX480-S is $1,000 for a piece of foam and some stamped sheet metal.   
Does anyone have any alternatives?

-Matt

___
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] ACX5448 & ACX710 - Update!

[Eric Van Tol]

We ran into this, too. We signed up to beta test at the beginning of this year 
and nowhere, not even in discussions with our SE (who also wasn't told by 
Juniper), was it mentioned it was a DC-only device. Imagine my surprise when I 
received the box and it was DC only. Such a disappointment.

-evt

On 7/29/20, 9:43 AM, "juniper-nsp on behalf of Mark Tinka" 
 wrote:

So an update on this thread...

Juniper went ahead and made the ACX710 a DC-only box. So if you are an
AC house, you're in deep doo-doo (which is us).

DC, for large scale deployment in the Metro? Makes zero sense to me.

Apparently, no way around this; which, to me, smells of the box being
built for some larger operator (like mobile), who primarily have DC
plants. And that's it - no other options for anyone else.

Oh, these vendors...

I haven't yet seen an ACX710 outside of a PDF, but deep scouring on the
Internet led me to this:



https://portal.nca.org.gh/search_type_approval_view_details.php?typeApproveDetailID=2244

Some kind of type approval with National Communications Authority of Ghana.

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] ACX5448 & ACX710

[Eric Van Tol]

On 1/22/20, 10:08 AM, "juniper-nsp on behalf of Mark Tinka" 
 wrote:
According to Juniper, it's targeted as an IP/MPLS router for the Metro
and similar applications.

It is meant to compete with Cisco's ASR920 and NCS540 boxes, as Juniper
have no plans to develop a lite version of the MX204.

Which is something many of us smaller providers have been begging them for 
YEARS to make. Hopefully it doesn't have restrictions on port configurations 
like the MX204 or weird filtering limitations like the original ACX boxes. The 
ASR920 is popular for a reason - they are rock-solid, offered decent port 
configurations, sensible and reasonably priced licensing, small form-factor and 
features decent enough for an access MPLS device.

Trying to get more info from my SE, but likely will not be able to share it due 
to NDA, as it's not yet a released product.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Managing MX480 fxp0

[Eric Van Tol]

This used to be possible by setting the "net.pfe.transit_re" (or similar) value 
using sysctl, but I'm not sure if it still works on newer Junos versions:

https://www.kumari.net/index.php/networking/tips-and-tricks/14-

I would not do this on production router, though. If you need to reach your 
fxp0 from locations outside of your OOB subnet, I think the practice is to 
either use source NAT on a device that has connectivity to your OOB or you 
should put fxp0 into a routing-instance using 'management-instance' on Junos 
17.x and above (I believe). One caveat to doing the latter is that if you use 
TACACS (and possibly RADIUS) for authentication and your source address is the 
router loopback IP in inet.0, your 'mgmt_junos' instance needs to have static 
routes for the TACACS servers installed:

routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.14.1; # Default route for fxp0 network
route 192.0.2.55/32 next-table inet.0;  # Public lo0.0 IP
route 10.55.234.90/32 next-table inet.0; # TACACS server
}
}

In my environment, this was necessary, but YMMV.

-evt

On 11/22/19, 12:02 PM, "juniper-nsp on behalf of Aaron Gould" 
 wrote:

Thanks again (Chris) for solving my vpls/irb/tagging combination problem
yesterday. we can bridge successfully now. 

 

Taking this one step further, we now are trying to route via fxp0 and
*through* it to the irb.100 interface and are unable to.

 

Is it possible to route traffic *through* an fxp0 interface ? (MX204)

 

I'm asking since it seems that someone mentioned that it is in fact possible
with some sort of static routes.  but I'm unsure what they meant exactly.

 

If it's definitely not possible to transit an fxp0 interface, I just need to
know that, and I will seek solutions using a revenue interface instead.

 

Resurrecting an old thread(s)..

https://www.mail-archive.com/juniper-nsp@puck.nether.net/msg09809.html   

https://puck.nether.net/pipermail/juniper-nsp/2010-August/017545.html 

 

subnet A-fxp0/mx204/irb.100subnet B

 

<---is bi-dir comms possible?-->

 

 

-Aaron

___
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] Suggestions for Edge/Peering Router..

[Eric Van Tol]

On 9/19/19, 1:05 AM, "juniper-nsp on behalf of Phil Reilly" 
 wrote:

MX104's are the dual brain unit of the 204. Though a 204 has 40/100G 
capabilities. If I read your original request correctly about ip 
routing. Not sure the 104/204 is grunty enough to deal with multiple 
internet tables. Thats a demanding task these days best left to the 
larger chassis.

The MX204 should work fine with multiple full table peers. The MX104 is the 
dual-RE version of the MX80 PPC-powered router. The MX204 is essentially an 
MPC7E, has a 64-bit Junos that runs the OS in a VM and has 16GB of RAM. MX204 
is pretty powerful for what it is, which is a 1U router with 100G/40G/10G/1G 
capabilities, but you cannot use all ports simultaneously if you enable 100G or 
40G. It's a bit convoluted, but it's explained here:

https://www.juniper.net/documentation/en_US/junos/topics/concept/port-speed-capability-mx204router.html

They offer a port-checker tool to verify configurations here:

https://apps.juniper.net/home/port-checker/index.html

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] 802.3ad LAG between ASR 1002-X and Juniper MX204

[Eric Van Tol]

On 7/19/19, 3:40 PM, "Gert Doering"  wrote:
That sounds a bit weird... why should the device care how the other
end balances its packets?  Never heard anyone state this, and I can't
come up with a reason why.

 *sigh* 

I'd been focusing way too much on the config portion of the documentation that 
I completely skimmed over the very first paragraph:

"MX Series routers with Aggregated Ethernet PICs support symmetrical load 
balancing on an 802.3ad LAG. This feature is significant when two MX Series 
routers are connected transparently through deep packet inspection (DPI) 
devices over an LAG bundle. DPI devices keep track of flows and require 
information of a given flow in both forward and reverse directions. Without 
symmetrical load balancing on an 802.3ad LAG, the DPIs could misunderstand the 
flow, leading to traffic disruptions. By using this feature, a given flow of 
traffic (duplex) is ensured for the same devices in both directions."

Carry on, nothing to see here...
 

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] 802.3ad LAG between ASR 1002-X and Juniper MX204

[Eric Van Tol]

Hi all,
I need to bring up a 2x10G LAG between an MX204 and a customer's ASR 1002-X and 
I want to make sure the links get load balanced as closely and reliably as 
possible. Junos docs say, "The hash-computation for the forward and reverse 
flow must be identical." They go on to detail how to configure a link index to 
each physical port and that Trio chipsets require symmetrical load-balancing. 
The LAG will be bridged through to one of the 40G uplinks on the MX204. Here's 
my config for the Juniper side:

chassis {
aggregated-devices {
ethernet {
device-count 1;
}
}
fpc 0 {
pic 1 {
hash-key {
family {
multiservice {
payload {
ip {
layer-3;
}
}
}
}
}
}
}
}
interfaces {
et-0/0/0 {
per-unit-scheduler;
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
}
unit 2 {
encapsulation vlan-bridge;
vlan-id 3190;
family bridge;
}
}
xe-0/1/0 {
gigether-options {
802.3ad {
ae0;
link-index 0;
}
}
}
xe-0/1/1 {
gigether-options {
802.3ad {
ae0;
link-index 1;
}
}
}
ae0 {
encapsulation ethernet-bridge;
aggregated-ether-options {
no-flow-control;
minimum-links 1;
link-speed 10g;
}
unit 0 {
family bridge;
}
}
}
forwarding-options {
hash-key {
family multiservice {
payload {
ip {
layer-3;
}
}
symmetric-hash;
}
}
enhanced-hash-key {
family multiservice {
no-mac-addresses;
}
symmetric;
}
}
On the Cisco, I am going to suggest:
port-channel load-balance-hash-algo src-dst-ip
!
interface TenGigabitEthernet0/0/0
no ip address
channel-group 1 link 1
!
interface TenGigabitEthernet0/0/1
no ip address
channel-group 1 link 2
!
interface Port-channel1
no negotiation auto
ip address 10.45.98.10 255.255.255.0
load-balance flow
!
Can anyone tell me if there is anything I'm missing here? I did not include 
here my CoS config to help with serialization delay issues. I don't have an ASR 
1002-X to test with and the ASR 920s I do have available to me don’t have full 
command parity with the 1002-X. I’m also not sure of the chipset differences 
between the 1002-X and the 920 model. Any suggestions appreciated.
Thanks,
evt


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Question about sampling rate - Juniper MX Series Edition 2

[Eric Van Tol]

Hi all,
I've been reading the much better information about Inline J-Flow in the 
Juniper MX Series O'Reilly book and there's a table in there that shows various 
sampling rates for MX sampling configurations (Page 770, Figure 8-5). It says a 
valid input-rate should match the formula: input-rate = 2n - 1. Why? Where is 
the exponent coming from? This isn't discussed anywhere in the actual docs, as 
far as I can tell, nor is there any explanation in the book.

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 Input Scheduling/Shaping

[Eric Van Tol]

Posting here for posterity.

The issue turned out to be that ingress scheduling can only be enabled on one 
MIC in the MX80. I had it enabled on both MICs and once I removed 1/0 and 1/1, 
the errors seem to have gone away. I only discovered this information in the 
Juniper MX Series, 2nd Edition book by Doug Hanks, Harry Reynolds and David 
Roy. If only the Juniper docs would mention this fact somewhere, or at least 
somewhere more obvious.

-evt

-Original Message-
From: juniper-nsp  On Behalf Of Eric Van 
Tol
Sent: Monday, October 8, 2018 7:06 AM
To: Tim Jackson ; Alexander Arseniev 

Cc: jnsp 
Subject: Re: [j-nsp] MX80 Input Scheduling/Shaping

>Looks like you get 12 queues per MX80/104 for ingress shaping. Doesn't seem to 
>be tied to QX at all. Egress you get per unit on the MIC slots though.
>
>https://www.juniper.net/documentation/en_US/junos/topics/task/configura
>tion/cos-configuring-ingress-hierarchical-cos-on-trio-mpc-mic.html
>
>https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-hi
>erarchical-scheduling-understanding-fine-grained-queuing-for.html

So according to this, ingress scheduling is supported on the MX80 MIC slots. My 
question remains, which is, wtf is up with the inconsistent commit error? I 
checked PRs, but I've yet to find anything relevant.

-evt

On Fri, Oct 5, 2018, 8:45 PM Alexander Arseniev via juniper-nsp < 
juniper-nsp@puck.nether.net> wrote:

> Hello,
> Egress scheduling/shaping on MIC ports - correct, that's why I said 
> "roughly" equal.
> Ingress scheduling/shaping  requires Q or EQ MPC which is not 
> supported on MX80.
> Thanks
> Alex
>
> -- Original Message --
> From: sth...@nethelp.no
> To: arsen...@btinternet.com; juniper-nsp@puck.nether.net
> Sent: 05/10/2018 20:20:06
> Subject: Re: [j-nsp] MX80 Input Scheduling/Shaping
>
> >>Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX 
> >>series book, 2nd ed, page 598.
> >>
> >>MX80 COS capabilities are roughly equal to MPC1, without Q.
> >
> >Disagree. MX80 does per-VLAN queuing/scheduling/shaping just fine for 
> >ports on MICs. *Not* for the builtin 10G ports.
> >
> >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
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 Input Scheduling/Shaping

[Eric Van Tol]

>Looks like you get 12 queues per MX80/104 for ingress shaping. Doesn't seem to 
>be tied to QX at all. Egress you get per unit on the MIC slots though.
>
>https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/cos-configuring-ingress-hierarchical-cos-on-trio-mpc-mic.html
>
>https://www.juniper.net/documentation/en_US/junos/topics/concept/cos-hierarchical-scheduling-understanding-fine-grained-queuing-for.html

So according to this, ingress scheduling is supported on the MX80 MIC slots. My 
question remains, which is, wtf is up with the inconsistent commit error? I 
checked PRs, but I've yet to find anything relevant.

-evt

On Fri, Oct 5, 2018, 8:45 PM Alexander Arseniev via juniper-nsp < 
juniper-nsp@puck.nether.net> wrote:

> Hello,
> Egress scheduling/shaping on MIC ports - correct, that's why I said 
> "roughly" equal.
> Ingress scheduling/shaping  requires Q or EQ MPC which is not 
> supported on MX80.
> Thanks
> Alex
>
> -- Original Message --
> From: sth...@nethelp.no
> To: arsen...@btinternet.com; juniper-nsp@puck.nether.net
> Sent: 05/10/2018 20:20:06
> Subject: Re: [j-nsp] MX80 Input Scheduling/Shaping
>
> >>Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX 
> >>series book, 2nd ed, page 598.
> >>
> >>MX80 COS capabilities are roughly equal to MPC1, without Q.
> >
> >Disagree. MX80 does per-VLAN queuing/scheduling/shaping just fine for 
> >ports on MICs. *Not* for the builtin 10G ports.
> >
> >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

[j-nsp] MX80 Input Scheduling/Shaping

[Eric Van Tol]

Hi all,
I've looked at the docs and can't find this, so maybe someone can point me in 
the right direction here. What are the limitations/restrictions on using input 
scheduling and shaping on the MX80 MICs? I have the 'traffic-manager mode 
ingress-and-egress' configured for the PIC and the following configured as a 
test in the CoS interfaces stanza:

ge-1/2/4 {
scheduler-map eth-egress;
input-scheduler-map eth-egress;
shaping-rate 50m;
input-shaping-rate 50m;

While this commits fine sometimes, it seems that whenever I make certain 
changes to other parts of the config, completely unrelated to ge-1/2/4, I get a 
commit error:

admin@mx80# show | compare
[edit interfaces]
+   ge-1/2/5 { /* OMITTED */ };
[edit bridge-domains bd1]
 interface ge-1/2/4.1 { ... }
+interface ge-1/2/5.1;

[edit]
admin@mx80# commit check
[edit class-of-service interfaces ge-1/2/4 input-scheduler-map]
  'input-scheduler-map eth-egress'
input scheduler map not allowed on interface ge-1/2/4
error: configuration check-out failed

[edit]
admin@mx80# rollback
load complete

[edit]
admin@mx80# commit check
configuration check succeeds

Sometimes I'll make a change, delete it, and the commit still won't work until 
I do a full rollback:

[edit]
admin@mx80# commit check
[edit class-of-service interfaces ge-1/2/4 input-scheduler-map]
  'input-scheduler-map eth-egress'
input scheduler map not allowed on interface ge-1/2/4
error: configuration check-out failed

[edit]
admin@mx80# show | compare

[edit]
admin@mx80# rollback
load complete

[edit]
admin@mx80# commit check
configuration check succeeds

This particular MX80 is on 17.1R1.8, but production will likely just use 
whatever the recommended version is. What gives here? Are certain aspects of 
ingress CoS not supported by the MX80?

Thanks,
evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Eric Van Tol]

> Beware the bundle upgrades on the MX104 – when we looked at these in 2016,
> for some reason that our VAR couldn’t explain it was cheaper to just throw
> the MX104-MX5-AC away and buy a brand new MX104-40G-AC-BNDL bundle rather
> than purchasing the MX104-MX5-40G-UPG license.

Yes, it's generally like that with all the absurd licenses on the low-end MX. 
Look at the price of an MX80, then look at the price of an MX5, upgraded 
gradually to an MX80 over time. Pay as you grow, indeed. It's actually cheaper 
to buy multiple other vendor routers entirely than to pay the exhorbitant 
license fees to upgrade one MX5 to support either the 2nd MIC slot or any one 
of the built-in 10G ports. 

That said, we have found that original MX80-5, which I believe was the original 
part number prior to Juniper shipping actual MX5 "board branded" routers, have 
no restrictions. Not that we would take advantage of this, but it's good 
information to have in the event of a capacity emergency.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MIC-3D-4XGE-XFP in a MX104?

[Eric Van Tol]

> Seems odd they would choose the same form factor for incompatible
> designs, but that explains why the 2-port card is more expensive.

Also seems odd the 4-port MIC is listed as compatible on the MX80/MX104 on the 
Hardware Compatibility List. This is why I put zero trust in these sorts of 
tools when building systems. I can confirm that the MIC doesn't even show up in 
the hardware listing if you install it into an MX80.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] deactivate routing-options forwarding-table

[Eric Van Tol]

> I do see where it looks like an export policy was applied but there is
> nothing in it
> 
> "set routing-options forwarding-table export exp-to-fwd"
> 
> show configuration policy-options policy-statement exp-to-fwd (no output)
> 
> 
> show configuration | display set | match exp-to-fwd (only thing found)
> set routing-options forwarding-table export exp-to-fwd

My guess is that someone deleted the exp-to-fwd policy, tried to commit, and 
saw it was being called from within the forwarding table. Rather than delete 
that line, they deactivated it, perhaps with a reason, but there should be no 
issues just removing that line altogether. The 'deactivate' just ignores the 
configuration altogether, essentially the same as not having any explicit 
forwarding-table configuration.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Odd issue with logical-system

[Eric Van Tol]

> Is the correct interface and unit number specified inside the logical-system
> on both sides?  

Yes - the issue isn't basic connectivity. I can see the inbound tcp syn on LS1, 
but it doesn't respond back. I have even deleted every lo0 filter on the router 
because that's the most obvious reason for dropping packets.

> Have you tried deleting the config, commit full, rollback?

I haven't done a commit full, but I've deleted the LS and added it back in, 
changed the loopback unit number and changed the BGP source address in LS1, all 
to no avail.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Odd issue with logical-system

[Eric Van Tol]

> Have you tried enabling BGP traceoptions to see if that logs more useful
> diagnostics?

Yes, per my first message:

>I also see absolutely nothing when I enable traceoptions on the 
>peer in LS1 and with MX2 attempting to contact LS1

Nothing helpful in those, with all flags enabled, both sides show the same 
thing:

bgp_connect_complete: error connecting to x.x.x.x (Internal AS x): Socket 
is not connected

Again, I don't even see a TCP SYN being sent in the 'monitor traffic interface' 
output on the only active interface in LS1, as though it's being dropped before 
it even hits the wire.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Odd issue with logical-system

[Eric Van Tol]

Hi all,
To Aaron - Yes, that map is correct.

> I have 40+ logical systems in a 4 chassis lab, all speaking 
> BGP withloads of families negotiated.

I've never had this problem with logical systems before except with this one 
router (MX1). It happened a couple years ago - the exact same thing - and I 
ended up moving the logical system off this router because I didn't have time 
to troubleshoot it, nor was it that important that the LS exist on this router.

> Start with the easy stuff.  Did you fat finger an ASN or an MD5 key?
> Did you set type internal?  Your trace options and show bgp neighbor
> output should help you determine the failure if it's an application
> layer issue.

Thanks, I did check all this and re-entered MD5 keys by pasting in on all 4 
routers. The fact that only one session out of the bunch isn't coming up 
indicates that it's not an MD5 or ASN issue, though, as they are all defined 
within groups and not individual definitions within the neigbhor statements. 
Traceoptions simply show that the attempts timed out. LS1 is not responding at 
all to the incoming request from MX2, nor is it even *sending* a TCP SYN to MX2 
in its own supposed session request (LS1 is not in passive mode). 

IPv6 peering between all four nodes is working, too.

I feel like this is going to end up a JTAC ticket, but wanted to know if anyone 
else had ever seen this behavior. I may end up rebooting MX1 to see if that 
fixes it, but I'd prefer not to do the Roy and Moss Method if I can help it.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Odd issue with logical-system

[Eric Van Tol]

Hi all,
Since I've now run into this issue a second time, I figured I'd reach out to 
the community to see if anyone else has experienced this. I'm working on a pair 
of MX960s, running 13.3R6.5. 

I have a pair of logical systems (LS1, LS2) configured in each MX960 (MX1, MX2) 
and both MXs are directly attached and in production with no other issues. Each 
logical system is configured to IBGP peer with each MX, but not each other. 

My problem is that LS1 is unable to bring up a BGP session with MX2. I've 
disabled all lo0 filters to ensure that it's not a filtering problem. Routing 
is working properly, as I can ping each MX from each LS and vice versa. If I do 
a 'monitor traffic interface' on MX2 and on LS1, I can see the MX sending a TCP 
SYN and it's received on LS1, but it's just dropped silently. I can also see an 
originating TCP session in the 'show system connections' output on LS1, but no 
packets are being seen leaving LS1. I also see absolutely nothing when I enable 
traceoptions on the peer in LS1 and with MX2 attempting to contact LS1.

Anyone else seen this? I don't see any PRs related this in 13.3R6, either.

Thanks in advance,
evt


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] J-NSP list working ?

[Eric Van Tol]

> Is the J-NSP list broken?  I haven't seen a post since Tuesday.

I think the entire network engineering community is on vacation, as even the 
high-traffic cisco-nsp list has only had about a half dozen messages in the 
past two weeks. :)

-evt 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RFC2544 and Juniper clarification

[Eric Van Tol]

Hi all,
Can anyone verify whether RFC2544 reflect mode is supported on MX80 with a 
20x1GE MIC installed, running 17.1? The documentation is ambiguous - some 
references say MX80 and MX104, while others state just MX104. Maybe the MX80 is 
implied when mentioning the MX104, I don't know.

As a follow-up, has anyone been able to get the MX to reflect non-Juniper 
sourced RFC2544 tests? I'm trying to test out sending RFC2544 packets from an 
Accedian device and I've yet to get the MX to reflect the data back to the 
Accedian. I've tried both L2 and L3 configurations:

L3:
disable-signature-check;
mode reflect;
reflect-mode mac-swap;
family inet;
source-udp-port ;
destination-udp-port ;
test-interface irb.6;
destination-ipv4-address 172.16.1.1;

L2:
source-mac-address 00:15:ad:39:53:3c;
destination-mac-address 5c:5e:ab:de:1e:f0;
ovlan-id 522;
outer-tag-protocol-id 0x8100;
ivlan-id 6;
service-type elan;
in-service;
disable-signature-check;
mode reflect;
reflect-mode mac-swap;
family bridge;
direction egress;
test-interface ge-1/2/9.16000;

Any guidance would be appreciated.

Thanks,
evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4600 : Ping problem

[Eric Van Tol]

> 'no route to host' normally means 'did not get an
> arp reply, could not deliver packet'.

"no route to host" normally indicates that the route does not exist in the 
routing table, not that an ARP response isn't coming back.

Are all your interfaces operationally up, including the IRB? 

-evt

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Chris Morrow
> Sent: Monday, November 28, 2016 3:06 PM
> To: deloin.rob...@laposte.net
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] EX4600 : Ping problem
> 
> SAt Mon, 28 Nov 2016 20:55:04 +0100 (CET),
> Deloin via juniper-nsp  wrote:
> >
> >
> > Hello,
> >
> > I have 2 EX4600 switchs.
> > They have the same symetric configurations:
> >
> >
> > SWITCH EX4600-1SWITCH EX4600-2
> >
> > interfaces {   interfaces {
> >   xe-0/0/1 { xe-0/0/1 {
> > unit 0 {   unit 0 {
> >   family ethernet-switching {family ethernet-switching {
> > interface-mode access; interface-mode access;
> > vlan { vlan {
> >   members vlan-RESEAUX;  members vlan-RESEAUX;
> > }  }
> > storm-control default; storm-control default;
> >   }  }
> > }  }
> >   }  }
> >
> >   irb {  irb {
> > unit 0 {   unit 0 {
> >   family inet {  family inet {
> > address 10.101.0.4/16; address 10.101.0.5/16;
> >   }  }
> > }  }
> >   }  }
> > }  }
> >
> >
> > routing-options {  routing-options {
> >   static {   static {
> > route 0.0.0.0/0 next-hop 10.101.0.1;   route 0.0.0.0/0 next-hop
> 10.101.0.1;
> >   }  }
> > }  }
> >
> >
> > vlans {vlans {
> >   default {  default {
> > vlan-id 1; vlan-id 1;
> >   }  }
> >
> >   vlan-RESEAUX { vlan-RESEAUX {
> > vlan-id 98;vlan-id 98;
> > l3.interface irb.0;l3.interface irb.0;
> >   }  }
> > }  }
> >
> > I put an optic fiber between xe-0/0/1 from a switch and xe-0/0/1 from the
> other switch.
> > And I can't ping the @ 10.101.0.3 and 10.101.0.4 from each switchs.
> 
> you appear to have 2 interfaces connected, with a single fiber and a
> /16 netblock assigned.  Then you ping .3 which is on neither
> interface, so ... 'no route to host' normally means 'did not get an
> arp reply, could not deliver packet'.
> 
> this sounds like it's working exactly as expected?
> 
> > I obtain :
> > root@EX4600-01# run ping 10.101.0.3
> > PING 10.101.0.3 (10.101.0.3): 56 data bytes
> > ping: sendto: No route to host
> > ping: sendto: No route to host
> > ping: sendto: No route to host
> > ping: sendto: No route to host
> > the same for the other.
> >
> > Can you help me. Can you tell me where is the mistake, or what I forget ?
> >
> > Thank you !
> > ___
> > 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] QoS when there is no congestion

[Eric Van Tol]

> Yeah YMMV indeed, as your approach works only in one of the three cases
> below:
> 1) Your network is not connected to the Internet.
> 1) Your network is connected to the Internet, but all traffic on your
> network is best effort.
> 3) Your network is connected to the Internet, but the sum of traffic that
> can ingress your network from the Internet is less than the capacity of the
> smallest link on your network.

My opinion on QoS for networks with low bandwidth is to always implement it. 
It's really not that difficult and you never know when microbursts could be 
affecting things. Believe me, even if your upstream link is a 1Gb/s circuit, 
and your outbound traffic is less than 10Mb/s, you can still have drops due to 
microbursts.

Voice and video, depending on your use of them, are normally very important and 
very sensitive to drops/delays. It will never cost you anything (besides time) 
to learn to implement some simple QoS policies, however, if you have customers 
who complain about bad voice/video quality, it will cost you your reputation 
and possibly revenue when said customers cancel their contracts because of a 
service you cannot reliably provide.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX for subscriber aggregation

[Eric Van Tol]

> > I use ACX5048
> >
> Fantastic, and good to hear from you again Aaron! Currently we're used to
> that sort of behaviour as our PPPoE LNS dumps /32 routes for each
> subscriber. But thanks for the heads up and mention of your usage!
> 

Will ACX5048 operating temperature limitation work in a cell tower (32F to 
104F)? They seem to be more aligned with installation inside a temperature 
controlled environment such as a general colo facility, no? Moreover, the power 
consumption on these is like 350W fully loaded, which is more than three times 
as much as a 24-port ASR920.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX5048 - vlan-map conflict with routing-instance with vlan-id tags?

[Eric Van Tol]

> Can't actually picture what you are really trying to achieve here with an
> irb and multiple vlan tags, but did you try configuring `vlan-id-list` under
> the logical unit? That or vlan-id-range might be useful.
> 
> If what i just said was totally irrelevant to you, please elaborate the
> picture and the problem you are facing :p
> 

I suspect what he is asking for is a valid configuration on the ACX that is 
similar to what you can do on the MX - he has customers on different VLANs that 
he wants to put into the same broadcast domain:

MX Config:
set interfaces ge-1/1/1 unit 281 encapsulation vlan-bridge
set interfaces ge-1/1/1 unit 281 vlan-id 281
set interfaces ge-1/1/1 unit 282 encapsulation vlan-bridge
set interfaces ge-1/1/1 unit 282 vlan-id 282
set interfaces irb unit 128 family inet address 192.168.254.1/24
set bridge-domains shared-bd description "Shared Bridge Domain"
set bridge-domains shared-bd domain-type bridge
set bridge-domains shared-bd vlan-id 128
set bridge-domains shared-bd interface ge-1/1/1.281
set bridge-domains shared-bd interface ge-1/1/1.282

Not sure if it's the same on ACX, or even if it's possible, but the above 
configuration works on the MX for aggregating mismatched VLANs into one bridge 
domain.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] vMX for ESXi

[Eric Van Tol]

> It would seem that vMX is still in the quite early stages.  When I looked
> at it a few months ago, the documentation was lacking lots of details.  In
> the end, I just didn't feel like it was ready for production in the role
> that I wanted to use it in.  The lack of VMWare support at the time was one
> of the main reasons as well.

While I applaud Juniper for continuing to develop vMX, can someone shed some 
light as to how this type of nonsense gets by the product managers and QA? To 
their credit, they are responding to issues on their forum and quickly trying 
to fix them, but how does it even get this far? Are they trying to meet 
arbitrary release deadlines? Was this meant to be a beta release or an official 
release?

evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 console port woes

[Eric Van Tol]

> I don't.  We have a bunch of LX-4032T-001 from 2012 running 5.3 and
> happily talking to EX4200 switches.  I know we had to replace some
> older MRV that lacked the memory for the firmware upgrade.  I no
> longer remember the model numbers.
> 
> Rich

Thanks again. We found out from our MRV rep that the hardware only supports up 
to 4.1.8. Oh well.

Thanks!
evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 console port woes

[Eric Van Tol]

> We have seen this several times.  It is apparently a firmware issue
> on the MRV, and it affects EX4200 and EX4500 consoles, but not SRX
> or MX or anything else that we own.  You need to be running firmware
> version 5.2 or higher on your MRV console server.
> 
> Rich

Wow, thanks! Do you know if 5.2 will run on the LX-4032-001? I get the feeling 
that this model is a bit long in the tooth and may not be officially supported 
anymore.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 console port woes

[Eric Van Tol]

I’ve looked at this and there’s nothing in the console port config at all. I’ve 
tried disabling and re-enabling the console port in the config, as well as 
rebooting the switch to see if there was some “negotiation” going on. I’m able 
to connect to the console using a Cisco 2511 terminal server, as well as just a 
regular serial connection to a PC. It’s just the connection to this MRV console 
server that isn’t working. This is what I get:

InReach:0 >>telnet 172.28.1.2 2100

Entering character mode
Escape character is  ^] .

¿ÿÿ¿ÿÿ

I can remove the cable from the EX4200 and plug it into anything else and it 
works fine, so I’m stumped as to why any EX doesn’t work.

-evt

From: Will O'Brien - NOAA Affiliate [mailto:will.obr...@noaa.gov]
Sent: Thursday, December 31, 2015 12:04 PM
To: Eric Van Tol <e...@atlantech.net>
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] EX4200 console port woes

double check the console port config... .

It's under system ports console

On Thu, Dec 31, 2015 at 9:11 AM, Eric Van Tol 
<e...@atlantech.net<mailto:e...@atlantech.net>> wrote:
Hi all,
I have been struggling for the past day to get my EX4200 console ports to work 
on an MRV LX4000T console server and something is just not right. I'm hoping 
someone else may have come across this or tell me where I'm being stupid.

I'm using a rolled cable that works fine with the SRX and various Cisco 
consoles. Console server is configured with 8N1, no flow control, 9600bps, but 
when I try to connect to the EX, I get gibberish on the screen and framing 
errors showing up in the port stats on the console server. Pinouts for both the 
EX and SRX (and I imagine all Juniper gear) are the same:

EX:
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/port-ex-series-console-connector-pinout.html

SRX:
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/rj45-connector-pinout-srx110-for-console-port.html

I cannot figure out what's going on with the EX. Again, cable has been tested 
with multiple other kit, so it's not a cable issue AFAIK.

Thanks,
evt

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.net<mailto: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 console port woes

[Eric Van Tol]

> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
> Jérôme Nicolle
> Sent: Thursday, December 31, 2015 12:20 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] EX4200 console port woes
>
> The default console speed on the EX4200 is 9600bauds, as stated here :
> 
> http://www.juniper.net/techpubs/en_US/release-independent/junos/information-
> products/topic-collections/hardware/ex-series/ex3200-4200/topic-42349.html
> 
> Eric's settings looks fine, unless he missed a change in console speed
> configuration.

Correct, but I did try different speeds just as a test, with no change. It 
*does* mimic a speed issue, though. 

Tried other ports, other EX switches, other cables.

There seems to be something specific with the EX console port that this MRV 
does not like. Again, the problem does not appear to be the console port 
itself, as it works perfectly when I access it by other means. And again, I can 
simply move the cable into any other device that isn't an EX switch and I get 
proper communication on that port.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] EX4200 console port woes

[Eric Van Tol]

Hi all,
I have been struggling for the past day to get my EX4200 console ports to work 
on an MRV LX4000T console server and something is just not right. I'm hoping 
someone else may have come across this or tell me where I'm being stupid.

I'm using a rolled cable that works fine with the SRX and various Cisco 
consoles. Console server is configured with 8N1, no flow control, 9600bps, but 
when I try to connect to the EX, I get gibberish on the screen and framing 
errors showing up in the port stats on the console server. Pinouts for both the 
EX and SRX (and I imagine all Juniper gear) are the same:

EX:
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/port-ex-series-console-connector-pinout.html

SRX:
http://www.juniper.net/techpubs/en_US/release-independent/junos/topics/reference/specifications/rj45-connector-pinout-srx110-for-console-port.html

I cannot figure out what's going on with the EX. Again, cable has been tested 
with multiple other kit, so it's not a cable issue AFAIK.

Thanks,
evt
 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Basic Implementation of VLAN/LogicalPort across MPLS

[Eric Van Tol]

 interfaces {
 ae0 {
 aggregated-ether-options {
 lacp {
 active;
 }
 vlan-tagging;
 encapsulation flexible-ethernet-services;
 unit 10 {
 encapsulation vlan-ccc;
 vlan-id 10;
 }
 unit 20 {
 encapsulation vlan-ccc;
 vlan-id 20;
 }
 }

Additionally, if you need to transport a single VLAN on one side to a full port 
on the other, you need to pop the VLAN on ingress (and push on egress) into 
(and out of) the tunnel:

unit 10004 {
description To Port-Based EoMPLS;
encapsulation vlan-ccc;
vlan-id 2123;
input-vlan-map pop;
output-vlan-map push;
family ccc;
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] experience with modeling tool

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Phil Bedard
 Sent: Wednesday, December 24, 2014 11:41 AM
 To: jjs...@aol.com; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] experience with modeling tool
 
 Junosphere doesn't do that type of modeling and simulation but WANDL
 does.  Juniper may be working on Junosphere/WANDL integration now that
 they own WANDL. They used to support Cariden MATE within Junosphere but
 stopped when Cisco bought Cariden.
 
 WANDL will certainly do what you want, I would talk to your sales rep
 about it.  The other popular tools are Cariden MATE now owned by Cisco
 and OpNet now owned by Riverbed.
 
 Cariden was the easiest to use in my previous experience.

All these are great until you see the price tag.  If you're a huge telco or NSP 
and money is no object, go for it.  It might be better for most smaller shops 
to just purchase some Junosphere time, as there is a virtualized WANDL VM that 
can be hooked up to your topology in Junosphere.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 JFlow Setup

[Eric Van Tol]

Be aware that modifying the 'table-size' parameters will cause the tfeb to 
reboot.  You will want to do this during a maintenance period if this is a 
production router.

-evt

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Scott Granados
 Sent: Tuesday, December 23, 2014 12:31 PM
 To: Levi Pederson
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] MX80 JFlow Setup
 
 Hi there, what you have will work well with a  few modifications.
 
 If you're using inline sampling you might as well set the rate to 1, the
 sampling is happening at 1:1 regardless and all the rate adjusts in this
 config is the scaling factor.
 You're config also needs sample points so something like
 
 set interfaces xe-0/0/0.0 family inet sampling input
 place an input sampling statement on the interfaces that face your
 upstream and that face your inside network, do not sample on the output
 channel.
 
 You also don't need to define everything on the template level
 you can just do services monitoring flow sampling template ipv4 ipv4-
 template
 
 you can set your flow sizes on the forwarding options sampling instance
 input section and finally you want to define an ipv4 and ipv6 flow-table
 size on the tfeb.
 
 set chassis tfeb slot 0 sampling instance blah ipv4 and ipv6 table-size
 
 note that the tfeb will restart when configured  to reprogram with the
 new flow table size settings.
 
 Settings are 1-15 where the number is x*256K flows.  You can define ipv4
 only if you do not have any ipv6.
 
 Hope that helps.
 
 
 On Dec 23, 2014, at 12:16 PM, Levi Pederson
 levipeder...@mankatonetworks.net wrote:
 
  All,
 
  Trying to get an MX80 to output Flow to an external collector.  I've
 been
  reading several pieces of documentation and I keep getting differing
 views
  and opinions on how this is supposed to be done.  I'm looking for the
  simplest option right now and if I need to expand I can move to more
  detailed processes after
 
  I'm currently using the following
 
  [edit chassis]
  -   tfeb {
  -   slot 0 {
  -   sampling-instance calix;
  -   }
  -   }
  [edit]
  -  forwarding-options {
  -  sampling {
  -  instance {
  -  calix {
  -  input {
  -  rate 50;
  -  }
  -  family inet {
  -  output {
  -  flow-server [ipaddress] {
  -  port 2058;
  -  version-ipfix {
  -  template {
  -  ipv4;s
  -  }
  -  }
  -  }
  -  inline-jflow {
  -  source-address [ipaddress];
  -  }
  -  }
  -  }
  -  }
  -  }
  -  }
  -  }
  -  services {
  -  flow-monitoring {
  -  version-ipfix {
  -  template ipv4 {
  -  flow-active-timeout 60;
  -  flow-inactive-timeout 70;
  -  template-refresh-rate {
  -  seconds 30;
  -  }
  -  option-refresh-rate {
  -  seconds 30;
  -  }
  -  ipv4-template;
  -  }
  -  }
  -  }
  -  }
 
 
  Edited for Anonymity.
 
  Thank you,
  .
  *Levi Pederson*
  Mankato Networks LLC
  cell | 612.481.0769
  work | 612.787.7392
  levipeder...@mankatonetworks.net
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 anti-spoofing filter

[Eric Van Tol]

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Mark Tinka
Sent: Wednesday, December 17, 2014 1:06 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MX80 anti-spoofing filter

That's what we do.

Mark.

+1.  We have a 'bgp-customers' prefix-list which includes not only our 
customer's networks, but the networks in our own IP space that our customers 
use for BGP.  

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Move traffic to strict-priority-queue on MX

[Eric Van Tol]

-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of 
Mark Tinka
Sent: Monday, December 01, 2014 7:48 AM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Move traffic to strict-priority-queue on MX

I'd suggest spending some time reading up on the CoS (Class 
of Service) subject on Juniper's web site, so you can get a 
better handle on what you need to do. 

Read this Day One book, it's very helpful:

http://www.juniper.net/us/en/training/jnbooks/day-one/fundamentals-series/deploying-basic-qos/

If you want more specific MX class of service info, I highly recommend the 
O'Reilly Juniper MX Series book:

http://www.juniper.net/us/en/training/jnbooks/mx-series.page

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ACX is just not there (was Re: EX4550 L2Circuit/VPN to MX80/lt Interface)

[Eric Van Tol]

-Original Message-
From: Phil Bedard [mailto:phil...@gmail.com] 

Maybe vMX is the answer to a 1U MX at this point, depending on the 
throughput you really need.  

How do you stuff a minimum of 12x1G and 4x10G interfaces into a 1U server that 
needs to have a maximum 26 depth and 100F+ degree environments with little to 
no airflow?  Or am I misunderstanding the vMX?  Not trying to be snarky, it's a 
serious question.  I am not sure where I would see the vMX in a production 
service provider network, but I am certainly open to ideas.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface

[Eric Van Tol]

On Wed, Nov 12, 2014 at 10:04 AM, Mark Tinka mark.ti...@seacom.mu wrote:

 If you're trying to make a router out of something that
 looks like a switch, the Cisco ME3600X is hard to beat.


ME3600X is wonderful, but very expensive once you get the full feature
set.  We are waiting (rather impatiently at this point) for our first
ASR920 to arrive to test out.  This is supposed to be the replacement
for the ME3400, but with MPLS.  It fits us nicer than the ME3600X, as
the footprint is much smaller and there are various models for port
density.


 ALU have a good product, but hardware layout is still an
 issue for me in this space.

Odd - we tried to engage ALU and they said all their gear is layer-2
only.  They were supposed to come to our office for a meet-and-greet,
but never came.  This is the second time we've tried to engage them
with no success.  Guess they are not interested in our business.

 Juniper have continued to come short in this area. And no,
 the ACX doesn't cut it.

Agreed.  ACX is just not there.  It baffles me why Juniper has left
this market untapped.  The mid-range MX is just too expensive and too
big for our deployments and the lack of LSR functionality in the EX
won't work for us.

Now, to get back on topic:

OP - we have some L2circuits on LT interfaces, but not with an EX on
the other end.  Is there any way you can try this by hairpinning a
couple of GE ports on the MX80?  Also, what's the reason behind using
'l2vpn' instead of 'l2circuit'?  I see you are using private
addressing on your interface - is there any chance that there are
blanket filters applied to your interface using configuration groups
or perhaps a forwarding table filter to prevent 1918 space from
traversing your network?


 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] Refurbished

[Eric Van Tol]

On Mon, Oct 20, 2014 at 11:26 AM, Mark Tinka mark.ti...@seacom.mu wrote:

 On Monday, October 20, 2014 03:36:53 PM Jerry Jones wrote:

  As long as DPC are the only line cards should work well.
  I am reluctant to mix with MPC in a single chassis.

 This should, apparently, be fixed in later code.

We run both MPC and DPC on multiple MX960s in our network without
issue.  We are currently on 12.3R6.6 and had run previously on 11.4R7
no problem.  That said, if I had my choice and unlimited budget, the
DPCs would be tossed in favor of the MPC modules.

-evt
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Question about inline flow sampling on MX 480 / Treo based interfaces

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Scott Granados
 Sent: Wednesday, June 11, 2014 11:13 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Question about inline flow sampling on MX 480 / Treo
 based interfaces
 
 What's the story on this and are there any
 pointers to methods of determining the best most granular rate possible?
 Any help would be most appreciated.
 

It's my understanding that the sample rate has no effect when inline sampling 
is being done.  It can be configured, but sampling is performed on a 1:1 ratio 
no matter what.  Someone please correct me if I'm wrong.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Feature difference between latest Junos 12 and 13

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Gavin Henry
 Sent: Wednesday, June 04, 2014 7:28 PM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Feature difference between latest Junos 12 and 13
 
 Found it:
 
 http://pathfinder.juniper.net/feature-explorer/compare-
 softwares.html?swName=Junos+OStyp=1#bm=cmpswpl=MX80rel1=13.3R2rel2=12
 .3R6

I would take this data with a tiny grain of salt - the data it provides on a 
per-hardware model basis is often incredibly inaccurate.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Trio Bandwidth

[Eric Van Tol]

Hi all,
I'm trying to clear something up that's been bothering me for some time and 
that is the MPC1/MPC2/MPC3E actual bandwidth specs.  I know from various 
sources that the MPC1 has a single Trio chipset, MPC2 has two Trio chipsets, 
and the MPC3E has a single enhanced Trio chipset.

The question I have is related to bandwidth.  The Juniper MX Series book says 
the MPC1 is 40Gb/s throughput, the MPC2 is 80Gb/s throughput, and the MPC3E is 
130Gb/s throughput.  Are these numbers in full duplex rates, ie. the MPC2 can 
only handle 4x10G ports total before it is oversubscribed?  Or is the total 
throughput on each one really 80Gb/s, 160Gb/s, and 260Gb/s bi-directionally?

Bonus question - what does the 'Enhanced' portion of the MPC1E/MPC2E provide 
over the original non-E versions?

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Limitations of MPLS support on EX4200

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Jerry Jones
 Sent: Thursday, May 01, 2014 7:57 AM
 To: Victor Sudakov
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Limitations of MPLS support on EX4200
 
 My favorite place to go and find out if a feature is available for any
 platform vs release is the feature explorer. It really does a nice quick
 job and produces a nice savable output
 
 http://pathfinder.juniper.net/feature-explorer/

Yeah, if only the data it produced was actually correct.  I wasn't aware that 
the MX80 supported Virtual Chassis, 100-Gigabit Ethernet MICs, MX-MPC2-3D MPCs, 
and any number of DPCs, but according to Feature Explorer, all these things are 
supported.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] J2300/J4300 FPCs cannot go online

[Eric Van Tol]

 Hi all,
 We have a lot of J2300/J4300 routers in educational labs.
 Suddenly (this weekend) on all of them all the interfaces (both embedded
 and on line cards) disappeared.

This was just released:

http://kb.juniper.net/InfoCenter/index?page=contentid=TSB16366

Junos License Certificate Expired 2014-03-24 Issue

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Eric Van Tol]

ast.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Eric Van Tol]

 it's a nice-to-have, maybe? but this sounds more like an opportunity for
 you to sell some JNCIA courses. i mean, how long has junos been around
 now?

Confusing comment, since this enhancement isn't about CLI inexperience.  It 
doesn't matter how long Junos has been around or how experienced someone is, 
it's still too incredibly easy to hit 'Enter' too soon and clear all your BGP 
neighbors by accident.

I don't see a problem with adding the requirement 'all'.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] H-QoS support

[Eric Van Tol]

 -Original Message-
 From: sth...@nethelp.no [mailto:sth...@nethelp.no]

 You should be just fine with 12.3. Can you share some of your config
 related to the H-QoS?

I'm barely at the testing phase right now.  The config I was using is below, 
but using this config, I was unable to ping across my S-VLAN 107 C-VLAN 100 
until I removed the entire config and added it back in again without the 
'hierarchical-scheduler' command.  Then I saw the errors and went to 
investigate further, as opposed to spending all day trying to get it working.  
(Instead, I spent all day trying to see if it was even supported).

Config follows.  Trying to do a simple 'strict-high' priority on SV107-CV100 
(unit 107) while sharing 100m with units 1777 (45m cir) and 1778 (45m cir).

~~~
interfaces {
interface-set cid- {
interface ge-1/0/5 {
vlan-tags-outer 107;
}
}
ge-1/0/5 {
enable;
hierarchical-scheduler;
flexible-vlan-tagging;
mtu 9192;
encapsulation flexible-ethernet-services;
gigether-options {
no-auto-negotiation;
}
unit 102 {
vlan-tags outer 102 inner 102;
family inet {
address 172.20.1.21/30;
}
family mpls;
}
unit 103 {
vlan-tags outer 103 inner 103;
family inet {
address 172.20.1.9/30;
}
family mpls;
}
unit 104 {
vlan-id 104;
family inet {
address 172.20.1.5/30;
}
family mpls;
}
unit 105 {
vlan-id 105;
family inet {
address 172.20.1.25/30;
}
family mpls;
}
unit 106 {
vlan-tags outer 106 inner 106;
family inet {
address 172.20.1.13/30;
}
family mpls;
}
unit 107 {
vlan-tags outer 107 inner 100;
family inet {
address 172.20.1.245/30;
}   
}
unit 1777 {
encapsulation vlan-ccc;
vlan-tags outer 107 inner 300;
input-vlan-map pop-pop;
output-vlan-map push-push;
family ccc;
}
unit 1778 {
vlan-tags outer 107 inner 101;
family inet {
address 172.20.1.97/30;
}
}
unit 2694 {
vlan-id 2694;
family inet {
address 172.20.1.17/30;
}
family mpls;
}
}
}
class-of-service {
classifiers {
dscp ds-voip {
forwarding-class ef-class {
loss-priority low code-points ds-ef;
}
forwarding-class af-class {
loss-priority low code-points ds-af;
}
}
}
code-point-aliases {
dscp {
ds-be 00;
ds-af 100010;
ds-ef 101110;
ds-nc 11;
}
}
forwarding-classes {
queue 0 be-class;
queue 1 ef-class;
queue 2 af-class;
queue 3 nc-class;   
}
traffic-control-profiles {
LEVEL_1-phy_int_shaper {
shaping-rate 1g;
}
LEVEL_2-svlan_100m {
shaping-rate 100m;
guaranteed-rate 100m;
}
LEVEL_3-cvlan_100 {
scheduler-map cvlan-voice;
shaping-rate 10m;
guaranteed-rate 10m;
}
LEVEL_3-cvlan_101 {
scheduler-map cvlan-data;
shaping-rate 100m;
guaranteed-rate 45m;
}
LEVEL_3-cvlan_300 {
scheduler-map cvlan-data;
shaping-rate 100m;
guaranteed-rate 45m;
}
LEVEL_2-svlan_10m {
shaping-rate 10m;
guaranteed-rate 10m;
}
}
interfaces {
interface-set cid- {
output-traffic-control-profile LEVEL_2-svlan_100m;
}
ge-1/0/5 {
output-traffic-control-profile LEVEL_1-phy_int_shaper;
unit 102 {
output-traffic-control-profile LEVEL_2-svlan_10m;
classifiers {
dscp ds-voip;
}
}
unit 103 {
output-traffic-control-profile LEVEL_2-svlan_10m;
classifiers {
dscp ds-voip;
}
}
unit 104 {
output-traffic-control-profile LEVEL_2-svlan_10m;
classifiers {
dscp ds-voip;
}
}
unit 105 {  
output-traffic-control-profile LEVEL_2-svlan_100m;
classifiers {
dscp ds-voip;
}
 

Re: [j-nsp] H-QoS support

[Eric Van Tol]

 -Original Message-
 From: sth...@nethelp.no [mailto:sth...@nethelp.no]
 Sent: Friday, February 07, 2014 1:05 PM
 To: Eric Van Tol
 Subject: Re: [j-nsp] H-QoS support

 H-QoS is supported on the MICs, because these connect to the Q side of
 the switching ASIC. It is *not* supported on the builtin 10G ports (not
 relevant to the MX5 in any case).
 

Thanks for the confirmation.  I was aware that 10G were only port-based queuing 
and I did find some more documentation that supports your statement, but 
whenever I enable hierarchical queuing on MIC slot 1 (the 10-port 1G MIC) of my 
MX5, I see this in the syslog:

dcd[1415]: DCD_PARSE_ERROR_HIER_SCHEDULER: ge-1/0/5: hierarchical or shared 
scheduler is not valid on this interface
dcd[1415]:  get_fpc_i2cid_from_ifd: Cannot determine FPC i2cid
dcd[1415]:  get_fpc_i2cid_from_ifd: Cannot determine FPC i2cid
dcd[1415]: check_hardware_encap_support_scheduler: fpc i2cid is invalid

Am I missing something here?  Is there a minimum release version?  I'm on 
12.3R5.7 at the moment and I shudder to think that I would have to go up to 
13.x.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] RSVP neighbor sequence changes

[Eric Van Tol]

 -Original Message-
 From: Alex Arseniev [mailto:arsen...@btinternet.com]
 Sent: Wednesday, February 05, 2014 8:08 AM
 To: Eric Van Tol; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] RSVP neighbor sequence changes
 
 Duplicate IP on this shared segment?
 Just my guess...
 HTH
 Thanks
 Alex

Good suggestion, but alas, that was not the problem.  This morning, I ended up 
just disabling the interfaces entirely, then re-enabling them and the issue 
stopped occurring.

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RSVP neighbor sequence changes

[Eric Van Tol]

Hi all,
Two sets of routers in my network keep logging the following message:

rpd[1559]: RPD_RSVP_NBRDOWN: RSVP neighbor x.x.x.x down on interface ae0.1 
nbr-type Direct, neighbor seq number change 

The interface is different on the two sets of routers, obviously.  All other 
RSVP sessions seem to work fine:

RSVP neighbor: 6 learned
Address   Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd
x.x.x.x  0  2/1  12w4d 21:39:069 1282869/1282869 376297
x.x.x.x  0  2/119:29:029  7786/7786 18297
x.x.x.x  0  1/0 3:19:299  1322/1322 11192
x.x.x.x  5  2/1 2:54:209  1238/1220 1251
x.x.x.x  0  1/019:39:339  7817/7817 41623
x.x.x.x 10  0/0   89  1361/1361 16225

It's that last one which keeps resetting every 9 seconds.  Communication 
between the opposing interfaces is fine with no errors that I can see.  I've 
tried disabling RSVP on both sides, but this doesn't resolve the issue when 
it's re-enabled.

What type of situation can cause both neighbors to constantly change their 
sequence number?  RFC3209 shows: 

This value MUST change when the sender is reset, when the node reboots, or 
when communication is lost to the neighboring node and otherwise remains the 
same.

None of those conditions appear to be getting met, so I'm a bit puzzled.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] J series packet mode

[Eric Van Tol]

 The successor for the J series is the ACX series but you need to skip the
 lower end models as for some weird reason they come with E1 interfaces
 stuck on them.

Where did you hear this?  The ACX is purpose-built for mobile backhaul and 
lacks many features that both the J-Series and SRX have for enterprises.  The 
successor to the J-Series is the SRX.  Why Juniper even makes J-Series anymore 
is beyond me, since an SRX in packet mode is essentially the same thing.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper MX104

[Eric Van Tol]

One thing to keep in mind about these boxes is that, like the MX5/10/40/80, the 
built-in 10G ports do not do hierarchical QoS (per-unit scheduling).  I'm 
confused as to why this is, considering they are Trio-based routers, but I 
digress.  I personally don't think that the astronomical cost to enable the 10G 
ports on all the low-end MX routers is worth it, considering they can't even do 
per-unit scheduling.

-evt

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
 joel jaeggli
 Sent: Tuesday, November 12, 2013 4:00 PM
 To: Saku Ytti
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Juniper MX104
 
 
 On Nov 12, 2013, at 12:46 PM, Saku Ytti s...@ytti.fi wrote:
 
  On (2013-11-12 20:14 +), Tom Storey wrote:
 
  Why so much just to enable some ports? How do they come up with that
  kind of price? Pluck it out of thin air?
 
  The hardware has been paid for, and I know thats only list pricing,
  but it still seems ridiculous.
 
  The question might have been rhetoric. But I'll bite.
 
  The BOM on these boxes is nothing, I'm guessing less than 1kUSD. But the
  volume you can sell them also is very very small, so the margins need to
 be
  very high to be able to design and support them.
  Licensing allows you to sell to larger group of people, people who
 normally
  would buy smaller/inferior box, now can afford it,  which in turn allows
 you
  to reduce your margins, making you more competitive.
 
  I actually like it. I wish vendors like Agilent/Ixia, Spirent would sell
  test-kit with some sort of 'per hours used' license. Lot of SPs have need
 for
  proper testing kit, but only will need them very irregularly. And renting
 is
  always such a chore. It's same thing there, BOM is nothing, but volume is
 even
  lower, so prices are ridiculously high, consequently proper testing is
 very
  rarely done by other than telco size SPs.
 
 It's one of those things where you work with account team. if the commercial
 terms don't work out for most potential buyers, then the product won't be
 successful and either things will change or they won't.
 
  --
   ++ytti
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MPLS PEs out in the last-mile

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
 Will Orton
 Sent: Thursday, August 29, 2013 2:28 PM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] MPLS PEs out in the last-mile
 
 Is there some way to have a PE hanging out in the breeze without
 setting it up directly in my IGP? I don't really want last-mile IGP
 churn from hundreds of micro-PEs in my network.

Not sure what type of provider you work for, whether it be this is what you 
get, deal with it or we'll do anything within reason to provide the service 
and win the business against someone larger, but one solution to this exact 
problem that we implemented was Carrier-of-Carriers VPN.  We basically build 
the customer their own L3VPN as though they are a VPN service provider, then 
create L2VPNs within that, either to a corresponding SRX at their other remote 
site, or to a customer logical system on an edge router.  

It may not be pretty and certainly may not be the best way to do this, but it 
works well, prevents the CPE from participating in our IGP, and so far has been 
stable.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Connecting two spanning-tree domains

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
 Johan Borch
 Sent: Tuesday, August 27, 2013 4:57 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Connecting two spanning-tree domains
 
 Hi!
 
 I need to connect two spanning-tree domains, one is running MSTP and one is
 running rapid-pvst. Is this doable? The two networks have different roots
 and it needs to stay like that but I still need redundant links between
 them. I need to transport VLANs from one network to the other and only one
 side support MPLS.
 
 Ideas? :)

Is there any chance you could forgo STP and use something like REP, ERPS, Flex 
Links, or something similar?  All of these would give you the redundancy you 
need, but enable you to disable STP on those links and use something with a 
faster failover rate (sub-50ms).

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mixed Cisco/Juniper MPLS network

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Mark Tinka
 Sent: Thursday, August 15, 2013 12:04 PM
 To: juniper-nsp@puck.nether.net
 Cc: Saku Ytti
 Subject: Re: [j-nsp] Mixed Cisco/Juniper MPLS network
 
 If Cisco had a command that implemented the Junos behaviour,
 e.g,., mpls ldp label allocation loopbacks-only without
 needing to tinker around with filters, I'd be the first one
 to implement it :-).
 
 Mark.

Isn't this what the aforementioned allocate global host-routes command does?  
We do run this command on our ME3600s, but we also do filtering.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Mixed Cisco/Juniper MPLS network

[Eric Van Tol]

Hi all,
We've had MPLS running on our network for years using JUNOS and until only very 
recently, we haven't had to deal with any of our Cisco equipment needing MPLS.  
That changed when we started purchasing ME3600X switches so we could provide 
VPN services in our metro fiber rings.

I'm trying to wrap my head around how other people handle the label filtering 
in Cisco-world.  As you know, JUNOS will only advertise a label for the local 
loopback, but IOS will advertise anything it has a destination to.  Because of 
this, we've had to implement label filtering on the Cisco switches.  While this 
works, it seems kind of cumbersome, especially when we need to add a new 
MPLS-capable device to the network, a prefix-list has to be updated.  If a 
non-MPLS device is added, another prefix-list has to be updated.  

Is this the normal way of doing things, or is there something I am missing?  I 
suppose we could assign a certain range of addresses out of our loopback subnet 
to be used solely for non-MPLS devices, but what happens when one day we need 
to add MPLS capabilities via a license or an entire hardware replacement?

Any ideas or clue-bats upside the head would be appreciated.

THanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Mixed Cisco/Juniper MPLS network

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Saku Ytti
 Sent: Wednesday, August 14, 2013 12:34 PM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Mixed Cisco/Juniper MPLS network
 
 I'd only use separate blocks if I specifically have next-hops which MUST
 NOT be label switched (I don't have, but some prefer INET not to be label
 switched, so they run INET to different loopback than VPNv4)
 In your case, it seems it would make more sense to figure out what the
 actual problem is and then go back to flat/static ACL for all core loops.
 
 Maybe add one less used non-MPLS box as allowed and reserve some
 additional
 resourced to help troubleshooting when problem is in effect.

So what you're saying is that there is definitely some other issue here and 
it's not necessarily the fact that the destinations are allocated labels, but 
rather the label allocation is exposing an underlying problem.  If so, that 
narrows it down and points me in the right direction.  I'm trying to replicate 
in the lab, as I just had an idea, thanks to your response.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Getting High Latency and Slow browsing Issue in Juniper M7i with RE-850

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Abdullah Al Faruque Mullick
 Sent: Friday, June 14, 2013 10:56 AM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Getting High Latency and Slow browsing Issue in
 Juniper M7i with RE-850
 
 Hi
 
 
 Can anyone help me to sort out the issue or could tell me how to proceeds
 or how much traffic can m7i handle
 
 
 Please help me as I not getting anything wrong in M7i but in peak we are
 getting high latency and slow browsing issue
 
 Thanks in advanced...

While it's somewhat difficult to work out how much bandwidth each port is 
forwarding, due to the message formatting, you should be aware that the 4-port 
IQ2 PIC is oversubscribed 4:1.  You can only get a total of 1Gb/s full-duplex 
through that PIC, so if one is receiving 450Mb/s, another is receiving 350Mb/s 
and another is receiving 450Mb/s, you are way oversubscribed on that PIC.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX Reliability

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
 Of Andrew Gabriel
 Sent: Wednesday, June 12, 2013 8:41 AM
 To: juniper-nsp; Phil Mayers
 Subject: Re: [j-nsp] SRX Reliability
 Hi Phil,
 
 Thanks, we are mainly looking at basic FW, VPN, and routing capability,
 which we need to be rock solid. We do not intend to use the IPS and UTM
 type features at the moment.
 
 Thanks,
 -Andrew.

We started using the SRX for security both on our critical DNS/mail 
infrastructure, as well as our voice infrastructure over the past year.  We've 
been very happy with it.  We've got a clustered pair of SRX3600s, as well as a 
few clustered pairs of SRX240s and SRX210s.  We're in a similar boat as you - 
we just need firewalling (v4/v6), VPN, and routing (v4/v6 ISIS/BGP).  

We have yet to have an issue with them in terms of major bugs or hardware 
failures.  Getting the IPSec VPN to work with our ASAs was challenging, but we 
got it worked out.  We've also had to perform work before on the links and 
devices that connect to our clusters and the manual failover has always been 
seamless.

And if you're into using a GUI to configure devices, the J-Web is nice, only 
for the fact that you don't need to install some extra app on your computer 
just to configure the firewall.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] DOM support for OEM optics

[Eric Van Tol]

 I have started collecting information regarding DOM support for 3rd party
 optics.
 I am primarily interested in support for MX and EX series.
 Brief search of list did not reveal much information.

We've had good luck with SolidOptics in both MX and EX, both the Juniper-coded 
and Cisco-coded 1G and 10G SFP, SFP+, XFP.

Same with MRV - BiDi SFP, SFP, SFP+, XFP

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX960 Error Message - MPC2

[Eric Van Tol]

Hi all,
Has anyone ever experienced this error message on MX960 with a single DPC-E and 
a single MPC2-3D?  The MPC has a single MIC in it, a MIC-3D-4XGE-XFP.  The DPCE 
is a DPCE-R-20GE-2XGE.  JUNOS version 10.4R8.5.  The configuration that causes 
the issue appears to be a VLAN-bundled logical interface for MPLS transport 
across the network.

Mar 25 10:19:16  fpc1 trinity_insert_ifl_channel ifl 134 NOENT
Mar 25 10:19:16  fpc1 jnh_ifl_topo_handler_pfe: Failed to insert L2PD channel 
for ifl 134

I don't seem to be getting anywhere with JTAC after a week of back-and-forth.

thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MX80 port numbering

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Skeeve Stevens
 Sent: Friday, March 15, 2013 7:56 AM
 To: Juniper NSP
 Subject: Re: [j-nsp] MX80 port numbering
 
 This is so funny... I am exactly the same... I'm like 'umm... '
 trying
 to find what I'm looking for each time.
 
 ...Skeeve

Lol.  Figuring out port assignments shouldn't be like re-living Advanced 
Calculus in high school.

Thanks to the poster who provided the KB article, that was really helpful.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] VLAN bundles in CCC

[Eric Van Tol]

 -Original Message-
 From: Alex Arseniev [mailto:alex.arsen...@gmail.com]
 Sent: Wednesday, March 13, 2013 11:05 AM
 To: Eric Van Tol; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] VLAN bundles in CCC
 
 2 things:
 1/ add family ccc under ge-1/2/0.2
 2/ add encapsulation ethernet under l2circuit neighbor config.
 Default encaps when You use tagged units is ethernet-vlan and with
 ethernet-vlan the L2circuit actually checks if VLAN ids are same on
 both
 ends. With encapsulation ethernet this check is not done.
 HTH
 Thanks
 Alex

Thanks, Alex, but that didn't do it.  I still see the l2circuit as 'up', but 
still no traffic between the two:

Neighbor: 10.0.0.2 
Interface Type  St Time last up  # Up trans
ge-1/2/0.2(vc 2)  rmt   Up Mar 12 19:40:05 2013   1
  Remote PE: 10.0.0.2, Negotiated control-word: No
  Incoming label: 299792, Outgoing label: 299792
  Negotiated PW status TLV: No
  Local interface: ge-1/2/0.2, Status: Up, Encapsulation: ETHERNET

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX upgrade procedure -ready for enterprise?

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Mark Menzies
 Sent: Friday, March 08, 2013 1:03 PM
 To: Andy Litzinger
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] SRX upgrade procedure -ready for enterprise?
 
 The best approach, which does NOT include minimal downtime is to
 upgrade
 both nodes and then reboot them both at the same time.  Its less
 complicated, less prone to error but it does mean that the services
 are
 down for the time it takes for the boxes to boot and bring up all
 interfaces.

I've thought about this a lot lately. At what point do the two nodes start 
communicating with each other after a reboot? What I'm getting at is, could you 
upgrade both, reboot one node, then right before it comes back online fully, 
reboot the other one?  This way, you're not waiting around a full reboot cycle 
for service to return.  

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] large subnet/no memory

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Phil Shafer
 Sent: Monday, February 11, 2013 2:40 PM
 To: The Drifter
 Cc: Juniper TAC
 Subject: Re: [j-nsp] large subnet/no memory
 
 The Drifter writes:
 Sounds great. Now need to get a buy-in from  the ops folks :)
 How would you weigh the effectiveness of using your suggestion
 versus Cristian's?
 
 The prefix-limit statement is much simpler and more efficient for
 the specific case that it is targeting.  In contrast, commit scripts
 allow a broader range of tests and abilities, but require more work
 (writing the script, deploying it, configuring it).  If you see
 this as being an isolated instance, the prefix-limit will be the
 simpler solution.   If you see yourself defining a larger set of
 rules that all configurations should follow (sanity checks,
 co-constraints, mandatory statements, derived configuration, etc),
 then this may be your first step toward commit scripts.
 

Someone please correct me if I'm wrong, but I read this as the OP asking about 
a bad mask on what I assume to be an ethernet interface, not a BGP 
configuration.  As such, I'm not sure what good a prefix-limit would do in this 
case.  The commit script seems to be the best option, IMO.

I know that JUNOS used to throw up an error when the same or overlapping 
subnets were configured on two different interfaces in a routing instance (in 
this case, 'default'), but I'm not sure whatever happened to those errors.  I 
personally liked them because it was easy to spot fat-finger or accidental 
double-allocation mistakes.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Quick way to delete multiple licenses on SRX

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Mark Menzies
 Sent: Friday, February 01, 2013 7:04 AM
 To: Eugeniu Patrascu
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Quick way to delete multiple licenses on SRX
 
 If we park the fact that this is for training courses here, I still
 need an
 answer to how I would do this on an SRX.  :)  So the problem exists
 and am
 just looking to see if we can find an answer.
 

Does the *shudder* web GUI offer a way to do this?

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] MAG2600 versus 4610 and above

[Eric Van Tol]

Your post almost gave me a heart attack, as we just purchased two of these 
specifically for UAC.  Our Juniper reps were about to get an earful from me.  
:-)

-evt

From: Mark Menzies [mailto:m...@deimark.net]
Sent: Thursday, January 31, 2013 9:09 AM
To: Eric Van Tol
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] MAG2600 versus 4610 and above

Ahh, nice one.  I didnt realise that the 2600 was upgraded  :)
This is the kind of thing that Juniper need to be making more noise about as 
some of our customers would definitely like this.  :)

On 31 January 2013 13:06, Eric Van Tol 
e...@atlantech.netmailto:e...@atlantech.net wrote:
 -Original Message-
 From: 
 juniper-nsp-boun...@puck.nether.netmailto:juniper-nsp-boun...@puck.nether.net
  [mailto:juniper-nsp-mailto:juniper-nsp-
 boun...@puck.nether.netmailto:boun...@puck.nether.net] On Behalf Of Mark 
 Menzies
 Sent: Thursday, January 31, 2013 7:14 AM
 To: David Gee
 Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] MAG2600 versus 4610 and above

 MAG2600 is only SSL or Enterprise guest access.  It doesn't do UAC.

 Its only from the MAG4600 and up do we see the full blown UAC
 personality
 switching there.

The MAG2600 does support UAC:

http://www.juniper.net/techpubs/software/ive/releasenotes/j-sa-sslvpn-7.2R1-whatsnew.pdf

-evt

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX Switch Question

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Paul Stewart
 Sent: Thursday, January 10, 2013 9:23 AM
 To: 'Per Granath'; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] EX Switch Question
 
 Thanks but this is pure layer2 deployments (typically).  I should
 have
 clarified that some of the VLAN's have IP but most are to link
 buildings
 together within a metro etc
 
 Really, this is more of a metro ethernet type of environment.
 

I personally would not use the EX series in a metro ethernet deployment, as 
that's not where they are positioned to be.  Perhaps the MX80 would work?  You 
can get 40 ports of copper (using SFPs) into a single box, with both 
shaping/policing on a per-port/per-vlan basis.  I don't think you can do this 
with an MX80-48T, though.  The other option would be an MX240 with -X-Q or 
3D-Q/EQ modules, but those can get rather expensive.

Honestly, if you're looking for metro ethernet switches, I'd continue on with 
Cisco, primarily due to price compared with the MX80, and features specifically 
positioned for Metro-E compared with the EX series.  ME3600 and ME3800 seem to 
be great switches with tons of features.  This is an area where I think Juniper 
really needs to catch up on (vlan translation, swapping, QoS, MPLS, REP, etc.).

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper equivalent to Cisco 3800X

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Riccardo S
 Sent: Wednesday, January 02, 2013 9:04 AM
 To: jackson@gmail.com
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Juniper equivalent to Cisco 3800X
 
 
 Hi Tim
 indeed was Cisco directly telling me to use C3800X but I guess I know
 why
 
 I was thinking to EX4200 or EX4550...
 MPLS is not needed.
 
 Cisco 3400E has only 10/100 24 ports and 2 combo as far as I know...
 
 Ric

That is correct.  Make sure that if you are looking at the EX, you get a quote 
for the Advanced License, which seems to be required if you want to route 
multicast.  If you mean full routing tables when you say Full BGP Support, 
then the EX is not going to cut it.  I believe the next step up, if you require 
full tables, is the MX80 or one of its enterprise-level variants (MX5, MX10, 
etc.).  If you don't require MPLS, I question the reasoning behind the ME3800 
recommendation from Cisco - why not the 3750X? 

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper equivalent to Cisco 3800X

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Riccardo S
 Sent: Wednesday, January 02, 2013 9:36 AM
 To: je...@atlantech.net
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Juniper equivalent to Cisco 3800X
 
 Hi Eric
 I guess 3750X could be an option.
 
 By the way the use needed by this machine is a ethernet customer
 aggregator (hence many eth ports) with the need of BGP/PIM sessions
 for mcast redistribution from the core (hence needs of BGP/PIM but no
 MPLS).
 
 I know EX4200 can support up to 128 BGP sessions, no matter about
 routing table dimension since is less than 1k.
 
 Do you know how many BGP peers are supported by 3750X ?
 

Unfortunately, I do not.  There may be other differences between the two which 
is why they were pushing the ME3800X, such as buffer space or other QoS related 
differences.  Perhaps it was a positioning issue, but if that's the case, why 
not the ME3600X?  Given just the birds eye view of what you need, it sounds 
like the ME3600X, ME3800X, EX3200, and EX4200 would all work and it really 
depends on the more specific features and functions you would need, as well as 
your budget.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SNMPv3 with v2c support

[Eric Van Tol]

Hi all,
I'm trying to get SNMPv3 configured with v2c (polling only, no traps) support 
for a legacy NMS and I am obviously doing something wrong.  I know it's 
something stupid, but I'm not sure what.  Could someone look at my config below 
and slap me with a clue bat?  Thanks in advance.

-evt

~
usm {
local-engine {
user user1 {
authentication-sha {
authentication-key xx; ## SECRET-DATA
}
privacy-aes128 {
privacy-key xxx; ## SECRET-DATA
}
}
}
}
vacm {
security-to-group {
security-model usm {
security-name user1 {
group all-mibs-group;
}
}
security-model v2c {
security-name legacy1 {
group all-mibs-group-v2c;
}
}
}
access {
group all-mibs-group {
default-context-prefix {
security-model usm {
security-level privacy {
read-view all-mibs;
}
}
}
}
group all-mibs-group-v2c {
default-context-prefix {
security-model v2c {
security-level none {
read-view all-mibs;
}
}
}
}
}
}
target-address ta-host1 {
address 192.168.225.22;
address-mask 255.255.255.255;
target-parameters tp-legacy;
}
target-parameters tp-legacy {
parameters {
message-processing-model v2c;
security-model v2c;
security-level none;
security-name legacy1;
}
}
snmp-community index1 {
community-name xxx; ## SECRET-DATA
security-name legacy1;
tag ta-host1;
}

[snmp]
view all-mibs {
oid .1;
}

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX240H Cluster SNMP

[Eric Van Tol]

 -Original Message-
 From: Mikkel Mondrup Kristensen [mailto:m...@one.com]
 Sent: Monday, August 20, 2012 7:00 PM
 To: Eric Van Tol
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] SRX240H Cluster  SNMP
 
 Hi Eric,
 
 I had the same issue on my srx240 cluster and a friendly soul found
 PR800735 for me that mentioned a workaround by doing set snmp
 filter-interfaces interfaces gr-0/0/0 that made my Observium
 instance able to poll the cluster without timeouts.
 
 /Mikkel

Mikkel,
You are my hero.  That worked, thanks!

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX240H Cluster SNMP

[Eric Van Tol]

All,
Is there a version above 11.2 where SNMP works properly in a cluster?  Seems 
that when running various versions (11.2R7.4 and 11.4R4.4, so far) on a 240H 
cluster, SNMP doesn't work properly and starts spitting out 'noSuchObject' 
errors on perfectly valid queries like when querying the interfaces MIB.  I 
should also mention that the OIDs it seems to have a problem with are primarily 
ones that have to do with the backup chassis in redundancy-group 0 (ge-5/0/0 
through ge-5/0/15).  JTAC has thus far been unsuccessful at assisting me.

I have downgraded to 10.4R10.7 on a non-production cluster and it's working 
successfully, but I really want to take advantage of the global address book.  
I can certainly live without it, but it does make things much easier.

Thanks in advance,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] SRX240H Cluster SNMP

[Eric Van Tol]

Hi Wayne,
Answers inline.

 I doubt it matters, but I'm polling the devices through their
 loopback
 interfaces.  I also filter out some of the interfaces and filter
 duplicates:

I do the same thing.  Just for the Hell of it, I tried to poll through the fxp0 
port, but the same thing happens.

 Does it seem to happen the most when there are lots of queries going
 through?  

The issue is really just trying add the device to my NMS.  The NMS sends out 
Get requests for all the interfaces to add them into its database.  I have no 
problems doing this for a 3600 cluster or really any other Juniper devices.  

 Any signs of trouble on your control or fabric interfaces?

Not that I can tell.  No errors or drops.

 Has JTAC already had you enable tracing for SNMP?

They made me get a capture of the queries, which I sent to them, but because 
the SRX was sending get-response packets back, that seemed to indicate to the 
JTAC engineer that there was no problem.  What he didn't do was actually look 
at the responses where the SRX is sending 'noSuchObject' back for valid 
interface objects.  Performing a 'show snmp mib walk oid' for one of the OIDs 
for which a 'noSuchObject' was sent elicits an incredibly slow response time 
from the CLI with an eventual output of the information contained within that 
OID.

Maybe I'll try 11.2R6 and see if that version works.  The SRX3600 cluster is 
running 11.2R7.4 and I'm not seeing the same problems.  It's specifically 
related to the SRX240, from what I can tell, as both the production cluster and 
the lab cluster exhibit the same behavior.

-evt

 :w
 
 
 
 On Mon, Aug 20, 2012 at 8:51 AM, Eric Van Tol e...@atlantech.net
 wrote:
  All,
  Is there a version above 11.2 where SNMP works properly in a
 cluster?  Seems that when running various versions (11.2R7.4 and
 11.4R4.4, so far) on a 240H cluster, SNMP doesn't work properly and
 starts spitting out 'noSuchObject' errors on perfectly valid queries
 like when querying the interfaces MIB.  I should also mention that
 the OIDs it seems to have a problem with are primarily ones that have
 to do with the backup chassis in redundancy-group 0 (ge-5/0/0 through
 ge-5/0/15).  JTAC has thus far been unsuccessful at assisting me.
 
  I have downgraded to 10.4R10.7 on a non-production cluster and it's
 working successfully, but I really want to take advantage of the
 global address book.  I can certainly live without it, but it does
 make things much easier.
 
  Thanks in advance,
  evt
 
  ___
  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] SRX3600 port mirroring

[Eric Van Tol]

Hi all,
Does anyone know if port mirroring is supported on the SRX3600 and if so, what 
are the caveats?  Can I support two different analyzers?  Finding information 
on this is sparse, which leads me to believe that it's not supported.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] MX80 SNMP stats on 10.4R8.9

[Eric Van Tol]

Hi all,
Is anyone having issues with 10.4R8.9 reporting weird results for the 64-bit 
interface traffic counters?  We have some Gig subinterfaces that are shaped at 
low rates like 10Mb/s or 3Mb/s and we're seeing spikes on our NMS graphs of 
over 100Mb/s at various times.  I know this version of JUNOS is no longer 
recommended for the MX, but it's been stable for us on several MX240s and 
MX80s.  I'd prefer not to upgrade if I don't *have* to, only to find out that 
R9 is also having SNMP problems.

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Logical tunnel encapsulation

[Eric Van Tol]

 -Original Message-
 From: Rafael Rodriguez [mailto:packetjoc...@gmail.com]
 Sent: Friday, December 23, 2011 4:37 PM
 To: Eric Van Tol
 Cc: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Logical tunnel encapsulation
 
 If my memory is correct, 11.x supports IPv6 with lt.
 
 Sent from my iPhone
 

Thanks to all for the responses.  I'd hate to have to upgrade to 11.x just for 
this.  Anyone have a suggestion for a stable version of 11.x?  My only foray 
into this version on MX caused me to downgrade because of an snmpd bug.

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Logical tunnel encapsulation

[Eric Van Tol]

Hi all,
Is frame-relay encapsulation not supported on the MX80 logical tunnel 
interfaces?  I'm on 10.4R8.5 and need to configure IPv6 on an lt- interface:

Interface on the default instance:

# show interfaces lt-0/0/10 
unit 1 {
encapsulation frame-relay;
dlci 128;
peer-unit 1;
family inet {
address 192.168.209.201/30;
}
family inet6 {
address 2001:db8::d1c9/64;
}
}
Interface on my logical-system:

# show interfaces lt-0/0/10 
unit 1 {
encapsulation frame-relay;
dlci 128;
peer-unit 0;
family inet {
address 192.168.209.202/30;
}
family inet6 {
address 2001:db8::d1ca/64;
}
}

Interface shows 'up' and no flags are set to indicate a problem.  However, 
pinging doesn't work and this shows up in my logs:

Dec 23 07:57:12  r1 tfeb0 HALP-trinity_nh_ucast_installnh(690) encaps-install 
failed: unsupported option
Dec 23 07:57:12  r1 tfeb0 Failed to create platform state, unsupported option
Dec 23 07:57:12  r1 /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP) failed, err 1 
(Unknown) peer_class 0, peer_index 0 peer_type 17
Dec 23 07:57:12  r1 /kernel: RT_PFE: NH details: idx 690 type 2 ifl 80
Dec 23 07:57:12  r1 tfeb0 Failed to install in platform, unsupported option
Dec 23 07:57:12  r1 tfeb0 Type specific Add failed unsupported option nh-id:690
Dec 23 07:57:12  r1 /kernel: RT_PFE: NH IPC op 2 (CHANGE NEXTHOP) failed, err 1 
(Unknown) peer_class 0, peer_index 0 peer_type 17
Dec 23 07:57:12  r1 l2cp[1186]: Read acess profile () config
Dec 23 07:57:12  r1 /kernel: RT_PFE: NH IPC op 1 (ADD NEXTHOP) failed, err 1 
(Unknown) peer_class 0, peer_index 0 peer_type 17
Dec 23 07:57:12  r1 /kernel: RT_PFE: NH details: idx 692 type 2 ifl 81
Dec 23 07:57:13  r1 tfeb0 HALP-trinity_nh_ucast_installnh(690) encaps-install 
failed: unsupported option
Dec 23 07:57:13  r1 tfeb0 Failed to create platform state, unsupported option
Dec 23 07:57:13  r1 tfeb0 Failed to install in platform, unsupported option
Dec 23 07:57:13  r1 tfeb0 Type specific Add failed unsupported option nh-id:690
Dec 23 07:57:13  r1 tfeb0 Failed to instantiate new copy for NH(690)
Dec 23 07:57:13  r1 tfeb0 Failed to change state
Dec 23 07:57:13  r1 tfeb0 HALP-trinity_nh_ucast_installnh(692) encaps-install 
failed: unsupported option
Dec 23 07:57:14  r1 tfeb0 Failed to create platform state, unsupported option
Dec 23 07:57:14  r1 tfeb0 Failed to install in platform, unsupported option
Dec 23 07:57:14  r1 tfeb0 Type specific Add failed unsupported option nh-id:692

Also, this all works if I remove 'family inet6' and change encapsulation to 
'ethernet'.

If frame-relay encapsulation isn't supported, how does one use IPv6 on the lt- 
interfaces?  

Thanks in advance,
evt

___
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?

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Phil Mayers
 Sent: Tuesday, November 29, 2011 7:38 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Does a L3VPN RR require routing-instance for each
 VRF?
 
 As per subject line: if we want to use a JunOS box (M7i, running
 10.4)
 as a route-reflector, it seems to reject inet-vpn routes with:
 
 bgp_rcv_nlri: 129.x.x.0:4:193.x.x.0/92 rejected due to the lack of a
 valid target community
 
 I was hoping we could avoid the hassle of defining the VRF on the RRs
 if
 possible, but I guess that is required - am I missing some obvious /
 subtle point why that is the case, or some way of making it work?

Basic question - I'm assuming that you have cluster x.x.x.x configured under 
the BGP group or individual BGP neighbor?  This is the only reason I could see 
this occurring, is if you were missing the cluster statement, or it was being 
overridden by something else.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] SRX Chassis Clustering and MPLS

[Eric Van Tol]

Hi all,
With chassis clustering enabled on a pair of SRX240s, is MPLS packet-based 
possible, using Selective Stateless Packet Based forwarding?  I can't seem to 
be able to find a full list of actual unsupported features once chassis 
clustering is enabled.

TIA,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Juniper-MX-960-Using the same Ge-Port as L2 and L3 !

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of vaibhava varma
 Sent: Friday, September 23, 2011 7:30 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] Juniper-MX-960-Using the same Ge-Port as L2 and L3 !
 
 Dear All
 
 Is there is a possibility in Juniper MX-960 to configure the same
 Physical Port to support L2 Bridging ie Trunk Link and also configure
 same time for L3 Routing ie Sub-interfaces.
 
 It would look something like this as listed below
 
 {master}[edit]
 root@Junos# set interfaces ae1 unit 0 family ethernet-switching port-
 mode trunk
 root@JUnos# set interfaces ae1 unit 0 family ethernet-switching vlan
 members [ 71-73 573 ]
 root@JUnos#set interfaces ae1 unit 79 vlan-id 79 family inet address
 1.1.1.1/30

Not sure about AE interfaces, but you can do this with physical interfaces:

ge-0/0/5 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
family bridge {
interface-mode trunk;
vlan-id-list [ 130 131 ];
}
}
unit 32 {
vlan-id 32;
family inet {
address 192.168.54.2/30;
}
}
unit 210 {
vlan-id 210;
family inet {
address 192.168.54.177/30;
}
}
}

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] snmp count for arp policer?

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Clarke Morledge
 Sent: Tuesday, July 12, 2011 11:07 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] snmp count for arp policer?
 
 On an IP interface (on a router like the MX), you can configure
 filters to
 count different types of IP packets.  But there does not appear to be
 a
 way to count ARP packets, since they do not have an IP header.
 
 I would like to be able to have some type of ARP packet counter per
 interface that I can query with SNMP, just like you would with the IP
 counters via filters that can be programmed into the router hardware.
 
 The closest thing I can find that might do it is using an ARP
 policer.
 Unfortunately, this will only catch packets that hit some limit on
 your
 policer.   This is better than nothing, but not great.   From the
 CLI, you
 can look at the number of hits on the __default_arp_policer__, which
 I
 assume will get superceded by any interface specific ARP policer.  In
 this
 context, the show policer output via the CLI is helpful:

I have run into the same issue.  I'm using an M7i and some Ethernet 
subinterfaces are hitting the default ARP policer.  I configured a more sane 
policer and I'd like to track which interfaces this is happening on, but there 
doesn't seem to be a way to do it through SNMP.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN Active Route Selection

[Eric Van Tol]

 -Original Message-
 From: Stacy W. Smith [mailto:st...@acm.org]
 Sent: Monday, June 27, 2011 12:34 PM
 To: Eric Van Tol
 Cc: 'Juniper-Nsp'
 Subject: Re: [j-nsp] L2VPN Active Route Selection
 
 Do you have anything configured under [edit protocols bgp path-
 selection]? Specifically, do you happen to have cisco-non-
 deterministic configured?
 
 --Stacy

No, I do not.  The BGP config on the PE is pretty bare - no options besides the 
family:

admin@lab.router# show protocols bgp | display inheritance 
local-address 10.18.20.46;
group 65000-dr {
type internal;
family inet {
unicast;
}
family inet-vpn {
unicast;
}
family l2vpn {
signaling;
}
export ibgp-car_to_dr;
peer-as 7784;
neighbor 10.18.20.72;
neighbor 10.18.20.73;
}
group 65000-vpn {
type internal;
family inet-vpn {   
unicast;
}
family l2vpn {
signaling;
}
neighbor 10.18.20.10;
}

I thought about configuring 'bgp-always-compare-med' or 
'cisco-non-deterministic', but figured it would be pointless, because the MEDs 
are all equal, and thus, the options wouldn't have any effect.

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ISIS traceoptions

[Eric Van Tol]

Hi all,
I'm wondering what, if any, interaction the 'traceoptions' for ISIS has with 
the running protocol on the router.  I've troubleshot two odd problems in ISIS 
in the past six months that were miraculously fixed simply by enabling 
traceoptions.  The first time, I thought that it was merely a coincidence, but 
this second time, I see that it had a definite effect, as no other changes were 
made.

Has anyone experienced something similar, where turning on traceoptions just 
fixes your problem?

Running 9.6R3.8 on MX.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX2200 series and q-in-q (802.1ad)

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Stephane JAUNE
 Sent: Wednesday, February 02, 2011 10:50 AM
 To: 'Juniper-Nsp'
 Subject: [j-nsp] EX2200 series and q-in-q (802.1ad)
 
 
   Hi all,
 
   Does somebody know if EX2200 series support q-in-q ? we would
 like to use some of them to tag customer traffic with a S-VLAN, and I
 only found that 802.1Q is supported.
 
 
   Regards.

Q-in-Q is now supported in 11.1, if you're that brave to use it.  Haven't 
tested it out yet to see what features are really available, but release notes 
indicate that it's supported.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] M7i

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of cjwstudios
 Sent: Thursday, March 24, 2011 2:50 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] M7i
 
 Hello Juniper folks :)
 
 I'm setting up a remote metro ethernet site (fiber in a closet) that
 will have 2 x 100mb BGP transit feeds and a smattering of IGP feeds.
 The traffic will be service provider transit without inspection, NAT
 or other services.
 
 Since everything is cost sensitive these days I initially planned on
 implementing an ebayish 7206vxr-npe-g1.  Although I was quite happily
 slinging the 7206 around 10 years ago I realized tonight that it has
 been 10 years and the 7206 platform is well aged.   M7i (M7i 2AC 2FE
 w/ RE400,PE-1GE-SFP) are quite common on the secondary market now and
 likely more than enough to get started.  Although trunking multiple
 metro FE feeds to a single GE port will be frowned upon I may
 consider
 this as an option.
 
 I suppose my questions are whether a base M7i config out of the box
 will support this application or if there are better options out
 there.  Thank you in advance.

If your network is all ethernet and you don't plan on doing any TDM/SONET any 
time soon, I would look at the new MX80 bundles.  With the right discount from 
your sales team, you can get an MX80 with 20 1G SFP-based ports for less than 
$20K.  The MX80 has full internet route capabilities, 4 built-in 10G ports 
(although on the MX80-5G, they are restricted, meaning you can't use them 
;-)), and a restricted extra MIC slot.  All these restricted options are 
enabled by a simple license purchase.  The jury is still out on whether said 
restrictions are actually enforced, though - anyone have any experience with 
this?

The main problem with the M7i you listed is that the PE-1GE-SFP does not have 
per-VLAN queuing, which is becoming increasingly important in today's metro 
ethernet networks.  The MX80 SFP ports also support 100M SFPs.  You'd be much 
better off getting the MX80 than an M7i, if only for future-proofing your 
network.  Yes, the M7i may be cheap on the secondary market, but if you plan on 
having this in production and getting software updates, you'll have to have it 
recertified by Juniper, which is something that can become quite costly.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] ERP Question

[Eric Van Tol]

Hi all,
Probably a dumb question, but when configuring Ethernet Ring Protection, do all 
nodes on the ring need to support ERP? 

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX2200 series and q-in-q (802.1ad)

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Stephane JAUNE
 Sent: Wednesday, February 02, 2011 10:50 AM
 To: 'Juniper-Nsp'
 Subject: [j-nsp] EX2200 series and q-in-q (802.1ad)
 
 
   Hi all,
 
   Does somebody know if EX2200 series support q-in-q ? we would
 like to use some of them to tag customer traffic with a S-VLAN, and I
 only found that 802.1Q is supported.
 
 

Sorry, not supported:

blah {
##
## Warning: statement ignored: unsupported platform (ex2200-24t-4g)
##
dot1q-tunneling;
}

The EX2200 supports very little beyond basic layer 2 services and static 
routing.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] L2VPN CoS

[Eric Van Tol]

Hi all,
Probably a stupid question, but if I have an Ethernet-to-Ethernet or 
TDM-to-Ethernet P2P L2VPN, is there a way to classify the layer 3 traffic 
contained within it and schedule/queue based upon that traffic?  For instance, 
customer is running some voice across their L2VPN and they want to give strict 
priority to that traffic - is that possible?  I've been messing around some 
with the EXP rewrite rules and have yet to come up with a configuration that 
will rewrite the EXP bit using DSCP values.  My feeling is that it isn't going 
to work, because it's L2, after all, and I will be stuck with 802.1p values to 
work with, which won't really work for me.

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN CoS

[Eric Van Tol]

It's my understanding (which may be wrong entirely), that 802.1p is only set 
when 802.1q VLAN encapsulation is being used.  In this setup, while there are 
two VLANs on the customer side, they are being terminated on the CPE and they 
connect to the L2VPN via a single VLAN, untagged to an Ethernet over Copper L2 
CPE to the transport provider.  Basically, all their traffic is sent to us over 
a single tagged VLAN.

From: Herro91 [mailto:herr...@gmail.com]
Sent: Tuesday, October 26, 2010 10:30 AM
To: Eric Van Tol
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] L2VPN CoS

Hi,

If memory serves on the ethernet side you would need something to classify on, 
802.1p bits in vlan header. Is that not an option?

On the TDM side, similarly you need something to classify on. If it was 
frame-relay encap you have some options - DLCI, etc
On Tue, Oct 26, 2010 at 9:34 AM, Eric Van Tol 
e...@atlantech.netmailto:e...@atlantech.net wrote:
Hi all,
Probably a stupid question, but if I have an Ethernet-to-Ethernet or 
TDM-to-Ethernet P2P L2VPN, is there a way to classify the layer 3 traffic 
contained within it and schedule/queue based upon that traffic?  For instance, 
customer is running some voice across their L2VPN and they want to give strict 
priority to that traffic - is that possible?  I've been messing around some 
with the EXP rewrite rules and have yet to come up with a configuration that 
will rewrite the EXP bit using DSCP values.  My feeling is that it isn't going 
to work, because it's L2, after all, and I will be stuck with 802.1p values to 
work with, which won't really work for me.

Thanks,
evt

___
juniper-nsp mailing list 
juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] router recommendation

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Giuliano Cardozo Medalha
 Sent: Thursday, October 14, 2010 8:41 PM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] router recommendation
 
   MX80 - 40 Gbps (48 x 10/100/1000 + 4 x 10G XFP) 65 Mpps  ... don´t
 forget to buy routing license.
 
 M7i - 5 Gbps Full Duplex (with 4 Ethernet PIC and 1 FIC) - 16 Mpps ...
 there is a special bundle in list price M7i-5GE-RE850-US-B

This M7i bundle will not accomplish what the OP wants.  The 4-port GE PIC that 
comes in this bundle is a 4:1 oversubscribed PIC that can only push 1Gb/s among 
all 4 ports at one time.

MX80 is definitely the way to go.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] L2VPN MTU Issue

[Eric Van Tol]

Hi all,
I'm having an issue with an L2VPN customer at the moment. They need to be able 
to pass 1500-byte IP packets between two locations connected via an ethernet 
encapsulated L2VPN.  I am able to ping from PE to PE with 1500-byte sized 
packets with the df-bit set without a problem.  The L2VPN connection is up and 
the customer can get a max of 1490-bytes through without fragmentation.  My LSP 
shows an MTU of 1500:

x.x.x.47
  From: x.x.x.46, LSPstate: Up, ActiveRoute: 0
  LSPname: xx_to_nn, LSPpath: Primary
  Suggested label received: -, Suggested label sent: -
  Recovery label received: -, Recovery label sent: 302048
  Resv style: 1 FF, Label in: -, Label out: 302048
  Time left:-, Since: Tue Sep 28 12:35:29 2010
  Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500
  Port number: sender 5 receiver 19901 protocol 0
  PATH rcvfrom: localclient 
  Adspec: sent MTU 1500
  Path MTU: received 1500
  PATH sentto: x.x.x.131 (ge-1/3/0.0) 217 pkts
  RESV rcvfrom: x.x.x.131 (ge-1/3/0.0) 215 pkts
  Explct route: x.x.x.131 x.x.x.121 x.x.x.5 x.x.x.58 x.x.x.164 
  Record route: self x.x.x.131 x.x.x.121 x.x.x.5 x.x.x.58 x.x.x.164  
Total 2 displayed, Up 2, Down 0

All interfaces *between* the PEs have the following config: IP MTU = 1500, MPLS 
MTU = 1512.  I have verified that the customer can hit their respective site's 
PE with 1500-byte packets by temporarily configuring each customer-facing 
interface with an appropriate IP address and pinging.

Here's the pertinent configs of the two PEs:

Side A:

interfaces {
ge-0/0/1 {
description Site A;
enable;
mtu 9192;
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
}
protocols {
rsvp {
interface ge-0/0/0.0;
}
mpls {
label-switched-path xx_to_nn {
to x.x.x.46;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
ldp {
interface ge-0/0/0.0;
}
}
routing-instances {
cid-A {
instance-type l2vpn;
interface ge-0/0/1.0;
route-distinguisher x.x.x:3211;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
protocols {
l2vpn {
encapsulation-type ethernet;
no-control-word;
interface ge-0/0/1.0;
site Side-A {
site-identifier 1;
interface ge-0/0/1.0 {
remote-site-id 2;
}
}
}
}
}
}


Side B:
interfaces {
fe-0/2/1 {
description Site B;
enable;
mtu 9192;
encapsulation ethernet-ccc;
unit 0 {
family ccc;
}
}
}
protocols {
rsvp {
interface ge-1/3/0.0;
}
mpls {
label-switched-path nn_to_xx {
to x.x.x.47;
}
interface ge-1/3/0.0;
interface fe-0/2/1.0;
}
ldp {
interface ge-1/3/0.0;
}
}
routing-instances {
cid-A {
instance-type l2vpn;
interface fe-0/2/1.0;
route-distinguisher x.x.x:3211;
vrf-import vpn-A-import;
vrf-export vpn-A-export;
protocols {
l2vpn {
encapsulation-type ethernet;
no-control-word;
interface fe-0/2/1.0;
site Side-A {
site-identifier 1;
interface fe-0/2/1.0 {
remote-site-id 2;
}
}
}
}
}
}

Does anyone see a problem with my configs here?  I seem to be losing 10 bytes 
somewhere and it's driving me mad. 

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN MTU Issue

[Eric Van Tol]

 -Original Message-
 From: Diogo Montagner [mailto:diogo.montag...@gmail.com]
 Sent: Wednesday, September 29, 2010 6:51 AM
 To: Eric Van Tol; juniper-nsp
 Subject: Re: [j-nsp] L2VPN MTU Issue
 
 Hi Eric,
 
 Can you check the mtu negotiated by the l2vpn ? (Use traceoptions)
 
 What kind of pic are you using ? And what is the platform ?
 
 Tks
 

One side is an M7i and the other side is a J2320.  Enabling traceoptions and 
searching the logs shows the following:

Sep 29 06:56:59.594402 adjusted mtu = 9178
Sep 29 06:58:29.333516 adjusted mtu = 9178
Sep 29 06:58:30.085894 adjusted mtu = 9178
Sep 29 06:58:51.754114 adjusted mtu = 9178
Sep 29 06:58:52.435535 adjusted mtu = 9178
Sep 29 06:58:52.437526 Intf ge-0/0/1.0: processing params change (new status : 
intf Up, new encaps : ETHERNET, new cntl word pic support : 0 mtu : 9178, 
vlan_id : 65535 tdm_payload_size: 0 tdm_bitrate: 0).

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN MTU Issue

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Eric Van Tol
 Sent: Wednesday, September 29, 2010 6:19 AM
 To: juniper-nsp
 Subject: [j-nsp] L2VPN MTU Issue
 
 Hi all,
 I'm having an issue with an L2VPN customer at the moment. They need to be
 able to pass 1500-byte IP packets between two locations connected via an
 ethernet encapsulated L2VPN.  I am able to ping from PE to PE with 1500-byte
 sized packets with the df-bit set without a problem.  The L2VPN connection is
 up and the customer can get a max of 1490-bytes through without
 fragmentation.  My LSP shows an MTU of 1500:

For historic purposes, the solution was to change my MPLS MTU to 1528 
throughout the network.  Now that I see the number, it should have been more 
obvious to me.

Thanks to those who responded, but public and private.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN MTU Issue

[Eric Van Tol]

 -Original Message-
 From: Dermot Williams [mailto:dermot.willi...@imaginegroup.ie]
 Sent: Wednesday, September 29, 2010 10:43 AM
 To: Eric Van Tol; juniper-nsp
 Subject: RE: [j-nsp] L2VPN MTU Issue
 
 Hi Eric,
 
 Unless it's sensitive, would you mind sharing how you arrived at that
 number please?
 
 Thanks,
 
 Dermot

Well, primary credit goes to JTAC, but doing some packet captures, I found that 
the packets entering the customer interface were not leaving the router.  JTAC 
suggested 1520, but that only allowed 1498-bytes through.  I bumped it up to 
1524, which still did not work, so then I bumped it up to 1528.  I am still not 
too keen on the math, but JTAC hasn't broken it down for me yet.  If anyone out 
there knows, please point me to a reference.  I googled like mad yesterday, but 
either overlooked the obvious, or wasn't searching for the right info.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN MTU Issue

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Eric Van Tol
 Sent: Wednesday, September 29, 2010 2:57 PM
 To: juniper-nsp
 Subject: Re: [j-nsp] L2VPN MTU Issue

 Well, primary credit goes to JTAC, but doing some packet captures, I found
 that the packets entering the customer interface were not leaving the router.
 JTAC suggested 1520, but that only allowed 1498-bytes through.  I bumped it
 up to 1524, which still did not work, so then I bumped it up to 1528.  I am
 still not too keen on the math, but JTAC hasn't broken it down for me yet.
 If anyone out there knows, please point me to a reference.  I googled like
 mad yesterday, but either overlooked the obvious, or wasn't searching for the
 right info.
 
 -evt

I was reading a partial thread yesterday in the archives and for whatever 
reason, could not find the reference thread and today, I came upon this:

http://puck.nether.net/pipermail/juniper-nsp/2006-September/007000.html

In a typical l2 vpn there would be two labels added; vrf and outer transport. 
The core interfaces will need an mtu of ethernet (1500) + vlan (4) + martini 
encap (0 | 4) + labels
(8) + what ever link encap is needed based on core interface type. If the core 
interfaces are also ethernet then this is another 14 for total of 1526-1530 
(the latter is with optional martini control word)

I came up with 1504 + 8 + 14 = 1526 in this calculation.  I am 2 bytes over the 
necessary, but to be honest, I will probably bump it up to 1530 or higher, so 
that 802.1q encapsulation can be supported.  For anyone starting out in MPLS 
VPNs in the Juniper world, this thread is a good one to read, as Harry points 
out at least one (perhaps previously, now) undocumented function of the MPLS 
MTU later on in one of his responses.

Thanks, Harry!

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Inter-Area MPLS TE

[Eric Van Tol]

 -Original Message-
 From: Mark Tinka [mailto:mti...@globaltransit.net]
 Sent: Sunday, September 05, 2010 12:54 AM
 To: juniper-nsp@puck.nether.net
 Cc: Eric Van Tol
 Subject: Re: [j-nsp] Inter-Area MPLS TE
 
 
 Are you trying to setup TE tunnels between different levels
 across a link?
 
 One problem JUNOS suffers from is the inability to implement
 IGP Shortcuts when CSPF is disabled.
 
 Cisco don't have this problem, and their Autoroute Announce
 feature (the equivalent of IGP Shortcuts) works fine even
 with explicitly-defined LSP's + CSPF turned off.


My question was more about going from one ISIS area to another (say, 49.0001 to 
49.0002), but this information could help me out as well.  I recall doing the 
L2-L1 tunnels in the lab and was able to get it to work.  IIRC, I had to define 
explicit paths through the network from the L2-L1 router, correct?

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Inter-Area MPLS TE

[Eric Van Tol]

Hi all,
Sorry if this info is readily available, but I couldn't find it in the Juniper 
docs.  Does JUNOS support inter-area MPLS traffic engineering for ISIS?  I see 
that setting the 'expand-loose-hop' works for OSPF, but is it the same for 
ISIS, or does ISIS simply support this functionality naturally?

Thanks,
evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] bgp summary outq

[Eric Van Tol]

Hi all,
I noticed this morning that all my IPv6 BGP neighbors have what appear to be 
thousands of messages in the 'OutQ'.  It's only IPv6 neighbors.  The numbers 
continue to climb and I'm curious as to why.  I'm not dropping sessions and I 
can't imagine that the v6 route table fluctuates so much that all these 
messages would queue up:

ber2.ss.sls.md# run show bgp summary
Groups: 6 Peers: 8 Down peers: 0
Table  Tot Paths  Act Paths SuppressedHistory Damp StatePending
inet.0644649 322548  0  0  0 24
inet6.04  2  0  0  0  0
Peer AS  InPkt OutPktOutQ   Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped...
:::::d0401234 168393 172216   0   1 
7w5d20h Establ
  inet6.0: 1/2/2/0
:::::d0411234 205620 210491   0   1 
9w3d23h Establ
  inet6.0: 1/2/2/0
:::::d0441234   2431   2433   0   2
18:35:32 Establ
  inet6.0: 0/0/0/0

I'm running 9.5R4.3 on various platforms (M-Series / MX-Series).  Is this 
normal?  If it is, I guess I just never noticed it.  None of my v4 neighbors 
show this behavior.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] bgp summary outq

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of David DeSimone
 Sent: Wednesday, August 11, 2010 11:09 AM
 To: juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] bgp summary outq
 
 
 I think this is just a presentation/column-alignment problem.  The
 columns are intended to be Peer then AS then InPkt then OutPkt
 then OutQ, but due to the wide IPV6 address in the Peer column, the
 OutPkt numbers are appearing underneath the OutQ label.

*facepalm*

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Single Fiber SM SFP

[Eric Van Tol]

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Keegan Holley
 Sent: Friday, August 06, 2010 11:03 AM
 To: Brendan Mannella
 Cc: juniper-nsp
 Subject: Re: [j-nsp] Single Fiber SM SFP
 
 Have you tried Juniper?  I have used cisco 1G sfp's with EX's in the past
 so
 10G should probably work as well.  The only issue is that sh chassis
 hardware will read unknown.  Maybe I don't understand the question but
 Juniper sells sfp's for it's gear the same way cisco does.  They are
 probably even made by the same companies.
 

Unless you like being price-gouged where it hurts the most by Juniper, I'd 
suggest looking at third-party vendors like MRV or Finisar for SFPs.  MRV makes 
DOM-enabled SFPs that work in Juniper equipment and they are 1/10th the price 
of Juniper's branded SFPs at the same or better quality.  I have never 
encountered any issue where Juniper saw that non-J SFPs were installed and 
wouldn't provide support.  However, if the problem is the SFP itself, then 
obviously they won't support it.  That's why spares are good to have around.  
With the money you save by buying MRV or Finisar, you can have spares *and* go 
on a Caribbean cruise.

-evt

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp