Re: [c-nsp] off-topic NMS Suggestion
Hi Omar, Ciscoworks LMS 4.0 has gone pretty extensive changes in the UI / UX space. it's also very competitively priced respect to the other mgmt solutions out there. You can take the eval version it for a spin and see if it's something you want to roll out. http://www.cisco.com/go/lms https://cisco.mediuscorp.com/market/networkers/homeWork.se.work http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_lan_management_solution/4.0/install/guide/prep.html#wp1316880 regards .siva On Wed, 18 May 2011, Jorge Rodriguez wrote: I have used WhatsUp Gold from IPswitch for a couple of years. It can do everything we need it to do and more and it relatively inexpensive. I would say that it's comparable to Solarwinds. Check them out and good luck Sent from my iPhone On May 17, 2011, at 10:38 PM, omar parihuana wrote: Hi List, Please could you suggest me a NMS for WAN/LAN? the WAN is a MPLS/VPN (300 remote offices) and the Switching is a campus LAN (aprox 1000 Network Devices) and three remote buildings (aprox Network 200 devices in each building). Before I tried Cisco Works but I faced some issues; HP Openview was difficult also. We need a easy web interface for monitoring and reporting (unfortunately no open source solutions are accepted). Thank you for your suggestions. Rgds. -- Omar E.P.T - Certified Networking Professionals make better Connections! ___ 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] 3750X?
the X-models are at a lower list price then the E-models. thanks .siva On Thu, 15 Apr 2010, Peter Rathlev wrote: On Wed, 2010-04-14 at 08:57 -0500, Jeffrey Ollie wrote: So, before the meeting, does anyone else have opinions or questions that I should be asking? Ask them when they will begin supporting software upgrades per-member in a stack. :-) The power sharing looks impressive. And it supports MACsec, though that's probably hardly relevant yet. Together with PoE+ those are the things that make it stand out from the 3750E in my eyes. Are these X-models considerably more expensive than E-models? Or are they targeted at replacing the E-models? -- Peter ___ 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] Baseline CoPP policies?
the platform team should be able to work with the NSSTG QoS team to get this to happen. you might want to direct your account team at your platform team. they in turn can work with the QoS team to get the necessary MQC extensions. regards .siva On Wed, 8 Jul 2009, Justin Shore wrote: One thing that the documentation always lacks is sufficient info on handling IS-IS with CoPP. The inability of IOS to match IS-IS traffic without using class-default is a major problem. Of all the people that would need CoPP (people with publicly exposed routers like SPs) one would think that IS-IS support for CoPP would be a big deal. Is there a specific dev group within Cisco that I can point my account team to that would be the one to consider my feature request. Justin Siva Valliappan wrote: Hi Drew, have you looked at the following docs: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html ___ 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] QoS on 837 using PPPoE
correct. vbr-nrt only affects the output not the input. regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi Siva, Your suggestions seem to have to have worked. Just so that I understand, the vbr-nrt shaping is just for the outbound cells and does not affect inbound traffic correct?? This is a 3m/384k and I do not want to affect their inbound. I could only reserve 288k in my policy (which is fine since the upload is only 384k). And the logs did show why it did not take the command and I was able to adjust my policy as the logs suggested. I/f ATM0.1 VC 1/100 class VoIP requested bandwidth 320 (kbps), available only 288 (kbps) This is now what shows up in the config policy-map Voice class VoIP priority 288 interface ATM0.1 point-to-point pvc 1/100 vbr-nrt 384 384 encapsulation aal5snap service-policy output Voice pppoe-client dial-pool-number 1 On Tue, Jul 7, 2009 at 4:32 PM, Siva Valliappan wrote: what does the log messages say? a show log should tell you why it didn't accept the commands. On Tue, 7 Jul 2009, Clue Store wrote: It took the command under the pvc section, but after a "sho run" the config did not show up. Nor when I did a "show policy-map interface a0.1" did anything show up. I've looked through several docs on the cisco site, but did not come up with anything that seem'd to work. Will try to upgrade the IOS later tonight. Anyone else with any ideas?? On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan wrote: IIRC you need to apply it on the ATM interface e.g. Interface ATM0.1 point-to-point . . pvc 1/100 service-policy output Voice regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi All, I am having a hard time trying to figure how to apply a QoS policy on this router. I have applied a few typical service-policies on the dialer interfaces, but a "show policy interface di0" shows packets being matched but nothing being dropped and the link is saturated. I believe the policy needs to be applied to the virtual-access interface that comes up when PPP negotiates, but i'm not quite sure how this would be done since the use of vpdn-groups are no longer used. Relevent config posted. Any suggestions are greatly appreciated. *And yes I know the service-policy is not applied to the dialer interface...this was due to it not working. class-map match-any VoIP match ip rtp 16384 16383 match access-group name VoicePorts ! ! policy-map Voice class VoIP priority 256 ! ! ! ! ! interface Ethernet0 ip address 192.168.10.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Ethernet2 no ip address shutdown hold-queue 100 out ! interface ATM0 no ip address load-interval 30 no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point pvc 1/100 encapsulation aal5snap pppoe-client dial-pool-number 1 ! ! interface FastEthernet1 duplex auto speed auto ! interface FastEthernet2 duplex auto speed auto ! interface FastEthernet3 duplex auto speed auto ! interface FastEthernet4 duplex auto speed auto ! ! interface Dialer0 ip address negotiated ip mtu 1492 ip nat outside ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1412 dialer pool 1 no cdp enable ! ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Dialer0 ! ip http server no ip http secure-server ! no ip nat service skinny tcp port 2000 no ip nat service sip udp port 5060 ip nat inside source list 10 interface Dialer0 overload ! ! ip access-list extended VoicePorts permit udp any host *.*.*.* range 22026 62025 permit udp any host *.*.*.* range 22026 62025 access-list 10 permit 192.168.10.0 0.0.0.255 ___ 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] QoS on 837 using PPPoE
what does the log messages say? a show log should tell you why it didn't accept the commands. On Tue, 7 Jul 2009, Clue Store wrote: It took the command under the pvc section, but after a "sho run" the config did not show up. Nor when I did a "show policy-map interface a0.1" did anything show up. I've looked through several docs on the cisco site, but did not come up with anything that seem'd to work. Will try to upgrade the IOS later tonight. Anyone else with any ideas?? On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan wrote: IIRC you need to apply it on the ATM interface e.g. Interface ATM0.1 point-to-point . . pvc 1/100 service-policy output Voice regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi All, I am having a hard time trying to figure how to apply a QoS policy on this router. I have applied a few typical service-policies on the dialer interfaces, but a "show policy interface di0" shows packets being matched but nothing being dropped and the link is saturated. I believe the policy needs to be applied to the virtual-access interface that comes up when PPP negotiates, but i'm not quite sure how this would be done since the use of vpdn-groups are no longer used. Relevent config posted. Any suggestions are greatly appreciated. *And yes I know the service-policy is not applied to the dialer interface...this was due to it not working. class-map match-any VoIP match ip rtp 16384 16383 match access-group name VoicePorts ! ! policy-map Voice class VoIP priority 256 ! ! ! ! ! interface Ethernet0 ip address 192.168.10.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Ethernet2 no ip address shutdown hold-queue 100 out ! interface ATM0 no ip address load-interval 30 no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point pvc 1/100 encapsulation aal5snap pppoe-client dial-pool-number 1 ! ! interface FastEthernet1 duplex auto speed auto ! interface FastEthernet2 duplex auto speed auto ! interface FastEthernet3 duplex auto speed auto ! interface FastEthernet4 duplex auto speed auto ! ! interface Dialer0 ip address negotiated ip mtu 1492 ip nat outside ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1412 dialer pool 1 no cdp enable ! ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Dialer0 ! ip http server no ip http secure-server ! no ip nat service skinny tcp port 2000 no ip nat service sip udp port 5060 ip nat inside source list 10 interface Dialer0 overload ! ! ip access-list extended VoicePorts permit udp any host *.*.*.* range 22026 62025 permit udp any host *.*.*.* range 22026 62025 access-list 10 permit 192.168.10.0 0.0.0.255 ___ 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] QoS on 837 using PPPoE
it's been many years since i worked in this area, so you will need to bear with me. couple of things to check. can you do a "show log" and is there any other messages that were generated when you tried to configure the service policy on the ATM interface? do you have a "vbr-nrt " definition under the ATM interface? can you configure that first, and then configure the service policy statement? does it resolve the issue? if not, what were the log messages that were generated? thanks .siva On Tue, 7 Jul 2009, Clue Store wrote: On A0.1. config-subif)#service-policy output Voice CBWFQ : Not supported on subinterfaces On A0 (config-if)#service-policy output Voice CBWFQ : Not supported on this interface It would seem out old ways of QoS have changed ;) On Tue, Jul 7, 2009 at 4:06 PM, Siva Valliappan wrote: IIRC you need to apply it on the ATM interface e.g. Interface ATM0.1 point-to-point . . pvc 1/100 service-policy output Voice regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi All, I am having a hard time trying to figure how to apply a QoS policy on this router. I have applied a few typical service-policies on the dialer interfaces, but a "show policy interface di0" shows packets being matched but nothing being dropped and the link is saturated. I believe the policy needs to be applied to the virtual-access interface that comes up when PPP negotiates, but i'm not quite sure how this would be done since the use of vpdn-groups are no longer used. Relevent config posted. Any suggestions are greatly appreciated. *And yes I know the service-policy is not applied to the dialer interface...this was due to it not working. class-map match-any VoIP match ip rtp 16384 16383 match access-group name VoicePorts ! ! policy-map Voice class VoIP priority 256 ! ! ! ! ! interface Ethernet0 ip address 192.168.10.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Ethernet2 no ip address shutdown hold-queue 100 out ! interface ATM0 no ip address load-interval 30 no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point pvc 1/100 encapsulation aal5snap pppoe-client dial-pool-number 1 ! ! interface FastEthernet1 duplex auto speed auto ! interface FastEthernet2 duplex auto speed auto ! interface FastEthernet3 duplex auto speed auto ! interface FastEthernet4 duplex auto speed auto ! ! interface Dialer0 ip address negotiated ip mtu 1492 ip nat outside ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1412 dialer pool 1 no cdp enable ! ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Dialer0 ! ip http server no ip http secure-server ! no ip nat service skinny tcp port 2000 no ip nat service sip udp port 5060 ip nat inside source list 10 interface Dialer0 overload ! ! ip access-list extended VoicePorts permit udp any host *.*.*.* range 22026 62025 permit udp any host *.*.*.* range 22026 62025 access-list 10 permit 192.168.10.0 0.0.0.255 ___ 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] Baseline CoPP policies?
Hi Drew, have you looked at the following docs: http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html and http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html regards .siva On Tue, 7 Jul 2009, Daniel Dib wrote: Hi all, Does anyone have any baseline CoPP policies to put in place on a switch where you can't really anticipate the kind of traffic that will be coming into it but you need the IP INPUT processes, etc to stay at some level of control? I've seen the Cisco TTL Expiry attack documentation etc, are there any good generalized guidelines Cisco published or not? Thanks, -Drew This will probably be highly dependant on what platform you are running. What switch are we talking about? You should probably try to blast it with different types of traffic to see what it can handle. Will you be running dynamic routingprotocols? What protocols will you use for remote access etc? More info is needed if we are going to try to answer your question. /Daniel __ Information from ESET NOD32 Antivirus, version of virus signature database 4222 (20090707) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ 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] QoS on 837 using PPPoE
IIRC you need to apply it on the ATM interface e.g. Interface ATM0.1 point-to-point . . pvc 1/100 service-policy output Voice regards .siva On Tue, 7 Jul 2009, Clue Store wrote: Hi All, I am having a hard time trying to figure how to apply a QoS policy on this router. I have applied a few typical service-policies on the dialer interfaces, but a "show policy interface di0" shows packets being matched but nothing being dropped and the link is saturated. I believe the policy needs to be applied to the virtual-access interface that comes up when PPP negotiates, but i'm not quite sure how this would be done since the use of vpdn-groups are no longer used. Relevent config posted. Any suggestions are greatly appreciated. *And yes I know the service-policy is not applied to the dialer interface...this was due to it not working. class-map match-any VoIP match ip rtp 16384 16383 match access-group name VoicePorts ! ! policy-map Voice class VoIP priority 256 ! ! ! ! ! interface Ethernet0 ip address 192.168.10.1 255.255.255.0 ip nat inside ip virtual-reassembly ! interface Ethernet2 no ip address shutdown hold-queue 100 out ! interface ATM0 no ip address load-interval 30 no atm ilmi-keepalive dsl operating-mode auto ! interface ATM0.1 point-to-point pvc 1/100 encapsulation aal5snap pppoe-client dial-pool-number 1 ! ! interface FastEthernet1 duplex auto speed auto ! interface FastEthernet2 duplex auto speed auto ! interface FastEthernet3 duplex auto speed auto ! interface FastEthernet4 duplex auto speed auto ! ! interface Dialer0 ip address negotiated ip mtu 1492 ip nat outside ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1412 dialer pool 1 no cdp enable ! ip forward-protocol nd ip route 0.0.0.0 0.0.0.0 Dialer0 ! ip http server no ip http secure-server ! no ip nat service skinny tcp port 2000 no ip nat service sip udp port 5060 ip nat inside source list 10 interface Dialer0 overload ! ! ip access-list extended VoicePorts permit udp any host *.*.*.* range 22026 62025 permit udp any host *.*.*.* range 22026 62025 access-list 10 permit 192.168.10.0 0.0.0.255 ___ 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] REP
Hi Eric, REP and STP are incompatible with each other. if you are running REP on a set of links, you cannot run STP on them. that said we have the capability for a node that is running STP on a different set of links to work with the REP running on other links via the REP edge node neighbor feature. REP is able to generate Spanning Tree Change Notifications to send into the STP part of the network and propagate changes coming from the SPT domain into the REP domain. regards .siva On Fri, 26 Jun 2009, Eric Van Tol wrote: I'm looking at REP for use in a metro ethernet environment and am looking for some real world opinions on its effectiveness. The available white paper and documentation aren't 100% clear to me that STP can be disabled completely, or whether it should still run in addition to REP. My preference is to remove STP from any switch in our network, then burn it, spread its ashes in a field, let cattle graze on the grass, then burn the cattle and shoot their remains into space on a collision course with the sun. Apologies to animal rights activists, but this should give you an idea of how I really feel about Spanning Tree Protocol. Can anyone share any experiences they've had using REP? We primarily use ME3400s in a ring topology with each end of the ring terminating in a pair of 6509s. The 6509s, however, will be repurposed over the next few months as we replace them with an alternate vendor's equipment. Not sure if this matters, but figured I'd mention it. Right now, we use strictly layer 3 on all links between nodes on a ring, preventing us from taking advantage of the more advanced layer 2 and vrf-lite features of the ME3400s. This probably poor design decision was made due to previously perceived limitations with REP some years ago. Thanks in advance, evt ___ 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] PPPoA DSL up/up, no traffic
i think the ATM encap is dependent on the provider and their equipeent. for my provider I have been using aal5snap. the most common encap used to be AAL5SNAP (a few years back). On Tue, 2 Oct 2007, Scott Granados wrote: > I could be wrong but I think you have your encapsulation wrong. > > interface ATM0/0 > no ip address > no ip mroute-cache > no atm ilmi-keepalive > dsl operating-mode auto > pvc 0/35 > encapsulation aal5mux ppp dialer > dialer pool-member 1 > ! > ! > > - Original Message - > From: "Adam Greene" <[EMAIL PROTECTED]> > To: > Sent: Tuesday, October 02, 2007 10:58 AM > Subject: [c-nsp] PPPoA DSL up/up, no traffic > > >> Hi, >> >> I'm trying to configure a DSL line on a Cisco 1841 (C1841-IPBASE-M), >> Version >> 12.4(1c). >> >> The atm interface is plugged into a DSL line, it shows up/up, I have >> packets >> going out, but none coming back in. >> >> Do I have to do something in particular to initiate the connection? Are >> there obvious errors with the config? Perhaps I need to contact the ISP. >> >> Disclaimer: this is the first DSL line I've ever configured (might be >> obvious). >> >> Thanks for the help. >> Adam >> >> >> Here are the configurations so far, and some command / debug output: >> >> >> CONFIGS >> >> >> ! >> aaa new-model >> ! >> aaa session-id common >> ! >> mmi polling-interval 60 >> no mmi auto-configure >> no mmi pvc >> ! >> interface FastEthernet0/0 >> ip address x.x.x.x 255.255.252.0 >> duplex auto >> speed auto >> ! >> interface ATM0/0/0 >> no ip address >> no ip mroute-cache >> no atm ilmi-keepalive >> dsl operating-mode auto >> hold-queue 224 in >> pvc 0/35 >> encapsulation aal5snap >> protocol ppp dialer >> dialer pool-member 1 >> ! >> interface Dialer1 >> ip address negotiated >> ip mtu 1492 >> encapsulation ppp >> no ip mroute-cache >> dialer pool 1 >> dialer idle-timeout 0 >> dialer-group 1 >> ppp authentication pap callin >> ppp pap sent-username password 7 >> ! >> ip route 0.0.0.0 0.0.0.0 Dialer1 >> ! >> dialer-list 1 protocol ip permit >> ! >> end >> >> >> = >> SH INT ATM0/0/0 >> = >> >> ATM0/0/0 is up, line protocol is up >> Hardware is DSLSAR (with Alcatel ADSL Module) >> MTU 4470 bytes, sub MTU 4470, BW 832 Kbit, DLY 610 usec, >> reliability 255/255, txload 1/255, rxload 1/255 >> Encapsulation ATM, loopback not set >> Encapsulation(s): AAL5 AAL2, PVC mode >> 23 maximum active VCs, 256 VCs per VP, 1 current VCCs >> VC Auto Creation Disabled. >> VC idle disconnect time: 300 seconds >> Last input never, output 00:00:17, output hang never >> Last clearing of "show interface" counters never >> Input queue: 0/224/0/0 (size/max/drops/flushes); Total output drops: 0 >> Queueing strategy: Per VC Queueing >> 5 minute input rate 0 bits/sec, 0 packets/sec >> 5 minute output rate 0 bits/sec, 0 packets/sec >> 0 packets input, 0 bytes, 0 no buffer >> Received 0 broadcasts, 0 runts, 0 giants, 0 throttles >> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort >> 66050 packets output, 1056800 bytes, 0 underruns >> 0 output errors, 0 collisions, 0 interface resets >> 0 output buffer failures, 0 output buffers swapped out >> >> == >> DEBUG PPP NEGOTIATION >> == >> *Oct 2 15:51:10.173: %LINK-3-UPDOWN: Interface ATM0/0/0, changed state to >> up >> *Oct 2 15:51:13.173: %LINEPROTO-5-UPDOWN: Line protocol on Interface >> ATM0/0/0, >> changed state to up >> *Oct 2 15:51:13.173: %LINK-3-UPDOWN: Interface Virtual-Access2, changed >> state to up >> *Oct 2 15:51:13.173: %DIALER-6-BIND: Interface Vi2 bound to profile Di1 >> *Oct 2 15:51:13.173: Vi2 PPP: Using dialer call direction >> *Oct 2 15:51:13.173: Vi2 PPP: Treating connection as a callout >> *Oct 2 15:51:13.173: Vi2 PPP: Session handle[EF04] Session id[2] >> *Oct 2 15:51:13.173: Vi2 PPP: Phase is ESTABLISHING, Active Open >> *Oct 2 15:51:13.173: Vi2 PPP: No remote authentication for call-out >> *Oct 2 15:51:13.173: Vi2 LCP: O CONFREQ [Closed] id 173 len 10 >> *Oct 2 15:51:13.173: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) >> *Oct 2 15:51:15.161: Vi2 LCP: TIMEout: State REQsent >> *Oct 2 15:51:15.161: Vi2 LCP: O CONFREQ [REQsent] id 174 len 10 >> *Oct 2 15:51:15.161: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) >> *Oct 2 15:51:17.177: Vi2 LCP: TIMEout: State REQsent >> *Oct 2 15:51:17.177: Vi2 LCP: O CONFREQ [REQsent] id 175 len 10 >> *Oct 2 15:51:17.177: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) >> *Oct 2 15:51:19.193: Vi2 LCP: TIMEout: State REQsent >> *Oct 2 15:51:19.193: Vi2 LCP: O CONFREQ [REQsent] id 176 len 10 >> *Oct 2 15:51:19.193: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) >> *Oct 2 15:51:21.209: Vi2 LCP: TIMEout: State REQsent >> *Oct 2 15:51:21.209: Vi2 LCP: O CONFREQ [REQsent] id 177 len 10 >> *Oct 2 15:51:21.209: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) >> *Oct 2 15:51:23.225: Vi2 LCP: TIM
Re: [c-nsp] PPPoA DSL up/up, no traffic
iirc DSL line scrambling should be negotiated between the DSL interfaces. so if it is on or off it shouldn't matter. the virtual access interface will remain down untill PPP LCP (Line Control Protocol) is negotiated. since you are not getting any incoming PPP packets, LCP negotiation never starts. hence, your virtual access interface is up (phyiscal interface it's bound to is up), down (LCP not yet open, hence status is down). i think what you need to do is find out from your provider how your line is provisioned (which ATM VC, which encap, and if they are doing PPPoA with snap or mux encap or 1483 bridging). this will allow you to configure the router appropriately. one way to guss some of this is to see if your provider gave you a free DSL modem with your DSL link. based on it's capabilities and it's config you could guess with reasonable accuracies the answers to some of the above questions. cheers .siva On Tue, 2 Oct 2007, Adam Greene wrote: > Hi all, > > I appreciate the feedback. > > I tried these commands, but no dice: > > pvc 0/35 > encapsulation aal5mux ppp dialer > dialer pool-member 1 > > The router doesn't seem to accept the "atm route-bridge ip" command. I tried > on the atm interface and the pvc. > > I couldn't find a place to enter a "scrambling" or "no scrambling" command > either, unfortunately (someone suggested this off-list). > > I tried deleting and recreating the pvc on the cpe end, with no positive > results. > > I will contact the ISP and see if they can recreate the pvc on their end. > > One note: this probably doesn't mean anything, but I see interface > Virtual-Access 2 gets bound to Dialer1, but shows up/down, with lots of > outbound packets but no inbound packets. By contrast, int Virtual-Access 1 is > up/up but not bound to anything and is not passing traffic. I wonder if > that's relevant at all. > > Finally, here's some debug ppp neg and debug atm events output during the > setup phase. It appears the Vi2 LCP step is what is failing. > > *Oct 2 20:46:12.891: ATM0/0/0 dslsar_1a_reset: PLIM type is 18, Rate is > 832Mbps > *Oct 2 20:46:12.891: ATM0/0/0 dslsar_1a_shutdown: state=4 > *Oct 2 20:46:12.891: dslsar disable ATM0/0/0 > *Oct 2 20:46:12.895: DSL: SET: [DMTDSL_STOP -> DMTDSL_INIT] > *Oct 2 20:46:12.895: Resetting ATM0/0/0 > *Oct 2 20:46:12.895: dslsar_1a_config(ATM0/0/0) > *Oct 2 20:46:12.895: dslsar_1a_enable(ATM0/0/0) > *Oct 2 20:46:12.895: ATM0/0/0: dslsar_init > *Oct 2 20:46:12.899: ATM0/0/0 dslsar_MatchSARTxToLineSpeed(): usbw 832, > clkPerCell 18004 prev_clkPerCell 9702 > *Oct 2 20:46:12.899: ATM0/0/0 dslsar_MatchSARTxToLineSpeed(): Changing line > speed from fast to slow > *Oct 2 20:46:13.015: ATM0/0/0 dslsar_update_us_bandwidth(): upstream bw =832 > Kbps > *Oct 2 20:46:13.535: (ATM0/0/0)1a_enable: delay activation of vcd=2, > vc=0x62EABDBC > *Oct 2 20:46:13.539: DSL: SM: [DMTDSL_STOP -> DMTDSL_INIT] > *Oct 2 20:46:13.539: DSL: SM: [DMTDSL_INIT -> DMTDSL_DLOAD_1] > *Oct 2 20:46:13.539: DSL: Downloading ASW_init_3_8_131.bin > *Oct 2 20:46:13.547: DSL:(ATM0/0/0) Downloaded 5 blocks... Finished! > *Oct 2 20:46:13.547: DSL(ATM0/0/0): Sent command 0x14 > *Oct 2 20:46:14.891: %LINK-3-UPDOWN: Interface ATM0/0/0, changed state to > down > *Oct 2 20:46:14.891: dslsar_atm_lineaction(ATM0/0/0): state=0 > *Oct 2 20:46:14.891: dslsar_atm_lineaction: REG_INVOKE: line down > *Oct 2 20:46:17.455: DSL: Received response: 0x80 > *Oct 2 20:46:17.455: DSL: SM: [DMTDSL_DLOAD_1 -> DMTDSL_DLOAD_2] > *Oct 2 20:46:17.539: DSL: Downloading ASW_R3_8_131.bin > *Oct 2 20:46:17.687: DSL(ATM0/0/0): Downloaded 100 blocks > *Oct 2 20:46:17.835: DSL(ATM0/0/0): Downloaded 200 blocks > *Oct 2 20:46:17.979: DSL(ATM0/0/0): Downloaded 300 blocks > *Oct 2 20:46:18.127: DSL(ATM0/0/0): Downloaded 400 blocks > *Oct 2 20:46:18.275: DSL(ATM0/0/0): Downloaded 500 blocks > *Oct 2 20:46:18.419: DSL(ATM0/0/0): Downloaded 600 blocks > *Oct 2 20:46:18.571: DSL(ATM0/0/0): Downloaded 700 blocks > *Oct 2 20:46:18.715: DSL(ATM0/0/0): Downloaded 800 blocks > *Oct 2 20:46:18.863: DSL(ATM0/0/0): Downloaded 900 blocks > *Oct 2 20:46:19.011: DSL(ATM0/0/0): Downloaded 1000 blocks > *Oct 2 20:46:19.155: DSL(ATM0/0/0): Downloaded 1100 blocks > *Oct 2 20:46:19.303: DSL(ATM0/0/0): Downloaded 1200 blocks > *Oct 2 20:46:19.451: DSL(ATM0/0/0): Downloaded 1300 blocks > *Oct 2 20:46:19.475: DSL:(ATM0/0/0) Downloaded 1317 blocks... Finished! > *Oct 2 20:46:19.475: DSL(ATM0/0/0): Sent command 0x14 > *Oct 2 20:46:21.475: changed current state to do open!! > *Oct 2 20:46:21.475: DSL: SM: [DMTDSL_DLOAD_2 -> DMTDSL_DO_OPEN] > *Oct 2 20:46:21.475: DSL: Send ADSL_OPEN command. > *Oct 2 20:46:21.475: DSL(ATM0/0/0): Using subfunction 0x15 > *Oct 2 20:46:21.479: DSL(ATM0/0/0): Sent command 0x3 > *Oct 2 20:46:23.979: DSL(ATM0/0/0): 1: Modem state = 0x8 > *Oct 2 20:46:26.479: DSL(ATM0/0/0): 2: Modem state = 0x8 > *Oct 2 20:46:28.979: DSL(ATM0/0/0): 3: Modem state = 0x8 > *
Re: [c-nsp] PPPoA DSL up/up, no traffic
if this is a bridged 1483 circuit (the newer DSL installations seem to be doing this vs PPPoA), then the config will need to be modified. you shouldn't be using a dialer interface. you will want to configure the interface for RBE (route bridge encap) as described below. and place the "ip address negotiated" on the ATM subint. On Tue, 2 Oct 2007, Majdi S. Abbas wrote: > On Tue, Oct 02, 2007 at 01:58:51PM -0400, Adam Greene wrote: >> I'm trying to configure a DSL line on a Cisco 1841 (C1841-IPBASE-M), Version >> 12.4(1c). >> >> The atm interface is plugged into a DSL line, it shows up/up, I have packets >> going out, but none coming back in. >> >> Do I have to do something in particular to initiate the connection? Are >> there obvious errors with the config? Perhaps I need to contact the ISP. > > Try placing the following on the VC: > > atm route-bridge ip > > This should get it to actually recognize those RFC1483 bridged > frames and do the right thing with them. > > --msa > ___ > 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] PPPoA DSL up/up, no traffic
config-wise, it looks ok. only thing you need to do (if necessary) is to configure NAT and translate between your FE and Dialer interface. otherwise you won't be able to get out onto the internet. That said, sounds like your DSL layer is up, but you have a L2/L3 issue. you are not getting any incoming PPP packets. the reasons could be as follows: a) you are using the wrong ATM VC b) the upstream SP has not terminated the VC on an aggregator c) some other problem upstream of the DSLAM i had a similar problem recently (~4 months ago) when my 827 went down (after working for 2+ years). a call to the 1st level tech support put me through the did you power cycle the PC 20 questions. I told them i already troubleshot my side and the issue was a L2/L3 issue and asked for escalation to their next tier. their 2nd level support just rebuilt the circuit and things came back up as we were on the line. Once the PPP session is fixed and you get an IP address on your dialer interface, you may need to configure NAT if required. cheers .siva On Tue, 2 Oct 2007, Adam Greene wrote: > Hi, > > I'm trying to configure a DSL line on a Cisco 1841 (C1841-IPBASE-M), Version > 12.4(1c). > > The atm interface is plugged into a DSL line, it shows up/up, I have packets > going out, but none coming back in. > > Do I have to do something in particular to initiate the connection? Are > there obvious errors with the config? Perhaps I need to contact the ISP. > > Disclaimer: this is the first DSL line I've ever configured (might be > obvious). > > Thanks for the help. > Adam > > > Here are the configurations so far, and some command / debug output: > > > CONFIGS > > > ! > aaa new-model > ! > aaa session-id common > ! > mmi polling-interval 60 > no mmi auto-configure > no mmi pvc > ! > interface FastEthernet0/0 > ip address x.x.x.x 255.255.252.0 > duplex auto > speed auto > ! > interface ATM0/0/0 > no ip address > no ip mroute-cache > no atm ilmi-keepalive > dsl operating-mode auto > hold-queue 224 in > pvc 0/35 > encapsulation aal5snap > protocol ppp dialer > dialer pool-member 1 > ! > interface Dialer1 > ip address negotiated > ip mtu 1492 > encapsulation ppp > no ip mroute-cache > dialer pool 1 > dialer idle-timeout 0 > dialer-group 1 > ppp authentication pap callin > ppp pap sent-username password 7 > ! > ip route 0.0.0.0 0.0.0.0 Dialer1 > ! > dialer-list 1 protocol ip permit > ! > end > > > = > SH INT ATM0/0/0 > = > > ATM0/0/0 is up, line protocol is up > Hardware is DSLSAR (with Alcatel ADSL Module) > MTU 4470 bytes, sub MTU 4470, BW 832 Kbit, DLY 610 usec, > reliability 255/255, txload 1/255, rxload 1/255 > Encapsulation ATM, loopback not set > Encapsulation(s): AAL5 AAL2, PVC mode > 23 maximum active VCs, 256 VCs per VP, 1 current VCCs > VC Auto Creation Disabled. > VC idle disconnect time: 300 seconds > Last input never, output 00:00:17, output hang never > Last clearing of "show interface" counters never > Input queue: 0/224/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: Per VC Queueing > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 0 packets input, 0 bytes, 0 no buffer > Received 0 broadcasts, 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 66050 packets output, 1056800 bytes, 0 underruns > 0 output errors, 0 collisions, 0 interface resets > 0 output buffer failures, 0 output buffers swapped out > > == > DEBUG PPP NEGOTIATION > == > *Oct 2 15:51:10.173: %LINK-3-UPDOWN: Interface ATM0/0/0, changed state to > up > *Oct 2 15:51:13.173: %LINEPROTO-5-UPDOWN: Line protocol on Interface > ATM0/0/0, > changed state to up > *Oct 2 15:51:13.173: %LINK-3-UPDOWN: Interface Virtual-Access2, changed > state to up > *Oct 2 15:51:13.173: %DIALER-6-BIND: Interface Vi2 bound to profile Di1 > *Oct 2 15:51:13.173: Vi2 PPP: Using dialer call direction > *Oct 2 15:51:13.173: Vi2 PPP: Treating connection as a callout > *Oct 2 15:51:13.173: Vi2 PPP: Session handle[EF04] Session id[2] > *Oct 2 15:51:13.173: Vi2 PPP: Phase is ESTABLISHING, Active Open > *Oct 2 15:51:13.173: Vi2 PPP: No remote authentication for call-out > *Oct 2 15:51:13.173: Vi2 LCP: O CONFREQ [Closed] id 173 len 10 > *Oct 2 15:51:13.173: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) > *Oct 2 15:51:15.161: Vi2 LCP: TIMEout: State REQsent > *Oct 2 15:51:15.161: Vi2 LCP: O CONFREQ [REQsent] id 174 len 10 > *Oct 2 15:51:15.161: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) > *Oct 2 15:51:17.177: Vi2 LCP: TIMEout: State REQsent > *Oct 2 15:51:17.177: Vi2 LCP: O CONFREQ [REQsent] id 175 len 10 > *Oct 2 15:51:17.177: Vi2 LCP:MagicNumber 0x2FA57203 (0x05062FA57203) > *Oct 2 15:51:19.193: Vi2 LCP: TIMEout: State REQsent > *Oct 2 15:51:19.193: Vi2 LCP: O CONFREQ [REQsent] id 176 len 10 >
Re: [c-nsp] Information on rate limit issue
the C3750 is capable of wire rate forwarding so there should be no TCP performance issue with vanilla forwarding. if you are having issues when rate limiting is enabled it could be due to any number of reasons (e.g. it is behaving as per configuration :) ) some more detail might help someone on the list answer your question. such as topology, configuration, traffic pattern, etc. cheers .siva On Tue, 12 Jun 2007, Paul Schopis wrote: > I am needing to find a concise description of an issue on the Cisco 3550 or > 3750. As I understand it there is an issue with getting good TCP performance > due to a hardware limitation (Broadcom Chipset?) that will not allow one to > properly set the burst size. I would like to understand this issue better and > seem to be having difficulty finding a good description of the issue. > > Thanks in advance, > Paul > > > ___ > 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] Applying ACL
if you are using a plaform that supports the "config replace" feature, you could choose to build your new ACL off-line then do a replace of the partial config with the new ACL... :) cheers .siva On Thu, 31 May 2007, Gert Doering wrote: > Hi, > > On Wed, May 30, 2007 at 01:33:21PM -0700, Kevin Graham wrote: >> If you are wiping them out, you should always remove them to be safe >> (even if weren't default-deny behavior when missing, there is an >> unavoidable window between creation and completion). > > Just to correct this small bit: default in IOS for packet ACLs is > "default-permit" *if the ACL is completely missing*. > > But usually you're dead in the water as soon as you copy-and-paste a > new version of the ACL and the first line gets active, prohibiting any > further lines to go through... > > gert > > -- > USENET is *not* the non-clickable part of WWW! > //www.muc.de/~gert/ > Gert Doering - Munich, Germany [EMAIL PROTECTED] > fax: +49-89-35655025[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/ > ___ 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] GRE router recommendations
Hi Simon, GRE is not support on the cat3k switches. cheers .siva On Fri, 20 Apr 2007, Simon Lockhart wrote: > Is anyone aware of any documents detailing the GRE performance of different > Cisco devices? > > I'm in the process of designing a network which will need to tunnel back to > the core, for which I'm intending to use GRE. > > At the sites where I need to tunnel from are currently 3550 switches (and > a few 3750's). What sort of GRE performance should I see from those? > > Assuming I use something other than the 3550 for GRE, what device would give > me GRE at 100Mbps? 300Mbps? 500Mbps? 1Gbps? 5Gbps? > > Many thanks, > > Simon > ___ > 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] 3750 - duplicate arp replies on SVIs with input ACLs applied
Hi Calin, there is no way the IP ACL would be duplicating the packet. However, the ACL may count the packet more then once if the packet is software switched as the ACLs are applied at each switching path. The reason for the ACL count is described in - CSCdv12330. the output of "debug ip arp" on the 3k would be interesting to see what is actually happening. can you enable packet sniffing on the linux box to see how many ARP requests are actually going out and how many coming back? also what version of code are you running? and is this a stacked configuration or are you using the C3750 as a standalone box? cheers .siva On Tue, 27 Mar 2007, Calin VELEA wrote: > Hello cisco-nsp, > > Don't know if this is normal or > specific to the 3750, but here is the > problem: > > interface Vlan1540 > ip address 10.99.99.3 255.255.255.0 > ip access-group test-acl in > no ip redirects > no ip unreachables > no ip proxy-arp > end > > The acl is as simple as: > > #sh access-lists test-acl > Extended IP access list test-acl >250 permit ip any any > > > On a Linux box in the same vlan having IP 10.99.99.1, > I run: > > arping -I eth1.1540 10.99.99.3 > > and for each ARP request, I get duplicate ARP replies. > > [EMAIL PROTECTED]:~# arping -I eth1.1540 10.99.99.3 > ARPING 10.99.99.3 from 10.99.99.1 eth1.1540 > Unicast reply from 10.99.99.3 [00:11:93:4D:C8:58] 1.346ms > Unicast reply from 10.99.99.3 [00:11:93:4D:C8:58] 1.586ms > > > Unicast reply from 10.99.99.3 [00:11:93:4D:C8:58] 1.375ms > Unicast reply from 10.99.99.3 [00:11:93:4D:C8:58] 1.716ms > > > ...so on > > > If I remove the input acl from the interface, things are > back to normal, one ARP reply per ARP request. > I am seeing duplicate ARP replies even if I apply > a non-existent acl to the interface. > > I noticed this because duplicate ARP replies caused packet > loss in normal traffic for a few seconds, when the Linux box > was renewing the ARP entry for the Cisco gateway. As soon as I set up > static ARP for it on the Linux machine, the loss was gone. > > Running 'sh interface Vlan1540' shows the "packets input" > counter increasing by 2 when the acl is applied, even if > the Linux box sends only one arp request (checked this > with tcpdump). It looks like the IP acl is duplicating the > ARP requests somehow. > > > Can someone explain this behavior? > > > > -- > Best regards, > Calin mailto:[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/ > ___ 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/
