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
On Friday, December 30, 2011 02:48:33 AM Mark Smith wrote:
> I would not expect the L2 service provider to be able to
> tunnel ethernet OAM (CCM etc) traffic.
If the provider's archiecture is VLAN-based pw's, then yes,
it's possible they may not be able to tunnel all Layer 2
protocols running b
On 12/29/11 1:48 PM, "Mark Smith" wrote:
>On Thu, Dec 29, 2011 at 6:45 PM, Phil Bedard wrote:
>> BFD on the IGP session would be the best option. We currently run ours
>>at 300x3 on Juniper boxes and lower on some other platforms with better
>>hardware processing of BFD packets. If you are u
Yeah slightly baffling that one - all these Ethernet devices that only pass
payloads of arp, ipv4 and ipv6, or to normal unicast addresses.
No-one has ever given me a good explanation of what this kit *is* doing with
these frames...
(talking about passing .ag here of course - not participating,
On Thu, Dec 29, 2011 at 6:45 PM, Phil Bedard wrote:
> BFD on the IGP session would be the best option. We currently run ours at
> 300x3 on Juniper boxes and lower on some other platforms with better hardware
> processing of BFD packets. If you are using aggregates something like
> 802.3ah ma
On 29 December 2011 11:48, Mark Smith wrote:
> Correct me if I am wrong, but doesn't enabling BFD on the IGP cause
> IGP to reconverge in case of fault?
yes
> Is there any (reasonable) way to utilize link-node-protection or FRR
> if link state information is not usable between MPLS routers? O
On Dec 29, 2011, at 2:36 PM, Phil Mayers wrote:
> On 12/29/2011 06:48 PM, Mark Smith wrote:
>
>> I would not expect the L2 service provider to be able to tunnel
>> ethernet OAM (CCM etc) traffic.
>
> In general, or in this specific case?
>
> (I have high hopes for Ethernet OAM eventually, but
On 12/29/2011 06:48 PM, Mark Smith wrote:
I would not expect the L2 service provider to be able to tunnel
ethernet OAM (CCM etc) traffic.
In general, or in this specific case?
(I have high hopes for Ethernet OAM eventually, but from what I can tell
at the moment, it's still not quite there y
BFD on the IGP session would be the best option. We currently run ours at
300x3 on Juniper boxes and lower on some other platforms with better hardware
processing of BFD packets. If you are using aggregates something like 802.3ah
may work better as BFD control traffic has a tendency to just t
On Friday, December 30, 2011 12:12:43 AM David Ball wrote:
> Ditto. We dialed our BFD down (up?) in our agg rings
> to around 150ms 'hellos' since we have MX80s which don't
> yet support distribution of BFD to the PFE. Any lower
> than that and we started to see false positives, though
> YMMV.
On 29 December 2011 01:46, Mark Tinka wrote:
> On Thursday, December 29, 2011 03:49:25 PM Mark Smith wrote:
>> Which one of them (if any) is the best solution?
>
> We enable BFD on the IGP only. The IGP drives everything
> (iBGP, LDP, RSVP, e.t.c.). If that is stable, all other
> protocols will t
On Thu, Dec 29, 2011 at 12:40 AM, Doug Hanks wrote:
> You can actually configure 50G worth of tunnel-services on the MX80. 10g
> worth on FPC0 and 40G worth on FPC1. You need to be running Junos 10.2R4.
> All of this without losing any revenue ports, but at the cost of
> over-subscribing them.
On Thursday, December 29, 2011 03:49:25 PM Mark Smith wrote:
> I have spent some time searching for a solution. I have
> found these: 1) enable BFD on the IGP session
> 2) enable BFD on the LSPs
> 3) enable BFD on the RSVP session
>
> Which one of them (if any) is the best solution?
We enable BF
14 matches
Mail list logo