Hi Mark,
> Some good news from my friendly SE... the ER to add support per subject
> has been filed.
>
> Timelines on when we shall see code are forthcoming.
Good news!
Sander
signature.asc
Description: Message signed with OpenPGP
___
juniper-nsp ma
Hi all.
Some good news from my friendly SE... the ER to add support per subject
has been filed.
Timelines on when we shall see code are forthcoming.
I'll keep you all posted.
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.
Hi all.
Some good news from my friendly SE... the ER to add support per subject
has been filed.
Timelines on when we shall code forthcoming.
I'll keep you all posted.
Mark.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.n
On 3/Oct/18 15:40, Gert Doering wrote:
> If you run different IGPs for IPv4 and IPv6, you'll have independent
> BFD sessions for IPv4 and IPv6. Just the "dual-stack ISIS hooking into
> BFD" won't give you "dual BFD" - since there is a common ISIS adjacency
> for all transported routing informat
On 3/Oct/18 15:37, adamv0...@netconsultings.com wrote:
> I've been wondering for quite some time why vendors don’t allow us to
> configure BFD as a standalone protocol very much like any other IGP protocol
> and instead insist on doing that themselves automatically under the hood.
You can, bu
Hi,
On Wed, Oct 03, 2018 at 10:51:08AM +0100, James Bensley wrote:
> On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote:
> > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote:
> >
> > If you'd have separate ISIS process for v6 would it be possible to spin up a
> > separate/dedicated BFD process fo
> From: James Bensley [mailto:jwbens...@gmail.com]
> Sent: Wednesday, October 03, 2018 10:51 AM
>
> On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote:
> > On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote:
> >
> > If you'd have separate ISIS process for v6 would it be possible to
> > spin up a se
So JTAC are saying that because link-local addresses are always
maintained in the RE for BFD, BFD for IPv6 as driven by IS-IS is not
supported in the PFE, as those sessions run over link-local.
You can imagine what I asked them next...
Mark.
___
juniper
On Wed, 3 Oct 2018 at 10:13, Mark Tinka wrote:
> On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote:
>
> If you'd have separate ISIS process for v6 would it be possible to spin up a
> separate/dedicated BFD process for that ISIS?
Unless I'm mistaken BFD isn't "multi-tenant", so only one set of
> From: Mark Tinka [mailto:mark.ti...@seacom.mu]
> Sent: Wednesday, October 03, 2018 10:13 AM
>
>
> On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote:
> If you'd have separate ISIS process for v6 would it be possible to spin up a
> separate/dedicated BFD process for that ISIS?
>
> Probably n
On 3/Oct/18 11:09, adamv0...@netconsultings.com wrote:
> If you'd have separate ISIS process for v6 would it be possible to spin up a
> separate/dedicated BFD process for that ISIS?
Probably not. I'm not sure there is a way to run separate IS-IS
processes in Junos, unless you run single-stack
> Of Mark Tinka
> Sent: Tuesday, October 02, 2018 9:47 PM
>
>
>
> On 2/Oct/18 21:13, James Bensley wrote:
>
> > I presume that if one were to run MT-ISIS there would be no impact to
> IPv4?
>
> We already run MT for IS-IS. I consider this as basic a requirement as
"Wide
> Metrics".
>
> Howeve
On 3/Oct/18 10:06, James Bensley wrote:
> I'm not sure about Junos but IOS-XR can run wide metrics in ST-ISIS so
> I wasn't going to assume MT :)
You can run ST with narrow metrics. But if you want MT, you need wide
metrics.
MT is highly recommended if you are running IS-IS both for IPv4 and
On Tue, 2 Oct 2018 at 21:46, Mark Tinka wrote:
> On 2/Oct/18 21:13, James Bensley wrote:
>
> I presume that if one were to run MT-ISIS there would be no impact to IPv4?
>
>
> We already run MT for IS-IS. I consider this as basic a requirement as "Wide
> Metrics".
I'm not sure about Junos but IOS
❦ 2 octobre 2018 23:07 +0200, Mark Tinka :
>> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
>> independent when using public IPv6 addresses. However, I've just noticed
>> that when using an IRB, BFD is handled by the control plane, both for
>> IPv6 and IPv4.
>
> It's clear t
On 2/Oct/18 23:01, Vincent Bernat wrote:
> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
> independent when using public IPv6 addresses. However, I've just noticed
> that when using an IRB, BFD is handled by the control plane, both for
> IPv6 and IPv4.
It's clear that whet
On 2/Oct/18 23:01, Vincent Bernat wrote:
> Dunno with IS-IS, but with BGP, BFD is advertised as control plane
> independent when using public IPv6 addresses. However, I've just noticed
> that when using an IRB, BFD is handled by the control plane, both for
> IPv6 and IPv4.
It's clearly that wh
❦ 2 octobre 2018 20:13 +0100, James Bensley :
>> > Not exactly your scenario but we had the same problems with eBGP with
>> > IPv6 link-local addresses on QFX10K platform.
>> > Dev Team had replied that rather than hardware limitation it's more of
>> > a "design decision" to not distribute IPv6
On 2/Oct/18 21:13, James Bensley wrote:
> I presume that if one were to run MT-ISIS there would be no impact to IPv4?
We already run MT for IS-IS. I consider this as basic a requirement as
"Wide Metrics".
However, the issue here is BFD sees the whole of IS-IS as a client. So
if BFD has a mome
On Tue, 2 Oct 2018 at 16:39, Mark Tinka wrote:
> The real-world problem we are seeing is when, for whatever reason, the
> RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well,
> IS-IS integrates both IP protocols.
I presume that if one were to run MT-ISIS there would be no impa
Hi,
On Tue, Oct 02, 2018 at 05:39:06PM +0200, Mark Tinka wrote:
> On 2/Oct/18 17:05, Gert Doering wrote:
>
> > "nobody is using this for real, so just make sure we can tick the
> > marks on the customers' shopping lists"
>
> The real-world problem we are seeing is when, for whatever reason, the
On 2/Oct/18 17:05, Gert Doering wrote:
> "nobody is using this for real, so just make sure we can tick the
> marks on the customers' shopping lists"
The real-world problem we are seeing is when, for whatever reason, the
RE CPU spikes and BFD for IPv6 sneezes, we also lose IPv4 because, well,
IS
Hi,
On Tue, Oct 02, 2018 at 03:37:15PM +0200, Mark Tinka wrote:
> Definitely makes the case for anyone that says IPv6 is not as ready as
> IPv4... did Juniper elaborate what "design decision" actually means?
"nobody is using this for real, so just make sure we can tick the
marks on the customers'
On 2/Oct/18 15:30, Виталий Венгловский wrote:
> Mark,
>
> Not exactly your scenario but we had the same problems with eBGP with
> IPv6 link-local addresses on QFX10K platform.
> Dev Team had replied that rather than hardware limitation it's more of
> a "design decision" to not distribute IPv6 LL
Hi all.
I've been going back & forth with JTAC on this, and they seem a bit lost.
Does anyone know whether BFD for IPv6 (IS-IS) is supported in the PFE on
the MX?
On the router, it clearly isn't:
*
Destination: aaa.bb.cc.2, Protocol: BFD, Transmission interval: 2000
*Distributed: TRUE*, Di
Check interface stats and look for duplex, run a rapid burst of pings with
small and large payloads (2 tests) also is this a service provider link or
a link you control both ends?
If the latter applies, might be worth looking at the optics and physical
wire... else call your provider and ask for i
If it's an intermittent issue with Ping reachability, then check out
interface errors as well. On top of that find out if there are any memory
errors (where data gets buffered) in the Syslog i.e. CRC failing..
On Mon, Mar 27, 2017 at 8:55 AM, Jeff Haas wrote:
>
> > On Mar 5, 2017, at 3:05 AM, Mo
> On Mar 5, 2017, at 3:05 AM, Mohammad Khalil wrote:
>
> Hi all
> I have a BFD session between two routers (which was working normally)
> Currently , the session is down from one side and init from the other side
> The ISIS adjacency is up
> What could be the issue?
The other comments in the th
Hi,
Is that a copper SFP?
Then try to do series of rapid long pings across this link with any
applicable policers/shapers deactivated.
If You see missed packets, replace this SFP and a patch cable as well.
HTH
Thx
Alex
On 05/03/2017 11:40, Mohammad Khalil wrote:
admin@CR02# run show interf
admin@CR02# run show interfaces diagnostics optics ge-2/1/0
Physical interface: ge-2/1/0
Optical diagnostics : N/A
On 5 March 2017 at 13:23, Alexander Arseniev
wrote:
> Hello,
>
> Check Your laser light levels :
>
> show interfaces diagnostics optic
Hello,
Check Your laser light levels :
show interfaces diagnostics optics ge-x/y/z
HTH
Thx
Alex
On 05/03/2017 10:51, Mohammad Khalil wrote:
As well , I have checked the log messages , and I can see the below message:
RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake
BR,
Moha
admin@CR03# run show interfaces ge-2/0/0 | grep MTU
Link-level type: 52, MTU: 1600, Speed: 1000mbps, BPDU Error: None,
Protocol bridge, MTU: 1600
Protocol inet, MTU: 1578
Protocol iso, MTU: 1575
Protocol inet6, MTU: 1578
Protocol mpls, MTU: 1566
Protocol multiservice, MTU:
The inet MTU shows as 1578 , so I have pinged as below:
run ping 10.0.0.10 size 1550 do-not-fragment
sometime it shows packet loss and sometimes no
On 5 March 2017 at 13:00, wrote:
> > As well , I have checked the log messages , and I can see the below
> message:
> > RPD_ISIS_ADJDOWN : ISIS lost
> As well , I have checked the log messages , and I can see the below message:
> RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake
In which case it sounds like ISIS is also having problems. Can you
ping across the link with full MTU (inet MTU - 28, physical interface
- 42, both assu
As well , I have checked the log messages , and I can see the below message:
RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake
BR,
Mohammad
On 5 March 2017 at 12:24, Mohammad Khalil wrote:
> Hi
> I have removed the whole filter from the lo0 interface and the same applies
>
> BR,
Hi
I have removed the whole filter from the lo0 interface and the same applies
BR,
Mohammad
On 5 March 2017 at 12:03, wrote:
> > I have a BFD session between two routers (which was working normally)
> > Currently , the session is down from one side and init from the other
> side
> > The ISIS ad
> I have a BFD session between two routers (which was working normally)
> Currently , the session is down from one side and init from the other side
> The ISIS adjacency is up
> What could be the issue?
Check if you you have firewall filter on lo0 which blocks UDP port 3784
or 3785.
Steinar Haug,
Hi all
I have a BFD session between two routers (which was working normally)
Currently , the session is down from one side and init from the other side
The ISIS adjacency is up
What could be the issue?
BR,
Mohammad
___
juniper-nsp mailing list juniper-ns
On 20 May 2016 at 20:35, Duane Grant wrote:
> i agree that they could make it work, but it's a biggish change. bfd is an
> L3 protocol and below he's asking it to work at L2 and do neighbor
> discovery. the way bfd works now, the registering protocol does or provides
> the neighbor discover par
i agree that they could make it work, but it's a biggish change. bfd is an
L3 protocol and below he's asking it to work at L2 and do neighbor
discovery. the way bfd works now, the registering protocol does or
provides the neighbor discover part and tells bfd. this infrastructure
isn't available
On 20 May 2016 at 16:51, Duane Grant wrote:
> in every OS I've used, you need a registering protocol to get bfd to start,
> and if you start shutting them down (or remove peer reachability), bfd will
> admindown itself, which causes interesting consequences.
Sure, but this is implementation issue
in every OS I've used, you need a registering protocol to get bfd to start,
and if you start shutting them down (or remove peer reachability), bfd will
admindown itself, which causes interesting consequences.
if you want bfd to watch a physical link, have it monitor a static route,
but you'll also
If the interface is ethernet you may want to consider ethernet OAM options
LFM or CFM
depending on the topology.
On Thu, May 19, 2016 at 12:45 PM, James Bensley wrote:
> On 19 May 2016 at 10:53, Mark Tinka wrote:
> >
> >
> > On 19/May/16 11:49, James Bensley wrote:
> >
> >> In Cisco land we hav
On 19 May 2016 at 10:53, Mark Tinka wrote:
>
>
> On 19/May/16 11:49, James Bensley wrote:
>
>> In Cisco land we have the interface command "carrier-delay", for Junos
>> (this scenario) can the OP not use some variant of "set interfaces
>> xe-0/0/1 hold-time up 5000" ?
>
> OP says the issue is remo
On 19/May/16 12:13, Saku Ytti wrote:
> +1 why create higher abstraction layers and complicated notifications
> per protocols, when usually if we need single-hop BFD, we need it
> because we broke physical liveliness detection
+1.
It has always been assumed that routing or signaling protocols a
On 19 May 2016 at 12:38, Adam Vitkovsky wrote:
> /rant/
> I don’t understand why BFD can't be configured as a standalone protocol under
> protocols stanza same way as oam lfm is.
> Something like the below.
> set protocols bfd interface ae0 pdu-interval 100
> set protocols bfd interface ae0 pdu-
On 19/May/16 11:49, James Bensley wrote:
> In Cisco land we have the interface command "carrier-delay", for Junos
> (this scenario) can the OP not use some variant of "set interfaces
> xe-0/0/1 hold-time up 5000" ?
OP says the issue is remote.
Local link to provider's switch does not fail, and
In Cisco land we have the interface command "carrier-delay", for Junos
(this scenario) can the OP not use some variant of "set interfaces
xe-0/0/1 hold-time up 5000" ?
Cheers,
James.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.n
> Clarke Morledge
> Sent: Wednesday, May 18, 2016 11:54 PM
>
> I am trying to figure out the best way to configure an MX router, on an
> interface, to wait a specific time before it can re-establish an IS-IS
> adjacency,
> after an adjacency has been lost.
>
> Assume I am using BFD with reasonably
On 19/May/16 01:11, Clarke Morledge wrote:
> Thanks, Mark.
>
> I looked into that, but the situation is such that the physical link
> itself remains up. The problem is that the L2 device in between is
> dropping packets. I should have clarified that.
In that case, BFD is your friend.
You could
Thanks, Mark.
I looked into that, but the situation is such that the physical link
itself remains up. The problem is that the L2 device in between is
dropping packets. I should have clarified that.
Clarke Morledge
College of William and Mary
Information Technology - Network Engineering
Jones
On 19/May/16 00:53, Clarke Morledge wrote:
> I am trying to figure out the best way to configure an MX router, on
> an interface, to wait a specific time before it can re-establish an
> IS-IS adjacency, after an adjacency has been lost.
>
> Assume I am using BFD with reasonably short timers/mult
I am trying to figure out the best way to configure an MX router, on an
interface, to wait a specific time before it can re-establish an
IS-IS adjacency, after an adjacency has been lost.
Assume I am using BFD with reasonably short timers/multipliers to detect
when an IS-IS adjacency fails, wi
Hello all, hoping for some info. I am seeing an issue with BFD between an
MX80 and a Cisco ASR9001. Long story short is I am seeing a bfd issue caused
by adaptive mode on the Juniper.
Setup isASR<--o-->EX4200<--o-->EX4500<--o-->MX80
| |vc|
|vc|
Hi
I am struggling to get a BFD session coming up over eBGP on Juniper SRX650
(junos 11.4)
I have set up the SRX650 in packet mode , but for the life of me i am
unable to get the session up
The BGP BFD configuration is fine, as checked with documentation
(bfd-liveness-detection minimum-interval
We use 100ms x 3 in our core (we're a city-based carrier with direct
fiber between all cores, hence very low latency) and 150ms x 3 in our
agg rings which hang off our cores. As has been covered in a previous
thread, be mindful of how your platform(s) handle BFD messages. Some
can distribute BF
On Friday, December 30, 2011 12:52:45 PM tim tiriche wrote:
> Would like to know what others are running on their
> production sites.
We're running 250ms across all Cisco and Juniper routers and
switches in our network.
Multipliers tend to be 3, but we've been playing around with
slightly high
Hello,
Are there any recommended timers for IGP and iBGP when running BFD.
Would like to know what others are running on their production sites.
--tim
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/jun
Hi All
I have a requirement in my typical LAN scenario whereby my LAN server
connects in a dual homed fashion to two different LAN switches from a third
party vendor. We are using vrrp for the server LAN. The two 3rd party vendor
switches are uplinked via L3 links to two ex-4500. We are tracking th
On Friday, March 04, 2011 06:27:27 am Doug Hanks wrote:
> We generally recommend 150ms to most customers. The
> added benefit of going from 150ms to 50ms is generally
> not enough to warrant the move.
We've been using 250ms with multipliers of 3 on short runs
and 5 on longer ones. Has been stab
2011 10:07 AM
> To: David Ball
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] BFD timers for OSPF - MX80 - 10.3R2.11
>
> We are using bfd on mx80 with 300ms timers and no problems. Only 2 or 3
> sessions per box however.
>
> --
>
> Regards
>
> An
, March 03, 2011 10:07 AM
To: David Ball
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] BFD timers for OSPF - MX80 - 10.3R2.11
We are using bfd on mx80 with 300ms timers and no problems. Only 2 or 3
sessions per box however.
--
Regards
Andy Harding
Internet Connections Ltd
Phone: 0870
We are using bfd on mx80 with 300ms timers and no problems. Only 2 or 3
sessions per box however.
--
Regards
Andy Harding
Internet Connections Ltd
Phone: 0870 803 1868
Mobile: 07813 975459
Fax: 0870 803 1781
Web: www.inetc.co.uk
Email: a...@inetc.co.uk
On 3 Mar 2011, at 17:53, David Ball wr
Probably yes, however, RFC 5880 states:
---
protocol intended to detect faults in the bidirectional path between
two forwarding engines, including interfaces, data link(s), and to the
extent possible the forwarding engines themselves, with potentially
very low latency. It operates independently of
On (2011-03-03 20:42 +0300), Egor Zimin wrote:
Hi,
> It looks like BFD implementation in MX80 is not distributed. At this
> moment I have a case in JTAC. The case is opened yet, however, it
> _looks_like_ bfd is not distributed.
If it would be 'distributed', wouldn't it run in 'linecard excepti
Ah, that might help explain it. And shame on me for not checking
'sh pfe statistics traffic protocol bfd', which of course shows none
received or absorbed.
I'll only have 2 sessions on each MX80, so I think I might leave it
enabled, but may toy with the interval. I'm expecting the control
pla
Hello, David
It looks like BFD implementation in MX80 is not distributed. At this
moment I have a case in JTAC. The case is opened yet, however, it
_looks_like_ bfd is not distributed.
Probably because of this BFD echomode is not supported. And using 30ms
timers for BFD ControlPackets can be not s
MX80s running 10.3R2.11
For those of you using BFD for OSPF, how low have you been able to
set your minimum-interval timer? I have a pair of MX80s connected via
XFPs and 1m patch cables and with my hellos set to 30ms and multiplier
set to 3, I'm seeing failures. I haven't disabled distributed
Yes you can use BFD for this. However as these are low end devices BFD runs
centrally on the cpu. I would just lower the vrrp timetable instead. Set
them down to one second advertisements.
Hth
Chris
On Jul 23, 2010 8:09 AM, "Nick Ryce" wrote:
Hi Guys,
I have searched through this list and al
Hi Guys,
I have searched through this list and also on juniper and cant find an answer.
Is it possible to use BFD on a j2320/j6350 to make the router become either
backup/master on a vrrp group?
Nick
--
This email and any files transmitted with it are confide
Sean
One router have other one i will check. is there any other step to find issue
or specially in config.
Thanks Sean
FAS
> Date: Wed, 10 Feb 2010 16:48:21 +0100
> From: sean1...@gmail.com
> To: fahadaq...@hotmail.com
> Subject: Re: [j-nsp] BFD over MPLS RSVP
>
> Do
Hi Experts
I have 2 M320 ( P )routers Junos 9.3S2.1 connected with Gig ports and other
vendor routers.
I m trying to enable BDF over rsvp. BDF session is not create even with Juniper
router like i run # sh bfd session.
my config.
mpls {
path-mtu {
rsvp mtu-signaling;
}
On Tue, Dec 15, 2009 at 11:03:08PM -0600, Kevin Day wrote:
>
> I went back and forth on this forever (pestering you while doing it),
> because it was affecting us badly on old M20s. My "lab" boxes would
> never ever show the problem, but it would happen in on the production
> routers. I fina
On Dec 9, 2009, at 5:21 PM, Richard A Steenbergen wrote:
The behavior we've always seen (from mid 7.x's until today) is that
something seems to "block" the KRT queue while the pending changes
keep
piling up, then eventually whatever is causing the blockage clears and
all the routes quickly i
In lab tests, RSVP success during ISSU was hit-or-miss. There were several
cases that is did work but It seemed to be not entirely based on
configuration (some degree of random failure). AFAIK it still hasn't been
officially listed as supported in release notes or upgrade guides. Am I
missing so
On Tue, Dec 15, 2009 at 04:53:44PM +0800, Mark Tinka wrote:
> We've always been in favour of the NSR concept since
> inception, but the reason we didn't choose it at the time
> was because of limited protocol support (early days of JUNOS
> 9.x). Also, only a handful of boxes on the Cisco side
>
On Tuesday 15 December 2009 04:16:23 pm Richard A
Steenbergen wrote:
> As for GR vs NSR, we're actually in the process of
> turning GR off in favor of NSR. So far, in very limited
> tests mind you, ISSU has actually worked for us without
> anything exploding or catching on fire (surprising I
>
On Tue, Dec 15, 2009 at 02:59:04PM +0800, Mark Tinka wrote:
> On Monday 14 December 2009 05:23:45 pm Richard A Steenbergen
> wrote:
>
> > Oh what good timing, just had to reboot a router tonight
> > to recover from a differnet Juniper bug (enabling
> > graceful-switchover on a 9.5R3 box caused
On Monday 14 December 2009 05:23:45 pm Richard A Steenbergen
wrote:
> Oh what good timing, just had to reboot a router tonight
> to recover from a differnet Juniper bug (enabling
> graceful-switchover on a 9.5R3 box caused blackholing of
> traffic, disabling it didn't fix it, had to reboot the
Thanks for all the great info Richard...
-Hoogen
On Mon, Dec 14, 2009 at 1:23 AM, Richard A Steenbergen wrote:
> On Sun, Dec 13, 2009 at 03:11:29AM -0600, Richard A Steenbergen wrote:
> > That one is pretty different from the usual slowness issue that seems to
> > be affecting most people. I jus
On Sun, Dec 13, 2009 at 03:11:29AM -0600, Richard A Steenbergen wrote:
> That one is pretty different from the usual slowness issue that seems to
> be affecting most people. I just cleared bgp sessions on a router to
> demonstrate the issue, which you can portions of any time you make a
> major rou
On Fri, Dec 11, 2009 at 02:50:51PM -0500, Ross Vandegrift wrote:
> On Wed, Dec 09, 2009 at 05:21:21PM -0600, Richard A Steenbergen wrote:
> > I've personally never had any luck reproducing it in the lab, so I
> > understand Juniper's frustration. It seems to require a complexity of
> > routes, port
On Wed, Dec 09, 2009 at 05:21:21PM -0600, Richard A Steenbergen wrote:
> I've personally never had any luck reproducing it in the lab, so I
> understand Juniper's frustration. It seems to require a complexity of
> routes, ports, and/or protocols which we simply don't have the time or
> money to rep
On Wed, Dec 09, 2009 at 09:13:28AM -0700, David Ball wrote:
> Do your KRT queues eventually flush though? Is it just a slow
> control->fwding thing when large route updates occur? I've done 2
> upgrades in as many years to resolve a KRT related bug, but that
> resulted in the queue NEVER emptying
Do your KRT queues eventually flush though? Is it just a slow
control->fwding thing when large route updates occur? I've done 2
upgrades in as many years to resolve a KRT related bug, but that
resulted in the queue NEVER emptying. It's apparently related to a
residual variable being set after
On Wednesday 09 December 2009 05:40:00 pm Richard A
Steenbergen wrote:
> Nothing current, it ended up spread out over a bunch of
> cases which all got closed with no real resolution to
> the root problem. Everyone I've talked to at Juniper
> knows that the problem exists, they just don't know
On Wed, Dec 09, 2009 at 11:04:59AM +0200, Pekka Savola wrote:
> On Wed, 9 Dec 2009, Richard A Steenbergen wrote:
> >Oh and btw I take back all the nice things I said about progress being
> >made to resolve the slow fib install / krt queue blocking bug. It is
> >still alive and well in 9.5R3, and bl
On Wed, 9 Dec 2009, Richard A Steenbergen wrote:
Oh and btw I take back all the nice things I said about progress being
made to resolve the slow fib install / krt queue blocking bug. It is
still alive and well in 9.5R3, and blackholing traffic more than ever
(just recorded a good 10 minutes of it
On Wed, Dec 09, 2009 at 12:27:55AM -0600, Richard A Steenbergen wrote:
> Maybe, but I'm not sufficiently motivated to try and explain the issue
> to JTAC to find out. :) FWIW we've now upgraded 3 of the MX960s that had
> the issue from 9.2R4->9.5R3 and it resolved things completely. 9.2R4 is
> a gi
On Tue, Dec 08, 2009 at 07:54:49PM -0500, Ross Vandegrift wrote:
> On Fri, Dec 04, 2009 at 02:40:14PM -0600, Richard A Steenbergen wrote:
> > FYI I found the root problem and hereby take back any comments impugning
> > BFD's reputation. It turns out there actually WAS some kind of pfe bug
> > which
On Fri, Dec 04, 2009 at 02:40:14PM -0600, Richard A Steenbergen wrote:
> FYI I found the root problem and hereby take back any comments impugning
> BFD's reputation. It turns out there actually WAS some kind of pfe bug
> which was causing intermittent blackholing of traffic for a few seconds
> at a
On Sat, Nov 21, 2009 at 05:16:57PM -0600, Richard A Steenbergen wrote:
> On Sat, Nov 21, 2009 at 12:53:58PM -0800, Nilesh Khambal wrote:
> > Hi Richard,
> >
> > Just talking from this router perspective, it looks like the remote
> > end router has problem receiving BFD packets from this router. It
On Sat, Nov 21, 2009 at 12:53:58PM -0800, Nilesh Khambal wrote:
> Hi Richard,
>
> Just talking from this router perspective, it looks like the remote
> end router has problem receiving BFD packets from this router. It
> signaled the BFD session down because of that.
There are actually two particu
[Hit send accidently before completing the email]
You can narrow down the pfe stats per FPC using the "fpc" knob in the "show
pfe statistics traffic" output.
At the remote end, you can look for any input errors (framing, CRC etcs) at
the interface level. Then look for any drops at the route looku
Hi Richard,
Just talking from this router perspective, it looks like the remote end
router has problem receiving BFD packets from this router. It signaled the
BFD session down because of that.
You can start by looking at egress stats at the on the local router. See if
there are any ttp queue drop
Is there a way to see stats on bfd sessions, such as the number of
probes lost? I'm trying to figure out why I can't reliably keep bfd
running between two Juniper's without getting a ton of false positives,
even with very high detection thresholds. Nothing useful in "show bfd
session extensive" (be
Hi David,
we were using both version 9.2 and 9.4 with mpls oam feature, but as fas as
I know Cisco does not support this functionality. For testing BFD we teared
down logical interface, so the meaning of BFD actually come in place
(physical port stayed up).
On Cisco side I saw that BFD actually t
How long does it take for your FRR to kick in? Is your logical or
physical link actually down (you mention both below) ? I imagine if
you want BFD-speed failover, you may want to look at 9.4, which
apparently supports BFD for LDP and RSVP sessions.
David
On 03/04/2009, Robert Kern wrote:
>
Hi all,
we have run into a problem with BFD between Cisco and Juniper box when
MPLS-FRR is configured.
ISIS is used as IGP protocol and one hop MPLS-TE tunnels are configured with
link protection. BFD is configured on both sides (under IS-IS protocol).
After primary logical link is dropped betwee
On Wednesday 03 December 2008 14:11:38 Richard A Steenbergen
wrote:
> BFD on a LAG is completely pointless. The BFD packets
> will only be transmitted over a single member link (since
> BFD works at the IP layer, and will be hashed onto one
> member), and you have no guarantee that the return
> p
1 - 100 of 115 matches
Mail list logo
