Re: Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general

2017-06-22 Thread Joel Jaeggli


Sent from my iPhone

> On Jun 22, 2017, at 07:38, Eric Dugas  wrote:
> 
> Hello,
> 
> We're planning to phase out some 10G link-aggregations in favor of 100G
> interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and
> Fiberstore CFPs.
> 
> I've been told that CFPs (in general) weren't that reliable. They were
> kinda "replaced" almost a year and a half or so after its introduction by
> CFP2 and then by CFP4 and so on. Size and power consumption aside, are the
> MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of
> the 100GBase?

CFP has been around a while, like 8 years at this point. CFP2 and CFP4 are 
significantly smaller have accordingly lower power budgets and do not include 
the DSP on board (the linecard for cfp/2/4/8 differs significantly respecting 
level of integration components and so forth and also port count).

Apart from the resulting low port density per card, which makes them unsuitable 
for a number applications they're mature products at this point.
> 
> Eric
> 



Re: IPv6 traffic percentages?

2017-06-22 Thread Mukom Akong T.
On 18 June 2017 at 17:36, Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net> wrote:

> so for the record, business customers are much more active in
> *rejecting* IPv6, either explictely (they say they want it disabled) or
> implicitly (they install their own router, not configured for IPv6). The
> bigger the business, the bigger the chance of rejection.
>


Did they per chance state their reasons for rejecting it?


-- 

Mukom Akong T.

LinkedIn:Mukom   |  twitter:
@perfexcellent


--
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
---


Re: PCIe adapters supporting long distance 10GB fiber?

2017-06-22 Thread Jason Alderfer
On Tue, Jun 20, 2017 at 11:15 AM, Baldur Norddahl  wrote:

> The real question here is: will my NIC support other SFP+ modules than the
> few options carried by the NIC vendor?



Has anyone tried changing the vendor ID of an SFP+ with one of these?
https://sfptotal.com/

I am highly intrigued and skeptical.

Jason


Re: Long AS Path

2017-06-22 Thread Steve Lalonde
Mel,

There was a Cisco bug many years ago that caused lots of issues. Since then we 
have limited max-as to 50 and it has not caused any reported issues yet.

Link that does not require a CCO login to view.
http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html

Regards

Steve Lalonde


> On 21 Jun 2017, at 16:49, Mel Beckman  wrote:
> 
> Steinar,
> 
> What reason is there to filter them? They are not a significant fraction of 
> BGP paths. They cause no harm. It's just your sense of tidiness. 
> 
> You might consider contacting one of the operators to see if they do have a 
> good reason you haven't considered. But absent a good reason *to* filter 
> them, I would let BGP mechanics work as intended.
> 
> -mel beckman
> 
> On Jun 21, 2017, at 12:57 AM, "sth...@nethelp.no"  wrote:
> 
>>> Just wondering if anyone else saw this yesterday afternoon ?
>>> 
>>> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH=3D AS_SEQ(2=
>>> ) 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 234=
>>> 56 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 =
>>> 23456 23456 23456 23456 23456 ... attribute length (567) More than configur=
>>> ed MAXAS-LIMIT
>> 
>> There are quite a few examples of people using stupidly long AS paths.
>> For instance
>> 
>> 177.23.232.0/24*[BGP/170] 00:52:40, MED 0, localpref 105
>> AS path: 6939 16735 28163 28163 28163 28163 28163 28163 
>> 28163 28163 28163 28163 28163 28163 28163 28163 28163 28163 262401 262401 
>> 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 262401 
>> 262401 262401 262401 262949 52938 52938 52938 52938 52938 52938 52938 52938 
>> 52938 52938 52938 I
>> 
>> I currently have 27 prefixes in my Internet routing table with 40 or
>> more ASes in the AS path (show route aspath-regex ".{40,}").
>> 
>> I see no valid reason for such long AS paths. Time to update filters
>> here. I'm tempted to set the cutoff at 30 - can anybody see a good
>> reason to permit longer AS paths?
>> 
>> Steinar Haug, Nethelp consulting, sth...@nethelp.no



Re: PCIe adapters supporting long distance 10GB fiber?

2017-06-22 Thread Oliver Elliott
I have used 3rd party Cisco coded optics in an Intel SFP card successfully,
but it won't be "officially supported".

Oli

On 20 June 2017 at 16:15, Baldur Norddahl  wrote:

> The real question here is: will my NIC support other SFP+ modules than the
> few options carried by the NIC vendor?
>
> For example Intel claims the Intel NICs can only accept SFP+ modules by
> Intel. They probably do not make optics themselves and only have few
> options available. And indeed if you put in a third party optic it will be
> rejected.
>
> There are two ways around that. One is finding a device driver with vendor
> check disabled. The other option is to get optics that pretend to be Intel.
>
> You can get optics with vendor ID many places. A good place to start is
> Fiberstore fs.com because they have public pricing on the website.
>
> With the vendor id the answer to the question is that all NICs with SFP+ I
> ever heard about will support any range, WDM or other special SFP+ module.
>
> Regards,
>
> Baldur
>
>
> Den 20. jun. 2017 02.59 skrev "chiel" :
>
> > Hello,
> >
> > We are deploying more and more server based routers (based on BSD). We
> > have now come to the point where we need to have 10GB uplinks one these
> > devices and I prefer to plug in a long range 10GB fiber straight into the
> > server without it going first into a router/switch from vendor x. It
> seems
> > to me that all the 10GB PCIe cards only support either copper 10GBASE-T,
> > short range 10GBASE-SR or the 10 Km 10GBASE-LR (but only very few). Are
> > there any PCIe cards that support 10GBASE-ER and 10GBASE-ZR? I can't seem
> > to find any.
> >
> > Chiel
> >
>



-- 
Oliver Elliott
Senior Network Specialist
IT Services, University of Bristol
t: 0117 39 (41131)


Re: Long AS Path

2017-06-22 Thread Jakob Heitz (jheitz)
23456 is AS_TRANS. Either your router does not support 4 byte AS or there is a 
bug at AS 12956 or AS 12956 is intentionally prepending 23456.

Thanks,
Jakob.


> 
> Date: Tue, 20 Jun 2017 23:12:45 +
> From: James Braunegg 
> To: "nanog@nanog.org" 
> Subject: Long AS Path
> Message-ID: 
> Content-Type: text/plain; charset="us-ascii"
> 
> Dear All
> 
> Just wondering if anyone else saw this yesterday afternoon ?
> 
> Jun 20 16:57:29:E:BGP: From Peer 38.X.X.X received Long AS_PATH= AS_SEQ(2) 
> 174 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 
> 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 
> 23456 23456 23456 23456 ... attribute length (567) More than configured 
> MAXAS-LIMIT
> 
> Jun 20 16:15:26:E:BGP: From Peer 78.X.X.X received Long AS_PATH= AS_SEQ(2) 
> 5580 3257 12956 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 
> 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 23456 
> 23456 23456 23456 23456 ... attribute length (568) More than configured 
> MAXAS-LIMIT
> 
> Someone is having fun, creating weird and wonderful long AS paths based 
> around AS 23456, we saw the same pattern of data from numerous upstream 
> providers.
> 
> Kindest Regards,
> 
> James Braunegg
> 
> 


Reliability of Juniper MIC3-3D-1X100GE-CFP and CFP in general

2017-06-22 Thread Eric Dugas
Hello,

We're planning to phase out some 10G link-aggregations in favor of 100G
interfaces. We've been looking at buying MIC3-3D-1X100GE-CFP, MPC3E and
Fiberstore CFPs.

I've been told that CFPs (in general) weren't that reliable. They were
kinda "replaced" almost a year and a half or so after its introduction by
CFP2 and then by CFP4 and so on. Size and power consumption aside, are the
MIC3-3D-1X100GE-CFP and CFP modules reliable at all? Are they the SFP-TX of
the 100GBase?

Eric


Re: Long AS Path

2017-06-22 Thread Mel Beckman
You don't have to wonder. You can call and ask them. 

-mel via cell

> On Jun 22, 2017, at 5:47 AM, jim deleskie  wrote:
> 
> I see 5+ prepends as maybe not reason to have your "BGP driving license
> revoked" but if I can continue with the concept that you have your BGP
> learners permit.
> If I think back to when I learned to code or when making ACL's,  we still
> used line number and practice would be to give ourselves lots
> of space 5 or 10 numbers in case we have to insert something in the middle.
> ie I need 2 sets of prepends, I'm still learning this stuff
> so I'll go with 5 and 10. We all started somewhere, we all did dumb stuff,
> hopefully, we all learned.
> 
> 12AS hops, I have to go see how they are connected now, maybe someone in
> that chain needs to be invited by an IX to a NANOG or GPF or some such,
> that can't be super efficient.
> 
> -jim
> 
> On Thu, Jun 22, 2017 at 3:09 AM, Pierfrancesco Caci  wrote:
> 
>>> "Mel" == Mel Beckman  writes:
>> 
>> 
>>Mel> Why not ask the operator why they are pretending this path?
>> Perhaps
>>Mel> they have a good explanation that you haven't thought of. Blindly
>>Mel> limiting otherwise legal path lengths is not a defensible
>> practice, in
>>Mel> my opinion.
>> 
>>Mel>  -mel beckman
>> 
>> 
>> A prepend like that is usually the result of someone using the IOS
>> syntax on a XR or Junos router.
>> 
>> Long ago, someone accidentally prepending 255 times hit a bug (or was it
>> a too strict bgp implementation? I don't remember) resulting in several
>> networks across the globe dropping neighbors. One has to protect against
>> these things somehow.
>> 
>> As a data point, here is how many prefixes I see on my network for each
>> as-path length, after removing prepends:
>> 
>> 
>> aspath length   count
>> -
>>0:  340
>>1:  47522
>>2:  292879
>>3:  227822
>>4:  58390
>>5:  10217
>>6:  2123
>>7:  638
>>8:  48
>>9:  58
>>11: 20
>>12: 2
>> 
>> 
>> So, does your customer have a legitimate reason to prepend more than 5
>> times? Maybe. I still think that anyone that does should have their BGP
>> driving licence revoked, though.
>> 
>> Pf
>> 
>> 
>> 
>> 
>> --
>> Pierfrancesco Caci, ik5pvx
>> 


Re: Long AS Path

2017-06-22 Thread Stephen Satchell
On 06/22/2017 04:27 AM, Jon Lewis wrote:
> 
> You do have to wonder, what was the thought process that resulted in 35
> being the right number of prepends "accomplish" whatever TE they were
> shooting for?
> 
> AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644
> 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
> 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
> 55644 55644 55644 45271
> 
> I don't mean to single out 55644.  It's just the first/most obnoxiously
> long as-path I found when looking for long ones.
> 
> I seriously doubt provider/customer/customer-of-customer relationships
> ever get much deeper than a handful or so of ASNs...so if prepending a
> few times doesn't get it done, 10-20-30 prepends are unlikely to help.
> 
> In the above case, that long path is actually our best path.  We
> localpref peering above transit.  So, it doesn't matter how many
> prepends, they add, we're never going to not use this path if its
> available.  We have transit paths to these routes that are only a single
> handful of ASNs long.


I think I understand the problem, and now I understand why prepends
didn't do much for me.  Over the years, I tended two multi-homed sites.
In both cases, the two uplinks had different speeds.  When I used
prepend to try to get the outside world to prefer the faster link, some
traffic was stubborn about coming in the slow one.

Difference in speeds?  In the first network it was 45 mbps and 10 mbps.
In the second network it was 16 mbps and 1.5 mbps.  Both network owners
were too stingy at the time to opt for harmonized rates.

Question:  how could communities be used to "force" preference for one
uplink over another by the peers?  I'm long past needing this, but
others might benefit.  (And when you stop learning, you're dead.)


Re: Long AS Path

2017-06-22 Thread jim deleskie
I see 5+ prepends as maybe not reason to have your "BGP driving license
revoked" but if I can continue with the concept that you have your BGP
learners permit.
If I think back to when I learned to code or when making ACL's,  we still
used line number and practice would be to give ourselves lots
of space 5 or 10 numbers in case we have to insert something in the middle.
ie I need 2 sets of prepends, I'm still learning this stuff
so I'll go with 5 and 10. We all started somewhere, we all did dumb stuff,
hopefully, we all learned.

12AS hops, I have to go see how they are connected now, maybe someone in
that chain needs to be invited by an IX to a NANOG or GPF or some such,
that can't be super efficient.

-jim

On Thu, Jun 22, 2017 at 3:09 AM, Pierfrancesco Caci  wrote:

> > "Mel" == Mel Beckman  writes:
>
>
> Mel> Why not ask the operator why they are pretending this path?
> Perhaps
> Mel> they have a good explanation that you haven't thought of. Blindly
> Mel> limiting otherwise legal path lengths is not a defensible
> practice, in
> Mel> my opinion.
>
> Mel>  -mel beckman
>
>
> A prepend like that is usually the result of someone using the IOS
> syntax on a XR or Junos router.
>
> Long ago, someone accidentally prepending 255 times hit a bug (or was it
> a too strict bgp implementation? I don't remember) resulting in several
> networks across the globe dropping neighbors. One has to protect against
> these things somehow.
>
> As a data point, here is how many prefixes I see on my network for each
> as-path length, after removing prepends:
>
>
> aspath length   count
> -
> 0:  340
> 1:  47522
> 2:  292879
> 3:  227822
> 4:  58390
> 5:  10217
> 6:  2123
> 7:  638
> 8:  48
> 9:  58
> 11: 20
> 12: 2
>
>
> So, does your customer have a legitimate reason to prepend more than 5
> times? Maybe. I still think that anyone that does should have their BGP
> driving licence revoked, though.
>
> Pf
>
>
>
>
> --
> Pierfrancesco Caci, ik5pvx
>


Re: Long AS Path

2017-06-22 Thread Jon Lewis

On Wed, 21 Jun 2017, Saku Ytti wrote:


Hey,

Uou're saying, you drop long AS_PATH, to improve customer observed
latency? Implication being, because you dropped the long AS_PATH
prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?

Absent of this policy, in which scenario would you have inserted the
filtered longer AS_PATH prefix to the FIB? I assume only scenario
where this happens is where there is larger aggregate route, which is
lower latency than the more specific route with longer as_path.



You do have to wonder, what was the thought process that resulted in 35
being the right number of prepends "accomplish" whatever TE they were
shooting for?

AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644
55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
55644 55644 55644 45271

I don't mean to single out 55644.  It's just the first/most obnoxiously
long as-path I found when looking for long ones.

I seriously doubt provider/customer/customer-of-customer relationships 
ever get much deeper than a handful or so of ASNs...so if prepending a few 
times doesn't get it done, 10-20-30 prepends are unlikely to help.


In the above case, that long path is actually our best path.  We localpref 
peering above transit.  So, it doesn't matter how many prepends, they add, 
we're never going to not use this path if its available.  We have transit 
paths to these routes that are only a single handful of ASNs long.


--
 Jon Lewis, MCP :)   |  I route
 |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_


Re: IPv6 traffic percentages?

2017-06-22 Thread Mikael Abrahamsson

On Thu, 22 Jun 2017, Radu-Adrian Feurdean wrote:


To make it short : education. And we as as small ISP we have neither the
resources, nor the motivation (because $$$ on the issue is negative) to
do it (the education).


An ISP should be an enabler, and have a service portfolio to cover most 
customers need. Not all customers will want all the services, so if a 
customer doesn't want IPv6 then fine, turn it off for them. When they come 
back later and want it, they know you have it.


You've done your part, and that's great!

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: IPv6 traffic percentages?

2017-06-22 Thread Radu-Adrian Feurdean
On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
> 
> On 18 June 2017 at 17:36, Radu-Adrian Feurdean  adrian.feurdean.net> wrote:>> so for the record, business customers are much 
> more active in
>>  *rejecting* IPv6, either explictely (they say they want it
>>  disabled) or>>  implicitly (they install their own router, not configured 
>> for
>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
> 
> 
> Did they per chance state their reasons for rejecting it?

Not explicitly. But when we get something like "turn off that IPv6 crap
!" we take it for: - they don't have a clearly defined need for it
 - they don't know how to deal with it
 - they don't want to deal with things they don't need (see the
   irst point)... usually all of them at the same time.

To make it short : education. And we as as small ISP we have neither the
resources, nor the motivation (because $$$ on the issue is negative) to
do it (the education).
--
R-A.F.


Re: Long AS Path

2017-06-22 Thread Pierfrancesco Caci
> "Mel" == Mel Beckman  writes:


Mel> Why not ask the operator why they are pretending this path? Perhaps
Mel> they have a good explanation that you haven't thought of. Blindly
Mel> limiting otherwise legal path lengths is not a defensible practice, in
Mel> my opinion.

Mel>  -mel beckman


A prepend like that is usually the result of someone using the IOS
syntax on a XR or Junos router.

Long ago, someone accidentally prepending 255 times hit a bug (or was it
a too strict bgp implementation? I don't remember) resulting in several
networks across the globe dropping neighbors. One has to protect against
these things somehow. 

As a data point, here is how many prefixes I see on my network for each
as-path length, after removing prepends:


aspath length   count
-
0:  340
1:  47522
2:  292879
3:  227822
4:  58390
5:  10217
6:  2123
7:  638
8:  48
9:  58
11: 20
12: 2


So, does your customer have a legitimate reason to prepend more than 5
times? Maybe. I still think that anyone that does should have their BGP
driving licence revoked, though.

Pf




-- 
Pierfrancesco Caci, ik5pvx