Re: Brocade SLX Internet Edge

[Youssef Bengelloun-Zahr]

Last I heard (before switching shops), not yet it won’t.

Best regards.



> Le 31 oct. 2018 à 21:56, Aaron  a écrit :
> 
> It won't hold a full table. 256,000 IPv4 and 64,000 IPv6 routes.
> 
> 
>> On 10/31/2018 3:01 PM, Kevin Burke wrote:
>> Does anyone have any success with the Brocade SLX 9540 or similar?  Its 
>> going to be taking full BGP tables from two Tier1's and some peering.
>> 
>> The specs and sales rep says its fine, but the price makes me think its too 
>> good to be true.
>> 
>> We are trying to shepherd an old Cat 6509 out of our core.
>> 
>> 
>> Kevin Burke
>> 802-540-0979
>> Burlington Telecom - City of Burlington
>> 200 Church St, Burlington, VT 05401
>> 
> 
> -- 
> 
> Aaron Wendel
> Chief Technical Officer
> Wholesale Internet, Inc. (AS 32097)
> (816)550-9030
> http://www.wholesaleinternet.com
> 
> 

Re: Time to add 2002::/16 to bogon filters?

[Youssef Bengelloun-Zahr]

Hello Scott,

I believe Gary has already provided the community with an official answer 
yesterday on Team Cymru’s behalf.

Best regards.



> Le 5 juil. 2018 à 21:17, Scott Fisher  a écrit :
> 
> Youssef & all,
> 
> My team will investigate this and get back to the list on what we are
> going to do.
> 
> Thanks,
> Scott Fisher
> Systems Engineer
> Team Cymru
> 
> 
> On 6/28/18 3:11 PM, Youssef Bengelloun-Zahr wrote:
>> Hello Job,
>> 
>> Thank you for this feedback. I guess that NTT adopting this as a best 
>> practice will ring some bells around.
>> 
>> Do you know if Team Cymru has updated their filters accordingly ?
>> 
>> Best regards.
>> 
>> 
>> 
>>> Le 28 juin 2018 à 20:58, Job Snijders  a écrit :
>>> 
>>> Dear alll,
>>> 
>>> Thank you all for your input. Just a heads-up - we deployed a few days ago.
>>> 
>>> NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32”
>>> to be bogon prefixes, and no longer accepts announcements for these
>>> destinations from any EBGP neighbor.
>>> 
>>> Kind regards,
>>> 
>>> Job
> 

Re: Time to add 2002::/16 to bogon filters?

[Youssef Bengelloun-Zahr]

Hello Job,

Thank you for this feedback. I guess that NTT adopting this as a best practice 
will ring some bells around.

Do you know if Team Cymru has updated their filters accordingly ?

Best regards.



> Le 28 juin 2018 à 20:58, Job Snijders  a écrit :
> 
> Dear alll,
> 
> Thank you all for your input. Just a heads-up - we deployed a few days ago.
> 
> NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32”
> to be bogon prefixes, and no longer accepts announcements for these
> destinations from any EBGP neighbor.
> 
> Kind regards,
> 
> Job

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Youssef Bengelloun-Zahr]

Still believe in santa ?   ;-)

Good luck with that.

Best regards.



2018-04-03 8:37 GMT+02:00 Marty Strong via NANOG :

> Orange France is known, they just didn’t tell us the exact reason.
>
> They said that if you contact them, they’ll provide you with an official
> explanation.
>
> Regards,
> Marty Strong
> --
> Cloudflare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
>
> https://www.peeringdb.com/asn/13335
>
> > On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン)  wrote:
> >
> > Hello,
> >
> > On Mon, 2 Apr 2018 16:26:13 +0100
> > Marty Strong via NANOG  wrote:
> >
> >> So far we know about a few CPEs which answer for 1.1.1.1 themselves:
> >>
> >> - Pace 5268
> >> - Calix GigaCenter
> >> - Various Cisco Wifi access points
> >>
> >> If you know of others please send them my way so we can investigate.
> >
> > It seems that in France, Orange's Livebox is also using 1.1.1.1 is some
> > way...
> >
> > 215 [6:20] rol@riri:~> traceroute 1.1.1.1
> > traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
> > 1  * * *
> > 2  * * *
> > 3  * * *
> > 4  * * *
> >
> > 216 [6:20] rol@riri:~> ping 1.1.1.1
> > PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
> > 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms
> > 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms
> > ^C
> > --- 1.1.1.1 ping statistics ---
> > 2 packets transmitted, 2 received, 0% packet loss, time 1037ms
> > rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms
> >
> > 217 [6:20] rol@riri:~> traceroute 8.8.8.8
> > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> > 1  livebox.home (192.168.1.254)  0.268 ms  0.236 ms  0.263 ms
> > 2  * * *
> > 3  ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138)  1.724
> ms  1.733 ms  1.793 ms
> > ...
> >
> > That IP address is definitely full of magic...
> >
> > Paul
> >
> >
>
>

Re: Yet another Quadruple DNS?

[Youssef Bengelloun-Zahr]

Hi,

Maybe this links will help :

https://blog.cloudflare.com/dns-resolver-1-1-1-1/

https://blog.cloudflare.com/announcing-/

Best regards.



> Le 1 avr. 2018 à 19:05, Mike Hammett  a écrit :
> 
> Unless you want optimum CDN performance, then your recursive servers belong 
> pushed back in your network until there are no more diverse upstream\peer 
> paths to choose from. 
> 
> Yes, I know there's an extension to DNS to help remove this need, but until 
> that's universally supported, you can't abandon the old way. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Stephen Satchell"  
> To: nanog@nanog.org 
> Sent: Sunday, April 1, 2018 11:22:10 AM 
> Subject: Re: Yet another Quadruple DNS? 
> 
>> On 04/01/2018 08:18 AM, Matt Hoppes wrote: 
>> Why not just implement recursive cache severs on end user routers? 
>> Why does an end user CPE need to query one or two specific DNS 
>> servers? 
> Recursive lookups take bandwidth and wall time. The closer you can get 
> your recursive DNS server to the core of the internet, the faster the 
> lookups. This is particularly true of mobile and satellite. 
> 
> Implementing large caches in that close-to-the-core DNS server can add 
> another benefit: lookups to common and popular endpoints, such as 
> Google, would require far less real time to resolve. As the traffic 
> tides change, the cache would change with it, so flash-in-the-pan sites 
> would be served from cache, and forgotten in time when said sites drift 
> back to obscurity. 
> 
> (I wonder if the Internet Systems Consortium has considered adding a 
> cache-hit counter, or even a very coarse heat map (say, four 16-bit 
> counters cycled every five minutes), to DNS entries, to figure out the 
> best ones to drop? It would increase the complexity of BIND, but the 
> benefit for a BIND server serving a largish customer population could be 
> significant. If I were younger, I might try to model such a change. 
> Sort by hits, then by time-to-die. Drop the oldest 250 or so entries 
> when the cache is full. That way, the oldest least-used cache entries 
> get dropped.) 
> 
> ISPs provide to their customers DNS addresses to servers that, 
> allegedly, are closer to the core than the customers are. (Pipe dream, 
> I know; which is why so many ISPs have decided to specify 8.8.8.8 and 
> 8.8.4.4, because Google is closer to the core than the ISP is.) 
> 
> I've not personally measured the number of times a look-up could be 
> satisfied from a cache in a production environment; it's been 15 years 
> since I worked in such a job. It would be interesting to see if someone 
> has taken the time to gather those statistics and published them. 
> 
> The main reason for *not* implementing recursion exclusively in CPE is 
> that a recursive lookup is a complex operation, and I have my doubts if 
> BIND or equivalent could be maintained properly in, say, a wireless 
> access point (router) -- how would you update a hints table? 
> 

Re: Brocade unsupported transceiver?

[Youssef Bengelloun-Zahr]

Hello Eric,

I got confused, you are absolutely right. Here is a thread I started a few
years ago when we bought our first units :

https://community.brocade.com/t5/Ethernet-Fabric-VDX-CNA/Passive-Twinax-cables-not-recognized-in-VDX-switches/td-p/28978

Best regards.



2018-03-21 23:58 GMT+01:00 Eric Litvin :

> You need to program the passive dac to look like an active dac. Brocade
> wants active.
>
> Ping me if you want help.
>
> Eric
>
> Sent from my iPhone
>
> > On Mar 21, 2018, at 3:36 PM, Mike Hammett  wrote:
> >
> > No one knows of such a command and apparently the VDX line is finicky
> with what passive DACs they'll work with. I just ordered more of the ones I
> know that work.
> >
> >
> > Tangent: Is it normal for these guys to still transmit light even when
> the interface is shut?
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > Midwest-IX
> > http://www.midwest-ix.com
> >
> > - Original Message -
> >
> > From: "Mike Hammett" 
> > To: "NANOG list" 
> > Sent: Wednesday, March 21, 2018 3:18:28 PM
> > Subject: Brocade unsupported transceiver?
> >
> > Anyone know if there is a command in Brocade NOS (4.x) to force the use
> of an unsupported transceiver? If so, what is it?
> >
> >
> >
> >
> > -
> > Mike Hammett
> > Intelligent Computing Solutions
> > http://www.ics-il.com
> >
> > Midwest-IX
> > http://www.midwest-ix.com
> >
>

Re: Brocade unsupported transceiver?

[Youssef Bengelloun-Zahr]

Yes, and they (old hardware plateformes) support only passive DAC. I remember 
being bitten by this at the time.

Tangent : hum 樂... doesn’t seem normal to me. Maybe a bug ?!?

Best regards.



> Le 21 mars 2018 à 23:36, Mike Hammett  a écrit :
> 
> No one knows of such a command and apparently the VDX line is finicky with 
> what passive DACs they'll work with. I just ordered more of the ones I know 
> that work. 
> 
> 
> Tangent: Is it normal for these guys to still transmit light even when the 
> interface is shut? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Mike Hammett"  
> To: "NANOG list"  
> Sent: Wednesday, March 21, 2018 3:18:28 PM 
> Subject: Brocade unsupported transceiver? 
> 
> Anyone know if there is a command in Brocade NOS (4.x) to force the use of an 
> unsupported transceiver? If so, what is it? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 

Re: Brocade unsupported transceiver?

[Youssef Bengelloun-Zahr]

Hi,

We have been (and still) using all kinds of brocade hardware, including VDX 
from early NOS2.x

AFAIK, I couldn’t find an equivalent command to « unsupported transceiver ». So 
you will always get a syslog message, but usually it won’t stop port from 
coming up.

Regarding to optical transceivers, re-encoded 3rd party transceivers work very 
well.

But when it comes to DAC, and we have tested a lot for them, usually we use « 
original » brocade DACs.

We also tested successfully IBM an CISCO DACs, they work just fine but you’ll 
the usual syslog message. However, DOM information might be incomplete.

Best regards.



> Le 21 mars 2018 à 21:31, Mike Hammett  a écrit :
> 
> I've had a few offlist responses looking for the same or about coded optics. 
> 
> I've been able to use Brocade -coded optics from FiberStore, but a DAC which 
> should be universal (and passes the muster for the Intel NICs it's plugged 
> into) returns, " 2018/03/21-15:14:00, [NSM-1028], 2679, DCE, ERROR, sw0, 
> Incompatible SFP transceiver for interface TenGigabitEthernet 54/0/16 is 
> detected." 
> 
> Unfortunately, show media doesn't help because the interface is offline. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 
> - Original Message -
> 
> From: "Mike Hammett"  
> To: "NANOG list"  
> Sent: Wednesday, March 21, 2018 3:18:28 PM 
> Subject: Brocade unsupported transceiver? 
> 
> Anyone know if there is a command in Brocade NOS (4.x) to force the use of an 
> unsupported transceiver? If so, what is it? 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> Midwest-IX 
> http://www.midwest-ix.com 
> 

Re: How are you configuring BFD timers?

[Youssef Bengelloun-Zahr]

Which platform ? What context ?

Best regards.



> Le 21 mars 2018 à 18:10, Jason Lixfeld <jason+na...@lixfeld.ca> a écrit :
> 
> A few years ago I did some testing and found that the time between the 
> transceiver detecting LOS and the routing protocol (ISIS in this case) being 
> informed that the link was down (triggering the recalculation) took longer 
> than it took BFD to signal ISIS to recalculate.
> 
>> On Mar 21, 2018, at 12:35 PM, Bryan Holloway <br...@shout.net> wrote:
>> 
>> Wouldn't any tangible problem on a dark-fiber link result in an interface 
>> shutdown, ostensibly creating the trigger one would need to begin 
>> re-convergence?
>> 
>> 
>>> On 3/21/18 11:31 AM, Alex Lembesis wrote:
>>> To speed up BGP routing convergence.  The (2x) dark fiber links from PA to 
>>> FL are being used as Layer3 datacenter interconnects, where each datacenter 
>>> has its own AS.  The DF is also carrying FCIP traffic, so we need failover 
>>> to be as fast as possible.
>>> Best regards,
>>> Alex
>>> -----Original Message-
>>> From: Job Snijders (External) [mailto:j...@instituut.net]
>>> Sent: Wednesday, March 21, 2018 12:25 PM
>>> To: Youssef Bengelloun-Zahr
>>> Cc: Alex Lembesis; NANOG
>>> Subject: Re: How are you configuring BFD timers?
>>> Silly question perhaps, but why would you do BFD on dark fiber?
>>> Kind regards,
>>> Job
>>> This message is intended solely for the designated recipient(s). It may 
>>> contain confidential or proprietary information and may be subject to 
>>> attorney-client privilege or other confidentiality protections. If you are 
>>> not a designated recipient you may not review, copy or distribute this 
>>> message. If you receive this in error, please notify the sender by reply 
>>> e-mail and delete this message. Thank you.
> 

Re: How are you configuring BFD timers?

[Youssef Bengelloun-Zahr]

Using 200 ms / 200 ms / x3 on either metro dark fiber or longhaul waves
(Paris / Frankfurt / Amsterdam) successfully.

Best regards.

Y.



2018-03-21 16:11 GMT+01:00 Alex Lembesis :

> Using 250ms x 3 on fiber connecting Pennsylvania to Florida...
>
> Best regards,
>
>
>
> Alex
>
> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jason Lixfeld
> (External)
> Sent: Wednesday, March 21, 2018 9:10 AM
> To: NANOG
> Subject: How are you configuring BFD timers?
>
> Hey,
>
> For those running BFD on your land-based point-to-point links, I’m
> interested in hearing about what factors you consider when deciding how to
> configure your timers and multiplier.
>
> On paper, BFD between two devices over a local or metro dark fibre or wave
> seems pretty trivial:  Assuming your gear can a) support echo mode b)
> hardware offloads echo processing c) automatically treats echos as vital
> and puts them into the appropriate high priority queue, then setting the
> timers down to their lowest possible values (3ms on some of the gear that
> I’ve seen) and some low multiplier seems more than reasonable.  But?
>
> From another angle, your link isn’t dark fibre or a wave but, for example,
> ethernet over some sort of IP based L2 Transport, and is still a low (sub
> 1ms) one-way latency local or metro link.  How do you set your timers, and
> what do you base that on?
>
> From yet another angle, what if your link is a long-haul wave, or for that
> matter a wave of any distance that imposes a one-way latency that is higher
> than the minimum tx and rx timers that are supported by your gear?  We’ll
> assume an unprotected wave, because I’m sure if it’s protected, you have no
> choice but to consider the one-way latency of the longest of the two
> segments.
>
> I made some assumptions above about support for echo mode and hardware
> offload, but what if (some of) your gear doesn’t support some or all of
> that stuff?  How do you factor your configuration decisions?
>
> Thanks!
>
> This message is intended solely for the designated recipient(s). It may
> contain confidential or proprietary information and may be subject to
> attorney-client privilege or other confidentiality protections. If you are
> not a designated recipient you may not review, copy or distribute this
> message. If you receive this in error, please notify the sender by reply
> e-mail and delete this message. Thank you.
>

China is beefing up filtering measures

[Youssef Bengelloun-Zahr]

Dear Nanogers,

By now, I'm pretty that the community has heard that china is planning to
increase (once again) filtering measures by limiting ports 80 / 443 / 8080 :

https://www.reddit.com/r/China/comments/7opv4f/china_to_block_sdwan_and_vpn_traffic_by_jan_11/

https://www.goldenfrog.com/blog/article-claims-china-block-vpns-causing-confusion

https://www.sd-wan-experts.com/blog/china-stops-sd-wans-cold-register/

https://www.networkworld.com/article/3247705/sd-wan/will-china-start-blocking-sd-wan-traffic-today.html

I've been doing some googling (read above) and I have come to the following
conclusions :

- Only clear thing is that a "commercial" ISP can register with CN gov to
lift that filtering ?

- This should be enforced by Feb, 1st.

- Pretty much all the rest is unclear when it comes to the : who ? what ?
how ?

I'm trying to understand exactly what we might be dealing with here.

Do anyone happen to have a clear view on this ? Are some of you already
affected by this ?

Thank you for your feedbacks.

Best regards.

Re: Cogent ops contact

[Youssef Bengelloun-Zahr]

Hi,

Issue is I’m not a cogent customer.

Best regards.



> Le 18 janv. 2018 à 21:04, Alistair Mackenzie <magics...@gmail.com> a écrit :
> 
> I've had no problem dealing with their noc on these sort of issues in the 
> past. 
> 
>> On 18 Jan 2018 10:54, "Youssef Bengelloun-Zahr" <benge...@gmail.com> wrote:
>> Dear Nanog community,
>> 
>> I have an issue with a client trying to reach an IP that has been
>> blackholed on Cogent backbone for shady "security reasons".
>> 
>> Can someone reach out in MP please ?
>> 
>> Thank you.

Cogent ops contact

[Youssef Bengelloun-Zahr]

Dear Nanog community,

I have an issue with a client trying to reach an IP that has been
blackholed on Cogent backbone for shady "security reasons".

Can someone reach out in MP please ?

Thank you.

Re: IPv6 migration steps for mid-scale isp

[Youssef Bengelloun-Zahr]

Hi,

My advice is not to mix IGPs. If you are already running ISIS, then go for 
multi-topology and dual-stack it.

I've done that several times, running different backbones, works like a charm. 
Less overhead as you'd only be running one IGP.

My 2 cents.



> Le 16 sept. 2017 à 10:09, Fredrik Sallinen  a 
> écrit :
> 
> Thank you all for your Ideas. AFAIK one of the main decisions for IPv6
> transition and deployment is the choice of IPv6 IGP. I read somewhere
> that its a good practice to use different IGP protocol for IPv6 and
> IPv4. For example if IGP for IPv4 is IS-IS then use OSPFv3 for IPv6.
> any comments on this?
> Additionally I will appreciate it if you share your suggestions on
> products and their performance? For example If I go for NAT64+DNS64 to
> handle IPv4 traffic, What sort of carrier grade products are you
> recommending and can you share your experience on their
> performance/pitfalls? currently we have ~150Gbps of IPv4 traffic, so
> we need a solution to
> support such scale and future growth.
> 
> 
> Regards,
> 
>> On Thu, Sep 14, 2017 at 9:35 PM, Mikael Abrahamsson  wrote:
>>> On Wed, 13 Sep 2017, Fredrik Sallinen wrote:
>>> 
>>> Hello,
>>> 
>>> Recently we have decided to start IPv6 migration in our network. We
>>> have ~1K BNGs and connecting our customers to network using PPPoE.
>>> I'd be interested in hearing from the technical community about their
>>> experiences and recommendations on this process. I'm wondering:
>>> 
>>> Shall I go for IPv6-only deployment or dual stack?
>> 
>> 
>> For PPPoE with existing IPv4, go dual stack.
>> 
>>> Where to start with IPv6? (core, edge or ...)
>> 
>> 
>> Core, peering, work outwards towards end users.
>> 
>>> What are the best practices for ISPs?
>>> What are the costs and return on investment?
>>> How to identify address CPE and legacy application issues?
>> 
>> 
>> There is a lot written and presented about IPv6 deployment. People have been
>> doing this in volume since around 2010, and if you search for IPv6
>> deployment experience you'll find lots of presentations.
>> 
>> Some I found that seem relevant:
>> 
>> https://www.nanog.org/meetings/nanog51/presentations/Monday/aronson-pierantozzi-level3-ipv6.pdf
>> https://www.ietf.org/proceedings/54/slides/plenary-15.pdf
>> https://www.apnic.net/community/ipv6-program/ipv6-stories/
>> https://www.ipv6council.be/experiences-de-deploiements-ipv6/
>> 
>> If you prefer video form, there are lots of presentations from conferences,
>> available on youtube as well.
>> 
>> --
>> Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Verizon 701 Route leak?

[Youssef Bengelloun-Zahr]

Hello,

Do you mean this one ?

https://dyn.com/blog/large-bgp-leak-by-google-disrupts-internet-in-japan/

https://bgpmon.net/bgp-leak-causing-internet-outages-in-japan-and-beyond/

https://mobile.twitter.com/bgpmon/status/901565301048803329

Best regards.



> Le 25 août 2017 à 08:58, Marcus Josephson  a écrit :
> 
> Anyone from Verizon want to comment on a possible route leak on the 25th 
> 10:30 PM EDT? Saw route table jump up to 737629 routes last night from 701.
> 
> 
> Marcus Josephson
> 
> mjoseph...@inap.com * 
> www.inap.com
> 
> INAP (r)
> connectivity | colocation | managed hosting | cloud
> 
> One Ravinia Drive * Suite 1300 * Atlanta * GA * 30346
> 

Re: DWDM Mux/Demux using 40G Optics

[Youssef Bengelloun-Zahr]

Hi,

Ex CubeOptics (now Huber Schuner) are just great. Been using them for years, 
rock solid. I highly recommend them.

Best regards.



> Le 26 juil. 2017 à 04:28, Colton Conor  a écrit :
> 
> Besides FS.com and http://www.beetlefiberoptics.com, do you have any more
> recommendations for passive muxes? I usually stick to and like FiberStore,
> but I am wondering if there is anything out there better/cheaper.
> 
> One of the things I am noticing is the CWDM and DWDM SFP+ optics are quite
> expensive at  $250 for CWDM and $350 for DWDM. I guess it shouldn't be
> cheap to send 10G around a ring, but I am wondering what transponders cost.
> 
> On Tue, Jun 20, 2017 at 3:55 AM, Jeroen Wunnink 
> wrote:
> 
>> Another alternative is to ask the http://www.beetlefiberoptics.com guys.
>> They build muxes on spec and they can also provide a 1310nm wide-band port
>> on their units which allows a 40/100G-LR4 aside from the 1550nm DWDM band.
>> 
>> We’ve used some simple splitters (line/1310nm LR4/1550nm DWDM ports on a
>> unit) and full passive DWDM muxes with a 40/100G-LR4 port on there and
>> these work pretty good.
>> 
>> 
>> 
>> 
>> Jeroen Wunnink
>> IP Engineering manager
>> office: +31.208.200.622 ext. 1011
>> Amsterdam Office
>> www.gtt.net 
>> 
>> 
>> 
>> 
>> On 20/06/2017, 01:14, "NANOG on behalf of Colton Conor" <
>> nanog-boun...@nanog.org on behalf of colton.co...@gmail.com> wrote:
>> 
>>Do you have any idea if fiberstore has one with both a monitor and 1310
>>wideband port? I would want both.
>> 
>>Seeing as how they don't charge extra for an expansion port, but do for
>>other special ports I am thinking of just using the expansion port.
>> 
>>On Mon, Jun 19, 2017 at 4:52 PM, Faisal Imtiaz <
>> fai...@snappytelecom.net>
>>wrote:
>> 
>>> 
> From the sounds of it, no one knows the real difference between the
>>> expansion port, 1310 port, and 1550 port
>>> 
>>> Hmm.. not sure how you are reading this...
>>> I believe that there is no 'standard' and as such the actual filter
>> on the
>>> mux/demux you are using may vary by mfg.
>>> I can confirm what is an expansion port... (pass everything thru
>> that is
>>> not being filtered by the mux/demux )
>>> I can also confirm that Fiberstore 1310nm port (not to be confused
>> with
>>> the CWDM 1310 port) will pass all 4 wavelengths for 40g/100g optics.
>>> I don't have experience with the 1550nm port.
>>> 
> For real world applications, I would assume the monitor port would
>> be to
>>> plug in a handheld meter, and see which channels are coming through
>> that
>>> node without breaking the ring.
>>> 
>>> Correct that is what it is designed for. it allows a fraction of
>>> light (I am guessing would also cause an increase in insertion loss
>>> figure).
>>> 
> Not sure if their would be a monitor port for both directions is
>> you
>>> were using a OADM?
>>> If you look at the OADM's e.g. like a Cisco CWDM OADM with monitor
>> ports,
>>> you will see that they are on both sides east & west.
>>> 
>>> 
>>> Regards.
>>> 
>>> 
>>> Faisal Imtiaz
>>> Snappy Internet & Telecom
>>> 7266 SW 48 Street
>>> Miami, FL 33155
>>> Tel: 305 663 5518 x 232 <(305)%20663-5518>
>>> 
>>> Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email:
>>> supp...@snappytelecom.net
>>> 
>>> --
>>> 
>>> *From: *"Colton Conor" 
>>> *To: *"Faisal Imtiaz" 
>>> *Cc: *"Mike Hammett" , "Luke Guillory" <
>>> lguill...@reservetele.com>, "nanog list" 
>>> *Sent: *Monday, June 19, 2017 4:14:19 PM
>>> 
>>> *Subject: *Re: DWDM Mux/Demux using 40G Optics
>>> 
>>> Thanks for the answers. From the sounds of it, no one knows the real
>>> difference between the expansion port, 1310 port, and 1550 port. For
>> real
>>> world applications, I would assume the monitor port would be to plug
>> in a
>>> handheld meter, and see which channels are coming through that node
>> without
>>> breaking the ring. Not sure if their would be a monitor port for both
>>> directions is you were using a OADM?
>>> 
>>> On Mon, Jun 19, 2017 at 2:38 PM, Faisal Imtiaz <
>> fai...@snappytelecom.net>
>>> wrote:
>>> 
 Answers in-line ...
 
 Faisal Imtiaz
 Snappy Internet & Telecom
 7266 SW 48 Street
 Miami, FL 33155
 Tel: 305 663 5518 x 232 <(305)%20663-5518>
 
 Help-desk: (305)663-5518 <(305)%20663-5518> Option 2 or Email:
 supp...@snappytelecom.net
 --
 
 *From: *"Colton Conor" 
 *To: *"Mike Hammett" 
 *Cc: *"Luke Guillory" , "nanog list" <
 nanog@nanog.org>, "Faisal Imtiaz" 
 *Sent: *Monday, June 19, 2017 3:30:37 PM
 *Subject: *Re: DWDM Mux/Demux using 40G Optics
 
 I guess that is the real question. Besides the 

Re: AS9498 Bharti BGP hijacks

[Youssef Bengelloun-Zahr]

Hi,

What's more concerning here is that those prefixes were able to pass through 
all filters on their way, via their transits and maybe probably via their peers 
as well. Haven't we been here before !?!

And here I thought 2017 internet would be a "safer" place. Silly me...

Y.



> Le 1 avr. 2017 à 23:33, Job Snijders  a écrit :
> 
> Hi all,
> 
> Perhaps another explanation is that these are router2router linknets
> between the involved parties, and all we are seeing is the effect of
> "redistribute connected". If this is the case, the word "hijack" might be
> somewhat strong worded.
> 
> Kind regards,
> 
> Job
> 
> On Sat, 1 Apr 2017 at 23:25, Tyler Conrad  wrote:
> 
> So not only are they hijacking prefixes, they're leaking the  /30s to their
> peers. Failure through and through.
> 
> On Saturday, April 1, 2017, George William Herbert  wrote:
> 
>> 
>> Hey, Bharti, knock that off.
>> 
>> http://bgpstream.com/event/78126
>> http://bgpstream.com/event/78125
>> http://bgpstream.com/event/78124
>> http://bgpstream.com/event/78123
>> http://bgpstream.com/event/78122
>> 
>> 
>> Sent from my iPhone
>> 

Re: BGP Route Reflector - Route Server, Router, etc

[Youssef Bengelloun-Zahr]

Same old same.

Y.



2017-03-20 11:35 GMT+01:00 Mark Tinka :

>
>
> On 14/Jan/17 00:39, Brandon Ewing wrote:
>
> > One important thing to remember when migrating from full mesh to a RR
> design
> > is that you are reducing information available to the routers in the ASN.
> > When you had a full mesh, each router could select the best path from all
> > available paths, according to its position in the IGP.  In a RR
> environment,
> > by default, routers only have available to them the best routes from the
> > RR's position in the IGP, which can lead to suboptimal exits being
> selected.
> >
> > Work is being done to allow RRs to compute metrics from the client's
> > position in the IGP: See
> > https://tools.ietf.org/html/draft-ietf-idr-bgp-optimal-
> route-reflection-13
> > for more information
>
> BGP-ORR is currently supported in Junos and IOS XR (ASR9000, I
> believe... I haven't confirmed for other IOS XR platforms).
>
> I'm getting Cisco to add support for it in IOS and IOS XE (CSR1000v).
> I'm now dealing with the usual "How large is the customer's spend for
> this feature" nonsense. BGP-ORR, I feel, is one of those features that
> doesn't need a business case - much like ketchup at a fast-food joint.
>
> That the IOS XR PI team have it in there and the IOS/IOS XE PI teams
> don't highlights the depth of the fundamental problem over at Cisco-land.
>
> Mark.
>

Re: BGP Route Reflector - Route Server, Router, etc

[Youssef Bengelloun-Zahr]

Dear Justin,

You could take a look at this presentation from Mark Tinka during last NANOG :

https://m.youtube.com/watch?v=wLEjOj2fyp8

HTH.

Y.



> Le 12 janv. 2017 à 23:41, Łukasz Bromirski  a écrit :
> 
> 
>> On 12 Jan 2017, at 21:32, Justin Krejci  wrote:
>> 
>> Nanog,
>> […]
> 
> You did some homework. In essence, there’s no immediate problem with running 
> Quagga or OpenBGPd as
> RR apart from lack of different knobs and not-so-stellar 
> performance/scalability. BIRD is grounds up built
> to act as high-performance BGP daemon, and it’s actually used as RR in live 
> deployments, not only at IXes.
> 
>> I am wondering if people can point me in the direction to some good resource 
>> material on how to select a good BGP route reflector design. Should I just 
>> dust off some 7206VXR routers to act as route reflectors? Use a few existing 
>> live routers and just add the responsibility of being route reflectors, is 
>> there a performance hit? Install and run BIRD on new server hardware? Buy 
>> some newer purpose built routers (Cisco, Juniper, Brocade, etc) to act as 
>> route reflectors and add them to the iBGP topology? GNS3 running IOS on 
>> server hardware? Something else? How many reflectors should be implemented? 
>> Two? Four?
> 
> Disclaimer: I work at Cisco.
> 
> If You have some 7200VXRs that have 1 or 2GBs of RAM, that may be the best 
> option (IF you have them).
> Loaded with 12.2S/15S software they may actually be the most cost-effective 
> solution and at the same
> time support things like AddPath, BGP error handling, etc - when time comes 
> to use such features.
> If that’s a NPE400 based chassis or something even older - leave it for 
> lab/etc as You need rather
> performant CPU.
> 
> So, if that’s not the option, try to work with the BIRD, CSR 1000v (IOS-XE on 
> VM) or ASR 1001X/HX
> (currently, the most scaleable and fastest BGP route reflector out there, but 
> one that will cost $$$).
> 
> Two RRs provide ample redundancy to run even very large deployments (1000+ 
> clients), so unless you’re
> trying to hit higher numbers or plan to play fancy games with one pair of RRs 
> for IPv4/IPv6 unicast
> and other pair for different AFs, four may be an overkill to maintain, 
> synchronize and monitor.
> 
> Don’t go with GNS3, running compiled at runtime emulation is wrong idea for 
> any production deployment,
> not to mention rights/licenses to do it.
> 
> — 
> Łukasz Bromirski

Re: Arista unqualified SFP

[Youssef Bengelloun-Zahr]

2016-08-18 13:47 GMT+02:00 Mark Tinka <mark.ti...@seacom.mu>:

>
>
> On 18/Aug/16 13:41, Youssef Bengelloun-Zahr wrote:
>
> Hello all,
>
> At my actual job, some colleagues bought Arista switchs very recently. They 
> asked the question about 3rd party transceivers and their SE told them 
> exactly what has been said before :
>
> "we do accept 3rd party transceivers but we don't support them. If you still 
> want to use them willingly, you'll have to sign a discharge paper and we'll 
> provide you with a key to activate on your equipement".
>
> That's Arista's official policy regarding 3rd party transceivers.
>
>
> I am fine with that.
>
> All other vendors, explicitly or silently, adopt the same approach.
>
> Mark.
>


+1. At least they have a policy that they fully assume publically, which is
more than others can say/do.

Best regards.


-- 
Youssef BENGELLOUN-ZAHR

Re: Arista unqualified SFP

[Youssef Bengelloun-Zahr]

Hello all,

At my actual job, some colleagues bought Arista switchs very recently. They 
asked the question about 3rd party transceivers and their SE told them exactly 
what has been said before :

"we do accept 3rd party transceivers but we don't support them. If you still 
want to use them willingly, you'll have to sign a discharge paper and we'll 
provide you with a key to activate on your equipement".

That's Arista's official policy regarding 3rd party transceivers.

HTH.

BR.



> Le 18 août 2016 à 13:29, Dovid Bender  a écrit :
> 
> And I was about to jump on to the Arista train.
> 
> Regards,
> 
> Dovid
> 
> -Original Message-
> From: Stanislaw 
> Sender: "NANOG" Date: Thu, 18 Aug 2016 13:24:05 
> To: nanog list
> Subject: Re: Arista unqualified SFP
> 
> Hi all,
> If somebody is following my epic adventure of getting uqualified SFP to 
> work on Aristas, here is the unhappy end of it.
> 
> I've written to Arista support and got the following dialogue:
> Support guy:
> Hi,
> Thank you for contacting Arista Support. My name is  and I'll be 
> assisting you on this case.
> Could you please provide the "show version" output from this switch?
> 
> Me:
> Hi,
> Here it is:
> 
> 
> Support guy:
> Hi,
> Thank you for the information.
> Unfortunately, we are unable to activate your 3rd party components. To 
> ensure ongoing quality, Arista devices are designed to support only 
> properly qualified transceivers.
> Please let me know if you have any other questions.
> 
> Me:
> I do not understand,
> But there is a command which allows using non-Arista transceivers. Why 
> have you implemented it but don't provide an access key to your 
> customers when they ask for it?
> If it is required to sign some papers which declare that I am aware of 
> all the risks and losing my warranty - I agree with that, lets do it. 
> Any way what are the conditions to receive that access key?
> 
> Support guy:
> I'm afraid that there is nothing I'm able to do regarding this 
> situation. If you have any other questions regarding enabling 3rd party 
> options in Arista switches, I suggest to contact your local account team 
> (or sales) for further discussion on this matter.
> 
> 
> Next, i've tried inserting various QSFP+ DAC cables I have - none of 
> them has been even detected on the switch, it was acting like nothing 
> has been inserted. I guess that even if I get the key, most of my 
> transceivers/DAC (which work like a champ in Juniper or Extreme 
> switches) cables wouldnt work.
> 
> I'm writing this post to make somebody who considers buying their 
> switches be aware of what they'd get. Just buy Juniper instead.
> 
> 
> Stanislaw wrote at 2016-08-17 23:25:
>> Hi Tim,
>> 
>> Thanks for your expressive answer. Will try it :)
>> 
>> Tim Jackson писал 2016-08-17 22:57:
>> 
>>> I'd suggest bitching and moaning at your account team & support until 
>>> they give you the key to unlock them..
>>> 
>>> --
>>> Tim
>>> 
 On Wed, Aug 17, 2016 at 2:50 PM, Stanislaw  wrote:
 
 Hi all,
 Is there a way for unlocking off-brand transceivers usage on Arista 
 switches?
 
 I've got an Arista 7050QX switch with 4.14 EOS version. Then it has 
 been found out that Arista switches seem to not have possibility to 
 unlock off-brand xcievers usage (by some service command or so).
 
 I've patched /usr/lib/python2.7/site-packages/XcvrAgent.py, made the 
 checking function bypass the actual check and it helped: ports are 
 not in errdisable state anymore. But despite of xceivers are detected 
 correctly, links aren't coming up (they are in notconnect state).
 
 If anyone possibly have does have a sacred knowledge of bringing 
 off-branded transceivers to life on Arista switches, your help'd be 
 very appreciated. Thanks.

Re: Brocade Fabric Help

[Youssef Bengelloun-Zahr]

Dear Mike,

Are you running fabric with logical-chassis mode. Did you set priorities on the 
rbridges to select selection order of the principal switch ? Did you make any 
configuration changes from anywhere else than on the principal switch (using 
cluster VIP to connect) ?

IF so, then message seems to point to a configuration difference between nodes 
hence a possible DB corruption.

When that happens, the switchs would rather not join the fabric then try merge 
and possibly cause configuration alterations and instabilities.

You should try to dig that message out on the net or in NOS guides. Maybe open 
a case with BTAC ?

But ultimately, I think you'll probably end up disabling one of the switchs, 
reset the config and rejoin it in the fabric.

HTH.

Y.



> Le 30 juin 2016 à 21:41, Mike Hammett  a écrit :
> 
> I asked on the Brocade forum, but it's largely been crickets there. I hoped 
> someone here would have an idea. 
> 
> One switch says: 23 Te 12/0/24 Up ISL segmented,(ESC mismatch, Distributed 
> Config DB)(Trunk Primary) 
> The other switch says: 23 Te 54/0/24 Up ISL segmented,(ESC mismatch, 
> Distributed Config DB)(Trunk Primary) 
> 
> I saw that means, "The DCM Configuration DB is different on both the ends of 
> ISL," but I have no idea how to resolve that. 
> 
> 
> VDX-6720s running 4.1.3b. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 

Re: CDN

[Youssef Bengelloun-Zahr]

Hello,

I believe Microsoft does that too, even if it's not explicitly written :

http://www.microsoft.com/Peering/Caching

Best regards.



> Le 19 déc. 2015 à 17:13, Patrick W. Gilmore  a écrit :
> 
> PeeringDB will tell you where they connect. I do not think anyone puts stuff 
> into PeeringDB when they have on-net nodes.
> 
> In general, only the big three (Akamai, Netflix, Google) have significant 
> deployments inside eyeball networks. Exceptions to every rule and all that, 
> but if you pick random large eyeball network, chances are very, very high 
> they have no one other than those three - if they have any at all.
> 
> -- 
> TTFN,
> patrick
> 
>> On Dec 19, 2015, at 10:35 AM, Mehmet Akcin  wrote:
>> 
>> looking at peeringdb -- http://www.peeringdb.com/view.php?asn=16509 might
>> give you an idea where they are.
>> 
>> mehmet
>> 
>> On Sat, Dec 19, 2015 at 6:53 AM, Ahmed Munaf 
>> wrote:
>> 
>>> Dear All,
>>> 
>>> Does anyone know if AWS amazon “cloudfront”, cloud flare, Microsoft … etc,
>>> hosting their servers on other party providers?
>>> just like what GGC and Akamai do by hosting their servers on other ISP’s
>>> datacenter!
>>> 
>>> Regards,
> 

Re: AW: /27 the new /24

[Youssef Bengelloun-Zahr]

Hi,

FYI, newer linecard models from BROCADE can hold 2 million routes. Probably 
others can do that now too.

Disclaimer : I'm not working for them or defending them, just setting an 
information straight.

My 2 cents.



> Le 3 oct. 2015 à 10:33, Jürgen Jaritsch  a écrit :
> 
> As mentioned before: even the new SUP2T from Cisco is limited to 1Mio routes 
> ...
> 
> There are MANY other vendors with the same limitations: Juniper, Brocade, etc
> 
> And the solt equipment is not the 99USD trash from the super market at the 
> corner ...
> 
> 
> Jürgen Jaritsch
> Head of Network & Infrastructure
> 
> ANEXIA Internetdienstleistungs GmbH
> 
> Telefon: +43-5-0556-300
> Telefax: +43-5-0556-500
> 
> E-Mail: j...@anexia.at
> Web: http://www.anexia.at
> 
> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
> Geschäftsführer: Alexander Windbichler
> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
> 
> 
> -Original Message-
> From: Max Tulyev [max...@netassist.ua]
> Received: Samstag, 03 Okt. 2015, 9:11
> To: nanog@nanog.org [nanog@nanog.org]
> Subject: Re: AW: /27 the new /24
> 
> Which routers? DIR-300 with OpenWRT/Quagga? :)
> 
> I think all above-the-trash level routers supports >1M routes, isn't it?
> 
>> On 02.10.15 17:45, Jürgen Jaritsch wrote:
>> Hi,
>> 
>> this would at least help to get rid of many old routing engines around the 
>> world :) ... or people would keep their "learn nothing smaller than /24" 
>> filters in place. Also an option - but not for companies who act as an IP 
>> transit provider.
>> 
>> 
>> best regards
>> 
>> Jürgen Jaritsch
>> Head of Network & Infrastructure
>> 
>> ANEXIA Internetdienstleistungs GmbH
>> 
>> Telefon: +43-5-0556-300
>> Telefax: +43-5-0556-500
>> 
>> E-Mail: jjarit...@anexia-it.com
>> Web: http://www.anexia-it.com
>> 
>> Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt
>> Geschäftsführer: Alexander Windbichler
>> Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: NANOG [mailto:nanog-boun...@nanog.org] Im Auftrag von Justin Wilson - 
>> MTIN
>> Gesendet: Freitag, 02. Oktober 2015 16:32
>> An: NANOG
>> Betreff: /27 the new /24
>> 
>> I was in a discussion the other day and several Tier2 providers were talking 
>> about the idea of adjusting their BGP filters to accept prefixes smaller 
>> than a /24.  A few were saying they thought about going down to as small as 
>> a /27.  This was mainly due to more networks coming online and not having 
>> even a /24 of IPv4 space.  The first argument is against this is the 
>> potential bloat the global routing table could have.  Many folks have worked 
>> hard for years to summarize and such. others were saying they would do a /26 
>> or bigger.
>> 
>> However, what do we do about the new networks which want to do BGP but only 
>> can get small allocations from someone (either a RIR or one of their 
>> upstreams)?
>> 
>> Just throwing that out there. Seems like an interesting discussion.
>> 
>> 
>> Justin Wilson
>> j...@mtin.net
>> 
>> ---
>> http://www.mtin.net Owner/CEO
>> xISP Solutions- Consulting – Data Centers - Bandwidth
>> 
>> http://www.midwest-ix.com  COO/Chairman
>> Internet Exchange - Peering - Distributed Fabric
> 

Re: Mac compatible SFP+/XFP programmer

[Youssef Bengelloun-Zahr]

Hi,

Flexoptics seems to do the trick but via a Web browser :

https://www.flexoptix.net/en/flexbox-v3-transceiver-programmer.html

From what I've heard, this thing does the Job.

Best regards.



 Le 30 juil. 2015 à 20:28, Jason Lixfeld ja...@lixfeld.ca a écrit :
 
 Does anyone know where I might find a SFP+/XFP programmer with a Mac 
 compatible programmer application?
 
 Thanks!

Re: looking glass software

[Youssef Bengelloun-Zahr]

Hello,

Anyone that would know of an LG that would work with recent Brocade gear ?

Best regards.



 Le 27 mai 2015 à 20:48, Farhan Ali Khan far...@cyber.net.pk a écrit :
 
 Hello Bogdan,
  have a look http://freecode.com/projects/lg/  it supports IOS,
 Junos but doesnt support IOS XR if you are comfortable with this one
 let me know ill try to assist you  to modify the code.
 i never tried but i do believe with some modification same tool can
 also work with huawei , nortel any other CLIs as well
 
 Good Day 
 Farhan Khan
 
 On 27/May/15 06:52, Bogdan wrote:
 hello
 
 what software do you use for looking glass. for cisco ios and
 ios-xr?
 i use the old cougar/version6.net for ios, but ios-xr is not
 supported.
 i came across https://github.com/tmshlvck/ulg/ but did't installed
 yet.
 are there any other interesting lg's out there?
 
 That's the one we use, but we run it against IOS. Should also work
 for
 IOS XE.
 
 I think I've seen some folk use it for Junos as well.
 
 Mark.
 

Re: Route Optimization Products

[Youssef Bengelloun-Zahr]

Border6 NSI.

Best regards.



 Le 15 mai 2015 à 17:19, Mike Hammett na...@ics-il.net a écrit :
 
 What is out there for route optimization products? I can think of Noction (no 
 inbound) or Internap FCP (old).
 
 
 
 -
 Mike Hammett
 Intelligent Computing Solutions
 http://www.ics-il.com
 
 
 
 Midwest Internet Exchange
 http://www.midwest-ix.com
 

Re: 100Gb/s TOR switch

[Youssef Bengelloun-Zahr]

Hello Piotr,

You can always take a look at :

- Arista :

http://www.arista.com/en/products/7280e-series

- Brocade :

http://www.brocade.com/products/all/switches/product-details/vdx-6940-switch/index.page

HTH.

BR.



 Le 8 avr. 2015 à 21:01, Piotr piotr.1...@interia.pl a écrit :
 
 Hi,
 
 There is something like this on market ? Looking for standalone switch, 1/2U, 
 ca 40 ports 10Gb/s and about 4 ports 100Gb/s fixed or as a module.
 
 regards,
 Peter

Re: AS6713 (aka IAM / MOROCCO TELECOMS) peering contact

[Youssef Bengelloun-Zahr]

Hello,

Let me (the OP) put an end to this :

- I'm certainly not a native english speaker, but my english level is good 
enough to make myself clear / understandable.

@Barry : No offense taken ;-)

- Maybe this he/she false debate all started with an honnest/innocent 
mistake. I do not care about / pay attention / give importance about the gender 
of my fellow estimed networking pairs.

@Clayton : Really, all I've asked for when I sent the initial email was a 
peering contact. Nothing more, nothing less. PERIOD ;-)

Now that AS6713 has been publitized (more than they haven't asked for), maybe 
someone overthere will finally ping back !

After all, it's Xmas, you never know what santa can bring along with him.

Wish you all a happy holiday season.

Best regards.



 Le 27 déc. 2014 à 22:20, Barry Shein b...@world.std.com a écrit :
 
 
 May I share some clue?
 
 The OP is probably not a native speaker of English.
 
 You don't play PC language games with people who you aren't *certain*
 are native speakers of English.
 
 Why? Because if you do I will show up at your door!
 
 I dunno, just don't do it, it's rude and stupid, imagine if you were
 trying to post in your college Arabic or French or whatever and got
 hit with subtleties like this instead of a simple answer.
 
   -b
 
 
 On December 27, 2014 at 14:35 clay...@mnsi.net (Clayton Zekelman) wrote:
 
 That is why the better pronoun choice would have been 'you', not 'he' or 
 'she'. 
 
 Sent from my iPhone
 
 On Dec 27, 2014, at 1:47 PM, Javier J jav...@advancedmachines.us wrote:
 
 What if they don't identify as a he or a she?
 
 On Fri, Dec 26, 2014 at 6:46 PM, Clayton Zekelman clay...@mnsi.net wrote:
 What if the peering team member is a she?  Should she not contact you if 
 so?
 
 Sent from my iPhone
 
 On Dec 26, 2014, at 5:48 PM, Youssef Bengelloun-Zahr yous...@720.fr 
 wrote:
 
 Hello,
 
 If someone from IAM peering team is watching, could he please get in touch
 OFF-list please ?
 
 Best regards.
 
 --
 Youssef BENGELLOUN-ZAHR
 

AS6713 (aka IAM / MOROCCO TELECOMS) peering contact

[Youssef Bengelloun-Zahr]

Hello,

If someone from IAM peering team is watching, could he please get in touch
OFF-list please ?

Best regards.

-- 
Youssef BENGELLOUN-ZAHR

Re: Juniper MX Sizing

[Youssef Bengelloun-Zahr]

Hi,

Running MLXe with MR2 and/or CER-RT as MPLS PEs depending on POP size. We also 
run the later as route reflectors.

They behave beautifully when it comes to churning BGP full feeds, convergence 
is around 30-45s (full RAM). Routing capacity is also amazing.

I'm particularly amazed by the CER-RT from a price/performance/footprint 
perspective. So I would advice it unless the OP has some specific technical 
requirements (flowspec support, etc.).

Best regards.



 Le 5 déc. 2014 à 22:52, Brad Fleming bdfle...@gmail.com a écrit :
 
 We have both Brocade CER and XMR (predecessor to the MLXe) in our environment 
 today. We find both platforms attractive from a price and power consumption 
 standpoint. They will both handle the IPv4 and IPv6 unicast routing tables 
 today.* The MLXe with MR2 cards is quite a formidable box; lots of power and 
 pretty light-weight OS (compared to Junos). We found our XMR nodes with 
 original mgmt cards and Gen1 line cards converge pretty quick; we’ve never 
 timed one officially but my gut feeling is RIB+FIB convergence is roughly 
 45sec assuming your peer is RTT nearby. The CER is a little slower to 
 converge in our experience; however, we have them in non-critical portions of 
 the network so I can’t really attest to their convergence performance. 
 Sorry.. not much in the way of lab readings for our Brocade gear.
 
 
 
 On Dec 5, 2014, at 2:09 PM, Ammar Zuberi am...@fastreturn.net wrote:
 
 What’s a cheaper alternative to the MX104s?
 
 We take a full BGP table and are on the AMS-IX and DE-CIX and are looking 
 for a new router. The MX series looks a bit out of budget but we’re 
 currently looking into the Brocade MLX series. We push under 10Gbps, but we 
 do need 10Gbps routing due to capacity issues during attacks.
 
 Sorry for being a bit off-topic here.
 
 Ammar
 
 This email and any files transmitted with it are confidential and intended 
 solely for the use of the individual or entity to whom they are addressed. 
 If you have received it by mistake, please let us know by e-mail reply and 
 delete it from your system; you may not copy this message or disclose its 
 contents to anyone. Please note that any views or opinions presented in this 
 email are solely those of the author and do not necessarily represent those 
 of the company. Finally, the recipient should check this email and any 
 attachments for the presence of viruses. The company accepts no liability 
 for any damage caused by any virus transmitted by this email.
 
 On Dec 6, 2014, at 12:01 AM, Brad Fleming bdfle...@gmail.com 
 mailto:bdfle...@gmail.com wrote:
 
 Then you should look for something other then the MX104.
 
 In our testing an MX104 running Junos 13.3R4 with a single, full feed took 
 about 4min 25sec to (1) converge the RIB from a router sitting 0.5ms RTT 
 away and (2) update the FIB with all entries. This performance was observed 
 with single RE and dual RE and without any excess services running. If we 
 added inline-flow sampling to the device full convergence took closer to 
 5min 45sec in our lab. Efforts to bring the convergence time down (without 
 filtering ingress advertisements) with the assistance of JTAC proved 
 unsuccessful.
 
 We decided to “bite the bullet” and procure MX480s instead but obviously 
 that’s not possible for everyone. If the MX480 is out of the question a 
 Brocade CER Premium is an option. We have 3 in production and see very 
 attractive convergence times; however, they have a more limited feature set 
 and you’ll want to understand how their FIB memory scales. Apologies, I 
 don’t know the Cisco equivalent from the ASR line these days but I’m sure 
 others on the list could help out.
 
 
 On Dec 5, 2014, at 11:45 AM, Graham Johnston johnst...@westmancom.com 
 mailto:johnst...@westmancom.com wrote:
 
 Shawn,
 
 It's more about FIB than RIB as I am concerned about the time it takes 
 until MPCs have updated route information after large scale changes in 
 routes learned via BGP.
 
 Graham Johnston
 Network Planner
 Westman Communications Group
 204.717.2829
 johnst...@westmancom.com mailto:johnst...@westmancom.com
 think green; don't print this email.
 
 -Original Message-
 From: Shawn Hsiao [mailto:phs...@tripadvisor.com] 
 Sent: Friday, December 05, 2014 11:30 AM
 To: Graham Johnston
 Cc: nanog@nanog.org
 Subject: Re: Juniper MX Sizing
 
 
 Is your sizing concern just for the RIB, or also for FIB to sync up?   The 
 latter was a problem for us, but not the former.   We also have 
 inline-jflow turned on and that is still a work-in-progress in terms of 
 impacting performance.
 
 We are using MX104 for similar purposes for many months now, and with some 
 tweaks in our procedures and configurations we found it to be acceptable.  
   MX104 may not be able to process routes as fast as MX480, but MX480 is 
 also not instantaneous either so similar risks exist.
 
 
 
 On Dec 5, 2014, at 11:59 AM, Graham Johnston johnst...@westmancom.com 
 wrote:

Re: upstream support for flowspec

[Youssef Bengelloun-Zahr]

Envoyé de mon iPhone

 Le 18 sept. 2014 à 19:53, Daniel Corbe co...@corbe.net a écrit :
 
 
 I was perusing RFC5575 after reading a presentation that ALU did
 (presumably during some previous NANOG conference).  Reference:
 https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf
 
 This seems like it would be a godsend for small operators like myself who 
 don't have
 access to unlimited bandwidth and are put off by off-site scrubbing
 services.  
 
 As far as I can tell though the only platforms that offer support are
 the 7750-SR and platforms made by Juniper.
 
 Is there anything in the air about widening the adoption base?  Cisco?
 Brocade?

Hi,

I've submitted a request through my Brocade SE to support this, but it seems 
they are not interested about it.

They claim their strategy is to achieve the same using SDN capabilities via 
OPENFLOW support.

In the mean time, we are sitting ducks with our traditional technics.

I read in an old NANOG thread (IIRC) that cisco was about to support this 
really soon on IOS-XR, but I am not 100% sur.

Best regards.

 
 And once that happens, what are the chances of services providers
 adopting this for their customers to make use of on as wide of a scale
 as (for example) blackhole community strings.
 
 I'd certainly *love* to have a way to mitigate an attack that doesn't
 involve me sacrificing one service on my network to save the rest.
 
 Best,
 Daniel

Rackspace (AS36248) peering contact

[Youssef Bengelloun-Zahr]

Hi,

Can someone from Rackspace hosting peering team get in touch with me ? No
peeringDB page or contacts easily available.

Thanks.



-- 
Youssef BENGELLOUN-ZAHR

Re: Listing or google map of peering exchange

[Youssef Bengelloun-Zahr]

Hello,

Kindly provided by the Telegeography team :

http://www.internetexchangemap.com/

Hope this helps.

Y.



2014-07-09 20:34 GMT+02:00 William F. Maton Sotomayor wma...@ottix.net:


 On Wed, 9 Jul 2014, Dennis Burgess wrote:

  Looking for a good listing of US/Canada peering exchange, similar to
 Torx in Toronto..Google map listing would be nice J


 Telegeography may have this

 or:

 https://prefix.pch.net/applications/ixpdir/





 Dennis Burgess, Mikrotik Certified Trainer Author of Learn RouterOS-
 Second Edition http://www.wlan1.com/product_p/mikrotik%20book-2.htm 

 Link Technologies, Inc -- Mikrotik  WISP Support Services

 Office: 314-735-0270 tel:314-735-0270  Website:
 http://www.linktechs.net http://www.linktechs.net/  - Skype: linktechs
 skype:linktechs?call

 -- Create Wireless Coverage's with www.towercoverage.com
 http://www.towercoverage.com/  - 900Mhz - LTE - 3G - 3.65 - TV
 Whitespace





 wfms




-- 
Youssef BENGELLOUN-ZAHR

Re: 012 Smile Telecom (AS9116) peering contact

[Youssef Bengelloun-Zahr]

Hello Hank,

Many thanks for the hint.

Best regards.



 Le 18 juin 2014 à 18:29, Hank Nussbacher h...@efes.iucc.ac.il a écrit :
 
 Try isp_ni...@012.net.   They recently merged with another ISP and many 
 addresses stopped working.  This one still works and should hopefully lead to 
 someone with a clue there.
 
 Hank
 
 On Jun 18, 2014 9:59 AM, Youssef Bengelloun-Zahr yous...@720.fr wrote:
 
 Dear All, 
 
 I'm looking for a valid peering contact for 012 Smile Telecom AS9116 (aka 
 Golden-Lines/Internet-Gold/012 Smile Communications). Their public peering 
 contact isn't working. 
 
 If one their peering admins is watching, please contact me privatly. 
 
 Best regards. 
 
 
 
 -- 
 Youssef BENGELLOUN-ZAHR