Re: Friday Thanks

[Graham Johnston via NANOG]

Sorry, NTT, I didn't mean to leave you out, you were great too - Thanks.




From: NANOG  on 
behalf of Graham Johnston via NANOG 
Sent: Friday, August 11, 2023 10:53 AM
To: nanog@nanog.org 
Subject: Friday Thanks

I've been busy over the last few days trying to clean up IRR information for 
our subnets and issue ROAs for our address space. Invariably I came across 
stale entries in various IRR databases. They aren't really hurting me, but I 
feel like there shouldn't be competing incorrect information out there that I'm 
not in control of. The database maintainers have been mixed in their response 
so far. This email isn't about name and shame though, I'm not at that point. 
Instead, I want to provide thanks to two organizations that have been very 
responsive and easy to deal with in getting records cleaned up.


RADb - Thank you.


Level3/CenturyLink/Lumen - Thank you.



Separately, I know there is some work to do with ARIN's recent RPKI/IRR 
changes, but as someone from a regional ISP, rather than a national or 
multi-national ISP, I can say that the tools are moving in the right direction. 
The experience right now is better than it was several years ago. Thank you 
ARIN for the improvements and the dedication to work with us on making further 
improvements.


Have a good weekend,

Graham

Friday Thanks

[Graham Johnston via NANOG]

I've been busy over the last few days trying to clean up IRR information for 
our subnets and issue ROAs for our address space. Invariably I came across 
stale entries in various IRR databases. They aren't really hurting me, but I 
feel like there shouldn't be competing incorrect information out there that I'm 
not in control of. The database maintainers have been mixed in their response 
so far. This email isn't about name and shame though, I'm not at that point. 
Instead, I want to provide thanks to two organizations that have been very 
responsive and easy to deal with in getting records cleaned up.


RADb - Thank you.


Level3/CenturyLink/Lumen - Thank you.



Separately, I know there is some work to do with ARIN's recent RPKI/IRR 
changes, but as someone from a regional ISP, rather than a national or 
multi-national ISP, I can say that the tools are moving in the right direction. 
The experience right now is better than it was several years ago. Thank you 
ARIN for the improvements and the dedication to work with us on making further 
improvements.


Have a good weekend,

Graham

RE: Akvorado Resource Requirements

[Graham Johnston via NANOG]

Thanks, Vincent, I appreciate the feedback.

Regards,
Graham
 

-Original Message-
From: Vincent Bernat  
Sent: Friday, March 24, 2023 2:35 PM
To: Graham Johnston ; nanog@nanog.org
Subject: Re: Akvorado Resource Requirements

On 2023-03-24 15:01, Graham Johnston via NANOG wrote:
> For anyone running Akvorado, can you please comment on resource requirements. 
> I'm most concerned with CPU and memory, with the assumption that resources 
> are somewhat linear to flow rate, but also curious about disk usage 
> secondarily.


A VM with 64 GB, 24 vCPU can sustain about 100k flows/s.

1 TB seems enough to keep data for about 5 years at 30k flows/s with the 
default setup. This is however highly dependent on how well your flows can be 
compressed. The main table with the default retention can use around 600 GB by 
itself. The data compresses well outside of the main table.

You should test on your setup and let it run for a few days. You can check how 
much space each table uses and extrapolate depending on the TTL set on each 
table.

Akvorado Resource Requirements

[Graham Johnston via NANOG]

For anyone running Akvorado, can you please comment on resource requirements. 
I'm most concerned with CPU and memory, with the assumption that resources are 
somewhat linear to flow rate, but also curious about disk usage secondarily. 

Thanks,
Graham

Experiences with commercial NOS vendors in white box space

[Graham Johnston]

Good day.

I'm curious to hear from those with direct, hopefully in-production,
experience in using a commercial network operating system vendor along
with white box switches. I'm specifically looking for operators in the
service provider space, rather than data center or enterprise. I'm
largely focused on Jericho2/Qumran2 based devices, with what would
likely be modest feature requirements. We currently use MPLS with RSVP
to build automatic paths, but don't do anything specific for traffic
engineering. Segment routing isn't a requirement for today. Currently
use more traditional forms of MPLS services for customer L2 and L3
VPNs, but are investigating a transition to EVPN. Automation is very
much important to us, as are routing security features. Based on
research, and use of vertically integrated Jericho-based switches, we
aren't concerned about QoS as our needs aren't super complex. I guess
I'm largely saying that we don't expect the ASIC to be the weak point
in our use case, but rather the NOS or the nature of support from the
vendor.

I'm aware of IPInfusion and their OcNOS product, but the CLI and
config syntax feels dated. I feel like I've been ruined by Cisco RPL,
Juniper policy-statements, and Arista RCF and expect I would find
wanting more than what route-map syntax has to offer. Can I accomplish
the same complex routing policies via route-maps that I can with more
modern solutions, and I'm just assuming it's limiting? Is it fair to
say that even if I can achieve the same functionality, that route-maps
are the poorer choice when it comes to the human interaction aspect?

I know of Arrcus, but don't know much more than I can see on their
website. Edge-core has an interesting reference in its Open Networking
Solution Guide on their website in which they position Arrcus for core
applications and IPInfusion for access and aggregation. All of which
could be meaningless based on the varied definitions and expectations
of what a core network is and does. Is it feature rich or just a set
of fast LSR P-routers? The Edge-Cor guide also identifies Exaware and
Capgemini, both of whom I know little about. Are there viable SP
focused NOS vendors that I haven't touched on?

Thanks in advance for any reply, be it on-list or off-list.

Regards,
Graham

Re: Random Early Detect and streaming video

[Graham Johnston]

Sorry, everyone, my initial reply was only to Saku so I'm replying again
for visibility to the list.

On Tue, 8 Nov 2022 at 02:57, Saku Ytti  wrote:

> Hey,
>
>
> On Mon, 7 Nov 2022 at 21:58, Graham Johnston 
> wrote:
>
>
> > I've been involved in service provider networks, small retail ISPs, for
> 20+ years now. Largely though, we've never needed complex QoS, as at
> $OLD_DAY_JOB, we had been consistently positioned to avoid regular link
> congestion by having  sufficient capacity. In the few instances when we've
> had link congestion, egress priority queuing met our needs.
>
> What does 'egress priority queueing' mean? Do you mean 'send all X,
> before any Y, send all Y before any Z'? If this, then this must have
> been quite some time now, as since traffic managers were implemented
> in hardware ages ago, this hasn't been available. And the only thing
> that has been available has been 'X has guaranteed rate X1, Y has Y1
> and Z has Z1' and love it or hate it, that's the QoS tool industry has
> decided you need.
>

Yeah, I'm sure I didn't use all of the features, we did have to set a
bandwidth-share value and possibly a bit more. I guess as I look at my past
it was more a case of not having to perform any rate limiting on the parts
of the network that I'm thinking about, and long term familiarity with that
platform as compared to the new environment which I'm less familiar with,
and is a different platform, Juniper to be specific.


>
> > combine that with the buffering and we should adjust the drop profile to
> kick in at a higher percentage. Today we use 70% to start triggering the
> drop behavior, but my head tells me it should be higher. The reason I am
> saying this is that we are dropping packets ahead of full link congestion,
> yes that is what RED was designed to do, but I surmise that we are making
> this application worse than is actually intended.
>
> I wager almost no one knows what their RED curve is, and different
> vendors have different default curves which is then the curve almost
> everyone uses. Some use a RED curve such that everything is basically
> tail drop (Juniper, 0% drop at 96% fill and 100% drop at 98% fill).
> Some are linear. Some allow defining just two points, some allow
> defining 64 points. And almost no one has any idea what their curve
> is, i.e. mostly it doesn't matter. If it usually mattered, we'd all
> know what the curve is and why. As practical example Juniper has
> basically
>

Overall, with my current concern being drops before they seem to be
necessary, combined with you comments about Juniper which I take to be the
behavior of default drop profile, I feel more confident that our current
drop profile behavior is just more aggressive than it needs to be.


>
> In your case, I assume you have at least two points with 0% drop at
> 69% fill, then a linear curve from 70% to 100% fill with 1% to 100%
> drop. It doesn't seem outright wrong to me. You have 2-3 goals here,
> to avoid synchronising TCP flows so that you have steady fill, instead
> of wave-like behaviour and to reduce queueing delay for packets not
> dropped, which would experience as long a delay as there is queue if
> tail dropped. You could have a 3rd possible goal, if you map more than
> 1 class of packets into the same queue you can still give them
> different curves, so during congestion in a single queue can show two
> different behaviours depending on packet.
> So what is the problem you're trying to fix? Can you measure it?
>

As mentioned above, my problem/supposition is that we drop too much before
it's necessary and impact the customer experience in a way that isn't
needed. While I can't directly measure the customer experience, I can
measure drop rate versus bandwidth. If my supposition is correct, that a
drop profile that drops later (at a higher utilization rate), we'd see less
dropped packets, and possibly a higher utilization rate. While this whole
configuration policy is in place to reduce utilization, we operate these
links with a hard cap, thus I'd like to use as much of it as possible. What
may have changed is that in the past these links were functionally operated
at their capacity, rather than right now where we are slightly below
capacity.


>
> I suspect in a modern high speed network with massive amounts of flows
> the wave-like synchronisation is not a problem. If you can't measure
> it or If your only goal is to reduce queueing delay because you have
> 'strategic' congestion, perhaps instead of worrying about RED, use
> tail only and reduce queue size to something that is tolerable 1ms-5ms
> max?
>

On many levels, it does seem like what I want is tail drop rather than RED.


> --
>   ++ytti
>

Thanks for your response, Saku. I also am a user of Oxidized, thanks for
that as well.

Random Early Detect and streaming video

[Graham Johnston]

I've been involved in service provider networks, small retail ISPs, for 20+
years now. Largely though, we've never needed complex QoS, as at
$OLD_DAY_JOB, we had been consistently positioned to avoid regular link
congestion by having sufficient capacity. In the few instances when we've
had link congestion, egress priority queuing met our needs. With a new
organization there is a set of circumstances that have resulted in a long
standing business decision to apply some rate-limiting/traffic management
during times of higher utilization to a subset of traffic. This traffic
happens to be ABR streaming video traffic. The thought was that a little
bit of packet loss that comes from RED or WRED could largely be absorbed in
the ABR playback client's innate behavior, and yes, possibly a drop in
video profile. These are acceptable business outcomes in this case. The
question I have for the smart people of this list is, given the specific
application that is receiving this treatment, is there any reason to apply
a RED behavior any appreciable amount before the bandwidth limit for this
application? It makes sense to me for interactive TCP traffic where you
want to apply some artificial control to the TCP window, but I *feel* like
ABR streaming video was designed to expect congestion, at least as the edge
of the customers home, and combine that with the buffering and we should
adjust the drop profile to kick in at a higher percentage. Today we use 70%
to start triggering the drop behavior, but my head tells me it should be
higher. The reason I am saying this is that we are dropping packets ahead
of full link congestion, yes that is what RED was designed to do, but I
surmise that we are making this application worse than is actually intended.

Hopefully my targeted vagurey has still left enough context intact to
receive some useful commentary back.

Thanks

EVPN-VXLAN Service Types

[Graham Johnston via NANOG]

Good day, NANOG.

I'm at the front end of an expected implementation of EVPN-VXLAN as the primary 
method to shift a network that is largely based on traditional Ethernet 
switching and spanning-tree to one that attempts to route traffic as often as 
possible, and where we want to separate the physical topology from the logical 
services. We are selecting EVPN-VXLAN as it seems to inherently provide for the 
Network Virtualization Overlay function, as well as routing since the entire 
underlay will be routed. As part of all the reading we are doing, and lab 
testing that is just about to commence, I'm trying to weigh the options around 
VLAN-based services and VLAN-aware bundle services. I know that the options 
aren't mutually exclusive, and that I can mix and match, at least I expect that 
this to be an option.

In case it matters, our implementation will initially involve VTEPs based on a 
mix of Juniper QFX5100, QFX5110, QFX5120, and EX4650 switches, as well as MX. 
Yes, I do recognize the RIOT capabilities that aren't present in the QFX5100.  
From a basic FIB standpoint, we do believe that we are well below the quote 
limits in terms of hosts, routes, etc. I do believe that we've effectively 
weighed the use of VXLAN over MPLS. We currently believe that our use cases 
don't require some of the more advanced features and control knobs available in 
MPLS. We are also pragmatic and are trying to use the equipment that we have. 
We believe that the Trident ASICs in our devices are likely better suited for 
VXLAN than MPLS, despite the glossy datasheets quoting support for various MPLS 
features. Feel free to comment on this.

For internal use, I can see the VLAN-aware bundles as advantageous to group all 
our own services together in a single MAC-VRF, treat ourselves as a tenant. I'm 
not clear yet if I should be concerned or not about each switch that is 
involved in this EVI having to populate all entries into FIB. Our own use cases 
are likely of a small enough scale that it wouldn't matter in comparison to the 
positive outcomes. As for customer use cases, I can't yet see an advantage to 
VLAN-aware bundles as our customers don't interact with multiple VLANs where 
those individual VLANs are terminating on individual VTEP ports. The customer 
use cases feel more like a traditional Q-in-Q type activity that has us 
treating them as single outer VLAN, and thus the VLAN-based service seems more 
appropriate. I'm flat out ignoring the middle ground option of VLAN-bundle 
service as I can't see anything that seems compelling compared to the other two.

I know there is bunch that I don't know here. Am I focusing on the right two 
choices of the three service types? Do organizations regularly use both two 
that I am focusing on? How do you decide between the two models when 
provisioning an EVI? What gotchas await me with the Juniper equipment, or the 
Trident ASICs, that just aren't spelled out in the documentation? Answers to 
these questions and anything else you have to offer is appreciated.

Thanks in advance,
Graham

RE: Quantifying the customer support and impact of cgnat for residential ipv4

[Graham Johnston]

>We have 10,000+ customers and by default everyone is behind CGNAT. Around 25 
>customers have asked for a dedicated public IP 
>address and we usually just give them one free of charge. For our case, very 
>low percentage actually request one.

> Travis

Out of curiosity, based on your experience, or anyone else that wishes to 
respond, how many public IPs are required per 1000 customers?

Re: 100G, input errors and/or transceiver issues

[Graham Johnston]

Thank you all for the consensus. What I hear from you is that 100G takes
more care to operate error free, as compared to 10G, which wasn't
surprising to me. Also, that generally, we should be able to operate
without errors, or certainly less than I'm currently observing, and that
connector and transceiver interface cleanliness is our first likely point
of investigation.

Thanks to all who responded.

On Mon, 19 Jul 2021 at 12:58, Jared Mauch  wrote:

>
>
> > On Jul 19, 2021, at 1:50 PM, Saku Ytti  wrote:
> >
> > On Mon, 19 Jul 2021 at 20:19, Graham Johnston
> >  wrote:
> >
> >> I don't at this point have long term data collection compiled for the
> issues that we've faced. That said, we have two 100G transport links that
> have a regular background level of input errors at ranges that hover
> between 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that
> jumped to 0.03943 PPS over the weekend). The range is often directionally
> associated rather than variable
> >
> > On typical 100G link we do not get single FCS error in a typical day.
> > However Ethernet spec still allows very high error rate of 10**-12. So
> > 1 error per 1Tb (b not B). I.e. 1 error per 10s, or 0.1PPS would be
> > in-spec. We see much better performance to this and vendors generally
> > accept lower error rates as legitimate errors.
> >
>
> I will confirm my experience with this at $dayjob as well.  We see
> interfaces with no errors over much longer periods of time inclusive of
> several of the technology options.  If you are seeing errors, there’s
> likely something wrong like unclean fiber or bad optic/linecard etc.
>
> - Jared
>
>

Re: 100G, input errors and/or transceiver issues

[Graham Johnston]

Saku,

I don't at this point have long term data collection compiled for the
issues that we've faced. That said, we have two 100G transport links that
have a regular background level of input errors at ranges that hover
between 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that
jumped to 0.03943 PPS over the weekend). The range is often directionally
associated rather than variable behavior of a single direction. The data
comes from the last 24 hours, the two referenced links are operated by
different providers on very different paths (opposite directions). Over
shorter distances, we've definitely seen input errors that have affected
PNI connections within a datacenter as well. In the case of the last PNI
issue, the other party swapped their transceiver, we didn't even physically
touch our side; I note this only to express that I don't think this is just
a case of the transceivers that we are sourcing.

Comparatively, other than clear transport system issues, I don't recall
this sort of thing at all with 10G "wavelength" transport that we had
purchased for years prior. I put wavelengths in quotes there knowing that
it may have been a while since our transport was a literal wavelength as
compared to being muxed into a 100G+ wavelength.

On Mon, 19 Jul 2021 at 12:01, Saku Ytti  wrote:

> On Mon, 19 Jul 2021 at 19:47, Graham Johnston
>  wrote:
>
> Hey Graham,
>
> > How commonly do other operators experience input errors with 100G
> interfaces?
> > How often do you find that you have to change a transceiver out? Either
> for errors or another reason.
> > Do we collectively expect this to improve as 100G becomes more common
> and production volumes increase in the future?
>
> New rule. Share your own data before asking others to share theirs.
>
> IN DC, SP markets 100GE has dominated the market for several years
> now, so it rings odd to many at 'more common'. 112G SERDES is shipping
> on the electric side, and there is nowhere more mature to go from
> 100GE POV. The optical side, QSFP112, is really the only thing left to
> cost optimise 100GE.
> We've had our share of MSA ambiguity issues with 100GE, but today
> 100GE looks mature to our eyes in failure rates and compatibility. 1GE
> is really hard to support and 10GE is becoming problematic, in terms
> of hardware procurement.
>
>
> --
>   ++ytti
>

100G, input errors and/or transceiver issues

[Graham Johnston]

Good day,

Over the last two years, organizations that I've worked with have upgraded
equipment and now make regular use of 100G port speeds. To provide a frame
of reference on use cases, the organizations that I've worked for make use
of 100G speeds within their own data centers, in carrier neutral data
centers, and lease 100G transport from larger carriers; they don't
currently operate their own 100G coherent/long-haul networks.


   - How commonly do other operators experience input errors with 100G
   interfaces?
   - How often do you find that you have to change a transceiver out?
   Either for errors or another reason.
   - Do we collectively expect this to improve as 100G becomes more common
   and production volumes increase in the future?

Thanks,
Graham

BGP Graceful Restart

[Graham Johnston]

I do believe that I understand the intended purpose of BGP
graceful-restart. With that said, I was watching a video of a talk
given by someone respected in the industry the other day on the use of
graceful-shutdown and at the beginning of the talk there was a quick
disclaimer that his topic had nothing to do with graceful-restart
along with some text on the slide that provided me a clear indication
that he was not a fan of graceful-restart.

Largely, I suspect that his point was that if you otherwise do the
right things during maintenance that graceful-restart has the
potential of being really problematic if things go wrong, and thus he
was discouraging the use of it. Is there consensus as to whether
graceful-restart has any place in a service provider network?

Thanks,
Graham

MIB Browser Recommendation

[Graham Johnston]

We have historically been a CentOS shop when it comes to choice of Linux OS, 
and in turn that meant, largely out of laziness, that we used mbrowse to browse 
mibs and perform simple snmp test queries to devices, just manual work until we 
find what we want and configure something in our NMS. We are moving some 
servers to Ubuntu now with the change to CentOS/RHEL, and we are curious what 
others are using for a SNMP/MIB browser. An FOSS choice would be on top on our 
list as it is just easy to install from the repo, but I'll take any 
recommendation that people have.

Thanks,
Graham

RE: cloud automation BGP

[Graham Johnston]

Does anyone have a quick answer as to what public data sources are used? I 
tried looking at the main github page for the project but I either missed it or 
it isn't there.

Graham


-Original Message-
From: Randy Bush

have folk looked at https://github.com/nttgin/BGPalerter

randy

RE: Advertisement of Equinix Chicago IX Subnet

[Graham Johnston]

Thank you Nick.

Graham Johnston
Manager, Network Services
Westman Communications Group
1906 Park Avenue | Brandon, MB | R7B 0R9
204-717-2829 |    
johnst...@westmancom.com



        

-Original Message-
From: Nick Hilliard  
Sent: March 27, 2019 4:50 PM
To: Graham Johnston 
Cc: nanog@nanog.org
Subject: Re: Advertisement of Equinix Chicago IX Subnet

CAUTION: This email is from an external source. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.

Graham Johnston wrote on 27/03/2019 21:36:
> What am I doing that isn't best practices that would have prevented this?

you're setting the next-hop of the prefixes learned at the IXP to be
your own IP address from the IXP subnet (i.e. 208.115.136.0/23).

When your routers learn this address from an external source, that is
preferred to your internal OSPF route.  Ergo your IX traffic is sent out
via transit.

There are two things you should do:

1. change the bgp distance for ebgp to be higher than all your IGPs.  On
a cisco router, you would use something like:

router bgp xxx
  address-family ipv4
   distance bgp 200 200 200
  address-family ipv6
   distance bgp 200 200 200

2. use next-hop-self on internal ibgp sessions to ensure that when you
redistribute the eBGP routes learned from your IX towards the internals
of your network, the next-hop address is set to be the loopback address
of your peering router.  I.e. you remove the requirement for your
internal network to know anything about the IXP address range.

Nick

Advertisement of Equinix Chicago IX Subnet

[Graham Johnston]

This afternoon at around 12:17 central time today we began learning the subnet 
for the Equinix IX in Chicago via a transit provider; we are on the IX as well. 
The subnet in question is 208.115.136.0/23. Using stat.ripe.net I can see that 
this subnet is also being learned by others, see the snip below. On our network 
this caused a nasty routing loop until we figured out what was wrong. My 
current best understanding is that because the route was learned via eBGP it 
trumped the OSPF learned route. As soon as I filtered the advertisement from my 
transit provider everything returned to normal. What am I doing that isn’t best 
practices that would have prevented this?

Thanks,
graham


RIPE Info
1 RRCs see 1 peers announcing 208.115.136.0/23 originated by 
AS32703

* ▼RRC00 in Amsterdam, Netherlands sees 1 ASN orginating 
208.115.136.0/23.AS32703

o▼AS32703 is seen as the origin by 1 
peer.192.102.254.1

§  ▼192.102.254.1 is announcing route 
AS395152 AS63297 
AS6327 
AS36280AS32703.

§  Origin: IGP

§  Next Hop: 192.102.254.1

§  Peer: 192.102.254.1

§  Community: 63297:1000

§  AS Path: 395152 63297 6327 36280 32703

§  Last Updated: 2019-03-27T17:17:19


Route-views
route-views.chicago.routeviews.org> show ip bgp 208.115.136.0
BGP routing table entry for 208.115.136.0/23
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  32709 32703
208.115.136.134 from 208.115.136.134 (63.134.128.248)
  Origin IGP, localpref 100, valid, external, best
  AddPath ID: RX 0, TX 64414249
  Last update: Wed Mar 27 17:16:09 2019

IRR Cleanliness

[Graham Johnston]

Hi,

I'm in the middle of transitioning all of my IRR data from RADb to ARIN and as 
part of this I am trying to get old stale IRR data cleaned up that other 
providers have put in place in the past.  While doing this I was using the 
nlnog IRR explorer website and found that a company that I peer with on a 
public exchange has my ASN listed in an as-macro that they control. The way the 
as-macro is named I am reasonably confident that they aren't using it for 
transit related activity, rather they are likely using it for controlling 
peering activity and filtering on the IX in question. Part of me is okay with 
this, but given that I've never seen this behavior from any other provider on 
the three reasonably large exchanges that we participate on I am curious what 
the community thinks about this. Is this uncommon but acceptable in the eyes of 
community?

Thanks,
Graham

DAZN CDN

[Graham Johnston]

Anyone from DAZN here, or anyone know what CDN is used for their content? I'm 
specifically curious about NFL Sunday Ticket content in case it makes a 
difference.

Thanks,
Graham

Datacenter powering

[Graham Johnston]

Anybody out there willing to provide a brief description of the power 
configuration in your datacenter today and further comment on if there are ways 
you would reconfigure it given the chance?

To provide context, I am asking from the standpoint of a datacenter operated 
for your own use, not part of a co-location type environment. Total power draw 
in my situation is ~100kW.

graham

Zabbix IT Services feature set

[Graham Johnston]

Hi,

We have the Zabbix IT Services (running on Zabbix 3.2) configured for some test 
groups.  It usually returns good data but occasionally it seems that one 
service group or trigger will get stuck in an alerting state and provide an 
incorrect SLA.  This can occur if the trigger has changed to a problem state 
and then back to OK but the IT services doesn't reflect that change.  It will 
occur where the top level group will show as having 100% problem time and the 
sub groups and items either have no problem time or such a small amount that it 
wouldn't indicate 100% problem time.

We have it built with some groups under root, some sub groups and items and the 
items will have a trigger associated with those items.  We followed this 
article to the best of our knowledge: 
https://www.zabbix.com/documentation/3.2/manual/it_services
 
For Example: 
|Data Center 
|-Core1
|--Core1 - ICMP - Trigger
|-Core2
|--Core2 - ICMP - Trigger

Each subitem is a child of the item above it.  We haven't configured any 
dependencies to any other groups or items.
My question is, has anyone gotten the Zabbix IT Services to work correctly?  Is 
there a trick to getting it to work, some configuration we are doing 
incorrectly?

Thanks,
Graham

RE: Templating/automating configuration

[Graham Johnston]

Job,

Would you be able to provide any further insight into your Don’t #5 – “Don’t 
agree to change management. Managers are rarely engineers and should not be 
making technical decisions. (nor should sales)“.

Thanks,
Graham

From: Job Snijders [mailto:j...@ntt.net]
Sent: Tuesday, June 6, 2017 4:03 PM
To: Brian Knight <m...@knight-networks.com>; Graham Johnston 
<johnst...@westmancom.com>
Cc: nanog@nanog.org
Subject: Re: Templating/automating configuration

Hi,

Here are some extra pointers:

https://youtube.com/watch?v=C7pkab8n7ys

https://www.nanog.org/sites/default/files/dosdontsnetworkautomation.pdf

https://github.com/coloclue/kees

Kind regards,

Job


On Tue, 6 Jun 2017 at 13:49, Brian Knight 
<m...@knight-networks.com<mailto:m...@knight-networks.com>> wrote:
Because we had different sources of truth which were written in-house, we wound 
up rolling our own template engine in Python. It took about 3 weeks to write 
the engine and adapt existing templates.  Given a circuit ID, it generates the 
full config for copy and paste into a terminal session.  It also hooks into a 
configuration parser tool, written in-house, that tracks configured interfaces, 
so it is easy to see whether the template would overwrite an existing interface.



I used the Jinja2 template engine, along with pyodbc/unixODBC/FreeTDS for 
access to a Microsoft SQL backend.



The keys for us are:



* extracting information from a source of truth

* validating the information for correctness

* making sure you don't overwrite existing config

* outputting the right templates for the circuit features



It made more sense to write a tool than it did to try to adapt something for 
our environment.



If I had a free hand and unlimited budget, I would find a single app that 
functions as a source of truth for all circuits and products, which includes a 
templating engine that hooks in easily.



-Brian





 On Tue, 06 Jun 2017 08:22:59 -0500 Graham Johnston 
johnst...@westmancom.com<mailto:lt%3bjohnst...@westmancom.com> wrote 












Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept.



Graham Johnston

Network Planner

Westman Communications Group

204.717.2829

johnst...@westmancom.com<mailto:johnst...@westmancom.com>mailto:johnst...@westmancom.com<mailto:johnst...@westmancom.com>

Templating/automating configuration

[Graham Johnston]

Short of complete SDN, for those of you that have some degree of configuration 
templating and/or automation tools what is it that you run? I'm envisioning 
some sort of tool that let's me define template snippets of configuration and 
aids in their deployment to devices. I'm okay doing the heaving lifting in 
defining everything, I'm just looking for the tool that stitches it together 
and hopefully makes things a little less error prone for those who aren't as 
adept.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>

BCP38/84 and DDoS ACLs

[Graham Johnston]

I really did try looking before I sent the email but couldn't quickly find what 
I was looking for.

I am looking for information regarding standard ACLs that operators may be 
using at the internet edge of their network, on peering and transit 
connections, wherein you are filtering ingress packets such as those sourced 
from UDP port 19 for instance. I've found incomplete conceptual discussions 
about it nothing that seemed concrete or complete.

This doesn't seem quite like it is BCP38 and more like this is BCP84, but it 
only talks about use of ACLs in section 2.1 without providing any examples. 
Given that it is also 13 years old I thought there might be fresher information 
out there.

Thanks,
graham 

Static IP allocation schemes for end users (commercial)

[Graham Johnston]

I work for a cable MSO, meaning that our access network is DOCSIS based. 15 
years ago when we had way more IP addresses than customers we had a static IP 
allocation scheme wherein we aligned a /24 with each node and reserved the 
first 20 or so IPs for static assignment, the rest being left for dynamic 
assignment. The primary reason behind this scheme was that as the network grew 
and a node moved from one CMTS to another we could pull the /24 with it and 
customers wouldn't have to re-address.

As our network has grown, in terms of the number of nodes, as well as the 
number of IPs in use we've come to the obvious conclusion that the old scheme 
isn't workable into the future. For instance I will soon have more nodes in 
service than I have /24s allocated to me.

Instead we are entertaining two basic options as an alternative.

  *   Create static reservations, as required, within the otherwise dynamic 
range.
 *   Whether or not the customer continues to DHCP or assigns the IP 
statically doesn't matter to me.
  *   Move to having a single subnet, or portion therein, per CMTS. This keeps 
the process more or less identical to what we do now.

Both of the schemes above would require the customer to undergo addressing 
changes in the event that we move their node between CMTSs in the future.

Can anyone else share what they are doing or otherwise identify if there is a 
best practice in this area?

Thanks,
Graham

RE: Regulatory Recovery Surcharge for Canadian corporations

[Graham Johnston]

We don't explicitly pay a charge like this for the transit bandwidth we 
purchase in Toronto from an international carrier, and I doubt that it is built 
into the cost without any mention of it. I've never heard of such a thing.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Eric Dugas
Sent: Tuesday, March 14, 2017 9:04 AM
To: NANOG
Subject: Regulatory Recovery Surcharge for Canadian corporations

I recently negotiated a new contract with a tier1 for IP transit in Canada and
just got the invoice. I saw a "new" Regulatory Recovery Surcharge of 10% the
MRC (before taxes) that I've never seen before. Do any of my Canadian fellows
on this list are paying this outrageous surcharge?  

  

Other than saying "it's in the MSA", our rep, their tax and billing department
are not useful at all. The actual rate is not specified anywhere in the MSA or
in the contract.  

Favorite Speed Test Systems

[Graham Johnston]

For many years we have had a local instance of the Ookla speedtest.net on our 
network, and while it is pretty good some other tests seem include more 
detailed results.

I am aware of the following speedtest systems that an operator can likely have 
a local instance of:

* Speedtest.net

* Sourceforge.net/speedtest

* Dslreports.com/speedtest

Are there others? What is your preferred one and why?

Thanks,
Graham

Brocade MLXe Selective FIB Population

[Graham Johnston]

Does anybody have information on how to selective populate the IPv4 FIB on a 
Brocade MLXe?

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>
P think green; don't print this email.

Traffic engineering and peering for CDNs

[Graham Johnston]

Lately I have been putting in some effort to maximize our IX connections by 
trying to work with the top 5-ish list of ASNs that still send us traffic via a 
paid transit connection despite the fact that we are both present on the same 
IX(s). In one case I missed the fact that one ASN wasn't using the IXs 
route-servers, that's on me for not spotting that one.

Even with proper IX peering in place though it seems like some CDNs are better 
at using the IX connections than others.  ASN 15169 for instance does an 
excellent job sending more than 99.99% of traffic via the IX connection; thank 
you. While others only seem to manage to send 60 - 80% of traffic via the IX.  
What I am not understanding about the respective CDN's network wherein they 
don't send traffic to me through a consistent path? Is the content coming from 
widely different places and rather than transport it across their own network 
from a remote site they would rather hot-potato it out a local transit 
connection?  Are their transit costs so low that they don't care about using an 
IX connection over transit unlike a small operator like me? Is this just a 
non-obvious issue wherein they maybe just can't originate enough of the traffic 
near the IX and therefore don't make use of the IX connection, again a 
hot-potato phenomenon?

Secondly can someone explain to me why some CDNs want a gigabit or two of 
traffic to be exchanged between our respective networks before they would peer 
with me via a public IX? I totally get those kinds of thresholds before 
engaging in a private interconnect but I don't understand the reluctance with 
regard to a public IX, that they are already established at. Is it again just a 
simple case of bandwidth economics that operate at a different scale than I can 
comprehend?

I'm hoping the community can shed some light on this for me as I'm trying to 
avoid grilling the operators that are working with me as I don't expect those 
front line individuals to necessarily have a full view of the factors at play.

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>
P think green; don't print this email.

AS 714/6185 IX Peering

[Graham Johnston]

Is there anyone from AS 714/6185 that can reach out to me, AS 19016, to try and 
get traffic from your network to come to me via your Equinix IX connection 
instead of a transit connections.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>
P think green; don't print this email.

RE: Cable Operator List

[Graham Johnston]

DSG=Docsis Set-Top Gateway.  It is a more modern implementation of the command 
and control communications path that tradition video set-top boxes used.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>
P think green; don't print this email.

From: Colton Conor [mailto:colton.co...@gmail.com]
Sent: Tuesday, February 02, 2016 9:44 AM
To: Graham Johnston
Cc: NANOG
Subject: Re: Cable Operator List

Graham,

What is DSG? Yes, I am really looking for a CMTS to perform layer 2 just as our 
DSLAMs and GPON do today. All layer 3 will be upstream. I would want to handle 
DHCP upstream, but have the CMTS insert Option 82 if that is a feature. Not 
sure what specific CMTS stuff you need.

On Tue, Feb 2, 2016 at 8:12 AM, Graham Johnston 
<johnst...@westmancom.com<mailto:johnst...@westmancom.com>> wrote:
Colton,

It really depends on what features you are after.  I've demo'd one of the small 
1/2RU C-DOCSIS CMTSs, and they certainly work.  For us though it was a 
non-starter as we needed support for DSG and it didn't have it.  If all you are 
after is basic internet connectivity there is Pico Digital, Vecima, Sumavision, 
as well as others.  Many of the C-DOCSIS CMTSs seem either only support, or are 
more often meant to support layer 2 operations where the routing happens 
upstream from the CMTS.

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: NANOG [mailto:nanog-boun...@nanog.org<mailto:nanog-boun...@nanog.org>] On 
Behalf Of Colton Conor
Sent: Tuesday, February 02, 2016 8:00 AM
To: Daniel Corbe
Cc: NANOG
Subject: Re: Cable Operator List
Well, maybe NANOG's not a bad place for this post then! I would like to
know more about the data-only side of CMTS systems, and who the main
vendors are.

We have MDU properties where there is either old inside CAT3 phone wire, or
coaxial cable. We have looked and are very familiar with the multiple
technologies that work over phone lines namely VDSL2 and G.FAST. However,
using the coaxial cable seems to be a much better solution than using the
phone wires.

So I am looking for compacts, low cost CMTS systems. Based on the specs, I
am looking for something at least DOCSIS 3.0 capable, with at least 16X4
output. Something with the ability to upgrade to software upgrade to DOCSIS
3.1 would be nice, but I doubt that would be a low cost solution.

Whats out there for small operators that don't want a large chassis based
system to feed an entire town with.

So far I have found the
http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to
retail for under $5000.


On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe 
<dco...@hammerfiber.com<mailto:dco...@hammerfiber.com>> wrote:

>
> > On Feb 2, 2016, at 8:42 AM, Colton Conor 
> > <colton.co...@gmail.com<mailto:colton.co...@gmail.com>> wrote:
> >
> > Are there any mailing lists out there dedicated for cable/MSO type
> > operators?
> >
>
> I'm curious about this too.
>
> I’m not a cable operator (in that I haven’t successfully registered for a
> cable franchise yet) but I do operate a docsis network and I’ve
> successfully negotiated the treacherous waters of obtaining and providing
> content to my users.
>
> I’m still a bit green behind the ears but I could probably offer some
> measure of assistance if you have a specific question.
>
> -Daniel
>
>

RE: Cable Operator List

[Graham Johnston]

Those that are SCTE members have access to the SCTE mailing list.  Like the 
comments about the CableTV list, it is often focused on plant/transport/RF more 
than Docsis but there are good DOCSIS knowledgeable people on the list too that 
answer questions.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com
think green; don't print this email.


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colton Conor
Sent: Tuesday, February 02, 2016 7:42 AM
To: NANOG
Subject: Cable Operator List

Are there any mailing lists out there dedicated for cable/MSO type
operators?

RE: Cable Operator List

[Graham Johnston]

Colton,

It really depends on what features you are after.  I've demo'd one of the small 
1/2RU C-DOCSIS CMTSs, and they certainly work.  For us though it was a 
non-starter as we needed support for DSG and it didn't have it.  If all you are 
after is basic internet connectivity there is Pico Digital, Vecima, Sumavision, 
as well as others.  Many of the C-DOCSIS CMTSs seem either only support, or are 
more often meant to support layer 2 operations where the routing happens 
upstream from the CMTS.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com
think green; don't print this email.


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Colton Conor
Sent: Tuesday, February 02, 2016 8:00 AM
To: Daniel Corbe
Cc: NANOG
Subject: Re: Cable Operator List

Well, maybe NANOG's not a bad place for this post then! I would like to
know more about the data-only side of CMTS systems, and who the main
vendors are.

We have MDU properties where there is either old inside CAT3 phone wire, or
coaxial cable. We have looked and are very familiar with the multiple
technologies that work over phone lines namely VDSL2 and G.FAST. However,
using the coaxial cable seems to be a much better solution than using the
phone wires.

So I am looking for compacts, low cost CMTS systems. Based on the specs, I
am looking for something at least DOCSIS 3.0 capable, with at least 16X4
output. Something with the ability to upgrade to software upgrade to DOCSIS
3.1 would be nice, but I doubt that would be a low cost solution.

Whats out there for small operators that don't want a large chassis based
system to feed an entire town with.

So far I have found the
http://picodigital.com/product-details.php?ID=miniCMTS200a which seems to
retail for under $5000.


On Tue, Feb 2, 2016 at 7:48 AM, Daniel Corbe <dco...@hammerfiber.com> wrote:

>
> > On Feb 2, 2016, at 8:42 AM, Colton Conor <colton.co...@gmail.com> wrote:
> >
> > Are there any mailing lists out there dedicated for cable/MSO type
> > operators?
> >
>
> I'm curious about this too.
>
> I’m not a cable operator (in that I haven’t successfully registered for a
> cable franchise yet) but I do operate a docsis network and I’ve
> successfully negotiated the treacherous waters of obtaining and providing
> content to my users.
>
> I’m still a bit green behind the ears but I could probably offer some
> measure of assistance if you have a specific question.
>
> -Daniel
>
>

IPv6 Implementation and CPE Behavior

[Graham Johnston]

Hi nanog,

We are little behind in our IPv6 rollout are pushing to make big strides by the 
end of Q2.  We have all of our core network and primary infrastructure 
dual-stack enabled at this point and our next step will be to move to 
dual-stack on our CMTSs.  For those retail operators that have enabled 
dual-stack can you comment on behavior that you observed from customer CPE 
equipment after flipping the switch?  Are most CPE devices generally not IPv6 
capable in the first place?  For those that are capable are they usually still 
configured with IPv6 disabled, requiring the customer to enable it?  For those 
CPE that are capable and enabled, is there a common configuration such as full 
blown DHCPv6 with PD?

For those that are responding I am primarily concerned about customer routers.  
I have followed the many discussions about Android phones that don't perform 
DHCPv6, and I am really concerned about these kind of issues as these devices 
basically won't be seen at the edge of the customer's network.

If you have something else that you think is noteworthy, I'm all ears.

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>
P think green; don't print this email.

RE: Anyone having issues with Equinix IX out of Ashburn?

[Graham Johnston]

I think we saw an issue like this a few weeks back in Chicago.  It took them 
longer than I would have expected to fix it, later they ultimately ended up 
upgrading software I think.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com
think green; don't print this email.

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Baker, Byrn
Sent: Friday, November 27, 2015 8:32 AM
To: nanog@nanog.org
Subject: RE: Anyone having issues with Equinix IX out of Ashburn?


All of our IX peers dropped around 11 UTC. All recovered about 30 mins later.


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Jeroen Wunnink
Sent: Friday, November 27, 2015 8:13 AM
To: nanog@nanog.org
Subject: Re: Anyone having issues with Equinix IX out of Ashburn?

We've seen issues as well. We've just started to turn the exchange up again and 
check if it's fixed.


On 27/11/15 15:03, Nick Ellermann wrote:
> At about 4:15 am eastern we lost our bgp peers on the Ashburn IX at Equinix. 
> Equinix is not responding to our support requests, either they are overloaded 
> with support requests or all on holiday. Curious if others know if there are 
> known issues at this site or is it just us.
>
>
> Sincerely,
> Nick Ellermann - CTO & VP Cloud Services BroadAspect
>
> E: nellerm...@broadaspect.com<mailto:nellerm...@broadaspect.com>
> P: 703-297-4639
> F: 703-996-4443
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
> MATERIAL and is thus for use only by the intended recipient. If you received 
> this in error, please contact the sender and delete the e-mail and its 
> attachments from all computers.
>


--

Jeroen Wunnink
IP Engineering Manager - Hibernia Networks Main numbers (Ext: 1011): USA 
+1.908.516.4200 | UK +44.1704.322.300 Netherlands +31.208.200.622 | 24/7 IP NOC 
Phone: +31.20.82.00.623 jeroen.wunn...@hibernianetworks.com
www.hibernianetworks.com

This e-mail and any attachments thereto is intended only for use by the 
addressee(s) named herein and may be proprietary and/or legally privileged. If 
you are not the intended recipient of this e-mail, you are hereby notified that 
any dissemination, distribution or copying of this email, and any attachments 
thereto, without the prior written permission of the sender is strictly 
prohibited. If you receive this e-mail in error, please immediately telephone 
or e-mail the sender and permanently delete the original copy and any copy of 
this e-mail, and any printout thereof. All documents, contracts or agreements 
referred or attached to this e-mail are SUBJECT TO CONTRACT. The contents of an 
attachment to this e-mail may contain software viruses that could damage your 
own computer system. While Hibernia Networks has taken every reasonable 
precaution to minimize this risk, we cannot accept liability for any damage 
that you sustain as a result of software viruses. You should carry out your own 
virus checks before opening any attachment.

SMS Gateway

[Graham Johnston]

Today we use a product from MultiTech Systems call MultiModem iSMS to send SMS 
text messages from our monitoring system to our on call staff.  This is a 2G 
product and we need to replace it soon. I know there are more generic cellular 
modems that can do texting if you are willing to put in the effort, the product 
we use currently though has a simple HTTP based API specifically to send SMS. 
Is anybody out there using something similar that can work on 3G or 4G networks?

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com<mailto:johnst...@westmancom.com>
P think green; don't print this email.

FIB Sizing

[Graham Johnston]

Does anybody have a working projection, or crystal ball, that can provide a 
recommendation on FIB size requirements for the next 24 months?  Are we 
expecting the IPv4 table to continue to grow at somewhere around 50k routes a 
year? I came up with this from eyeballing the graph at 
http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active.txtdescr=Active%20BGP%20entries%20%28FIB%29ylabel=Active%20BGP%20entries%20%28FIB%29with=step.

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.commailto:johnst...@westmancom.com
P think green; don't print this email.

RE: SAS Drive Enclosure

[Graham Johnston]

I am primarily wanting something that will act like a DELL MD1200, SAS 
connected to a server, then run a clustered filesystem on the server(s) which 
will serve up NFS or iSCSI to client devices.

Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.com
think green; don't print this email.

-Original Message-
From: Jameson, Daniel [mailto:daniel.jame...@tdstelecom.com] 
Sent: Tuesday, May 26, 2015 3:11 PM
To: Ray Van Dolson; Graham Johnston
Cc: 'nanog@nanog.org'
Subject: RE: SAS Drive Enclosure

What are you thinking for connectivity,  Ethernet,  FiberChannel, Infiniband 
...  Building *Storage Nodes* or in need of just drive connectivity?


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Van Dolson
Sent: Tuesday, May 26, 2015 2:53 PM
To: Graham Johnston
Cc: 'nanog@nanog.org'
Subject: Re: SAS Drive Enclosure

On Tue, May 26, 2015 at 07:19:59PM +, Graham Johnston wrote:
 I am looking for information about SAS drive enclosures, is there a 
 list like NANOG that covers that area of IT?
 
 I am specifically looking for an enclosure that can handle 12 or more 
 drives, I am looking to create a clustered file system between 
 multiple servers and would like to avoid a drive enclosure that only 
 works with a very small number of approved drives.  I am looking to 
 support traditional HDDs as well as SSDs.

There were discussions at some point about setting up a storage-centric list 
via SNIA or something else fairly 'neutral'.  Never really materialized, 
however.

Lists like lopsa-tech and the LISA/USENIX SAGE list are general enough you 
might get some good responses.

WRT your question, we've had good luck with the Dell MD1200 line of JBODs.

Ray

SAS Drive Enclosure

[Graham Johnston]

I am looking for information about SAS drive enclosures, is there a list like 
NANOG that covers that area of IT?

I am specifically looking for an enclosure that can handle 12 or more drives, I 
am looking to create a clustered file system between multiple servers and would 
like to avoid a drive enclosure that only works with a very small number of 
approved drives.  I am looking to support traditional HDDs as well as SSDs.

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.commailto:johnst...@westmancom.com
P think green; don't print this email.

Multiple Spanning Tree Instance 0

[Graham Johnston]

We are planning a migration from Rapid PVST+ to Multiple Spanning Tree to 
better support a mixed vendor environment.  My question today is about MST 
Instance 0.  In practice do you map any VLANs there other than VLAN 1?

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.commailto:johnst...@westmancom.com
P think green; don't print this email.

Brocade MLX Feedback

[Graham Johnston]

We are looking at Brocade MLX routers to act as Internet edge routers.  They 
will initially handle two to four full tables, plus peering on an IX.  The 
price is certainly attractive.  We are coming from Cisco 7600 series devices.  
Can anyone comment about their use of them?  Are you happy with them?  Any 
gotchas?  Particularly we are interested in convergence time to full FIB 
population.

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.commailto:johnst...@westmancom.com
P think green; don't print this email.

Juniper MX Sizing

[Graham Johnston]

I am wondering if anyone can provide their real world experience about sizing 
Juniper MX routers as it relates to BGP.  I am needing a device that has a mix 
of layer 2 and 3 features, including MPLS, that will have a very low port count 
requirement that will primarily be used at a remote POP site to connect to the 
local IX as well as one or two full route transit providers.  The MX104 has 
what I need from a physical standpoint and a data plane standpoint, as well as 
power consumption figures.  My only concern is whether the REs have enough 
horsepower to churn through the convergence calculations at a rate that 
operators in this situation would find acceptable.  I realize that 'acceptable' 
is a moving target so I would happily accept feedback from people using them as 
to how long it takes and their happiness with the product.

For those of you that deem the MX104 unacceptable in this kind of role and 
moved up to the MX240, what RE did you elect to use?

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.commailto:johnst...@westmancom.com
P think green; don't print this email.

RE: Juniper MX Sizing

[Graham Johnston]

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
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:

 I am wondering if anyone can provide their real world experience about sizing 
 Juniper MX routers as it relates to BGP.  I am needing a device that has a 
 mix of layer 2 and 3 features, including MPLS, that will have a very low port 
 count requirement that will primarily be used at a remote POP site to connect 
 to the local IX as well as one or two full route transit providers.  The 
 MX104 has what I need from a physical standpoint and a data plane standpoint, 
 as well as power consumption figures.  My only concern is whether the REs 
 have enough horsepower to churn through the convergence calculations at a 
 rate that operators in this situation would find acceptable.  I realize that 
 'acceptable' is a moving target so I would happily accept feedback from 
 people using them as to how long it takes and their happiness with the 
 product.
 
 For those of you that deem the MX104 unacceptable in this kind of role and 
 moved up to the MX240, what RE did you elect to use?
 
 Thanks,
 Graham Johnston
 Network Planner
 Westman Communications Group
 204.717.2829
 johnst...@westmancom.commailto:johnst...@westmancom.com
 P think green; don't print this email.
 

Chicago Colo and IX

[Graham Johnston]

We are looking to expand our network and establish a POP in Chicago; it is 
expect that we will focus on 350 East Cermak.  Can anyone provide 
recommendations on Colo providers?  We will only really need enough space to 
deploy a modest router and the power it requires.  As we won't be able to do 
work on site, given its remote location to us, a colo provider who provides a 
remote hands service is a requirement.

I'm also curious if anyone can comment on the Equinix IX that is there.  Our 
only experience today with an IX is with TorIX, which has been extremely 
positive, and I'm not sure what significant differences I should expect if any.

Thanks,
Graham Johnston
Network Planner
Westman Communications Group
204.717.2829
johnst...@westmancom.commailto:johnst...@westmancom.com
P think green; don't print this email.