Actually, it's quite possible to have 400 in one direction and 60 in the
other. As an example, if you assume a 1 Gbps link with 20ms RTT, a receiver
using a 1 MB receive window might see between 300-400 Mbps, whereas a
receiver stuck with a 64 KB receive window on the same link might see only
20 Mb
As others have said, check the TCP receive window on the receiving end of
that slow transfer. There's a good chance that you don't have window
scaling enabled on that device. You may already know this, but here's a
link to the details that I've found to be helpful.
http://www.psc.edu/index.php/net
I have a couple of MX960s that have the wrong NET and I need to update
them. This is a production network. What is the best way to handle this? Do
I need to disable ISIS first or can I just change the ISO address on
loopback0?
My thought is that I need to disable ISIS, change the ISO address, then
You may be referring to a question I had about ECMP a few months ago. In my
case, I was sent to this link which was very helpful. You're right, it is
way more involved than it should be.
http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
Regards,
John
On
y a 2960G even in IOS 15.
>
> Looks like some packet handling code isn't correctly de-activated.
>
>
> Le 16/06/2014 07:23, John Neiberger a écrit :
> > This does seem to be specific to RA/RS. I haven't been involved in
> > troubleshooting over the weekend but the upd
ow
more after a meeting in the morning. Sure seems awfully funky, though. JTAC
seems to be at a loss to explain what is happening.
Thanks,
John
On Sun, Jun 15, 2014 at 5:22 AM, Phil Mayers
wrote:
> On 14/06/14 22:24, John Neiberger wrote:
>
> The EX4550 is just layer two. There is no rout
I was paged to take a look at an interesting problem this morning. We have
an MX960 connected to an EX4550 via a trunk carrying multiple VLANs. The
EX4550 is, in turn, connected to a second switch. I don't recall what model.
The second switch used to be connected to something else and was moved ov
signalled from
> and where traffic enters and egress for the termination point where traffic
> exits.
>
> > On Fri, May 9, 2014 at 8:23 PM, John Neiberger
> wrote:
> >
> >> I just took a Juniper MPLS and VPNs course and I have a question about
> the
> >>
I just took a Juniper MPLS and VPNs course and I have a question about the
ingress and egress types of LSPs. The terminology makes zero sense to me.
The LSP that is used to send traffic is called the ingress LSP, and the LSP
used to receive traffic is an egress LSP. How in the heck does that make
a
cular link,
is it a fair bet that it was hashed to that same link prior to the link
going down?
Thanks,
John
On Tue, Apr 15, 2014 at 12:07 PM, John Neiberger wrote:
> Holy cow. I never would have figured that one out, and the two Juniper
> engineers I asked had no idea how to do it. I app
's ridiculously overcomplicated, David Roy wrote a
> fine article about that, at least for MX with DPC:
>
> http://www.junosandme.net/article-junos-load-balancing-part-3-troubleshooting-109382234.html
>
>
> Olivier
>
> Le 15 avr. 2014 à 04:01, John Neiberger a écrit :
&g
I know that ECMP is, by default, based on a hash of source and destination
IP address, and I know that we can see the available paths by doing "show
route forwarding-table destination ", but is there a way to
determine which path a particular flow is using?
For those of you familiar with Cisco, I
I've only seen something like this once and it was a graceful restart
issueer"feature" on a Cisco router, so I doubt it's the same
problem here. In that situation, the router waited for a graceful restart
timer to expire before it would clear out the routes, and it was doing this
despite th
I'm a little confused about how wildcards work in groups that use for our
class of service configs. I was thinking that the wildcard would allow us
to apply a configuration to an interface and all its logical units with one
command, but now I don't think that's the case. Here is an basic example:
On Wed, Jan 29, 2014 at 9:08 AM, Chris Adams wrote:
> Once upon a time, John Neiberger said:
>> Passive learning is an interesting thought, but I'd still like to find
>> the root cause of the problem: why don't the IP addresses respond to
>> ARP requests from only
>
> I'd suggest looking at a couple of things...
>
> First, the arp cache cache timers on both the switch & routers.
> From memory, Cisco & juniper differed in when the arp cache was expired.
>
> On the router side, it'd be worth checking if accept-data is enabled at the
> interface level.
> Turnin
On Tue, Jan 28, 2014 at 8:42 AM, Marcel Plug wrote:
> If packet captures on the servers don't show the arp packets getting there,
> its a good bet they aren't getting there. Have you ruled out the switch as
> the culprit? At least monitor the server's port on the switch to confirm
> the arp pack
I'll preface this question by saying that I don't think this is a
problem on the router, but I'm stumped and I'm curious if anyone else
has run into this. We have a Cisco 4948 with two uplinks to different
MX960s we'll call RouterA and Router B. There are a few linux servers
connected to the switch
On Thu, Jan 23, 2014 at 2:41 AM, Alexandre Snarskii wrote:
> On Wed, Jan 22, 2014 at 09:20:36AM -0700, John Neiberger wrote:
>> I ran into an issue yesterday that confused me, which seems to be a
>> weekly occurrence lately regarding Juniper CoS.. We had an interface
>> that
On Thu, Jan 23, 2014 at 2:41 AM, Alexandre Snarskii wrote:
> On Wed, Jan 22, 2014 at 09:20:36AM -0700, John Neiberger wrote:
>> I ran into an issue yesterday that confused me, which seems to be a
>> weekly occurrence lately regarding Juniper CoS.. We had an interface
>> that
I ran into an issue yesterday that confused me, which seems to be a
weekly occurrence lately regarding Juniper CoS.. We had an interface
that was receiving traffic marked as EF. The interface only had the
default CoS configuration. For some reason, the traffic was arriving
at the destination marked
On Tue, Jan 14, 2014 at 1:31 AM, Mark Tinka wrote:
> On Tuesday, January 14, 2014 12:39:34 AM John Neiberger
> wrote:
>
>> It doesn't have a forwarding class named VOIP-BEARER at
>> all. So, how in the world does matching on a forwarding
>> class in a firewall
I'm trying to troubleshoot a one-way audio problem and I'm very
confused. The traffic is marked as EF but it's not making it to the
destination. The egress interface has a firewall filter that at first
glance appears to permit all EF:
term permit-fec-ef {
from {
forwarding-class VOIP-B
us to upgrade, and rightfully so. I just hope we can
find a workaround in the interim.
On Tue, Dec 24, 2013 at 9:04 AM, John Neiberger wrote:
> We're in the process of upgrading all of our MXs running older code,
> but we haven't gotten to this router just yet. We are upgrading to
We're in the process of upgrading all of our MXs running older code,
but we haven't gotten to this router just yet. We are upgrading to
some flavor of 11.4, as I recall. I have someone working on getting a
capture, but I will grab what I can using "monitor traffic interface".
Thanks!
John
On Tue,
I'm running into an odd problem that seems to be related to v6
neighbor discovery on an MX960 running 9.6R4. Here is a simplified
topology for explanation:
[RouterA] [RouterB] [Host]
The host server is connected to a switch that is connected to RouterB.
If you try to ping the host from
When I telnet from a Juniper router to a device on one TCP port I get
"connection refused", but if I try some other ports I get "operation
not permitted". What is the difference between these messages? Is it
that one is failing with no response at all from the far side while
the other is failing wi
ased cards. It was in junos 11.4. Jtac had found an
> internal PR that matched our issue.
>
> Workaround was the using buffer-size in %.
>
> Which version and cards do you use?
>
> David
>
> Envoyé de mon iPad
>
> > Le 1 oct. 2013 à 21:13, "John Neiberger"
I've been troubleshooting an interesting problem off and on the past couple
of days. We have a 1-gig link that is consistently running around 10%
utilization, give or take a couple of percent, but we see periods where the
egress WRED drops for queue 0 spike. It's bizarre because there is no
corresp
We ran into something very similar a long time ago. I don't remember the
resolution, but I think we either reloaded the linecard or replaced the
linecard. Nothing else we tried fixed it. I seem to recall we tried
restarting the VRRP process but it didn't help. That was over a year ago,
at least. My
What sort of multicast traffic is it? Is it a constant stream like voice or
video or is it an intermittent feed like some sort of multicast messaging?
If this is very low-rate traffic and intermittent, Juniper routers often
drop the first packet because the multicast route has timed out of the
forw
; hmac-md5 blah level X, of course ?
>
> --
> regards,
> Olivier Benghozi
>
> Le 12 juin 2013 à 17:08, John Neiberger a écrit :
> > We've got an MX960 connected to a Cisco CRS, both of which are configured
> > for ISIS authentication. However, the CRS is currently configur
On the Juniper side we only have authentication configured under "protocols
isis level 2".
On Wed, Jun 12, 2013 at 10:22 AM, Bikram Singh wrote:
> have you configured authentication on interface(in ISIS) as well on mx960?
>
> - B
>
> > From: jneiber...@gmail.com
> > Date: Wed, 12 Jun 2013 09:08
We've got an MX960 connected to a Cisco CRS, both of which are configured
for ISIS authentication. However, the CRS is currently configured for only
hello authentication. It appears that Junos enables both hello
authentication and CSNP/PSNP authentication by default. This is allowing
the adjacency
tly
stable. That pretty much proves to me beyond any reasonable doubt that this
is a problem with the SBC and the switch itself is not contributing to the
problem in any way.
On Mon, Jun 10, 2013 at 8:57 AM, John Neiberger wrote:
> Here's an example of what I'm talking about. The MA
10, 2013 at 8:36 AM, John Neiberger wrote:
> I was just checking again and I'm really having difficulty reconciling the
> conflicting information reported by the switch. The output of "show
> ethernet mac-learning-log" is stable and the MAC addresses show as learned
>
.
Thanks,
John
On Mon, Jun 10, 2013 at 8:23 AM, John Neiberger wrote:
> I think they do have them configured differently, but they swear they
> don't and I don't have the access or the knowledge on that platform to
> disagree with them. The network side is straightforward sw
Mon, Jun 10, 2013 at 2:37 AM, Phil Mayers wrote:
> On 06/09/2013 04:59 PM, John Neiberger wrote:
>
> We have several of these throughout our network and we're only seeing this
>> problem in a couple of cases. The rest work just fine. Most of the SBCs
>> are
>>
>
tive/Passive
> mode with a VRRP like protocol. This means a common MAC that floats between
> both boxes depending on which is primary. Maybe both boxes think they're
> primary and keep advertising the same MAC? This would cause a constant move
> of the same MAC.
>
> Serge
>
gt;
>
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of
> John Neiberger
> Sent: Saturday, June 08, 2013 4:16 PM
> To: Gavin Henry
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] What is this ethernet
://www.gossamer-threads.com/lists/drbd/users/24805
>
> http://serverfault.com/questions/58146/what-can-cause-two-network-interfaces-on-the-same-machine-to-flip-flop-their-ip
>
> arpwatch will report "flip flop" in the logs.
>
> If you're not on Linux then I'm not
tus 0, 0
Jun 7 23:37:09.776953 vlan sbc-core mac 00:08:25:fa:3c:91 (tag 40), iif =
ge-0/0/8.0: present in FDB
Jun 7 23:37:09.777140 (3, 00:08:25:fa:3c:91) next-hop index change [1330
-> 1329]
On Fri, Jun 7, 2013 at 6:30 PM, John Neiberger wrote:
> I just checked and we do not have sp
connected via two ports?
> >
> > Sent from my iPad 2
> >
> > On 7 Jun 2013, at 23:12, John Neiberger wrote:
> >
> >> Also, another interesting thing about this is that the output of "show
> >> ethernet mac-learning-log" stops at April 13th.
ging to
the MAC learning log?
By the way, this is an EX4200 running 10.4R6.5.
On Fri, Jun 7, 2013 at 4:07 PM, John Neiberger wrote:
> We're trying to troubleshoot an odd issue and this log output makes it
> appear that a MAC address is flipping between interfaces. There are other
&
We're trying to troubleshoot an odd issue and this log output makes it
appear that a MAC address is flipping between interfaces. There are other
interfaces involved later in the logs. I'm starting to think this isn't
telling us what we think it's telling us. Does this indicate that the MAC
address
That makes perfect sense. I'm not sure what my mental block was with that.
lol
How does Juniper handle situations where you do need to mark a packet on
ingress so that you can match on the new marking on egress? If there is a
rewrite rule, does the rewrite happen before any egress firewall filter
I'm still learning how Junos handles DSCP marking and I ran into a question
based on something I saw in production.
Let's assume we have an irb, and in that irb is an ae, and the ae has two
physical ports in it. If I want to mark traffic on ingress, does it matter
on which interfaces I configure t
I hope someone tackles this question soon. I'm pretty interested to find
out what the answer is, too.
John
On Wed, Dec 19, 2012 at 11:45 AM, Matt Bentley wrote:
> Hi All:
>
> We have a 200Mbps ethernet service delivered via EoSDH. We have GigE
> handoffs to the carrier on either side. We've b
scenario that it's really bugging me that I can't figure it out. lol
On Fri, Nov 2, 2012 at 4:43 PM, John Neiberger wrote:
> Okay, I've been looking at this for a little bit and it's just really
> bizarre. I was wrong about the connectivity earlier. It's really ju
are no special features enabled, like MAC filtering or whatever.
It's very straightforward, which is why we're all stumped. Something is
stopping those multicasts from reaching router 2, but for the life of me I
don't see what it could be.
On Fri, Nov 2, 2012 at 3:53 PM, John Neiberger
ces or lo0 and if yes, do you allow
> "protocol vrrp" as well as AH/proto 51 and have you added/changed VRRP auth
> type recently? Proto 51 is used when VRRP MD5 auth is configured. In any
> case, I'd suggest to configure a FW filter to log/syslog incoming VRRP
> packets
We have a very odd problem that we've been dealing with for a couple of
weeks. JTAC is involved but we have not come to a resolution yet. The gist
of the problem is that we have two MX960s and we're running VRRP on
multiple interfaces with different Cisco switches in between each pair of
Juniper in
tched in the flow map
now?
Thanks,
John
On Mon, Oct 8, 2012 at 3:44 PM, Nilesh Khambal wrote:
> Sure. Make sure you implement this workaround across all Juniper boxes that
> are in path for this multicast group traffic.
>
> - Nilesh.
>
> From: John Neiberger
> Date: Monday,
On Mon, Oct 8, 2012 at 3:28 PM, Nilesh Khambal wrote:
> Hi John,
>
> Is it the first packet that gets lost from the stream or the subsequent
> ones?
>
> If the route does not exist on MX for your (S,G) in the forwarding-table,
> then when you receive the packet for this (S,G) on MX, it will be pun
On Mon, Oct 8, 2012 at 2:27 PM, John Neiberger wrote:
> We have a simple setup like this:
>
> [receiver] [ Cisco-rtr-A] [ Cisco rtr-B] - [MX960] -
> [Cisco rtr-C] [source]
>
> The receiver has joined a specific S,G, but this is very low rate,
> per
We have a simple setup like this:
[receiver] [ Cisco-rtr-A] [ Cisco rtr-B] - [MX960] -
[Cisco rtr-C] [source]
The receiver has joined a specific S,G, but this is very low rate,
perhaps just a couple of multicast packets per week. It's a multicast
messaging setup related to
FIC-CLASS-4-SCHEDULER {
buffer-size temporal 35k;
priority strict-high;
On Fri, Jul 20, 2012 at 10:39 PM, John Neiberger wrote:
> On Fri, Jul 20, 2012 at 3:49 PM, Wayne Tucker wrote:
>> Does show interfaces extensive on the interface between Router A and
>> Device A show any drops?
rchitect EABU
> Juniper Networks
>
>
> On 7/22/12 10:34 AM, "John Neiberger" wrote:
>
>>Forgive my Juniper noobiness once again. We have the following term in
>>a ingress firewall filter for marking:
>>
>>term netmgmt {
>>then {
>>
Forgive my Juniper noobiness once again. We have the following term in
a ingress firewall filter for marking:
term netmgmt {
then {
count fec-cs2;
loss-priority high;
forwarding-class MNGMT;
It seems to be working, but I don't know why. If there is no "accept",
shouldn
On Fri, Jul 20, 2012 at 3:49 PM, Wayne Tucker wrote:
> Does show interfaces extensive on the interface between Router A and
> Device A show any drops? IIRC, the default scheduler map does not define
> schedulers for anything other than be and nc - so if you're classifying the
> packets on input
ap does not define
> schedulers for anything other than be and nc - so if you're classifying the
> packets on input then it could be that they're going to a class that has no
> resources on the egress interface.
>
> :w
>
>
> On Fri, Jul 20, 2012 at 2:15 PM, John Neib
Relavent config bits would help.
>
> On Jul 20, 2012, at 3:56 PM, John Neiberger wrote:
>
>> We've been troubleshooting a strange problem for a few days. JTAC is
>> on the case, too, but we have not found any resolution. I thought
>> maybe picking some minds h
We've been troubleshooting a strange problem for a few days. JTAC is
on the case, too, but we have not found any resolution. I thought
maybe picking some minds here would be helpful. Here is a simplified
diagram:
[Device A] --- [Router A] --- [Router B] --- [Router C]
- [Device
I have a lot of spiky traffic hitting a particular queue and much of
it is being dropped. I want to find out exactly what that traffic is.
I would guess that some variation of "monitor traffic interface" would
do the trick, but what is the best way to structure that if there is a
lot of traffic and
;
>
>
>
>
> -Original Message-
> From: John Neiberger [mailto:jneiber...@gmail.com]
> Sent: Tuesday, March 13, 2012 4:55 PM
> To: Harry Reynolds
> Cc: Mohammad; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] Hidden IPv4 iBGP routes
>
> We do have the followi
so also applies to any vrfs and their
> configured asns.
>
> HTHs
>
>
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
> Sent: Tuesday, March 13, 2012 4:17 PM
o applies to any vrfs and their
> configured asns.
>
> HTHs
>
>
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of John Neiberger
> Sent: Tuesday, March 13, 2012 4:17 PM
> To:
Okay, there is no local AS configured under protocols bgp, and the AS
configured under routing options is correct.
On Tue, Mar 13, 2012 at 5:11 PM, John Neiberger wrote:
> I'll do that right now. I checked the AS under routing-options, but
> didn't check for a local-as. Thanks!
I'll do that right now. I checked the AS under routing-options, but
didn't check for a local-as. Thanks! I'm very new to Juniper, so I'm
still pretty lost.
On Tue, Mar 13, 2012 at 4:29 PM, Mohammad wrote:
> I think you need to check the autonomous-system under the routing-options
> hierarchy; and
Something that makes this a little stranger to me is that in the
output showing the looped AS, the local AS isn't ever listed. The
route is originating in AS Y and passing through AS X on the
way to this router, which is in AS Z. I'm confused about how an AS
path loop could be happening
I was troubleshooting a problem last night and it boiled down to a
Juniper router that was not a whole slew of iBGP routes from a
neighboring ASR9K. I'm too new to Junos to decipher the reason for it.
I had to disguise it a bit, so I hope it's still readable. What does
this actually mean? Can you t
> Mark,
>
> Do you have any tips regarding ISIS authentication between Junos and
> IOS? We have a 7600 that is connected to this same MX960 and it's
> having a similar problem. Do you know of any idiosyncrasies with
> regard to Juniper-to-IOS ISIS authentication?
>
> Thanks,
> John
Nevermind, I ju
On Fri, Mar 9, 2012 at 4:39 AM, Mark Tinka wrote:
> On Thursday, March 08, 2012 11:22:48 AM John Neiberger
> wrote:
>
>> I think some mixture of those commands would have helped,
>> but I think I also just spotted the real culprit. The
>> CRS that is working h
for. I have no CRS thus
> no further ideas...
>
> Aaron
>
> On Mar 7, 2012, at 7:53 PM, John Neiberger wrote:
>> I'm pretty new to Juniper and I'm trying to troubleshoot a pretty
>> weird problem between an MX960 running 9.6R4.4 and a CRS-8 running XR
>>
I'm pretty new to Juniper and I'm trying to troubleshoot a pretty
weird problem between an MX960 running 9.6R4.4 and a CRS-8 running XR
4.0.4. It's a very straightforward ISIS configuration for IPv6. We
have MD5 authentication configured on both sides. The adjacency comes
up, but the Juniper doesn'
75 matches
Mail list logo
