Re: [c-nsp] IO 7200 GE Improve Performance and help with the CPU Load?
On Wed, Jun 03, 2009 at 07:23:47PM +0200, Gert Doering wrote: On Wed, Jun 03, 2009 at 11:10:47AM -0430, Juan C. Crespo R. wrote: That's great but the IO7200GE could help with the cpu load? *NO*. There is no intelligence on the IO board. Packets go to the CPU. If the CPU is loaded, it doesn't matter where the packets are coming from. unless pushing all the frames to one interface causes reduced CPU time spent servicing interrupts from interrupt coalescing. -- bill ___ 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] SoO causing 1-member update groups
i don't run any MPLS or anything like that, so i decided to steal the
SoO ext community for use as a generic which colo was this route
originated from/learned in community. the fact that it pretty printed
it on one line in the CLI had something to do with it.
anyways, after adding it on one of my routers, a previously 20 member
update group became 20 independent update groups all w/ the same SoO
community set. and that's my question: why would all of these become
independent update groups? is it because the loop protection changes the
outbound logic such that messages can't be replicated?
also, some of these displayed in the update-groups as:
Site-of-Origin is 0x0:0:0 (2 different update groups)
Site-of-Origin is 0xEF43:8653:1627824172 (5 different update groups)
Site-of-Origin is 0xD0D:3341:218959117 (4 different update groups)
when the only thing that was set was:
Site-of-Origin is SoO:36692:2
why does adding an external community to a route (via a route-map)
impact the neighbor itself? i realize in later versions of IOS this
command was added to the per-{neighbor,peer-group,peer-policy} stanzas.
i guess that's what i get for trying to steal a special-use community
for my own usage. i just didn't expect the update group madness (they
were all set to the same SoO) or the corruption.
i'm just curious about all of this, it didn't have any operational impact.
-- bill
p.s. just for kicks, i ran 'clear ip bgp update-group', which according to
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpdpg.html
Clears BGP update membership and recalculates BGP update-groups.
but it actually reset all the neighbors themselves. yay docs.
___
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] bgp multipath-relax + dmzlink
config: bgp bestpath as-path multipath-relax bgp dmzlink-bw neighbor aa.bb.cc.73 dmzlink-bw neighbor xxx.yyy.zzz.77 dmzlink-bw interface bandwidth settings: rtr1#show ip route aa.bb.cc.73 | i direct * directly connected, via GigabitEthernet0/0.5 rtr1#show int gi0/0.5 | i BW MTU 1500 bytes, BW 9000 Kbit, DLY 10 usec, rtr1#show ip route xxx.yyy.zzz.77 | i direc * directly connected, via GigabitEthernet0/0.3 rtr1#show int gi0/0.3 | i BW MTU 1500 bytes, BW 55000 Kbit, DLY 10 usec, rtr1# bgp shows the proper DMZ-link BW: rtr1#show ip bgp 4.23.94.0 [...] 2914 7018 46164 xxx.yyy.zzz.77 from xxx.yyy.zzz.77 (129.250.0.19) Origin IGP, metric 0, localpref 100, weight 1, valid, external, multipath Community: 2914:420 2914:2000 2914:3000 36692:10210 no-export DMZ-Link Bw 6875 kbytes 701 7018 46164 aa.bb.cc.73 from aa.bb.cc.73 (137.39.2.70) Origin IGP, metric 0, localpref 100, weight 1, valid, external, multipath, best Community: 36692:10210 no-export DMZ-Link Bw 1125 kbytes here's the problem: rtr1#show ip route 4.23.94.0 Routing entry for 4.23.94.0/23 Known via bgp 36692, distance 20, metric 0 Tag 701, type external Last update from aa.bb.cc.73 00:24:40 ago Routing Descriptor Blocks: * xxx.yyy.zzz.77, from xxx.yyy.zzz.77, 00:24:40 ago Route metric is 0, traffic share count is 1 AS Hops 3 Route tag 701 aa.bb.cc.73, from aa.bb.cc.73, 00:24:40 ago Route metric is 0, traffic share count is 10 AS Hops 3 Route tag 701 the traffic share count is the inverse of what it should be (1:10 when it should be 7:1). this is confirmed by cef: rtr1#show ip cef 4.23.94.0 int 4.23.94.0/23, epoch 0, RIB[B], refcount 5, per-destination sharing sources: RIB feature space: IPRM: 0x00018000 ifnums: GigabitEthernet0/0.3(14): xxx.yyy.zzz.77 GigabitEthernet0/0.5(15): aa.bb.cc.73 path_list contains at least one resolved destination(s). HW not notified path 63DC37C4, path list 502C51E0, share 1/1, type recursive nexthop, for IPv4, flags resolved recursive via xxx.yyy.zzz.77[IPv4:Default], fib 2A195DFC, 1 terminal fib path 28F39760, path list 28ACD5A8, share 0/1, type adjacency prefix, for IPv4 attached to GigabitEthernet0/0.3, adjacency IP adj out of GigabitEthernet0/0.3, addr xxx.yyy.zzz.77 5038CE40 path 28F3A664, path list 502C51E0, share 10/10, type recursive nexthop, for IPv4, flags resolved recursive via aa.bb.cc.73[IPv4:Default], fib 2026A89C, 1 terminal fib path 63DC5360, path list 502C6E90, share 0/1, type adjacency prefix, for IPv4 attached to GigabitEthernet0/0.5, adjacency IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 output chain: loadinfo 63DBB918, per-session, 2 choices, flags 0003, 126665 locks flags: Per-session, for-rx-IPv4 11 hash buckets 0 IP adj out of GigabitEthernet0/0.3, addr xxx.yyy.zzz.77 5038CE40 1 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 2 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 3 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 4 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 5 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 6 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 7 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 8 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 9 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 10 IP adj out of GigabitEthernet0/0.5, addr aa.bb.cc.73 5038CFC0 s.. is it possible to get working unequal load sharing across two different ASNs? i wouldn't need the hidden 'bgp bestpath as-path multipath-relax' if they were the same ASN, but if they were the same ASN i wouldn't be trying to meet different target commit rates. i tried to simply flip the bandwidths to get what i want, but that made things even worse: 2914 7018 46164 xxx.yyy.zzz.77 from xxx.yyy.zzz.77 (129.250.0.19) Origin IGP, metric 0, localpref 100, weight 1, valid, external, multipath Community: 2914:420 2914:2000 2914:3000 36692:10210 no-export DMZ-Link Bw 1250 kbytes 701 7018 46164 aa.bb.cc.73 from aa.bb.cc.73 (137.39.2.70) Origin IGP, metric 0, localpref 100, weight 1, valid, external, multipath, best Community: 36692:10210 no-export Routing entry for 4.23.94.0/23 Known via bgp 36692, distance 20, metric 0 Tag 701, type external Last update from aa.bb.cc.73 00:00:33 ago Routing Descriptor Blocks: * xxx.yyy.zzz.77, from xxx.yyy.zzz.77, 00:00:33 ago Route metric is 0, traffic share count is 1 AS Hops 3 Route tag 701 aa.bb.cc.73, from aa.bb.cc.73, 00:00:33 ago Route metric is 0, traffic share count is 48 AS Hops 3 Route tag 701 i set the bandwidth on the 2914 link to be 100:1 the
Re: [c-nsp] IOS IPv6 CEF adjacencies on 12xxx
N.B. it's been a half-decade since i've touched a cisco 12k. On Tue, Dec 09, 2008 at 06:15:49PM -, David Freedman wrote: ra#sh ipv6 int tun0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C316:9EE rb#sh ipv6 int tun0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C316:9ED Also, from the perspective of CEF, all seems to be ok on the surface: ra#sh ipv6 cef tun0 2001:DB8:B::/48 nexthop FE80::C316:9ED Tunnel0 ^^ 2001:DB8:1::/126 attached to Tunnel0 rb#sh ipv6 cef tun0 2001:DB8:A::/48 nexthop FE80::C316:9ED Tunnel0 ^^ should be FE80::C316:9EE if this was a paste-o, ignore this mail 2001:DB8:1::/126 attached to Tunnel0 ra#sh ipv6 cef exact-route 2001:db8:a::1 2001:db8:b::1 2001:DB8:A::1 - 2001:DB8:B::1 interface Tunnel0 rb#sh ipv6 cef exact-route 2001:db8:b::1 2001:db8:a::1 2001:DB8:B::1 - 2001:DB8:A::1 interface Tunnel0 **BUT** if you dig deeper, you find that this isn't the case at all: ra#execute-on slot LANCARD sh ipv6 cef exact-route 2001:db8:a::1 2001:db8:b::1 2001:DB8:A::1 - 2001:DB8:B::1 interface Tunnel0 Adjacency is incomplete so not cef switched ra#execute-on slot WANCARD sh ipv6 cef exact-route 2001:db8:a::1 2001:db8:b::1 2001:DB8:A::1 - 2001:DB8:B::1 interface Tunnel0 Adjacency is incomplete so not cef switched but this message does not appear on rb guess: since rb doesn't point to FE80::C316:9EE there's no adjacency to be incomplete. does 'sh ipv6 cef unresolved' show anything? i'm hitting the limits of my knowledge. So, it looks like the lack of adjacency is the cause, before I go open a TAC case (and get told to clear dCEF tables/ reboot linecards) , is there anything non-invasive I could try to debug/resolve this? how are RA,RB getting routes for 2001:DB8:A::1 and 2001:DB8:B::1? if dynamically, try static. if static, try a routing protocol. just to mix things up. :) a pair of cisco 7301s, albeit running GRE and not ip6ip (sorry) rtr1.nshow ipv6 int tun1003 | i link IPv6 is enabled, link-local address is FE80::217:FFF:FE1C:BC1B rtr1.nshow ipv6 cef tun1003 :0:BBF:1::1/128 nexthop FE80::217:FFF:FE07:2C1B Tunnel1003 [... other learned networks with the same output ...] rtr1.nshow ipv6 int lo0 | i subnet :0:BBC:1::1, subnet is :0:BBC:1::1/128 rtr1.nshow ipv6 cef exact-route :0:BBC:1::1 :0:BBF:1::1 :0:BBC:1::1 - :0:BBF:1::1 = IPV6 adj out of Tunnel1003 rtr1.n rtr1.pshow ipv6 int tun1003 | i link IPv6 is enabled, link-local address is FE80::217:FFF:FE07:2C1B rtr1.pshow ipv6 cef tun1003 :0:BBC:1::1/128 nexthop FE80::217:FFF:FE1C:BC1B Tunnel1003 [... other learned networks with the same output ...] rtr1.pshow ipv6 int lo0 | i subnet :0:BBF:1::1, subnet is :0:BBF:1::1/128 rtr1.p rtr1.pshow ipv6 cef exact-route :0:BBF:1::1 :0:BBC:1::1 :0:BBF:1::1 - :0:BBC:1::1 = IPV6 adj out of Tunnel1003 rtr1.p unless your output from above is a paste-o, it looks like the link-local addresses aren't being resolved properly between RA and RB at your end. in my scenario, the output of 'sh ipv6 cef' corresponds to the link-local address of the tunnel at the far side. however, i both don't have attached to TunnelX and the resolution through that in my cef tables because i use unnumbered ipv6 interfaces and run ospf3 across them. ipv6 address autoconfig ipv6 unnumbered Loopback0 maybe instead of the /126 you could try using unnumbered loopbackX. -- bill p.s. 12.2(31)SB11, if it matters ___ 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] Load-sharing between two routing protocols with same administrative distance?
On Sat, Nov 15, 2008 at 10:09:53AM +0100, Christian Meutes wrote: redistribute routes from one protocol into another and use route-maps to change the metrics and route 'type' (protocol dependent) such that the protocol considers them equal cost. the usual warnings about route redistribution apply: using tags so loops don't occur and taking care not to redistribute too many routes. wont work in most cases. Routes redistributed from IGP to BGP are better than routes learned from eBGP or iBGP - vice versa routes redistributed from BGP to IGP (OSPF, EIGRP ie.) are seen as external and will loose in route decission if the IGP prefix is native/internal (will work if route is first learned with IGP because local redistributed routes in BGP are better). In the second case you can change metric and metric-type on redistribution to IGP and ecmp could take place then but if the prefix is first learned from BGP and then from IGP - BGP wins and the OSPF prefix can't be used for load-sharing inside of the ASBR. Route selection in these cases is higly depending on timeing and is something I wouldnt recommend. any method that tries to equate two different routes from different protocols is going to be messy and require tweaking of origins, metrics, and/or distances(!). i wouldn't recommend doing any of this, was just suggesting a way to do what the OP was asking. -- bill ___ 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] Load-sharing between two routing protocols with same administrative distance?
On Fri, Nov 14, 2008 at 04:02:40PM -0200, Everton da Silva Marques wrote: Two routing protocols, Same administrative distance? http://www.internetworkexpert.org/2007/12/31/two-routing-protocols-same-administrative-distance/ I am wondering: any hint on how to work-around such a behavior (if at all possible) ? redistribute routes from one protocol into another and use route-maps to change the metrics and route 'type' (protocol dependent) such that the protocol considers them equal cost. the usual warnings about route redistribution apply: using tags so loops don't occur and taking care not to redistribute too many routes. -- bill ___ 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] Recommended Cisco boxes for a small multihoming solution?
On Thu, Nov 13, 2008 at 11:52:29AM +0100, Magnus Eriksson wrote: The setup currently uses 2 Juniper M5 but those are in dire need of refresh. i realize this is a cisco list, but the reason i make this suggestion is that it'd be easier to copy your configuration to what's already junos than port to IOS: look into the juniper j-series: http://www.juniper.net/products_and_services/j_series_services_routers/index.html even the lowest end device (w/ 1GB of memory from crucial.com or others) can do what you're asking and w/ discount will be well below the other solutions mentioned in this thread. even if your M5s have service PICs, those are emulated in software on that platform. What is the appropiate Cisco boxes to go for? Do I need any memory upgrades etc? others have mentioned the 7301/7201/7200-NPE-G2/ASR100x and those are fine choices as well. i don't know if i'd go for the 28xx/38xx models mentioned unless my budget was severely constrained or if i knew traffic was never going to grow. -- bill ___ 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] Network Management System
On Thu, Oct 23, 2008 at 08:42:16PM +0800, Daniel Hooper wrote: The only good NMS is the one you write yourself. also the most expensive. ome of the things you'd expect from an NMS for a service provider: [...] * ACL's and permissions to manage who can change / see what. [...] * Integration with a help-desk ticket tracking system the rest of the items you listed have been adequately covered in the archives. for these two remaining components, look into Crowd and JIRA (respectively) from Atlassian. Crowd can aggregate multiple authentication sources (LDAP, Active Directory, etc.) and provide AAA lookups for all your existing applications (via apache plug-ins or XML-RPC interfaces for $language) and/or any custom. JIRA is a great ticketing system - very powerful, extensible, etc. when used with Crowd you could base the user back-end on both your customer database and your employee database w/o actually merging them. if these databases aren't reachable via LDAP you may need to write some java code to do lookups against the data. the interface (in the OOP sense of the word) is well defined. in the end, if the FOSS community wants One All Encompassing NMS, an organization (e.g. ISC) will have to step up and gather requirements, funding, developers, etc. all of the existing open source systems with such a for-profit corporate backer that are financially supported by support and/or development contracts. priorities for integration and collaboration with other systems (plug-ins) are based on profit. i have nothing against such systems, but in my observations they just end up being specialized (monitoring or data visualization or statistics), limited to a handful of vendors, trailing behind bleeding edge devices, and/or targeted to 1-200 devices OR 10,000-100,000 devices but not much in-between. there's so much quality open source tools and technology out there, in some cases rivaling that of their commercial counterparts, but nothing really weaves it all together. -- bill ___ 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 match local IP address?
On Tue, Oct 21, 2008 at 10:36:04PM +, Marko Milivojevic wrote: Here, I had a few minutes to play in the lab: router bgp 100 address-family ipv4 redistribute connected route-map rc no auto-summary no synchronization exit-address-family ! ip prefix-list AAA seq 5 permit 10.0.0.0/8 ge 24 le 24 ! route-map rc permit 10 match ip address prefix-list AAA set community no-export ! [..] R1#sh ip bgp 10.0.0.0 BGP routing table entry for 10.0.0.0/24, version 8 Paths: (1 available, best #1, table Default-IP-Routing-Table, not advertised to EBGP peer) Flag: 0x8A0 Not advertised to any peer ^^ Local 0.0.0.0 from 0.0.0.0 (10.3.0.1) Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best Community: no-export i believe the OP wants to advertise these prefixes to his eBGP neighbors w/ no-export set. this way, his provider(s) have the more specifics for each site and his larger prefix is advertised to the world at large. ``A Framework for Inter-Domain Route Aggregation'' http://www.ietf.org/rfc/rfc2519.txt hence, NO_EXPORT must be set on the outbound route-map of the neighbors. the OP could tag the routes or add his own local community and use an outbound route-map to set NO_EXPORT on the announced prefix. -- bill ___ 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 only on ingress and HSRP setup
On Thu, Oct 16, 2008 at 10:55:29AM +, Borg Tinderne wrote: Raw netflow is a box centric view of network traffic,the few netflow display products I have played with over the last decade or so continue with this box-centric view , can't comment on nfsen. As interesting as a box-centric view is,?? I generally find I want a network-centric view of network traffic,?? so post processing of flow data with something ,??for me this has been RYO, so??choose your own poison ( perl / sql / tcl??/ awk ..??)??.?? w/ flow-tools you can write flow-nfilter such that you aggregate networks into abstractions and tag them. then you generate your rrd (or whatever) by-tag instead of by-host. not hard. - bill ___ 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] Conditional BGP
On Tue, Sep 23, 2008 at 09:23:16AM -0500, James Slepicka wrote: they both wish to use us as a backup provider and wish to ONLY use our network if their primary provider (Cogent) is down. I'm currently doing this with Cogent and another provider. I get default routes from both and simply prepend my AS a few times on the backup connection. In your situation this would mean that all of the config is on the customer side. e.g.: router bgp ... neighbor backup route-map prepend_outbound out neighbor x.x.x.x peer-group backup ... route-map prepend_outbound permit 10 set as-path prepend avoid manual peer-groups.. templates using 'inherit peer-(session|policy)' are more flexible and easier to change later. if your neighbors have the same outbound policy, they'll get stuffed into the same update group w/o the peer-group. and to answer the OP question: this is a question of local policy for the customer. give them lots of options. let them use weight (and/or localpref, if they have multiple routers in the AS) to determine egress. give them communities if that will help their route selection decision making. i wouldn't go much further than the previous suggestions of 'full routes', 'customer routes', 'default origination' unless $customer is paying you to rig something up or you're feeling particularly nice. finally, 'down' can mean a lot of things and your customer needs to figure out if that means 'interface loss', 'loss across cogent' (frequent occurrence), 'latency spike', etc. in IOS, using IP SLA and a track object is probably the best way to implement those checks. -- bill ___ 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] NPE G1, CEF and ACLs and high CPU
[ reading through quickly, just some ACL pointers.. ] On Mon, Sep 08, 2008 at 09:15:31PM +0100, Mateusz B?aszczyk wrote: ! deny rogue IPs (it is interesting how many catches are here) deny ip 10.0.0.0 any deny ip 192... any deny ip host 0.0.0.0 any this breaks PMTUD. icmp messages from poorly addressed routers still need to get back to your hosts. etc ! deny spoofing us... deny ip OURBLOCK1 any deny ip OURBLOCK2 any move to the top. ! pings and traceroute permit icmp any any either permit the specific ICMPs required for end to end communication to work and permit the rest after your anti-spoof, or just move this towards the top. permit udp any any range 32xxx 34xxx rarely used, moved towards the bottom. ! transit providers permit tcp host THEM1 host US1 eg bgp permit tcp host THEM1 eq bgp host US1 ! Internet eXchanges - bgp/msdp permit tcp THEM2 WCARD2 host US2 eg bgp permit tcp THEM2 WCARD2 eq bgp host US2 deny ip any US1 deny ip any US2 rarely used, move towards bottom. consider removing the port-specific portions and see if you can get your ISP to use the TTL hack. ! some legacy stuff permit ip any host XXX move towards the top. ! deny access to infrastructure deny ip any NETWORK_1 ... deny ip any NETWORK_N hack sometimes, you can null route these blocks and use policy route-maps that set next-hop for your local device and/or management networks that allow the forwarding plane take care of discarding these /hack permit ip any any and here's where the majority of your traffic matches - at the bottom. this will kill performance. consider the trade-off of adding a: permit tcp any any established towards the top of your config. that rule will catch the majority of most networks' traffic. your deny rules below will still prevent SYN packets from getting through to your infrastructure space. yes, your 'infrastructure' will be open to ACK floods and other such things, but you can deploy other measures to assist with that. for example: ACLs on the interfaces facing your management network instead. also, if you run a service that represents the bulk of your traffic on that device, add a short-circuit rule for that service higher at the top, even if a rule with wider reach allows the same later. any significant advantage over entry-level 6500/7600? 6500/7600 will be way less order dependent and you'll be able to have much longer ACLs. in my experience, on software platforms 99% of your traffic should either be permitted or denied in the first 5 or so rules or you're going to see serious performance problems. consider using 'access-list compiled' if your platform/IOS support it. distribute your ACLs as much as possible. take a multi layered approach. know your device's strengths and weaknesses when it comes to filtering and exploit those. -- bill ___ 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] debugging stack corruption
On Tue, Aug 19, 2008 at 10:41:05AM -0400, Rodney Dunn wrote:
How are you getting this output?
ssh rtr1
en
sh stacks
If you ssh/telnet to it and run the command do you get th esame output?
it is not signal noise (serial spew, ip corruption, etc).
That's not stack corruption to me.
i'll try and profile the exec process, but i'm not so good w/ profiling
and tracing w/o at least symbols.
there is also the matter of the 30% solid EXEC process. however, the
switch that device is attached to (both in network and by serial via
rtr1:auxsw1:cons) is exhibiting the same behavior. it could be a feedback
loop on the serial connection, but i've tried turning all of that down
and still no relief. the jump occurred to both at the same time.
it could just be corruption in the display, but the CPU spike is what
made me investigate in the first place.
-- bill
rtr1#show stacks
Minimum process stacks:
Free/Size Name
[...]
3360/6000
d^\ytd^[^P^Ld^\zTd^[`Dd^[I$d^\^[Td^[T^Dd^\y^Dd^\^P[EMAIL
PROTECTED]d^\^B,[EMAIL PROTECTED])$d^[pLd^[|^\d^\
,d^[mdd^\^Nld^\
dd^[4d^[Qd^[^V^\d^\1dd^[1d^[O4d^[|Dd^\^Pd^[^Ydd^[e\d^[)$d^[NTd^[
4d^[1^Dd^[`Td^[{td^[^E^\d^[md^[^Z^Ld^[8d^[}^Dd^[j^\d^\^Q|d^[x^\d^[u^\d^\
,d^\^ALd^[jTd^[pLd^[|^\d^[~td^[^D,d^[RDd^ld^[x$d^[^^Dd^[ptd^[^Bld^[^QLd^[^Q\d^[
ld^[zdd^\,$d^[ttd^[^Vdd^[iLd^[^X\d^[)4d^\34d^[v$d^[^VTd^\^Ptd^^\d^[{Dd^[R|d^\^Q^\d^[`^Ld^[]^Ld^\
,d^[^R^Dd^[^Fld^[\d^[b^Td^[^LDd^\^P^Dd^[^B4d^[^NLd^[^Y,d^[^Kdd^\
^\d^\^CDd^[s^Td^[^A^\d^[U,d^[j,d^[~^Dd^\^QDd^[Jtd^[~Ld^[|^Td^[,Dd^^\d^[rld^[R|d^[{Dd^[
\d^[^Add^[^Q\d^[^QLd^[
ld^[ttd^[zdd^\,$d^[^Vdd^[)4d^\34d^[wLd^[m,d^[^Z|d^[\,d^[g|d^[y|d^[^Dd^[x$d^[^^Dd^[
ld^[^Bld^[RDd^[ptd^[^Q$d^[v4d^\^Ptd^[^VTd^[7$d^\1td^[P$d^[uTd^[^VTd^[zdd^[7$d^[z,[EMAIL
PROTECTED]^Dd^\,$d^\+Dd^\,4d^[^Dd^\`^Dd^[^VTd^[k4d^[P^Td^[a$d^[$d^[^V^\d^[^Utd^[mdd^[^Ytd^[|^Ld^[^L^Ld^\^ALd^[#^Dd^[e\d^[f^Dd^\^FTd^[^Pld^[^B|d^[n^\d^[d4d^[H|d^[^Rtd^[^N^Td^Td^[^Td^[{,d^[+dd^[`Td^[.^Dd^[s\d^[^ETd^[^Z^Ld^[
$d^[YTd^\^L^Dd^[1^Dd^[^O^\d^[^PDd^[^L^\d^\
dd^[
Ld^[)$d^[#td^[1d^[^E|d^[^_Ld^[KTd^[
4d^[^BDd^[yLd^[+,d^[^E^\d^\^S^Dd^[
4d^[y^Td^[^WDd^[l\d^[Y|d^\1^Dd^\0$d^\/Dd^\1dd^[{^Dd^[^SDd^[^LTd^[|^\d^[H4d^[pLd^[Md^[.,d^[]ld^[Qd^[U^\d^[~td^[l$d^[8d^[6^Ld^[^F4d^[^Odd^\^O$d^[^Kd^[^Nd^[^K^Dd^[^W4d^[_,d^[p^Dd^[+^\d^[N,d^[$Td^[~^\d^[eLd^[NTd^[
,d^[xTd^[r4d^[u^\d^[n^Ld^[rDd^[p^Td^[{td^[~d^\
,d^[}$d^[}^Dd^[P\d^[w|d^[mtd^[O4d^[{ld^[x\d^[?d^[md^[
d^[o4d^[wd^[yd^[*d^\^Pd^[u|d^[^Ydd^\^Pdd^[^Yd^[D|d^\^P,d^[.td^\^Nld^\^N4d^[|Dd^[$^\d^[jTd^[q,d^[j^\d^[\Td^\^Q|d^[f,d^[^D,d^[gDd^[x^\d^[]4d^\Dd^[w^Ld^[bLd^[L\d^[
Dd^[dld^[.d^[Lld^\ td^\4d^\ld^^Td^\d^\ d^\
^Dd^Ld^$d^[,d^[dd^[^\d^[Td^\
6856/9000
d^\^[Td^[T^Dd^\y^Dd^\^P[EMAIL PROTECTED]d^\^B,[EMAIL
PROTECTED])$d^[pLd^[|^\d^\
,d^[mdd^\^Nld^\
dd^[4d^[Qd^[^V^\d^\1dd^[1d^[O4d^[|Dd^\^Pd^[^Ydd^[e\d^[)$d^[NTd^[
4d^[1^Dd^[`Td^[{td^[^E^\d^[md^[^Z^Ld^[8d^[}^Dd^[j^\d^\^Q|d^[x^\d^[u^\d^\
,d^\^ALd^[jTd^[pLd^[|^\d^[~td^[^D,d^[RDd^ld^[x$d^[^^Dd^[ptd^[^Bld^[^QLd^[^Q\d^[
ld^[zdd^\,$d^[ttd^[^Vdd^[iLd^[^X\d^[)4d^\34d^[v$d^[^VTd^\^Ptd^^\d^[{Dd^[R|d^\^Q^\d^[`^Ld^[]^Ld^\
Minimum process stacks:
Free/Size Name
,d^[^R^Dd^[^Fld^[\d^[b^Td^[^LDd^\^P^Dd^[^B4d^[^NLd^[^Y,d^[^Kdd^\
^\d^\^CDd^[s^Td^[^A^\d^[U,d^[j,d^[~^Dd^\^QDd^[Jtd^[~Ld^[|^Td^[,Dd^^\d^[rld^[R|d^[{Dd^[
\d^[^Add^[^Q\d^[^QLd^[
ld^[ttd^[zdd^\,$d^[^Vdd^[)4d^\34d^[wLd^[m,d^[^Z|d^[\,d^[g|d^[y|d^[^Dd^[x$d^[^^Dd^[
ld^[^Bld^[RDd^[ptd^[^Q$d^[v4d^\^Ptd^[^VTd^[7$d^\1td^[P$d^[uTd^[^VTd^[zdd^[7$d^[z,[EMAIL
PROTECTED]^Dd^\,$d^\+Dd^\,4d^[^Dd^\`^Dd^[^VTd^[k4d^[P^Td^[a$d^[$d^[^V^\d^[^Utd^[mdd^[^Ytd^[|^Ld^[^L^Ld^\^ALd^[#^Dd^[e\d^[f^Dd^\^FTd^[^Pld^[^B|d^[n^\d^[d4d^[H|d^[^Rtd^[^N^Td^Td^[^Td^[{,d^[+dd^[`Td^[.^Dd^[s\d^[^ETd^[^Z^Ld^[
$d^[YTd^\^L^Dd^[1^Dd^[^O^\d^[^PDd^[^L^\d^\
dd^[
Ld^[)$d^[#td^[1d^[^E|d^[^_Ld^[KTd^[
4d^[^BDd^[yLd^[+,d^[^E^\d^\^S^Dd^[
4d^[y^Td^[^WDd^[l\d^[Y|d^\1^Dd^\0$d^\/Dd^\1dd^[{^Dd^[^SDd^[^LTd^[|^\d^[H4d^[pLd^[Md^[.,d^[]ld^[Qd^[U^\d^[~td^[l$d^[8d^[6^Ld^[^F4d^[^Odd^\^O$d^[^Kd^[^Nd^[^K^Dd^[^W4d^[_,d^[p^Dd^[+^\d^[N,d^[$Td^[~^\d^[eLd^[NTd^[
,d^[xTd^[r4d^[u^\d^[n^Ld^[rDd^[p^Td^[{td^[~d^\
,d^[}$d^[}^Dd^[P\d^[w|d^[mtd^[O4d^[{ld^[x\d^[?d^[md^[
d^[o4d^[wd^[yd^[*d^\^Pd^[u|d^[^Ydd^\^Pdd^[^Yd^[D|d^\^P,d^[.td^\^Nld^\^N4d^[|Dd^[$^\d^[jTd^[q,d^[j^\d^[\Td^\^Q|d^[f,d^[^D,d^[gDd^[x^\d^[]4d^\Dd^[w^Ld^[bLd^[L\d^[
Dd^[dld^[.d^[Lld^\ td^\4d^\ld^^Td^\d^\ d^\
^Dd^Ld^$d^[,d^[dd^[^\d^[Td^\
10468/12000 HSRP (Standby)
Interrupt level stacks:
LevelCalled Unused/Size Name
1 2648551315 6280/9000 Network interfaces
2 0 9000/9000 DMA/Timer Interrupt
3 185107 7472/9000 PA Management Int Handler
4 1715750501 8444/9000 Console Uart
5 0 9000/9000 OIR/Error Interrupt
7 3207930022 8532/9000 NMI Interrupt Handler
Spurious interrupts: 233
rtr1#
and on a different router:
rtr1.chi#sh stacks
Minimum process stacks:
Free/Size Name
[]
[c-nsp] debugging stack corruption
anyone see anything like this. i assume only a reload will fix this:
rtr1#sh proc cpu | e 0.0
CPU utilization for five seconds: 33%/8%; one minute: 37%; five minutes:
35%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
3528125122320274973 22 23.35% 20.79% 20.97% 0 Exec
70 3616544001417549298255 0.15% 0.11% 0.12% 0 IP Input
115 4851843096833738 0 0.15% 0.14% 0.15% 0 HQF Shaper Backg
rtr1#
nobody else is logged on, little to no amount of traffic is running
through the aux/cons ports, but this is interesting:
rtr1#show stacks
Minimum process stacks:
Free/Size Name
5676/6000 CDP BLOB
8640/9000 EM ED RF
11052/12000 Router Init
8676/9000 cdp init process
8348/12000 Init
5304/6000 RADIUS INITCONFIG
3616/6000 BGP Open
2264/3000 Rom Random Update Process
5616/6000 URPF stats
5316/6000 BGP Accepter
9248/12000 Exec
7176/12000 SSH Process
4264/6000 TFTP Read Process
4204/6000 MSDP Open
34540/36000 TCP Command
5236/7200 TTY Daemon
8496/9000 IP-EIGRP Router
3360/6000
d^\ytd^[^P^Ld^\zTd^[`Dd^[I$d^\^[Td^[T^Dd^\y^Dd^\^P[EMAIL
PROTECTED]d^\^B,[EMAIL PROTECTED])$d^[pLd^[|^\d^\
,d^[mdd^\^Nld^\
dd^[4d^[Qd^[^V^\d^\1dd^[1d^[O4d^[|Dd^\^Pd^[^Ydd^[e\d^[)$d^[NTd^[
4d^[1^Dd^[`Td^[{td^[^E^\d^[md^[^Z^Ld^[8d^[}^Dd^[j^\d^\^Q|d^[x^\d^[u^\d^\
,d^\^ALd^[jTd^[pLd^[|^\d^[~td^[^D,d^[RDd^ld^[x$d^[^^Dd^[ptd^[^Bld^[^QLd^[^Q\d^[
ld^[zdd^\,$d^[ttd^[^Vdd^[iLd^[^X\d^[)4d^\34d^[v$d^[^VTd^\^Ptd^^\d^[{Dd^[R|d^\^Q^\d^[`^Ld^[]^Ld^\
,d^[^R^Dd^[^Fld^[\d^[b^Td^[^LDd^\^P^Dd^[^B4d^[^NLd^[^Y,d^[^Kdd^\
^\d^\^CDd^[s^Td^[^A^\d^[U,d^[j,d^[~^Dd^\^QDd^[Jtd^[~Ld^[|^Td^[,Dd^^\d^[rld^[R|d^[{Dd^[
\d^[^Add^[^Q\d^[^QLd^[
ld^[ttd^[zdd^\,$d^[^Vdd^[)4d^\34d^[wLd^[m,d^[^Z|d^[\,d^[g|d^[y|d^[^Dd^[x$d^[^^Dd^[
ld^[^Bld^[RDd^[ptd^[^Q$d^[v4d^\^Ptd^[^VTd^[7$d^\1td^[P$d^[uTd^[^VTd^[zdd^[7$d^[z,[EMAIL
PROTECTED]^Dd^\,$d^\+Dd^\,4d^[^Dd^\`^Dd^[^VTd^[k4d^[P^Td^[a$d^[$d^[^V^\d^[^Utd^[mdd^[^Ytd^[|^Ld^[^L^Ld^\^ALd^[#^Dd^[e\d^[f^Dd^\^FTd^[^Pld^[^B|d^[n^\d^[d4d^[H|d^[^Rtd^[^N^Td^Td^[^Td^[{,d^[+dd^[`Td^[.^Dd^[s\d^[^ETd^[^Z^Ld^[
$d^[YTd^\^L^Dd^[1^Dd^[^O^\d^[^PDd^[^L^\d^\
dd^[
Ld^[)$d^[#td^[1d^[^E|d^[^_Ld^[KTd^[
4d^[^BDd^[yLd^[+,d^[^E^\d^\^S^Dd^[
4d^[y^Td^[^WDd^[l\d^[Y|d^\1^Dd^\0$d^\/Dd^\1dd^[{^Dd^[^SDd^[^LTd^[|^\d^[H4d^[pLd^[Md^[.,d^[]ld^[Qd^[U^\d^[~td^[l$d^[8d^[6^Ld^[^F4d^[^Odd^\^O$d^[^Kd^[^Nd^[^K^Dd^[^W4d^[_,d^[p^Dd^[+^\d^[N,d^[$Td^[~^\d^[eLd^[NTd^[
,d^[xTd^[r4d^[u^\d^[n^Ld^[rDd^[p^Td^[{td^[~d^\
,d^[}$d^[}^Dd^[P\d^[w|d^[mtd^[O4d^[{ld^[x\d^[?d^[md^[
d^[o4d^[wd^[yd^[*d^\^Pd^[u|d^[^Ydd^\^Pdd^[^Yd^[D|d^\^P,d^[.td^\^Nld^\^N4d^[|Dd^[$^\d^[jTd^[q,d^[j^\d^[\Td^\^Q|d^[f,d^[^D,d^[gDd^[x^\d^[]4d^\Dd^[w^Ld^[bLd^[L\d^[
Dd^[dld^[.d^[Lld^\ td^\4d^\ld^^Td^\d^\ d^\
^Dd^Ld^$d^[,d^[dd^[^\d^[Td^\
6856/9000
d^\^[Td^[T^Dd^\y^Dd^\^P[EMAIL PROTECTED]d^\^B,[EMAIL
PROTECTED])$d^[pLd^[|^\d^\
,d^[mdd^\^Nld^\
dd^[4d^[Qd^[^V^\d^\1dd^[1d^[O4d^[|Dd^\^Pd^[^Ydd^[e\d^[)$d^[NTd^[
4d^[1^Dd^[`Td^[{td^[^E^\d^[md^[^Z^Ld^[8d^[}^Dd^[j^\d^\^Q|d^[x^\d^[u^\d^\
,d^\^ALd^[jTd^[pLd^[|^\d^[~td^[^D,d^[RDd^ld^[x$d^[^^Dd^[ptd^[^Bld^[^QLd^[^Q\d^[
ld^[zdd^\,$d^[ttd^[^Vdd^[iLd^[^X\d^[)4d^\34d^[v$d^[^VTd^\^Ptd^^\d^[{Dd^[R|d^\^Q^\d^[`^Ld^[]^Ld^\
Minimum process stacks:
Free/Size Name
,d^[^R^Dd^[^Fld^[\d^[b^Td^[^LDd^\^P^Dd^[^B4d^[^NLd^[^Y,d^[^Kdd^\
^\d^\^CDd^[s^Td^[^A^\d^[U,d^[j,d^[~^Dd^\^QDd^[Jtd^[~Ld^[|^Td^[,Dd^^\d^[rld^[R|d^[{Dd^[
\d^[^Add^[^Q\d^[^QLd^[
ld^[ttd^[zdd^\,$d^[^Vdd^[)4d^\34d^[wLd^[m,d^[^Z|d^[\,d^[g|d^[y|d^[^Dd^[x$d^[^^Dd^[
ld^[^Bld^[RDd^[ptd^[^Q$d^[v4d^\^Ptd^[^VTd^[7$d^\1td^[P$d^[uTd^[^VTd^[zdd^[7$d^[z,[EMAIL
PROTECTED]^Dd^\,$d^\+Dd^\,4d^[^Dd^\`^Dd^[^VTd^[k4d^[P^Td^[a$d^[$d^[^V^\d^[^Utd^[mdd^[^Ytd^[|^Ld^[^L^Ld^\^ALd^[#^Dd^[e\d^[f^Dd^\^FTd^[^Pld^[^B|d^[n^\d^[d4d^[H|d^[^Rtd^[^N^Td^Td^[^Td^[{,d^[+dd^[`Td^[.^Dd^[s\d^[^ETd^[^Z^Ld^[
$d^[YTd^\^L^Dd^[1^Dd^[^O^\d^[^PDd^[^L^\d^\
dd^[
Ld^[)$d^[#td^[1d^[^E|d^[^_Ld^[KTd^[
4d^[^BDd^[yLd^[+,d^[^E^\d^\^S^Dd^[
4d^[y^Td^[^WDd^[l\d^[Y|d^\1^Dd^\0$d^\/Dd^\1dd^[{^Dd^[^SDd^[^LTd^[|^\d^[H4d^[pLd^[Md^[.,d^[]ld^[Qd^[U^\d^[~td^[l$d^[8d^[6^Ld^[^F4d^[^Odd^\^O$d^[^Kd^[^Nd^[^K^Dd^[^W4d^[_,d^[p^Dd^[+^\d^[N,d^[$Td^[~^\d^[eLd^[NTd^[
,d^[xTd^[r4d^[u^\d^[n^Ld^[rDd^[p^Td^[{td^[~d^\
,d^[}$d^[}^Dd^[P\d^[w|d^[mtd^[O4d^[{ld^[x\d^[?d^[md^[
d^[o4d^[wd^[yd^[*d^\^Pd^[u|d^[^Ydd^\^Pdd^[^Yd^[D|d^\^P,d^[.td^\^Nld^\^N4d^[|Dd^[$^\d^[jTd^[q,d^[j^\d^[\Td^\^Q|d^[f,d^[^D,d^[gDd^[x^\d^[]4d^\Dd^[w^Ld^[bLd^[L\d^[
Dd^[dld^[.d^[Lld^\ td^\4d^\ld^^Td^\d^\ d^\
^Dd^Ld^$d^[,d^[dd^[^\d^[Td^\
10468/12000 HSRP (Standby)
Interrupt level stacks:
LevelCalled Unused/Size Name
1 2648551315 6280/9000 Network interfaces
2 0 9000/9000 DMA/Timer Interrupt
3 185107 7472/9000 PA Management Int Handler
4 1715750501 8444/9000 Console Uart
5 0 9000/9000 OIR/Error Interrupt
7 3207930022 8532/9000 NMI Interrupt Handler
Spurious interrupts: 233
rtr1#
and on a different router:
rtr1.chi#sh stacks
Minimum process stacks:
Re: [c-nsp] OT: Linux Script for router management
On Thu, Aug 07, 2008 at 12:08:04PM -0400, Eric Van Tol wrote: -Original Message- I'm facing a problem with routers management, near of 80 dispersed routers of differents providers with differents usr/pass , I would like to have a linux console with a Menu with router list, then when a choose a option, I can get into the router automatically, or maybe other way, for example before I used a Linux console where I write down the hostname and I get the router. Do you know some tool/script that can do it? You should be able to use RANCID (http://www.shrubbery.net/rancid) in combination with an MOTD banner on your server that lists all the routers and an alias to get access to each one. You get the added benefit of backing up configs of all the routers, too. as for the menu: sh/dialog: http://invisible-island.net/dialog/ C: http://www.troubleshooters.com/lpm/200405/200405.htm#_A_Simple_Menu Perl: http://backpan.cpan.org/authors/id/C/CC/CCOLLINS/Curses-Menu-1.00.readme TCL: http://wiki.tcl.tk/12953 PHP: http://devzone.zend.com/article/1083-Using-Ncurses-in-PHP Python: http://www.ibm.com/developerworks/linux/library/l-python6.html choose your poison. -- - bill fumerola / [EMAIL PROTECTED] ___ 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] Spanning VRFs and seeing my own MAC address on a 4948
On Tue, Aug 05, 2008 at 12:21:31PM +0100, Sam Stickland wrote: Phil Mayers wrote: Sam Stickland wrote: SW1 SVI ---VLANA-- SW2 SVI | | DDOS Std DDOS Act | | SW1 (L2) --VLANB-- SW2 (L2) X | | | Inside VLANB--- Inside The Standby DDOS device does not pass traffic, but VLANs A and B are effectively bridged by the Active DDOS device on the right. What is a DDOS device? Do you mean IDS/IPS? Yup. these are two devices, not one with two interfaces, right? are they connected to each other in any way besides through the switch? e.g. for state sharing or other such. The SVIs on SW1 and SW2 are in a seperate outside VRF, and they provide a HSRP address that the inside network has a default pointing towards. The CPU on the active side (SW2) is pegged at 99% and it's all in host learning. The log buffer reports: Aug 5 07:44:34.467 UTC: %C4K_L2MAN-5-ROUTERMACADDRESSRXASSOURCE: (Suppressed 61591949 times)Packet received with my own MAC address (X:X:X:X:X:X) as source on port Gix/y in vlan B (Gix/y connects to the inside port on the DDOS appliance). Frankly I'm surprised this isn't working; if the SW2(L2) are really at layer2 with no SVI, and no L2 control protocols passing the DDoS device e.g. spanning tree, CDP, LLDP etc. The have no SVI, but spanning-tree instances are running for VLANs A and B. [...] Unfortunately the C4k platform doesn't support changing the BIA addresses, but given the nature of the error I don't think it would help. I think it's caused by the layer 2 portion of the switches seeing traffic sourced from it's own SVI on ones it's ports, which is confusing the host learning. off-the-top-of-my-head: - which spanning tree version are you running? does the IDS participate? - redacted configs would be appropriate since the SVI configuration is so specific and not just the usual vlanX,no-vrf.. you mix they have no SVI and mentions of SVIs enough times that it's not clear where they really are or aren't and who/what is pointing to them - your diagram mixes L1,L2 and L3, it'd be nice to get a physical and logical diagram (and/or a redacted config) - fire up ye olde sniffer on the IDS box, it could very well be bridging more (or less!) than you think - speaking of bridging, is there a way to use .1q + routing w/ your IDS? - look into Loop Guard on both SW1 and SW2. also, to a lesser extent look into rootguard, bpduguard, and be sure spanning tree isn't oscilating - w/o the config, it's hard to say, but PVLANs may give you the seperation of traffic between ports you desire - VACLs on the IDS ports to permit the things you know about and log the things you don't may be useful combined w/ sniffing also, i've only used cat6.5k (hybrid native) and not the 4948.. i dunno the exact capabilities of some of the features i mentioned (PVLAN, VACL). -- - bill fumerola / [EMAIL PROTECTED] ___ 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] MPLS errors w/ no MPLS configured
anyone seeing these messages? Aug 1 02:35:58.924 UTC: %BGP_MPLS-3-GEN_ERROR: BGP: MPLS outlabel changed, MPLS forw not updated, prefix not in routing table -Traceback= 61061318 610616E4 61042C28 61042CD0 610A3544 610A3904 61048EF4 6105053C 610516A8 Aug 3 15:38:32.708 UTC: %BGP_MPLS-3-GEN_ERROR: BGP: MPLS outlabel changed, MPLS forw not updated, prefix not in routing table -Traceback= 61061318 610616E4 61042C28 61042CD0 610A3544 610A3904 61048EF4 6105053C 610516A8 i'm not sure how dangerous these messages are. on one hand, we're not running MPLS at all. on the other hand, i don't like errors that involve broken tables/memory tracebacks. rtr1.lon#sh run | i mpls|MPLS no mpls traffic-eng auto-bw timers frequency 0 rtr1.lon#sh ver | i 12.[23] Cisco IOS Software, 7301 Software (C7301-K91P-M), Version 12.2(31)SB11, RELEASE SOFTWARE (fc3) ROM: System Bootstrap, Version 12.3(4r)T4, RELEASE SOFTWARE (fc1) BOOTLDR: 7301 Software (C7301-BOOT-M), Version 12.3(26), RELEASE SOFTWARE (fc2) rtr1.lon# there are BGP neighbors, both internal and external, on this host. no address-family vpn tho. -- bill ___ 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] Total output drops - congestion ? - 7200-VXR
On Thu, Jul 17, 2008 at 08:32:34AM +0800, Wilkinson, Alex wrote: Half-duplex, 10Mb/s You will note that it is Half-duplex, 10Mb/s. That is no mistake since the device that is connected to this switch-port is only capable of 10Mb/s. 10Mb/s doesn't infer half-duplex though. are you sure the device requires half-duplex? what is the device? also, i'll repeat rodney's point that ATM and Ethernet interface problems can only be tangentially related. -- bill ___ 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] Calculate wildcard..
On Sat, Jun 21, 2008 at 07:41:18PM +0300, almog ohayon wrote: Q : when i have couple of address that i need to know their common wildcard, i XOR them and i get excellent result but how can i know that i'm not overlapping any other addresses ?? a wildcard will match 2^x addresses where x= the number of bits set. examples: 0.0.0.1 = 0 0 0 1 = 2 addrs 10.0.0.0 10.0.0.1 = 10.0.0.0 0.0.0.1 0.0.0.3 = 0 0 0 11 = 4 addrs 10.0.0.0 10.0.0.1 10.0.0.2 10.0.0.3 = 10.0.0.0 0.0.0.3 0.0.0.6 = 0 0 0 110 = 4 addrs 10.0.0.0 10.0.0.2 10.0.0.4 10.0.0.6 = 10.0.0.0 0.0.0.6 0.1.0.1 = 0 1 0 1 = 4 addrs 10.0.0.0 10.1.0.0 10.0.0.1 10.1.0.1 = 10.0.0.0 0.1.0.1 -- bill ___ 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 behavior under strict CAR rate-limiting
[ i deleted some of this thread already am too lazy to search archives to see if you posted tcpdumps, i'll go off what's in my mailbox. ] On Thu, Jun 19, 2008 at 02:22:39PM -0700, Christopher Hunt wrote: Thanks for the reply. I understand that those values are not recommended and in fact i do not use them outside of the lab. I am, however, struggling to understand how TCP reacts to very very low burst levels. What mechanism is causing such low throughput as the tcp_receive_window values are not low? the window settings may not be low, but i'd imagine that if you sniffed the traffic the actual window size never really ramped up. assuming this covers the entirety of the transaction: conformed 188 packets, 260984 bytes; action: transmit exceeded 65 packets, 97206 bytes; action: drop you dropped 25% of the packets sent. the window never would have scaled up and even if the window did scale up before this policy was applied it would drop to 0 and slow start would begin again. tcp doesn't send an orgy of packets (a 16k window of packets) and then figure out how many landed where they should, it ramps / scales UP TO the max window size. it was never afforded the opportunity to do so due to your incredibly small burst size causing these drops. -- bill ___ 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 behavior under strict CAR rate-limiting
On Thu, Jun 19, 2008 at 03:07:27PM -0700, Christopher Hunt wrote:
I am familiar with TCP's concept of Slow Start, but my understanding
is that it is the RWIN that is slow to start. The packet does show the
first packet as 24 Byte payload, but even then the client RWIN is 5888
(scaled x7) (CentOS running 2.6.18 kernel). The server is XP Pro
running an RWIN 65535 with scaling disabled. As far as I can tell, TCP
slow start is not happenning. What other signs of Slow Start should i
be looking for?
every second (+/- .1s) the drops occur and SACK kicks in:
23:05:46.809550 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
115865:117313(1448) ack 1 win 46 nop,nop,timestamp 754051101 746671
23:05:46.810977 IP 10.180.55.211.commplex-link 192.168.10.2.33538: . ack
117313 win 65535 nop,nop,timestamp 746671 754051101
23:05:46.810997 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
117313:121657(4344) ack 1 win 46 nop,nop,timestamp 754051103 746671
ack 120209 begins, backlog to 126001 occurs:
23:05:46.812489 IP 10.180.55.211.commplex-link 192.168.10.2.33538: . ack
120209 win 65535 nop,nop,timestamp 746671 754051103
23:05:46.812508 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
121657:124553(2896) ack 1 win 46 nop,nop,timestamp 754051104 746671
SACK kicks in:
23:05:46.813864 IP 10.180.55.211.commplex-link 192.168.10.2.33538: . ack
120209 win 65535 nop,nop,timestamp 746671 754051103,nop,nop,sack 1
{121657:123105}
23:05:46.813883 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
124553:126001(1448) ack 1 win 46 nop,nop,timestamp 754051105 746671
23:05:46.814051 IP 10.180.55.211.commplex-link 192.168.10.2.33538: . ack
120209 win 65535 nop,nop,timestamp 746671 754051103,nop,nop,sack 1
{121657:124553}
23:05:46.814070 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
126001:127449(1448) ack 1 win 46 nop,nop,timestamp 754051106 746671
23:05:46.815196 IP 10.180.55.211.commplex-link 192.168.10.2.33538: . ack
120209 win 65535 nop,nop,timestamp 746671 754051103,nop,nop,sack 1
{121657:126001}
ack of last sack packet:
23:05:46.815214 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
120209:121657(1448) ack 1 win 46 nop,nop,timestamp 754051107 746671
.4 second delay, retransmit of ack of last sack packet:
23:05:47.237107 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
120209:121657(1448) ack 1 win 46 nop,nop,timestamp 754051529 746671
acks 120209-126001 finally occur, 10.180.55.211 moves on, .45 seconds later
23:05:47.238740 IP 10.180.55.211.commplex-link 192.168.10.2.33538: . ack
126001 win 65535 nop,nop,timestamp 746675 754051529
23:05:47.238771 IP 192.168.10.2.33538 10.180.55.211.commplex-link: .
126001:127449(1448) ack 1 win 46 nop,nop,timestamp 754051530 746675
this pattern repeats frequently. sometimes with a retransmit, sometimes
without, always taking .3-.5 seconds or so. hence, the crap performance.
-- bill
___
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 behavior under strict CAR rate-limiting
On Thu, Jun 19, 2008 at 04:16:19PM -0700, Christopher Hunt wrote: It would appear from the sender's counters and from the snmp checks on the router interface that the interface never hits 10mbps even for a second, but the rate-limiting counters do show tail drops. I guess it is difficult to get the sub-second granularity necessary to see the process in action and by the time the counters are hit again, they've averaged out over the second. instantaneous counters have this problem. clearing before each experiment and using relative wall clock time and absolute counters are an option. I know, for example that the the stats provided by ifconfig under RedHat only seem to update every 1-2 seconds. often this is because they're only polled from the ethernet hardware's registers periodically. other counters (like IP protocol statistics) exist in kernel memory. Similarly SNMP is polled at most each second and while it shows no spikes, the interface must be receiving spikes CAR (even if only for microseconds?)in order to drop packets, right? if the backing data for the SNMP counters is hardware depdendent, the counters will reflect that. otherwise, things are implementation dependent. I wonder how the rate-limiting counters really work with the Cisco. It obviously doesn't do the math each second, but instead i guess it does the math each time a packet arrives and the 1 second inteface counters obviously don't show burst that last a few microseconds. i don't know how the internals work. there are a number of different ways to implement this. even across multiple platforms there will be differences due to HZ, hardware v. software classification, etc i'm sure you've already read it, but: http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/fqos_c.html has quite a bit of detail. outside of source code, the implementation specifics are magical. which brings us to: I wish i could see the cwnd in action, but I guess I'll have to content myself with what we can see. Bill et al., thanks very much for checking this out. I hope to be useful to others some day ;-) if you're really interested, using freebsd you can compile a kernel with 'options TCPDEBUG' to export this information. see also: trpt(8) - transliterate protocol trace finally, the folks on the IETF tcpm list are helpful, but they also eat sleep and breathe tcp state, timers, congestion, etc. if you have specific questions about specific conditions, they can clarify. i'd read the archives before posting - a lot of these things have been covered before. -- bill ___ 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 TTL check (GTSM)
On Wed, Jun 18, 2008 at 11:47:14AM -0500, Justin Shore wrote: Has anyone run into any problems with the BGP TTL security check? I've tried to configure it a couple of times on our eBGP peers with no luck. The BGP session is eventually dropped after the hold time expires. It should be extremely easy to configure but for some reason it always fails. neighbor a.b.c.d ttl-security hops 1 as others have explained, this doesn't work the way it seems it should work. i got bit by the same line of thinking. ideally, you could just examine/infer the TTL of incoming packets and do: neighbor a.b.c.d ttl-security min-hops 255 and that would drop any packets from neighbor a.b.c.d with less than 255 in the TTL field. less braindead operating systems can provide this simple functionality. why IOS can read ip options but not TTL is a mystery to me. the former is a variable length often in a variable position, the latter is in a fixed position and the fields on either side are read indirectly (for frag match) or directly (for protocol). this protection would go far in protecting (e.g.) peering interfaces from MD5 cpu starvation attacks. -- bill ___ 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 router
On Fri, Jun 06, 2008 at 08:33:13AM +0200, Elmar K. Bins wrote: My gut feeling is go with a 7301 or 7200/NPE-G1. Why? Because it can deliver the 200 Mbit/s bandwidth, and it's a simple architecture - everything is software, and there is lots less hidden surprises than with the 6500/7600 platform. That would depend on packet sizes. I know we're a bit extreme (most of our packets are around 64-128 Bytes), yet...we're hitting 50% CPU load on 7301s with like 60 Mbps of Traffic (in+out aggregated), which amounts to around 72kpps. we experience the same. traffic is a little higher, but a large amount of it is DNS packets, hence mostly 512 bytes. If your traffic consists of considerably larger packets, you may want to go with 7301s (G1) or 7201s (G2); if your packet sizes are small, you need to consider hardware forwarding platforms. i know this may be heresy on this list, but look at juniper's J6350. similar price to a c7301, more throughput (even at small packet sizes). Why is it, btw, that IOS doesn't use both CPU kernels there? Or did I miss an IOS version that started doing that? (still on 12.3T here) i believe the 2nd CPU can only be enabled for some very specific features: http://www.cisco.com/en/US/docs/routers/7300/install_and_upgrade/7301/7301_install_and_config_guide/5418c.html#wp1154543 %% The Cisco 7301 includes a dual-CPU-core BCM 1250. All Cisco IOS images for the Cisco 7301 platform use CPU-core 0. CPU-core 1 allows acceleration of specific feature sets via separately purchased special software. As of Cisco IOS Release 12.3(14)YM, multi-processor forwarding (MPF) accelerates the following broadband features: L2TP Access Concentrator (LAC), L2TP Network Server (LNS), and PPP Terminated Aggregation (PTA). Port adapters are not supported in the multi-processor forwarding (MPF) path on processor 1. %% wild-ass speculation follows: i imagine the cost of data structure and code-path locking, IPIs and other multi-processor primitives (or simply the fiscal cost of coding same for this platform in 15+ year old code) negates any value to enabling the 2nd CPU for code paths that run in interrupt context and/or run through to delivery of the packet. the aforementioned MPF features can run independent of the IOS data structures that would need to be locked if the entire IOS code ran in what we traditionally call SMP. they most likely directly access the broadcom hardware over amd hypertransport, hence the unavailability of port adapters for MPF. /speculation there were murmurs of a team at cisco porting freebsd mips, which would have given native SMP support. however, all the people who were supposedly working on that no longer work for cisco (or now work in groups whose bailiwick is clearly not core OS coding). read into that what you will. -- bill ___ 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] interrupt cpu // processor routed packets
On Thu, Jun 05, 2008 at 10:32:30AM -0400, Rodney Dunn wrote: #1 issue with tunnels is usuall a fragmentation reassembley problem. (damn, i'm usually smarter than this.. :-) Watch 'sh ip traffic' outputs for large jumps. Clear the counters and capture snapshots of 'sh ip traffic'. we were already tracking the IP-MIB in cacti, so viewing the ipFrag* and ipReasm* values made this obvious. good call. Also, do sh buff input-interface name packet' to see what packets are being punted. You have to do it against the subinterface if it's a trunk. sure enough, a bunch of packets a few bytes over the MTU and a few bytes over the minimum. it would be nice to know through which tunnel they were coming from. is there anyway to use the memory values from 'sh buff input-interface' there to display the actual packets (or buffer)? thanks for your help, this was driving me mad. -- bill ___ 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 router
On Fri, Jun 06, 2008 at 09:04:05PM +0400, Alexandre Snarskii wrote: I suppose, You've heard not about Cisco, but about Juniper. no, i know what i said and it's accurate. They ported FreeBSD to MIPS and then donated MIPS code back to FreeBSD: http://www.freebsd.org/news/newsflash.html 25 December: Juniper Networks, Inc. (http://www.juniper.net) has donated a reference FreeBSD port to the MIPS architecture to The FreeBSD Project. This code will be used as one reference for creating an official project-supported FreeBSD/MIPS offering yeah, i know. :) -- [EMAIL PROTECTED] ___ 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] interrupt cpu // processor routed packets
folks, at $WORK we use 7301s as border routers at our sites. recently, we've seen an uptick in cpu. it's too difficult to isolate the change that was made, but it's our belief that some feature or option has caused a majority of packets to be run through the processor as opposed to through cef/caches. this is happening on several routers, but i'll limit the output to one of them. rtr1.ash#sh int stats GigabitEthernet0/0 Switch pathPkts In Chars In Pkts Out Chars Out Processor 2784467772 2512553561 3619252418 92352609 Route cache 1983176953 3753638533 1446323093 1223073183 Total 472677429 1971224798 770608215 1315425792 Tunnel1004 Switch pathPkts In Chars In Pkts Out Chars Out Processor 3025559230 32886251643990521 311834632 Route cache 238098300 2332344373 2454903224 3851240155 Total 3263657530 1326002241 2458893745 4163074787 there are more tunnels than tu1004. some of them are key'd, but most are not. rtr1.ash# sh int | i key|checksum Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel protocol/transport GRE/IP, key 0x138B, sequencing disabled Tunnel protocol/transport GRE/IP, key 0x138D, sequencing disabled rtr1.ash# gi0/0 has a few .1q subints. one is the local machines, three more are transit providers. the unicast/multicast filter tables are not full. i'm most familiar with the cat6k series and i'm unable to find what is causing the processor path to be tripped. we use GRE tunnels fairly heavily in our setup and it's possible that is what is causing such a surge. the counters wrap from time to time. rtr1.ash#sh proc cpu | e 0.0 CPU utilization for five seconds: 52%/46%; one minute: 53%; five minutes: 57% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 535199292 87282048403 0.47% 0.32% 0.52% 0 Pool Manager 46 5504888562337240730235 4.79% 2.40% 3.62% 0 IP Input rtr1.ash# all the cpu seems to be in interrupt context. what i'm looking for from the list is a plethora of commands to investigate what forwarding path is causing this. i've reached the end of my knowledge on this platform. plenty more output after my .sig -- bill fumerola interface Tunnel1004 description ASH - PAO bandwidth 1048576 ip address ip mtu 1500 ip pim sparse-dense-mode keepalive 5 3 ipv6 enable ipv6 ospf 36692 area 0 tunnel source tunnel destination no clns route-cache ! interface GigabitEthernet0/0 description trunk to sw1.ash no ip address no ip proxy-arp duplex full speed 1000 media-type rj45 no negotiation auto no clns route-cache ! interface GigabitEthernet0/0.1 description ash management subnet encapsulation dot1Q 1 native ip address secondary ip address secondary ip address ip access-group PRODUCTION out no ip proxy-arp ntp broadcast ntp multicast ttl 1 ipv6 address XXX::/64 eui-64 ipv6 enable ipv6 nd prefix XXX::/64 ipv6 ospf network broadcast ipv6 ospf 36692 area yyy.yy.yy.y ! these two commands were fired one right after another: rtr1.ash#sh ip cef switching st Path Reason Drop Punt Punt2Host RP RIB Packet destined for us 0 2740402100 0 RP RIB Total 0 2740402100 0 RP LES Packet destined for us 0 2852377644 0 RP LES Encapsulation resource 07056820 0 RP LES Total 0 2859434464 0 RP PAS Packet destined for us 130 2852377644 0 RP PAS No adjacency47098437 07291703 RP PAS Incomplete adjacency9582 0 57 RP PAS TTL expired0 0 28060459 RP PAS IP options set 0 0502 RP PAS Bad IP packet length 50 0 0 RP PAS Routed to Null0505265584 02740520 RP PAS Features 623282 0 519123 RP PAS IP redirects 0 0 112010 RP PAS Total 552997065 2852377644 38724374 AllTotal 552997065 4157246912 38724374 rtr1.ash#sh ip cef switching st Path Reason Drop Punt Punt2Host RP RIB Packet destined for us 0 2740402151 0 RP RIB Total 0 2740402151 0 RP LES Packet destined for us 0 2852377695 0 RP LES Encapsulation resource 07056820 0 RP LES
Re: [c-nsp] 6500 Netflow
On Thu, Apr 17, 2008 at 01:32:25PM -0700, virendra rode // wrote: The PFC3xxx/DFC3xxx do not support egress netflow. If you enable egress netflow, only the software switched packets are going to get counted. - - Is this specific to 6500 platform? absolutely, the PFC3BXL in your 2800 will work just fine! -- bill ___ 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 10k?
On Thu, Mar 13, 2008 at 04:39:24PM -0400, Matthew Crocker wrote: Isn't Cisco doing away with all the routers based off the FPGA code? NSE-100, 7301, NSE-1 *very* fast when the packets can be handled in PXF, not so good when they can't. i'd be interested in any documentation or discussion that would point to cisco distancing themselves from the 7301. -- bill ___ 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 tuning
On Wed, Mar 05, 2008 at 10:21:54AM -0500, Justin M. Streiner wrote: I don't know if it's an absolute requirement anymore, but I still do it because it's a good idea. I'd think if the router is doing forwarding and ACL processing in software, tuning your ACLs is still a very good idea. even if you forwarding/acl is done in hardware (6500/7600), there are optimizations to be made. example: although logic would dictate otherwise, using several 'eq' statements, even when a range can be used (for a sufficiently small range), can reduce LOU usage. see: http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00800c9470.shtml#wp43669 short answer to acl tuning: it's platform dependent. i've also discovered some nasty (but very cost-saving) tricks that can combine seemingly unrelated lines by using discontiguous networks/masks. you really either need to generate them from a readable source, be the only one who is reading/writing the resulting acls, or use comments and/or remarks to explain the math. -- - bill fumerola / [EMAIL PROTECTED] ___ 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] Reflexive ACLs or CBAC on 6500
On Fri, Jan 25, 2008 at 12:19:20PM +0200, Tassos Chatzithomaoglou wrote: Has anyone real world experience of using these 2 features (Reflexive ACLs or CBAC) on 6500 with MSFC2 (SUP2) or MSFC3 (SUP720)? depends on your environment. if you can limit the traffic that that would trigger the reflexive acl with acls on your edge or are only triggering the reflexive acl with your own traffic, they can be used. they should be used in corner cases. for instance, i have two NTP servers on my network and use them to allow the return traffic from outside NTP servers. the acl is specific to those two servers and can only be triggered by ntp traffic from those servers. for them to go haywire, my ntp servers would have to start sending ntp traffic to many destinations. that's the kind of corner case i would use them for on msfc platform. beyond things like that, as Roland says, avoid them. -- bill ___ 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] ipflow/netflow appliance
On Mon, Jan 14, 2008 at 03:56:40PM -0500, Adam Powers wrote: I can attest to this. nProbe is your best bet for a ?virtual NetFlow exporter?. It performs well and has tons of export formats and features. We use it extensively for QA and testing. You do, however, have to pay a bit for it whereas fprobe and others are free. it's unclear to me how a piece of software can be both GPL (or GPL derived) and for sale and the end users prevented from redistributing it. according the license, by the simple act of receiving the software you're entitled to the source. once you have that, it's unclear what prevents anyone from modifying redistributing the source. arguing license nits is for another list, i suppose. so, to keep on topic: has anyone here purchase the nProbe software? the online store says the source comes with it. is the entire codebase GPL'd? care to share the redistributable portions of the source? off-list replies to this would be fine, summaries will come if i get any meaningful response. -- bill ___ 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] RFC 1918 on loopback?
On Tue, Jan 15, 2008 at 06:07:41PM +, john heasley wrote: Tue, Jan 15, 2008 at 08:56:44AM -0800, Tony Tauber: - Merger/acquisition/interconnection with another entity which uses them and there's an overlap. (That will never happen are the words which ... which FUD is made of. The dubious security argument and inter-AS debugging, such as traceroute, should be sufficient to end this discussion. Need another? BGP RID? Need another? ICMP messages originating from these addresses and either being filtered (by you, by others) or being ambiguous. Need another? along similar lines of acqusition problems: networks of your staff using the same space (home, coffee shop, offices, etc) and VPN headaches (split horizon, overlaping routes) that result. while there are many many reasons to move from RFC1918 numbering of loopbacks and/or interfaces into assigned space, there are very little reasons (mostly contrived or based on a false sense of security) to move towards RFC1918 on devices. RFC1918 defines them and everyone (read: Other People's Networks) treats them based on those definitions. except that treatment by OPNs is based on interpretation and generally what suits the situation. -- - bill fumerola / [EMAIL PROTECTED] ___ 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] Port Traceroute utility?
On Tue, Nov 06, 2007 at 02:30:10PM -0500, Aaron Daubman wrote: This is going to sound weird, but I am looking for a utility that will let me tracroute on a specific port to see if and where a port is being blocked on a network... Check out the man page for traceroute: http://developer.apple.com/documentation/Darwin/Reference/Manpages/man8/traceroute.8.html Depending on your OS/version, the flags may differ, however, in general, you should be able to accomplish this using traceroute by: 1) setting firewall compatibility mode / dont-increment-port-number mode 2) Set the protocol to TCP or UDP as necessary (usually -P) 3) Set the port number to use (usually -p) setting the port number to an open port won't generate the ICMP PORT UNREACH that traceroute is expecting to see. discerning a lack of PORT UNREACH from a dropped packet (routing, policy, sunspots..) can be difficult depending on how much of the path you have further visibility into. -- bill ___ 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] Port Traceroute utility?
On Tue, Nov 06, 2007 at 01:02:52PM -0600, Jonathan Charles wrote: This is going to sound weird, but I am looking for a utility that will let me tracroute on a specific port to see if and where a port is being blocked on a network... http://michael.toren.net/code/tcptraceroute/ I run into issues where customers have ACLs on their network (that they don't know about) and it is causing network failures... (usually TFTP...)... that's udp, so tcptraceroute won't work. detecting open/closed/filtered udp ports typically requires specific knowledge about the network and possible filtering/blocking going on. different techniques work for different networks. once the equation gets big enough, no techniques may work. often end-to-end testing (e.g. a sniffer or tcpdump at both ends) is the only real solution. -- bill ___ 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] When to switch to DFC3BXL
On Thu, May 17, 2007 at 10:49:40AM -0500, Janet Plato wrote: On 5/16/07, Chris Woodfield [EMAIL PROTECTED] wrote: show platform hardware capacity gives you some pretty good data that may be useful in this situation. I think SXD was the first minor rev to support it, but I could be wrong. -C Thanks for the info. FWIW, I've got it in 12.2(18)SXF4 but not 12.2(18)SXE5. data point: i don't have it in 12.2(18)SXE6a -- bill ___ 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/
