Re: [c-nsp] sup2T software & release notes have hit
* Simon Leinen: > Thanks for the heads-up! There's some more technical information about > the Supervisor 2T in the White Papers section: > > http://www.cisco.com/en/US/customer/products/hw/switches/ps708/prod_white_papers_list.html Hmm, this redirects to a login page for me. Is Cisco's technical documentation no longer publicly available? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] Best practice for CAM and ARP aging timers
> have others observed unicast flooding in topologies > without asymmetric traffic flows but with mismatched ARP/CAM timers? I've seen them with default timers. I don't know if they were mismatched. There is a feature called unknown unicast flood blocking (UUFB). It might be available for your platform, too. ___ 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] Cogent IOS upgrade == BGP-3, "update malformed"
* Zoe O'Connell:
>> 729078: Aug 22 16:21:39 MDT: %BGP-3-NOTIFICATION: sent to neighbor A.B.C.D
>> 3/1 (update malformed) 21 bytes 31FE420C 31FE58C8 124683E8 0206CC67 00
>> 729079: Aug 22 16:21:39 MDT: BGP: A.B.C.D Bad attributes
>> 0060 0200 4140 0101 0040 020C 0205 00AE 0CB9 235A
>> 2046 5BA0 4003 0426 6532 7580 0404 5DE8 C008 0800 AE52 0800 AE55 FD31
>> FE42 0C31 FE58 C812 4683 E802 06CC 6700 0002 1854 1608 1854 1609
5BA0 suggests its related to 32 bit ASNs. We've got the prefixes in
our table, apparently with a proper 32-bit ASN:
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
41698 3320 1299 8262 196930
193.227.124.197 from 193.227.124.197 (193.227.124.128)
Origin IGP, localpref 100, valid, external, best
Community: 3320:1276 3320:2010 3320:9020
Last update: Thu Aug 19 19:30:07 2010
BGP routing table entry for 84.22.9.0/24
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
41698 3320 1299 8262 196930
193.227.124.197 from 193.227.124.197 (193.227.124.128)
Origin IGP, localpref 100, valid, external, best
Community: 3320:1276 3320:2010 3320:9020
Last update: Thu Aug 19 19:30:07 2010
--
Florian Weimer
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
___
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] Which IP's belong to AS1234?
* Andy Saykao: > This might be a silly question but is there a tool somewhere that will > give me a list of IP's that are owned by a particular AS. > > As an example, I might want to know which IP blocks belong to AS1234? Run this: show ip bgp regexp _1234$ on a router in the DFZ. (I get a single prefix, 193.110.32.0/21, right now.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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 Cease - Connection collision resolution
* Paul Stewart: > So, I've discovered that 6/7 means "Connection collision resolution" - does > anyone know what that means in English? ;) In general, it means that both peers successfully established a TCP connection, and one connection was closed. This happens from time to time and does not indicate a problem. (Or do you mean what it means for this specific IOS version? Sorry, in this case I have to pass.) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] IPv6 Subnetting - Service Provider
* Bob Snyder: > One issue we ran into was that not all the networking gear we had > could support /126. The vendor's (not Cisco) immature support for > IPv6 could only understand the concept of /128 loopbacks and /64 > subnets. Subnets smaller than /64 containing (conceptually) global unicast addresses are not allowed per the IPv6 addressing architecture RFC. So it's just another case of vendors got bitten by RFCs that don't match customer requirements. 8-/ -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] Dreaded FIB Exception on Sup2
* Rich Davies: > Has anyone ever utilized Unicast RPF (reverse path forwarding) to help > mitigate this limitation on the SUP2's? I have also ran into the same > limitation with our SUP2's (full BGP routing table, multiple peering > sessions) and I have read that enabling Unicast RPF would help temporarily > alleviate the TCAM memory being exhausted On a MSFC2/PFC2, enabling uRPF cuts the number of available routes in half, so it makes things only worse. Don't know about more modern MSFCs, sorry. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] Dreaded FIB Exception on Sup2
* Gert Doering: > On Thu, Sep 04, 2008 at 02:05:54PM +0200, Florian Weimer wrote: >> Do you mean the filters based on RIR minimum allocations? From time >> to time, someone who should now better announces something smaller >> without the covering aggregate, > > So what? They do not want your traffic, obviously... But your customers might be interested in theirs. To some extent, RIR minimum allocation filters trade FIB resources for operator resources. Desparate attempts at traffic engineering are certainly not restricted to those who have no traffic to deal with. 8-/ -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] Dreaded FIB Exception on Sup2
* Oliver Dewdney: > Do you need full routing tables? Jon Lewis emailed a week ago about > how to reduce the table by filtering the bgp feeds to get the table > to fit. I think that the routing/connectivity should be fine for a > hosting provider. > > http://jonsblog.lewis.org/ Do you mean the filters based on RIR minimum allocations? From time to time, someone who should now better announces something smaller without the covering aggregate, so this requires some maintenance. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] 3560 ACL performance?
* rendo: > is there any exact/rough number of acl which doesn't impact the cpu? > or how can we check/make sure that the cpu will not be impacted if the > traffic increasing? According to the docs, if you run it in the router profile, the ACL TCAM has 1,000 entries. There should be a (hidden) command to dump the TCAM contents, so you can check how your ACLs are compiled and project TCAM utilization according to that. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] IOSW vs JunOS
* Tom Storey: > I notice Cisco poked at Junipers ScreenOS... > > Cisco has/had CatOS, and has PIX and ASA operating systems, which look > and feel completely different to IOS, so they dont neccessarily get > off the hook that easily. :-) And the VPN Concentrators had their own software line. I learnt that the hardware while scripting the Telnet interface: It tended to lock up the device after a couple of session (even if those were properly terminated). ___ 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] Wanting to learn Juniper...
* Jonathan Crawford: > I do have to agree with Ben on this one... shutdown/negation of > shutdown is one of the last things I would say is > counter-intuitive... with JunOS the equivalent would be "deactivate > interfaces ge-0/0/0" to shutdown ge-0/0/0. They are active by > default when you create the entries for them and commit, but to > activate a deactivated... it is just "activate interface ..." Uhm, no. A deactivated configuration item is considered not to be present in the configuration at all, which means you cannot reference that interface anywhere else in the configuration (that would be an error that prevents you from committing the change). If you want to shut down an interface (while keeping it in the configuration), you need to disable it, and the equivalent of "no shutdown" in that sense is "delete disable". Talk about intuitive... -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] OT: Check Point v Cisco PIX (ASA 5500 Series)
* A. L. M. Buxey: >> for a firewall, not sending an RST for a denied connection, isn´t it >> the "Right Thing" to do? > > ah, the perennial DROP or REJECT question. Not really. Faking the RST with the address of the target doesn't give you any hint what's rejected the connection attempt. I know that some people do not want to leak that data, but it's absence makes debugging quite hard. -- Florian Weimer<[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ 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] Prepare for router Wednesday
* Gert Doering: > What they are *not* doing is "post security advisories every few weeks > for things that are not (yet) known out in the wild". Because when they > do that, people *will* go out trying to find the exploit, and then everybody > has to scramble to upgrade, multiple times a year. This is one precondition for creating a market for intelligence derived by comparing subsequent IOS versions. Certainly an interesting development. ___ 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/
