Re: [c-nsp] NTP synchronization problems C2801
Hi, On Wed, Jun 30, 2010 at 12:48:28AM +0200, Peter Rathlev wrote: If both devices were the same I would just shrug and think the C2801 wasn't up to the job. But I have one device with no problems and another acting up. Why is that? :-) My standard comment would be IOS letter overflow, but 15.0M doesn't actually have a letter. But a bug sounds likely, there have been a number of NTP changes late in the 12.4T train - maybe one of them is problematic on your hardware (as far as I understand, the NTP clock adjustment bit in IOS is somewhat hardware-specific) 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-35655025g...@net.informatik.tu-muenchen.de pgpN29SEQLNbL.pgp Description: PGP signature ___ 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] 6PE: was: mpls over native ipv6?
On 30 June 2010 02:57, Harold Ritter hrit...@cisco.com wrote: Hi Christian, Most recent IOS versions should support 6PE. The command mpls ipv6 source-interface has been removed from most recent IOS versions as well. This command only applied to locally originated traffic and the source address selection is now as per RFC3484. And what IPv6 address should it be used by 6PE router when originating ICMPv6 packets in response to traceroutes coming from behind the MPLS network? On 7600 with SRB7[1] and SRD[2] it takes an IPv6 address that is configured on the first physical interface (ie. not SVI) visible in the configuration... Not like with MPLS/VPNs where the source address is taken from the egress interface towards VPN. Bug? Best Regards, -mat [1] Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRB7, RELEASE SOFTWARE (fc1) [2] Cisco IOS Software, c7600rsp72043_rp Software (c7600rsp72043_rp-ADVIPSERVICESK9-M), Version 12.2(33)SRD, RELEASE SOFTWARE (fc2) ___ 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] smaller PI
Hi guys, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan signature.asc Description: OpenPGP digital signature ___ 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] smaller PI
That's an interesting development... I know that some providers run filters to filter anything longer than /24, so this may be an interesting experience... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jan Gregor Sent: Wednesday, June 30, 2010 14:54 To: cisco-nsp@puck.nether.net Subject: [c-nsp] smaller PI Hi guys, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan ___ 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] smaller PI
It is like it is. RIPE NCC allocates PI according to the demand within 12 months. If it is a /26, you'll get a /26. RIPE NCC does not guarantee that the block they allocate is routable. Tricky eh? There is a policy proposal to make PI blocks at least /24 in case it is planned to announce them to the DFZ. -Sascha On Wed, 30 Jun 2010, Arie Vayner (avayner) wrote: That's an interesting development... I know that some providers run filters to filter anything longer than /24, so this may be an interesting experience... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jan Gregor Sent: Wednesday, June 30, 2010 14:54 To: cisco-nsp@puck.nether.net Subject: [c-nsp] smaller PI Hi guys, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan ___ 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] smaller PI
Hi, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan Will anybody accept a prefix smaller than a /24 (we won't for one ;-) ? It isn't in addition to existing PI space is it, so they actually have a larger block than this to advertise? Nope, it's just that /26 . Probably other parts of that /24 will be assigned to other customers. Best regards, Jan signature.asc Description: OpenPGP digital signature ___ 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] smaller PI
Hi Jan, this isn't uncommon. RIPE issues address space on the documented need independent of routing requirements. So if you document a need of 60 addresses there'll be no rounding up /24-wise. This is intendend with the policies and - I don't remember the details - a policy proposal to change this got stuck, withdrawn or not approved. Many voices from the community given in the discussion opted for this being a providers problem and sooner or later providers have to open up filters for any crap advertisements. regards, Marcus -Ursprüngliche Nachricht- Von: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] Im Auftrag von Jan Gregor Gesendet: Mittwoch, 30. Juni 2010 13:54 An: cisco-nsp@puck.nether.net Betreff: [c-nsp] smaller PI Hi guys, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan ___ 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] 6500/Sup720 losing startup-config
On 06/29/2010 10:16 PM, Peter Rathlev wrote: On Tue, 2010-06-29 at 18:24 +0200, Asbjorn Hojmark - Lists wrote: On Tue, 29 Jun 2010 17:53:48 +0200, you wrote: Anybody have a clue about what I could do? Other than have it replaced? :-) The solution *is* to have it RMA'ed. We currently have no service contract covering hardware replacement for this device. :-| Remember, support is on the chassis - just plug it into something you do have support on ;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/
Re: [c-nsp] smaller PI
That's weird, PI stands for provider independent. How can one be independent with a non-routable IP range??? Where did the try to aggregate as much as possible concept go to? Ziv -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Sascha Pollok Sent: Wednesday, June 30, 2010 3:28 PM To: Arie Vayner (avayner) Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] smaller PI It is like it is. RIPE NCC allocates PI according to the demand within 12 months. If it is a /26, you'll get a /26. RIPE NCC does not guarantee that the block they allocate is routable. Tricky eh? There is a policy proposal to make PI blocks at least /24 in case it is planned to announce them to the DFZ. -Sascha On Wed, 30 Jun 2010, Arie Vayner (avayner) wrote: That's an interesting development... I know that some providers run filters to filter anything longer than /24, so this may be an interesting experience... Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jan Gregor Sent: Wednesday, June 30, 2010 14:54 To: cisco-nsp@puck.nether.net Subject: [c-nsp] smaller PI Hi guys, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan ___ 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 footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals computer viruses. 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/
Re: [c-nsp] smaller PI
On Wed, 30 Jun 2010, Ziv Leyes wrote: That's weird, PI stands for provider independent. How can one be independent with a non-routable IP range??? Where did the try to aggregate as much as possible concept go to? The RIRs guarantee uniqueness, not routability. If the space just needs to be unique, it's not an issue. If it needs to be unique and routed on the public internet, it seems a little silly for an RIR to allocate IPs they know will not be generally accepted by the internet. AFAIK, filtering longer than /24 is pretty common practice. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] smaller PI
Well, I just did a quick look up on the current routing table, and it seems that there are quite a few /25 and /26 in there with quite long as-paths, so it seems that this nothing longer than /24 policy is not strongly enforced. Arie -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jan Gregor Sent: Wednesday, June 30, 2010 15:40 To: pete.barnw...@whole.net.uk Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] smaller PI Hi, one of our customers requested PI adresses from RIPE (for whatever reason) and got back /26. Opinions? Best regards, Jan Will anybody accept a prefix smaller than a /24 (we won't for one ;-) ? It isn't in addition to existing PI space is it, so they actually have a larger block than this to advertise? Nope, it's just that /26 . Probably other parts of that /24 will be assigned to other customers. Best regards, Jan ___ 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] smaller PI
Hi, On Wed, Jun 30, 2010 at 03:55:12PM +0300, Ziv Leyes wrote: That's weird, PI stands for provider independent. How can one be independent with a non-routable IP range??? PI space can be used for things that are not on the global Internet but still need unique IP addresses (e.g. VPN rendevouz networks between large enterprises). There's a RIPE policy proposal on the table to change the minimum PI assignment size to a /24 (if needed for routing reasons) - which didn't get consensus last round, but a new victim^Wproposer was^W volunteered and will now try to get consensus on it. Where did the try to aggregate as much as possible concept go to? Now *that* has nothing whatsoever to do with the *size* of a PI chunk - PI is, by definition, not aggregateable, and a /24 PI will need the same amount of TCAM space as a /8. 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-35655025g...@net.informatik.tu-muenchen.de pgp0L1nZIwswX.pgp Description: PGP signature ___ 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] smaller PI
...And several shops filter on per-/8 RIR allocation min + maxes, too! Bassically, a /24 isn't a safe, global assumption, unless from swamp space and/or a RIR portion specifically created for micro-allocations. Take note of the cisco isp ingress strcit prefix list on the ftp site. Folks *are* using the examples linked from: http://blogs.cisco.com/security/comments/surprise_all_your_prefix_are_belong_to_us/ -Tk -Original Message- From: Jon Lewis jle...@lewis.org Sender: cisco-nsp-boun...@puck.nether.net Date: Wed, 30 Jun 2010 09:14:05 To: Ziv Leyesz...@gilat.net Cc: cisco-nsp@puck.nether.netcisco-nsp@puck.nether.net Subject: Re: [c-nsp] smaller PI On Wed, 30 Jun 2010, Ziv Leyes wrote: That's weird, PI stands for provider independent. How can one be independent with a non-routable IP range??? Where did the try to aggregate as much as possible concept go to? The RIRs guarantee uniqueness, not routability. If the space just needs to be unique, it's not an issue. If it needs to be unique and routed on the public internet, it seems a little silly for an RIR to allocate IPs they know will not be generally accepted by the internet. AFAIK, filtering longer than /24 is pretty common practice. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] smaller PI
On Wed, 30 Jun 2010 tkap...@gmail.com wrote: ...And several shops filter on per-/8 RIR allocation min + maxes, too! Bassically, a /24 isn't a safe, global assumption, unless from swamp space and/or a RIR portion specifically created for micro-allocations. Take note of the cisco isp ingress strcit prefix list on the ftp site. Folks *are* using the examples linked from: http://blogs.cisco.com/security/comments/surprise_all_your_prefix_are_belong_to_us/ Or you could look at http://jonsblog.lewis.org/2008/01/19#bgp IIRC, even when I wrote that, there were one or more /8s from which RIPE said the longest prefix they'd allocate was 24. 91/8, 193/8, and 194/7 are all listed as longest prefix = /29! When I wrote the filter referenced above, I chose to ignore this and filter these ranges denying /25 and longer. Does RIPE really expect everyone to accept BGP routes as long as /29? I just checked our BGP feed from Level3, and they're not sending us anything longer than /24. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] smaller PI
Well, I just did a quick look up on the current routing table, and it seems that there are quite a few /25 and /26 in there with quite long as-paths, so it seems that this nothing longer than /24 policy is not strongly enforced. I'd say that depends. We certainly enforce /24 at our borders, and have no plans to change that policy. 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] smaller PI
IIRC, even when I wrote that, there were one or more /8s from which RIPE said the longest prefix they'd allocate was 24. 91/8, 193/8, and 194/7 are all listed as longest prefix = /29! When I wrote the filter referenced above, I chose to ignore this and filter these ranges denying /25 and longer. Does RIPE really expect everyone to accept BGP routes as long as /29? Maybe they do. But it's not likely to happen on a universal scale. We filter at /24 and have no plans to change. I just checked our BGP feed from Level3, and they're not sending us anything longer than /24. We're receiving /25s and /26s from Global Crossing. Which we promptly drop in the bit bucket. 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] SNMP MIB for Receiving Prefix Counts for Individual Peers
Seeing as that was published in Feb 2010, I doubt it's supported by anything yet... I guess I'll have to wait and see... On Wed, Jun 30, 2010 at 9:16 AM, Per Carlson pe...@hemmop.com wrote: Hi Gary. Is anyone aware of a MIB that supports querying the number of prefixes (not the individual prefixes) received from a BGP peer? There is an I-D supporting this: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-10 From the Overview section: This MIB addresses several of the deficiencies of the previous BGP-4 MIB. In particular: o Add several counters of operational interest. For example, the number of routes received from a given BGP peer. Finding a software supporting the I-D is another story... -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ cisco-nsp mailing list cisco-...@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] Troubleshooting Input Queue Drops on 7600 running 12.2(33)SRC5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All: I am seeing increasing input queue drops on a 7600 running 12.2(33)SRC5 on a SPA-2X1GE in a 7600-SIP-400. #sh int g1/1/1 GigabitEthernet1/1/1 is up, line protocol is up Hardware is GigEther SPA, address is 001d.7170.3500 (bia 001d.7170.3500) Description: Internet address is x.x.x.x/yy MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 72/255, rxload 46/255 Encapsulation ARPA, loopback not set Keepalive not supported Full Duplex, 1000Mbps, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 01:44:10 Input queue: 0/75/1707/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 183245000 bits/sec, 41346 packets/sec 5 minute output rate 283924000 bits/sec, 55078 packets/sec 256319513 packets input, 149816057859 bytes, 0 no buffer Received 5 broadcasts (0 IP multicasts) 0 runts, 1707 giants, 0 throttles 1707 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 308870586 packets output, 193458081331 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out I also ran sh int g1/1/1 switching and it looks like the RP is dropping the packets. #sh int g1/1/1 switching GigabitEthernet1/1/1 Throttle count 0 Drops RP 1706 SP 0 SPD Flushes Fast 0SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 7257 Drops 0 Protocol PathPkts In Chars In Pkts Out Chars Out OtherProcess 0 0 0 0 Cache misses 0 Fast 0 0 0 0 Auton/SSE 15978 958680 0 0 IPProcess 80379934 7498092736 42273104 3084247027 Cache misses 0 Fast 68341283 50171546761197481 86714780 Auton/SSE 401843915443 245108148367129 516300637842 386876899705145 DEC MOPProcess 0 0 317002440900 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 ARPProcess 15978 958680 15866 951960 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 Any advice on troubleshooting? I looked at http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml and show buffers input-interface g1/1/1 header does not display any data and performing debug ip packet on a production router may not be in my best interests. :) - -- Devon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrYxwACgkQWP2WrBTHBS+BUACfQ65VbBf9rWz7p2z952IvRp5q LpQAn0iRMn5Gv4vB26f+zcs8+ZwB1W5x =+tUx -END PGP SIGNATURE- ___ 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] smaller PI
Does RIPE really expect everyone to accept BGP routes as long as /29? Maybe they do. But it's not likely to happen on a universal scale. We filter at /24 and have no plans to change. Imho, that is not fair to network community to have such filters if RIRs are giving these IPs to ppl out there. It is somehow us that delegated RIPE and such to provide us with policies and guard our IP usage. If they decided to give smaller allocations to save space (or otherwise) we should comply. I wouldn't like to have my fully legal prefixes to be dropped out of the internet just because someone wants to have /xx on its borders. Having said that I must admit that we do have /24 filtering, but frankly speaking I learnt today that RIPE is giving longer prefixes that /24, so I think we should update the filters accordingly to include these microallocations. That doesn't mean that I am for deagregation of routes outside of that microallocations and I think /24 limit is reasonable to protect against it. Best Regards, -mat ___ 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] smaller PI
On 6/30/10 6:18 AM, Arie Vayner (avayner) wrote: Well, I just did a quick look up on the current routing table, and it seems that there are quite a few /25 and /26 in there with quite long as-paths, so it seems that this nothing longer than /24 policy is not strongly enforced. Many providers will send prefixes longer than a /24 to their customers but not out to their peers. I could announce a /25 to Sprint, for example, but only other Sprint customers will see it. ~Seth ___ 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] smaller PI
On 30-6-2010 14:28, Sascha Pollok wrote: It is like it is. RIPE NCC allocates PI according to the demand within 12 months. If it is a /26, you'll get a /26. RIPE NCC does not guarantee that the block they allocate is routable. Tricky eh? There is a policy proposal to make PI blocks at least /24 in case it is planned to announce them to the DFZ. It has been changed recently, now your needs will be meet only for 9 months. It is the run out fairly policy. In a couple of months it will be 6 months, eventually 3. And then the IP's will be over. -- Grzegorz Janoszka ___ 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] NTP synchronization problems C2801
M isn't a letter?? :) On Wed, Jun 30, 2010 at 04:56, Gert Doering g...@greenie.muc.de wrote: Hi, On Wed, Jun 30, 2010 at 12:48:28AM +0200, Peter Rathlev wrote: If both devices were the same I would just shrug and think the C2801 wasn't up to the job. But I have one device with no problems and another acting up. Why is that? :-) My standard comment would be IOS letter overflow, but 15.0M doesn't actually have a letter. But a bug sounds likely, there have been a number of NTP changes late in the 12.4T train - maybe one of them is problematic on your hardware (as far as I understand, the NTP clock adjustment bit in IOS is somewhat hardware-specific) gert -- USENET is *not* the non-clickable part of WWW! // www.muc.de/~gert/ http://www.muc.de/%7Egert/ 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/ ___ 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] smaller PI
Hi, On Wed, Jun 30, 2010 at 09:57:47AM -0400, Jon Lewis wrote: Does RIPE really expect everyone to accept BGP routes as long as /29? RIPE doesn't expect anyone to accept anything. RIPE deals in addresses, not in routing. (Yes, this sounds a bit academic - but there is a point to it: what if the operator community decides next year that /24s are evil, and only /23s are to be accepted? Does this mean that RIPE will have to upgrade all existing PI blocks to /23s?) 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-35655025g...@net.informatik.tu-muenchen.de pgp3C8Exyib0x.pgp Description: PGP signature ___ 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] smaller PI
On Wed, 30 Jun 2010, Gert Doering wrote: On Wed, Jun 30, 2010 at 09:57:47AM -0400, Jon Lewis wrote: Does RIPE really expect everyone to accept BGP routes as long as /29? RIPE doesn't expect anyone to accept anything. RIPE deals in addresses, not in routing. Yeah...I mentioned in my previous message that the RIRs only guarantee uniqueness of the numbers they assing...not routability on the public internet. (Yes, this sounds a bit academic - but there is a point to it: what if the operator community decides next year that /24s are evil, and only /23s are to be accepted? Does this mean that RIPE will have to upgrade all existing PI blocks to /23s?) Have to? Maybe not...but I bet they'd get flooded with requests. The RIRs can't guarantee general routability, but it seems disingenuous of them to assign a /27 to a multihomed network when it's well known that a /27 won't work for them...unless they only plan to use that /27 internally and use PA space for their BGP announced route. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] smaller PI
Hi, On Wed, Jun 30, 2010 at 12:54:49PM -0400, Jon Lewis wrote: (Yes, this sounds a bit academic - but there is a point to it: what if the operator community decides next year that /24s are evil, and only /23s are to be accepted? Does this mean that RIPE will have to upgrade all existing PI blocks to /23s?) Have to? Maybe not...but I bet they'd get flooded with requests. The RIRs can't guarantee general routability, but it seems disingenuous of them to assign a /27 to a multihomed network when it's well known that a /27 won't work for them...unless they only plan to use that /27 internally and use PA space for their BGP announced route. Well, the current RIPE policies state you get the number of addresses that you need to number your devices (without that specific wording). It specifically doesn't say if you have special technical needs, we'll graciously round up the numbers to 32+ times the number of machines that you have (/29 - /24). Of course this is because the same rules apply to PA and to PI holders - and we've told PA holders since 10+ years no, if you only have 5 machines, I am not going to give you a 'Class C', here's a /29, and that's all you're gonna get!. So changing these rules for PI /24 for free, just say the magic word! is frowned-upon by many in the community... But in the end, IPv4 just sucks, and I'm happy when it's finally used up. IPv6 PI is a /48, no matter how big or small the company, so RIPE can nicely keep out of the we can't give you what you want, so you lie to us, and get it anyway mess. 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-35655025g...@net.informatik.tu-muenchen.de pgpgMDTldao6k.pgp Description: PGP signature ___ 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] SNMP MIB for Receiving Prefix Counts for Individual Peers
Wed, Jun 30, 2010 at 10:52:25AM -0400, Gary T. Giesen: Seeing as that was published in Feb 2010, I doubt it's supported by anything yet... I guess I'll have to wait and see... this is still a draft, but you should ask your vendors to add per-afi/safi support (please). juniper and cisco have enterprise mibs with some of the data (ie: at least ipv4), of course it depends on O/S revision. On Wed, Jun 30, 2010 at 9:16 AM, Per Carlson pe...@hemmop.com wrote: Hi Gary. Is anyone aware of a MIB that supports querying the number of prefixes (not the individual prefixes) received from a BGP peer? There is an I-D supporting this: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-10 From the Overview section: This MIB addresses several of the deficiencies of the previous BGP-4 MIB. ?In particular: ? o ?Add several counters of operational interest. ?For example, the ? ? ?number of routes received from a given BGP peer. Finding a software supporting the I-D is another story... -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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/ ___ 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] smaller PI
On 30/06/2010 17:54, Jon Lewis wrote: Have to? Maybe not...but I bet they'd get flooded with requests. The RIRs can't guarantee general routability, but it seems disingenuous of them to assign a /27 to a multihomed network when it's well known that a /27 won't work for them...unless they only plan to use that /27 internally and use PA space for their BGP announced route. The RIPE NCC address policy people are disinterested in routing, although not uninterested. 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/
Re: [c-nsp] smaller PI
Hi, I guess I have just opened jac-in-the-box here :). IMHO if Tier1 accept these prefixes it is ok. Hands up anyone who does not have 0.0.0.0/0 in their network pointing to the upstream :). Could be problem for smaller providers though. Best regards, Jan On 30. 6. 2010 16:00, sth...@nethelp.no wrote: Well, I just did a quick look up on the current routing table, and it seems that there are quite a few /25 and /26 in there with quite long as-paths, so it seems that this nothing longer than /24 policy is not strongly enforced. I'd say that depends. We certainly enforce /24 at our borders, and have no plans to change that policy. 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/ signature.asc Description: OpenPGP digital signature ___ 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] smaller PI
On Wed, 2010-06-30 at 18:28 +0200, Grzegorz Janoszka wrote: It has been changed recently, now your needs will be meet only for 9 months. It is the run out fairly policy. In a couple of months it will be 6 months, eventually 3. And then the IP's will be over. So, what should we do ? I'd say: - Large transit providers (T1) should accept the microalloc from customers peers. - Non-T1 transit providers should setup a default route to T1 upstreams. It may implement non-optimized routing for those prefixes (for T2/T3 networks, except if they accept longer prefixes), but it would be at least reachable worldwide. Well, dreams are beautiful... I don't really see T1 networks accept such small allocs... Regards, -- Clément ___ 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] Troubleshooting Input Queue Drops on 7600 running 12.2(33)SRC5
You could try the 'debug ip cef packet' on the RP, as it captures only sw switched traffic, and it has rate limiting ability built in it. Rodney On 6/30/10 11:30 AM, Devon True wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All: I am seeing increasing input queue drops on a 7600 running 12.2(33)SRC5 on a SPA-2X1GE in a 7600-SIP-400. #sh int g1/1/1 GigabitEthernet1/1/1 is up, line protocol is up Hardware is GigEther SPA, address is 001d.7170.3500 (bia 001d.7170.3500) Description: Internet address is x.x.x.x/yy MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 72/255, rxload 46/255 Encapsulation ARPA, loopback not set Keepalive not supported Full Duplex, 1000Mbps, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters 01:44:10 Input queue: 0/75/1707/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 183245000 bits/sec, 41346 packets/sec 5 minute output rate 283924000 bits/sec, 55078 packets/sec 256319513 packets input, 149816057859 bytes, 0 no buffer Received 5 broadcasts (0 IP multicasts) 0 runts, 1707 giants, 0 throttles 1707 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 308870586 packets output, 193458081331 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out I also ran sh int g1/1/1 switching and it looks like the RP is dropping the packets. #sh int g1/1/1 switching GigabitEthernet1/1/1 Throttle count 0 Drops RP 1706 SP 0 SPD Flushes Fast 0SSE 0 SPD Aggress Fast 0 SPD Priority Inputs 7257 Drops 0 Protocol PathPkts In Chars In Pkts Out Chars Out OtherProcess 0 0 0 0 Cache misses 0 Fast 0 0 0 0 Auton/SSE 15978 958680 0 0 IPProcess 80379934 7498092736 42273104 3084247027 Cache misses 0 Fast 68341283 50171546761197481 86714780 Auton/SSE 401843915443 245108148367129 516300637842 386876899705145 DEC MOPProcess 0 0 317002440900 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 ARPProcess 15978 958680 15866 951960 Cache misses 0 Fast 0 0 0 0 Auton/SSE 0 0 0 0 Any advice on troubleshooting? I looked at http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml and show buffers input-interface g1/1/1 header does not display any data and performing debug ip packet on a production router may not be in my best interests. :) - -- Devon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwrYxwACgkQWP2WrBTHBS+BUACfQ65VbBf9rWz7p2z952IvRp5q LpQAn0iRMn5Gv4vB26f+zcs8+ZwB1W5x =+tUx -END PGP SIGNATURE- ___ 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] NTP synchronization problems C2801
Peter, I'm not a NTP expert but I know there were some issues when it went to v4 regarding sync times, etc... One of them was: CSCte91471NTP v4 takes several hours to sync when multiple servers are configured From looking at the source code that fix doesn't appear to be in 15.0(1)M2. You may want to try it with the next rebuild when it comes out. Rodney On 6/29/10 6:13 PM, Peter Rathlev wrote: I have two devices where one keeps itself synchronized to within 5-10 usec of the NTP servers but the other one varies _wildly_, sometimes having an offset of ~150 ms. The NTP servers are two CentOS 5.4 servers, themselves using two Meinberg M300 GPS devices as stratum 1 sources. Working device: C2801 running 12.4(24)T3 Enterprise Base, 128 MB RAM. Connected to a 3560E as an access device, Fa0/0 has an IP address and a default route pointing at the gateway for that access VLAN. NTP update source is this interface. Non-working device: C2801 running 15.0(1)M2 Enterprise Service, 256 MB RAM. Connected redundantly to two 6500/Sup720s on L3 interfaces. Running IS-IS and MPLS. NTP update source is a Loopback interface. None of the devices are CPU or traffic loaded in any serious way (30% peaks about once per hour, otherwise3%). Both devices are supposed to be doing IP SLA collection. NTP configuration is the same, with just the two servers configured and an update source for one device. (I've cleared the auth config to see if that was it, no change.) The non-working device: non_working#sh ntp status Clock is synchronized, stratum 3, reference is 10.85.247.20 nominal freq is 250. Hz, actual freq is 250.0181 Hz, precision is 2**24 reference time is CFD496F6.08BA94AC (17:59:50.034 CEST Tue Jun 29 2010) clock offset is -27.2854 msec, root delay is 3.51 msec root dispersion is 50.75 msec, peer dispersion is 1.26 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.72382 s/s system poll interval is 16, last update was 70 sec ago. non_working#sh ntp ass address ref clock st when poll reach delay offset disp *~10.85.247.2010.83.8.130 2 8 16 377 1.778 -27.285 1.116 +~10.83.247.2010.83.8.130 2 0 16 377 0.877 -26.844 1.302 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured non_working# And the working device: working#sh ntp status Clock is synchronized, stratum 3, reference is 10.83.247.20 nominal freq is 250. Hz, actual freq is 250.0274 Hz, precision is 2**24 reference time is CFD49516.7C7CB895 (17:51:50.486 CEST Tue Jun 29 2010) clock offset is -0.0051 msec, root delay is 0.00 msec root dispersion is 0.04 msec, peer dispersion is 0.00 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000109809 s/s system poll interval is 256, last update was 564 sec ago. working#sh ntp ass address ref clock st when poll reach delay offset disp +~10.85.247.2010.83.8.130 2233256 377 1.759 -5.567 8.367 *~10.83.247.2010.83.8.130 2232256 377 0.877 -5.194 7.547 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured working# I tried many things, among others to fix the maxpoll interval, adjust scheduler allocation, disable authentication, reset the configuration completely (with no ntpcr) and reset the clock to when Prince was still young to force a stepping. Still the 15.0(1)M2 Ent Serv. simply cannot keeps a precise time. Reachability is perfect (377 all the time) and the device can even see the root offset! It just cannot adjust correctly. I know it takes time (why can't I have an explicit step command in IOS?) but the offset varies, also getting worse over time. Is it because of the extra MPLS encapsulation? The newer IOS version? Another feature set? Or should I just give up? :-) ___ 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] SNMP MIB for Receiving Prefix Counts for Individual Peers
The older MIBs support the prefix count for IPv4. Cisco does not currently support the v2 spec that allows IPv6. That is something they really need to get fixed. LR Mack McBride Network Architect Viawest, Inc. -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Gary T. Giesen Sent: Wednesday, June 30, 2010 8:52 AM To: Per Carlson Cc: c-nsp Subject: Re: [c-nsp] SNMP MIB for Receiving Prefix Counts for Individual Peers Seeing as that was published in Feb 2010, I doubt it's supported by anything yet... I guess I'll have to wait and see... On Wed, Jun 30, 2010 at 9:16 AM, Per Carlson pe...@hemmop.com wrote: Hi Gary. Is anyone aware of a MIB that supports querying the number of prefixes (not the individual prefixes) received from a BGP peer? There is an I-D supporting this: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-10 From the Overview section: This MIB addresses several of the deficiencies of the previous BGP-4 MIB. In particular: o Add several counters of operational interest. For example, the number of routes received from a given BGP peer. Finding a software supporting the I-D is another story... -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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/ ___ 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] SNMP MIB for Receiving Prefix Counts for Individual Peers
Hi. Seeing as that was published in Feb 2010, I doubt it's supported by anything yet... I guess I'll have to wait and see... Still a live document yes. It also hasn't got an OID from IANA yet... -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ 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] LTL?
Newbie question here. LTL -- in the context of the Cisco world -- what is it and what does it do? Sounds like it's some sort of an index to track which ports to forward frames to. However, I believe we may have run into an LTL overflow (older hardware, 32-bit data-size?). Anyone know what might trigger this? Just wanting to get a little background / understanding. What I've read makes it sound like the LTL wouldn't contain all that much data. Thanks, Ray ___ 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] NTP synchronization problems C2801
On Wed, 2010-06-30 at 14:12 -0400, Rodney Dunn wrote: I'm not a NTP expert but I know there were some issues when it went to v4 regarding sync times, etc... One of them was: CSCte91471NTP v4 takes several hours to sync when multiple servers are configured From looking at the source code that fix doesn't appear to be in 15.0(1)M2. You may want to try it with the next rebuild when it comes out. That sounds just like it. I can see the 15.1(1)T also has the same bug, so I guess there's no point in trying that one. I've had an expect script run show ntp status every five minutes on the two devices the last 5-6 hours, and if I extrapolate linearly (R^2=0.76 though) the one running 15.0(1)M2 will be synchronized in around 11 hours, from an offset of ~15 ms now. The bug description says ... after few hours., but this one will have taken nearly 36 hours if the linear extrapolation is correct. Tomorrow I will try to downgrade to 12.4(24)T3 to make sure it isn't hardware related. The one running 12.4(24)T3 now has the past 5 hours never exceeded 1 usec offset according to show ntp status. -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] NTP synchronization problems C2801
Can you try the iburst option to see if it changes it? http://www.cisco.com/en/US/docs/ios/netmgmt/command/reference/nm_10.html#wp1102197 I don't see how going back to 24T would change it as it has v4 there too...unless there was something later that made it even worse. Rodney On 6/30/10 5:25 PM, Peter Rathlev wrote: On Wed, 2010-06-30 at 14:12 -0400, Rodney Dunn wrote: I'm not a NTP expert but I know there were some issues when it went to v4 regarding sync times, etc... One of them was: CSCte91471NTP v4 takes several hours to sync when multiple servers are configured From looking at the source code that fix doesn't appear to be in 15.0(1)M2. You may want to try it with the next rebuild when it comes out. That sounds just like it. I can see the 15.1(1)T also has the same bug, so I guess there's no point in trying that one. I've had an expect script run show ntp status every five minutes on the two devices the last 5-6 hours, and if I extrapolate linearly (R^2=0.76 though) the one running 15.0(1)M2 will be synchronized in around 11 hours, from an offset of ~15 ms now. The bug description says ... after few hours., but this one will have taken nearly 36 hours if the linear extrapolation is correct. Tomorrow I will try to downgrade to 12.4(24)T3 to make sure it isn't hardware related. The one running 12.4(24)T3 now has the past 5 hours never exceeded 1 usec offset according to show ntp status. ___ 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] LTL?
Hi Ray, You're right, LTLs are also known as port selects, it's basically a table in various ASICs that identify which ports should receive a frame. For a unicast frame, the LTL would select a single port; for multicast, could be many or all. What the destination LTL of a packet is inside the box is typically dictated by the forwarding engine lookup. It's a bit more complex than that when you dig into it, but that's it in a nutshell. Note that every physical port in the system has an LTL (destination index) set aside for it so you can't really run out in that case. But in other cases LTLs are a dynamic, limited resource, eg for multicast, there's a fixed number available, each describing a particular fanout or receiver set, so if there are many unique receiver sets then each will burn an LTL from that pool. Some platforms can share those LTLs so if two mcast groups share the same fanout they can share an LTL. Others don't have that capability. The specific capacities capabilities etc are very hardware dependent. The primary shipping platforms that use LTL today that I know of are 6500/7600, and Nexus 7000. What leads you to think you have run into an overflow condition, some error msg I take it? Hope that helps, Tim At 01:13 PM 6/30/2010, Ray Van Dolson contended: Newbie question here. LTL -- in the context of the Cisco world -- what is it and what does it do? Sounds like it's some sort of an index to track which ports to forward frames to. However, I believe we may have run into an LTL overflow (older hardware, 32-bit data-size?). Anyone know what might trigger this? Just wanting to get a little background / understanding. What I've read makes it sound like the LTL wouldn't contain all that much data. Thanks, Ray ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsphttps://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/http://puck.nether.net/pipermail/cisco-nsp/ Tim Stevenson, tstev...@cisco.com Routing Switching CCIE #5561 Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. ___ 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] NTP synchronization problems C2801
On Wed, 2010-06-30 at 17:43 -0400, Rodney Dunn wrote: Can you try the iburst option to see if it changes it? I tried adding iburst, and though it behaves as expected by sending 8 rapid (~4 secs apart it seemed) after initialization I still end up relatively unsynchronized: 10.83.247.20 configured, authenticated, our_master, sane, valid, stratum 2 ref ID 10.85.8.130 , time CFD638BF.C765F6DB (23:42:23.778 CEST Wed Jun 30 2010) our mode client, peer mode server, our poll intvl 64, peer poll intvl 64 root delay 1.70 msec, root disp 25.60, reach 1, sync dist 30.50 delay 0.92 msec, offset -14.8808 msec, dispersion 0.15 precision 2**20, version 4 org time CFD63B35.5F8F925C (23:52:53.373 CEST Wed Jun 30 2010) rec time CFD63B35.637A41FB (23:52:53.388 CEST Wed Jun 30 2010) xmt time CFD63B35.633885DA (23:52:53.387 CEST Wed Jun 30 2010) filtdelay = 0.980.951.581.410.990.930.920.94 filtoffset = -14.80 -14.81 -14.96 -15.05 -14.87 -14.88 -14.88 -14.88 filterror = 0.000.030.060.090.120.150.180.21 minpoll = 6, maxpoll = 10 That's from shortly after the initial burst ended. Status: Clock is synchronized, stratum 3, reference is 10.83.247.20 nominal freq is 250. Hz, actual freq is 250.0256 Hz, precision is 2**24 reference time is CFD63B2B.63AE2585 (23:52:43.389 CEST Wed Jun 30 2010) clock offset is -14.8808 msec, root delay is 2.63 msec root dispersion is 978.06 msec, peer dispersion is 0.15 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000102725 s/s system poll interval is 64, last update was 13 sec ago. I don't see how going back to 24T would change it as it has v4 there too...unless there was something later that made it even worse. I tried to harass the 24T device as much as I could: delete NTP config, reset drift file (ntp clear drift), set the clock to somewhere in 1993 and reinsert config. It recovers (~10 usec offset) within several minutes. I'd like it to run 15.0M, so the downgrade is just to see if it makes any difference. -- Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] mpls over native ipv6?
On Wednesday 30 June 2010 05:18:12 am Christian MacNevin wrote: I'm prodding around at a couple of different IOSes and googling, and it seems as though 6PE is well documented, but while I can see white papers about MPLS over native ipv6, I'm not exactly sure how well supported it really is. Anyone got the info on this? Supported trains for the 7200 perhaps? Currently, IPv6 control plane support for LDP is not implemented by any known vendor, despite the fact that 'draft-manral-mpls-ldp-ipv6-03' has been in existence for quite some time now. I've been chasing both Cisco and Juniper about it for years, but it doesn't appear to be an interesting area of focus for either of them. No idea what other vendors are thinking. I don't see it becoming available for at least another 1.5 - 2.5 years from now, but I do hope to be proven wrong, sooner rather than later. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] smaller PI
On Thursday 01 July 2010 01:20:59 am Jan Gregor wrote: I guess I have just opened jac-in-the-box here :). IMHO if Tier1 accept these prefixes it is ok. Hands up anyone who does not have 0.0.0.0/0 in their network pointing to the upstream :). hand_up We do, however, originate default to some customers that ask for both full feed + default. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] smaller PI
On Thursday 01 July 2010 12:49:45 am Clement Cavadore wrote: - Large transit providers (T1) should accept the microalloc from customers peers. - Non-T1 transit providers should setup a default route to T1 upstreams. What is a Tier-1 network? What is a Tier-1 network in Russia vs. one in Namibia vs. another in Canada? This tier classification is not necessarily feasible given the size of the connected network. Well, not nowadays anyway. Mark. signature.asc Description: This is a digitally signed message part. ___ 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] smaller PI
On Thursday 01 July 2010 12:20:09 am Seth Mattinen wrote: Many providers will send prefixes longer than a /24 to their customers but not out to their peers. I could announce a /25 to Sprint, for example, but only other Sprint customers will see it. It is also not uncommon to permit /32 (v4) prefixes outward toward providers (inbound from customers) if they provide you with community-based blackholing capabilities. You just have to hope they have great internal routing policies that such prefixes don't end up beyond their domain. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ 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] NTP synchronization problems C2801
Gotcha. We may have to wait for M3 rebuild and try that one. Rodney On 6/30/10 6:10 PM, Peter Rathlev wrote: On Wed, 2010-06-30 at 17:43 -0400, Rodney Dunn wrote: Can you try the iburst option to see if it changes it? I tried adding iburst, and though it behaves as expected by sending 8 rapid (~4 secs apart it seemed) after initialization I still end up relatively unsynchronized: 10.83.247.20 configured, authenticated, our_master, sane, valid, stratum 2 ref ID 10.85.8.130 , time CFD638BF.C765F6DB (23:42:23.778 CEST Wed Jun 30 2010) our mode client, peer mode server, our poll intvl 64, peer poll intvl 64 root delay 1.70 msec, root disp 25.60, reach 1, sync dist 30.50 delay 0.92 msec, offset -14.8808 msec, dispersion 0.15 precision 2**20, version 4 org time CFD63B35.5F8F925C (23:52:53.373 CEST Wed Jun 30 2010) rec time CFD63B35.637A41FB (23:52:53.388 CEST Wed Jun 30 2010) xmt time CFD63B35.633885DA (23:52:53.387 CEST Wed Jun 30 2010) filtdelay = 0.980.951.581.410.990.930.920.94 filtoffset = -14.80 -14.81 -14.96 -15.05 -14.87 -14.88 -14.88 -14.88 filterror = 0.000.030.060.090.120.150.180.21 minpoll = 6, maxpoll = 10 That's from shortly after the initial burst ended. Status: Clock is synchronized, stratum 3, reference is 10.83.247.20 nominal freq is 250. Hz, actual freq is 250.0256 Hz, precision is 2**24 reference time is CFD63B2B.63AE2585 (23:52:43.389 CEST Wed Jun 30 2010) clock offset is -14.8808 msec, root delay is 2.63 msec root dispersion is 978.06 msec, peer dispersion is 0.15 msec loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000102725 s/s system poll interval is 64, last update was 13 sec ago. I don't see how going back to 24T would change it as it has v4 there too...unless there was something later that made it even worse. I tried to harass the 24T device as much as I could: delete NTP config, reset drift file (ntp clear drift), set the clock to somewhere in 1993 and reinsert config. It recovers (~10 usec offset) within several minutes. I'd like it to run 15.0M, so the downgrade is just to see if it makes any difference. ___ 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/
