Re: [c-nsp] LDPv6 Census Check
On Fri, Jun 12, 2020 at 10:22 PM David Sinn wrote: > Except that is actually the problem if you look at it in hardware. And to > be very specific, I'm talking about commodity hardware, not flexible > pipelines like you find in the MX and a number of the ASR's. I'm also > talking about the more recent approach of using Clos in PoP's instead of > "big iron" or chassis based systems. > TE gives you the most powerful traffic engineering tool kit available. Naturally it has a bit more weight than just a single screwdriver. It can you build nearly any kind of multipath transport while that Clos thing is just one architecture hunting for the cheapest implementation of IP/LDP-style ECMP. On those boxes, it's actually better to not do shared labels, as this > pushes the ECMP decision to the ingress node. That does mean you have to > enumerate every possible path (or some approximate) through the network, > however the action on the commodity gear is greatly reduced. It's a pure > label swap, so you don't run into any egress next-hop problems. You > definitely do on the ingress nodes. Very, very badly actually. > Actually shared links are not a swap but just a pop similar to SR. But indeed this would shift your ECMP issue just to the headend. So for your ECMP scaling there would still be an option left to use an implementation which offers you a merge-point with a single label to all upstreams for a certain equal-cost multipath downstream. This does exist, so would certainly fix your ECMP scaling problem. But advanced control-plane code is certainly not cheap so in the end, like it was already said before, if a simple and cheap platform can solve all your needs then it might be the better one. Let‘s see what problems we need to solve in five years again. What I'm getting at is that IP allows re-write sharing in that what needs > to change on two IP frames taking the same paths but ultimately reaching > different destinations are re-written (e.g. DMAC, egress-port) identically. > And, at least with IPIP, you are able to look at the inner-frame for ECMP > calculations. Depending on your MPLS design, that may not be the case. If > you have too deep of a label stack (3-5 depending on ASIC), you can't look > at the payload and you end up with polarization. > Not really as you are still forced to rewrite on imposition for the simplest form of tunneling, and for TE as often as you need to go against your SPT as well, it‘s just happening on IP (and IP rewrites are more expensive than MPLS rewrites / forwarding operations).
Re: [c-nsp] LDPv6 Census Check
Salve, On Thu, Jun 11, 2020 at 8:08 PM David Sinn wrote: Rewrites on MPLS is horrible from a memory perspective as maintaining the > state and label transition to explore all possible discrete paths across > the overall end-to-end path you are trying to take is hugely in-efficient. > Applying circuit switching to a packet network was bad from the start. SR > doesn't resolve that, as you are stuck with a global label problem and the > associated lack of being able to engineer your paths, or a label stack > problem on ingress that means you need a massive ASIC's and memories there. > I don't think rewrites are horrible, but just very flexible and this *can* come up with a certain price. Irt to your memory argument that path engineering takes in vanilla TE a lot of forwarding slots we should remind us that this is not a design principle of MPLS. Discrete paths could also be signalled in MPLS with shared link-labels so that you will end up with the same big instructional headend packet as in SR. There are even implementations offering this. IP at least gives you rewrite sharing, so in a lite-core you have way > better trade-off on resources, especially in a heavily ECMP'ed network. > Such as one build of massive number of open small boxes vs. a small number > of huge opaque ones. Pick your poison but saying one is inheriantly better > then another in all cases is just plane false. > If I understand this argument correctly then it shouldn't be one because of "rewrite sharing" being irrelevant for the addressability of single nodes in a BGP network. Why a header lookup depth of 4B per label in engineered and non-engineered paths should be a bad requisite for h/w designers of modern networks is beyond me. In most MPLS networks (unengineered L3VPN) you need to read less of headers than in a eg. VXLAN fabric to make ECMP work (24B vs. 20B).
Re: Free Program to take netflow
ES, Kibana, pmacct and some glue (JSON to ES batching) ... and of course a lot of time and resources (eg. h/w). Cheers Chris On Sat 18. May 2019 at 18:04, Joe Loiacono wrote: > Dennis, > > You might try FlowViewer https://sourceforge.net/projects/flowviewer > > Fairly easy Linux install over top of SiLK, netflow capture and analysis > software from Carnegie-Mellon. SiLK is very robust and FlowViewer provides > a web-based interface with extensive analysis, graphing and tracking tools. > Filtering includes by AS. You can create an MRTG-like set of long-term > graphs for each AS and as a group of top 10 ASes (Last 24 Hours, 7 Days, 4 > Weeks, 3 Years.) > > Best, > > Joe > On 5/17/2019 10:26 AM, Dennis Burgess via NANOG wrote: > > I am looking for a free program to take netflow and output what the top > traffic ASes to and from my AS are. Something that we can look at every > once in a while, and/or spin up and get data then shutdown.. Just have two > ports need netflow from currently. > > > > Thanks in advance. > > > > > > *[image: LTI-Full_175px]* > > *Dennis Burgess, Mikrotik Certified Trainer * > > Author of "Learn RouterOS- Second Edition” > > *Link Technologies, Inc* -- Mikrotik & WISP Support Services > > *Office*: 314-735-0270 Website: http://www.linktechs.net > > Create Wireless Coverage’s with www.towercoverage.com > > > >
Re: Stupid Question maybe?
Hi Aseem, On Wed, Dec 26, 2018 at 6:42 PM Aseem Choudhary wrote: > Hi Christian, > > Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2. > > You can refer below link for details: > > https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620 > > I'am running 5.2.2. and it does definitely not work, only continues bits do work (typhoon-based LCs / 9001). cheers -- Christian e-mail/xmpp: christ...@errxtx.net PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318
Re: Pinging a Device Every Second
Depending on your requirements and scale - but I read you want history - it's probably less a demand on CPU or network resources, but more on IOPS. If you cache all results before writing to disk, then it's not much of a problem, but by just going "let's use RRD/MRTG for this" your IOPS could become the first problem. So you might look into a proper timeseries backend or use a caching daemon for RRD. On Sat, Dec 15, 2018 at 4:48 PM Colton Conor wrote: > How much compute and network resources does it take for a NMS to: > > 1. ICMP ping a device every second > 2. Record these results. > 3. Report an alarm after so many seconds of missed pings. > > We are looking for a system to in near real-time monitor if an end > customers router is up or down. SNMP I assume would be too resource > intensive, so ICMP pings seem like the only logical solution. > > The question is once a second pings too polling on an NMS and a consumer > grade router? Does it take much network bandwidth and CPU resources from > both the NMS and CPE side? > > Lets say this is for a 1,000 customer ISP. > > > -- Christian Meutes e-mail/xmpp: christ...@errxtx.net mobile: +49 176 32370305 PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318 Toulouser Allee 21, 40211 Duesseldorf, Germany
Re: Stupid Question maybe?
On Wed, Dec 19, 2018 at 8:32 AM Saku Ytti wrote: > 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, though it caused some loss of hair beforehand... > > Juniper originally didn't support them even in ACL use-case but were > forced to add later due to customer demand, so people do have > use-cases for them. If we'd still support them in forwarding, I'm sure > someone would come up with solution which depends on it. I am not > advocating we should, I'll rather take my extra PPS out of the HW. > > However there is one quite interesting use-case for discontinuous mask > in ACL. If you have, like you should have, specific block for customer > linknetworks, you can in iACL drop all packets to your side of the > links while still allowing packets to customer side of the links, > making attack surface against your network minimal. 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. -- Christian e-mail/xmpp: christ...@errxtx.net PGP Fingerprint: B458 E4D6 7173 A8C4 9C75315B 709C 295B FA53 2318
