Re: [c-nsp] Serious Bug in Cisco's 6500 & 6800 Platforms
hi, On Tue, Apr 09, 2024 at 03:20:15PM +0200, Mark Tinka via cisco-nsp wrote: > https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ios-dos-Hq4d3tZG I'm so glad our single box with SUP-2T has been retired many years ago... (We still do have one (1) Sup720-10G 6500 running, but that is being migrated away from right now) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ACL to block udp/0?
Hi, On Wed, Dec 06, 2023 at 09:00:58AM +, Dobbins, Roland wrote: > On Dec 6, 2023, at 04:45, Gert Doering via cisco-nsp > wrote: > > > deny ipv4 any any fragments > > This is approach is generally contraindicated, as it tends to break EDNS0, & > DNSSEC along with it. I'd argue that the DNS folks recommend using EDNS0 with 1232 bytes, which works just fine to avoid fragments... http://www.dnsflagday.net/2020/ ... but of course you are right that unconditionally dropping all fragments is not a recommended approach unless acutely under attack. What we do here is exactly what you recommend - rate-limit fragments to some 200Mbit/s per network ingress, which is ~50x the normal peak rate of fragments seen, and closely monitor drop counts. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ACL to block udp/0?
Hi, On Tue, Dec 05, 2023 at 11:27:21PM +0200, Hank Nussbacher via cisco-nsp wrote: > We encountered something strange. We run IOS-XR 7.5.2 on ASR9K platform. > > Had a user under udp/0 attack. Tried to block it via standard ACL: > > > ipv4 access-list block-zero > 20 deny udp any any eq 0 > 30 deny tcp any any eq 0 > 40 permit ipv4 any any D'Wayne Saunders already pointed at this most likely being fragments - large packet reflections, and all non-initial fragments being reported by IOS* as "port 0" (so you should see 1500 byte regular UDP as well, with a non-0 port number) IOS XR syntax for fragment blocking is deny ipv4 any any fragments gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Netflow vs SNMP
Hi,
On Mon, Oct 02, 2023 at 09:13:55AM +0300, Hank Nussbacher via cisco-nsp wrote:
> When comparing traffic stats with SNMP, Netflow stats always appear too low
> (see attachment).
>
> Opened a TAC case and their recommendation is to do 1:1 and I quote:
>
> "Irrespective of the rate at which the NP punts the records to CPU, exporter
> picks up a maximum of 2000 records at a time from the cache that are
> eligible for export (timers, network/TCP session events, etc). This is
> basically to avoid NetIO dropping the packets due to lack of b/w. When the
> exporter wakes up again, it repeats the same."
I fail to see why it would make sense to increase the number of flow
exports if their reasoning is "$machinery is busy, so, flow exports are
exported slowly"...
I do like 1:1 netflow, but the ASR9k (at least the linecards we have)
are not suitable to do that, alas - flow cache does not go high enough,
and NPU PPS is limited.
We currently do 1:10, which mostly works OK for our load, but we still
see a few
LC/0/0/CPU0:Oct 2 08:14:24.825 MEDST: nfsvr[280]:
%MGBL-NETFLOW-6-INFO_CACHE_SIZE_EXCEEDED : Cache size of 100 for monitor
v4mon has been exceeded
every day... (from what I understand, there should be enough LC memory
to go higher with that cache, but it cannot be configured).
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP peering Sessions?
Hi, On Wed, Sep 27, 2023 at 08:48:44AM +0800, Barry Greene via cisco-nsp wrote: > Q. Is anyone deploying TCP Authentication Option (TCP-AO) on their BGP > peering Sessions? Not me. Not sure if my vendors do support it (IOS XR and Arista EOS), but I do not see significant benefit. TBH, most of our (non-multihop) eBGP sessions do not even deploy MD5, as the whole password management thing adds another source of operational friction. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] "next-table" Equivalent for IOS XR - Default Route into Global Routing Table
Hi,
On Tue, Aug 29, 2023 at 02:28:53PM +0200, Mark Tinka via cisco-nsp wrote:
> So yes, our default routes point to Null0. I changed that to something
> useful and it still didn't work. It's almost as if the traffic exiting the
> VRF toward the global table wanted to follow a label switched path, and not
> an IP-based path. Not sure whether "label mode per-vrf" would have helped to
> obfuscate the fact that the global table default routes pointed to Null0,
> but it's too late to test now. The box has been swapped out.
My guess after staring long and hard at IOS XR and VRF leaking is that
the CEF structures are getting in the way here - on ingress forward lookup,
as far as I understand, the system expects to find complete egress
information, as in "output line card, output interface, encapsulation,
destination MAC".
When you create a route to another VRF "with an egress interface", this
information can then be populated properly. Asking for "go to the other
VRF and do a routing table lookup over there" needs packet recirculation,
and (again, guessing from how I understand the architecture) this is just
not possible.
... unless you add a loop cable somewhere.
... maybe they could have made a virtual loop cable (LT-), but maybe not...
So, yes, I would be interested what exactly happens inside the box, and
why it does not work / how hard it would be with existing ASR9k NPUs to
make it work (technically) but I expect there will be no answer on this.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP Routes
Hi,
On Sun, Mar 12, 2023 at 08:51:36PM +0200, Saku Ytti via cisco-nsp wrote:
> You might want add-path or best-external for predictability and
> improved convergence time.
Last time we did best-external with ASR9k it only worked in a useful
way if you are using labeled-unicast. That was many years ago, so
it might have been fixed, but "test and expect surprises".
In our case, the effect was that the local router that exported
best-external to its peers was also installing the best-external
path into its local FIB, as a load-shared path(!).
So we had packets come in from uplink, the "good" path was "send
internal over our network", but half the packets got balanced
via the "best-external" path. Intereresting isseus ensued.
To me this never made sense but TAC claimed "this is the way it is,
we're not considering this a bug, use labeled-unicast, then it will
work fine". As we didn't use LU, I could not verify this.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NCS IOS-XR rant (was:Re: Internet border router recommendations and experiences)
Hi, On Tue, Feb 28, 2023 at 08:33:47AM -0800, William McCall via cisco-nsp wrote: > My long-term solution to this problem is to install with iPXE. That lets > you do it via HTTP and without all the nonsense :) This sounds like a fairly long downtime to do upgrades... not exactly what I want either. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet border router recommendations and experiences
Hi, On Sun, Feb 26, 2023 at 08:21:01PM +, Phil Bedard wrote: > The newer software is packaged that way already, if you don?t need SMUs. If > you want to customize it with SMUs and whatnot it takes a few minutes, > depends on your processor and storage speed of course. The question was not so much "how long does it create the iso" but "how long will the platform take to do 'install replace myiso.iso'", given the abysmal filesystem performance of IOS XR. While I generally really like XR more than XE, the "copy one image to flash, and then reload, pointing to that image" is just much more convenient than "have the box extract the image into a full filesystem, waiting for that to succeed, eternities later". (The latter is also something JunOS on EX switches really *cough* excels at, mounting flash read-write that should be read-only, and destroying filesystems on power-outage reloads...) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet border router recommendations and experiences
Hi, On Sun, Feb 26, 2023 at 02:29:13PM +, Phil Bedard wrote: > XR for a number of years now has had the concept of a ?golden ISO?. It?s a > single image either built by Cisco or customers can build their own that > include the base software and the SMUs in a single image. You just issue a > single ?install replace myiso.iso? and that?s it. And that takes how many hours to complete? (But yes, that sounds like progress has been made in XR64 land) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet border router recommendations and experiences
Hi,
On Fri, Feb 24, 2023 at 05:00:52AM +0200, Mark Tinka via cisco-nsp wrote:
> For IOS XR, it's just too heavy for that sort of thing. Okay in the data
> centre where we are aggregating a ton of customers and/or Metro-E rings,
> but not out in the Metro. The Metro calls for a more agile OS. There are
> simply way too many devices to be dealing with the issue you mention,
> updating SMU's, rebooting, e.t.c., just to get a functionality and/or a
> bug fix from IOS XR.
I really do like XR, but the update hassles... so having an "image based"
XR ("scp $new_xr.bin router:", "boot system flash $new_xr.bin", "reload")
would have been really nice.
Now, SMUs and "restart only the affected service" is a great promise, but
in all our time with the ASR9001, all we've seen is "reboot required"
or "the SMU is not compatible with using service packs". So, "just upload
a new image, and then reload" would have had the same effect, with less
argueing with the box.
Not sure XR64 is better in that regard, no experience - we lost trust in
Cisco before the question of "successor to the 9001? something with XR64?"
arose.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet border router recommendations and experiences
Hi, On Thu, Feb 23, 2023 at 09:40:26AM +0200, Mark Tinka via cisco-nsp wrote: > The issue they face is Ethernet-centric platforms are much more > optimized for today's Internet, and platforms like the ASR1000 simply > don't make sense anymore. Why pay all that to get some Ethernet on an > ASR1000 when an MX240 or an ASR9000 is around? Basically they have "fixed" that by making the ASR9901/9902/9903 even more expensive. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Internet border router recommendations and experiences
hi, On Wed, Feb 22, 2023 at 06:29:00PM +, Eric Louie via cisco-nsp wrote: > We tried an NCS-5501 and it was a disaster, in a word. The 10G interface, > uRPF, source-based blackholing, and routing table depth with Cisco is a > limiting factor in their product line. Do not forget the licensing... "extra added value", and the bazaar style price negotiations. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] DNA -- How do I justify the expense to mgmt when we'll never use it?
Hi, On Wed, Jan 04, 2023 at 03:45:51PM +, Drew Weaver via cisco-nsp wrote: > I'm trying to put together an order for some Cisco switches. Cisco licensing shit has made us decide that we're just not going to buy any new Cisco products. Period. Yes, these really look nice, and the base price is quite attractive (guess why)... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NTP network design considerations
Hi, On Fri, Oct 14, 2022 at 03:07:47PM -0400, Aaron wrote: > You can setup a raspberry pi as a server and do GPS. Not sure on the > scalability (how many devices it can handle) of that but it does work. For a true time geek, the time the rPIs provide is just not good enough (fluctuates +/- 20 usec if the rPI has work to do and gets warm) :-) http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html ... but for "I want my own Stratum 1 device and it should not cost a fortune" it's definitely good enough... (I have one with a DCF77 antenna lying around somewhere here, for my network @ home) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NTP network design considerations
Hi, On Fri, Oct 14, 2022 at 02:41:45PM -0400, harbor235 wrote: > I hear what your saying but NTP is an active attack vector, I don't trust > outside resources implicitly and traffic segmentation is a prudent measure > especially if you are getting internet time. Now if you have your own > stratum1 then I understand your point more. The Meinberg boxes have GPS receivers, so they provide Stratum 1 directly. The FreeBSD boxes run standard NTP time, and sync to a variety of official sources (like ntp.se) that are hard to manipulate all at the same time. Now what I'd really like is to use one of those... https://www.oscilloquartz.com/de-de/products-and-services/ptp-grandmaster-clocks/sfp-pluggable-ptp-grandmasters/osa-5401-series ... plug it directly into one of our Aristas, *and* have the router use the PTP time source to feed its own NTP service, as stratum 1... "Less boxes" gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NTP network design considerations
Hi,
On Fri, Oct 14, 2022 at 10:27:16AM -0400, harbor235 via cisco-nsp wrote:
> How are you integrating NTP into your infrastructures? Is it part of your
> management network(s)?
NTP servers (appliances from Meinberg and regular FreeBSD servers, basically)
are just sitting "on the Internet" and our machines sync to them, and
monitor their relative times (= so if one is misbehaving, NTP will
do the right thing on its own, and monitoring will tell us so we can
fix it).
The machines protect themselves by local iptables rules for SSH/https,
and in-band by NTP access rules ("serve time to everyone, serve larger
responses only to management systems, do not believe anyone").
I've never understood this obsession on filtering things that are intended
to be put out in the wild.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How to disable ILMI/SNMP CSCvs33325
Hi, so, more on this... - on ASR9k, SNMPv3 is subject to regular control plane ACLs, so unless a SNMPv3 sender shows up in control-plane management-plane inband interface all allow all peer address ipv4 1.2.3.4/32 ! allow SNMP peer address ipv4 3.4.5.6/32 the ASR9k will not reply (I assume that's generic IOS XR). Good. - on IOS XE, I found something that "seems to do the right thing", as in, block all SNMPv3 packets, including discovery, while still permitting SNMPv2 asr920(config)#access-list 99 deny any log asr920(config)#snmp-server drop report access 99 asr920(config)#do term mon asr920(config)# Sep 21 12:25:07: %SEC-6-IPACCESSLOGS: list 99 denied 1.1.27.20 1 packet Sep 21 12:25:11: %SEC-6-IPACCESSLOGS: list 99 denied 1.1.0.18 1 packet Sep 21 12:31:03: %SEC-6-IPACCESSLOGS: list 99 denied 1.1.27.20 5 packets Sep 21 12:31:03: %SEC-6-IPACCESSLOGS: list 99 denied 1.1.0.18 5 packets (these are the two test hosts that could do SNMP v3 discovery before) - since we're not using SNMPv3 anywhere, that is good enough for us. This is on IOS XE 16.06.10. Older IOS XE and IOS versions have "snmp-server drop unknown-user", but that still permits discovery. So maybe the "snmp-server drop report" will at least help Hank... :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How to disable ILMI/SNMP CSCvs33325
Hi,
On Wed, Sep 21, 2022 at 08:14:30AM +0300, Hank Nussbacher wrote:
> Indeed the SNMP leaks appear to be exactly CSCtw74132 which we did not
> know about nor did Cisco TAC :-(
The more I dive into this, the more I want to return to my bed and
pull the blanket over my head...
So, the Cisco bug ID claims "this has been fixed in some versions",
but none of those are "ASR920 IOS trains" (except 03.9(00)E, which
is sort of weird).
The bug also claims "CVE ID CVE-2012-5719 has been assigned", but
MITRE says "** RESERVED ** This candidate has been reserved by an
organization or individual that will use it when announcing a new
security problem", so it got never published...
That said, I then went to test our Junipers and Aristas, and they
all do the same silly shit - no SNMPv3 configured, strict ACLs for
all configured SNMP communities, and *still* SNMP engine discovery
works from arbitrary sources out there. On the switches it's not
that annoying (management interface is in a well-isolated network
segment) but on the routers, customer-facing IPs are reachable
"from the world".
Sounds like a nice reflection attack in the coming...
*grumble*
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How to disable ILMI/SNMP CSCvs33325
Hi, On Mon, Sep 19, 2022 at 03:47:09PM +0300, Hank Nussbacher via cisco-nsp wrote: > On 19/09/2022 15:40, Gert Doering wrote: > > On Mon, Sep 19, 2022 at 02:29:06PM +0300, Hank Nussbacher via cisco-nsp > > wrote: > >> Recently Shodan has been showing how it probes all our IOS-XE routers > >> via SNMP even though we have an ACL on all our SNMP. We then found that > >> there is a bugid on the issue (ILMI can't be blocked by ACL): > >> CSCvs33325 > > > > Is that still a thing? Insane. > Indeed. Just for reference, here's the 2001 bug. With full PSIRT "get free software upgrade" parts... https://www.cisco.com/c/dam/en/us/support/docs/csa/cisco-sa-20010227-ios-snmp-ilmi.html [..] > > That said, I tried to reproduce it on our boxes, and neither the ASR920 > > nor the lone ASR1000 reponds to SNMP v1 or v2c queries with community > > "ILMI", with nothing in the config to block it (same source host can > > query with one of the configured SNMP communities). This is on IOS XE > > 16.6.10 and 15.5(3)S10 respectively. Seems you need something extra. > > It is V3. Here is a Shodan snippet from one of dozens of alerts we get > per day: Good to know. Looking at shodan, I see that both types of devices here are listed as well (ewww!). So, need to figure out what the magic -v3 incantation of snmpget is to make this work... (every time I tried v3 so far has led to "more grey hair"). thanks for the heads up gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How to disable ILMI/SNMP CSCvs33325
HI,
On Mon, Sep 19, 2022 at 02:29:06PM +0300, Hank Nussbacher via cisco-nsp wrote:
> Recently Shodan has been showing how it probes all our IOS-XE routers
> via SNMP even though we have an ACL on all our SNMP. We then found that
> there is a bugid on the issue (ILMI can't be blocked by ACL):
> CSCvs33325
Is that still a thing? Insane.
It used to be an issue on IOS 15+ years ago... (on IOS, the issue was
"ILMI is a predefined community which cannot be deleted" - but you
*could* expose it, make it explicit, and then put an ACL on it).
That bug is amazing anyway. My suggestion would have been "escalate via
PSIRT", but the bug says "The Cisco PSIRT has evaluated this issue and
determined it does not meet the criteria for PSIRT ownership or involvement.
This issue will be addressed via normal resolution channels."
WAT?!
That said, I tried to reproduce it on our boxes, and neither the ASR920
nor the lone ASR1000 reponds to SNMP v1 or v2c queries with community
"ILMI", with nothing in the config to block it (same source host can
query with one of the configured SNMP communities). This is on IOS XE
16.6.10 and 15.5(3)S10 respectively. Seems you need something extra.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] storm-control errdisable with no traffic or vlan
Hi, On Wed, Aug 03, 2022 at 07:05:59PM -0400, Joe Maimon via cisco-nsp wrote: > Even with switchport mode trunk and switchport allowed vlan none, with > input counters in single digits, storm control immediately takes the > port down after link up. There was negligible traffic on the link before > or after the attempt. > > Vendor's best idea is to turn off storm control, which I am only going > to do with an isolated switch on site, anyone seen anything like this or > have any other ideas? Make the port a routed port (= ingress packets go nowhere), set up a SPAN session, find out what sort of packets are coming in (broacast, multicast, unknown-unicast) and how many of them. Adjust limits, as ytti said. While I agree to "have storm-control anywhere" - if this is intended to be a routed link, limits can be fairly high (the only reason why you want storm-control is to protect the 4900M's CPU, not anything else in the network). OTOH, a 4900M? really? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 randomly loosing layer-2 on a port
Hi,
On Mon, Jul 11, 2022 at 04:47:57PM +, Brian Turnbow wrote:
> > On Mon, Jul 11, 2022 at 03:59:02PM +, Brian Turnbow wrote:
> > > Yep, sounds like the infamous uptime over 2 years "feature" from 3.16
> > (something)..
> > > Reboot and upgrade was the only way we fixed it
> >
> > Uh. Could you elaborate on what that "feature" is, exactly?
>
> It was the bug where after after two years of uptime
> If an interface went down it would stick as up and not pass traffic
> You could not provision new interfaces.
> Counters also stopped working. (we used this to find affected units)
Now THAT is interesting. I'm a bit further distanced from day-to-day
operations these days (otherwise I might have noticed), but indeed,
counters didn't work anymore either. "No traffic on this box!" which
I know to be not true (our daily TSM backups go through there...) - and
after reboot, "Traffic!".
Very interesting. "Interface itself" counters are all "0", but service
instance counters (gi0/0/2 si 90) still show traffic. So that's actually
something our alarming could trigger on "si has > 1 Mbit, interface itself
has 0"...
[..]
> Sounds like it may be different.
> Did the counters work?
> Maybe they decided to add it into 16.06 , you never know what a BU may decide
> is a must have feature
Obviously, 16.06 has much improved performance, so 2-year-bugs are now
hit after 0.5 years already!
OTOH... seems it wasn't actually 27 weeks uptime, but quite a bit more,
which was just distorted by SNMP uptime wrapping (and our prometheus
instance not properly distinguishing this for old data, it only recently
learned to query that other OID).
So, definitely more than 2 years, and traffic counters stopped some 5 months
ago... and we did not try to actually bring up anything new since then.
Yeah, thanks a lot for this information. This will be very helpful to
avoid needless frustration by our on-site people ("it does not link! can
you please try a different cable? did you get the patch right?").
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 randomly loosing layer-2 on a port
Hi,
On Mon, Jul 11, 2022 at 03:59:02PM +, Brian Turnbow wrote:
> Yep, sounds like the infamous uptime over 2 years "feature" from 3.16
> (something)..
> Reboot and upgrade was the only way we fixed it
Uh. Could you elaborate on what that "feature" is, exactly?
We recently had an ASR920-12CZ which stubbornly refused to establish
link on any 1GE ports ("as if no cable was connected"), though *existing*
links worked just fine. After a reboot, all ports back to normal.
This was on 16.06.05a - but the uptime was only 27.4 weeks, our
monitoring says... - so, maybe a different "feature"...
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] [j-nsp] SRTBH
Hi, On Thu, Jul 07, 2022 at 08:41:56AM -0400, harbor235 via juniper-nsp wrote: > Since Flowspec arrived, are there any uses for SRTBH? Scaling? My understanding of flowspec is that it is typically implemented by programming ACL TCAM, while SRTBH is routing table lookup, so "some 10.000 lines" vs. "2-4 million". OTOH, SRTBH is all-or-nothing, not "only port 80"... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] An attribute with less priority than local preference for choosing a best path.
Hi, On Fri, Jun 03, 2022 at 06:26:37PM +0200, Gert Doering wrote: > MED is what we use, because local-pref basically just ensures job > security (because once you start, you'll be twiddling all day to > fix the unexpected consequences). Forgot to add the URL to The Talk :-) https://www.youtube.com/watch?v=gn-cdzHxkpk https://media.ccc.de/v/denog13-12617-local-pref-considered-evil (same thing, video + slide show) https://pretalx.com/denog13/talk/RVC77F/ (slides) (I've let people talk me into making this a live show at DENOG 13 last fall...) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] An attribute with less priority than local preference for choosing a best path.
Hi, On Fri, Jun 03, 2022 at 03:48:37PM +, Drew Weaver wrote: > In order to control that I was using: > > if community matches-any LUMEN-CLEVE then > set local-preference 150 > endif Don't. MED is what we use, because local-pref basically just ensures job security (because once you start, you'll be twiddling all day to fix the unexpected consequences). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BFD not working on ASR920
Hi,
On Sun, Apr 03, 2022 at 07:58:22PM +0200, Mark Tinka wrote:
> On 4/3/22 12:01, Gert Doering wrote:
> > ... all the "down and we cannot find a reason" BFD sessions came up the
> > moment I removed the "ip flow ingress" from the interface config.
>
> IIRC, isn't Netflow support on the ASR920 somewhere between suspect to
> non-existent? Or was that NAT? Or was that PPPoE?
Netflow is sort of semi-supported, if I remember right - by using
the SPAN feature of the chip to siphon traffic off to the CPU, and
do netflow there, capped to 1GE of traffic. Or something like that.
Did not try NAT or PPPoE on that box... but I'm sure there is excitement.
(Speaking of SPAN - trying to debug BGP using a local SPAM is a real
adventure, as packets sent by the local CPU are not seen on a RX/TX
mirror session... only the RSTs coming in from the other end gave a
clue what happened)
> Thanks for the tip. I'm sure it will be helpful for many!
That was the idea :-)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] BFD not working on ASR920
Hi, this is no question (except "why oh why?") but for the sake of google and to help the next one that runs into this... We have a number of ASR920-12 on 16.06.05a - because we cannot be bothered to go to "the new licensing scheme" - and we have customer lines on them, "because SFP handoff". All the interfaces follow a standard scheme interface GigabitEthernet0/0/2 description /lid=nnn (primary) ip address 195.xx.xx.12 255.255.255.252 ip flow ingress negotiation auto cdp enable ipv6 address 2001:608:xxx:xxx::1234/64 bfd interval 200 min_rx 200 multiplier 10 (really nothing special here) and then there's BGP config to the customer's router, with BFD neighbor 195.xx.xx.13 fall-over bfd neighbor 2001:608:xxx:xxx::1235 fall-over bfd ... this used to work fine on our 6500s, but BFD just did not want to come up on the ASR920s, no matter what I tested and debugged. Today I found the culprit - the configs were copied over from the 6500, including an "ip flow ingress" line - we do not have netflow active on the ASR920 (and from my understanding of "how it works", this is not something we actually want) so I considered this more of a no-op / config wart than a problem. Today I went cleaning up... and lo and behold ar21(config)#interface GigabitEthernet0/0/2 ar21(config-if)#no ip flow ing ar21(config-if)#^Z Apr 3 11:41:11: %SYS-5-CONFIG_I: Configured from console by gert on vty0 (2001:608:0:736::18) Apr 3 11:41:18: %BFDFSM-6-BFD_SESS_UP: BFD-SYSLOG: BFD session ld:37 handle:9 is going UP ... all the "down and we cannot find a reason" BFD sessions came up the moment I removed the "ip flow ingress" from the interface config. long story short: "ip flow ingress" kills BFD on ASR920, both for IPv4 and for IPv6. (and no, I'm not going to bother spending another month of my life explaining this to TAC - documenting this on c-nsp is more helpful to other victims than trying to get things fixed on this platform) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 experiences?
Hi, On Thu, Feb 24, 2022 at 05:50:39PM +0200, Hank Nussbacher wrote: > We ordered 2x 9906s last month w/ delivery in August. > Will let you know how that turns out. Not sure the 9902/9903 are actually comparable to 9906... 2RU/3RU "mostly fixed" chassis with special-cased RPs vs. regular modular ASR990x chassis. (Also, I do not think the 9906 falls under the new license regime, where you need to buy one license per 100G throughput, per feature that you want to use) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9902 experiences?
Hi, On Thu, Feb 24, 2022 at 02:04:54PM +, Drew Weaver wrote: > Does anyone have any real world working experience with the ASR9902? Any > particular gotchas (yet)? Looked at the ASR9902 and 9903 list prices and required licenses shenannigans and decided to go for Arista. Especially the license absurdities - the base price is already insane, but then you need all the extra licences. Feature x Bandwidth. From the "Hardware features and IOS XR" I'd love to get a few :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] TCP MSS CLAMPING issue
Hi,
On Sun, Jan 23, 2022 at 06:58:29PM +0100, james list wrote:
> > It's "the Internet". Pointing at clients as being "non compliant" is
> > not going to fix your server's operation - otherwise, all this fiddling
> > with TCP/MSS would not even be necessary in the first place.
>
> > (Another option would be, of course, to fix your network :-) - so 1500
> > byte packets can get through, and no need to reduce the client's MSS)
>
> I guess that nowadays almost all the companies (with a name) rely upon
> antiDDOS systems using GRE hence I'm wondering why you say we need to fix
> something on our side.
Well. You could have direct connections to those AntiDDoS providers,
thus, no MTU issue. Or they could fragment inside the GRE tunnels,
or send ICMP packet too big back to the sender.
Lots of ways to deal with "reduced MTU" in IPv4 land, if you must have
a segment with reduced MTU.
We do not use AntiDDoS providers that can only do GRE, so, no, not
"all companies with a name". We have a direct handoff (using a DECIX
virtual service with 1500 MTU).
(Why does your firewall go into "must use SYN/ACK spoofing mode!!!" if
you have a DDoS provider in the path that should be dealing with that?)
> If there are RFC (=law) I'd expect those are followed, otherwise you cannot
> complain, am I wrong ?
This is The Internet. You will find any sort of non-compliant implementation
out there - and by deviating from commonly established behaviour ("send a
MSS value in SYN/ACK") you're triggering code paths in client implementations
that are less tested, and might be just buggy. Or rely on interface MTU
and PMTU detection (= ICMP packet too big).
But you can't fix the clients. They are what they are.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] TCP MSS CLAMPING issue
Hi, On Sun, Jan 23, 2022 at 06:31:40PM +0100, james list wrote: > thanks for the feedback. > > Firewall vendor reports this: > > " When > SYN Cookies > is activated, the firewall does not honor the TCP options that the server > sends because it does not know these values at the time that it proxies the > SYN/ACK. Therefore, values such as the TCP server???s window size and MSS > values cannot be negotiated during the TCP handshake and the firewall will > use its own default values. In the scenario where the MSS of the path to > the server is smaller than the firewall???s default MSS value, the packet > will need to be fragmented. " It does not have to know what the server would send to always put in an MSS option of its own... (but of course the vendor would tell you "this is not our fault"). > Here we see the client seems not RFC compliant, since in RFC6691 ( > https://datatracker.ietf.org/doc/html/rfc6691#appendix-A) is written: > > "If an MSS option is not received at connection setup, TCP MUST assume a > default send MSS of 536 (576-40) [TCP:4]." > > As recap: > > 1) during no attack client send MSS 1460 with DF=1, server respond through > MSS 1436 (due to GRE), client uses 1436, connection is established > correctly with TLS exchange > 2) during attack client send MSS 1460 with DF = 1, server (=firewall in > this phase due to syn-challenge) respond without MSS, client uses 1460, TLS > exchange is broken > > From my point of view, since RFC6691 state "MUST use 536", the customer is > not compliant. It's "the Internet". Pointing at clients as being "non compliant" is not going to fix your server's operation - otherwise, all this fiddling with TCP/MSS would not even be necessary in the first place. (Another option would be, of course, to fix your network :-) - so 1500 byte packets can get through, and no need to reduce the client's MSS) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] TCP MSS CLAMPING issue
Hi, On Sun, Jan 23, 2022 at 05:10:42PM +0100, james list wrote: > I suspect the current Cisco implementation does not change MSS because the > syn-ack does not contain the MSS option. If there is no MSS option, nothing can be adjusted - one would need extra code to *add* such an option, which is more complex than "change one number and adjust the checksum". So, get your firewall vendor to fix their SYN-ACK-spoofing code. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS XR RPL Matching on neighbor IP/ASN
Hi,
On Mon, Nov 22, 2021 at 10:02:56AM +0100, Sascha E. Pollok wrote:
> I have actually tried to specify a custom community as a parameter and match
> against that
> in the route-policy's condition but that didn't work with match-any
> ($community). The
> parser wouldn't let me commit that.
>
> Do the RPL variables only work for numbers? Then I wouldnt also assume that
> something like
> match-any (12345:$var) would work?
Haven't tried, but that would be extremely annoying.
The use case I have in mind is using large communities to control
per-peer-AS exports, as in:
:0: --> "do not announce to $yourasn"
:1: --> "prepend to $yourasn"
and if that cannot be done by RPL parameters, this idea already looks
like "meh, nah, not worth the effort of having hundreds of nearly
identical policies"
route-policy export-to-
if match-any community in ( 5539:0: )
then
drop
fi
apply decix-generic
end-policy
*scratch head*
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] IOS XR RPL Matching on neighbor IP/ASN
Hi,
On Fri, Nov 19, 2021 at 05:48:56PM +0100, Sascha E. Pollok via cisco-nsp wrote:
> So for example if I have a route-policy on a neighbor-group and would like to
> announce a
> specific prefix only to one of these neighbors, I would like to be able to do
> something like:
>
> if (neighbor-asn '12731') then
> # Announce this one prefix only, if receiving neighbor is in ASN 12731
> done
> elseif (neighbor-ip '192.168.1.1') then
> # Announce this one prefix only, if receiving neighbor is 192.168.1.1
> done
> endif
Not sure if that is possible (but I can see why you'd want it).
It might be possible by having something like
neigh 192.168.1.1 address-fam ipv6 u route-policy MyPolicy(192.168.1.1) out
... but I'm not sure you can have an IP address there and compare it
to "something". Numbers should work...
https://lukasz.bromirski.net/docs/prezos/2018-IOS-XR-RPL-CLN.pdf
page 23 and 24 have interesting-looking examples.
(And yes, it means "one extra line of config per neighbour", but that's
still better than "one distinct route-policy per neighbour")
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FIB scale on ASR9001
Hi,
On Thu, Nov 11, 2021 at 03:02:35PM +0100, Lukas Tribus wrote:
> > We're on 6.5.3 ("nothing interesting in newer versions, and still
> > supported").
>
> When I tested RTR on IOS-XR I hit some strange bugs in the RTR client,
> specifically the RTR session would hang in certain scenarios (router
> restart, RTR server reboot, etc), requiring manual intervention with a
> "clear bgp rpki-server 1.2.3.4". It was *a lot* better in more recent
> releases, but 6.5.3 was not part of those better releases.
Yeah. That bug hits here as well, every now and then one of the two
sessions (or both) get stuck. We have a script that walks all our XR
boxes and verifies that they all see the same amount of prefixes on
both sessions, across all boxes... and then alerts, and we go "clear".
Not exactly displaying best of software quality, but more of a minor
nuisance (for us).
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FIB scale on ASR9001
Hi, On Thu, Nov 11, 2021 at 10:14:16AM +0200, Mark Tinka wrote: > I have read a lot of Cisco documentation on configuring ROV on IOS XE > and IOS XR, and unless something has been recently updated, this is not > one of the explicit recommendations in that documentation. I can see how > easy it is to overlook (or if you do have 'soft-reconfiguration inbound' > configured, how that significance can also be overlooked). I've been extremely underwhelmed with the quality of IOS XR documentation in many respects, ROV being one of them. (And ROV on IOS XE is full of different eels... as if a totally different company has implemented it, without ever speaking to someone who has done this before, or understand what it's supposed to do) > All that notwithstanding, the move to 100Gbps peering/transit + faster > CPU's on the MX204 is still a worthy reason to move away from the > ASR9001, for us anyway :-). Yeah, not argueing that decision, just curious about the problems you saw. We're moving towards Arista 7280R, which is not without its own set of surprises... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FIB scale on ASR9001
Hi, On Thu, Nov 11, 2021 at 09:26:12AM +0200, Mark Tinka wrote: > We are currently running 6.7.1, mainly to fix some LDPv6 issues. > > However, we started seeing this "too many BGP refresh messages" issue as > far back as 6.4.2. I seem to remember it's related to RPKI ROV (every time the RPKI server sends new data the BGP implementation asks for a refresh to re-validate the incoming feed). Or at least there is something in the back of my head that says "I have heard someone talk about this unintended side-effect of RPKI ROV, together with a BGP setup without 'soft in always'". Might there be a correlation in your environment? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FIB scale on ASR9001
Hi,
On Thu, Nov 11, 2021 at 08:27:44AM +0200, Mark Tinka wrote:
> We have nothing against the forwarding performance of the ASR9001. It's
> the control/management plane that seems to be slowing down (at least for
> us, anyway) with newer code and a growing Internet DFZ.
"newer code" might be the key issue here - what version are you on?
Our 9001 have been extremely well-behaved in regards to BGP performance
and robustness. Not as fast as the RSP440, but still well up to the
job.
We're on 6.5.3 ("nothing interesting in newer versions, and still
supported").
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] FIB scale on ASR9001
Hi,
On Tue, Nov 09, 2021 at 04:49:54PM +, Drew Weaver wrote:
> We have a couple of these in production also are you planning on going with
> the 9902 or 9903 or are you switching altogether?
>
> I would love it if they could just make an ASR that has 4xQSFP28 ports and a
> slot to add 4-6 more.
>
> Would be perfect for us assuming that it wasn't $80,000
Looking at the prices for 9901/02/03/04, and the licensing models for
NCS5700, I can assure you, "it won't be $80,000".
More like "$100k for the Chassis, and then another $300k for all required
licenses, to be renewed every 3 years" (subject to bazaar style discount
negotiations that make any sort of budget planning impossible)...
Cisco is a textbook example how to drive away a truly loyal user base,
and then blaim it on stock market analysts ("they said that any company
without a recurring revenue software model will be dead soon").
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] TIL: Maintenance Operations Protocol (MOP)
Hi, On Fri, Aug 06, 2021 at 02:00:30PM +0200, Lukas Tribus wrote: > I'm no longer putting in hundreds of hours to fight losing battles, > which earlier in my carrier I did: > https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/Cisco-SA-20140828-CVE-2014-3347 Ensuring that MOP is dead and stays buried might actually be worth a PSIRT effort - any feature that is on-by-default and enables unauthorized access to a device should be worth the fight. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] TIL: Maintenance Operations Protocol (MOP)
Hi, On Thu, Aug 05, 2021 at 10:40:20PM +0200, Lukas Tribus wrote: > code from decades ago, the BU responsible for the code path today > probably handles a million other things, some of them presumably do > actually make money. Yeah, like invent new license madness... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9K using XR 7
Hi, On Thu, Jul 29, 2021 at 07:48:09PM +, Erik Sundberg wrote: > Just wondering if anyone out there has and moved there ASR9K's to XR 7. Which RPs, which line card generation? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 1600R series router internals
Hi, On Fri, Mar 26, 2021 at 03:37:41PM +, Tom Storey wrote: > Interesting. I might take a little look into this, but not sure how much of > it will translate over, I presume they will be very different platforms > (there are very few similarities between the 2500 and 1600R other than the > family of CPU). 3600 is similar in some aspects, as it has the NM modules with WIC slots on them. (I do not have any specifics, but assume that the NM would have a PCI<->PCMCIA bridge chip on it, connecting the WICs) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 Port Licensing
Hi, On Wed, Feb 24, 2021 at 11:36:48AM -0500, Shawn L wrote: > Interesting. It is full of surprises. So that brings up the next > question. what happens when someone upgrades the IOS and the licensing > model changes? > > I can definitely see a situation where that happens and ports that used to > be in service are now unlicensed. That'll be a fun one to troubleshoot in > the middle of the night. Yep. Welcome to the world of "we truly understand what our customers are really expecting from a network vendor". If only Arista had something comparable to the ASR920 line (port/footprint/ pricing)... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 Port Licensing
Hi, On Wed, Feb 24, 2021 at 06:42:41AM -0500, Shawn L wrote: > On the new router that was sent, only 6 ports are operational. The other 6 > are disabled, and won't enable, giving me license error when I try. > Cisco's telling me that the licenses on both the new and old routers match, > so their job is done. Port usability without license on ASR920 changed between software versions. We do not have the 12x10 models, but we have the 12x1+2x10 models, and they changed from "you can only use ports /1../6" to "you can use any port, but only 6 in total" at some point int the past That said, if you have the same software version on the RMA'ed device, it definitely should behave the same. *That* said, the ASR920 BU is full of interesting *ahem* surprises. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] asr1001-x : dynamic qos on virtual-template
Hi, On Mon, Feb 15, 2021 at 01:51:33PM +0100, BASSAGET Cédric wrote: > policy-map parent > class class-default > shape average percent 100 >service-policy child "average percent 100" of... what? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NXOS BFD sends packets sourced and destined for it's own IP address to the remote host.
Hi, On Tue, Jan 19, 2021 at 01:22:57PM +, Drew Weaver wrote: > Ah okay, I suppose I was confused because I didn't configure bfd echo on the > Nexus side and it's not anywhere in the configuration on the device. Google says echo mode is default on Nexus. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NXOS BFD sends packets sourced and destined for it's own IP address to the remote host.
Hi, On Mon, Jan 18, 2021 at 08:15:02PM +, Drew Weaver wrote: > I can really easily resolve this by just adding another line to the ACL but I > would much rather understand how this traffic is ending up on the wire in the > first place. By being sent out, to be returned by the other end "if its IP forwarding engine is working" - BFD echo mode https://netcraftsmen.com/clarifying-bfd-and-bfd-echo/ gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] eBGP/iBGP question
Hi,
On Thu, Dec 24, 2020 at 10:16:08AM +0200, h...@interall.co.il wrote:
> Ideas and clues welcome.
BGP will only ever signal the best path onward.
So if R1 decides "I like eBGP paths behind R2 much more!", it will never
send its own eBGP paths to R2, because they are not "best".
There is "bgp best-external" and "bgp add-paths" to achieve other
results, but those have implications - like "more memory usage" and
on XR "best-external does totally weird things unless you run labeled-
unicast".
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RPKI extended-community RFC8097
Hi, On Sat, Dec 19, 2020 at 11:02:16AM +0100, Robert Raszuk wrote: > > As far as I know, no way to set "ineligible" from a route-map. Is there? > > A workaround could be to set unreachable next hop instead of dropping :) > That automatically disables such path from best path comparison yet it > keeps in BGP. Interesting trick. Need to test. > But as said implementation could make it easier with a knob. > > The question to ask if you want to advertise INVALID paths around ? Even if > not best path once you enable add-paths it may be advertised. We do not use add-paths today, but if we did, I wouldn't want INVALIDs advertised anywhere. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RPKI extended-community RFC8097
Hi, On Sat, Dec 19, 2020 at 10:13:36AM +0100, Robert Raszuk wrote: > See even if you validate in route map you may just mark it not-eligible or > set higher local pref for VALID etc I am not sure how anyone could > come with the idea to just drop there. In the face of invalid more-specifics, the "local-pref" thing just plain doesn't work. So "ineligible or drop for INVALID" is the only option. We do "drop in route-map", on ASR 9k, and this thread has me thinking if this was a good idea. As far as I know, no way to set "ineligible" from a route-map. Is there? So back to the drawing board. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RPKI extended-community RFC8097
Hi, On Fri, Dec 18, 2020 at 10:25:30AM +0200, Ben Maddison via cisco-nsp wrote: > The router should not *act* on validation status unless told to by the > operator at all. This! > I would suggest that the 'bgp bestpath prefix-validate ...' commands be > deprecated altogether, and be replaced with a single per-afi/safi > command that simply enables rov-checking (i.e. records the status in the > RIB, but takes no policy action). > Everything else can be done in a route-map. And this! gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Local DNS cluster behavior
Hi, On Sun, Dec 06, 2020 at 12:11:34PM +0800, wrote: > Based on the logic above we talked.Is it possible that the first time DNS > query sent out by Local DNS Server A using IPv4 to the authority Server,but > somehow the second time query by Server B turned out IPv6 query instead of > IPv4? Sure. Possible, and also fairly likely. And no problem whatsoever. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NCS540 - Interface up, not passing traffic
Hi, On Fri, Dec 04, 2020 at 03:09:33PM +, Eric Van Tol wrote: > Yeah, I've also had weird experiences with the ASR, but the difference here > is that the port is up on both sides, and consistently comes up when the > interface is shut/no shut, whereas in every instance we've had such > weirdness, the port would not come up at all on the ASR. Definitely not > ruling it out, it's just different behavior than I've seen before. > Regardless, I'll keep the ASR in mind as a possible source of the problem. Try enabling LLDP or CDP and see if you can see anything. Try looking on the "show int ten... accounting" counters to see if either side receives what the other side claims to be sending. The link might be good, but the IP layer might be confused... or one side might be sending ok, but not receiving anything. Counters good. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9k RSP440
Hi, On Thu, Nov 12, 2020 at 10:06:11AM -0600, N. Max Pierson wrote: > We're trying to figure out what the last train of XR software that can run > on the RSP440 for a 9006. We're running 6.2 right now but I can't seem to > find any docs that state what the last version of support is. We're trying > to patch/upgrade a few 9006's from CSCvv09115 > <https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvv09115> but aren't sure > if 6.7.2 will run on our RSPs. We're getting rid of these in a few months > but didn't want to be exposed in the interrium if possible. 6.5.3 works and has a SMU for that bug. It is officially not supported, as in "we do not even try to see if it boots", but for us, it works ok (so far). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EOBC0/0 ifInErrors
Hi, On Fri, Oct 02, 2020 at 03:00:05PM +0700, Eugene Grosbein wrote: > Instead, error rate decreased significantly but not ceased (12:25 was the > moment): > http://www.grosbein.net/cisco/eobc0_0-day.png Well, if the now-active RSP is the one with the faulty EOBC link, this is what would happen - by removing the standby RSP, you removed a lot of traffic on the EOBC bus (session sync etc). Some traffic remains (talking to the line cards), so it's not "gone" but "less" gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Whats happens when TCAM is full on 7600/RSP720RSP-3CXL?
Hi,
On Mon, Sep 21, 2020 at 10:14:40PM +0100, Tom Hill wrote:
> The only issue now is (as gert alludes to) RSP-440 are somewhat old, as
> is the 9006 chassis.
It's not "somewhat old", Cisco has explicitly declared the RSP-440
end-of-life. The ASR-9006 chassis is still supported.
https://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/eos-eol-notice-c51-737819.html
the RSP-440 stopped selling in 2017, and it's formally no longer supported
beyond IOS XR 6.4.
6.5.3 works nicely (*ahem*), but is officially "never tested on RSP440,
never bugfixed, we do not care".
So - if you know exactly what you are getting yourself into, getting a
used ASR-9006 + RSP-440 + Typhoon LCs will be a nice bargain, but you
won't get a service contract for it, and you *will* run into "ah, no,
*that* feature is not implemented on this linecard..." issues.
OTOH, for the original requirements "up to 3 Gbit/s", getting a box that
uses 1000+ Watts *and* needs so much space *and* is end-of-life might
not be a good choice... in Cisco land, there's the ASR9001 (nice box,
though the MPAs all carry the "we do not want to sell them" price tag)
or the ASR1000 as alternative (though I'd never buy one), or you look
into Juniper land for a MX204. The MX204 is really like "the box".
Given the IOS XR is sufficiently different from IOS that you need to
invest in training anyway, have a close look at the MX204.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Whats happens when TCAM is full on 7600/RSP720RSP-3CXL?
Hi, On Fri, Sep 18, 2020 at 12:44:55PM +0200, ??ukasz Bromirski wrote: > For traffic going to prefixes that failed to be installed in HW, > resulting performance will be similar to what you can get on those > pretty small, non-x86 CPUs. Much worse, actually, as the control-plane limiters hit hard - so you do not get "full software-switched performance, with 100% CPU load" but "CPU load is mostly normal, everything looks normal, some targets have 80% packet loss". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Whats happens when TCAM is full on 7600/RSP720RSP-3CXL?
Hi, On Fri, Sep 18, 2020 at 10:54:53AM +0200, chiel wrote: > 3. New route entries will be software routed, but entries that are > already in TCAM will be hardware routed. You won't notice much impact in > the beginning. "Route entries that have churn will end up in software" *and* "the software path is heavily rate-limited". So "for some targets you'll see massive packet loss". Only a reload will get this fixed -> avoid this situation. > What is true? > > The only reason that our 7606 needs to be replaces it because of the > TCAM. It doesn't do much traffic, like 3Gbps upstream. Only BGP/OSPF. > And not many ports, 8 x 10Gb fiber + 30 x 1Gb copper (local servers). > > We will probably go for the ASR9006. But I would like to use it like I'm > using the 7600 now, as a router/switch. I have been reading that you > need to make some uncommon config to create Ethernet VLAN/Trunk > interfaces and ports, as this is not commonly not done with this router. > But is this good practice? Will it be fine once I fingered it out? If spanning tree is involved, the ASR9k gets clunky. Besides that, it does routing/switching on VLANs and trunks nicely (though the config is quite different to "more switchy" platforms like the 6500/7600). > Last question. Can I take a full BGP feed on both v4 and v6 with a > A9K-RSP440-TR? Or do I need the -SE? The RSP440 will cope nicely. It is end-of-life, though. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9K HSRP Configuration
Hi, On Fri, Aug 28, 2020 at 03:05:19PM +, Mohammad Khalil wrote: > Greetings all > I am trying to bring up HSRP between ASR9Ks who are connected through bundle > ether to N5K What do you need ICCP for? As in "is this supposed to be an all-active 4-port MLAG to the N5K"? Never done ICCP-based MLAGs on the 9k, but if you can get around that and just use routed interfaces on "just one 9k" LAGs it should work fine... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 LACP and xconnect
Hi, On Fri, Aug 21, 2020 at 08:34:14AM +0300, h...@interall.co.il wrote: > We have seen that as well. We had that recently with a new > international carrier. > Turns out when they set up the circuit on their optical switching > equipment (whether it be Ciena, ECI, Infinera, Cisco or whoever), > there are some knobs that need to be adjusted to allow through all > types of packets. After having our NOC staff eat 4 hours in the wee > hours of the morning trying to debug why the LACP bundle would not > come up, a simple change by the carrier the next day had the new > circuits up in a matter of seconds. LACP bundles *through* two ASR920s actually work nicely. Just LACP *to* an ASR920, and then forwarding said bundle via EoMPLS (not individual VLANs, but "all of the poX interface") fails. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR920 LACP and xconnect
Hi,
On Thu, Aug 20, 2020 at 06:12:29PM +, Eric Van Tol wrote:
> I???m trying to verify something here that is working, but also not working.
> At some point, we built an LACP bundle to a customer device (2x1G ports) and
> put it into an EoMPLS setup using xconnect to send it over to another site
> where they have a 10G single circuit. While the LAG is ???up??? and passing
> traffic, the ports continuously get removed from the bundle and added back in
> and there???s obviously a small amount of packet loss that occurs when that
> happens.
I've been there, and could not make it work (we tried with 2x 10G as
well as 2x 1G). I have the feeling that it's eating the/some LACP packets.
[..]
> If this is confirmed as unsupported, would I be correct in that we would have
> to separate out the untagged native VLAN into its own, non-xconnect EFP, so
> as to do proper ???l2protocol peer??? configuration? My only concern there is
> that the native VLAN needs to be transported along with all other VLANs to
> the other end of the xconnect so I am not sure right now how we do that, or
> if we even can.
There's an "encapsulation untagged" or something - it can be done :)
I have not tried to find out whether it's officially supported or
unsupported - ASR920 "what is supported and what not?" documentation is
not exactly satisfactory.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ARP requests
Hi,
On Thu, Aug 20, 2020 at 12:05:07AM +0700, Eugene Grosbein wrote:
> > Otherwise, ask the router - "debug arp" - and for each ARP request you
> > see it issue, check the routing whether it points directly to an
> > interface.
>
> Well, I have packet capture in my analyzer and I see all the details there,
> like this:
This is missing the point. The router will tell you more on "what it
thinks the interface is".
[..]
> > (And never believe what switches say about tagging vs. not)
>
> I've saved capture to PCAP file and verified it with Wireshark, no tags.
> Still cannot understand why no tags.
On many platforms, monitoring ports will not show the original tag.
(On Cat6500, tags will only be shown if the *destination* port is set
to "switchport mode trunk", for example)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ARP requests
Hi,
On Wed, Aug 19, 2020 at 06:23:36PM +0200, ??ukasz Bromirski wrote:
> Working with TAC would be probably best option going forward.
I find your optimism amazing.
(My TAC case about "ASR920 do not always honour IPv4 ACLs on SVIs"
is not getting anywhere since December. We managed to reproduce the
issue in the TAC lab around April...)
It might give some sort of satisfaction if a TAC case eventually comes
to a conclusion different from "works as designed" or "the effect is
gone after reboot" or "have you tried upgrading to the latest version?"
(and then "gone after reboot") but for ongoing operational problems,
we have been less than underwhelmed with TAC performance.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ARP requests
Hi,
On Wed, Aug 19, 2020 at 10:03:29PM +0700, Eugene Grosbein wrote:
> I have not such routes: the command "show ip route | include 0/1$" shows
> nothing.
> The interface Gi0/1 does not have any IP configuration itself, only its
> sub-interfaces have.
Do you have a subinterface with no "encaps dot1q ..." configured? That
would be "untagged" then.
Otherwise, ask the router - "debug arp" - and for each ARP request you
see it issue, check the routing whether it points directly to an
interface.
(And never believe what switches say about tagging vs. not)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ARP requests
Moin,
On Wed, Aug 19, 2020 at 09:40:43PM +0700, Eugene Grosbein wrote:
> Gi3/9 of the switch is actually the port connected to router's Gi0/1.
> So, the question remains same.
Check the routes on the router. If you have something which is pointing
directly to an interface ("ip route 0.0.0.0 0.0.0.0 gi0/1") it will
generate proxy-ARP requests for all destinations covered by that route.
Always use interface + gateway-IP unless this is a desired property.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ARP requests
Hi, On Wed, Aug 19, 2020 at 08:02:13PM +0700, Eugene Grosbein wrote: > Switch mirroring configuration is the following: > > monitor session 1 source interface Gi2/3 tx "tx"? This is "outbound to the router", not "from the router" gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] BGP - advertising default route to Branch offices
Hi, On Wed, Aug 12, 2020 at 08:20:39PM -0400, Yham wrote: > 2 - default-originate command under every BGP neighborship. I have 100+ > neighbors so configure this command for all. Peer-groups are an amazing invention. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Campus Network - Deployment mode of Perimeter Firewalls
Hi, On Mon, Aug 10, 2020 at 11:33:06PM -0400, Yham wrote: > Thanks for your comments. I kinda agree with you on avoid using transparent > mode however not clear why you wouldn't want your north-south traffic pass > through perimeter security devices (FWs). how would you protect your > network from outside if you don't have firewalls in the traffic path? I > have seen some enterprises use by-pass switches to go around the firewalls > in case of an unexpected failure from where firewalls can't recover. What is the point of a firewall in front of a web server? The web server should not have any services running besides "web", and these have to be available from the outside. Adding a firewall means "you put a device in front of it that can handle less load and costs more" - but where's the security gain? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Netflow/Sflow for "irrelevant" traffic?
Hi, On Thu, Jul 30, 2020 at 12:37:52PM +, Drew Weaver wrote: > So if a flow is less than the sampling rate it does not export anything, > I believe is what you are saying. No. If you happen to just not see a packet of that flow, it will not export anything. You can have a flow of 100.000 packets that all just happen to always be "one of the 499 out of 500 packets" that are not being looked at. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Netflow/Sflow for "irrelevant" traffic?
Hi,
On Thu, Jul 30, 2020 at 12:23:28PM +, Drew Weaver wrote:
> So just for a refresher if you are sampling lets say at 1:500 and lets say 1
> byte goes through an interface that is not intended to produce an export?
It's statistics: 1:500 says "only look at one packet in 500" - so it
will just not *see* this "1 byte" (with a very high propability).
> The exporting only happens if the amount of data is over a certain threshold?
> Does that threshold vary?
Not "data over threshold" but "did you see the packet or not"
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Rehosting a perpetual CSR1000V license
Hi, On Wed, Jul 22, 2020 at 09:44:44AM -0700, Seth Mattinen wrote: > As a small operator I've had a lot of effectively new off lease > equipment pass through my doors, and expiring license keys don't really > favor that. Works as designed. "We do not want you to re-use stuff that we're not making money on!". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco N540-ACC-SYS ipv4 routes
Hi,
On Thu, Jul 16, 2020 at 06:53:49PM -0400, Phil Bedard wrote:
> >The CRS made a lot of sense because we had a need for plenty of
> >non-Ethernet links, and both the MX and ASR9000 were too expensive on a
> >per-slot basis.
>
> Fair enough. Every vendor has gone through their own pain with
> the older midplane systems in having to swap out chassis multiple
> times to get to higher speeds. Thankfully with the newer fabric
> designs we've eliminated most of that.
But that's actually one of the things that alienates the "not megacarrier"
customers. There's perfectly working routers, they fall out of love,
new features are not added anymore, and you're expected to buy 32x400G
things when all you need are like "16x 10G".
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Somewhat quirky question regarding C6513
Hi, On Thu, Jul 09, 2020 at 04:54:51PM +0200, Mark Tinka wrote: > It had been a while since we run switches that big, but when it came > time to replace our C6880-X in some PoP's, we went with Arista's 7508E. I was about to suggest that, but the 7500 series is WAY deeper than the 6500s (like "80-85 cm" vs. "50 cm"). I'd still go for Aristas instead of Nexus. Spent two hours on the phone with Cisco TAC today, and 3 hours with Arista TAC yesterday. Arista case was open 5 days and is now already in engineering. Cisco case is open 8 months and TAC is still running in circles. No vendor is perfect, but Cisco is no longer even aiming for goodness. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Cisco N540-ACC-SYS ipv4 routes
Hi, On Thu, Jul 09, 2020 at 07:04:13AM +0530, Vikas Sharma wrote: > Also, processing power of ASR vs C 540 is very different, one with quard > core 1.2 GHz and another with 2.5 GHz, so I was also wondering if BGP > scanner process will be good with which. If 540 can take care of scanning > process!! BGP scanner process died like 10 years ago... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
Hi,
On Sat, Jun 20, 2020 at 07:42:31PM +0200, Mark Tinka wrote:
> On 19/Jun/20 17:26, Gert Doering wrote:
>
> We bought the C6880-X for our core switch back in 2014. It's still
> humming, running plain old IOS.
The 6880/6840 products were promising at that time, but the pricing made
it uninteresting. So we kept our 6506Es for a time...
> The upgrade path is Arista for this. I'm not sure what switching is
> doing over at Cisco, these days.
... and then went to Arista 7050SX2/SX3 for the "edge things" (small
routing table, lots of 10G/25G ports, small power draw, EVPN/VXLAN).
Nice stuff like the JSON RPC API, which is nice to work with and
amazingly *fast* (compared to JunOS commit times...). And, most important,
a good TAC and a company interested in listening to their customers.
I'm a bit annoyed that the 7050SX* do not have MPLS-P support (because
we have MPLS PEs that basically "live behind" the 7050SX, and now need
to have vlans *through* them, to reach a MPLS P router).
I do understand that the BRCM Trident is fairly limited wrt MPLS handling,
so Arista decided "better no MPLS than something which is not enough
for people" - unfortunately for us, because we only want "LDP and
single-label swap/pop", but I can accept the technical arguments to
some extent.
(As a side note, changing our network from EIGRP to OSPF for IPv4 did
not come for free, so I would have much preferred to stay in my self-
chosen vendor lock-in with Cisco. But Cisco has gone insane these days,
and new boxes like the NCS5500 come *without* EIGRP support. So they
really do not want us customers locked in...)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
Hi, On Fri, Jun 19, 2020 at 03:05:50PM +0200, Mark Tinka wrote: > On 19/Jun/20 14:50, Tim Durack wrote: > > > If y'all can deal with the BU, the Cat9k family is looking > > half-decent: MPLS PE/P, BGP L3VPN, BGP EVPN (VXLAN dataplane not MPLS) > > etc. > > UADP programmable pipeline ASIC, FIB ~200k, E-LLW, mandatory DNA > > license now covers software support... [..] > > I'd like to hear what Gert thinks, though. I'm sure he has a special > place for the word "Catalyst" :-). There's a special place in hell for people re-using the "Catalyst" brand name and then putting yearly renewable licenses on it. Or IOS XE. I'm not actually sure *which* BU is doing "Catalyst" these days, but we're so annoyed about Cisco these days that I haven't really looked at all these new and shiny products from all these new and shiny BUs with all these new and shiny operating systems in quite a while. I've been told Merak is very nice... if all you're interested in is "sell to Enterprise customers and make lots of cash". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Devil's Advocate - Segment Routing, Why?
Hi, On Thu, Jun 18, 2020 at 12:17:20AM +0200, Mark Tinka wrote: > Routers, in 2020, still ship with RIPv2. If anyone wants to use it (as I > am sure there are some that do), who are we to stand in their way, if it > makes sense for them? There's an argument for testability of the code base here... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
Hi, On Thu, Jun 11, 2020 at 01:17:55PM +0100, adamv0...@netconsultings.com wrote: > But running MPLS over IPv6 in addition to already running it over IPv4, Not "in addition to" but "to throw out the IPv4 part" :-) More relevant to strongly growing networks that do not need to roll out IPv4 to new parts, though. (If I had LDPv6 today, I wouldn't actually change the existing network today. But for the next round of rebuilding things, it would be something to consider...) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
Hi, On Wed, Jun 10, 2020 at 09:45:55PM +0300, Saku Ytti wrote: > I'm pretty sure that one or more of Mark, Gert or Tim are thinking > SR/MPLS IPv6 when they say SRv6? > > No one in their right minds thinks SRv6 is a good idea, terrible snake > oil and waste of NRE. SR/MPLS IPv6 of course is terrific. > > LDPv6 and SRv6 seem like an odd couple, LDPv6 SR/MPLS IPv6 seem far > more reasonable couple to choose from. I have my favorite. Oh. Indeed, sorry for being unclear here. SR/MPLS sounds like a good idea (reducing label state). SR/IPv6 does not sound convincing. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
Hi, On Wed, Jun 10, 2020 at 08:45:31PM +0200, Mark Tinka wrote: > On 10/Jun/20 20:10, Gert Doering wrote: > > > To be honest, I do not think we're going to buy any IOS XE gear in the > > foreseeable future. But if we did, LDPv6 would be nice to have - to get > > rid of IPv4 in the backbone network. > > We have LDPv6 working beautifully between IOS XR (6.4.2) and Junos > (17.4). But we can't make the core BGPv6-free because downstream > ASR1000's and ASR920's don't have it. > > So if you don't have IOS XE today, but have the others, then you're good > to go :-). We do have IOS XEs today (ASR920), and based on that, we're not going to buy new IOS XE devices any time soon. The amount of... strangeness... that this BU considers acceptable is... not. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] LDPv6 Census Check
Hi, On Wed, Jun 10, 2020 at 07:19:18PM +0200, Mark Tinka wrote: > Just want to sample the room and find out if anyone here - especially > those running an LDP-based BGPv4-free core (or something close to it) - > would be interested in LDPv6, in order to achieve the same for BGPv6? > > A discussion I've been having with Cisco on the matter is that they do > not "see any demand" for LDPv6, and thus, won't develop it (on IOS XE). > Meanwhile, it is actively developed, supported and maintained on IOS XR > since 5.3.0, with new features being added to it as currently as 7.1.1. To be honest, I do not think we're going to buy any IOS XE gear in the foreseeable future. But if we did, LDPv6 would be nice to have - to get rid of IPv4 in the backbone network. We do not intend to run SRv6 any time soon. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] ASR9001 ASR9901 IOS-XR IPv6 filtering
Hi, On Wed, Jun 10, 2020 at 02:21:55PM +0200, c...@marenda.net wrote: > 2. On the Neighbor Discovery ets stuff is src and dst allway link-lokal > or must I allow explicit the four pairs LL-LL LL-real real-LL real-real ? IPv6 ND sucks big time. You'll also see :: sources (DAD). This is what we have at DECIX: 20 permit icmpv6 fe80::/64 2001:7f8::/64 nd-ns 30 permit icmpv6 2001:7f8::/64 2001:7f8::/64 nd-ns ttl eq 255 40 permit icmpv6 2001:7f8::/64 2001:7f8::/64 nd-na ttl eq 255 90 permit icmpv6 any ff02::/64 nd-ns 100 permit icmpv6 fe80::/64 fe80::/64 nd-ns 110 permit icmpv6 any fe80::/64 nd-ns 120 permit icmpv6 any fe80::/64 nd-na 130 permit icmpv6 any host ff02::1 nd-na 140 deny icmpv6 any any nd-ns log 150 deny icmpv6 any any nd-na log 160 permit ipv6 fe80::/64 fe80::/64 170 permit ipv6 fe80::/64 ff02::/64 180 deny ipv6 fe80::/64 any ... (looking closer, I seem to have any-to-LLA nd-ns twice here... that is obviously not needed) You should be able to filter ND/NS by matching on TTL 255, but when we did this, we saw peer routers send out NS with lower TTLs - which is a violation of RFCs, but nobody seems to care... We do filter link-local to anything non-multicast / non-onlink - nobody should ever forward these, but we did see packets. > 3. will that ACL work on the mentioned devices in Hardware > or is it done in software slowing down everything ? This is fairly easy, XR will do things in hardware, or not at all. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3560E Migrating from a single uplink to a port-channel on a trunk port with several VLANs
Hi,
On Fri, May 08, 2020 at 05:28:04PM +, Drew Weaver wrote:
> Plan right now is to create the port-channel interface on both ends,
> duplicate the configuration from the existing interface and then plug in the
> 2nd cable.
>
> I expect that spanning tree will block the port-channel and nothing bad will
> happen.
>
> Then I will shut down the existing port which should change the port-channel
> from blocking to forwarding at this point I can just add the original
> interface to the port-channel.
The general plan is sane.
Now, there is spanning tree involved, so you'll see more or less downtime
still.
If you do rapid-pvstp (which I generally recommend), make sure that all
edge ports (= not linked to other switches) are properly tagged with
"spanning-tree portfast". Otherwise, they might see a "topology has
changed, re-learn port status" cycle, leading to downtime.
No idea about MST, won't touch that stuff with a pitchfork.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RPKI validation weirdness
Hi, On Fri, May 08, 2020 at 12:44:14PM +0200, Mark Tinka wrote: > On 8/May/20 12:24, Gert Doering wrote: > > > This is why you use a broker who understands their trade to facilitate > > the transfer. Ensure that such details are not overlooked. > > What are the chances these brokers know about IPv6? And that's just the > basic requirement to graduate to RPKI, and DNSSEC :-). If a broker doesn't know about that, I wouldn't use them. (I'm a bit picky anyway, because I tend to only trust people I've met and worked with for a while, and since there are two brokers among them that well understand RIR policies and all that - these are the ones I'd use and recommend :-) ) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RPKI validation weirdness
Hi, On Fri, May 08, 2020 at 11:42:51AM +0200, Robert Raszuk wrote: > See when you sign a block then sell this block without removing your RPKI > signature, then the block gets cutted into chunks and sold further - and no > one in this process of transaction chain cares about RPKI - this entire > story of using this for validation becomes pretty weak. And this is no > longer NOT-FOUND. You get false INVALIDs which some may apply to suppress > or drop. This is why you use a broker who understands their trade to facilitate the transfer. Ensure that such details are not overlooked. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working
Hi, On Mon, May 04, 2020 at 11:36:09AM +0200, Mark Tinka wrote: > Of course, all going over BGP :-). This is *not* funny. The work that IETF/IDR is doing these days is truly and deeply scaring me. "Hey, we have this nice reliable protocol to transport information from here to there. Why not add tons of different other things we want to be transported from routers to collectors, or between routers, to BGP, because, you know, we can?". Trying to understand what a BGP speaker is doing is difficult enough today. Or, for that matter, get an implementation right. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working
hi, On Thu, Apr 30, 2020 at 07:13:32PM +0100, Nick Hilliard wrote: > everything has its use. PWs have major problems loadbalancing over > multiple links. Also the complexity of mpls + associated control plane > is a drawback in situations. Sometimes vxlan provides the required > functionality. Why use a more complicated protocol when a simpler one > is a 100% match for your requirements? Which actually makes me wonder why I'm not ditching EVPN completely and going back to VXLAN with configured VTEPs on the Aristas - the system knows where it's peers are, and it MUCH MUCH simpler to figure out all the moving pieces... *sigh* (The idea behind using EVPN was twofold - one: it would interop with A9K. Ditch that. Two: if I add into the same VLAN/VXLAN mesh, I only need configure *that* node, and it will BGP-signal to all the other nodes "hey, I'm part of it!". OTOH, most affected VLANs will only ever see 2 or 3 clusters, and the provisioning knows which devices are part of it... meh) ((Now, if all these ugly hypervisors would actually speak EVPN/whatever, in a reasonably interoperable way, I could just leave the mess to them, and provide a default gateway in some place(s), not bothering with all this layer2 thinking at all. But that's not going to happen either)) Can I retire yet? gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working
Hi,
On Thu, Apr 30, 2020 at 01:14:12PM +0100, adamv0...@netconsultings.com wrote:
> > On Sun, Mar 29, 2020 at 11:52:03AM +0200, Gert Doering wrote:
> > > I'm trying to make EVPN via VXLAN encapsulation work between two
> > > ASR9001 (with the goal of eventually making it work between ASR9001
> > > and Arista boxes, but right now I'm failing ASR9001 <-> ASR9001
> > > already).
>
> Would it be feasible to go the EVPN over MPLS route? Arista might support
> some basic MPLS forwarding (most Data-Centre switches do).
Hah!
As in: the Trident 2+/Trident 3 boxes *could* do MPLS P, but Arista says
that their MPLS capabilities are too limited so they do not provide any
MPLS support for these boxes. Not sure if it actually could do enough
actual encap/decap for the MPLS PE bits required for EVPN/MPLS - but if
it can't even do P, no good asking.
The Jericho boxes can do "all of this", but given the price difference,
we run the "customer edge" on Trident boxes - no need for full tables
there, rarely a need for extra large buffers or detailed QoS ("these
links are never full").
OTOH, Trident 2+ does 802.1q<->VXLAN perfectly well, and T3 even does
"routed into VXLAN" without performance impact, so this is where the
journey is headed to. Whether we like it or not.
Now, as a side note: of course ASR9k does VXLAN with multicast underlay
and "MAC learning from the data plane" just fine, but *this* is not
supported on the Arista side. Of course.
Arista could statically configured VXLAN VTEP neighbours, but *that* is
not supported on the ASR9k side. Of course.
So, EVPN/VXLAN was the promise "hey, we have an IETF standard here, and
both vendors claim to support it". And of course some other BUs inside
Cisco actually support this. Yeah. (#include )
> Never understood this VXLAN nonsense in DC universe (not the comics), in SP
> space this was a solved problem and is a well-trodden path since ever -PWs,
> VPLS now EVPN (even with traffic engineering possibilities -you know the
> mice around elephant flows...)
> MPLS to DCs is my answer.
Unfortunately, vendors still think MPLS is something for people with
deep pockets... (like, Juniper charging tons of extra money for the
MPLS license for their QFX5k gear...)
I'm totally fine with MPLS... we've run that for like 10+ years with
lots of cludges around our 6500/sup720s... (like, looped ports from
the box to itself to be able to EoMPLS-away a single VLAN which is
also routed on the box itself)
In the end, I do not really care. The box config and the linkage
between "boxes in the same distributed VLAN" is coming from the
provisioning magic box, I just need to figure out which of the parts
actually work.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working
Hi, On Wed, Apr 29, 2020 at 07:16:29PM +0300, Saku Ytti wrote: > I think for Gert committing on such an old platform was matter of > density, no need for 9901 density, Right. 9001 is officially still supported, and while I could use a few more 10GE ports, it does what is needed in these POPs - namely, transport about ~6-8 Gbit/s (!!!) with a decent number of 10 Gbit/s ports (so we can go over 1 Gbit on each of them, even if the total throughput is not all that much), full BGP table, proper incoming anti-DDoS rate limiting (the usual reflective UDP crap). We're a small shop - our BGP edge is all 10Gbit/s, but due to "we want it distributed so no box has all the links" the total traffic in the box is much much lower than it could do - so the extra bang of the 9901 and the accompanying price tag makes it not very interesting. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working
Hi, On Wed, Apr 29, 2020 at 05:11:46PM +0100, Nick Hilliard wrote: > Gert Doering wrote on 29/04/2020 16:21: > > But anyway. In case someone stumbles across this thread in the archives - > > it's not implemented and not expected to work. > > now that this is documented, it's a feature, right? This is all just to save power consumption in the NPU! gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EVPN/VXLAN on ASR9001 - BGP announcements not working
Hi,
remember me...? Fighting with this "simple task" since quite a few weeks...
On Sun, Mar 29, 2020 at 11:52:03AM +0200, Gert Doering wrote:
> I'm trying to make EVPN via VXLAN encapsulation work between two ASR9001
> (with the goal of eventually making it work between ASR9001 and Arista
> boxes, but right now I'm failing ASR9001 <-> ASR9001 already).
... so, whatever I did, it wouldn't work. Unicast packets actually do
work (provided the B end is not using ESIs, in that case I can see them
in the "show evpn evi mac" table, but never in the hardware table), but
most prominently, flooding never worked in the
local AC --> VXLAN peers
direction (while everything in BGP and EVPN and etc. was displaying the
expected results).
So, long story short, TAC time. XR TAC engineer (very competent) did
not bother much with looking at my RDs and ESIs and what not, but looked
at NPU packet drops instead - and lo and behold, packet drops in the
"RSV_DROP_IPM4_ING_RTE_DROP" category, which could be identified as
"yes, these are the ARP packets that are not flooded".
After some more research, this is what came back today...
"... Typhoon supports VXLAN EVPN features that were introduced up to
6.2.2. Features that were introduced after 6.3.1 are not supported.
Ingress-replication bgp is not supported in Typhoon LCs"
Which is slightly annoying, given that this seems to be not documented
anywhere AND that the ASR9001 is still not EOLed (as far as my google
fu can find)...
But anyway. In case someone stumbles across this thread in the archives -
it's not implemented and not expected to work.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Rolling Back from IOS XR 64-bit to IOS XR OS
Hi, On Sun, Apr 26, 2020 at 02:02:45PM -0700, Vince wrote: > Anyone success with Rolling Back from IOS XR 64-bit to IOS XR OS, I have an > issue and my RSP880 stuck / hang when start booting the downgrade image. Have you tried turbobooting? That should always work (unless I totally misunderstand something). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Default Route recalculated every 60 seconds.
Hi, On Mon, Apr 20, 2020 at 08:54:27PM +, Bradley Ordner wrote: > Thanks Gert, I will now ask them to do packet capture on their side and see > if they are advertising this default to any other customer every 60 seconds. > > Something else I noticed, we only accept routes less than or equal to /18. I > noticed that many updates come in, for different prefixes. I can???t see how > the Internet could be that unstable unless there is something wrong with > their network. Wonder what is the norm when seeing so many prefixes change. The Internet is huge - 70.000 networks(!) connected together. Things are rebuilt and changed all over the place all the time, and links and devices fail and get repaired all over the time. So yes, there's a constant stream of BGP updates. Google for Geoff Huston. He's done a number of very good presentation on the dynamics of BGP updates over time. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Default Route recalculated every 60 seconds.
Hi, On Mon, Apr 20, 2020 at 09:36:55AM +, Bradley Ordner wrote: > They have told me they have no other issues with other customers and same > config, but this could be a bug between different IOS versions because I am > running IOS-XE and they may be running XR as they have a ASR9K. Strictly speaking, there is no "issue", except that the counter for "how old is the route?" on your side is being reset every minute. Packet forwarding works, routing is stable, no CPU churn. WRT "bugs between different IOS versions" - please read what I wrote before: frequent reannouncements of a single route *can not* be triggered by anything on your side. There is nothing in the BGP protocol which would enable this. (If it happens for *all* routes, it could be a soft reconfig request going awry, but this not what you see) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Swapping A9K-RSP's different versions
Hi, On Sun, Apr 19, 2020 at 08:22:05AM +0100, Mati Panos wrote: > Hope everyone is keeping well! > > We need to increase the memory on our A9K routers. They are currently > running a pair of A9K-RSP440-TR (6Gb). Is it possible to replace the > standby with a A9K-RSP440-SE(12Gb) and seamlessley switchover to the > standby so it becomes the active RSP? Any recommendations on how best to > do to this without downtime? They will use the same IOS-XR version If you search cisco.com for "A9K-RSP440 RAM upgrade" you'll get a page that, basically, says "remove the passive -TR, put int the first -SE, wait for it to sync up, then failover redundancy, then swap the other one". So it should be straightforward and supported. Haven't done it, never take my word on it, find the page yourself :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] STP on ASR9k
Hi,
On Sat, Apr 18, 2020 at 08:34:57PM +0100, adamv0...@netconsultings.com wrote:
> > We really like Arista. Yes, they can not do everything Cisco can, but the
> stuff
> > that they *do* has been really rock-solid for us (and the "oh, that does
> not
> > work" bits are not as surprising as with Cisco... ran into "no, you cannot
> have
> > STP for a VLAN with mixed tagged untagged ports on IOS XR" yesterday,
> > much to my dismay).
>
> They actually do have STP on XR? Why?
I'd say because their EVPN stuff wasn't finished yet :-)
> Yes ASR9k was meant as L2 switch initially, but then they changed their mind
> and turned it into a router, i.e. LAG. MC-LAG, BUM rate limiters and
> split-horizon groups in bridge-domains I'd consider as the right tools (or
> REP if pushed hard), but STP? I guess you found yourself between a rock and
> a hard place in your design.
Small POP, two ASR9001 for routed connectivity, redundant paths to
two switches that have 1GE customer connections. Customer has two
firewalls, that speak their sort of cluster redundancy protocol
("VRRP-ish", with a virtual MAC that moves around).
Customers are not to be trusted, so STP on the customer ports is a must.
Switch hardware / SFP+ can break, so the switches can lose their
interconnect - in which case, split brain, unless you do bridge-domain
"ring" through the two ASRs. And then you have a ring, and want STP
to break flooding.
(But indeed, for that topology, split-horizon groups might actually
be a better answer. Need to revisit our deployments to see if I
can generalize our tooling to avoid STP in simple topologies like
this one... in other places, we've managed to totally go away from
STP already except as "protect customer ports against short-circuiting",
doing everything with MLAGs on the Aristas. MC-LAG on the ASR9001
eats too many ports...)
Thanks for giving me something to think about :-)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] RPKI extended-community RFC8097
Hi,
On Sat, Apr 18, 2020 at 05:24:27PM +0200, Lukas Tribus wrote:
> On Sat, 18 Apr 2020 at 16:24, Gert Doering wrote:
> > On Sat, Apr 18, 2020 at 02:13:07PM +, Ben Maddison wrote:
> > > I meant "dumb" as in "I painted the life-saving emergency stop button
> > > green and mounted it on a green wall behind a locked fire-proof door in
> > > a different building, which was dumb"
> >
> > Very dumb indeed :-) - in a very british tradition of fine understatement.
> >
> > I do not very much like IOS XE anyway, and my classic IOS boxes that do
> > speak BGP are too old for RPKI support ("no, you can't have new control
> > plane features, if we think your hardware is old") and will retire in
> > the next few months anyway.
> >
> > Yes, you Sup720 and Sup2Ts, this is you. Out!
>
> You should really upgrade to 7600 then (but 7200 or ME3600 will work
> too, slightly different platforms of course) ;)
7600, really? This was the first Cisco BU to try the "how much can
we annoy customers before they go and buy elsewhere" stunt. And no.
And no, the ME3600-now-ASR920 is not exactly what I'd call "trustworthy
routers". Nice metro/mpls switches.
> FWIW: Mark is trying to get the fix as far back as 7200 series:
>
> https://mailman.nanog.org/pipermail/nanog/2020-March/107009.html
I didn't know that 7200s actually had any sort of RPKI support, given
that they are all long EOL and much more interesting bugfixes have
never come (like the L2TP crash bugs affecting LNSes).
But anyway, my last few 7301s that do "close to full table" BGP have
no eBGP sessions anymore, and will go into retirement soon as well.
As for "what do you use instead?" - for the edge stuff with no full
tables, 6500s are being replaced by Arista 7050 (T2+/T3), "full BGP"
stuff is being replaced by ASR9k, and testing Arista 7280R now.
We really like Arista. Yes, they can not do everything Cisco can,
but the stuff that they *do* has been really rock-solid for us
(and the "oh, that does not work" bits are not as surprising as with
Cisco... ran into "no, you cannot have STP for a VLAN with mixed
tagged untagged ports on IOS XR" yesterday, much to my dismay).
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
