Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX.
Harry, Thanks for sharing, but I don't see Cisco 1/3/45 nor Cisco 1/3/46. The Brocade side is showing disabled. Have you tried disabling the Brocade 3/19 and 3/20 and then re-enabling them one at a time? Frank -Original Message- From: Harry Hambi - Atos [mailto:harry.ha...@bbc.co.uk] Sent: Friday, October 24, 2014 3:12 AM To: 'Frank Bulk' Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX. Hi Frank, Please find attached information requested. I've tried disabling lacp rate fast no joy. The working half of the trunk has this command enabled. Cisco --1/3/45 --MLX 3/19non-working trunk Cisco --1/3/46 --MLX 3/20 Cisco --2/3/45MLX 8/19 working trunk. Cisco --2/3/46MLX 8/20 Rgds Harry Harry Hambi BEng(Hons) MIET Rsgb -Original Message- From: Frank Bulk [mailto:frnk...@iname.com] Sent: 24 October 2014 03:10 To: Harry Hambi - Atos Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX. Thanks for sharing. Could you please share the Cisco interface configs (Po345 and each of the LAG members)? Note that the Cisco is set to use fast while Brocade is set to use slow. I would start with setting them the same. Frank -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Harry Hambi - Atos Sent: Thursday, October 23, 2014 4:11 AM To: james jones Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX. Hi James, Yes good idea, please find attached configuration of Cisco Brocade switches. Not much on the Brocade end see attached. The ports with the error message LACP-BLOCKED are 3/19 3/20 on the Brocade end. Rgds Harry Harry Hambi BEng(Hons) MIET Rsgb From: james.v...@gmail.com [mailto:james.v...@gmail.com] On Behalf Of james jones Sent: 22 October 2014 16:07 To: Harry Hambi - Atos Cc: Nick Hilliard; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX. Config snippets would be useful. On Wed, Oct 22, 2014 at 10:42 AM, Harry Hambi - Atos harry.ha...@bbc.co.ukmailto:harry.ha...@bbc.co.uk wrote: Yes, I have checked config of working Trunk and no difference. Rgds Harry Harry Hambi BEng(Hons) MIET Rsgb -Original Message- From: Nick Hilliard [mailto:n...@foobar.orgmailto:n...@foobar.org] Sent: 22 October 2014 15:39 To: Harry Hambi - Atos; 'cisco-nsp@puck.nether.netmailto:cisco-nsp@puck.nether.net' Subject: Re: [c-nsp] LACP Trunk between Cisco VSS and Brocade MLX. On 22/10/2014 15:31, Harry Hambi - Atos wrote: Has anyone seen this error ?. yes, it's normally caused by misconfiguration. Both brocade netiron and cisco IOS have mature 802.3ad/LACP implementations which interoperate nicely. Nick ___ cisco-nsp mailing list cisco-nsp@puck.nether.netmailto: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] Simple ACL not working 7600
We do have a good AUP that allows us to interact with customers on things like this. We don't have a captive portal, and even if we did, I wouldn't block over 10% of our customers! That would be a career changing move. And even more so if there's no reasonable mitigation other than buying a new SOHO router. Blocking port 1900 is clearly the cleaner mitigation approach. Frank -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Roland Dobbins Sent: Monday, August 04, 2014 9:09 PM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Simple ACL not working 7600 On Aug 5, 2014, at 9:01 AM, Frank Bulk frnk...@iname.com wrote: Unfortunately I'm not in the position to dictate which routers my residential subscribers use on their broadband connection, Is there anything in your AUP about customers running abusable services? If not, it might be time to consider revising it. The AUP is the single most effective security tool a network operator has, if it's both complete and enforced (the second most effective security tool a network operator has is the RFP). and the quantity of subs (over 1000) makes forcing them to remediate nigh impossible. Do you have some sort of capture/quarantine system to force a subscriber browsing the Web into a portal which can be used to display a page telling them that they've an issue they must remediate? If not, it might be a good idea to look at implementing one. -- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Equo ne credite, Teucri. -- Laocoön ___ 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] Netflow analysis tools?
Scott, It looks like the Netflow monitoring of PRTG is only for 30 days -- if you want to try something that doesn't expire, but only has the last hour of information, look at SolarWinds' product: http://www.solarwinds.com/products/freetools/appflow-jflow-sflow-analyzer.aspx Frank -Original Message- From: cisco-nsp [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of David beckett Sent: Monday, May 19, 2014 12:45 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Netflow analysis tools? Hello Scott, PRTG Network Monitor can present Netflow monitoring in pretty graphs, including usage over time, and top talkers. It is commercial / paid for, but I think you can test up to 10 sensors (monitored objects) without a license. That means 10 Netflow instances if you pause or stop monitoring everything else. HTH Yours sincerely, Sincères salutations, Mit freundlichen Grüssen, Distinti saluti, David BECKETT Network Service Delivery Switzerland DACH IMT IBM Suisse IBM Banking Solutions Center Avenue de la Vallombreuse 100 CH - 1008 PRILLY Switzerland Hotline / Piquet Téléphone : +41 (0) 58 333 68 23 Téléphone Direct : +41 (0) 58 333 24 07 Téléphone Mobile : +41 (0) 765 54 07 23 Fax: +41 (0) 21 683 0094 mailto: david.beck...@ch.ibm.com http://www.ibm.ch From: Scott Granados sc...@granados-llc.net To: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Date: 16.05.2014 16:17 Subject:[c-nsp] Netflow analysis tools? Sent by:cisco-nsp cisco-nsp-boun...@puck.nether.net Good morning, I’m starting to work with Net Flow data and am looking for both good background documentation to get more familiar and suggestions for an analyzer. I already have data collection working so I’m looking for suggestions for something to turn that data in to something meaningful, preferably open source or paid with a trial period to evaluate. Are there any tools that run on the Mac that anyone would suggest for processing the nfcapd files or something with a web front end I can install in a *nix environment. Any general documentation or specific tool recommendations would be most welcome. Thank you Scott ___ 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/
[c-nsp] Platform feature development for 7200
I learned from our SE today that platform feature development for the 7200 has ended, and that SB code train is going to be EOL very soon. The recommendation is to move to the ASR1K. This affects us because we needed both IPv6 PBR and DHCPv6-PD with automatic route insertion on the same code release. Regards, Frank Bulk ___ 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] ARP strangeness
No, the FTTH doesn't allow broadcasts, at all. =( Right now the ARP timeout is 480 seconds, CAM is 540 seconds, and the FTTH's FDB is 900 seconds. If the CPE had a reasonable ARP timeout, it would refresh the ARP entry for it's default gateway (7609) upon the first CPE-initiated packet after a period of deafness, but it doesn't. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Wednesday, January 12, 2011 4:09 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On 01/11/2011 08:06 PM, Keegan Holley wrote: That doesn't make sense though. The cpe will need to broadcast for the initial request and after reboots regardless of what the provider router does. The device that was blocking broadcast was a third party FTTH device. I get the feeling I'm missing something here though. Maybe it only allows broadcast for a specific interval after it detects a link down/link up. As I understood it, the FTTH device permits broadcasts but they're only flooded on ports with FDB entries (!). So, once the FDB entry expires (as a result of a quiet CPE) it's impossible to refresh the ARP (and FDB) entry from the outside - only the CPE could do it, and it isn't doing it. Therefore there is a need to tune ARP timers well below FDB timers on the FTTH device, to ensure that even for quiet hosts, ARP refresh traffic from the 7600 keeps the state. This does seem like a broken smart layer2 to me, but I'm sure someone thought it was a good idea ;o) ___ 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] ARP strangeness
Yes, broadcast traffic blocked from the headend toward the CPE. The challenge is as you described, getting the CPE in the home environment to ARP for its default gateway more regularly. Frank -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com] Sent: Wednesday, January 12, 2011 8:58 AM To: Keegan Holley Cc: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness I thought it was stated it only blocked them from the headend out towards the CPE. As long as you had them originated from the CPE (which in a home environment makes some sense as it's usually traffic originated from the CPE not servers hosted there..typically that is) one wouldn't need broadcast from the headend router if the refresh was unicast. I'm not advocating for that as the optimal solution by any means. ;) Rodney On 1/11/11 3:06 PM, Keegan Holley wrote: On Tue, Jan 11, 2011 at 2:50 PM, Rodney Dunn rod...@cisco.com mailto:rod...@cisco.com wrote: On 1/11/11 11:49 AM, Keegan Holley wrote: Possibly a stupid question, but I thought ARP had to be broadcast because the mac address of the destination was unknown. That is true for the first request. For subsequent arp refreshes the most efficient way is to unicast it. That's what I said. However, having an ethernet that doesn't support broadcast would make that first entry impossible. The problem would repeat after reboots or power outages. If the CPE has the correct mac address to unicast an ARP request, why would it need to arp in the first place? To make sure the CPE is still alive and responding. RIght but it can only do that if it has already successfully arp'd so I think we are saying the same thing. I suppose I can understand renewing the entry via unicast, but there will always be a need for broadcast ARP. It just seems strange to implement an ethernet based device and block all broadcast traffic. Am I missing something? I didn't go back and read the entire thread to remember what was blocking the broadcast and understand the thought logic of whey they do it. It may would be, and possibly has some logic to it, that in a CPE environment you always rely on traffic originated at the CPE to trigger the arp so you block broadcast out to the CPE not coming from the CPE. That doesn't make sense though. The cpe will need to broadcast for the initial request and after reboots regardless of what the provider router does. The device that was blocking broadcast was a third party FTTH device. I get the feeling I'm missing something here though. Maybe it only allows broadcast for a specific interval after it detects a link down/link up. On Mon, Jan 10, 2011 at 5:27 PM, Frank Bulk frnk...@iname.com mailto:frnk...@iname.com mailto:frnk...@iname.com mailto:frnk...@iname.com wrote: Thanks for explaining. Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP RENEW and DHCP DISCOVER, and because the access gear blocks all broadcast traffic, the 7609-S will never (re-)populate its ARP entry. I'm going to see if the Linksys BEFRS41 has a configurable ARP expiration timer. If so, dropping it to 10 minutes would cause it to unicast ARP for the default gateway, which would resolve the issue. Another possible option, I guess, is to extend the 7609-S ARP expiration to a longer time interval, but if the BEFRS41 is silent for even a second longer than the ARP timer, then I'm still stuck. I should really look at the behavior of other CPE to see how often they unicast ARP. Frank -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com mailto:rod...@cisco.com mailto:rod...@cisco.com mailto:rod...@cisco.com] Sent: Monday, January 10, 2011 1:30 PM To: frnk...@iname.com mailto:frnk...@iname.com mailto:frnk...@iname.com mailto:frnk...@iname.com Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness It only gets updated on getting and ARP packet from the host. It is not updated based on L3 data level traffic flowing to/from the host. Rodney On 1/10/11 11:43 AM, Frank Bulk wrote: Does the ARP cache get populated, or updated, if the traffic comes into an L3 interface, or is it only populated
Re: [c-nsp] ARP strangeness
Keegan: You're correct - without broadcast support, re-population initiated from the 7609 is impossible. Once it's expired, the FTTH access gear's design, which blocks broadcast traffic, makes it impossible for the CPE to respond to the broadcast ARP. The FTTH access gear never allows broadcast traffic to ingress from the 7609. So the only thing that can re-populate the 7609's ARP cache is an ARP request by the CPE, *but* the CPE only does that after a DHCP exchange after power on, never again, even after a full DHCP exchange. Frank From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Tuesday, January 11, 2011 2:07 PM To: rod...@cisco.com Cc: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On Tue, Jan 11, 2011 at 2:50 PM, Rodney Dunn rod...@cisco.com wrote: On 1/11/11 11:49 AM, Keegan Holley wrote: Possibly a stupid question, but I thought ARP had to be broadcast because the mac address of the destination was unknown. That is true for the first request. For subsequent arp refreshes the most efficient way is to unicast it. That's what I said. However, having an ethernet that doesn't support broadcast would make that first entry impossible. The problem would repeat after reboots or power outages. If the CPE has the correct mac address to unicast an ARP request, why would it need to arp in the first place? To make sure the CPE is still alive and responding. RIght but it can only do that if it has already successfully arp'd so I think we are saying the same thing. I suppose I can understand renewing the entry via unicast, but there will always be a need for broadcast ARP. It just seems strange to implement an ethernet based device and block all broadcast traffic. Am I missing something? I didn't go back and read the entire thread to remember what was blocking the broadcast and understand the thought logic of whey they do it. It may would be, and possibly has some logic to it, that in a CPE environment you always rely on traffic originated at the CPE to trigger the arp so you block broadcast out to the CPE not coming from the CPE. That doesn't make sense though. The cpe will need to broadcast for the initial request and after reboots regardless of what the provider router does. The device that was blocking broadcast was a third party FTTH device. I get the feeling I'm missing something here though. Maybe it only allows broadcast for a specific interval after it detects a link down/link up. On Mon, Jan 10, 2011 at 5:27 PM, Frank Bulk frnk...@iname.com mailto:frnk...@iname.com wrote: Thanks for explaining. Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP RENEW and DHCP DISCOVER, and because the access gear blocks all broadcast traffic, the 7609-S will never (re-)populate its ARP entry. I'm going to see if the Linksys BEFRS41 has a configurable ARP expiration timer. If so, dropping it to 10 minutes would cause it to unicast ARP for the default gateway, which would resolve the issue. Another possible option, I guess, is to extend the 7609-S ARP expiration to a longer time interval, but if the BEFRS41 is silent for even a second longer than the ARP timer, then I'm still stuck. I should really look at the behavior of other CPE to see how often they unicast ARP. Frank -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com mailto:rod...@cisco.com] Sent: Monday, January 10, 2011 1:30 PM To: frnk...@iname.com mailto:frnk...@iname.com Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness It only gets updated on getting and ARP packet from the host. It is not updated based on L3 data level traffic flowing to/from the host. Rodney On 1/10/11 11:43 AM, Frank Bulk wrote: Does the ARP cache get populated, or updated, if the traffic comes into an L3 interface, or is it only populated upon a successful ARP response? Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net mailto:cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rodney Dunn Sent: Wednesday, January 05, 2011 7:38 AM To: Jeff Kell Cc: cisco-nsp@puck.nether.net mailto:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On 1/4/11 11:43 PM, Jeff Kell wrote: On 1/4/2011 9:01 PM, Rodney Dunn wrote: There were some changes to ARP at one point to provide some more triggered capability. I don't recall exactly what that was but the default behavior for many years was that we send a unicast arp to the destination 60 seconds prior to the arp timer set to expire. If we don't get a response we send it again when the timer pops and if no response
Re: [c-nsp] ARP strangeness
There's no way for a smart L2 could compensate for the broadcast issue. With a broadcast ARP the MAC address is not known, unlike a unicast ARP where it is. So the only way for that broadcast ARP to make it to the CPE, which is unknown, is to blast it out to all the FTTH ports. The FTTH vendor is going to support MACFF (http://en.wikipedia.org/wiki/MAC-Forced_Forwarding), but that doesn't really address the issue I've been having. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Keegan Holley Sent: Wednesday, January 12, 2011 7:26 AM To: Phil Mayers Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On Wed, Jan 12, 2011 at 5:08 AM, Phil Mayers p.may...@imperial.ac.ukwrote: On 01/11/2011 08:06 PM, Keegan Holley wrote: That doesn't make sense though. The cpe will need to broadcast for the initial request and after reboots regardless of what the provider router does. The device that was blocking broadcast was a third party FTTH device. I get the feeling I'm missing something here though. Maybe it only allows broadcast for a specific interval after it detects a link down/link up. As I understood it, the FTTH device permits broadcasts but they're only flooded on ports with FDB entries (!). So, once the FDB entry expires (as a result of a quiet CPE) it's impossible to refresh the ARP (and FDB) entry from the outside - only the CPE could do it, and it isn't doing it. Therefore there is a need to tune ARP timers well below FDB timers on the FTTH device, to ensure that even for quiet hosts, ARP refresh traffic from the 7600 keeps the state. This does seem like a broken smart layer2 to me, but I'm sure someone thought it was a good idea ;o) Thanks, I knew I had missed a detail somewhere. It may be a longer route but I'd also send a feature request to the FTTH vendor. Opening up all broadcast has potential security implications. However, making the smart layer-2 a little smarter and may be in order. They could change the device so that it could recognize when the CPE was trying to wake up. They could also implement some sort of directed broadcast where arp and other protocols sent as broadcasts are only replicated to a single device. Implementing something similar to cisco private vlans would also work here. ___ 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] ARP strangeness
The order in which it fails (7609's ARP cache, 7609's MAC address table, and FTTH gear's forwarding bridge table) has not yet been made clear, because every since I started capturing state every 2 minutes, a week ago, it hasn't happened again. What you're describing should be all true. My only assumption at this point in time is that the pre-expiry and expiry ARPs don't make their way to the FTTH gear, and its forwarding bridge table expires its entries. Frank -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com] Sent: Tuesday, January 11, 2011 6:51 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness Frank, Maybe you could put it in a timeline for me as i think I'm still missing what exactly is failing. Sorry, a bit slow the last few days. The 7600 should send a *unicast* arp to every entry in it's arp cache 60 seconds prior to what you have the arp timer set to. It will then send another just at the arp timer expiring *if* it didn't get a response to the first one. So if your arp timer on the 7600 is low enough it should keep L2 mac forwarding state alive on all transit devices out to the CPE no? Broadcast is only sent when the L2 mapping isn't known. Rodney On 1/10/11 5:27 PM, Frank Bulk wrote: Thanks for explaining. Since the Linksys BEFRS41 does not ARP regularly, even after a DHCP RENEW and DHCP DISCOVER, and because the access gear blocks all broadcast traffic, the 7609-S will never (re-)populate its ARP entry. I'm going to see if the Linksys BEFRS41 has a configurable ARP expiration timer. If so, dropping it to 10 minutes would cause it to unicast ARP for the default gateway, which would resolve the issue. Another possible option, I guess, is to extend the 7609-S ARP expiration to a longer time interval, but if the BEFRS41 is silent for even a second longer than the ARP timer, then I'm still stuck. I should really look at the behavior of other CPE to see how often they unicast ARP. Frank -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com] Sent: Monday, January 10, 2011 1:30 PM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness It only gets updated on getting and ARP packet from the host. It is not updated based on L3 data level traffic flowing to/from the host. Rodney On 1/10/11 11:43 AM, Frank Bulk wrote: Does the ARP cache get populated, or updated, if the traffic comes into an L3 interface, or is it only populated upon a successful ARP response? Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Rodney Dunn Sent: Wednesday, January 05, 2011 7:38 AM To: Jeff Kell Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On 1/4/11 11:43 PM, Jeff Kell wrote: On 1/4/2011 9:01 PM, Rodney Dunn wrote: There were some changes to ARP at one point to provide some more triggered capability. I don't recall exactly what that was but the default behavior for many years was that we send a unicast arp to the destination 60 seconds prior to the arp timer set to expire. If we don't get a response we send it again when the timer pops and if no response we invalidate the ARP entry. Umm, that sort of rocks my boat with regard to network monitoring assumptions... We have one of those NMS systems that periodically reads L2 devices for mac-address/port mapping and reads L3 devices ARP for mac-to-IP mapping. Ideally, there should be no missing links (if the MAC is found, hopefully the ARP/IP is found, and vice-versa). That still holds true as long as a timer (sam cam ager) didn't pop sooner than your arp refresh timer. For the default mac-address aging time of 300 seconds, I had this notion that setting the ARP timeouts to 270 seconds would necessitate the router ARPing the device (assuming active traffic) prior to the mac-address aging out, keeping the mac-address table populated. Keep the other timers 60+ seconds out to be safe. But if the Cisco L3 behavior is to gratuitously do this for me before the ARP timeout... that changes things a bit. Is this default behavior across all the Cats, or just the 6500/7600? Is it supervisor-specific? Traditionally generic to all of IOS. There may have been some platform specific thing that changed here that I have missed in the last couple of years though. Rodney Jeff ___ 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] ARP strangeness
VLAN per customer provides L2 separation/protection and would avoid the problems we've had. Just I don't like the (lack of) scalability of (extra) management of that approach. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jared Mauch Sent: Wednesday, January 19, 2011 9:41 AM To: Tim Franklin Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On Jan 19, 2011, at 5:16 AM, Tim Franklin wrote: - Gert Doering g...@greenie.muc.de wrote: This sounds like a very very stupid design in the FTTH gear. But either not unique, or on some popular gear. I've recently reviewed the spec for a wholesale FTTH offering from a certain incumbent which contains exactly the same caveats. In my particular case, I'd be sticking a managed Cisco on the end of the service generating (and receiving) IPSLA probes if nothing else, so there should never be silence long enough for the MAC learning to time out. It was a bit of a WTF? moment, though... I've been continuing research on doing a small FTTH deployment, and my general consensus/balancing point starts to look somewhere between: 1) Put everyone on a large(r) broadcast domain with bidi sfps (something that would be nice if cisco would support more natively) 2) use a variety of kludges such as occam or other ftth gear to actually terminate and possibly vlan/qos for voip, iptv, etc to make it happen. Having not asked Frank what hardware he is using, it seems like It's a bug that should be addressed. The security model is intending to block some activity but is actually creating greater problems. Either the gear should act more like a true bridge, or support the features necessary to terminate the customers without trouble (and do things like IPv6 and other modern tech). Divorcing price from the equation entirely, I'd love to take something like Nexus and use it for massive FTTH termination with vlans, pvlans, and other capabilities supported in the Earl8. - Jared ___ 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] ARP strangeness
Phil, we're doing exactly this (pinging) for the Linksys BEFRS41 customers that have complained, until we find a way to mitigate or work around the problem. Known options at this time: a) replace the CPE with something else (thought a customer should be able to choose their own CPE and not have this issue) b) put that ONT Ethernet port in bi-directional mode, so it can receive broadcasts (hard to manage through future changes) c) allow the FTTH gear to router (it will do the ARP to the CPE, but this breaks our path toward IPv6 because the FTTH vendor's is at least a year or two away from sufficient IPv6 support to do that). Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Phil Mayers Sent: Wednesday, January 19, 2011 5:24 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On 19/01/11 07:47, Frank Bulk - iName.com wrote: Keegan: You're correct - without broadcast support, re-population initiated from the 7609 is impossible. Once it's expired, the FTTH access gear's design, which blocks broadcast traffic, makes it impossible for the CPE to respond to the I'm confused; Rodney mentioned up-thread that, in newer IOS, the behaviour is different than many (myself included) had assumed. If I understood him correctly: 1. At expiry - 60 seconds, attempt to renew the ARP entry via unicast 2. At expiry, attempt to renew the ARP entry via broadcast Shouldn't the first step flow through the FTTH gear fine, and renew the FDB entry? Anyway - this is vile, but have you considered pinging the CPE from a separate device as a way to keep the FDB entry alive? We do this to keep quiet hosts in the FDB on our switches because the mac-based-vlan implementation we're using is tied to FDB entry (not link up/down state) and if a host goes quiet (like a printer not used in 5 minutes) the FDB entry (and vlan assignment) will expiry, and unless/until the *host* sends a packet (which may be never) it's unreachable. We use fping every 4 minutes on 2 servers (offset by 2 minutes, so a ping arrives every 120 nseconds) for this. We extract the IP addresses from our registration database, but you could perhaps script it from a walk of the 7600 ARP table (maybe even filter by OUI or MAC of the devices you know need it?). Just a thought... ___ 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] ARP strangeness
Gert, you couldn't be more insightful: I did a software upgrade of the 7609 a few weeks ago, which led our helpdesk to raise this issue to me. Frank -Original Message- From: Gert Doering [mailto:g...@greenie.muc.de] Sent: Wednesday, January 19, 2011 3:54 AM To: Frank Bulk - iName.com Cc: 'Keegan Holley'; rod...@cisco.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness Hi, On Wed, Jan 19, 2011 at 01:47:20AM -0600, Frank Bulk - iName.com wrote: You're correct - without broadcast support, re-population initiated from the 7609 is impossible. Once it's expired, the FTTH access gear's design, which blocks broadcast traffic, makes it impossible for the CPE to respond to the broadcast ARP. The FTTH access gear never allows broadcast traffic to ingress from the 7609. So the only thing that can re-populate the 7609's ARP cache is an ARP request by the CPE, *but* the CPE only does that after a DHCP exchange after power on, never again, even after a full DHCP exchange. This sounds like a very very stupid design in the FTTH gear. Imagine what happens if the 7609 needs to be rebooted - *all* customers having to powercycle their CPEs? (Also, the whole idea of blocking broadcasts from the ISP side is bogus to start with - broadcasts from the CPE side are what needs to be well-controlled and only distributed to the ISP PE...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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] ARP strangeness
Jared: Thanks. We're running 12.2(33)SRE2, which is pretty recent. I could only hope that those CEF-MFI re-writes made it in the SR code line. As mentioned in the original post, the CAM timers are 540 seconds, and that's because Cisco documentation says it should be longer than the ARP time, which I have set to 480 seconds. Frank -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Tuesday, January 04, 2011 9:35 PM To: frnk...@iname.com Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness One thing to watch out for is the 6500/7600 (aka 76k) has the SUP and the MFSC that may have independent arp/mac/cam information that can also be out of sync. Depending on your layer-2 topology, software version, etc.. it's also possible that large numbers of MACs out a single interface can cause troubles as well (we've seen TFIB tracebacks due to arp timer churn in the SXF code creating duplicate cef events). A lot of this is better in newer code, eg: SXI5 (post cef-mfi rewrite that appeared in SXH). If you are doing layer-2 vlans at all, check your cam timers, eg: Router#sh mac-address-table aging-time VlanAging Time -- Global 300 no vlan age other than global age configured These may also be causing the troubles you are seeing. You may want to increase these timers to keep the SUP and MFSC aging closer to in-sync. - Jared On Jan 3, 2011, at 11:13 PM, Frank Bulk - iName.com wrote: The 7609 does stop ARPing after receiving a reply from the CPE, but the 7609 ARPs again 7 minutes later. One person told me off-list that Cisco doesn't expire an ARP entry before checking its ARP entries by doing an ARP request. Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP the host one minute before expiration. Because the FTTH product has its own smart-L2 implementation with a MAC address expiration time of 7 minutes, it won't forward directed or broadcast ARP requests from the 7609 once the CPE's MAC address has expired from the FTTH's MAC table. Once the CPE goes deaf, even a full DHCP exchange doesn't wake up the connection. Only power-cycling the BEFRS41 resolves the issue. The difference between a power cycle and a full DHCP exchange is that the BEFSR41 does an ARP request for the default router (7609) after the DHCP exchange. I've extended the MAC address expiration time of the FTTH link to 15 minutes (two times the 7 minutes plus 1 minute) and we'll see how that goes. Frank -Original Message- From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Monday, January 03, 2011 7:14 PM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness The 7600 should stop arping if it has gotten a reply. What happens when you ping your test CPE both from the router and from another node behind it? You can also run he command sh ip cef exact-match to see what the router is doing with a specific source-destination ip pair. If nothing strange pops up then it's probably a bug. Sent from my iPhone On Jan 3, 2011, at 12:58 PM, Frank Bulk frnk...@iname.com wrote: We have over a thousand FTTH customers hanging off a VLAN on our 7609-S running 12.2SRE3. Those who have Linksys BEFRS41 (wired-only routers) are complaining about lack of Internet access after many hours or days of idle time (not using their PC or other devices). Those who have Linksys WRT54G (wireless) have no complaints (my guess is that they're sending packets out regularly). We replicated this in our CO and put a hub between the ONT and the Linksys CPE so that we could capture those packets. What we're seeing in that capture are directed ARP requests every 7 minutes from the 7609 to the Linksys with an ARP response from the Linksys. After many hours, the 7609-S stops sending the ARP requests (well, at least we're not seeing it come in, perhaps it did try). We currently have our ARP timeout set to 480 seconds and MAC address table aging time to 540 seconds. Why? We use mac-address-table synchronize which is set to 160 seconds by default. The recommendation from that command is to set ARP three times that, so that would be 480. But it's also recommended that the MAC address table aging time be greater than the ARP timeout, so we added another 60 seconds on top. Two questions: - why is the 7609 sending any directed ARP requests at all, every 7 minutes? - why does it appear to stop sending them after many hours? I'm all ears if we should be using different expiration values, but the numbers I'm using are based on reading a lot of cisco-nsp archives and Cisco tech articles. Frank ___ 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
Re: [c-nsp] ARP strangeness
Rodney: I can't recall seeing that ARP refresh documented anywhere, but it's obviously happening. I agree with you about the race condition. Yesterday I set the FTTH MAC timeout to be 2 times the ARP refresh interval plus 60 seconds (to give me some room if the ARP unicast refresh doesn't happen exactly after 7 minutes). Broadcast ARPs, due to the FTTH's L2 security protection mechanisms, are not passed on. Once the MAC entry ages out of the FTTH, it has to relearn it from the CPE (I think via ARP) before it will pass thru certain types of traffic. The rest of what you're describing about ARP expiration makes sense. Thanks, Frank -Original Message- From: Rodney Dunn [mailto:rod...@cisco.com] Sent: Tuesday, January 04, 2011 8:01 PM To: frnk...@iname.com Cc: 'Keegan Holley'; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness On 1/3/11 11:13 PM, Frank Bulk - iName.com wrote: The 7609 does stop ARPing after receiving a reply from the CPE, but the 7609 ARPs again 7 minutes later. One person told me off-list that Cisco doesn't expire an ARP entry before checking its ARP entries by doing an ARP request. Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP the host one minute before expiration. There were some changes to ARP at one point to provide some more triggered capability. I don't recall exactly what that was but the default behavior for many years was that we send a unicast arp to the destination 60 seconds prior to the arp timer set to expire. If we don't get a response we send it again when the timer pops and if no response we invalidate the ARP entry. Because the FTTH product has its own smart-L2 implementation with a MAC address expiration time of 7 minutes, it won't forward directed or broadcast ARP requests from the 7609 once the CPE's MAC address has expired from the FTTH's MAC table. I wonder if you are missing one and then getting in to a race condition of the FTTH product not forwarding. If so it would seem you need to set the arp refresh down to a value less than the timeout of the transport gear. Once the CPE goes deaf, even a full DHCP exchange doesn't wake up the connection. Only power-cycling the BEFRS41 resolves the issue. The difference between a power cycle and a full DHCP exchange is that the BEFSR41 does an ARP request for the default router (7609) after the DHCP exchange. If you lose the arp from the 7609 and you ping from it directly we should send a broadcast arp. Not sure where you are getting the packet capture but a span directly off the port is what you need to see if we don't send those two refreshes (one 60 seconds prior to the timer expiring and the second on the timer expiring). If we do send those and no response then data driven from the 7609 (packets headed towards that remote IP) should trigger the arp broadcast out again. Rodney I've extended the MAC address expiration time of the FTTH link to 15 minutes (two times the 7 minutes plus 1 minute) and we'll see how that goes. Frank -Original Message- From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Monday, January 03, 2011 7:14 PM To:frnk...@iname.com Cc:cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness The 7600 should stop arping if it has gotten a reply. What happens when you ping your test CPE both from the router and from another node behind it? You can also run he command sh ip cef exact-match to see what the router is doing with a specific source-destination ip pair. If nothing strange pops up then it's probably a bug. Sent from my iPhone On Jan 3, 2011, at 12:58 PM, Frank Bulkfrnk...@iname.com wrote: We have over a thousand FTTH customers hanging off a VLAN on our 7609-S running 12.2SRE3. Those who have Linksys BEFRS41 (wired-only routers) are complaining about lack of Internet access after many hours or days of idle time (not using their PC or other devices). Those who have Linksys WRT54G (wireless) have no complaints (my guess is that they're sending packets out regularly). We replicated this in our CO and put a hub between the ONT and the Linksys CPE so that we could capture those packets. What we're seeing in that capture are directed ARP requests every 7 minutes from the 7609 to the Linksys with an ARP response from the Linksys. After many hours, the 7609-S stops sending the ARP requests (well, at least we're not seeing it come in, perhaps it did try). We currently have our ARP timeout set to 480 seconds and MAC address table aging time to 540 seconds. Why? We use mac-address-table synchronize which is set to 160 seconds by default. The recommendation from that command is to set ARP three times that, so that would be 480. But it's also recommended that the MAC address table aging time be greater than the ARP timeout, so we added another 60 seconds on top. Two questions: - why is the 7609 sending any directed ARP requests at all, every 7
Re: [c-nsp] ARP strangeness
The 7609 does stop ARPing after receiving a reply from the CPE, but the 7609 ARPs again 7 minutes later. One person told me off-list that Cisco doesn't expire an ARP entry before checking its ARP entries by doing an ARP request. Since ARP timeout is set for 8 minutes, perhaps Cisco's approach is to ARP the host one minute before expiration. Because the FTTH product has its own smart-L2 implementation with a MAC address expiration time of 7 minutes, it won't forward directed or broadcast ARP requests from the 7609 once the CPE's MAC address has expired from the FTTH's MAC table. Once the CPE goes deaf, even a full DHCP exchange doesn't wake up the connection. Only power-cycling the BEFRS41 resolves the issue. The difference between a power cycle and a full DHCP exchange is that the BEFSR41 does an ARP request for the default router (7609) after the DHCP exchange. I've extended the MAC address expiration time of the FTTH link to 15 minutes (two times the 7 minutes plus 1 minute) and we'll see how that goes. Frank -Original Message- From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Monday, January 03, 2011 7:14 PM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] ARP strangeness The 7600 should stop arping if it has gotten a reply. What happens when you ping your test CPE both from the router and from another node behind it? You can also run he command sh ip cef exact-match to see what the router is doing with a specific source-destination ip pair. If nothing strange pops up then it's probably a bug. Sent from my iPhone On Jan 3, 2011, at 12:58 PM, Frank Bulk frnk...@iname.com wrote: We have over a thousand FTTH customers hanging off a VLAN on our 7609-S running 12.2SRE3. Those who have Linksys BEFRS41 (wired-only routers) are complaining about lack of Internet access after many hours or days of idle time (not using their PC or other devices). Those who have Linksys WRT54G (wireless) have no complaints (my guess is that they're sending packets out regularly). We replicated this in our CO and put a hub between the ONT and the Linksys CPE so that we could capture those packets. What we're seeing in that capture are directed ARP requests every 7 minutes from the 7609 to the Linksys with an ARP response from the Linksys. After many hours, the 7609-S stops sending the ARP requests (well, at least we're not seeing it come in, perhaps it did try). We currently have our ARP timeout set to 480 seconds and MAC address table aging time to 540 seconds. Why? We use mac-address-table synchronize which is set to 160 seconds by default. The recommendation from that command is to set ARP three times that, so that would be 480. But it's also recommended that the MAC address table aging time be greater than the ARP timeout, so we added another 60 seconds on top. Two questions: - why is the 7609 sending any directed ARP requests at all, every 7 minutes? - why does it appear to stop sending them after many hours? I'm all ears if we should be using different expiration values, but the numbers I'm using are based on reading a lot of cisco-nsp archives and Cisco tech articles. Frank ___ 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] c3750x upgrade to 12.2(55)SE1 takes forever
Would this apply to the 3750 Metro, too? Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Nick Hilliard Sent: Monday, December 20, 2010 12:28 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] c3750x upgrade to 12.2(55)SE1 takes forever Just a heads-up for those planning to upgrade to 12.2(55)SE1 on the 3750X platform: this version includes both a bootloader upgrade and a hardware microcode upgrade. I did a upgrade on a C3750X stack several days ago, which took fully 38 minutes of nail-scratching downtime before all stack members were back in service. It doesn't mention the microcode upgrade in the release notes, nor give any hint that the upgrade will take a very long time indeed. If there's anyone from Cisco listening: it would really help if this sort of thing was mentioned in the release notes - please! Not everyone is in a position to lab-test their upgrades. Nick ___ 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] Freeing up an internal use VLAN on a 6509/Sup2/12.1(E) Native mode box
We ended marking those VLAN numbers as unavailable, and if your transport provider should be to use VLAN translation/re-tagging to accommodate your environment. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jason Lixfeld Sent: Thursday, December 02, 2010 4:38 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Freeing up an internal use VLAN on a 6509/Sup2/12.1(E) Native mode box I have a 6509/Sup2/12.1(13)E1 box that allocated VLAN1025 for internal use: router#show vlan internal usage | i 1025 1025 FastEthernet5/13 My transport provider is delivering a TLS service to me on VLAN1025, so needless to say, I can't create a VLAN1025 SVI to terminate this connection. Getting the transport provider change the VLAN is going to be very problematic so I need to know how to free up this VLAN on my side. Changing the internal allocation policy from ascending to descending following by a reboot will, I'm hoping, cause the box to come back up and allocate a VLAN to F5/13 from the high end of the range instead of the low end of the range but I have no way to test this. Anyone know if this will do the trick or is there something else that has to be done as well or can be done instead to free up this VLAN. Thanks in advance. ___ 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] Bridging 802.1q tagged Ethernet traffic to multiple T-1 in a DS-3
M(L)PPP is not an option Frank -Original Message- From: Michael K. Smith - Adhost [mailto:mksm...@adhost.com] Sent: Wednesday, November 17, 2010 4:27 PM To: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Bridging 802.1q tagged Ethernet traffic to multiple T-1 in a DS-3 What's the encapsulation protocol of the T-1's? I would think you could do MPPP and put both T-1's into the same bridge group as the Ethernet interface, but I'm not sure how that would work if it was using HDLC. Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksm...@adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Frank Bulk Sent: Wednesday, November 17, 2010 1:51 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Bridging 802.1q tagged Ethernet traffic to multiple T-1 in a DS-3 Is it possible to use a Cisco 7206VXR to bridge 802.1q tagged Ethernet traffic to multiple T-1s within a DS-3? The remote end, a RNC, can apparently take tagged traffic over multiple T-1's. We might be willing to live with the restriction of assigning certain T-1's within the DS-3 to a certain 802.1q, but would like to take advantage of aggregation. Apparently we can't use PVCs, otherwise I would prefer that approach. Frank ___ 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] QPPB on Cisco 3750-ME
Is this a feature that only works on the ES ports of that switch? Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Chris Mason Sent: Monday, July 26, 2010 12:01 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] QPPB on Cisco 3750-ME Hi, I am not having much luck on Google with regards to if this is supported or not, but I currently have a 3750-ME running 12.2(44)SE6 and I am having some interesting results when trying to use QPPB. The same configuration works perfectly well on an ISR, but the 3750 can be quite feature limiting due to it's hardware nature. I wouldn't be using a 3750 for this sort of thing unless I needed the throughput with H-QoS. I have a table-map applied under BGP which sets a precedence value based on a community (standard QPPB) and I can see that CEF has this precendence value saved ready to use: Switch# show ip route 192.0.2.1 Routing entry for 192.0.2.0/24 Known via bgp 64512, distance 20, metric 0 Tag 100, precedence priority (1), type external -- IP Prec 1 Last update from 192.168.0.1 00:47:11 ago Routing Descriptor Blocks: * 192.168.0.1, from 192.168.0.1, 00:47:11 ago Route metric is 0, traffic share count is 1 AS Hops 6 Route tag 100 I then define bgp-policy destination ip-prec-map on the ingress interface: interface FastEthernet1/0/2 no switchport ip address 10.254.0.1 255.255.255.0 bgp-policy destination ip-prec-map ! When I send traffic in on this interface it isn't being marked - I have applied an outbound ACL which matches precedence values and I can see it coming through as IP Prec 0. If I originate traffic with IP Prec 1 then it comes through as IP Prec 1 on my ACL - the bgp-policy statement doesn't appear to be doing anything at all. Has anyone tried to use this feature on the 3750-ME before or am I hitting a platform limitation? Thanks, Chris ___ 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] Logging Server
Did you look at Xangati, too, and if so, what did you think of it? Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Tuesday, July 13, 2010 10:01 AM To: Walter Keen; Mohammad Khalil; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Logging Server For just Neflow I would like to give Plixer's Scrutinizer a plug. They also have a syslog tool called LogAlot that I haven't tried out yet. We just bought Scrutinizer and I can't imagine any other tool giving more detail without doing packet sniffing. My understanding is that once we upgrade to IOS 15 on our routers that Netflow and NBAR will be integrated so instead of just seeing device X is talking on port 80 to another device - NBAR can help determine what is traveling over port 80 (http or other) so we will have even more insight into our traffic. Thanks, -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Walter Keen Sent: Tuesday, July 13, 2010 9:29 AM To: Mohammad Khalil; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Logging Server Logging as in Syslog (ksyslogd), netflow (nfsen), or authentication/authorization for configuration (tacacs+ from shrubbery.net) If anyone has suggestions other than the above, especially for netflow, I'd love to hear them. -Original Message- From: cisco-nsp-boun...@puck.nether.net on behalf of Mohammad Khalil Sent: Tue 7/13/2010 6:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Logging Server Dears what is the best free logging server to implement ? _ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 ___ 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/ This electronic mail (including any attachments) may contain information that is privileged, confidential, or otherwise protected from disclosure to anyone other than its intended recipient(s). Any dissemination or use of this electronic mail or its contents (including any attachments) by persons other than the intended recipient(s) is strictly prohibited. If you have received this message in error, please delete the original message in its entirety (including any attachments) and notify us immediately by reply email so that we may correct our internal records. Midland Paper Company accepts no responsibility for any loss or damage from use of this electronic mail, including any damage resulting from a computer virus. ___ 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs
So it sounds like if an end-customer wants an *untagged* port off of an SP switch that there aren't any/many options to deliver double-tagged traffic to that SP switch. Sounds like we can have double-tagged traffic between the core and distribution, but when we bring it to the edge we need to take strip off the outer tag. |core | || (double tagged) | distribution | | (single tagged) | Edge | SP switch at customer premise | (untagged) customer -Original Message- From: sth...@nethelp.no [mailto:sth...@nethelp.no] Sent: Friday, July 09, 2010 3:45 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs Thanks for explaining the semantical differences. What I'm looking to do is the termination -- wouldn't the ME3400 do the trick? No, the ME3400 cannot terminate dual tagged VLANs (encapsulation dot1q x second-dot1q y). Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs
Thanks for explaining the semantical differences. What I'm looking to do is the termination -- wouldn't the ME3400 do the trick? Frank -Original Message- From: sth...@nethelp.no [mailto:sth...@nethelp.no] Sent: Thursday, July 08, 2010 3:56 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Cheapest Cisco desktop switch that supports Q-in-Q/802.1Q VLAN encapsulation/double-tagged VLANs/Stacked VLANs What is the cheapest Cisco desktop switch that supports Q-in-Q? Is it the ME-3400G-2CS-A? We prefer the encapsulation dot1q x second-dot1q y approach. Your last sentence doesn't make sense here. Q-in-Q generally refers to *tunneling* one VLAN trunk through an L2 network by adding an extra VLAN tag in front of the existing VLAN tag. encapsulation dot1q x second-dot1q y is used to *terminate* a dual tagged VLAN connection (typically an IP termination). This is very different from *tunneling*. So - do you want tunneling or termination? I don't believe there are any Cisco desktop switches which can IP terminate a dual tagged VLAN connection. There are, of course, plenty of desktop switches which will do 802.1Q tunneling. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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] Missing BGP MIB support on Cisco 2621
Thanks for the suggestion, but querying for it specifically via snmpget and snmpwalk failed, so I don't think downloading the MIB itself would help. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Ziv Leyes Sent: Sunday, February 21, 2010 1:57 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Missing BGP MIB support on Cisco 2621 I think you should download the specific MIB for your release and try to browse it with some MIB Browser or using the Cisco MIB Locator Here's a link for the v2 MIB http://tools.cisco.com/ITDIT/MIBS/MainServlet?ReleaseSel=0PlatformSel=0fsS el=0IMAGE_NAME=c2600-is4-mz.123-26.binSUBMIT2=Submit HTH Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk - iName.com Sent: Friday, February 19, 2010 12:31 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Missing BGP MIB support on Cisco 2621 According to Cisco's MIB Locator, c2600-is4-mz.123-26.bin should have CISCO-BGP4-MIB support, but when I try to walk that part of the tree (1.3.6.1.4.1.9.9.187) in v1 or v2c that fails. I'm using this router to do IPv6 tunneling, and the only routes exchanged on this router are IPv6. Anyone else see this? Or is there a special knob I need to turn that on? Frank ___ 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/ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. ___ 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/
[c-nsp] Missing BGP MIB support on Cisco 2621
According to Cisco's MIB Locator, c2600-is4-mz.123-26.bin should have CISCO-BGP4-MIB support, but when I try to walk that part of the tree (1.3.6.1.4.1.9.9.187) in v1 or v2c that fails. I'm using this router to do IPv6 tunneling, and the only routes exchanged on this router are IPv6. Anyone else see this? Or is there a special knob I need to turn that on? Frank ___ 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] Unicast flooding?
I agree, I have some good evidence. I'm not against upgrading if that will resolve the issue. Frank -Original Message- From: Pavel Skovajsa [mailto:pavel.skova...@gmail.com] Sent: Wednesday, January 13, 2010 3:43 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Unicast flooding? Hello Frank, Does not sound really healthy - if you have gathered good evidence this is a good candidate for TAC. Anyway - you should probably upgrade to something other then SRB4 as TAC will tell you probably the same thing -pavel skovajsa On Wed, Jan 13, 2010 at 7:02 AM, Frank Bulk frnk...@iname.com wrote: We've been seeing some strange behavior on our 7609-S running 12.2(33r)SRB4. We have a VLAN (with four /24s) configured on three ports across two 10/100/1000 blades facing some FTTH transport equipment. Customers hanging off the FTTH equipment on the third port are complaining that several times per day they lose internet access. We've been able to correlate their complaints with failed ping attempts from our workstations and the 7609-S to their public IPs. What's interesting is that it's not all the traffic, and of the 4 IPs we are tracking, two of which are on separate /24s, the outages happen within the same /24. At the same time, while using Wireshark, I can see one of the Cisco interfaces sending out 1 to 2 Mbps of traffic that should be going to one of the other two Ethernet interfaces. This is happening about a dozen times per day for 4 to 6 minutes at a time. While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? Frank interface Vlan10 description FTTH network ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address 67.22.a.1 255.255.255.0 secondary ip address 67.22.b.1 255.255.255.0 secondary ip address 67.22.c.1 255.255.255.0 secondary ip address 67.22.d.1 255.255.255.0 ip helper-address e.f.g.h no ip redirects arp timeout 300 end interface GigabitEthernet1/29 (and 3/39 and 3/45) switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10 switchport mode trunk switchport nonegotiate load-interval 30 spanning-tree portfast trunk end ___ 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/
Re: [c-nsp] Unicast flooding?
-Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Wednesday, January 13, 2010 3:18 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Unicast flooding? While the event is occurring I have verified the ARP and CAM entry. The CAM entry is associated with one of the first two Ethernet interfaces, not the third. I can clear the ARP and CAM entry from the CLI and they are re-learned with the same information, yet the traffic continues to egress the wrong Ethernet port. Ugh. Agreed. I've set the ARP timeout to 4 minutes so that it's less than the CAM table's default configuration of 5 minutes, but there was no improvement. One more observation -- the errant port is the root of the bridge. Any ideas why the 7609 would be sending traffic out an Ethernet port to a device that the CAM table says is on a different Ethernet port? What module is the traffic coming in via? Which of the modules have DFCs? Have you looked at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not e09186a00807347ab.shtml#dfc ...specifically the 1st item Loss of Dynamic MAC Addresses with Distributed Switching which could possibly be related, though that is a wild guess. Thanks for reminding me about this article. When I do a sh mac-address-table, am I looking at what's on the Supervisor or line card's DFC? When I turn it on, I get this message: Mutual_7609(config)#mac-address-table synchronize % Current activity time is [160] seconds % Recommended aging time for all vlans is at least three times the activity interval The aging time of the CAM? By default it's 300 seconds, so working backwards, I would want a Current activity time of 100 seconds, but that doesn't appear to be an option. So I've now increased the mac address-table aging time for that VLAN to 480 seconds (3 x 160) and the arp timeout also to 480 seconds. How long has this been happening for? We've had the first two interfaces in production for several months. We just turned up this third interface two or three weeks, and started moving customers on there and they started complaining last week, so extrapolating from that I'm pretty confident it's been doing this the whole time. Frank ___ 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] Unicast flooding?
Good news is that with the mac-address-table synchronize command things have been stable for 2 hours, a new record. More below. Frank -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Wednesday, January 13, 2010 10:19 AM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Unicast flooding? Frank Bulk - iName.com wrote: Have you looked at: http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_not e09186a00807347ab.shtml#dfc ...specifically the 1st item Loss of Dynamic MAC Addresses with Distributed Switching which could possibly be related, though that is a wild guess. Thanks for reminding me about this article. When I do a sh mac-address-table, am I looking at what's on the Supervisor or line card's DFC? Well, on a 6500 under SXI, it shows me things like: Module 1: * 1740 .0c07.ac00 dynamic Yes160 Po1 * 1740 001e.2a6f.5c37 dynamic Yes220 Po1 * 1740 0015.c706.8c00 dynamic Yes170 Po1 Module 2[FE 1]: * 1740 .0c07.ac00 dynamic Yes 0 Po1 * 1740 0015.c706.8c00 dynamic Yes170 Po1 Module 2[FE 2]: * 1740 0015.c706.8c00 dynamic Yes170 Po1 The output under SRB is a bit different: Mutual_7609#sh mac-address-table Legend: * - primary entry age - seconds since last seen n/a - not available vlan mac address typelearn age ports --+++-+--+-- 280 0007.e96b.06fb dynamic Yes295 Gi1/32 150 0030.d700.1afe dynamic Yes295 Gi3/35 293 001e.e573.ee2e dynamic Yes 5 Gi1/39 293 0023.69c4.d0a7 dynamic Yes295 Gi1/39 572 0021.29d9.2dbb dynamic Yes295 Gi3/47 280 001e.e573.edda dynamic Yes295 Gi1/32 ...leading me to believe it's querying all the forwarding engines on all the modules but NOT the PFC on the sup (module 5 in our case) - possibly because we've got DFCs in all slots? Perhaps. As the example shows, the module and even FE tables within a module can differ. There's times where I've seen nothing for sh mac-address-table, but when I specify a port, I do see it listed (notice that it mentions Line card 3): Mutual_7609#sh mac-address-table int gi3/45 Displaying entries from Line card 3: Legend: * - primary entry age - seconds since last seen n/a - not available vlan mac address typelearn age ports --+++-+--+ * 10 0023.69c4.d0da dynamic Yes 5 Gi3/45 Etc. You can get the raw module local tables (and the PFC one) using: remote command module N sh mac-address-table [dynamic] [vlan N] If the active sup is in slot 5, these are equivalent: remote command module 5 remote command switch ...and on the sup I see, using the above example: Displaying entries from SP: RM PI_E RMA Vlan Destination Address Address Type XTag LTL Index ---++---+--+-+-++-- --- No Yes No 1740 ..0016static 0 0x802 No Yes No 1740 ..0001static 0 0x802 No Yes No 1740 ..000dstatic 0 0x7FF8 No No No 1740 .0c07.ac00dynamic 0 0x340 No Yes No 1740 0015.c70b.9000static 1 0x380 No No No 1740 001e.2a6f.5c37dynamic 0 0x340 No No No 1740 0015.c706.8c00dynamic 0 0x340 ...which looks like an amalgam of the module MAC tables. We're not running mac sync or anything odd. You can remote command [switch|module N] (or attach N) and run sh mac-address-table detail ...but based on the deafening silence in response to a query the other week, no-one knows what those flags mean - maybe you can see a pattern in your problematic entries though (yay I just love reverse engineering the 6500 forwarding architecture - thanks cisco!) Those remote commands work for me here, but as you said, who knows what those flags mean. When I turn it on, I get this message: Mutual_7609(config)#mac-address-table synchronize % Current activity time is [160] seconds % Recommended aging time for all vlans is at least three times the activity interval The aging time of the CAM? By default it's 300 seconds, so working backwards, I would want a Current activity time of 100 seconds, but that doesn't appear to be an option. So I've now increased the mac address-table aging time for that VLAN to 480 seconds (3 x 160) and the arp timeout also to 480 seconds. Interestingly, at some point when I was testing either SXH or SXI, I recall this very time (480 seconds) magically popped into the nvgen without any input
[c-nsp] Loopback/VLAN question
I have several uniquely numbered 802.1q tagged links coming into a Cisco 7609-S (12.2(33)SRB3) on a single physical port. I would like to use the same group of subnets for each VLAN and I tried using loopbacks but it doesn't work. Any ideas on what I'm doing wrong? interface Loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address a.b.c.1 255.255.255.0 ip address a.b.d.1 255.255.255.0 secondary ip address a.b.e.1 255.255.255.0 secondary ip helper-address w.x.y.z arp timeout 300 interface Vlan10 ip unnumbered loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip helper-address w.x.y.z interface Vlan11 ip unnumbered loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip helper-address w.x.y.z interface GigabitEthernet1/1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10, 11 switchport mode trunk end ___ 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] Loopback/VLAN question
It's my understanding that BVIs on the 7600-platform only bridge non-IP traffic, so that wouldn't work. Frank -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Tuesday, December 15, 2009 12:30 PM To: Frank Bulk - iName.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Loopback/VLAN question On Tue, 15 Dec 2009, Frank Bulk - iName.com wrote: I have several uniquely numbered 802.1q tagged links coming into a Cisco 7609-S (12.2(33)SRB3) on a single physical port. I would like to use the same group of subnets for each VLAN and I tried using loopbacks but it doesn't work. Any ideas on what I'm doing wrong? Use BVI's, not loopbacks. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ 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] Loopback/VLAN question
I have 5 remote sites where I'm doing FTTH and transporting the traffic over a third-party transport gear to our HQ. Each site-HQ link is a separate VLAN and uniquely numbered. My preference is to burn up only one port on the Cisco 7609-S (RSP720-3C with WS-X6748-DFC3C) and transport gear by trunking the traffic between the two boxes. But I don't want to have a separate IP address pool (with associated static IP /24 and web filter /24) for each remote site. I would like each remote site to use the same address pool. So I'm looking for something like IRB. SiteA SiteB SiteC SiteD SiteE | | | | | VLAN1 VLAN2 VLAN3 VLAN4 VLAN5 | | | | | = | 802.1q tagged (1 thru 5) | 7609-S | DHCP server I could use the transport gear's VLAN-translation and drop off each site into their own physical port on the 7609-S but have it be the same VLAN, but that's burning more ports on both boxes than what I would like. But perhaps I have to use separate IP address pools for each remote site. That would have the benefit of reducing the L3-broadcast traffic. Frank -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Tuesday, December 15, 2009 1:32 PM To: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Loopback/VLAN question Frank, Can you please explain what do you want to achieve? I think this should be done in a different way. Also, what HW do you have? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk - iName.com Sent: Tuesday, December 15, 2009 20:19 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Loopback/VLAN question I have several uniquely numbered 802.1q tagged links coming into a Cisco 7609-S (12.2(33)SRB3) on a single physical port. I would like to use the same group of subnets for each VLAN and I tried using loopbacks but it doesn't work. Any ideas on what I'm doing wrong? interface Loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address a.b.c.1 255.255.255.0 ip address a.b.d.1 255.255.255.0 secondary ip address a.b.e.1 255.255.255.0 secondary ip helper-address w.x.y.z arp timeout 300 interface Vlan10 ip unnumbered loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip helper-address w.x.y.z interface Vlan11 ip unnumbered loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip helper-address w.x.y.z interface GigabitEthernet1/1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10, 11 switchport mode trunk end ___ 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] Does the entire BGP routing table for IPv6 fit on a Cisco 2600 with 64 MB of DRAM?
The tunnel is up against HE's TunnelBroker service. The Cisco 2600 is reporting just 612 KB in use. Frank C2600#sh bgp summary BGP router identifier a.b.c.d, local AS number 53347 BGP table version is 2299, main routing table version 2299 2269 network entries using 301777 bytes of memory 2269 path entries using 163368 bytes of memory 1749 BGP path attribute entries using 104940 bytes of memory 1706 BGP AS-PATH entries using 41812 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 611897 total bytes of memory BGP activity 2271/2 prefixes, 2272/3 paths, scan interval 60 secs NeighborVAS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2001:470:1F03:10C::1 4 69391923 26 229900 00:22:06 2269 C2600# -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk - iName.com Sent: Monday, December 07, 2009 2:58 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Does the entire BGP routing table for IPv6 fit on a Cisco 2600 with 64 MB of DRAM? Does the entire BGP routing table for IPv6 (almost 2500 entries) fit on a Cisco 2600 with 64 MB of DRAM running 12.3(26)? I am planning to use this box for an IPv6-in-IPv4 tunneling appliance, but not sure if it can hold the whole table. Regards, Frank ___ 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] Loopback/VLAN question
Looks like I will be creating separate L3 domains. ARIN, here I come. =) Thanks again to this group for this helpful information. Frank -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Tuesday, December 15, 2009 2:14 PM To: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Loopback/VLAN question Frank, The right way to solve it would be to use the ES20 (or more actually the more recent ES+) modules. This would allow you to create a separate EVC/EFP (service-instance) per site, using whatever VLAN IDs (even reusing them, or using QinQ) and then bridge-domain them all to the same central global bridge VLAN, which would be the Layer 3 service endpoint (for DHCP). Use the right tools for the job Anyway, with your setup, if this is not becoming a big service (which would then make sense to invest in new HW), then maybe you should just break them into separate L3 domains. Another option is to use the MetroE model of uPE and nPE, where a uPE is used for some parts of the service. This could be a L2 switch (CPE? ME3400-2CS) to do the VLAN translation... Hope this helps. Arie -Original Message- From: Frank Bulk - iName.com [mailto:frnk...@iname.com] Sent: Tuesday, December 15, 2009 21:56 To: Arie Vayner (avayner); cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Loopback/VLAN question I have 5 remote sites where I'm doing FTTH and transporting the traffic over a third-party transport gear to our HQ. Each site-HQ link is a separate VLAN and uniquely numbered. My preference is to burn up only one port on the Cisco 7609-S (RSP720-3C with WS-X6748-DFC3C) and transport gear by trunking the traffic between the two boxes. But I don't want to have a separate IP address pool (with associated static IP /24 and web filter /24) for each remote site. I would like each remote site to use the same address pool. So I'm looking for something like IRB. SiteA SiteB SiteC SiteD SiteE | | | | | VLAN1 VLAN2 VLAN3 VLAN4 VLAN5 | | | | | = | 802.1q tagged (1 thru 5) | 7609-S | DHCP server I could use the transport gear's VLAN-translation and drop off each site into their own physical port on the 7609-S but have it be the same VLAN, but that's burning more ports on both boxes than what I would like. But perhaps I have to use separate IP address pools for each remote site. That would have the benefit of reducing the L3-broadcast traffic. Frank -Original Message- From: Arie Vayner (avayner) [mailto:avay...@cisco.com] Sent: Tuesday, December 15, 2009 1:32 PM To: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Loopback/VLAN question Frank, Can you please explain what do you want to achieve? I think this should be done in a different way. Also, what HW do you have? Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk - iName.com Sent: Tuesday, December 15, 2009 20:19 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Loopback/VLAN question I have several uniquely numbered 802.1q tagged links coming into a Cisco 7609-S (12.2(33)SRB3) on a single physical port. I would like to use the same group of subnets for each VLAN and I tried using loopbacks but it doesn't work. Any ideas on what I'm doing wrong? interface Loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip address a.b.c.1 255.255.255.0 ip address a.b.d.1 255.255.255.0 secondary ip address a.b.e.1 255.255.255.0 secondary ip helper-address w.x.y.z arp timeout 300 interface Vlan10 ip unnumbered loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip helper-address w.x.y.z interface Vlan11 ip unnumbered loopback 2 ip dhcp relay information trusted ip dhcp relay information option-insert none ip dhcp relay information policy-action keep ip helper-address w.x.y.z interface GigabitEthernet1/1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 10, 11 switchport mode trunk end ___ 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/
[c-nsp] Does the entire BGP routing table for IPv6 fit on a Cisco 2600 with 64 MB of DRAM?
Does the entire BGP routing table for IPv6 (almost 2500 entries) fit on a Cisco 2600 with 64 MB of DRAM running 12.3(26)? I am planning to use this box for an IPv6-in-IPv4 tunneling appliance, but not sure if it can hold the whole table. Regards, Frank ___ 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 L2 QoS
If you need to egress policing on those 24 ports, and those 24 ports don't talk to each other, try ingress policing on the uplink by using the enhanced port as the uplink.. Frank From: Mohammad Khalil [mailto:eng_m...@hotmail.com] Sent: Monday, December 07, 2009 3:15 AM To: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Cisco L2 QoS the problem is that the customers are connected to the 24 Fast Ethernet ports From: frnk...@iname.com To: eng_m...@hotmail.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Cisco L2 QoS Date: Sun, 6 Dec 2009 21:58:27 -0600 Don't forget that there's two enhanced ports on that unitthey have more QoS capabilities. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil Sent: Sunday, December 06, 2009 7:34 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco L2 QoS hi all i have cisco metroethernet switches 3750 i have some customers connected to some ports (the ports are access ports , layer2 ports) i am trying to apply rate limit on the bandwidth each customers consume rate limit command applies for layer 3 interfaces which does not match my case what should i do to achieve this ?? even though applying rate limit on the logical interface (interface vlan) does not work as well as the MQC model does not apply _ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/soc ial-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010 ___ 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/ _ Windows Live: Make it easier for your friends to see what you http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so cial-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009 're up to on Facebook. ___ 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] Does the entire BGP routing table for IPv6 fit on a Cisco 2600 with 64 MB of DRAM?
Good to know in advance that the 2600 doesn't have a lot of horsepower for this kind of work. What's a good IPv6-based speed test site I can to test against? Maybe I'll have to resort to iperf, if it's IPv6 ready. Frank -Original Message- From: Gert Doering [mailto:g...@greenie.muc.de] Sent: Monday, December 07, 2009 3:30 PM To: Frank Bulk - iName.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Does the entire BGP routing table for IPv6 fit on a Cisco 2600 with 64 MB of DRAM? Hi, On Mon, Dec 07, 2009 at 02:57:42PM -0600, Frank Bulk - iName.com wrote: Does the entire BGP routing table for IPv6 (almost 2500 entries) fit on a Cisco 2600 with 64 MB of DRAM running 12.3(26)? This is a bit tight. On my good old 4700M, the BGP router process, which is carrying all of IPv6, needs 6.5 Mbyte of RAM. 64 Mb total, 17 Mb free. *But*: 12.3 IP Plus IOS for 2600 will likely eat much more RAM to start with, so it might already be tight. I am planning to use this box for an IPv6-in-IPv4 tunneling appliance, but not sure if it can hold the whole table. ... and that will be a bigger problem. The 2600 is *slow*, so chances are you won't be able to tunnel enough IPv6 through it to even satisfy a single 16M ADSL link... and you won't be happy with proof-of-existance- but quite slow IPv6. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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] ISR G2 multicore?
I would have to disagree -- while there are some features shared by most configurations, there's enough implementations using particular 'knobs' that a less than complete feature set would leave the majority of network engineers frustrated. For example, pick the less than complete implementation of BFD. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Roland Dobbins Sent: Wednesday, October 28, 2009 8:18 AM To: Cisco-nsp Subject: Re: [c-nsp] ISR G2 multicore? On Oct 28, 2009, at 7:53 PM, James Weathersby (jweather) wrote: A lot of it has to do with the different roles the routers play. The smartest/sanest thing to do, IMHO, would be to work at migrating to NX-OS, feature-set by feature-set. It's by far the cleanest and best-designed OS platform Cisco have come out with to date. And, yes, whilst there are 4500+ features in IOS, the overwhelming majority of customers use a miniscule fraction of them. The idea would be to start with major features and gradually work towards minor ones, which would allow customers who don't need the more esoteric features to migrate over to the better/cleaner/more stable OS - which would also end up reducing the burden on account teams, TAC, et. al. This probably won't happen due to NIH/BU politics, but it would sure be nice, heh. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Sorry, sometimes I mistake your existential crises for technical insights. -- xkcd #625 ___ 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] PPPoE multiple sessions issue
At least they aren't duplicate IPs and the routing table seems to be correct give the situation. There is a ppp ipcp unique username command that you can assign to the Virtual Template, but a Cisco TAC person told me not to use that, as its use is not as the description would seem. Apparently that command was for situations from several years ago, not for restricting two usernames at the same time. We ended up using RADIUS to limit the number of connections to 1. Frank -Original Message- From: D.J. O'Berry [mailto:dobe...@zcorum.com] Sent: Monday, October 26, 2009 3:23 PM To: frnk...@iname.com Cc: 'Cisco-nsp' Subject: Re: [c-nsp] PPPoE multiple sessions issue Hi, Thanks for responding. As you may have noticed, I tried lowering the keepalive in the previous email I sent in. However, while I was out today the issue came back. I was able to catch the tail end of it though. The user had an ip assigned via dhcp on each interface. I could not ping the older entry (it was the timeout entry obviously) but could the newer entry. A show ip route for each ip showed a route entry for the corresponding interface. That's as far as I got though before the keep-alive killed the old entry and the user was able to browse again. I tried setting a limit of one on the vc with the line sessions per-vc limit 1, but it did not help. Is there a way on the router to limit the number of sessions by username to 1? (I'd rather do this on the router as my radius attribute knowledge is slim) Frank Bulk wrote: Do both PPPoE sessions have an IP address associated with them? If you look at the route table, both from an IP and a Virtual-Access perspective, are there duplicate or missing entries from any perspective? We ended up opening a TAC case for a somewhat similar issue centered around the use of an external DHCP server and faulty day zero PPP state situation. The bug was resolved in 12.2(33)SB16. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of D.J. O'Berry Sent: Friday, October 23, 2009 11:28 AM To: 'Cisco-nsp' Subject: [c-nsp] PPPoE multiple sessions issue Hello all, I have an issue where random users will apparently lose their pppoe connection on their end for some reason, and reconnect again. The reconnect goes well, but the user cannot browse. Doing a show user | inc username will list 2 pppoe sessions for the user. Obviously one of these is the lost session. We have a keepalive set, so after the keepalive time passes, the old session of course disappears. The problem is, until that happens or we remove the old session, the user cannot browse at all. Any ideas on causes of this would be much appreciated. Thanks in advance. -- D.J. O'Berry Network Design Engineer ZCorum 866-467-9791 ext 7041 dobe...@zcorum.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/
Re: [c-nsp] 7206VXR NPE for ~1000 RBE interfaces
An NPE400 should do fine if you're looking used or on a tight budget, but if you're looking to buy for growth, just get a G2 and be done with it. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Antonio Querubin Sent: Sunday, October 11, 2009 5:27 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] 7206VXR NPE for ~1000 RBE interfaces I'm researching upgrading a 7206VXR to handle about 1000 RBE interfaces off of either 2 T3 or 1 OC3 ATM line. Anybody got any recommendations on which NPE would handle this scenario? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ 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] Management stuff in VRFs
In short, the best management VRF is a serial-based terminal server. =) Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Peter Rathlev Sent: Thursday, September 03, 2009 4:34 PM To: cisco-nsp Subject: Re: [c-nsp] Management stuff in VRFs Thank you all for the reponses. As many replies point out, and as many previous threads bear witness to, the current implementations of IOS lack full support for a seperate management VRF. This alone made me curious why people still push in that direction. Generally I assume that some kind of OoB management is best practice already; the typical setup where I'm from is a terminal server of some kind (e.g. Cisco 2512) in each PoP and some octopus cables reaching out to all the console ports. This is for emergencies though, not for production, i.e. not for Netflow, TACACS+ and so on. A management network in a seperate VRF will not in itself give anyone emergency access to devices. I could imagine obscure software bugs that would actually hinder this access instead. And even though using seperate physical interfaces is much easier with an isolated VRF it is not a prerequisite, and without that some of the arguments for the VRF fall apart IMHO. Seperating non-business traffic (like Netflow, TACACS+, syslog) from business traffic is idealogically a good idea. If you extend this thought we would actually end up with a seperate set of interfaces for _everything_ which is not customer traffic, including IGP and BGP (and LDP for those so inclined). Or am I crossing a line here? And for the record: Yes, poor me, I have no real SP experience, having only worked with enterprise networks. We use exactly what Donn describes: A lean global table with all user traffic carried as MPLS. /Peter (... off to the purgatory for top posting, sorry. :-)) On Thu, 2009-09-03 at 10:42 -0700, Lasher, Donn wrote: -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jerome Durand Subject: Re: [c-nsp] Management stuff in VRFs We went in that direction in our latest deployment and discovered also that many pieces were missing in IOS and IOS-XR to have full management in a dedicated VRF for all our devices. At this stage we have the VRF but not all management goes there... so there is more complexity and network is no more secure... I must admit IOS-XR gives us more troubles as more management features are missing in VRF's. The most effective way to do this I've seen so far essentially turns your network inside out. The Global portion of the router is management, in RFC1918 space, and your internet/public IP's/traffic/etc are all carried in a dedicated VRF. Taking a production network NOT designed that way, and doing the inside-out... well that's every bit as hard as it sounds... ___ 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] Arp Inspection Rate Limit
We deal with this issue on the BWA side of the house. We typically set up the client radios to rate-limit broadcasts (yes, there's more to broadcast than ARP, but ARP is most of it) to 7 pps and main radio to as low as 12 pps. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Alexander Clouter Sent: Wednesday, August 19, 2009 4:59 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Arp Inspection Rate Limit Hi, nm...@guesswho.com wrote: Thanks for the response. Funny you mention the print server because that happens to be one device port I need to tweak since it occasionally exceeds the 15 pps. We have been fine at 10 for over a year now[1], however it took us a while to figure out that for some bizarre reason[2] 'File and Print Sharing' being enabled actually caused the workstation to flood ping the local subnet looking for printers everytime someone pressed Print on their workstation. Similar thing happens under Vista only when you want to add an IPP printer by hand :-/ Cheers [1] we are a university with about 600 staff and 3000 students [2] might be linked to Novell being installed too, but who knows -- Alexander Clouter .sigmonster says: There's enough money here to buy 5000 cans of Noodle-Roni! ___ 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] 7500 for DSL aggregation - RSP memory error?
Our DSLAM vendor supports PPPoA to PPPoE encapsulation/conversion (I'm not sure how), so that's our migration plan if we need to move to a new BRAS that doesn't have OC-3 interfaces. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of E. Versaevel Sent: Wednesday, August 05, 2009 3:02 AM To: Gert Doering Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 7500 for DSL aggregation - RSP memory error? Only drawback on the ASR1k platform is the lack of PPPoA support, otherwise we would have happely migrated away from our 7200/1G's We got 2 ASR1004's for ethernet aggregation and they're doing just fine for that :) If you *insist* on having route-processor redundancy (what about interface and physical path redundancy?), I think you can do that with ASR1k, but I admit to not having any hands-on experience with that platform yet. Erik Versaevel ___ 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] Monitoring BGP with NAGIOS
I appreciate all the feedback I received. The product of that feedback is this NAGIOS plugin: http://exchange.nagios.org/directory/Plugins/Network-Protocols/*-Routing/BGP %252D4/check_bgp_counters/details Regards, Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk Sent: Thursday, July 23, 2009 9:04 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Monitoring BGP with NAGIOS We're a small shop and our group's upstream is single-homed in terms of providers but dual-homed in terms of physical connectivity, with a private ASN. Occasionally there's BGP events and I would like to be remotely notified -- NAGIOS can do that and I prefer SNMP polling. We're not doing an SNMP TRAP or syslog processing at this time - that would be an obvious next step for us. Currently the NAGIOS plugin I'm developing polls the bgpPeerState, bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's a change. Since a BGP session could be re-established in a short amount of time, I would like to trigger an alert if the number of In/Out Updates or Messages exceeds the regular value (I'm presuming that when the BGP session re-establishes, these counters climb more quickly than during times of stability). But I'm not sure if Updates/Messages are normally sent every 30 or 60 seconds (I've seen 60 on a wiki page, but sh ip bgp neighbors says that the keepalive interval is 30 seconds and Default minimum time between advertisement runs is 30 seconds. I'm guessing this knob can be adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate for that, such that if the counters move '5' in 5 minutes that's OK with a 60 second period, but if it's a 30 second period, then those counts should move 10 times. But keep-alive/scan interval doesn't seem to be listed in the MIB. Also, there's a lot more information available at the Cisco CLI when executing sh ip bgp summary, specifically: . BGP table version . # of network entries . # of path entries . # of prefixes . # of paths . Up/Down times Is any of that available via SNMP, because my walking isn't showing that at all? If you think I'm going about this the wrong way, please feel free to tell me. =) Regards, Frank ___ 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] Multilink PPP Was - Re: Balancing T1's with CEF
All of this is further confirmation that if its IP that you need to send over multiple T1's, much better to get an ADC or like box that does Ethernet over one or more raw T-1's. Abstracts the whole transport issue, and gives Ethernet interfaces on both sides. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Thursday, July 30, 2009 11:02 AM To: ci...@peakpeak.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF We had a problem with balancing 3 T1s between 2 T1s on a dual port T1 controller WIC and the 3rd on a single port service module. Cisco TAC swore up and down that it SHOULD balance between the 2 types of WICs but more traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the controller did the trick. (And that's actually the problem that helped me find this wonderful list...THANKS!) -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Brian Raaen Sent: Thursday, July 30, 2009 10:38 AM To: ci...@peakpeak.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF Here is what I have on a multi-link with ATT. interface Multilink1 description X ip address XXX.XXX.XXX.XXX 255.255.255.252 load-interval 30 no keepalive no cdp enable ppp multilink ppp multilink fragment disable ppp multilink group 1 interface Serial1/0:0 description XXX bandwidth 1536 no ip address encapsulation ppp no fair-queue no cdp enable ppp multilink ppp multilink group 1 max-reserved-bandwidth 100 Security Team wrote: Well.we arent' doing per packet and the destinations are definitely different. The last time this problem occurred I did a clear ip cache and it went away. Since it isn't doing it this time I guess I thought I should try something else. Here is what I tried, I tried converting to multilink ppp encaps instead of HDLC to see if that would have any effect, and it didn't. (on both ends): aaa new-model aaa authorization network noauth none aaa session-id common interface Multilink1 no ip address load-interval 30 no cdp enable ppp authorization noauth ppp multilink ppp multilink group 1 no shut ! Interface Serial1/1/0 encapsulation ppp ppp authorization noauth shut no shut ! Interface Serial1/1/3 encapsulation ppp ppp authorization noauth shut no shut ! Interface Serial1/0/0/12:0 encapsulation ppp ppp authorization noauth shut no shut So with 3 static routes like this: ip route x.y.z.0 255.255.255.0 serial1/1/0 ip route x.y.z.0 255.255.255.0 serial1/1/3 ip route x.y.z.0 255.255.255.0 serial1/0/0/12:0 The customer works but still has the problem where all the traffic sacks one line inbound to their 28xx from our 7507. So all we accomplished here really was pre-build a multilink PPP bundle but just change the encaps for each serial interface to PPP instead of HDLC. Then I thought what I'd do is add each serial interface to the multilink bundle using: Int Serial1/1/0 ppp multilink ppp multilink group 1 Int Serial1/1/3 ppp multilink ppp multilink group 1 Int Serial1/0/0/12:0 ppp multilink ppp multilink group 1 That is when the fun stopped (no packets routed at all). I did get this message on the console: Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: Link(Serial1/0/0/12:0) added, Bundle(Multilink1) may not be distributed Not sure what this means. So I assume what I should have done in addition to adding the ppp multilink grouping to the serial interfaces is remove the static routes and replace them with this instead right? ip route x.y.z.0 255.255.255.0 Multilink1 I haven't ever configured multilink PPP before but this is right isn't it? Thanks, CJ On 7/30/09 7:32 AM, Matthew Huff mh...@ox.com wrote: Unless you do per-packet load-sharing (which you don't want to do since it's cpu switched), the path is session based. If most of the traffic is going from one source to one destination, it won't be load-shared. What do the routing tables look like in both directions? Matthew Huff | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139 -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of Security Team Sent: Wednesday, July 29, 2009 11:24 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Balancing T1's with CEF I rebooted a 7507 router that had a site connected with 3 T1's and now all the traffic is nailing one line instead of being distributed over all 3 using the static routes/CEF. I did look at the Cisco troubleshooting tips but didn't see anything
Re: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF
I wrote ADC but I meant, RAD, my fault. http://www.ethernetaccess.com/Home/0,6583,19337,00.html These basically bond T-1s and are carrier independent. All that either end sees is an Ethernet port. They appear to have QoS priority queues, thought I'm not personally familiar with this product to say anything more than what is in their data sheets. Frank -Original Message- From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com] Sent: Thursday, July 30, 2009 1:22 PM To: frnk...@iname.com Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF We are going to be deploying some more MLPPP ckts here in the next few months and I am not familiar with ADCs. Are those carrier dependant? Does this affect MPLS QoS? Thanks, -Jeff -Original Message- From: Frank Bulk - iName.com [mailto:frnk...@iname.com] Sent: Thursday, July 30, 2009 1:19 PM To: Jeff Wojciechowski; ci...@peakpeak.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF All of this is further confirmation that if its IP that you need to send over multiple T1's, much better to get an ADC or like box that does Ethernet over one or more raw T-1's. Abstracts the whole transport issue, and gives Ethernet interfaces on both sides. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Wojciechowski Sent: Thursday, July 30, 2009 11:02 AM To: ci...@peakpeak.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF We had a problem with balancing 3 T1s between 2 T1s on a dual port T1 controller WIC and the 3rd on a single port service module. Cisco TAC swore up and down that it SHOULD balance between the 2 types of WICs but more traffic was being sent over the WIC T1-DSU. Replacing the WIC 1-DSU with the controller did the trick. (And that's actually the problem that helped me find this wonderful list...THANKS!) -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Brian Raaen Sent: Thursday, July 30, 2009 10:38 AM To: ci...@peakpeak.com Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Multilink PPP Was - Re: Balancing T1's with CEF Here is what I have on a multi-link with ATT. interface Multilink1 description X ip address XXX.XXX.XXX.XXX 255.255.255.252 load-interval 30 no keepalive no cdp enable ppp multilink ppp multilink fragment disable ppp multilink group 1 interface Serial1/0:0 description XXX bandwidth 1536 no ip address encapsulation ppp no fair-queue no cdp enable ppp multilink ppp multilink group 1 max-reserved-bandwidth 100 Security Team wrote: Well.we arent' doing per packet and the destinations are definitely different. The last time this problem occurred I did a clear ip cache and it went away. Since it isn't doing it this time I guess I thought I should try something else. Here is what I tried, I tried converting to multilink ppp encaps instead of HDLC to see if that would have any effect, and it didn't. (on both ends): aaa new-model aaa authorization network noauth none aaa session-id common interface Multilink1 no ip address load-interval 30 no cdp enable ppp authorization noauth ppp multilink ppp multilink group 1 no shut ! Interface Serial1/1/0 encapsulation ppp ppp authorization noauth shut no shut ! Interface Serial1/1/3 encapsulation ppp ppp authorization noauth shut no shut ! Interface Serial1/0/0/12:0 encapsulation ppp ppp authorization noauth shut no shut So with 3 static routes like this: ip route x.y.z.0 255.255.255.0 serial1/1/0 ip route x.y.z.0 255.255.255.0 serial1/1/3 ip route x.y.z.0 255.255.255.0 serial1/0/0/12:0 The customer works but still has the problem where all the traffic sacks one line inbound to their 28xx from our 7507. So all we accomplished here really was pre-build a multilink PPP bundle but just change the encaps for each serial interface to PPP instead of HDLC. Then I thought what I'd do is add each serial interface to the multilink bundle using: Int Serial1/1/0 ppp multilink ppp multilink group 1 Int Serial1/1/3 ppp multilink ppp multilink group 1 Int Serial1/0/0/12:0 ppp multilink ppp multilink group 1 That is when the fun stopped (no packets routed at all). I did get this message on the console: Jul 30 09:03:09 MDT: %RP_MLP-5-LINKTYPEMISMATCH: Link(Serial1/0/0/12:0) added, Bundle(Multilink1) may not be distributed Not sure what this means. So I assume what I should have done in addition to adding the ppp multilink grouping to the serial interfaces is remove the static routes and replace them with this instead right? ip route x.y.z.0 255.255.255.0 Multilink1 I haven't ever configured multilink PPP before
Re: [c-nsp] Monitoring BGP with NAGIOS
Ian: Thanks for your input. I agree, snmptraps are the next obvious step. The URL you provided was the one I refered to when looking through the results of my walk through Cisco's BGP MIB. =) Since my upstream monitors our edge routers, including BGP, the monitoring is more to document that something happened. I won't have it page me at 3 in the morning, but when my upstream tells me that they're doing maintenance, I'll know when I wake up if it did impact BGP. It's also another input into my event correlation system (me) -- if a customer tells me that they've lost internet access, or if I've asked for another netblock to be advertised, I'll know immediately to look at a routing issue. Frank -Original Message- From: Ian MacKinnon [mailto:ian.mackin...@lumison.net] Sent: Thursday, July 23, 2009 9:15 AM To: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] Monitoring BGP with NAGIOS Hi Frank, You say maybe traps is the next step. You can get an snmp trap when a peer changes state, you can then get nagios to respond to the traps using traphandler Some info at http://www.cisco.com/en/US/docs/ios/12_3t/12_3t7/feature/guide/gt_bmibe.html We are using nagios and traphandlers to respond to things like link up/down I guess if you poll often enough you can be sure to catch a peer in a bad state, but do you actually care at 3 in the morning that a peer was down for 30s and is now back? Ian -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Frank Bulk Sent: 23 July 2009 15:04 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Monitoring BGP with NAGIOS We're a small shop and our group's upstream is single-homed in terms of providers but dual-homed in terms of physical connectivity, with a private ASN. Occasionally there's BGP events and I would like to be remotely notified -- NAGIOS can do that and I prefer SNMP polling. We're not doing an SNMP TRAP or syslog processing at this time - that would be an obvious next step for us. Currently the NAGIOS plugin I'm developing polls the bgpPeerState, bgpPeerIn/OutUpdates and bgpPeerIn/OutTotalMessages and alerts me if there's a change. Since a BGP session could be re-established in a short amount of time, I would like to trigger an alert if the number of In/Out Updates or Messages exceeds the regular value (I'm presuming that when the BGP session re-establishes, these counters climb more quickly than during times of stability). But I'm not sure if Updates/Messages are normally sent every 30 or 60 seconds (I've seen 60 on a wiki page, but sh ip bgp neighbors says that the keepalive interval is 30 seconds and Default minimum time between advertisement runs is 30 seconds. I'm guessing this knob can be adjusted in IOS, so ideally I would like the NAGIOS plugin to accommodate for that, such that if the counters move '5' in 5 minutes that's OK with a 60 second period, but if it's a 30 second period, then those counts should move 10 times. But keep-alive/scan interval doesn't seem to be listed in the MIB. Also, there's a lot more information available at the Cisco CLI when executing sh ip bgp summary, specifically: . BGP table version . # of network entries . # of path entries . # of prefixes . # of paths . Up/Down times Is any of that available via SNMP, because my walking isn't showing that at all? If you think I'm going about this the wrong way, please feel free to tell me. =) Regards, Frank ___ 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/ Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database: 270.13.20/2249 - Release Date: 07/21/09 18:02:00 -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ 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] Monitoring BGP with NAGIOS
Thanks. I had compiled RFC1213-MIB into my MIB browser, but not BGP4-MIB. Once I did, it was all there The stuff at NAGIOS exchange left me wanting, which is why I'm fleshing out my own. Frank -Original Message- From: nicot...@radiological.warningg.com [mailto:nicot...@radiological.warningg.com] On Behalf Of Brandon Ewing Sent: Thursday, July 23, 2009 11:10 AM To: Frank Bulk Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Monitoring BGP with NAGIOS snip BGP4-MIB::bgpPeerHoldTime ( .1.3.6.1.2.1.15.3.1.18 ) BGP4-MIB::bgpPeerKeepAlive ( .1.3.6.1.2.1.15.3.1.19 ) Hold time is 3x keepalive by default Updates are sent as they are processed There are also OIDs for the locally configured hold and keepalive timers, as you will use your peer's configured timers if they are lower. Also, there's a lot more information available at the Cisco CLI when executing sh ip bgp summary, specifically: . Up/Down times BGP4-MIB::bgpPeerInUpdateElapsedTime ( .1.3.6.1.2.1.15.3.1.24 ) BGP4-MIB::bgpPeerLastError ( .1.3.6.1.2.1.15.3.1.14 ) If you think I'm going about this the wrong way, please feel free to tell me. =) Have you looked at the following plugins in the Nagios Exchange? http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/che ck_bgp_neighbors/details http://exchange.nagios.org/directory/Plugins/Uncategorized/Software/SNMP/che ck_bgp/details Cisco's MIB Browser also has a wealth of information regarding BGP SNMP http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=enstep=2mibName= BGP4-MIB -- Brandon Ewing(nicot...@warningg.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/
Re: [c-nsp] hung vty on SXH3a?
Have you tried the SNMP approach? Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gert Doering Sent: Wednesday, June 03, 2009 2:16 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] hung vty on SXH3a? Hi, so far, we have been quite happy with SXH3a, but today two of our boxes have started playing games with me... notably, the command we use to auto-upload ACLs etc rcp new_config.txt router:running-config started to fail with rcp: running-config: No such file or directory. On other boxes, it works as usual. All the ip rcmd config is present and sane. The only thing that looks different is this: Cisco#who Line User Host(s) Idle Location 1 vty 0Virtual Exec 00:00:00 * 2 vty 1 gert idle 00:00:00 mgmthost Interface UserMode Idle Peer Address Cisco# - vty 0 looks weird. I can't find a way to recover that vty, that is clear line 1 or clear line vty 0 don't change anything. Nor is there a TCB assigned to it (show tcp vty 1 shows my telnet connection, but show tcb vty 0 doesn't display anything). So... is this a known bug in SXH3a? Is there a way to reclaim that VTY without rebooting? (I've also tried configuring transport input none under line vty 0, and to completely disable ip rcmd ... to get rid of the session, but no change either). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de ___ 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 analyzer suggestions
It's not cheap, but Xangati may be a good match. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Andy Dills Sent: Tuesday, June 02, 2009 2:21 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Netflow analyzer suggestions Hi there, Apologies for the non-cisco specific post, but I couldn't think of a better list to post to off of the top of my head. A friend of mine is looking to get some better visibility into their network usage (low bandwidth, T1 type scenario). I got them setup with an IOS that supports netflow v9, and since they had a freebsd box being barely used, I built ntop to be their collector/analyzer. It works reasonably well, but it's perhaps not quite...user friendly enough for them. What they're looking for is a graphical representation at the host level. In essence, they're looking for something like cricket/mrtg but with each IP having its own graph (rather than each interface). Additional features, such as protocol breakdown and so forth are helpful, but the primary desire is to be able to see how much bandwidth a given IP address is using currently and was using in the past. They're open to commercial solutions, but would prefer to keep costs down. Host operating system requirements for the collector/analyzer aren't important. Does anybody have any suggestions they could pass along? Thanks, Andy --- Andy Dills Xecunet, Inc. www.xecu.net 301-682-9972 --- ___ 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] Egress shaping/policing for bandwidth control on a 3750-ME
Thanks for the idea, but the port carries multiple VLANs. Only one of them needs to be rate-limited. Frank -Original Message- From: Alex Moya [mailto:alexm...@bellsouth.net] Sent: Tuesday, March 10, 2009 6:46 AM To: Brad Henshaw Cc: frnk...@iname.com; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Egress shaping/policing for bandwidth control on a 3750-ME Try policing the port Sent from my iPhone On Mar 9, 2009, at 7:59 PM, Brad Henshaw brad.hens...@qcn.com.au wrote: Frank Bulk - iName.com wrote: I have two Cisco 3750-ME (Metro) where we are trying to apply an 8 Mbps bandwidth limit to it. We tried HQM shaping but got a lovely message that Hierarchical service-policies are only supported on ES interfaces. Frank, The 3750ME can only do per-VLAN shaping on the ES ports. You can shape standard ports (but not per-VLAN) in increments of 10% of the port speed using the 'srr-queue bandwidth limit' command. To achieve 8Mbps with this you'd need to lock the [FastEthernet] port to 10Mbps and set the limit to 80%. Buffering of packets is less than ideal. The 3750ME supports hierarchical dual-level *ingress* policies on SVIs. To use these you need to set 'mls qos vlan-based' on the port and may or may not need to use a 'match input-interface' statement in the class of a subpolicy. (I've never used these so can't comment with authority) I'd provide an example but I'd just be ripping it from page 35-71 of the 3750 Metro 12.2(46)SE Software Configuration Guide ;-) I'm pretty sure neither SVIs nor standard ports support output policies so you'd best do as much as you can on the ES ports on ingress from your core. Note that ingress service policies on 12.2(44)SE1 seem to be broken - This may also affect other versions. We never logged a bug because it's fixed in 12.2(46)SE. Overall I think the quality control on IOS releases for the 3750ME leaves a BLOODY LOT to be desired. Regards, Brad ___ 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/
[c-nsp] Egress shaping/policing for bandwidth control on a 3750-ME
I have two Cisco 3750-ME (Metro) where we are trying to apply an 8 Mbps bandwidth limit to it. We tried HQM shaping but got a lovely message that Hierarchical service-policies are only supported on ES interfaces. When we tried policing, we can't seem to apply the mls qos bridged command to it: router(config)#interface vlan 260 router(config-if)#mls ? % Unrecognized command router(config-if)#mls This is the relevant configuration to our policing attempt: ip access-list extended customer-policer_inbound permit ip any any ip access-list extended customer-policer_outbound permit ip any any class-map match-any customer-networks match access-group name customer-policer_inbound match access-group name customer-policer_outbound ! policy-map customer-policer class customer-networks police 800 100 exceed-action drop ! interface Vlan260 mls qos bridged service-policy input customer-policer service-policy output customer-policer ! interface Gi1/0/1 mls qos vlan-based ! To get shaping work we should have had the uplink interface use non-ES ports and the interface facing our core use the ES ports. Any other ideas in terms or policing/shaping? Regards, Frank ___ 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] DHCP Binding Expiration
The ability to provide a new/different IP every time has been oft-discussed on ISC' dhcp-user listserv. IIRC, it contradicts the spec. You would have customize the code to have that functionality, or, as someone said, play with the leases file. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Justin Shore Sent: Monday, February 09, 2009 1:30 PM To: Church, Charles Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] DHCP Binding Expiration snip One thing on my to do list is to figure out how to always reject lease extension requests to force the CPE to pull a new IP every time a lease expires. This would prevent many of the less technical users from trying to run a publicly-accessible server. Set the lease time to 2 hours, client tries to extend the lease at 50% of the lease (1hr) and the server NAKs. The only question is will the client continue to request the IP until the lease expires before falling back and do a DISCOVER at the 2hr mark (interrupting the flow of traffic) or will it do a bcast DISCOVER in response to the NAK and immediately switch to the new IP once it gets an OFFER 1hr before the original lease expires, thus interrupting traffic again. I've seen systems do something similar before (or at least I thought they were). When I first got Cox CATV I could only keep my IP for about a day before it changed. One way to mitigate the flow of traffic problem would be to grant short lease extensions automatically until the wee hours of the morning and then force the change. Something to think about. It's on my list right behind setting up an OSS walled garden and convincing the boss to replace our 7 different DHCP provisioning systems with CNR. Oh, and finishing my IPv6 deployment. Thanks for the info Justin ___ 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 sessions
I've asked this before on cisco-bba: there doesn't appear to be an OID for that. I'm afraid you might need to screen-scrape. Frank -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mohammad Khalil Sent: Wednesday, February 04, 2009 8:53 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] PPPoA sessions Hey all , i have a router with PPPoE and PPPoA sessions i used to the OID 1.3.6.1.4.1.9.9.194.1.1.1 to draw the PPPoE sessions i searched for OID to draw the PPPoA but didnt find an OID for it can anyone help ?? _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspx; mkt=en-us ___ 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/
