Re: [c-nsp] ACL sometimes logging dest_IP sometimes nexthop - why?

Hi, On Wed, Jun 19, 2024 at 08:44:20AM +0300, Hank Nussbacher via cisco-nsp wrote: > RP/0/RSP0/CPU0:2024 Jun 19 05:12:47 : ipv4_acl_mgr[343]: > %ACL-IPV4_ACL-6-IPACCESSLOGP : access-list log-traffic (10) permit udp > 192.114.102.104(55638) -> 192.0.2.2(53), 1 packet You might actually have a clie

Re: [c-nsp] BGP routes disappearing

Hi, On Mon, Jun 10, 2024 at 11:05:18AM +0300, Hank Nussbacher via cisco-nsp wrote: > If the feed sets the IP to 192.0.2.2 then the BGP routes appear in the > routing table.  If I then change the IP address on interface > GigabitEthernet0/0/0/43.1 to 192.0.2.2 then the routes disappear as well > af

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 6

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

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 >

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

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

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,

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 yea

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 eithe

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

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

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. The

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 > ASR10

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 licensi

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

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 use

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

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 ou

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

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

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

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): >

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