Re: Arista Layer3

Hey Dmitry, > What do you think about Arista 7280SR (DCS-7280SR-48C6-M-R) as a BGP peering > router with 3 x upstream with full route view in RIB (ipv4 + ipv6) and > another IXP feed? > Considering switching from ASR9001 which is doing perfect work but has no > more ports left. > The price is

Re: WIndows Updates Fail Via IPv6 - Update!

On Tue, Mar 5, 2019 at 4:54 PM wrote: > Let me play a devil's advocate here, the above statement begs a question > then, how do you know all that is harmful would you test for every possible > extension and hw/sw permutation? > So there would be 3 sets (though lines might be blurred) known

Re: WIndows Updates Fail Via IPv6 - Update!

Hey Rich, > I've pointed folks at this for years: > ICMP Packet Filtering v1.2 > http://www.cymru.com/Documents/icmp-messages.html To me this seems anti-pattern. It seems it was written on basis of 'what we know we allow, what we don't know we deny'. With assumption that ICMP

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

On Tue, Mar 5, 2019 at 12:09 PM Joel Jaeggli wrote: > Parsing the icmp payload was something we considered in rfc7690 but wasn’t > one the approaches we pursued (we broadcasted the ptb to all hosts on the > segment(s) behind the load balancers in our original implementation). > > It actually

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

On Tue, Mar 5, 2019 at 12:26 AM Mark Andrews wrote: > Then Cloudflare should negotiate MSS’s that don’t generate PTB’s if > they have installed broken ECMP devices. The simplest way to do that Out of curiosity does that imply you are aware of non-broken ECMP devices, which are able to hash on

Re: a quick survey about LLDP and similar

Hey Thomas, > switches connected to end-user/customer gear: never ever. > switch to server interfaces: only to servers of teams you can trust. > temporarily enable to untrusted teams if you'd need to order remote > hands to lookup the exact cabling in case of problems. What are the problems in

Re: ICMPv6 "too-big" packets ignored (filtered ?) by Cloudflare farms

Hey Jean, > I confess using IPv6 behind a 6in4 tunnel because the "Business-Class" > service > of the concerned operator doesn't handle IPv6 yet. > > as such, I realised that, as far as I can figure, ICMPv6 packet "too-big" > (rfc 4443) > seem to be ignored or filtered at ~60%

Re: WIndows Updates Fail Via IPv6 - Update!

On Mon, Mar 4, 2019 at 10:02 AM Mark Tinka wrote: > > Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do > > have a very specific and motivated reason to block some types. > > I would even go as far as "allow all icmp from any to any" (and if possible > > as the first

Re: A Deep Dive on the Recent Widespread DNS Hijacking

On Tue, Feb 26, 2019 at 4:05 AM wrote: > So what registries/registrars are supporting 2FA that's better than SMS? > Or since 98% of domain names are Bait type, is nobody bothering > to support something for the 2% that could use it? Gandi does TOTP and CIDR filtering, that is, you can give them

Re: MX204 applications, (was about BGP RR design)

On Fri, Feb 15, 2019 at 10:54 AM Phil Lavin wrote: > > MX80/MX104 have both sides for revenue ports. > > They are, however, not Trio - rather just commodity CPUs. Routing > re-convergence times are shockingly high - in the region of 5-10 minutes for > MX80 with a full table vs 30 seconds

MX204 applications, (was about BGP RR design)

On Fri, Feb 15, 2019 at 9:55 AM Mark Tinka wrote: > > MX204 be good for that ? > > I'm sure it will be - it's an MPC7 in a cage :-). Anyone know why MX204 has so few ports? It seems like it only has WAN side used, leaving FAB side entirely unused, throwing away 50% of free capacity. MX80/MX104

Re: BGP topological vs centralized route reflector

Hey, in-band, out-of-band is bit of misnomers to me. You mean in-path or out-of-path. Main advantage of out-of-path is that you decouple FIB and RIB scaling requirements and feature requirements. Your backbone device does not need to be qualified for large RIB or BGP at all. And when you do

Re: Latency question - Juniper MX960 vs the Tellabs 8860

Hey Steve, 15us would be more than you'll realistically see in uncongested MX960, but it is in the ball-bark. I've not tried Tellabs, if customer is latency sensitive you probably want to look constant time pipeline devices rather than run to completion npus. You'll see low single digit us on

Re: BGP Experiment

Hey, > This is because you did your due diligence during the testing. > Do you have statistics on the probability of these "complex" bugs occurrence? No. I wish I had and I hope to make change on this. Try to translate how good investment test is, how many customer outages it has saved etc. I

Re: [ROUTING] Settle a pointless debate - more commonly used routing protocol in total deployments - OSPF vs IS-IS

Q: why do we have to start this debate every other day? A: because i don't have time to start it every day On Fri, 25 Jan 2019 at 16:18, Steven Bahnsen wrote: > > Hi, > > First time poster looking for some input on a debate and I apologise if I've > done this completely wrong, but I don't think

Re: BGP Experiment

On Thu, 24 Jan 2019 at 18:43, wrote: > We fight with that all the time, > I'd say that from the whole Design->Certify->Deploy->Verify->Monitor service > lifecycle time budget, the service certification testing is almost half of it. > That's why I'm so interested in a model driven design and

Re: BGP Experiment

On Thu, 24 Jan 2019 at 17:52, wrote: > This actually makes me thing that it might be worthwhile including these > types of test to the regression testing suite. I seem to recall one newish entrant to SP market explaining that they are limited by wall-time in blackbox testing. They would have no

Re: BGP Experiment

Hey, > firmware which only runs on certain expensive devices. My point is > that e.g. FRR is an open source software which is designed to run on > the same Intel-based systems as the one which probably powers your > laptop. Most vendors have virtual image for your laptop, all of the modern

Re: BGP Experiment

On Wed, 9 Jan 2019 at 20:45, Töma Gavrichenkov wrote: > Nope, this is a misunderstanding. One has to *check* for advisories at > least once or twice a week and only update (and reboot is necessary) > if there *is* a vulnerability. I think this contains some assumptions 1. discovering security

Re: BGP Experiment

On Wed, 9 Jan 2019 at 20:24, Töma Gavrichenkov wrote: > So, network device vendors releasing security advisories twice a year > isn't a big part of the explanation? Those are scheduled, they have to meet some criteria to be pushed on scheduled lot. There are also out of cycle SIRTs. And yes,

Re: BGP Experiment

On Wed, 9 Jan 2019 at 19:54, Töma Gavrichenkov wrote: > Which is, as usual, a pity, because, generally, synchronizing a piece of > software with upstream security updates less frequently than once to twice in > a week belongs in Jurassic Park today; and doing it hardly more frequently > than

Re: BGP Experiment

Hey, > After seeing this initial result I'm wondering why the researchers > couldn't set up their own sandbox first before breaking code on the > internet. I believe FRR is a free download and comes with GNU autoconf. We probably should avoid anything which might demotivate future good guys

Re: How to choose a transport(terrestrial/subsea)

On Wed, 2 Jan 2019 at 22:17, Tom Beecher wrote: > You can mitigate some of that by getting contract language in place that says > a carrier must maintain the circuit on the specified and agreed pathway, and > if it's later discovered that it has been moved, you don't pay for the > circuit

Re: Service Provider NetFlow Collectors

Hey, On Wed, 2 Jan 2019 at 14:40, H I Baysal wrote: > That absolutely depends on the amount of TAGs you use, and how you aggregate, > etc. > I am collecting DSTAS, SRCAS, en DST AS per IP. And influx is not even > sweating a single drop > > We have a 4 Tbps of traffic during peak, and as

Re: Service Provider NetFlow Collectors

Hey Tim, > I would advise against InfluxDB in this case - flow data has a very high (and > open) tag cardinality which is not suited to Influx (although their recently > new index format has improved this). I'm not entirely sure I understand. Does this mean the permutations of tags are high,

Re: CenturyLink

Hey Valdis, ´ > There's another number that's missing - the stability of the drift. Not the way I read it, I read +-1.1us verbatim, drifts is somewhere between 1.1 .. -1.1 in given 24h window. I assume if was constant + +-variable, the constant would already have been engineered out before

Re: CenturyLink

Hey Matthew, Thi > There isn't a specific regulation on free-running GPS, just "due diligence". > I work at a algorithmic program trading company (and have been for 20 years). > We have a high ROI, the cost differential for the rubidium OC versus having > to drop everything to conform to

Re: CenturyLink RCA?

Hey Steve, I will continue to speculate, as that's all we have. > 1. Are you telling me that several line cards failed in multiple cities in > the same way at the same time? Don't think so unless the same software fault > was propagated to all of them. If the problem was that they needed to

Re: CenturyLink

Hey Gary, On Mon, 31 Dec 2018 at 05:02, Gary E. Miller wrote: > The Rb frequency reference will be two or three orders of magnitude > more stable than an expensive ovenized crystal. Perhaps, but not supported by this: https://www.meinbergglobal.com/english/specs/gpsopt.htm For the tl;dr folk,

Re: CenturyLink

On Sun, 30 Dec 2018 at 20:04, Matthew Huff wrote: > Regulatory. > If we were to lose the GPS signal (antenna failure, etc...) then our stratum > 1 time sources wouldn't drift as much and as quickly. For telco and general > usage, the cost may not be worthwhile, but when you have auditors

Re: CenturyLink

Hey Matthew, > We use an older model of > https://www.microsemi.com/product-directory/enterprise-network-time-servers/4117-syncserver-s600 > with rubidium oscillator. Not cheap, but hardened and extremely accurate. Out of interest why rubidium? For short term stability oscillator choice isn't

Re: CenturyLink RCA?

uting Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > > From: "Saku Ytti" > To: "nanog list" > Sent: Sunday, December 30, 2018 7:42:49 AM > Subject: CenturyLink RCA? > > Apol

CenturyLink RCA?

Apologies for the URL, I do not know official source and I do not share the URLs sentiment. https://fuckingcenturylink.com/ Can someone translate this to IP engineer? What did actually happen? >From my own history, I rarely recognise the problem I fixed from reading the public RCA. I hope

Re: Stupid Question maybe?

On Thu, 20 Dec 2018 at 21:06, Grant Taylor via NANOG wrote: > Do you have /24 cover prefixes advertised to the Internet? Yes, just it drops at the peering edge as more specific is not found. > $EMPLOYER requires globally routable access to the link net IP on our > equipment for specific

Re: Stupid Question maybe?

On Thu, 20 Dec 2018 at 20:07, William Allen Simpson wrote: > Then there were the fine vendors that conflated the link and IP headers. > That fell apart when IEEE started assigning OUIs that began with 0x4xxx. There is no way to know in-transit what MPLS carries. Vendors have implemented

Re: Stupid Question maybe?

On Thu, 20 Dec 2018 at 18:22, Grant Taylor via NANOG wrote: > Are you advocating not advertising customer linknetworks within your own > organization? Correct. > I know of a use cases where linknetworks must be globally accessible. > At least the customer's linknetwork IP address. So, not

Re: Stupid Question maybe?

On Thu, 20 Dec 2018 at 10:32, Christian Meutes wrote: > And unfortunately is still not supported by IOS-XR for IPv6, which could mean > not having a scaleable way on your edge to protect your internal network. Aye. I'd recommend not advertise your linknetworks at all, and let customers either

Re: Stupid Question maybe?

On Wed, 19 Dec 2018 at 02:55, Philip Loenneker wrote: > I had a heck of a time a few years back trying to troubleshoot an issue where > an upstream provider had an ACL with an incorrect mask along the lines of > 255.252.255.0. That was really interesting to talk about once we discovered > it,

Re: Stupid Question maybe?

On Tue, 18 Dec 2018 at 21:52, Brian Kantor wrote: > of the address word was efficient, since subnet masks were always > a series of ones followd by zeros with no interspersing, which > was incorporated (or independently invented) about a decade later >From protocol POV there is no reason to

Re: rfd

I always wondered why does it have to be so binary. I don't want to decide for my customers if partial visibility is better than busy CPU, but I do appreciate stability. Why can't we have local-pref penalty for flapping route. If it's only option, keep offering it, if there are other, more stable

Re: Pinging a Device Every Second

On Sun, 16 Dec 2018 at 17:59, Stephen Satchell wrote: > A standard ping packet, with no IP options or additional payload, is 64 > bytes or 512 bits. If an application wants to make an accurate > round-trip-delay measurement, it can insert the output of a microsecond > clock, and compare that

Re: Pinging a Device Every Second

On Sun, 16 Dec 2018 at 00:48, Stephen Satchell wrote: > The 1500 bits are for each ping. So 1000 hosts would be 1,500,000 bits Why? Why did you choose 1500b(it) ping, instead of minimum size or 1500B(ytes) IP packets? Minimum: 672kbps 1500B: 12.16Mbps -- ++ytti

Re: Pinging a Device Every Second

On Sat, 15 Dec 2018 at 18:52, Stephen Satchell wrote: > Short answer: about 1500 bits of bandwidth, and the CPU loading on the I can't parse this. 1000 hosts at 1 pps would be 672kbps on ethernetII encapulation with minimum size frames. -- ++ytti

Re: Should ISP block child pornography?

On Fri, 7 Dec 2018 at 08:09, Lotia, Pratik M wrote: > Hello all, was curious to know the community’s opinion on whether an ISP > should block domains hosting CPE (child pornography exploitation) content? > Interpol has a ‘worst-of’ list which contains such domains and it wants ISPs > to block

Re: Cheap switch with a couple 100G

The argument should be 50G is cheaper than 40G. Because serdes is 25G typically, you get 25, 50, 100 without gearboxes and retimers, so less pincount, less thermal, higher density, lower cost. But BOM impact to pricing isn't high anyhow, unless we're talking about massive port counts. If box

Re: IGP protocol

On Sun, 18 Nov 2018 at 21:07, Grant Taylor via NANOG wrote: > Is it not possible to protect (just) the eBGP with IPsec? Not on all gears SPs are deploying. But people doing this. > I would think that IPsec would provide the desired protection and that > tuning filters to the proper ports would

Re: IGP protocol

On Sun, 18 Nov 2018 at 17:35, Mark Tinka wrote: > I've found my fair share of IS-IS bugs since I began using it back in 2007 > (when SRC ruled the roost on 7200/7600). What matters is that stuff gets > fixed. In 7600 it is simply not possible because of hardware limitation. I'd be surprised

Re: IGP protocol

On Sun, 18 Nov 2018 at 12:15, Alfie Pates wrote: > There's a school of thought which suggests MD5 security on single-hop BGP is > absolute theatre with no security benefit and that MACsec is the route you > should be taking. AFAIK there are no known attacks against HMAC-MD5. eBGP I don't care

Re: IGP protocol

On Sun, 18 Nov 2018 at 11:15, Mark Tinka wrote: > Yes, IS-IS is designed to speak to connected hosts, but will only do so if > you enable IS-IS on the interface facing that host. > The scope of the exposure, while present, is limited to the radius between > your device and the connected host,

Re: IGP protocol

On Tue, 13 Nov 2018 at 16:27, Alain Hebert wrote: > For those that got involved in fixing a network that goes down due to > OSPF spoofed packets... (Before OSPFv2|3) > + Security for IS-IS Do you know connected host can't talk ISIS to you? ISIS is false security. In modern platforms

Re: IGP protocol

On Tue, 13 Nov 2018 at 12:37, Mark Tinka wrote: > Main reasons: > - Doesn't run over IP. Why is this upside? I've seen on two platforms (7600, MX) ISIS punted on routers running ISIS without interface having ISIS. With no ability to limit it, so any connected interface can DoS device with

Re: Brocade SLX Internet Edge

Hey, They all do in principle the same thing. There are memories for longest path lookup and memories for exact lookup. I believe the trick is to put specific prefix size, like /24 to exact lookup table, relieving the LPM table stress greatly. Then in parallel ask both, and take more specific

Re: CLS to CLS Latency info

Agreed. Actual ping would not work, if we're talking about unixy system sending ping. Active devices increase latency in single digit microsecond, the host latency is much much higher, so the ping results would largely measure your host latency variation. You'd need NIC with hardware timestamping

Re: [OT?] Anyone else been contacted by networkequipment.net after commenting here?

Hey. I got the same spam from Brad and actually have Cat trash to offload, so I iterated SKUs and counts, and his reply: --- thank you Saku ... Feel free to hit me up anytime and have a fun week, Brad --- Dunno what to make of it, that's as far as it went. I expected offer or 'we can't

Re: ifIndex

On Fri, 12 Oct 2018 at 21:40, Chris Adams wrote: > Is there any good excuse that SNMP client software can't handle a basic > design of SNMP - indexed tables? ifIndex is far from the only index in > SNMP, and many of them still change today at various times. > > It isn't that hard to fetch the

Re: bloomberg on supermicro: sky is falling

Hey, > Important distinction; You fire any contractor who does it *repeatedly* after > communicating the requirements for securing your data. > > Zero-tolerance for genuine mistakes (we all make them) just leads to high > contractor turnaround and no conceivable security improvement; A a

Re: Console Servers

On Wed, 19 Sep 2018 at 11:54, James Bensley wrote: > I forgot to mention, it also depends how "out" of band your OOB needs > to be. We use Ciena 6500s for our DWDM infrastructure and they have a > wayside channel (like various DWDM vendors), so it's a separate > channel over the same physical

Re: Console Servers

Hey, > In some DCs I've done mutual OOB swaps with other telcos in the same > suite, this is usually cheap or free (excluding the one time xconnect We consciously decided to not ask or accept OOB swaps, because of fear that they might be provisioned outside processes which might make it

Re: Console Servers

On Tue, 18 Sep 2018 at 16:39, Alan Hannan wrote: > Long ago I used Cisco 2511/2611 and was fairly happy. A little later I used > portmaster and was less so. Recently I've been using Opengear and they work > fairly well but the price is fairly high. I use the CM7100 and IM7100. Out of

Re: Multicast traffic % in enterprise network ?

On Thu, 9 Aug 2018 at 15:27, James Bensley wrote: > A recent customer uses multicast to have the same packet arrive at > multiple destinations at the same time for resilience (their own > internal systems, not IPTV or media etc). Having just refreshed their > network for the next 5-10 years it's

Re: Multicast traffic % in enterprise network ?

On Wed, 8 Aug 2018 at 23:53, Stan Barber wrote: > but the basic requirements of the network itself (e.g. IPv6 uses multicast > instead of broadcast for some network control information distribution). This is almost never true, it's rare exception rather than common case. The idea was that in

Re: Confirming source-routed multicast is dead on the public Internet

On Fri, 3 Aug 2018 at 00:42, Saku Ytti wrote: > Cute :). Well 8*bitrates, but nice optimisation to make stream count > finite. Of course at cost of quality, as receiver needs up-speed of 8x > at start. Interesting side-effect, quality increases as movie > progresses :) I may ha

Re: Confirming source-routed multicast is dead on the public Internet

Hey, On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG wrote: > Hey, there's a better way. > Split the movie into segments: > Segment 1: Minute 1. > Segment 2: Minute 2. > Segment 3: Minutes 3,4. > Segment 4: Minutes 5-8. > Segment 5: Minutes 9-16. > etc. > Then send each segment in a

Re: Confirming source-routed multicast is dead on the public Internet

On Wed, 1 Aug 2018 at 20:47, Saku Ytti wrote: > I'm sure both of your use cases are used extensively in internal > network. I've worked for company who distributed broadcast TV on their > MPLS IP backbone, two-plane network, red and blue, one copy for each > tv channel on both planes

Re: Confirming source-routed multicast is dead on the public Internet

at 20:44, Miles Fidelman wrote: > > On 8/1/18 12:24 PM, Saku Ytti wrote: > > > Hey Mankamana, > > > >> other than billing problem, is there any other reasons why multicast would > >> not be viable for public internet ? > > Imagine someone like y

Re: Confirming source-routed multicast is dead on the public Internet

Hey Mankamana, > other than billing problem, is there any other reasons why multicast would > not be viable for public internet ? Imagine someone like youtube or netflix would like to use multicast, instead of caches. They'd need to start new multicast stream for every content with small delay

Re: Rising sea levels are going to mess with the internet

On Mon, 23 Jul 2018 at 05:55, Rob McEwen wrote: > Meanwhile, global warming > alarmists have ALREADY made MANY dire predictions about oceans levels > rising - that ALREADY didn't even come close to true. Now this discussion does not belong to NANOG, but 'global warming alarmist' is worrying

Re: Proving Gig Speed

On Wed, 18 Jul 2018 at 00:47, Alan Buxey wrote: > another prediction would be that your internet connection (and most devices > in house) connected by 5G - maybe with some local > WiFi - 802.11ax - if theres still spectrum left after the LTE groups have > taken it all for aforementioned 5G

Re: Proving Gig Speed

On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone from > reaching 802.11n speeds, much less whatever alphabet soup comes later. I admire your

Re: Proving Gig Speed

On Tue, 17 Jul 2018 at 10:53, James Bensley wrote: > Virtually any modern day laptop with a 1G NIC will saturate a 1G link > using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC > can do it on one core/thread. I guess if you use large packets this might be true. But personally,

Re: NTT engineer in the wings?

Hey Jason, Can you provide me ticket number (VNOC), time you called and who you spoke with? We have 24/7 NOC, and 24/7 escalation. Sunday is like every other day, this is highly atypical and I apologise for it. You can contact me off-list. Thanks! On Mon, 16 Jul 2018 at 01:16, JASON BOTHE via

Re: deploying RPKI based Origin Validation

On Sat, 14 Jul 2018 at 15:07, Job Snijders wrote: > I actually view it as a competitive advantage to carry a cleaner set of > routes compared to the providers with a more permissive (or lack of) > filtering strategy. Sometimes less is more. * When you consider your addressable market 'clueful

Re: What are people using for IPAM these days?

On 10 June 2018 at 23:56, Job Snijders wrote: > Netbox - https://github.com/digitalocean/netbox > NIPAP - http://spritelink.github.io/NIPAP/ > ed - http://man.openbsd.org/ed ;-) I think lot of these are missed opportunities. There shouldn't really be IPAM, there should number management system,

Re: Juniper BGP Convergence Time

Hey Adam, On 30 May 2018 at 22:49, Adam Kajtar wrote: > *Receiving Full Routes* > > Convergence time was 180 seconds. The routing table updated and showed the > correct path in under a minute but the forwarding table took 180 seconds > for most the routes to update. How as this verified?

Re: Segment Routing

> in the day's of yore, i know a few folks who built tooling to validate > and/or detect failure to sync between the IGP and LDP or detect data plane > black holing behaviors caused by resolution in the RIB w/no complementary > label allocation (or LDP convergence lagging significantly).

Re: Segment Routing

Hey Matt, > I guess my point is why go through the extra config to program labels for > each box when LDP does it for you? Why loose potential visibility to network > traffic? Cisco sales and marketing is digging huge into the SR game for > enterprise and SDWAN like backbone networking. They are

Re: Segment Routing

On 22 May 2018 at 17:43, steve ulrich wrote: Hey, > sorry, yes. i was referring to SRTE wrt the pop operation. Yup RSVP=>SR is more ambiguous and debatable than LDP=>SR which is unambiguous win. > not labels but they are encoded as labels. i hope operators have the

Re: Segment Routing

On 22 May 2018 at 17:29, Mark Tinka wrote: > This is what I'm struggling to find, as for me, this would be the ideal > use-case for SR. My first google hit shows IPv6 support:

Re: Segment Routing

On 22 May 2018 at 17:17, Mark Tinka wrote: > Have you seen an actual deployment in the field, forwarding IPv6 traffic > inside MPLS? My use-case would be to remove BGPv6 in the core, the same way > I removed BGPv4 from the core back in 2008. I have not, but I'm not good

Re: Segment Routing

Hey Steve, > the data plane behavior on LDP is swap oriented, while the data plane on SR > is pop oriented. depending on the hardware capabilities in use this may > have (subtle) traffic engineering or diagnostic implications at a minimum. > folks will likely have to build tooling to address

Re: Segment Routing

Hey Mark, > Can I use that to create MPLS LSP's to carry IPv6 traffic over an IPv6 > next-hop, like LDPv6 has been designed to, i.e., not need for IPv4 in any > way to forward MPLS frames carrying an IPv6 payload? Yes. In ISIS you'd use Prefix-SID sTLV and attach it to TLV-236 (IPv6) or TLV-237

Re: Segment Routing

On 22 May 2018 at 11:19, Matt Geary wrote: > really seeing the value of SR to replace LDP on my backbone. With some > scripting and lots of software tools I can make it just like LDP, but why? > So break the ease of LDP just to get label switching on my hub core not >

Re: Segment Routing

On 22 May 2018 at 12:36, Mark Tinka wrote: > I was excited about SR because I thought it would finally enable native > MPLSv6 forwarding. But alas... Why 'alas'? In ISIS you're free to signal Prefix-SID on IPv4 or IPv6, there isn't anything inherently IPv4 in the standard.

Re: is odd number of links in lag group ok

This is implementation specific. Consider hash result returning range 0-15. Then number of port count as divisor of 16/n must result in an integer value. To workaround this issue, you either have larger range of hash results, in which case unequal distribution has small bias, or you have

Re: China Showdown Huawei vs ZTE

https://kb.juniper.net/InfoCenter/index?page=content=JSA10819 https://kb.juniper.net/InfoCenter/index?page=content=JSA10713 https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180307-cpcp

Re: China Showdown Huawei vs ZTE

On 24 April 2018 at 21:45, Naslund, Steve wrote: Hey, > The US Government considers Huawei and ZTE to have "close ties" to the > Chinese government according to the Director of National Intelligence along > with the heads of CIA, FBI, and the NSA as stated in testimony

Re: China Showdown Huawei vs ZTE

Hey Aaron, > Excuse my lack of knowledge... What does this mean? "Shareholders are people > holding Vanguard/Blackrock." Funds which are largest owners of Cisco shares. -- ++ytti

Re: China Showdown Huawei vs ZTE

On 24 April 2018 at 19:50, Naslund, Steve wrote: > Easy one, what law is the company incorporated under? Nothing against the > Chinese companies (some of their stuff is really great), but it is admittedly > hard to separate China's military industrial complex from their

Re: China Showdown Huawei vs ZTE

On 20 April 2018 at 16:44, Colton Conor wrote: > Yes looks like they are both under pressure. I feel bad for the USA based > employees. I know Huawei has quite a few in Plano, Texas. Feel sorry for US based consumers. Historically protectionism always hurts the local

Re: Attacks on BGP Routing Ranges

Hey, On 18 April 2018 at 14:03, Ryan Hamel wrote: >> a) edge filter, on all edge interfaces ensure that only udp traceroute, icmp >> are sent (policed) to infrastructure addresses > > While I can implement an edge filter to drop such traffic, it's impacting our >

Re: Attacks on BGP Routing Ranges

Hey Ryan, I'm assuming edge link in your network facing another administrative domain. You'll have two scenarios 1) attack coming from your side 2) attack coming from far side You can easily stop 1, obviously. But for 2, you really need to have far-side who is cooperative and understanding of

Re: NG Firewalls & IPv6

Done Checkpoint, Netscreen, SRX , iptables, nftables IPv6 FW all with dynamic routing, but only under extreme duress, like I'm sure everyone who is forced to touch stateful firewalls. Send help. Seems to me this has mostly worked for over decade, worked in context where stateful FW can be said to

Re: Cloudflare 1.1.1.1 public DNS different as path info for 1.0.0.1 and 1.1.1.1 london

If they are for redundancy, wouldn't it be preferable to route them to different place to cover more fault scenarios. I would complain if they are routed to same place. On 2 April 2018 at 22:56, Colin Johnston wrote: > dont know if this is a problem but seeing different

Re: How are you configuring BFD timers?

On 22 March 2018 at 22:41, Måns Nilsson wrote: > Subject: Re: How are you configuring BFD timers? Date: Wed, Mar 21, 2018 at > 04:24:47PM + Quoting Job Snijders (j...@instituut.net): >> Silly question perhaps, but why would you do BFD on dark fiber? > > Because

Re: How are you configuring BFD timers?

. Standard intends echo mode to be HW, but does not guarantee. On 22 March 2018 at 12:10, James Bensley <jwbens...@gmail.com> wrote: > On 22 March 2018 at 09:59, Saku Ytti <s...@ytti.fi> wrote: >> Ethernet handles unidirectional failure natively through autonego asserting >> RF

Re: How are you configuring BFD timers?

On 22 March 2018 at 10:47, James Bensley wrote: > On 21 March 2018 at 16:37, Luke Guillory wrote: >> He's asking because if it was dark the interface would go down when the link >> was lost and the router would pull routes. But PA to FL would

Re: How are you configuring BFD timers?

Why does DWDM imply need of BFD? DWDM has no problem propagating loss-of-signal and asserting remote failure. It is of course possible to configure DWDM so that this does not happen, particularly if you buy protected circuit you might not want it to happen. But as per usual, you should test that

Re: BCP 38 addendum

Hey, > This is exactly my idea : why should I allowed uRPF passing traffic from > routes not learned on this port ?? Why if I have Cogent + Level3 and I > denied ^3356_174 and ^174_3356 AS pathes for logical reasons, I should get > spoofed traffic from Level3 ranges over Cogent peering port ?

Re: BCP 38 addendum

Hey, How would this work? ISP1--ISP2---ISP3 || +---ISP4-+ In case poor rendering ISP1 connects to ISP2, ISP4 and ISP3 connects to ISP2, ISP4 - ISP3 receives ISP1 prefixes via ISP[24] - ISP3 advertises its prefix out via ISP4 ISP1 will receive traffic from ISP3

Re: IPv6 Unique Local Addresses (was Re: New Active Exploit: memcached on port 11211 UDP & TCP being exploited for reflection attacks)

Enno et al ULA fans I could not agree more. Either you provide your enterprise customers transportable address or ULA. If you assign and promote them to use your 'PA' address, they will take your PA address with them when they change operator 10 years from now, and if you reuse it, these two

<    1   2   3   4   5   6   7   8   9   >