Mikael Abrahamsson wrote:
> This is a feature of IS-IS. You're less likely to get random crap in
> your IGP.
>
> :P
that alone makes a great argument for connecting to this sort of device
using bgp. Some vendors approach ospf with a hilarity-first attitude,
and at least bgp has the knobs to trea
Randy Bush wrote:
> the users' dilemma: do you buy a mac today, or wait six month hoping
> they will fix X (for your particular X)?
Apparently, they're bringing out an upgraded upgrade soon:
> https://blog.pinboard.in/2016/10/benjamin_button_reviews_the_new_macbook_pro/
I'm going to wait for thi
Selphie Keller wrote:
> APNIC -> 103.11.64.0/22 -> then to WebNX 103.11.67.0/24, which would show
> the full chain and a proper abuse contact for this subnet.
the tl;dr on the thread scrollback was:
1. whois is irredeemably broken
2. use rdap, which supports referrals
3. open source RDAP client:
Ronald F. Guilmette wrote:
> So the overall game plan is to continue to have these things all give
> out inaccurate and/or misleanding answers until such time as all of
> the trusting old school hacks like me either die out or get the memo
> telling us to just stop using this stuff?
no, it's to mo
Ronald F. Guilmette wrote:
> Oh, gz! ...
>
> Showing 1 to 10 of 1,823 entries
Yeah, get over it. Number resource transfers are a thing, and this
number is only going to increase.
> You are correct. In this case, it would have been helpful if APNIC's WHOIS
> server returned somethi
Ronald F. Guilmette wrote:
> I wasn't talking about irrdb. I was just talking about the WHOIS records
> for IPv4 allocations within the AFRINIC region.
afrinic, ripe ncc and apnic run a combined (+ partially authenticated)
irrdb and whois server.
> But my overall point remains. If there were ev
Ronald F. Guilmette wrote:
> In my actual comment I merely noted that RIRs are in fact -not- the
> Internet Police, and that none of them have ever displayed even the
> slightest desire to become that (and indeed, when asked, they have,
> without exception, exhibited a clear desire -not- to be assi
Ronald F. Guilmette wrote:
> I always start with whatver whois.iana.org has to
> say. And it says that that 103.0.0.0/8 belongs to APNIC, so of course,
> I only looked at what whois.apnic.net had to say about 103.11.67.105.
yeah, this prefix was transferred from APNIC to ARIN. You can search
fo
Mark Andrews wrote:
> It's not the RIR's job. They already provide the framework for
> ISP's to do the job of policing route announcements themselves.
> ISP's just need to use that framework.
Ron thinks otherwise. I'd like to understand what he thinks they can do
to stop this.
Nick
Ca By wrote:
> If the space is unassigned, could the rir announce the space to park it
> to null0. And register it in spamhaus ?
>
> This would make the rir the custodian of the space in their possession
The space isn't unallocated. It's allocated, but the assignee hasn't
announced it in the df
Ronald F. Guilmette wrote:
> Will never happen. The RiRs have been crystal clear, and also utterly
> consistant... "Not our job man! We am not the Internetz Police."
Ron,
Maybe you could suggest some ideas about how the RIRs can stop someone
from illegally squatting space?
Nick
Patrick W. Gilmore wrote:
> Our biggest problem is people thinking they cannot or do not want to
> help.
Our biggest problem is that if the Internet community does not handle
problems like this, governments and regulators may decide to intervene.
If they do this in the wrong way, it will turn one
Mark Tinka wrote:
> Not sure what gear you're using now, but you'll get full routing and
> MPLS features on the platforms such as the Cisco ASR920. I'd have
> recommended the Cisco ME3600X, but they just announced EoS/EoL last
> night, which means that while you can still order it until October 201
Mike Hammett wrote:
> Is that common in CMTSes or just in certain ones?
it's a mandatory part of the docsis3 specification.
Nick
Baldur Norddahl wrote:
> The sad thing is that if we boot out grandma they will just switch to one
> of our competors and the TV will still be a bot. You can't win.
Good thing the smart TV / other IoT manufacturers have taken the
responsible approach and have committed to providing lifetime softwa
Frank Bulk wrote:
> We recently purchased some generic optics from a reputable reseller that
> were marketed to reach 60 km.
transceivers don't work like that. They are sold with a specific
optical budget, normally rated in dB at a specific wavelength. The km
equivalent is usually based on G.652
Mikael Abrahamsson wrote:
> Any pointers to how to turn this of on Intel NICs and HP switches?
Yes: don't buy Intel NICs or HP switches.
Problem solved.
Nick
Tim Jackson wrote:
> "As I'm sure you know, Arista is not the only manufacturer that has made
> this choice. Unlike our competition, we work to make our optics pricing
> competitive, but we'll never be as low as the "Taiwan specials" that you
> see floating around. I have another customer that was
Leo Bicknell wrote:
> Cross connects are our industry's $100 gold plated HDMI cables.
In the US maybe. Cross-connect prices are much more reasonable in
Europe (€0 - €50/month).
Personally, I don't have a problem with MRCs when ordering
cross-connects: data centres are expensive to build and run.
Dave Temkin wrote:
> They are representative of the most important IXPs to deliver traffic
> from in Western Europe.
I don't doubt that they are important IXPs for delivering traffic.
However, no other IXP in europe (both eastern and western) is doing
expansion outside the countries that they ope
Hi Dave,
Dave Temkin wrote:
> General, with the four being used as varying examples.
Then there is a problem - you only presented info relating to those four
organisations, not for any other IXP, at least outside a small number of
sponsor-supported IXPs in the US.
With respect to all parties inv
Dave Temkin wrote:
> I was pointing out facts about IXPs that many did not know, including the
> actual organizational structure.
Dave,
was this talk about IXPs in general, or the 4 IXPs you named in your talk?
Nick
Nick Hilliard wrote:
> David Sotnick wrote:
>> I'm seeing *consistent* 46.1% packet loss between Comcast Res/Bus services
>
> 5/12 = 41.6%
and 5/12 != 46.1%, so scratch that. Anyway, the mtr output shows the
likely position of where the problem is.
Nick
David Sotnick wrote:
> I'm seeing *consistent* 46.1% packet loss between Comcast Res/Bus services
> in Northern CA and Pixar (Level 3 customer) also in Northern CA. I have
> ticket open with Level (3) but the problem appears to be on Comcast's
> network.
5/12 = 41.6%
Someone's got a 12-way LAG /
amuse wrote:
> +1 to a "Can you substantiate that claim please?" sentiment here. I've
> used it for years and found it to be reliable, flexible, feature-filled.
> And having the BSD CLI fully available has been a godsend.
The code quality is terrible in a 1990s sort of way. I.e. no separation
of
William Herrin wrote:
> I respectfully disagree. Sourcing more ram won't fix the next bit of
> sloppiness with the software. Or the one after that. Once the manager
> of that team starts to accept poor code quality, the only thing with a
> chance of fixing it is strong customer push-back.
You coul
William Herrin wrote:
> IMO, you should not accept that answer from the TAC. An IOS release
> that crashes with two 600k BGP feeds in 4 gigs of RAM is badly
> defective.
I suspect the time the OP would spend raging down the phone would be
better spent sourcing a third party memory upgrade to 8G or
Fredrik Korsbäck wrote:
> As I've told you when you hunted me down the last time through backside
> channels..
I can only hope you meant "back channels".
Nick
Baldur Norddahl wrote:
> With two uplinks that is highly unlikely to the point of being impossible.
> There is no topology change upstream that can cause a situation where it is
> not possible to do a high degree of aggregation of the full default free
> routing table before loading it in the FIB.
Laszlo Hanyecz wrote:
> I'm curious about specific failure modes that can result from this, if
> anyone can share examples/experience with it.
The canonical pathological case is where the deaggregated prefixes are
affected by upstream topology changes and suddenly your optimisations
which saved yo
Alain Hebert wrote:
> PS: "Superfluous" is a nice way to say that the best path of a
> subnet is the same as his supernet.
... from the point of view of the paths that you see, which is to say
two egress paths. Someone else on the internet may have a different set
of bgp views which will giv
Jean-Francois Mezei wrote:
> Canadian cable carriers seem to have all told the CRTC they can only
> carry 42mhz in the upstream because their amplifiers and nodes only
> amplify that narrow band in the upstream direction.
>
> Is/was 42mhz common across north america ?
42MHz was the traditional up
Josh Reynolds wrote:
> http://packetpushers.net/overpriced-optics-by-oems/
the cost bases mentioned in this article are a bit odd:
> So how much does a 10GB SFP+ SR optic cost? It turns out around $85 +
> some margin, bringing the cost to $95.
You can pick up a 10GB SFP+ SR for $15 in units of o
Christopher Morrow wrote:
> because at least:
> o safe handling of media is important (did the janitor just walk off
> with backup tapes/ disks/etc?)
> o 'a machine under your desk' is not a production operation.
> (if you think it is, please stop, think again and move that
> service
Mikael Abrahamsson wrote:
> However, I stand by my earlier statement that we need to include MTU/MRU
> in ND messages, so that this can be negotiated on a LAN where not all
> devices support large MTU.
this would introduce a degree of network complexity that is unnecessary
and would be prone to pr
Saku Ytti wrote:
> Member may puke L2 loop to IXP, you must have some channel to deal
> with your customers.
First, mac filters. Second, if someone l2 loops and it causes problems
because of hardware failure on our side, we reserve the right to pull
connectivity:
https://www.inex.ie/technical/ma
Saku Ytti wrote:
> I would go for 1500B edge, and 9100B core, but that's just me.
Other people would be fine with 1522 core because that suits both their
needs and equipment limitations. So what do you do? Go with 9100
because it suits you, or 9000 because that's what lots of other people
use?
Saku Ytti wrote:
> It works and has worked 2 decades in real IXP.
If you're referring to Netnod, this started out as a fddi platform with
a native max frame size of 4470. Maintaining something which already
exists is not nearly as difficult as starting something from scratch and
trying to reach a
Mikael Abrahamsson wrote:
> On all platforms I've configured and connected to an IXP, they would all
> be configured by setting max L2 MTU on the main interface, and then you
> configure whatever needed IPv4 and IPv6 L3 MTU on the subinterface.
iirc, we had problems with a bunch of ios based platf
Saku Ytti wrote:
> If customer does not react, put it on quarantine VLAN. This can be
> automated too. Wrong MTU => open internal case, contact customers
> email, no customer response in N days, quarantine VLAN.
... and then the customer will leave the service down because it the
primary peering l
On 9 Mar 2016, at 18:29, Saku Ytti wrote:
> It's not a novel idea, IXPs already do active polling, even ARP
> sponges. In a competitive market, hopefully customers will choose the
> IXP operator who knows how to ensure minimal pain for the customers.
There is a critical difference between these t
Saku Ytti wrote:
> I'm suggesting IXP has active poller which detects customer MTU misconfigs.
any ixp configuration which requires active polling to ensure correct
configuration is doomed to failure. You are completely overestimating
human nature if you believe that the IXP operator can make thi
Mikael Abrahamsson wrote:
> I have many times ping:ed with 1 byte packets on a device that has
> "ip mtu 9000" configured on it, so it sends out two fragments, one being
> 9000, the other one around 1100 bytes, only to get back a stream of
> fragments, none of them larger than 1500 bytes.
here
Saku Ytti wrote:
> Poller in the IXP has too large MTU, it tries to send ping packets
> with max_size+1, if they work, customer has too large MTU. Also it
> tries to send max_size, if it does not work, customer has too small
> MTU. As icing on top, it tries to send max_size+1 but fragments it to
>
Kurt Kraut wrote:
> Thank you for replying so quickly. I don't see why the consensus for an
> MTU must be reached. IPv6 Path MTU Discovery would handle it by itself,
> wouldn't it? If one participant supports 9k and another 4k, the traffic
> between them would be at 4k with no manual intervention.
Kurt Kraut via NANOG wrote:
> I'm trying to convince my local Internet Exchange location (and it is not
> small, exceed 1 terabit per second on a daily basis) to adopt jumbo frames.
this has been tried before at many ixps. No matter how good an idea it
sounds like, most organisations are welded h
Peter Phaal wrote:
> sampled packet. A simple filter along the lines:
>
> if ( sourceId.split(':')[1] != inputPort) return;
It's not a one-liner in practice. It involves maintaining an array of
source ip + egressPorts with sflow enabled and (depending on how you
implement it) e.g. ensuring that
Peter Phaal wrote:
> I think "pathologically broken" somewhat overstates the case.
> Bidirectional sampling is allowed by the sFlow spec and other vendors
> have made that choice. Another vendor used to implement egress only
> sampling (also allowed) but unusual. I agree that ingress is the most
>
Peter Phaal wrote:
> Monitoring ingress and egress in the switch is wasteful of resources.
It's more than a waste of resources: it's pathologically broken and
Cisco decline to fix it, despite the fact that enabling ingress-only or
egress-only is fully supported via API in the Broadcom SDKs, and
c
Peter Phaal wrote:
> The Nexus 3200 should work well with 100G flows - I believe it's
> based on the latest Broadcom Tomahawk ASIC. The older Trident II
> ASICs in the Nexus 9k are 40g parts
does nx-os still force ingress-and-egress sflow? sflow is pretty
useless you can define an accounting peri
Pavel Odintsov wrote:
> From hardware point of view almost all brand new switches support
> sflow free of charge (no additional licenses or modules). But be
> aware, Cisco do not support this protocol at all (that's pretty weird,
> really).
sflow is supported on the Nexus 3k range, but it's availa
Roland Dobbins wrote:
> Inconsistent stats, lack of ifindex information.
I've not yet come across an sflow implementation which didn't fill out
the ifindex field. No doubt they exist.
Not sure what you mean by "inconsistent stats".
Nick
Saku Ytti wrote:
> I cannot see why not, it's cheap. You're doing 1-2 LPM on the packet,
> QoS lookup, ACL lookup, incrementing various counters, etc., adding
> one hash lookup and two counters is not going to be relevant cost to
> the lookup time.
depends on what you define by "cheap". Netflow r
Todd Crane wrote:
> This maybe outside the scope of this list but I was wondering if
> anybody had advice or lessons learned on the whole sFlow vs netFlow
> debate. We are looking at using it for billing and influencing our
> sdn flows. It seems like everything I have found is biased (articles
> by
Mikael Abrahamsson wrote:
> Why isn't UDP/53 blocked towards customers? I know historically there
> were resolvers that used UDP/53 as source port for queries, but is this
> the case nowadays?
>
> I know providers that have blocked UDP/53 towards customers as a
> countermeasure to the amplificatio
courtneysm...@comcast.net wrote:
> Can anyone point me to examples of using rtconfig to generate IOS-XR
> configs? Specifically prefix and as-path sets. My Google skills are
> coming up short. The man page for rtconfig does not mention IOS-XR
> but it is supposedly supported. I get no farther than
Jason Bothe wrote:
> The 9k does however get a huge win with the ability to apply a ‘pie’
> or software patch while staying in service vs requiring a reload.
SMUs are often "hitless", which is to say, "hitless" with scary quotes.
What this means in practice is that the SMU itself might be hitless
Todd Underwood wrote:
> Can you scope "issue" with any facts or data?
are facts or data strictly necessary on the nanog mailing list?
Nick
> T
> On Feb 17, 2016 11:16, "Fred Hollis" wrote:
>
>> Anyone else aware of it?
>>
David Bass wrote:
> Looking to see what others are using out there as an alternative to a
> Cisco ME3600X? Also, what other vendors out there are playing in this
> space?
>
> Need a full MPLS stack.
Before choosing a box, you need to figure out:
- how many ports you need, and of what speed
- how
David Bass wrote:
> Looking to see what others are using out there as an alternative to a
> Cisco ME3600X? Also, what other vendors out there are playing in this
> space?
>
> Need a full MPLS stack.
Features, speed, price: choose 2.
Wait, you said MPLS: choose 1.5.
Nick
Scott Helms wrote:
> That very small upside for an extreme downside.Trying to hire someone
> to work on your system with Euro channelization, not to mention buying
> amplifiers and passives is a huge PITA.
... if your plant is in the US.
> I have customers in Europe who
> decided to do US DOCSIS
Scott Helms wrote:
> My 2 cents, buy CMTS/CCAP gear that's upgradeable to D3.1, ie CBR8, E6000,
> or the big Casa unit, for the time being shoot for 24 channel downstream
> bonding groups (24 * ~37mbps - overhead) which yields about 740 mbps
> usable.
the good thing about eurodocsis is that it giv
Jared Mauch wrote:
> I can create a catv or similar list easily. good name
> suggestions welcome.
"There are only two hard things in Computer Science: cache invalidation
and naming things".
docsis-nsp?
Nick
Brandon Butterworth wrote:
> It is but nobody worries about that, we trust route servers at IX
> carrying way more traffic than most of these access circuits.
more sessions for sure, but rarely more traffic.
The issue at hand is that multihop bgp at the isp edge is relatively
straightforward to f
Joe Maimon wrote:
> Maybe not for some people, but I have a hard time understanding why one
> extra ebgp session is such a novel concept for all you networking folk.
multihop bgp means that you don't have synchronised ethernet carrier
status between the provider and customer routers. This in turn
Brian Rak wrote:
> whois.radb.net seems to have been down since sometime last night, has
> anyone else seen problems with this?
since at least 2016-01-21, 20:30 UTC. It would be great if someone from
RADB could give an update on what's happening because this downtime is
causing operational proble
Chris Burwell wrote:
> I've had enough trouble with broadcast storms and other issues in N.A.
And you still want vpls? Wow.
If you're talking a requirement for connecting geographically separated
locations, there are sound technical reasons for avoiding vpls like the
plague. Unless there are ov
Daniel Corbe wrote:
> Let’s just cut off the entirety of the third world instead of having
> a tangible mitigation plan in place.
You mean, cut off Sweden, Ireland, Finland, Switzerland and Israel?
> https://en.wikipedia.org/wiki/Third_World
What an enormously silly idea.
Seasons greetings to a
James R Cutler wrote:
> All that is necessary is for us to end the years of religious debate
> of DHCP vs RA and to start providing solutions that meet business
> management needs.
Heresy! Burn him!
Nick
Sander Steffann wrote:
> So yes, people have to deploy IPv6 as soon as possible, but it's not
> the job of the IETF to fix all of the obstacles.
What we need is for the IETF to stop being an obstacle.
More to the point, as the IETF's opinion is based on the consensus of
its working groups, it wou
On 17/12/2015 17:36, Ahmed Munaf wrote:
> we are using ESP 20
You haven't said what you mean by "better". This could mean "faster" or
"copes with more sessions" or "cheaper". If your ISP is large, then it
might be "cost per user is lower" or "able to cope with the number of users".
Nick
On 03/12/2015 08:15, halp us wrote:
> a very well known group that has been in the news lately. Recently they've
> threatened to carry out a major DDoS attack if they are not paid by a
> deadline which is approaching. They've performed an attack of a smaller
> magnitude to prove that they're seriou
On 13/11/2015 22:10, Marco Davids wrote:
> On 13/11/15 23:01, Stephane Bortzmeyer wrote:
>> On Fri, Nov 13, 2015 at 09:54:28AM +,
>> a.l.m.bu...@lboro.ac.uk wrote
>>
>>> well, in EU I dont think that would ever fly.
>>
>> It is done in France, for a long time
>
> And it is common practice i
On 27/10/2015 08:31, marcel.durega...@yahoo.fr wrote:
> I'm asking because we see more and more peering partners which force the
> hold timer to a lower value, and when BGP negotiate the timer, the lowest
> hold timer is the winner.
You need to be careful with this. On larger IXPs, there will be
Hey!
New message, please read <http://hurricanedisasterphotos.com/several.php?0>
Nick Hilliard
Hey!
New message, please read <http://google-adwords.com.co/account.php?ny>
Nick Hilliard
---
El software de antivirus Avast ha analizado este correo electrónico en busca de
virus.
https://www.avast.com/antivirus
On 04/10/2015 16:03, Randy Bush wrote:
> yet another ipv6 fantasy. it may be in the powerpoint but it is not in
> the implementations.
the ipsec tickbox was removed from ipv6 in rfc6434 (2011).
Nick
On 29/09/2015 16:19, Jay Ashworth wrote:
> The idea of a private tieline network that is connected, by SIP, to a line
> appearance in the NOC of each AS, and no one else is on it, seems like a
> fine idea to me.
it's a great idea: I had my inoc-dba phone connected and live for 15 years.
I used i
On 23/09/2015 10:34, Nick Hilliard wrote:
> What are people using for ear protection for datacenters these days?
Summarising, people seem to use a wide variety of kit:
Ear muffs:
- 3M Peltor Shotgunner Hearing Protector
- 3M Peltor Optime
Acoustic headsets:
- 3M Pel
On 23/09/2015 21:37, Mike Hammett wrote:
> Do any of you have any useful input other than they need to upgrade
> their IOS to something newer than 4.5 years old?
12.4.(15)T is known to be affected by a variety of security problems, for
which cisco TAC will provide free upgrades - assuming they are
What are people using for ear protection for datacenters these days? I'm
down to my last couple of corded 3M 1110:
http://www.shop3m.com/3m-corded-earplugs-hearing-conservation-1110.html
These work reasonably well in practice, with a rated nominal noise
reduction rate of 29dB. Some people find
On 07/09/2015 21:23, James Downs wrote:
> What do you mean when you say “software defined networking”? Do you have
> a particular problem or use case you are approaching?
since when was that a requirement for SDN?
Nick
On 03/09/2015 11:56, Saku Ytti wrote:
> 40GE server will flood the window as fast as it can, instead of
> limiting itself to 10Gbps, optimally it'll send at linerate.
optimally, but tcp slow start will generally stop this from happening on
well behaved sending-side stacks so you send up ramping up
On 01/09/2015 21:13, valdis.kletni...@vt.edu wrote:
> On Tue, 01 Sep 2015 22:47:09 +0300, Tarko Tikan said:
>> Bad advice. No amount of money will fix major platforms that are not
>> happy to export flow telemetry via router management ports.
>
> And that box ended up in your rack, why exactly?
>
On 18/08/2015 22:10, William Herrin wrote:
> This technique described isn't URPF, it's simple destination routing.
> The routes I offer you via BGP are the only routes in my table, hence
> the only routes I'm capable of routing. If you send me a packet for a
> _destination_ I didn't offer to you, I
On 18/08/2015 21:56, Gert Doering wrote:
> So how's that stopping one of your bilateral peers from sending you
> traffic destined elsewhere?
it doesn't: you detect it and depeer them. If they force the situation
with static routes, the traffic will be dropped.
Nick
On 18/08/2015 20:22, Tim Durack wrote:
> This has always been my understanding - thanks for confirming. I'm weighing
> cost-benefit, and looking to see if there are any other smart ideas. As
> usual, it looks like simplest is best.
i'd advise being careful with this approach: urpf at ixps is a nig
On 02/08/2015 23:30, Randy Bush wrote:
> otoh, i did not believe in the fad of using 65xxs at the bgp global
> edge. while it was temporarily cheap, two years later not a lot of folk
> had that many boats which needed anchoring.
A juniper EX9200 is a switch and a cisco sup2t box is a router. The
On 02/08/2015 22:59, Randy Bush wrote:
> so it is heavily routed using L3 on the core 'switches'? makes a lot of
> sense.
Lots of switches will happily forward layer 3 packets.
Nick
On 01/08/2015 03:27, Keith Medcalf wrote:
> It just means that you cannot use the crappy apps or the crappy app store.
which is fine until Microsoft ties in future software upgrades to the app
store and you find that you can't upgrade without tying yourself into a
Microsoft account.
E.g. just lik
On 09/07/2015 22:35, Ricky Beam wrote:
> "Free" if you have a support contract.
No, free-as-in-beer.
You register a guest CCO account, email t...@cisco.com, provide the device
serial number (or output of "show hardware") and the bugid + Cisco PSIRT
URL reference. Cisco TAC will then provide you w
On 01/07/2015 17:03, Joe Abley wrote:
> The idea of configuring this stuff from the IRR is great in terms of
> distributing the ops cycles in the right places, but it doesn't help with
> verifying that the end result isn't insane, as I think you and Mike have
> described on this list over the past
On 01/07/2015 16:02, Mark Tinka wrote:
> Honestly, I'm ambivalent about using the IRR data for prefix-list
> generation (even without RPSL), also because of how much junk there is
> in there, and also how redundant some of it really is, e.g., someone
> creating a /32 (IPv4) route object and yet we
On 01/07/2015 15:57, Mark Tinka wrote:
> Remember some high-end Cisco routers only have 2MB of NVRAM. This could
> get tested with a large prefix-list configuration. Junos may not have
> much of a space issue since the configuration is stored on the compact
> flash or HDD.
Not at all. Even C6500
On 01/07/2015 15:51, Mark Tinka wrote:
> I found RPSL complicated a few years ago, and sort of put that on the
> back-burner.
you probably want to ignore more rpsl constructs and depend solely on
as-sets, aut-nums and route/route6 objects. RPSL is not going to live up
to your expectations.
Nick
On 01/07/2015 15:12, Jared Mauch wrote:
> I would like to see others participate in the dialog with vendors
> so we don't seem to be quite an outlier with "wow, you have really
> large configs". The vendors haven't quite kept pace with the increase
> in density proportional to the number of
On 30/06/2015 14:29, Mark Tinka wrote:
> - Get your downstreams to create route objects before you turn them up.
> - Get your provisioning teams to validate the prefixes being
> provided by your downstreams.
> - Use both prefix- and AS_PATH-based filters for your downstreams.
> - Us
On 24/06/2015 04:33, Harlan Stenn wrote:
> A clock crystal has to be REALLY bad for ntpd to need to step the clock.
or really virtual.
Nick
On 23/06/2015 18:23, shawn wilson wrote:
> NTP causes jumps - not skews, right?
this is implementation dependent. For normal clock differences on ntpd,
if you start it with the -x parameter, it will always slew and never step.
If you start ntpd without the -x parameter, if the calculated correct
On 23/06/2015 10:25, Mel Beckman wrote:
> Why should your head explode? Possibly you’re overthinking the problem.
The problems don't relate to Harlan overthinking the problem. They relate
to developers underthinking the problem and assuming that all clocks are
monotonic and that certain rules app
201 - 300 of 801 matches
Mail list logo
