Re: OSPF vs ISIS - Which do you prefer & why?

[Charles van Niman]

I don't think Nick asked for a list, just one single thing, any one
thing. To me at least, it doesn't really make sense to make the
statement you did, without pointing out what can be done to improve
the situation. I would be very interested to hear what network
requirements are not being met with Juniper's current IS-IS
implementation.

/Charles

On Thu, Nov 10, 2016 at 3:22 PM, Josh Reynolds  wrote:
> I'm sure a lot has changed with Juniper as of 2011 in regard to IS-IS
> support, which was the last time *I* looked.
>
> No, I do not have a list sitting ready, that catalogs in details
> between product lines and specific firmware versions and subversions
> between multiple vendors what one supports and what one does not as of
> Nov 11, 2016.
>
> What I can do is point you at the vendor list where you can make a
> comparison of that vendor to others, for the features that you need in
> your environment - as I'm not getting paid to maintain such lists, and
> they are.
>
> On Thu, Nov 10, 2016 at 2:47 PM, Nick Hilliard  wrote:
>> Josh Reynolds wrote:
>>> I have not kept up with all of the feature differences between Cisco's
>>> implementation and the other vendors. I can only encourage others
>>> interested in this to compare the specific feature sets between the
>>> two and see if it meets their needs. What I need in an environment
>>> from an IGP may be totally different from another data center,
>>> transport, or transit network provider.
>>
>> so you aren't prepared to (or can't) provide a single detail about all
>> the many features that the junos isis implementation is apparently
>> missing, which would justify saying that Juniper is "not getting it"
>>
>> Ok.
>>
>> Not even one?  A tiny little thin one?  Just... just one...?
>>
>> Nick
>>

Re: OSPF vs ISIS - Which do you prefer & why?

[Charles van Niman]

Your original point was that a list of vendors "didn't get IS-IS" but
provided no details about what you are talking about. As far as all
the documentation I have read, and some of the documentation you
linked to, it works just fine on quite a few vendors, and a few people
on this list. Your original point mentions nothing about wider OSPF
adoption, which you seem to have shifted to to deflect having to
provide any actual details.

Are we to assume that your original point was incorrect? As far as the
landscape as a whole, I have seen quite a few networks that get by
with either protocol just fine, the use-case for a given network is
not such a broad landscape, so I think "use the right tool for the
job" seems very apt, and that you can't just say that only two
protocols are suitable for all jobs.

/Charles

On Thu, Nov 10, 2016 at 6:00 PM, Josh Reynolds  wrote:
> As cute as your impotent white knighting of one vendor is (I very much like
> Juniper BTW), you're absolutely ignoring my original premise and point
> because you got your panties in a wad over a potential triviality of an
> internet comment - where documentation exists, should one take the time to
> go through it, to find discrepancies between them.
>
> So, if you'd like to prove your point and earn brownie points with $vendor,
> on a feature by feature basis please take the time to consult documentation
> of two vendors products (you can even pick the platform and subversion
> release!) to refute my claim. This has nothing at all to do with the point
> of my statement mind you, it's simply a sidetrack that has wasted enough
> time already.
>
> That said, glance across the landscape as a whole of all of the routing
> platforms out there. Hardware AND softwsre. Which ones support bare bones
> IS-IS? Which ones have a decent subset of extensions? Are they comparable
> or compatible with others? The end result is a *very mixed bag*, with far
> more not supporting IS-IS at all, or only supporting the bare minimum to
> even go by that name in a datasheet.
>
> Thus, my point stands. If you want as much flexibility in your environment
> as you can have, you want OSPF or BGP as your IGP.
>
> On Nov 10, 2016 5:33 PM, "Nick Hilliard"  wrote:
>
>> Josh Reynolds wrote:
>> > I didn't "trash talk" a vendor. If I did, it would be a multi-thousand
>> > line hate fueled rant with examples and enough colorful language to make
>> > submarine crews blush.
>>
>> I have no doubt it would be the best rant.  It would be a beautiful rant.
>>
>> Entertaining and all as hand-waving may be, please let us know if you
>> manage to unearth any actual facts to support the claims that you made
>> about junos's alleged feature deficits.
>>
>> Nick
>>
>>

Re: NTT high packet loss from US and BR to AU?

[Charles van Niman]

Howdy all,

  I've been lurking for a long time, first time writing in. Please
excuse my inexperience. Javier, can you provide full traces, and
source/destination addresses?

/Charles

On Wed, Oct 22, 2014 at 11:18 PM, Javier J 
wrote:

> Anyone else notice this?
>
> Or is this an AWS issue in APAC that hasn't been reported yet?
>
> AU-NY(aws)
> 18. xe-1.level3.lsanca03.us.bb.gin.n 72.0%
>
> BR(aws)-AU(aws)
> 11. ae-9.r20.snjsca04.us.bb.gin.ntt.net 71.4%
>
>
> NJ/NYC to AU(aws)
> 9. ae-9.r20.asbnva02.us.bb.gin.ntt.net 45.9% 772 10.1 16.4 9.2 94.4 13.3
> 10. ae-2.r21.lsanca03.us.bb.gin.ntt.net 40.5% 772 69.6 72.7 69.3 149.2 9.0
>

Re: nanog.org Website down ?

[Charles van Niman]

Yeah, looks like this just made it to the list:

>This morning we suffered a hardware failure in our production environment.
>The outage affected nanog mail and web services. While mail services have
>recovered, web services are still down.

On Wed, Jun 3, 2015 at 8:31 AM, Bob Evans  wrote:
> Not sure what's up - however I see what's down this AM. From the hotel
> nanog.org was not reachable. S, I tunneled out of the hotel to my
> office, still not reachable at 6:15 AM
>
> nanog.org (50.31.151.73)
> www.nanog.org (50.31.151.73)
>
> Bob Evans
> CTO
> Fiber Internet Center
>
>
>
>
>

Re: AS4788 Telecom Malaysia major route leak?

[Charles van Niman]

Does anyone at Level3 care to comment here about this event, and if
there are any plans to push BGP prefix security?

2015-06-12 8:25 GMT-05:00 Jürgen Jaritsch :
> http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/
>
>
>
> 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
>

Re: high latency on West Coast?

[Charles van Niman]

Hmmm, I am seeing about 20ms from a VPS in Seattle, do you happen to
have a trace of the path with this issue?

/Charles

On Fri, Sep 18, 2015 at 1:50 PM, Florin Andrei  wrote:
> I'm seeing 250 ms between California and Oregon. Not just AWS, but also
> between, say, Comcast and AWS.
>
> Latency from other locations, such as between N. Virginia and Oregon, is
> much lower, about 72 ms in my tests.
>
> Anyone else experiencing these issues along the west coast?
>
> --
> Florin Andrei
> http://florin.myip.org/

Re: Huge latency/packet loss between Hibernia and NTT at New York

[Charles van Niman]

Do you happen to have a copy of the path going in the other direction?
Based on this it seems that the issue starts after this leaves NTT.

/Charles

On Wed, Sep 23, 2015 at 9:01 PM, Paras  wrote:
> Hi all,
>
> Is anyone else seeing high latency and huge packet loss at NTT's NYC
> location?
>
> Packets   Pings
>  Host Loss%   Snt   Last   Avg  Best  Wrst StDev
>  1. hosted-by.reliablesite.net 0.0%920.7   1.5   0.7   6.6   1.7
>  2. 108.61.244.105 0.0%910.2   0.2   0.2   0.4   0.0
>  3. vl210-br2.pnj1.choopa.net 0.0%917.0   3.3   0.2  12.7   4.2
>  4. ae-33.r05.nycmny01.us.bb.gin.ntt.net 0.0%911.7   1.8   1.3   3.5
> 0.5
>  5. xe-0-4-0-35.r05.nycmny01.us.ce.gin.ntt.net 1.0%91  101.1 101.1 100.7
> 107.0   0.7
>  6. eth1-4.core1.nyc4.us.as5580.net 6.6%91  105.7 105.5 101.3 114.0
> 4.2
>  7. eth1-4.r1.dal1.us.as5580.net 7.7%91  101.6 102.1 101.3 128.0   3.1
>  8. new-jersey.ddos-filter.as63990.net 8.8%91  101.9 101.9 101.6 102.0
> 0.1
>  9. ???
> 10. ???
> 11. ???
> 12. ???
> 13. ???
> 14. ???
> 15. protraf.ddos-filter.as63990.net 8.8%91  101.9 101.9 101.7 102.3
> 0.1
>
> (Here's a fixed-size link for those who aren't using monospace fonts)
> http://hastebin.com/sivorejalu.avrasm
>
> At around hop 5 NTT completely drops the ball
>

Latency in ATT DSL from Houston.

[Charles van Niman]

Hello All,

I am trying to get some assistance with latency I am seeing inside
ATT. DSL Support has been next to useless, and I am already pursing
different connectivity options, but getting this fixed would be
awesome. The problem is two fold, I see latency to pretty much any
destination, that starts after my modem / gateway. The second part of
the problem is mostly clerical, ATT seems to be using IANA
documentation space inside their network, which DSL support has no
explanation for.

If someone from ATT could reach out to me off-list, that would be
greatly appreciated.

db-353-fw01> traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets


 1  75.39.205.94 (75.39.205.94)  2.451 ms  2.713 ms  2.693 ms
 2  192.0.2.100 (192.0.2.100)  882.693 ms  1375.347 ms  682.396 ms
 3  12.83.37.201 (12.83.37.201)  993.819 ms  1436.967 ms  616.373 ms
 4  12.122.85.197 (12.122.85.197)  944.982 ms  911.500 ms  676.696 ms
 5  206.121.120.70 (206.121.120.70)  937.521 ms  1312.248 ms
206.121.120.66 (206.121.120.66)  1353.350 ms
 6  216.239.40.139 (216.239.40.139)  1756.335 ms 216.239.54.109
(216.239.54.109)  1117.386 ms *
 7  72.14.238.45 (72.14.238.45)  1710.237 ms 64.233.175.9
(64.233.175.9)  1005.727 ms 64.233.174.151 (64.233.174.151)  1707.119
ms
 8  google-public-dns-a.google.com (8.8.8.8)  1468.629 ms  1529.764 ms
 834.876 ms


admin@db-353-fw01> traceroute 4.2.2.2
traceroute to 4.2.2.2 (4.2.2.2), 30 hops max, 40 byte packets
 1  75.39.205.94 (75.39.205.94)  2.702 ms  5.745 ms  6.493 ms
 2  192.0.2.100 (192.0.2.100)  1986.510 ms  621.122 ms  604.383 ms
 3  12.83.37.201 (12.83.37.201)  1202.705 ms  1886.382 ms  1821.073 ms
 4  gar26.dlstx.ip.att.net (12.123.16.109)  1458.154 ms  1338.124 ms
1766.894 ms
 5  * * *
 6  ae-3-80.edge2.Dallas1.Level3.net (4.69.145.139)  999.252 ms
ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  1597.016 ms  1843.397
ms
 7  ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  2156.637 ms
ae-1-60.edge2.Dallas1.Level3.net (4.69.145.11)  1125.729 ms
ae-4-90.edge2.Dallas1.Level3.net (4.69.145.203)  1912.391 ms
 8  b.resolvers.Level3.net (4.2.2.2)  1282.430 ms  1640.264 ms  1037.577 ms

admin@db-353-fw01> traceroute 12.123.16.109
traceroute to 12.123.16.109 (12.123.16.109), 30 hops max, 40 byte packets
 1  75.39.205.94 (75.39.205.94)  2.994 ms  3.034 ms  2.660 ms
 2  192.0.2.100 (192.0.2.100)  626.326 ms  1637.689 ms  1883.235 ms
 3  12.83.37.205 (12.83.37.205)  1972.528 ms !X * *

/Charles