Re: [c-nsp] Cellular Modem on Aux
From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: 23/10/2010 11:09 To: Peder Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cellular Modem on Aux Hi, On Fri, Oct 22, 2010 at 04:40:19PM -0500, Peder wrote: router croaks too. I've googled around and didn't really find anything. Siemens builds something called the MC35/MC35i/TC35 - basically a GSM phone without display and keyboard, and with a RS232 serial instead. We use those for monitoring gear to send out SMS if the network fails - but as far as I understand, it should work for HSCSD/V.110 dial-in as well (if the network provider doesn't block data calls, some of them do on normal voice SIM cards). I have not tested this yet, but it might give you some more food for googling. gert We are using the Siemens box for dial-in to the aux port - it works fine for this purpose. Be aware of bad GSM reception in a lot of datacenters Someone else mentioned the Cisco 3G card - that one is dial-out only afaik. Martin ___ 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] Monitor class based b/w
--- On Mon, 25/10/10, Vikas Sharma vikasshar...@gmail.com wrote: Usually we monitor b/w of the link to decide whether we need to upgrade the capacity. I want to know if we can monitor the class based b/w i.e. Premium calss or business-class, when reached to threshold, I should get an alert. Is that possible? What tools and MIB supports this. I need these MIBs for CRS1 / 12K / 7206 / 7609. Don't know about the other platforms, but we use CISCO-CLASS-BASED-QOS-MIB on 7609 to monitor bandwidth in classes. regards, Tony Miles. ___ 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] PIX ipv6 neighbour problem
Hello, thanks for your hint concerning the shared interfaces. When I disabled the interface in other contexts, the neighbour-discovery started working again. The Problem occured due to a no mac-address auto in the config. When I changed this to mac-address auto the neighour discovery works in all contexts with shared interfaces. thanks for help, Andreas On 10/19/2010 06:07 PM, Andrew Yourtchenko wrote: Hi Andreas, On Tue, 19 Oct 2010, Andreas Mueller wrote: Hello, my PIX515E is running PIX 8.0.4 with multiple contexts. In one of my contexts I would like to have IPv6 connectivity. The Interface is configured as I silently assume but just to verify - no shared interface between the contexts ? [snip] S ::/0 [0/0] via :::1::d, inside when I tried to ping the IP (:::1::e8) of the PIX on the inside interface from a linux box I get no responses. When I look at the output of the command show ipv6 neighbours, started multiple times during the pings I get the following outputs: pix515e/s6ipv6# show ipv6 neigh IPv6 Address Age Link-layer Addr State Interface fe80::20a:b8ff:fefb:6d43 518 000a.b8fb.6d43 STALE inside fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside pix515e/s6ipv6# show ipv6 neigh IPv6 Address Age Link-layer Addr State Interface fe80::20a:b8ff:fefb:6d43 518 000a.b8fb.6d43 STALE inside :::1::d 0 0021.85ca.6146 DELAY inside fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside pix515e/s6ipv6# show ipv6 neigh IPv6 Address Age Link-layer Addr State Interface fe80::20a:b8ff:fefb:6d43 519 000a.b8fb.6d43 STALE inside :::1::d 0 0021.85ca.6146 PROBE inside fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside pix515e/s6ipv6# show ipv6 neigh IPv6 Address Age Link-layer Addr State Interface fe80::20a:b8ff:fefb:6d43 519 000a.b8fb.6d43 STALE inside fe80::221:85ff:feca:6146 - 0021.85ca.6146 REACH inside Looks like we've already got the neighbor entry for pref:1::d, then tried to send the NS to it and failed ? here is the output of the PIX-debugging: Oct 19 15:55:52 pix515e %PIX-7-609001: Built local-host identity:fe80::20e:cff:fe80:c80c Oct 19 15:55:52 pix515e %PIX-7-609001: Built local-host inside:ff02::1 Oct 19 15:55:52 pix515e %PIX-6-302020: Built outbound ICMP connection for faddr ff02::1/0 gaddr fe80::20e:cff:fe80:c80c/0 laddr fe80::20e:cff:fe80:c80c/0 Oct 19 15:55:52 pix515e %PIX-7-711001: ICMPv6-ND: Sending RA to ff02::1 on inside Oct 19 15:55:52 pix515e %PIX-7-711001: ICMPv6-ND: MTU = 1500 Oct 19 15:55:52 pix515e %PIX-7-711001: IPV6: source fe80::20e:cff:fe80:c80c (local) Oct 19 15:55:52 pix515e %PIX-7-711001: dest ff02::1 (inside) Oct 19 15:55:52 pix515e %PIX-7-711001: traffic class 224, flow 0x0, len 72+0, prot 58, hops 255, originating Oct 19 15:55:52 pix515e %PIX-7-711001: IPv6: Sending on inside Oct 19 15:55:56 pix515e %PIX-6-302021: Teardown ICMP connection for faddr ff02::1/0 gaddr fe80::20e:cff:fe80:c80c/0 laddr fe80::20e:cff:fe80:c80c/0 Oct 19 15:55:56 pix515e %PIX-7-609002: Teardown local-host identity:fe80::20e:cff:fe80:c80c duration 0:00:04 Oct 19 15:55:56 pix515e %PIX-7-609002: Teardown local-host inside:ff02::1 duration 0:00:04 Based on the timestamps, seems like the ICMP connection was built to send the RA - so I do not see any traces of ND working here at all... Give it a shot this way: debug ipv6 nd, deb ipv6 icmp then clear ipv6 neigh, you should have something like this when pinging from the linux box: ASA(config)# clear ipv6 neigh ASA(config)# deb ipv6 nd ASA(config)# deb ipv6 icmp ASA(config)# sh ipv6 neigh ASA(config)# ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type 128 ICMPv6: Received echo request from 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6: Sending echo reply to 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6-ND: DELETE - INCMP: 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6-ND: Sending NS for 2002:c01d:cafe:1002:218:51ff:fef9:bceb on inside ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type 136 ICMPv6-ND: Received NA for 2002:c01d:cafe:1002:218:51ff:fef9:bceb on inside from 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6-ND: INCMP - REACH: 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type 128 ICMPv6: Received echo request from 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6: Sending echo reply to 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6: Received ICMPv6 packet from 2002:c01d:cafe:1002:218:51ff:fef9:bceb, type 128 ICMPv6: Received echo request from 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6: Sending echo reply to 2002:c01d:cafe:1002:218:51ff:fef9:bceb ICMPv6: Received ICMPv6 packet from fe80::218:51ff:fef9:bceb, type 135 ICMPv6-ND: Received NS for fe80::21e:7aff:fe36:6d37 on inside from fe80::218:51ff:fef9:bceb ICMPv6-ND: DELETE - INCMP: fe80::218:51ff:fef9:bceb ICMPv6-ND: INCMP - STALE: fe80::218:51ff:fef9:bceb
Re: [c-nsp] OSPF design
Dear all, Thank you for your replies. We use OSPF basically to advertise each router's loopback so that we can deploy L2 , L3 VPN between routers. There'll be no other external route advertised into OSPF. Thus, we will not configure summarization on any ABR router as well as stubby areas. I agree with Geoff's post that separating network into different OSPF areas cannot reduce LSDB size. If we separate into different areas, LSA1,2,3 are generated and all routers must trigger SPF for a topology change inside an area. If we do not separate into different areas, only LSA1,2 are generated and all routers must also trigger SPF for a topology change inside an area. According to below statement, iSPF helps each router to run SPF only on the changed portion of the topology. This means neither separating network into areas nor configuring inside an area will benefit from iSPF. Correct me if I'm wrong at this. OSPF uses Dijkstra's SPF algorithm to compute the shortest path tree (SPT). During the computation of the SPT, the shortest path to each node is discovered. The topology tree is used to populate the routing table with routes to IP networks. When changes to a Type-1 or Type-2 link-state advertisement (LSA) occur in an area, the entire SPT is recomputed. In many cases, the entire SPT need not be recomputed because most of the tree remains unchanged. Incremental SPF allows the system to recompute only the affected part of the tree. Recomputing only a portion of the tree rather than the entire tree results in faster OSPF convergence and saves CPU resources. Note that if the change to a Type-1 or Type-2 LSA occurs in the calculating router itself, then the full SPT is performed (source: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfispf.html) From your advice, I'm more likely to configure those 100 routers inside an OSPF area now. The reason why we design OSPF up to UPE devices because we also have FTTH switches configure as Layer 2, also we can deploy different Layer 3 redundancy techniques such Layer 3 loop prevention, MPLS TE..up to UPE layer. Thanks, Rin -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Heath Jones Sent: Saturday, October 23, 2010 6:05 AM To: Robert Crowe (rocrowe) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF design Just remember that you cannot summarize (today) your main Loopback used for your LDP/BGP ID as there needs to be a full LSP from ingress-to-egress PE across areas, if you providing L2/L3VPN services. Is this because the lsp is label in label (outer being pe, inner being customer route)? ___ 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/ ___ 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] Preventing host with lower ip to become IGMP querier
Forgot to say, it's Cisco 3560. On Mon, Oct 25, 2010 at 3:17 PM, Pavel Dimow paveldi...@gmail.com wrote: Hello, I have some strange situation (not that I really understand how it works), but I want to prevent device connected to a port to become IGMP querier because it has a lower ip address. I have also made sure to configure profile in order to prevent it for receiving (joining) any multicast groups but all mcast traffic goes to this port also. I don't have management on that device. Thanks in advance for any help/tips ___ 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] OSPF design
If you are doing MPLE TE then you really don't want more than one area as then you get into inter-area TE tunnels which makes TE optimal path selection harder(not possible in some cases). -Ben On Oct 25, 2010, at 4:50 AM, Rin wrote: Dear all, Thank you for your replies. We use OSPF basically to advertise each router's loopback so that we can deploy L2 , L3 VPN between routers. There'll be no other external route advertised into OSPF. Thus, we will not configure summarization on any ABR router as well as stubby areas. I agree with Geoff's post that separating network into different OSPF areas cannot reduce LSDB size. If we separate into different areas, LSA1,2,3 are generated and all routers must trigger SPF for a topology change inside an area. If we do not separate into different areas, only LSA1,2 are generated and all routers must also trigger SPF for a topology change inside an area. According to below statement, iSPF helps each router to run SPF only on the changed portion of the topology. This means neither separating network into areas nor configuring inside an area will benefit from iSPF. Correct me if I'm wrong at this. OSPF uses Dijkstra's SPF algorithm to compute the shortest path tree (SPT). During the computation of the SPT, the shortest path to each node is discovered. The topology tree is used to populate the routing table with routes to IP networks. When changes to a Type-1 or Type-2 link-state advertisement (LSA) occur in an area, the entire SPT is recomputed. In many cases, the entire SPT need not be recomputed because most of the tree remains unchanged. Incremental SPF allows the system to recompute only the affected part of the tree. Recomputing only a portion of the tree rather than the entire tree results in faster OSPF convergence and saves CPU resources. Note that if the change to a Type-1 or Type-2 LSA occurs in the calculating router itself, then the full SPT is performed (source: http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/ospfispf.html) From your advice, I'm more likely to configure those 100 routers inside an OSPF area now. The reason why we design OSPF up to UPE devices because we also have FTTH switches configure as Layer 2, also we can deploy different Layer 3 redundancy techniques such Layer 3 loop prevention, MPLS TE..up to UPE layer. Thanks, Rin -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Heath Jones Sent: Saturday, October 23, 2010 6:05 AM To: Robert Crowe (rocrowe) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF design Just remember that you cannot summarize (today) your main Loopback used for your LDP/BGP ID as there needs to be a full LSP from ingress-to-egress PE across areas, if you providing L2/L3VPN services. Is this because the lsp is label in label (outer being pe, inner being customer route)? ___ 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/ ___ 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/ ___ 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] OSPF design
Outer label is for label switching to the destination PE, inner label can represent a number of this depending on the technology being deployed (L2/L3/etc). Robert Crowe Email: rocr...@cisco.com -Original Message- From: Heath Jones [mailto:hj1...@gmail.com] Sent: Friday, October 22, 2010 7:05 PM To: Robert Crowe (rocrowe) Cc: Mack O'Brian; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPF design Just remember that you cannot summarize (today) your main Loopback used for your LDP/BGP ID as there needs to be a full LSP from ingress-to-egress PE across areas, if you providing L2/L3VPN services. Is this because the lsp is label in label (outer being pe, inner being customer route)? ___ 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] Preventing host with lower ip to become IGMP querier
Hi Pavel, I know that you can force which router will become the DR for the network with the ip pim dr-priority command, otherwise the highest ip address wins the election. Does that change which router becomes the querier? Dale Thus spake Pavel Dimow (paveldi...@gmail.com) on Mon, Oct 25, 2010 at 03:17:35PM +0200: Hello, I have some strange situation (not that I really understand how it works), but I want to prevent device connected to a port to become IGMP querier because it has a lower ip address. I have also made sure to configure profile in order to prevent it for receiving (joining) any multicast groups but all mcast traffic goes to this port also. I don't have management on that device. Thanks in advance for any help/tips ___ 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/ ___ 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] VTY access through VRF interface
Just to follow up to this issue, TAC decided this is a bug. I will post back when I get details on bug ID and any other info. On Mon, Oct 11, 2010 at 10:31 PM, Jay Nakamura zeusda...@gmail.com wrote: New discovery, no matter what, the router will not let me login to the IP on the serial interface if it's on a VRF. I can login to an Ethernet interface on the same VRF going through the serial interface. This seems to be what was tripping me up. Is this a bug? It sure feels like one. On Fri, Oct 8, 2010 at 3:45 PM, Jay Nakamura zeusda...@gmail.com wrote: Found out that this was because I didn't have the data license enabled yet. As soon as I enabled the data license, (I did have to reboot. Grumble...) it started working. On Thu, Oct 7, 2010 at 3:15 PM, Jay Nakamura zeusda...@gmail.com wrote: I am trying to configure a router with couple VRF and I need to be able to ssh/telnet to vty through VRF interface. I haven't had this problem with other routers prior to 15.0M. Am I missing a command I don't know about to enable this? With 12.4x, I used access-class vrf-also and that seems to have done it. The router I am working with is a 1941 with 15.0(1)M3 I don't have any firewall or anything else that could prevent logging in (That I can see) I can login through the interface on the global table, trying to get on the VRF interface gets me connection refused Here is the redacted config version 15.0 no ip source-route ip cef ! ! ip vrf Inside rd 64512:3 import map VRFDefaultMap route-target export 64512:3 route-target import 64512:2 ! ip vrf Outside rd 64512:2 route-target export 64512:2 route-target import 64512:3 ! ! ! interface GigabitEthernet0/0 ip address x.x.x.1 255.255.255.248 ip nat outside ip virtual-reassembly duplex auto speed auto ! ! interface GigabitEthernet0/1 ip vrf forwarding Inside ip address 172.17.0.1 255.255.252.0 ip nat inside ip virtual-reassembly duplex auto speed auto ! interface Serial0/0/0 ip vrf forwarding Outside ip address y.y.y.2 255.255.255.248 ip nat outside ip virtual-reassembly no clock rate 200 ! ! router bgp 64512 no synchronization bgp log-neighbor-changes no auto-summary ! address-family ipv4 vrf Inside no synchronization redistribute connected redistribute static exit-address-family ! address-family ipv4 vrf Outside no synchronization redistribute connected redistribute static default-information originate exit-address-family ! ip route 0.0.0.0 0.0.0.0 x.x.x.1 ip route vrf Outside 0.0.0.0 0.0.0.0 y.y.y.1 ! ! ip prefix-list DefaultOnly seq 5 permit 0.0.0.0/0 ! route-map VRFDefaultMap permit 10 match ip address prefix-list DefaultOnly line vty 0 4 access-class MgmntACL in vrf-also exec-timeout 120 0 privilege level 15 password 7 login local transport input telnet ssh line vty 5 15 access-class MgmntACL in vrf-also exec-timeout 120 0 privilege level 15 password 7 login local transport input telnet ssh ___ 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] Preventing host with lower ip to become IGMP querier
Hello Dale, ip pim dr-priority is the L3 command. Which I dont have turned on, just plain igmp snooping on per VLAN basic on the 3560. The problem manifest when some device is connected to a port in that VLAN and simply becomes mrouter for that VLAN, which causes that it can receive all multicast traffic. On Mon, Oct 25, 2010 at 6:01 PM, Dale W. Carder dwcar...@wisc.edu wrote: Hi Pavel, I know that you can force which router will become the DR for the network with the ip pim dr-priority command, otherwise the highest ip address wins the election. Does that change which router becomes the querier? Dale Thus spake Pavel Dimow (paveldi...@gmail.com) on Mon, Oct 25, 2010 at 03:17:35PM +0200: Hello, I have some strange situation (not that I really understand how it works), but I want to prevent device connected to a port to become IGMP querier because it has a lower ip address. I have also made sure to configure profile in order to prevent it for receiving (joining) any multicast groups but all mcast traffic goes to this port also. I don't have management on that device. Thanks in advance for any help/tips ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] Bug CSCso74996
Hello group, We have a customer that is migrating from WIC-1ADSL to HWIC-1ADSL-M and now the routers are complaining. The bug seems this one: ++ CSCso74996 Bug Details %SYS-4-CHUNKMALLOCFAIL: Could not allocate chunks for pak subblock c Symptoms: A %SYS-4-CHUNKMALLOCFAIL error message is seen. The cause field of the message states Not a dynamic chunk. Conditions: The symptom is observed in conditions where an application depends heavily on chunks. Workaround: There is no workaround. Further Problem Description: This issue will not affect the working/operation of the system although it may cause some performance slow down. The message %SYS-4-CHUNKMALLOCFAIL with cause field being Not a dynamic chunk shows the problem is occuring. An error message %SYS-4-CHUNKMALLOCFAIL with a cause field other than Not a dynamic chunk, is unrelated to this issue. ++ The routers are 2811 running 12.4(15)T1. It seems the fix was only integrated on 12.4M, not on 12.4T. Anyone has seen this issue and knows the real impact of it ? Yes, I can open a TAC case but I want to avoid it. Those that know what Shared Support is will understand :) Thanks. Regards, Antonio Soares, CCIE #18473 (RS/SP) amsoa...@netcabo.pt ___ 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] Preventing host with lower ip to become IGMP querier
hey, Forgot to say, it's Cisco 3560. What you are looking for is called multicast router guard http://www.cisco.com/web/about/security/intelligence/multicast_toolkit.html I've pushed cisco to make it available on platforms smaller than 6500 but no success so far. Their general reasoning is that if you deal with insecure endpoints, use MVR. -- tarko ___ 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] 6500 Memory Upgrade problems
I have a couple of Supervisor Engine 2 that I need to upgrade memory in order to run the latest IOS and to set them up as redundant SUPs on a 6513. I run in to the following symptoms on both Sups so I figure there must be something I'm missing. Both SUP are part number WS-X6K-SUP2-2GE new SP memory is part# MEM-S2-256MB new MSFC2 part# is MEM-MSFC2-512MB When I try to upgrade the SP memory the SUP will not boot at all, nothing will display on the console. When I upgrade the MSFC2 memory alone ( I leave the existing memory on the SP) then the IOS load will crash. Here is the extract... Cisco Internetwork Operating System Software IOS (tm) c6sup2_sp Software (c6sup2_sp-SP-M), Version 12.1(27b)E4, RELEASE SOFTWARE (fc3) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2008 by cisco Systems, Inc. Compiled Fri 29-Feb-08 13:22 by hqluong Image text-base: 0x40020EF4, data-base: 0x40954000 00:00:03: %PFREDUN-6-ACTIVE: Initializing as ACTIVE processor 00:00:08: %OIR-SP-6-CONSOLE: Changing console ownership to route processor 00:03:08: %SYS-SP-3-LOGGER_FLUSHED: System was paused for 00:00:00 to ensure console debugging output. 00:03:09: %OIR-SP-6-CONSOLE: Changing console ownership to switch processor *** System received a Software forced crash *** signal= 0x17, code= 0x4238, context= 0x423b7f34 PC = 0x401236c4, Cause = 0x1820, Status Reg = 0x34018002 Is there a firmware upgrade for the SUP and MSFC2 I may be missing? Here is the detail on the harware on one of the 6500 I'm using to test this. Mod Port Model Serial #Versions --- -- --- -- 12 WS-X6K-SUP2-2GESAL06282EJP Hw : 3.7 Fw : 7.1(1) Sw : 12.1(27b)E4 Fw1: 6.1(3) Sw1: 8.5(0.23)COS6 WS-F6K-MSFC2 SAL0542D5AQ Hw : 1.2 Fw : 12.1(4r)E Sw : 12.1(27b)E4 WS-F6K-PFC2SAL06272BVY Hw : 3.2 3 48 WS-X6148-RJ45V SAL0720D4LB Hw : 1.3 Fw : 5.4(2) Sw : 8.5(0.23)COS6 4 48 WS-X6148-RJ45V SAL062726SD Hw : 1.6 Fw : 5.4(2) Sw : 8.5(0.23)COS6 5 48 WS-X6148-RJ45V SAL06282HC8 Hw : 1.0 Fw : 5.4(2) Sw : 8.5(0.23)COS6 6 48 WS-X6348-RJ-45 SAL0545E384 Hw : 5.0 Fw : 5.4(2) Sw : 8.5(0.23)COS Any help will be greatlly appreciated. Thanks! ___ 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] Preventing host with lower ip to become IGMP querier
Dear Pavel, I have some strange situation (not that I really understand how it works), but I want to prevent device connected to a port to become IGMP querier because it has a lower ip address. I have also made sure to configure profile in order to prevent it for receiving (joining) any multicast groups but all mcast traffic goes to this port also. I don't have management on that device. It seems that Cisco switches lack of the forbidden mrouter interface command. Thanks in advance for any help/tips You can try access-list at an interface which rejects all hosts destination traffic. There is also a tricky way. You can switch mrouter learning mode at the switch to CGMP and put some particular interfaces into a static mrouter mode. I'm sure CPE doesn't use CGMP. 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/ ___ 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] OSPF design (danger will)
Christopher J. Wargaski war...@gmail.com writes: It just doesn't make sense to run OSPF when all of the links to the remote locations will be running BGP. Actually it does, in some cases. BGP cannot maintain 2 links to the same neighbour, and so it does not work if you have redundant links (except for LACP links and similar). That is when you need OSPF so you can peer on the loopback addresses. It is a bit surprising that no one has bothered to make an extension to BGP for this purpose, but I guess the OSPF/BGP combination works well enough. /Benny ___ 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] OSPF design (danger will)
On Mon, Oct 25, 2010 at 4:07 PM, Benny Amorsen benny+use...@amorsen.dk wrote: Christopher J. Wargaski war...@gmail.com writes: It just doesn't make sense to run OSPF when all of the links to the remote locations will be running BGP. Actually it does, in some cases. BGP cannot maintain 2 links to the same neighbour, and so it does not work if you have redundant links (except for LACP links and similar). That is when you need OSPF so you can peer on the loopback addresses. It is a bit surprising that no one has bothered to make an extension to BGP for this purpose, but I guess the OSPF/BGP combination works well enough. Doesn't multi-path fulfill this requirement? Running and IGP is required for next hop resolution (specifically for iBGP, and sometimes eBGP) right? /Benny ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] FWSM config-change timestamp
fwsm - ver 3.2(5) in cat 6509-E(12.2 SXI) The last-config-change timestamp in the running-copy of the config reflects the current-time in the following cases: 1) more system:running-config 2) copy running-config to a remote server and open via regular text editor. A sh run in the module has always stripped out the info and I am aware of that behavior but this one is new. I would leave it as a not-quite-so-cosmetic bug but in this case RANCID for obvious reasons, sees the different timestamp and emails the meaningless diffs to me and the PHB's and I have to explain... The startup-config reflects the actual-time a change was made. Wondering if anyone has seen this behavior and knows of a workaround short-of-an-upgrade. There is nothing related to this in cco- release notes/bug reports. Any insight would be appreciated. ./Randy ___ 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] PPPoEoA QoS issue
Hi, I am running following configuration on 7206 with IOS - 12.4(15)T10 interface ATM2/0.10856 point-to-point mtu 1500 no ip redirects no ip proxy-arp pvc 1/856 vbr-rt 2048 2048 1 dbs enable encapsulation aal5snap max-reserved-bandwidth 100 protocol pppoe group ft-pppoeoa ! end bba-group pppoe pppoeoa virtual-template 661 sessions per-mac limit 300 interface Virtual-Template661 no ip address ppp authentication chap end When I want to see the packets in policy, I can not see even a single packet in any queue... Router1#sh policy-map interface ATM2/0.10856 ATM2/0.10856: VC 1/856 - Service-policy input: SAR_QOS_FROM_MANAGED_CPE Class-map: Premium-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 5 0 packets, 0 bytes 1 minute rate 0 bps Match: ip dscp ef (46) 0 packets, 0 bytes 1 minute rate 0 bps QoS Set mpls experimental imposition 5 Packets marked 0 qos-group 5 Packets marked 0 Class-map: Business1-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af31 (26) 0 packets, 0 bytes 1 minute rate 0 bps QoS Set mpls experimental imposition 3 Packets marked 0 discard-class 3 Packets marked 0 qos-group 3 Packets marked 0 Class-map: Business2-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af21 (18) 0 packets, 0 bytes 1 minute rate 0 bps QoS Set mpls experimental imposition 2 Packets marked 0 discard-class 2 Packets marked 0 qos-group 2 Packets marked 0 Class-map: Business3-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp af11 (10) 0 packets, 0 bytes 1 minute rate 0 bps QoS Set mpls experimental imposition 1 Packets marked 0 discard-class 1 Packets marked 0 qos-group 1 Packets marked 0 Class-map: Routing-Management-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 6 7 0 packets, 0 bytes 1 minute rate 0 bps Match: ip dscp af41 (34) 0 packets, 0 bytes 1 minute rate 0 bps QoS Set mpls experimental imposition 6 Packets marked 0 discard-class 6 Packets marked 0 qos-group 6 Packets marked 0 Class-map: Default-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 0 0 packets, 0 bytes 1 minute rate 0 bps QoS Set mpls experimental imposition 0 Packets marked 0 discard-class 0 Packets marked 0 qos-group 0 Packets marked 0 Class-map: Multicast-From-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp cs4 (32) 0 packets, 0 bytes 1 minute rate 0 bps QoS Set discard-class 4 Packets marked 0 qos-group 4 Packets marked 0 Class-map: class-default (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: any Service-policy output: SAR_QOS_TO_COLT_TOTAL_CPE Class-map: Routing-Management-To-CPE (match-any) 6 packets, 518 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: qos-group 6 1 packets, 74 bytes 1 minute rate 0 bps Match: ip precedence 6 7 5 packets, 444 bytes 1 minute rate 0 bps Queueing Output Queue: Conversation 137 Bandwidth 5 (%) Bandwidth 102 (kbps)Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: Premium-Class-To-CPE (match-any) 190 packets, 14060 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: qos-group 5 190 packets, 14060 bytes 1 minute rate 0 bps Queueing Strict Priority Output Queue: Conversation 136 Bandwidth 50 (%) Bandwidth 1024 (kbps) Burst 25600 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: Business1-Class-To-CPE (match-any) 0 packets, 0 bytes 1 minute offered rate 0 bps, drop rate 0 bps Match: qos-group 3 0 packets, 0 bytes 1 minute rate 0 bps Queueing Output Queue: Conversation 138 Bandwidth 5 (%) Bandwidth 102 (kbps) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0
