Re: [c-nsp] IS-IS as PE-CE protocol
Robert Raszuk wrote: > Hi Victor, > > ISIS has analogy to OSPF down bit integrated if this was your question. Hopefully it is. > But > do check with your implementation to make sure if it supports ISIS leaking. > > PE-CE ISIS is inheriting loop prevention which was defined for ISIS route > leaking between levels in RFC2966 Looks like it. Thank you for the hint! > > " This document redefines this high-order bit in the default metric > >field in TLVs 128 and 130 to be the up/down bit." What would be the Cisco command to enable/disable this feature in IS-IS ? That would be the easiest way to check if the implementation supports it. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ 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] IS-IS as PE-CE protocol
Robert Raszuk wrote: > > > > > > A protocol designed to speak between 2 different autonomous systems. > > > > > > If that is not an option, not using a routing protocol is also a good > > > idea, i.e., static routing. > > > > Well, the Internet is full of examples and recommendations of an IGP > > (most often OSPF) being used between PE and CE, so it must be common > > practice. In fact, OSPF even has special enhancements for this very > > purpose. > > > > > > > > You're not my immediate competitor, so I'll advise you not to run an IGP > > > with a customer. > > > > Again, it seems a common practice to run an IGP with a customer to > > import the customer's routes into the provider's MPLS network. > Yes - the examples are there on the net for most BGP resistant customers > and non managed CPEs ... But as others already said all biggest SPs which > are still offering L3VPNs are only doing BGP and static. Still, the answer to my initial and direct question about IS-IS is... "yes" or "no"? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ 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] IS-IS as PE-CE protocol
Mark Tinka wrote: > > > Because the customer network is all IS-IS ? > > What would be "not shooting myself in the foot" in this case? > > A protocol designed to speak between 2 different autonomous systems. > > If that is not an option, not using a routing protocol is also a good > idea, i.e., static routing. Well, the Internet is full of examples and recommendations of an IGP (most often OSPF) being used between PE and CE, so it must be common practice. In fact, OSPF even has special enhancements for this very purpose. > > You're not my immediate competitor, so I'll advise you not to run an IGP > with a customer. Again, it seems a common practice to run an IGP with a customer to import the customer's routes into the provider's MPLS network. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ 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] IS-IS as PE-CE protocol
Nick Cutting wrote: > But I think the discussion is not the CE-PE IGP relationship that gets > put into a L3VPN, then tunneled via MPLS, but connecting the CE to his > internal IS-IS No, it is not. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ 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] IS-IS as PE-CE protocol
adamv0...@netconsultings.com wrote: > > > > OSPF as a PE-CE protocol has some useful features: the "DN bit" for loop > > prevention and sham links for route optimization. > > > > Does IS-IS have similar features? > > > It does if the PE end is L2 and CE end is L1, Sorry if I misunderstand, but all neighbors I see from the PEs are level L2. I don't know if the customer has L1 routers anywhere inside their network, maybe none at all. > but for the love of god why > would you want to shoot yourself in the foot? Because the customer network is all IS-IS ? What would be "not shooting myself in the foot" in this case? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ 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] IS-IS as PE-CE protocol
Dear Colleagues, OSPF as a PE-CE protocol has some useful features: the "DN bit" for loop prevention and sham links for route optimization. Does IS-IS have similar features? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/ ___ 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] One PE router, one customer, several sites
Christoffer Hansen wrote: > > We default to placing all logical circuits (mentioned as NET below) > of the same, into respective VRFs together. Not using unneeded > import/export statement. > Say service: > - NET customer-x-internal goes into VRF mpls-299, > - NET customer-x-wifi goes into VRF mpls-300, > - NET customer-x-guest goes into VRF mpls-301, > - NET customer-x-administration goes into VRF mpls-302, > And so forth. > Christoffer, If a customer has several separate sites each with Wifi, for example, will all these Wifi NETs go into the same VRF? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ 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] One PE router, one customer, several sites
Dear Colleagues, If a customer's several sites are connected to the same PE router, but to different interfaces, which is the recommended practice, assuming that all these sites must be reachable from one another: 1. Place all the interfaces into the same VRF. 2. Place each site into a separate VRF and set up route import/export between the VRFs. Thanks in advance for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859 ___ 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] Output Drops Due to QoS and threshold size
Saku Ytti wrote:
> On 6 April 2016 at 20:09, Victor Sudakov wrote:
>
> > Why is it *not* the default configuration?
>
> I don't know why the defaults are so broken, small cats are worse with
> mls qos enabled than without. And the common wisdom is if you have
> microbursts MLS QoS will only make it worse, while counter-intuitively
> even with single queue with mls-qos you get more buffers than without
> it.
Still I don't understand the idea of configuring a threshold >100%.
If for example IOS assigns 200 buffers to a port which are equally
distributed between 4 queues ("buffers 25 25 25 25"), whis means each
queue gets 50 buffers. If Thres1 in Q1 is 100%, it means 50 buffers.
If Thres1 in Q1 is set to 1000%, this would mean 500 buffers. Where
are the 500-200=300 additional buffers borrowed? From the common pool?
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
sip:suda...@sibptus.tomsk.ru
___
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] Output Drops Due to QoS and threshold size
Saku Ytti wrote: > > > My question is, what's the tradeoff? Why is the default threshold size > > the mere 100 and not 3100? What will happen if I make it 3100 on all > > queues in all the switches and forget about drops forever? Is it > > dangerous? > > I'd recommend reading this through: > https://supportforums.cisco.com/document/31581/egress-qos Thank you for the link. It has taken me several days to digest the somewhat lengthy document (little by little), and it contains some really useful and helpful information. However, all the solutions offered there (the "Quick and Easy Egress Buffer Optimizing Solution" and the more elaborate solutions with different classes of traffic being mapped to different queues and thresholds) are ALL based on the same principle: increasing the relevant thresholds to 1000% and more. My question still holds: why are the default thresholds so low? This must mean something? What will happen if I make them 3000 or 2000 on all queues in all the interfaces (or the uplink interfaces) and forget about drops forever? What do I lose or risk? Let me quote "3.1 Quick and Easy Egress Buffer Optimizing Solution" This is for those seeking a minor tweak to fix a problem with the occasional egress packet drop. The quick answer is to increase the drop thresholds used by WTD. Switch(config)#mls qos queue-set output 1 threshold 1 1000 1000 50 1000 Switch(config)#mls qos queue-set output 1 threshold 2 1000 1000 50 1000 Switch(config)#mls qos queue-set output 1 threshold 3 1000 1000 50 1000 Switch(config)#mls qos queue-set output 1 threshold 4 1000 1000 50 1000 Why is it *not* the default configuration? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Output Drops Due to QoS and threshold size
Dear Colleagues, I am now struggling with output drops on a 3560X. There is a good document at http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/116089-technote-switches-output-drops-qos-00.html The interface is not congested so it recommends increasing the buffer and threshold values for the queue that drops packets: In this example, queue-set 2 and queue 1 thresholds are changed. Both threshold 1 and threshold 2 are mapped to 3100 so that they can pull buffer from the reserved pool if required. Switch(config)#mls qos queue-set output 2 threshold 1 3100 3100 100 3200 My question is, what's the tradeoff? Why is the default threshold size the mere 100 and not 3100? What will happen if I make it 3100 on all queues in all the switches and forget about drops forever? Is it dangerous? Thanks a lot for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 and links with limited MTU size
Mark Tinka wrote: > > > > > > If you are using MPLS routers that perform forwarding in SW you can test in > > the lab if they would be able to handle the fragmentation so during the > > failure of primary link they would have to fragment. > > Otherwise the fragmentation would have to be done on CE routers which is > > something that some customers might not be happy about. > > MPLS does not like fragmentation. > > IP is happy with fragmentation. So if I find a way to fragment a customer's packet before it enters the MPLS network, I should be fine. The question is, I don't want to fragment the customers' packets all the time. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 and links with limited MTU size
Adam Vitkovsky wrote: > > There is an IP MPLS network with MTU=1600 on all routers' interfaces. > > There are plans to add some backup Ethernet links whose maximum frame > > size cannot exceed 1500 (hardware limit). > > > > If you are using MPLS routers that perform forwarding in SW you can > test in the lab if they would be able to handle the fragmentation so > during the failure of primary link they would have to fragment. You cannot fragment an MPLS packet, can you? I don't see anything in the MPLS header that could help reassemble it after fragmentation. > Otherwise the fragmentation would have to be done on CE routers > which is something that some customers might not be happy about. There are even no CE routers per se in the network in question. Customers are attached to interfaces on the PE routers (i.e. even if a customer has some routers we don't have control over them). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 and links with limited MTU size
Nick Hilliard wrote: > Victor Sudakov wrote: > > Is there any way those links can be put to any good use in the MPLS > > network? > > no. They're basically useless for an mpls provider network. I was thinking perhaps about some tunneling technology, like maybe MPLS over GRE over those links? I'm sure I'm not the first to encounter such a situation. Or a decisive "no"? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
[c-nsp] MPLS and links with limited MTU size
Dear Colleagues, There is an IP MPLS network with MTU=1600 on all routers' interfaces. There are plans to add some backup Ethernet links whose maximum frame size cannot exceed 1500 (hardware limit). Is there any way those links can be put to any good use in the MPLS network? Thanks in advance for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Advanced use of mrtg
Mark Tinka wrote: > > > > The process will require 259 MiB more space. > > 47 MiB to be downloaded. > > # > > So what's the problem? You can't find 259MB of space, or don't have > enough bandwidth to download the 47MB? > > You'll probably need more space than that to hold all your RRD files as > they grow, That reminds me :-) mrtg databases are compact files in plain text format which is nice too. > so not sure what the issue is if the installation is being > automated for you. Never mind, I am not here to start a flame. Thank you and Mike for recommending Cacti, I can easily find a jail or a dedicated virtual host for it, with all its dependencies, if it's worth while. It's just my old school misgivings about the dependency hell. Am I getting old-fashioned? If you already run Gnome or something like this on your Unix servers, then you of course don't care if a score of extra packages are automatically installed for you (which is the case with my FreeBSD desktop, but still not with the servers). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Advanced use of mrtg
Mark Tinka wrote: > > > Cacti has so many dependencies including PHP, MySQL, cairo, pango, > > some X libraries and what not, I really feel quite reluctant to > > install it. mrtg is tiny compared to that. > > We run Cacti on FreeBSD. > > FreeBSD takes care of all dependencies required by Cacti. Been running > it for years, can't complain. > > Of course, if you're installing things by hand, Cacti can be unwieldy. No, of course from the ports/packages, but the amount of required cr*p is amazing. And this is even after I have disabled some outrageous dependencies (like OpenGL) in my poudriere: # pkg install -n cacti Updating sibptus repository catalogue... sibptus repository is up-to-date. All repositories are up-to-date. The following 41 package(s) will be affected (of 0 checked): New packages to be INSTALLED: cacti: 0.8.8f_1 php5-sockets: 5.4.45 php5: 5.4.45 libxml2: 2.9.2_3 php5-mysql: 5.4.45 mysql56-client: 5.6.26 libedit: 3.1.20150325_1 php5-session: 5.4.45 php5-xml: 5.4.45 rrdtool: 1.4.8_9 pango: 1.36.8_2 encodings: 1.0.4_3,1 font-util: 1.3.1 fontconfig: 2.11.1,1 freetype2: 2.6_1 xorg-fonts-truetype: 7.7_1 font-misc-meltho: 1.0.3_3 mkfontdir: 1.0.7 mkfontscale: 1.1.2 xproto: 7.0.28 libfontenc: 1.1.3 font-bh-ttf: 1.0.3_3 font-misc-ethiopic: 1.0.3_3 dejavu: 2.35 harfbuzz: 1.0.6 cairo: 1.14.2,2 png: 1.6.18 pixman: 0.32.8 xcb-util-renderutil: 0.3.9_1 xcb-util: 0.4.0_1,1 libXdmcp: 1.1.2 libxcb: 1.11.1 libpthread-stubs: 0.3_6 libXau: 1.0.8_3 glib: 2.44.1_2 gettext-runtime: 0.19.6 perl5: 5.20.3_8 icu: 55.1 graphite2: 1.3.3 php5-snmp: 5.4.45 net-snmp: 5.7.3_11 The process will require 259 MiB more space. 47 MiB to be downloaded. # -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Advanced use of mrtg
Mike - st257 wrote: > > From what I've seen you'll find a more active community surrounding Cacti. > MRTG has its niche in interface statistic graphing, I'll give it that. Cacti has so many dependencies including PHP, MySQL, cairo, pango, some X libraries and what not, I really feel quite reluctant to install it. mrtg is tiny compared to that. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Advanced use of mrtg
Mike - st257 wrote: > > > > Does anybody have an --if-template for mrtg's cfgmaker to monitor > > interface discards and errors instead of traffic counters? > > > > Could you please share it? Thanks a lot in advance. > > > > Half of what you want (errors). > http://mrtg.gvolk.com/template/interface-errors.template Mike, I bet you have googled it up :-) I have also stumbled upon it while googling for an answer to my question. The problem is it's over 12 years old and I did not want to be the first to try it out. It would be nice to obtain such a template from someone who has used it him/herself. But thank you anyway, you have confirmed that it's perhaps the only available example and nobody cares to keep it up to date. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Advanced use of mrtg
Colleagues, Does anybody have an --if-template for mrtg's cfgmaker to monitor interface discards and errors instead of traffic counters? Could you please share it? Thanks a lot in advance. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Many "Total output drops", no congestion
Luke Flemington wrote: > > I have a 600Mb tcpdump of mirrored traffic from that port, is > > there a way to identify microbursts in Wireshark? > > Yes, do a search for something like ???microburst wireshark??? and you???ll > get a few results. > > http://timraphael.com/2015/02/13/investigating-micro-bursting/ > http://notalwaysthenetwork.com/2014/01/06/microburst-detection-with-wireshark/ Thank you, Luke, very useful. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Many "Total output drops", no congestion
CiscoNSP List wrote: > > Micro burstssnmp polling not granular/frequent enough to show these. Do you mean to say there are microbursts exceeding 100 Mbit/s there ? I have a 600Mb tcpdump of mirrored traffic from that port, is there a way to identify microbursts in Wireshark? I would be really interested to know what is causing them. In the Wireshark analysis I have done so far, I see mostly steady WSUS HTTP traffic in the dump. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Many "Total output drops", no congestion
Dear Colleagues, There is a huge number of "Total output drops" on one of the interfaces on a C3560X-24P with mls qos enabled. The egress traffic is not more than 40-50 Mbits/s according to mrtg (the interface being in Full-duplex, 100Mb/s mode). Only the most loaded of the 4 egress queues was dropping packets. I have been able to eliminate the output drops by following the recommendations in http://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/116089-technote-switches-output-drops-qos-00.html and namely by configuring mls qos queue-set output 1 threshold 2 3100 3100 100 3200 My question is: how is it possible that there were so many drops (hundreds per second) while the interface was so far from being congested. My understanding so far has been that there can be no drops before the congestion is reached. The interface configuration is simple: interface GigabitEthernet0/2 description V-Node S Port 4 BPTOiK switchport trunk encapsulation isl switchport mode trunk power inline never srr-queue bandwidth shape 0 0 0 0 mls qos trust cos ! Thank you very much in advance for shedding light on this. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: Multicast peer 224.0.1.1 does not exist
Juergen Marenda wrote: > > It's c7200p-advipservicesk9-mz.124-24.T8.bin > > Have you checked that the clock of your NPE-G2/7201 is in sync, It was the first thing I did. > > # sh ntp status > # sh ntp asso > > without having an accurate time, it will not send any ntp time-info -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: Multicast peer 224.0.1.1 does not exist
Gert Doering wrote: > > A 7206VXR (NPE-G2) is not sending ntp broadcasts nor multicasts, and I > > even cannot recofigure ntp settings on an interface (see below). > > Which IOS version is this? We've seen quite a bit of NTP misbehaviour > on a NPE-G1 with 15.1(4)M9 - not being able to sync at all, not being > able to provide time to others, etc. - and on 1900s with 15.2(4)M6a > (NTP ACLs not working at all) - so the All And Improved New NTP Code > seems to have quite a number of warts left... It's c7200p-advipservicesk9-mz.124-24.T8.bin -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: Multicast peer 224.0.1.1 does not exist
Yes, it is (sparse-dense-mode). But how is PIM related to broadcast NTP? Jared Mauch wrote: > Is pim enabled on the interface? > > > On Aug 21, 2015, at 3:39 AM, Victor Sudakov wrote: > > > > Colleagues, > > > > A 7206VXR (NPE-G2) is not sending ntp broadcasts nor multicasts, and I > > even cannot recofigure ntp settings on an interface (see below). > > > > Any idea what the problem could be? > > > > "debug ntp packet|events" does not show anything of interest. tcpdump > > shows that the router is simply not sending any NTP packets out > > GigabitEthernet0/2. Google does not even know the phrase "Cannot > > reconfigure the multicast peer", nor does cisco.com/search > > > > > > gw2(config-if)#do sh run int GigabitEthernet0/2 > > Building configuration... > > > > Current configuration : 428 bytes > > ! > > interface GigabitEthernet0/2 > > [dd] > > ntp broadcast key 2 destination 10.14.141.255 > > ntp broadcast key 2 > > ntp multicast key 2 ttl 1 > > end > > > > gw2(config-if)#no ntp multicast key 2 ttl 1 > > %NTP: Multicast peer 224.0.1.1 does not exist > > gw2(config-if)#no ntp multicast > > %NTP: Multicast peer 224.0.1.1 does not exist > > gw2(config-if)#ntp multicast key 2 ttl 6 > > %NTP: Cannot reconfigure the multicast peer. > > gw2(config-if)#ntp multicast ? > > A.B.C.D Multicast group IP address > > X:X:X:X::X Multicast group IPv6 address > > client Listen to NTP multicasts > > key Configure multicast authentication key > > ttl TTL of the multicast packet > > version Configure NTP version > > > > > > gw2(config-if)#ntp multicast 224.0.1.1 ? > > key Configure multicast authentication key > > ttl TTL of the multicast packet > > version Configure NTP version > > > > > > gw2(config-if)#ntp multicast 224.0.1.1 ttl 6 > > %NTP: Cannot reconfigure the multicast peer. > > gw2(config-if)# > > > > -- > > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > > sip:suda...@sibptus.tomsk.ru > > ___ > > 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/ -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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: Multicast peer 224.0.1.1 does not exist
I have found something interesting though, in "debug NTP core". NTP Core(INFO): transmit: 224.0.1.1 key 2 not found NTP Core(INFO): transmit: 10.14.141.255 key 2 not found gw2#sh run | i ntp au ntp authentication-key 2 md5 1525190916270A2F70 7 ntp authentication-key 3 md5 10791B1C171A330054 7 gw2# gw2(config)#interface GigabitEthernet0/2 gw2(config-if)#ntp broadcast key 3 %NTP: Cannot reconfigure the broadcast peer. gw2(config-if)# What gives? And what's this "Cannot reconfigure the peer" stuff? Thanks a lot for any input. Victor Sudakov wrote: > Colleagues, > > A 7206VXR (NPE-G2) is not sending ntp broadcasts nor multicasts, and I > even cannot recofigure ntp settings on an interface (see below). > > Any idea what the problem could be? > > "debug ntp packet|events" does not show anything of interest. tcpdump > shows that the router is simply not sending any NTP packets out > GigabitEthernet0/2. Google does not even know the phrase "Cannot > reconfigure the multicast peer", nor does cisco.com/search > > > gw2(config-if)#do sh run int GigabitEthernet0/2 > Building configuration... > > Current configuration : 428 bytes > ! > interface GigabitEthernet0/2 > [dd] > ntp broadcast key 2 destination 10.14.141.255 > ntp broadcast key 2 > ntp multicast key 2 ttl 1 > end > > gw2(config-if)#no ntp multicast key 2 ttl 1 > %NTP: Multicast peer 224.0.1.1 does not exist > gw2(config-if)#no ntp multicast > %NTP: Multicast peer 224.0.1.1 does not exist > gw2(config-if)#ntp multicast key 2 ttl 6 > %NTP: Cannot reconfigure the multicast peer. > gw2(config-if)#ntp multicast ? > A.B.C.D Multicast group IP address > X:X:X:X::X Multicast group IPv6 address > client Listen to NTP multicasts > key Configure multicast authentication key > ttl TTL of the multicast packet > version Configure NTP version > > > gw2(config-if)#ntp multicast 224.0.1.1 ? > keyConfigure multicast authentication key > ttlTTL of the multicast packet > version Configure NTP version > > > gw2(config-if)#ntp multicast 224.0.1.1 ttl 6 > %NTP: Cannot reconfigure the multicast peer. > gw2(config-if)# > > -- > Victor Sudakov, VAS4-RIPE, VAS47-RIPN > sip:suda...@sibptus.tomsk.ru > _______ > 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/ -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] %NTP: Multicast peer 224.0.1.1 does not exist
Colleagues, A 7206VXR (NPE-G2) is not sending ntp broadcasts nor multicasts, and I even cannot recofigure ntp settings on an interface (see below). Any idea what the problem could be? "debug ntp packet|events" does not show anything of interest. tcpdump shows that the router is simply not sending any NTP packets out GigabitEthernet0/2. Google does not even know the phrase "Cannot reconfigure the multicast peer", nor does cisco.com/search gw2(config-if)#do sh run int GigabitEthernet0/2 Building configuration... Current configuration : 428 bytes ! interface GigabitEthernet0/2 [dd] ntp broadcast key 2 destination 10.14.141.255 ntp broadcast key 2 ntp multicast key 2 ttl 1 end gw2(config-if)#no ntp multicast key 2 ttl 1 %NTP: Multicast peer 224.0.1.1 does not exist gw2(config-if)#no ntp multicast %NTP: Multicast peer 224.0.1.1 does not exist gw2(config-if)#ntp multicast key 2 ttl 6 %NTP: Cannot reconfigure the multicast peer. gw2(config-if)#ntp multicast ? A.B.C.D Multicast group IP address X:X:X:X::X Multicast group IPv6 address client Listen to NTP multicasts key Configure multicast authentication key ttl TTL of the multicast packet version Configure NTP version gw2(config-if)#ntp multicast 224.0.1.1 ? key Configure multicast authentication key ttl TTL of the multicast packet version Configure NTP version gw2(config-if)#ntp multicast 224.0.1.1 ttl 6 %NTP: Cannot reconfigure the multicast peer. gw2(config-if)# -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How can I increase Ethernet MTU?
Victor Sudakov wrote: > > There is one more point. Some switches are connected via > communications equipment (e.g. iPASOLINK radio relay) rather than > directly. Those switches' GigabitEthernet ports are running in the > 100Mb/s mode because the iPASOLINK equipment has FastEthernet ports > with maximum frame size = 2000. > > Does the "system mtu jumbo" affect GigabitEthernet ports in 100Mb/s > mode? Is anything larger than 1500 supported in 100Mb/s mode on Cisco? I have created a small lab http://i.imgur.com/D13GBeL.png with the switches I had at hand. The result is positive. Two GigabitEthernet ports, even if working in 100Mb/s mode and connected via equipment with FastEthernet ports only, do forward jumbo frames (1600 bytes in my lab). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How can I increase Ethernet MTU?
Lukas Tribus wrote: > > > > Soon we will be enabling MPLS on some routers connected to this > > network, so the switches will have to handle frames with the MTU > > larger than the default 1500 bytes. > > > > How do I configure the switches to pass frames with MTU=1600, if > > possible, without disrupting the service? > > > > I will be grateful for a link to some good howto. > > http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_53_se/configuration/guide/3750xscg/swtunnel.html#wp1042950 > There is one more point. Some switches are connected via communications equipment (e.g. iPASOLINK radio relay) rather than directly. Those switches' GigabitEthernet ports are running in the 100Mb/s mode because the iPASOLINK equipment has FastEthernet ports with maximum frame size = 2000. Does the "system mtu jumbo" affect GigabitEthernet ports in 100Mb/s mode? Is anything larger than 1500 supported in 100Mb/s mode on Cisco? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How can I increase Ethernet MTU?
Nick Hilliard wrote: > > What if I set "system mtu jumbo 9198" on a random switch in the > > middle of the network, would it disrupt connectivity (STP or OSPF in > > the management VLAN or anything else)? > > "system mtu jumbo" is only activated on a switch reboot. You can safely > issue the command on a switch, and it won't have any affect on running > traffic. But after a reboot with a new "system mtu jumbo", what adverse effects can I expect if there is a jumbo MTU switch among switches with the default MTU? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How can I increase Ethernet MTU?
Darren O'Connor wrote: > > >> Switch(config)#system mtu jumbo 9198 > > > > > > Should I do that on all switches in the network simultaneously ? > > > > > > What if I set "system mtu jumbo 9198" on a random switch in the > > > middle of the network, would it disrupt connectivity (STP or OSPF in > > > the management VLAN or anything else)? > > > > OSPF will be affected by an MTU mismatch, so if you have OSPF setup on > > everything, expect a downtime until all switches are done. > Or just set your routing MTU to 1500 while your ethernet MTU goes up to 9k+ I already have "system mtu routing 1500" configured, I guess it's the default, I hope this will not change if I change the "system mtu jumbo"? Guess it's time for a lab. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] How can I increase Ethernet MTU?
Nick Hilliard wrote: > On 24/01/2015 11:47, Lukas Tribus wrote: > > Don't think it will work without reload though ... > > Yes, it needs a reboot on the C3560/3750X platform. The command is: > > Switch(config)#system mtu jumbo 9198 Should I do that on all switches in the network simultaneously ? What if I set "system mtu jumbo 9198" on a random switch in the middle of the network, would it disrupt connectivity (STP or OSPF in the management VLAN or anything else)? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] How can I increase Ethernet MTU?
Colleagues, I have a network of about twenty C3560X switches switching IP-only traffic. Soon we will be enabling MPLS on some routers connected to this network, so the switches will have to handle frames with the MTU larger than the default 1500 bytes. How do I configure the switches to pass frames with MTU=1600, if possible, without disrupting the service? I will be grateful for a link to some good howto. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Daniel Roesen wrote: > On Sat, Nov 29, 2014 at 09:41:45PM +0600, Victor Sudakov wrote: > > We have set up port monitor sessions in various parts of the network > > and have found out the following. One of the C3560X-24P in the chain > > of identical switches does not let through packets with > > src=10.65.127.246&dst=224.0.0.5. Neither when such packets transit the > > switch nor when it's configured on one of it's own Vlan interfaces. > > > > Other switches in the chain are identical from the hardware/software > > point of view, and configured almost identically, but do not suffer > > from the problem. > > Check for enabled IGMP snooping on this switch. Try disabling snooping. We have already tried that, with no effect. Besides, IGMP snooping should not affect packets with only one unicast source address on only one switch. > Wouldn't outrule broken hardware... Some bit flip error or so. We may try to change the hardware some day, but for the present it's easier to just avoid one particular IP address. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Lukas Tribus wrote: > >> Are there any IP filters on the layer 2 side of this? Are you using CoPP > >> and > >> the IP is denied there? > > > > No. PASOLINK does not do IP filtering. > > > > It can only do some Ethernet frame filtering, like filtering out LLDP > > or STP frames, but no such filters are even configured. > > Just because its not configured or not configurable doesn't mean its not > actually doing it (it may be a bug). > > I have an Ethernet over FrameRelay Radio PTMP system that after a few > months of uptime inserts the UDP payload of customer A into the > TCP payload of customer B (customer B using this TCP session to > transfer files to a AS400 that doesn't check TCP checksums and > therefor the UDP payload of customer A makes it into the application > of customer B). The only fix here is to reload the whole system. > > The very same PTMP system sometimes drops traffic of a certain mac > address, although there are no layer 2 rules (other that different > vlans). Cool story. We have set up port monitor sessions in various parts of the network and have found out the following. One of the C3560X-24P in the chain of identical switches does not let through packets with src=10.65.127.246&dst=224.0.0.5. Neither when such packets transit the switch nor when it's configured on one of it's own Vlan interfaces. Other switches in the chain are identical from the hardware/software point of view, and configured almost identically, but do not suffer from the problem. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Lars Fenneberg wrote: > > > We are at a loss what could be blocking packets with this particular > > src addr. > > Are there any IP filters on the layer 2 side of this? Are you using CoPP and > the IP is denied there? No. PASOLINK does not do IP filtering. It can only do some Ethernet frame filtering, like filtering out LLDP or STP frames, but no such filters are even configured. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
27 09:17:39.902: OSPF: End of hello processing Nov 27 09:17:39.911: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from LOADING to FULL, Loading Done Nov 27 09:17:49.809: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:17:59.648: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:09.370: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:18.849: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:26.793: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from FULL to DOWN, Neighbor Down: Dead timer expired Nov 27 09:18:28.135: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:28.135: OSPF: Rcv hello from 10.65.127.246 area 0 from Vlan333 10.65.127.246 Nov 27 09:18:28.135: OSPF: Send immediate hello to nbr 10.65.127.246, src address 10.65.127.246, on Vlan333 Nov 27 09:18:28.135: OSPF: Send hello to 10.65.127.246 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:28.135: OSPF: End of hello processing Nov 27 09:18:28.143: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from LOADING to FULL, Loading Done Nov 27 09:18:37.538: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:46.782: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:18:56.554: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:05.882: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:15.470: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:17.273: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from FULL to DOWN, Neighbor Down: Dead timer expired Nov 27 09:19:25.158: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:25.158: OSPF: Rcv hello from 10.65.127.246 area 0 from Vlan333 10.65.127.246 Nov 27 09:19:25.158: OSPF: Send immediate hello to nbr 10.65.127.246, src address 10.65.127.246, on Vlan333 Nov 27 09:19:25.158: OSPF: Send hello to 10.65.127.246 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:25.158: OSPF: End of hello processing Nov 27 09:19:25.183: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from LOADING to FULL, Loading Done Nov 27 09:19:34.209: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:43.612: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:19:53.435: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:03.232: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:10.497: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from FULL to DOWN, Neighbor Down: Dead timer expired Nov 27 09:20:12.669: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:12.678: OSPF: Rcv hello from 10.65.127.246 area 0 from Vlan333 10.65.127.246 Nov 27 09:20:12.678: OSPF: Send immediate hello to nbr 10.65.127.246, src address 10.65.127.246, on Vlan333 Nov 27 09:20:12.678: OSPF: Send hello to 10.65.127.246 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:12.678: OSPF: End of hello processing Nov 27 09:20:12.686: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from LOADING to FULL, Loading Done Nov 27 09:20:21.703: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:31.333: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:40.862: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:49.989: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:20:59.459: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:21:00.986: %OSPF-5-ADJCHG: Process 20, Nbr 10.65.127.246 on Vlan333 from FULL to DOWN, Neighbor Down: Dead timer expired Nov 27 09:21:08.745: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:21:08.745: OSPF: Rcv hello from 10.65.127.246 area 0 from Vlan333 10.65.127.246 Nov 27 09:21:08.745: OSPF: Send immediate hello to nbr 10.65.127.246, src address 10.65.127.246, on Vlan333 Nov 27 09:21:08.745: OSPF: Send hello to 10.65.127.246 area 0 on Vlan333 from 10.65.127.243 Nov 27 09:21:08.745: OSPF: End of hello processing -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Karsten Thomann wrote: > As no one asked yet, is it possible to get ospf related debug from the > not working router and the DR router of the subnet? Good point, thank you. After looking at debug OSPF hello, we have found out that Hello packets with src=10.65.127.246 are being sent by the device Nov 27 05:29:35.923: OSPF: Send hello to 224.0.0.5 area 0 on Vlan333 from 10.65.127.246 but they are not Rcv-ed by other devices on the network segment. Hello packets with any other src IP address, e.g. 10.65.127.243, are being received as expected. We are at a loss what could be blocking packets with this particular src addr. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Davis, Philip wrote: > When you made your testbed did you have the same problem if the > subnet mask was different? The problem persists regardless of the subnet mask: sw-parabel#sh ip ospf 20 neighbor Neighbor ID Pri State Dead Time Address Interface 10.65.127.241 1 FULL/DR 958 msec10.65.127.241 Vlan333 10.65.127.242 1 FULL/BDR916 msec10.65.127.242 Vlan333 10.65.127.243 1 INIT/DROTHER975 msec10.65.127.243 Vlan333 10.65.127.244 1 INIT/DROTHER899 msec10.65.127.244 Vlan333 10.65.127.245 1 INIT/DROTHER706 msec10.65.127.245 Vlan333 10.65.127.247 1 INIT/DROTHER748 msec10.65.127.247 Vlan333 sw-parabel#sh ip ospf interface vlan 333 Vlan333 is up, line protocol is up Internet Address 10.65.127.246/24, Area 0 Process ID 20, Router ID 10.65.127.246, Network Type BROADCAST, Cost: 1 Topology-MTIDCostDisabledShutdown Topology Name 0 1 no noBase Transmit Delay is 1 sec, State DROTHER, Priority 1 Designated Router (ID) 10.65.127.241, Interface address 10.65.127.241 Backup Designated router (ID) 10.65.127.242, Interface address 10.65.127.242 Timer intervals configured, Hello 333 msec, Dead 1, Wait 1, Retransmit 5 oob-resync timeout 40 Hello due in 170 msec Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 7 Last flood scan time is 0 msec, maximum is 8 msec Neighbor Count is 6, Adjacent neighbor count is 2 Adjacent with neighbor 10.65.127.241 (Designated Router) Adjacent with neighbor 10.65.127.242 (Backup Designated Router) Suppress hello for 0 neighbor(s) sw-parabel#sh arp vrf OSPF Protocol Address Age (min) Hardware Addr Type Interface Internet 10.65.127.241 4 6073.5cac.1cc5 ARPA Vlan333 Internet 10.65.127.242 4 4403.a7cb.2644 ARPA Vlan333 Internet 10.65.127.243 4 4403.a7d1.7dc3 ARPA Vlan333 Internet 10.65.127.244 4 4403.a7cc.72c2 ARPA Vlan333 Internet 10.65.127.245 4 4403.a7d1.64c2 ARPA Vlan333 Internet 10.65.127.246 - e4d3.f1cc.f2c1 ARPA Vlan333 Internet 10.65.127.247 4 4403.a7cf.74c3 ARPA Vlan333 sw-rrs-nvartovsk#sh arp vrf OSPF Protocol Address Age (min) Hardware Addr Type Interface Internet 10.65.127.241 0 6073.5cac.1cc5 ARPA Vlan333 Internet 10.65.127.242 0 4403.a7cb.2644 ARPA Vlan333 Internet 10.65.127.243 0 4403.a7d1.7dc3 ARPA Vlan333 Internet 10.65.127.244 0 4403.a7cc.72c2 ARPA Vlan333 Internet 10.65.127.245 0 4403.a7d1.64c2 ARPA Vlan333 Internet 10.65.127.246 0 e4d3.f1cc.f2c1 ARPA Vlan333 Internet 10.65.127.247 - 4403.a7cf.74c3 ARPA Vlan333 sw-rrs-nvartovsk#sh ip ospf 20 neighbor Neighbor ID Pri State Dead Time Address Interface 10.65.127.241 1 FULL/DR 1000 msec10.65.127.241 Vlan333 10.65.127.242 1 FULL/BDR748 msec10.65.127.242 Vlan333 10.65.127.243 1 2WAY/DROTHER865 msec10.65.127.243 Vlan333 10.65.127.244 1 2WAY/DROTHER916 msec10.65.127.244 Vlan333 10.65.127.245 1 2WAY/DROTHER723 msec10.65.127.245 Vlan333 sw-rrs-nvartovsk#sh ip ospf interface vlan 333 Vlan333 is up, line protocol is up Internet Address 10.65.127.247/24, Area 0 Process ID 20, Router ID 10.65.127.247, Network Type BROADCAST, Cost: 1 Topology-MTIDCostDisabledShutdown Topology Name 0 1 no noBase Transmit Delay is 1 sec, State DROTHER, Priority 1 Designated Router (ID) 10.65.127.241, Interface address 10.65.127.241 Backup Designated router (ID) 10.65.127.242, Interface address 10.65.127.242 Timer intervals configured, Hello 333 msec, Dead 1, Wait 1, Retransmit 5 oob-resync timeout 40 Hello due in 22 msec Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 1 Last flood scan time is 0 msec, maximum is 8 msec Neighbor Count is 5, Adjacent neighbor count is 2 Adjacent with neighbor 10.65.127.241 (Designated Router) Adjacent with neighbor 10.65.127.242 (Backup Designated Router) Suppress hello for 0 neighbor(s) -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Harold 'Buz' Dale wrote: > If you "sh arp" do you see the right MAC address for the ip. Certainly. I can even ping it from any other device and telnet into it. > Could that address be in use on some dumb device? No, it could not. We have even recreated the problem in a separate VRF, created as a testbed specifically for the purpose. The problem is 100% reproducible. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Antonio Querubin wrote: > >> > >> Are you absolutely positively sure 10.65.127.246 still does not exist > >> somewhere else on one of the devices on that network, for example as a > >> stale router ID? > > > > I know that a duplicate router ID should cause a message like > > "%OSPF-4-DUP_RTRID, and I have not seen this message in the logs. > > > > So am I not absolutely positively sure, but I am pretty sure. > > > > And I have posted a "show ip ospf database" output in another message. > > Understood, but I have seen OSPF do weird things with router IDs in cases > where IP addresses on router interfaces have been changed/removed without > resetting the database by doing a 'clear ip ospf ...' or just rebooting > the router. We have even recreated the problem in a separate VRF, created as a testbed specifically for the purpose. The problem is 100% reproducible. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Joshua Riesenweber wrote: > Nothing is wrong with that IP address specifically, but I was wondering if it > is being chosen as the ID whether there is a conflict with another router ID, > perhaps manually set. A conflict of router IDs causes a well known message which I am not observing. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Joshua Riesenweber wrote: > Out of curiosity, is this the highest IP address on the router? On some routers there is no loopback interface, so yes, on some routers 10.65.127.246 may become the router ID. > Is it possible that this is being chosen as the OSPF router ID and causing > problems? What's wrong with 10.65.127.246 being an OSPF router ID? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Antonio Querubin wrote: > > > There are a dozen routers connected to a common 10.65.127.224/27 L2 > > backbone. All are running OSPF area 0. Any router which has the IP > > address 10.65.127.246 cannot establish OSPF adjacency with some other > > routers, showing them forever in the INIT/DROTHER or EXSTART/DROTHER > > state. > > > > When a different IP address is configured on the same router, the > > problem is solved. More over, when 10.65.127.246 is configured on ANY > > router in the segment, it experiences adjacency problems. > > > > We are currently using a workaround of never assigning 10.65.127.246 > > to any router. Is this Sauron's IP address, or is there some kind of curse > > thereon? > > Are you absolutely positively sure 10.65.127.246 still does not exist > somewhere else on one of the devices on that network, for example as a > stale router ID? I know that a duplicate router ID should cause a message like "%OSPF-4-DUP_RTRID, and I have not seen this message in the logs. So am I not absolutely positively sure, but I am pretty sure. And I have posted a "show ip ospf database" output in another message. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
10.65.155.1116780x803D 0x006228 2 172.16.146.11 172.16.146.11 406 0x8059 0x003FA2 6 Net Link States (Area 0) Link ID ADV Router Age Seq# Checksum 10.64.128.4 10.65.127.17158 0x8030 0x0009FE 10.65.127.3810.65.127.15867 0x802C 0x001502 10.65.127.133 10.65.127.10535 0x802F 0x003981 10.65.127.251 10.65.127.15350 0x8072 0x00E9C1 Type-5 AS External Link States Link ID ADV Router Age Seq# Checksum Tag 0.0.0.0 10.65.127.7 677 0x802F 0x00F237 10 10.12.0.0 10.65.127.7 677 0x8030 0x006B1E 0 10.14.128.0 10.65.127.7 677 0x8030 0x000DFC 0 10.64.0.0 10.65.127.7 677 0x8030 0x00EC6B 0 10.65.4.0 10.65.127.7 677 0x8030 0x00B1A1 0 10.65.8.0 10.65.127.7 677 0x8030 0x0071E1 0 10.65.165.0 10.65.127.7 677 0x8030 0x00CEDF 0 172.16.210.010.65.127.7 677 0x8030 0x00E926 0 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Cursed IP address
Colleagues, We have found a very interesting problem. There are a dozen routers connected to a common 10.65.127.224/27 L2 backbone. All are running OSPF area 0. Any router which has the IP address 10.65.127.246 cannot establish OSPF adjacency with some other routers, showing them forever in the INIT/DROTHER or EXSTART/DROTHER state. When a different IP address is configured on the same router, the problem is solved. More over, when 10.65.127.246 is configured on ANY router in the segment, it experiences adjacency problems. We are currently using a workaround of never assigning 10.65.127.246 to any router. Is this Sauron's IP address, or is there some kind of curse thereon? Below is a typical output sw-bptoik#sh ip ospf 12 neighbor Neighbor ID Pri State Dead Time Address Interface 10.65.127.7 130 2WAY/DROTHER984 msec10.65.127.249 Vlan22 10.65.127.9 130 FULL/DR 707 msec10.65.127.250 Vlan22 10.65.127.10 1 2WAY/DROTHER942 msec10.65.127.248 Vlan22 10.65.127.12 1 2WAY/DROTHER841 msec10.65.127.252 Vlan22 10.65.127.13 1 INIT/DROTHER942 msec10.65.127.235 Vlan22 10.65.127.14 1 INIT/DROTHER782 msec10.65.127.245 Vlan22 10.65.127.15130 INIT/DROTHER908 msec10.65.127.251 Vlan22 10.65.127.17 1 2WAY/DROTHER866 msec10.65.127.241 Vlan22 10.65.127.19 1 2WAY/DROTHER959 msec10.65.127.238 Vlan22 10.65.127.21 1 2WAY/DROTHER740 msec10.65.127.244 Vlan22 10.65.127.22 0 INIT/DROTHER766 msec10.65.127.243 Vlan22 10.65.127.23 1 2WAY/DROTHER891 msec10.65.127.230 Vlan22 10.65.127.24 1 2WAY/DROTHER682 msec10.65.127.231 Vlan22 10.65.155.11 1 2WAY/DROTHER816 msec10.65.127.253 Vlan22 172.16.146.11 1 2WAY/DROTHER858 msec10.65.127.247 Vlan22 sw-bptoik#sh ip ospf int Vlan22 Vlan22 is up, line protocol is up Internet Address 10.65.127.246/27, Area 0 Process ID 12, Router ID 10.65.127.246, Network Type BROADCAST, Cost: 1 Topology-MTIDCostDisabledShutdown Topology Name 0 1 no noBase Transmit Delay is 1 sec, State DROTHER, Priority 1 Designated Router (ID) 10.65.127.9, Interface address 10.65.127.250 Backup Designated router (ID) 10.65.127.9, Interface address 10.65.127.250 Timer intervals configured, Hello 333 msec, Dead 1, Wait 1, Retransmit 5 oob-resync timeout 40 Hello due in 264 msec Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 1/1, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 15, Adjacent neighbor count is 1 Adjacent with neighbor 10.65.127.9 (Designated Router) Suppress hello for 0 neighbor(s) -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 vtp pruning
Alex Moya wrote: > You should only have one vtp server the rest should be clients. Why? Could you kindly provide a prooflink? In VTPv3 there is a concept of primary server, what's wrong with other switches being VTP servers? > Also can > you post your pruning configurations. There were no configurations other than saying "vtp pruning" in config mode. What exactly should I post? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 vtp pruning
Ian Henderson wrote: > On 10 Nov 2014, at 4:02 pm, Victor Sudakov wrote: > > PortVlans in spanning tree forwarding state and not pruned > > Gi0/1 1,3,10,20,22,24-28,30,32,34,36,200,308 > > Gi0/2 1,3,10,20,22,24-28,30,32,34,36,200,308 > > > VTP won???t prune because you have dual uplinks. What is dual uplinks? My topology is linear. Gi0/1 goes to the South neighbor in the chain, and Gi0/2 goes to the North neighbor in the chain, like in ftp://ftp.sibptus.ru/pub/vas/Screenshot-306.png > It doesn???t know > that they both go to the core layer. Sometimes there is more than one link between two neighboring switches, STP takes care of them. Other than that, the topology is linear. I can even make it totally linear by manually disabling a couple of redundant links. > One could be a downstream > switch as far as VTP is concerned. Sometimes there is more than one link between two neighboring switches, STP takes care of them. Other than that, the topology is linear. I can even make it totally linear by manually disabling a couple of redundant links. I expect that if a vlan is being used only on one or two switches on one end of the chain, it should be pruned from the rest of the chain. But it is not happening. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 vtp pruning
Victor Sudakov wrote: > Ian Henderson wrote: > > On 10 Nov 2014, at 4:02 pm, Victor Sudakov wrote: > > > PortVlans in spanning tree forwarding state and not pruned > > > Gi0/1 1,3,10,20,22,24-28,30,32,34,36,200,308 > > > Gi0/2 1,3,10,20,22,24-28,30,32,34,36,200,308 > > > > > > VTP won???t prune because you have dual uplinks. > > What is dual uplinks? My topology is linear. Gi0/1 goes to the South > neighbor in the chain, and Gi0/2 goes to the North neighbor in the > chain, like in the attached screenshot. The attachment seems to have been stripped, you can view it here: ftp://ftp.sibptus.ru/pub/vas/Screenshot-306.png -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 vtp pruning
Ian Henderson wrote: > On 10 Nov 2014, at 4:02 pm, Victor Sudakov wrote: > > PortVlans in spanning tree forwarding state and not pruned > > Gi0/1 1,3,10,20,22,24-28,30,32,34,36,200,308 > > Gi0/2 1,3,10,20,22,24-28,30,32,34,36,200,308 > > > VTP won???t prune because you have dual uplinks. What is dual uplinks? My topology is linear. Gi0/1 goes to the South neighbor in the chain, and Gi0/2 goes to the North neighbor in the chain, like in the attached screenshot. > It doesn???t know > that they both go to the core layer. They both ARE the core layer. > One could be a downstream > switch as far as VTP is concerned. Sometimes there is more than one link between two neighboring switches, STP takes care of them. Other than that, the topology is linear. I can even make it totally linear by manually disabling a couple of redundant links. I expect that if a vlan is being used only on one or two switches on one end of the chain, it should be pruned from the rest of the chain. But it is not happening. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 vtp pruning
Colleagues, How exactly does VTP pruning function, or rather, why does it not function as I expect? There are several switches running VTPv3, each is a VTP server, one of them is primary. VTP pruning is enabled on each switch, e.g. sw-petkul#sh vtp status | i Prun VTP Pruning Mode: Enabled There are some VLANs that are only in use on one or two switches in the whole network. However, when I look at "sh int trunk" on other swithces, including edge swithces, I see that no vlans are actually pruned: PortVlans allowed and active in management domain Gi0/1 1,3,10,20,22,24-28,30,32,34,36,200,308 Gi0/2 1,3,10,20,22,24-28,30,32,34,36,200,308 PortVlans in spanning tree forwarding state and not pruned Gi0/1 1,3,10,20,22,24-28,30,32,34,36,200,308 Gi0/2 1,3,10,20,22,24-28,30,32,34,36,200,308 sw-petkul# How do i troubleshoot this situation? Any help is welcome. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Charles Sprickman wrote: > > > Scott Granados wrote: > >> This problem sounds a lot like a dissimilar grounding issue. Sounds > >> like a potential between buildings is causing problems. I don?t > >> know if this is feasible but a common ground might solve some of the > >> problems. > >> > > Our electricians say that everything is correct, that all the > > grounding circuits are interconnected and they measure their > > parameters annually. I lack the necessary qualification to call them > > liars (even if they are lying which I doubt). > > It still might be interesting next time you have a failure to put a > voltmeter between the switch chassis ground and each pin on the > ethernet cable that blew the port. If you see anything measurable > that might at least tell you if its something like a transient > lightning-induced spike or a weird grounding issue (I think). If there is something, it must be transient. I have had it measured and it's exactly zero. > > OT, but long ago I worked at an ISP where we once had a few hundred > phone lines going to modems and the lines ran up the buildings > freight elevator shaft. Each time someone had a freight elevator > delivery you could hear the sound of a bunch of modem relays > clicking as a bunch of users were disconnected. This was voltage > induced in the phone cables from whatever power cable the bundle was > lashed to. :-) Well we thought that Ethernet protective devices would mitigate such problems, and maybe they do mitigate them after all (i.e. I would get toasted switches every day and not twice a year). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Michael Loftis wrote: [dd] > >> The root cause is almost always bad grounding in one building or > >> another. In a couple cases we discovered that ants and termites had > >> colonized around the grounding rod. In another we discovered the > > > > Our electricians say that the grounding is correct, all grounding > > circuits on the site are interconnected and that they measure the > > parameters annually. I am not the person to expose them to be lying > > (if they really are), I lack such qualification. > > Have you checked to see how much potential difference is at one end or > the other? Yes, I have just had it checked at my request. > (Disconnect equipment from one end, and measure voltage > between the various RJ45 pins and ground, should be 0.00) We have checked between the switch ground and the RJ45 pins of the disconnected incoming cables, it's zero. > And how much > current is flowing? (set meter in mA and do same) Zero. > Worse your issue > could be entirely intermittent too. Yes, you're dealing with > gremlins. Just because the individual buildings are OK doesn't mean > they're OK with respect to eachother. You can have grounding > potential differences in different floors of the same building or > different areas of the same building. > > And all of this is assuming it's grounding potential > differencesnot something like your bundle of Cat5 runs right by a > big industrial refrigerator, or a sodium light or something like that > which is inductively coupling to your Cat5 run. There is some industrial equipment in the vicinity. That's why we had installed Ethernet protection (which proved ineffective this time). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Michael Loftis wrote: > > Many RJ45 ports have integrated magnetics now (transformer) - external > options are made by pulse, bel, halo, and many others. As for > external magnetics they're small - they don't need to be very large > because they're not designed to be carrying current. > http://www.pulseelectronics.com/products/lan has a dozen or more > examples. At first glance, these look exactly what I was asking for in the first post, a transformer, non-powered, right? There are so many models however, it's not clear if there are such ones could be placed between a regular UTP/FTP cable and regular switchport. > > > > >> If you've enough common mode > >> voltage to fault those out you may still be well short of "surge" > >> voltages that are protected by most equipment. You might improve the > >> issue by re-terminating each end only leaving the "spare" copper pairs > >> connected at one end of the RJ-45 (the switch end > >> generally)... > > > > Sounds like magic but could you elaborate? I did not quite catch the > > picture. > > You remove the extra (non 100mbit/10mbit) pins from the far end, don't > terminate them through, this sometimes is the path your stray ground > currents take. What to you mean by terminating/not terminating them? And thank you a lot for your input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Scott Granados wrote: > This problem sounds a lot like a dissimilar grounding issue. Sounds > like a potential between buildings is causing problems. I don?t > know if this is feasible but a common ground might solve some of the > problems. > Our electricians say that everything is correct, that all the grounding circuits are interconnected and they measure their parameters annually. I lack the necessary qualification to call them liars (even if they are lying which I doubt). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Andrey Kostin wrote: > > As I remember, APC protectors have to be grounded. If they aren't, they > can't protect. Of course ours are. > From my experience dusted for more than 10 years we had > such protectors burned out but they saved our equipment though still > resulted in downtime. OTOH, If you aren't using PoE it means you power > your remote devices by separate wire so why do not think about migration > to fiber? Rewiring scores of devices in many sites could be really expensive. I had thought the answer to my question would be simpler than it turns out. > > Also you can look at > http://www.zelax.ru/products/sfp-racks-cables/line-protection-uz-m#tabs|product:description > > and consult with Zelax's sales. Sorry guys, it is in russian. We work a lot with Zelax, I will talk to them, thank you for the idea. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Michael Loftis wrote: > No standard surge protector will help at all for you I'm betting. I have already guessed that therefore I was asking for something better than standard :-) > As > some have mentioned you're probably suffering significant (if > intermittent) common mode voltages...ethernet ports are already > "galvanically isolated" in the switch itself, and usually in the > device too, there's a transformer that'll remove the common mode > voltage component from the signal. Last time I looked at a NIC (and the inside of a toasted Catalyst) I don't remember seeing any transformers. But probably I did not look well enough, or they do not look as a typical transformer. Do you care to show a picture please? > If you've enough common mode > voltage to fault those out you may still be well short of "surge" > voltages that are protected by most equipment. You might improve the > issue by re-terminating each end only leaving the "spare" copper pairs > connected at one end of the RJ-45 (the switch end > generally)... Sounds like magic but could you elaborate? I did not quite catch the picture. > ultimately I've found nothing cures these issues except > full optical isolation (using a media converter at each end of the > building to building runs...in some cases this meant colocating > another switch in each building) and not running copper between the > buildings. Well, there are different rugged industrial copper Ethernet solutions for outdoor use (e.g. from Siemens), what do they use? > > The root cause is almost always bad grounding in one building or > another. In a couple cases we discovered that ants and termites had > colonized around the grounding rod. In another we discovered the Our electricians say that the grounding is correct, all grounding circuits on the site are interconnected and that they measure the parameters annually. I am not the person to expose them to be lying (if they really are), I lack such qualification. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Roland Dobbins wrote: > On Aug 18, 2014, at 8:07 PM, Victor Sudakov wrote: > > > Some devices cannot be grounded. > > I know you don't want to hear this, but if that's the case, they > should be immediately decommissioned as a safety hazard. You must be kidding. Whoever grounds a web camera? There are many devices that offically don't require grounding. > > This business of 'Ethernet surge protectors' isn't viable - if > equipment on one end of a data connection is shorting out equipment > on the other end of a data connection, the underlying electrical > problems *must* be solved. Tell this to numerous vendors of Ethernet protection devices ;-) -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
a.l.m.bu...@lboro.ac.uk wrote: > Hi, > > > Because I hoped to find someone already using them and ready to give > > positive or negative feedback about certain models. > > ah! > > > It's not like there is some backbone running between buildings as one > > might imagine. It's just perimeter protection devices and cameras, and > > an occasional data collection PC scattered on the premises. Some of > > them are outside and may even go as far as the gates or fence or > > whatever. > > yes - I can imagine the picture quite clearly. Can you imagine using optical fiber in this picture (unless the devices were equipped with fiber ports)? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
a.l.m.bu...@lboro.ac.uk wrote: > > > The choice is really big, Google gives many vendors and a wide range > > of models of Ethernet protectors. > > yesso why did you originally ask about them? ;-) Because I hoped to find someone already using them and ready to give positive or negative feedback about certain models. [dd] > this is why running direct copper between 2 buildings that are on > different grounding potentials etc - and running copper outside a > building generally - are It's not like there is some backbone running between buildings as one might imagine. It's just perimeter protection devices and cameras, and an occasional data collection PC scattered on the premises. Some of them are outside and may even go as far as the gates or fence or whatever. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Scott Granados wrote: > This problem sounds a lot like a dissimilar grounding issue. Sounds > like a potential between buildings is causing problems. I don?t > know if this is feasible but a common ground might solve some of the > problems. It is our version too, but using some isolation device could prove quicker and cheaper than rebuilding the grounding system(s). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
a.l.m.bu...@lboro.ac.uk wrote: > > > > http://datainterfaces.com/surge-protectors.aspx > > > > They do not seem to offer galvanic isolation, I think they use gas > > discharge modules. How do I know they are any better than those we > > already have (APC ProtectNet)? > > I dont. they are a choice thats out there The choice is really big, Google gives many vendors and a wide range of models of Ethernet protectors. > - and define your 'galvanic isolation' ;-) Well, er, http://en.wikipedia.org/wiki/Galvanic_isolation ;-) There are many methods, optical is one of them. What kind of optical isolation devices do you use? When I worked as a sound operator many years ago we used the transformer method a lot. In fact, our mixing consoles had symmetric transformer inputs. But I digress. > > > You are not advising them from your own experience, are you? > > nope. I havent used them as we have optical isolation (I feel I am > now repeating myself) BUT if anyone has used them or if you try > one out then please come back with your experience of it. > My experience so far is that the current model we use does not really protect. I will report later which model is that. The location where the last switch died is remote and normally unmanned. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Joel M Snyder wrote: > > > On 8/18/14, 2:51 PM, cisco-nsp-requ...@puck.nether.net wrote: > > >Do you know any devices to provide galvanic isolation for twisted pair > >Ethernet? > > > At Interop a few years back, Extreme switches in the infrastructure were > being blown up and we turned to APC isolation equipment. They had a > nice little 1U unit that seemed to do the trick. > > http://www.apc.com/products/family/index.cfm?id=145 This seems to be the one we are already using (however not a rackmounted variant, but standalone devices like the white thingie on the left of the picture) and they are not helping. > > Obviously it would be better to figure out the problem---probably ground > loop-related---but this might buy you some time while you figure out > what the problem is and, more importantly, how to solve it (which can be > very difficult or even impossible in some buildings). > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
a.l.m.bu...@lboro.ac.uk wrote: > > should never run copper for networks between buildings (and some > would say ever outside buildings) - thats optic territory. we use > optical isolation... In an ideal world, I agree. In the real world, I am not aware of any official standards, regulations or building codes that prohibit using Ethernet between buildings or outside buildings. If you know any, could you please provide a link. > but if you really want to > protect your ports maybe these will help: > > http://datainterfaces.com/surge-protectors.aspx They do not seem to offer galvanic isolation, I think they use gas discharge modules. How do I know they are any better than those we already have (APC ProtectNet)? You are not advising them from your own experience, are you? > > (if anyone else has experience of theseor you end up using > them...please review and give me some feedback as I do have some > annoying (and expensive) corner cases that they might be useful > for) > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Roland Dobbins wrote: > > > Something is very wrong, either on the switch or the 'attached > equipment'. Please see my reply to Howard Jones. > > Suggest you look into grounding of the devices on each end of the > connection, as well as PoE status on the ports at each end. PoE is not used. > > The solution is not in-line Ethernet 'surge suppressors', but rather > getting the electrical issue resolved. It is very easy to say 'get the electrical issue resolved' but it is the case of 'easier said than done'. Some devices cannot be grounded. Some can, but grounding them at a different grounding point than the switch itself can be worse than not grounding at all. After all, surge and ESD protection devices for Ethernet are on the market for a reason. It seems even a big market, all I ask you is to recommend a device. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Howard Jones wrote: > > > > Do you know any devices to provide galvanic isolation for twisted pair > > Ethernet? > > > > We have regular Ethernet surge protection devices (AFAIK APC) between > > the switch and the attached equipment but they don't help. This is the > > second Catalyst already with a burnt group of ports. > > > > Any advice is appreciated. > > > An SFP and some multimode fibre? (or a media converter to do the same - > Gig-E media converters are cheap) The devices (surveillance cameras, security sensors, portservers etc) have 10BASE-T and 100BASE-T interfaces, so this would mean two converters per device, and converters need to be powered... Too complicated. I have already thought of that and found unfeasible. > > What happens in the environment between the two devices? Is it passing > outside, or between buildings or something else? Yes, sometimes the cable passes outside and sometimes between buildings (but never exceeds 100m). Some devices can be grounded, some not. We thought that APC ProtectNet or similar surge protectors would be sufficient, but they don't seem to be. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Galvanic isolation for Ethernet?
Colleagues, Do you know any devices to provide galvanic isolation for twisted pair Ethernet? We have regular Ethernet surge protection devices (AFAIK APC) between the switch and the attached equipment but they don't help. This is the second Catalyst already with a burnt group of ports. Any advice is appreciated. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] UDLD enabling port prematurely?
Lukas Tribus wrote: > > However, UDLD is not useful in Victors' case, instead, I agree > that "spanning-tree loopguard enable" on the root port of the > remote switch is what will workaround the issue. Why on the root port only? I have enabled loopguard on all the ports connected to those MUXes without link poisoning. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] UDLD enabling port prematurely?
Dumitru Ciobarcianu wrote: > > > > This does not look good. If a broadcast frame arrives to this port > > before a BPDU does, there will be a storm and a lot of MAC flapping. > > Is there a way to keep the port from forwarding traffic until the UDLD > > state is Bidirectional ? > > You can try to enable spanning-tree loopguard. > It will disable the port until it receives an BPDU from the other side. Seems like a great idea, thank you. "The STP loop guard feature provides additional protection against Layer 2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) no longer receives STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the non-designated port receives BPDUs. When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes designated and moves to a forwarding state. This situation creates a loop. The loop guard feature makes additional checks. If BPDUs are not received on a non-designated port, and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state, instead of the listening / learning / forwarding state" -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] UDLD enabling port prematurely?
Saku Ytti wrote: > I guess if it's ethernet link over some radio or something, where autenego > isn't end-to-end, it might plausibly be useful, That is my case (an Ethernet link over several E1 links). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] UDLD enabling port prematurely?
Peter Rathlev wrote: > > [...] I need some sort of point-to-point L2 link fault management > > between the switches. > > > > Is UDLD suitable for this purpose? I have experimented a bit with > > "udld port aggressive" and have found out the following strange > > thing. > > > > When the physical link goes down, UDLD detects this condition and > > shuts the switch interface down. However, after several minutes, the > > interface goes up again with "%PM-4-ERR_RECOVER: Attempting to recover > > from udld err-disable state on Gi0/17". The interface is up even > > though "Current bidirectional state: Unknown", and seems to be in the > > STP forwarding state. > > This is because UDLD errdisable recovery has been enabled. You can > disable it with: > >no errdisable recovery cause udld > > Problem is that you have to intervene manually to enable the interface > after service has been restored. I may be already unable to reach the switch remotely to intervene manually, after the interface has been errdisabled for good. > But at least you will not have loops. > > I'm not aware of a more elegant solution to your problem, but I'm > interested in hearing about one. What if I try the non-aggressive UDLD, would it make any difference? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] UDLD enabling port prematurely?
Colleagues, I have several pairs of Catalyst 3560E switches connected via third party MUXes (Avara ENT100). When the actual physical medium goes down, the MUXes do not shutdown their Ethernet interfaces (i.e. they have no "link poisoning"). So I need some sort of point-to-point L2 link fault management between the switches. Is UDLD suitable for this purpose? I have experimented a bit with "udld port aggressive" and have found out the following strange thing. When the physical link goes down, UDLD detects this condition and shuts the switch interface down. However, after several minutes, the interface goes up again with "%PM-4-ERR_RECOVER: Attempting to recover from udld err-disable state on Gi0/17". The interface is up even though "Current bidirectional state: Unknown", and seems to be in the STP forwarding state. This does not look good. If a broadcast frame arrives to this port before a BPDU does, there will be a storm and a lot of MAC flapping. Is there a way to keep the port from forwarding traffic until the UDLD state is Bidirectional ? Thanks a lot for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Ge Moua wrote: > > Am I correct to assume that every time I need to move a vlan from one > > MST instance to another, my whole MST domain will fall apart until the > > MST reconfiguration is complete on all the switches? > I've seen good MST practice where the vlans per mst region/area are > accounted for ahead of time to mitigate what you stated here. > > ie, assign vlans by odd / even grouping for 2 mst regions (or more mst > regions if desired by some other preferred method). Great, thanks. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Federico Cossu wrote: > If you are looking for real fun, aggregate redundant links with > etherchannel, then disable STP. Etherchannel is not good for links with unequal bandwidth. If I wanted to get rid of STP, I would go for flex links. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3550/software/release/12-2_25_see/configuration/guide/swflink.html But this won't protect from occasional loops introduced e.g. by a technician. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
John Gaffney wrote: > You could consider MST to reduce the number of STP instances. > Sometimes that can increase efficiency. Am I correct to assume that every time I need to move a vlan from one MST instance to another, my whole MST domain will fall apart until the MST reconfiguration is complete on all the switches? Somehow I don't like this idea. > However what you are probably looking for is "spanning-tree > diameter" command. If I recall that can make some auto adjustments > to STP timers to accommodate for large switched networks. Even with the timer adjustments the maximum diameter is about 18 devices. Still my train does miraculously work provided the root switch is in the middle. > You should also be aware that 20 switches connected in a straight > line (hence middle switch) gives you a single point of failure. It is not exactly so because the radio equipment has a way to shunt the failed switch. So the continuity of the train can be quickly restored. But it is a different topic. I also have a backup root close to the middle of the train. This is also the reason why going all L3 is not an option. You cannot simply shunt a router. > If it is truly a "train" of switches you could also not run STP - no > ring/redundant link = no loop. As I have already said before, 'I have a "train" topology with some redundant links between neighboring switches'. There are however no rings in the sense that redundant links are only between neighbors. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Raymond Burkholder wrote: > > > I have a train of about 20 C3560X switches connected successively. > > > I know such a diameter is not good for STP, however, when I place the > > > root bridge in the middle of the train, PVST still works more or > > > less reliably. > > > > > Or turn on some simple routing like rip, and make each switch a layer 3 > subnet. Layer 3 segmentation can be more reliable than layer 2 > segmentation. In places where I need L3, I have routers connected to those C3560X switches, or VRFs with "no switchport" interfaces. But generally there are about 2 dozen VLANs which are more convenient on L2. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Dale W. Carder wrote: > > You could deploy rapid spanning tree. It does not care about diameter, > instead the max-age effectively defines your upper bound. That's good news. Does MST also not care about diameter, its IST instance being in fact an RSTP instance? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Engel wrote: > If the topology doesn't have any physical loop or redundant links > why would you run a SPT? I never said such a thing. On the contrary, I wrote: 'I have a "train" topology with some redundant links between neighboring switches' Moreover, even if I did not have redundant links between neighboring switches, STP is always a good precaution against someone (a technician) accidentally connecting two ports together. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
JC Cockburn wrote: > Hi All, > Might be a dumb response, but what about REP? > > http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/rele > ase/15-0_2_se/configuration/guide/scg3560/swrep.html > > seems legit??? Isn't it for ring topologies? I have a "train" topology with some redundant links between neighboring switches. I have also considered FlexLinks but came to the conclusion that STP was safer. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Antonio Soares wrote: > Check this article: > > http://slaptijack.com/networking/max-spanning-tree-stp-diameter/ Antonio, thanks for the interesting information, but my network's diameter is even more than 18. It's a long train of switches connected to a series of microwave radio relay towers built along a pipeline. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Antonio Soares wrote: > > > > I have a train of about 20 C3560X switches connected successively. > > I know such a diameter is not good for STP, however, when I place the root > > bridge in the middle of the train, PVST still works more or less reliably. > > > > However, if I wanted to divide this single STP domain into several smaller > > ones, which way is best? > > > > I can define three geographical areas between which no loop is physically > > possible and which cannot have any redundant links between one another. > > > > Should I just configure a bpdufilter on the border switches to separate the > > areas, or is there a smarter way, maybe going for MST instead of PVST? > MST is the way to go. It was designed with that in mind. Check this: > > http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/24248-147.html "Cisco recommends that you place as many switches as possible into a single region; it is not advantageous to segment a network into separate regions" I wonder if MST has any limits on the network diameter. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Divide large PVST domain?
Colleagues, I have a train of about 20 C3560X switches connected successively. I know such a diameter is not good for STP, however, when I place the root bridge in the middle of the train, PVST still works more or less reliably. However, if I wanted to divide this single STP domain into several smaller ones, which way is best? I can define three geographical areas between which no loop is physically possible and which cannot have any redundant links between one another. Should I just configure a bpdufilter on the border switches to separate the areas, or is there a smarter way, maybe going for MST instead of PVST? Thanks in advance for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
Gert Doering wrote: > > However, when I apply the following command to the interface: > > > > interface GigabitEthernet0/0 > > ntp multicast ttl 1 > > > > the routers again begins sending multicast NTP packets with ttl=28. > > > > What gives? > > "Don't do this, then" > > If you really care, open a TAC case, get a bug ID, and in 3-5 years, when > that particular network and router has long been retired, receive the > information that the particular IOS train that you are no longer using > is now bugfixed. > > Or maybe they will just change the documentation. I was writing here in the hope that it was I who was doing something wrong, maybe did not read some what's new note. This "ntp multicast ttl 1" has worked for me for years, I have some Unix hosts configured as multicastclients. Now I'll have to change them into broadcastclients. Not a big deal, but the surprise was unpleasant. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
Pete Lumbis wrote: > It sounds like NTP may be "stuck" in broadcast mode for some reason. I'd > suggest either calling TAC or issuing "no ntp" to completely disable the > service then reconfigure the ntp server commands. Resetting the ntp process by issuing "no ntp" and then reapplying the "ntp server" lines did help. However, when I apply the following command to the interface: interface GigabitEthernet0/0 ntp multicast ttl 1 the routers again begins sending multicast NTP packets with ttl=28. What gives? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
Aaron wrote: > Have you set your ntp source interface by any chance? No. In fact, now I have removed all NTP configuration except 2 ntp servers, but the multicast packets are still being sent: orlov# orlov#sh running-config | i ntp ntp server 10.14.129.71 ntp server 10.14.140.125 orlov# NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0). orlov# -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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 message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
This must be some NTP v4 novelty? All right, how do I revert to the old behaviour, or at least limit the ttl of those multicast packets sent from the 'NULL' interface? "ntp multicast ttl 1" on the interface does not seem to have any effect. Configuring a broadcast destination on an interface does not help either. I have tried configuring "ntp broadcast version 3" on the interface, but still see the dreaded packets to 224.0.1.1 with a big ttl. Those multicast packets with the big ttl are forwarded all over the network and cause confusion among ntp broadcast clients. Phil Bedard wrote: > NTP "broadcast" sends the messages using multicast, to 224.0.1.1. See > RFC5905. > > Phil > > On 7/2/13 6:09 AM, "Victor Sudakov" wrote: > > >Colleagues, > > > >Why is a CISCO3945 router sending multicast NTP packets with ttl=31 (!) > >while I have never configured it to do so? "debug ntp packets" reveals: > > > >NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0). > >NTP: ntpio_send_ipv4 called with bcast address and NULL interface > > > >In fact, it is configured to send NTP broadcast messages on some > >Ethernet interfaces, but not multicast. What could be wrong? > > > >! > >interface GigabitEthernet0/0 > > description Orlovka > > ip address 10.14.128.225 255.255.255.224 > > ip pim sparse-dense-mode > > duplex auto > > speed auto > > ntp broadcast destination 10.14.128.255 > > ntp broadcast > >end > > > > > >-- > >Victor Sudakov, VAS4-RIPE, VAS47-RIPN > >sip:suda...@sibptus.tomsk.ru > >___ > >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/ > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0).
Colleagues, Why is a CISCO3945 router sending multicast NTP packets with ttl=31 (!) while I have never configured it to do so? "debug ntp packets" reveals: NTP message sent to 224.0.1.1, from interface 'NULL' (0.0.0.0). NTP: ntpio_send_ipv4 called with bcast address and NULL interface In fact, it is configured to send NTP broadcast messages on some Ethernet interfaces, but not multicast. What could be wrong? ! interface GigabitEthernet0/0 description Orlovka ip address 10.14.128.225 255.255.255.224 ip pim sparse-dense-mode duplex auto speed auto ntp broadcast destination 10.14.128.255 ntp broadcast end -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Finding the root bridge
A convenient way to identify the root bridge without logging in to a lot of switches to figure out their addresses. Works only if you have VTPv3 enabled. sw-bptoik#sh spanning-tree vlan 22 | i Address Address 4403.a7c9.a780 [dd] sw-bptoik#sh vtp devices | i 4403.a7c9.a780 VLAN No 35 e4d3.f1cc.f280 4403.a7c9.a780 sw-sem sw-bptoik# So "sw-sem" is the root brigde. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Default CoS
Saku Ytti wrote: [dd] > > It's not very good idea to implement QoS without some idea of your goals. > At very least you should decide how many classes you need to discriminate > your traffic into (the fewer you can live with, the better, if you're not > running QoS now, 2 might be prudent) My present goal with QoS is simple enough. In the radio relay equipment we use, the Ethernet bridge can have 4 queues based on CoS bits. So I don't need more than 4 classes. I must classify frames so that VLANs with high priority traffic (e.g. SCADA) never get congested by low priority VLANs for business applications. The radio bridge is configured to trust the CoS bits on input. > > Especially in small Catalysts just turning MLS QoS on pretty much > invariably makes your life worse than what it was. Sounds pretty scary. If I could only mark outgoing frames without actually turning MLS QoS on, that would be fine with me. Is that possible? The bottleneck will always be in the radio relay system, not in the Catalysts themselves, I suppose, just because the bandwidth of the radio relay is just several STM-1s, nowhere near 1 Gbit/s of Catalysts' interfaces. Thanks for the links to documentation. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] Default CoS
Colleagues, I have enabled "mls qos" on some C3560X switches and configured "mls qos trust cos" on the trunk ports. Nothing more. In Wireshark I can see that some packets generated by the switches themselves have some non-default CoS values. E.g. OSPF hello packets and PIM messages have the cos value of 6 in the 802.1Q header, STP frames have the value of 7 etc etc. Why does this happen and where is it documented? I have read somewhere that IOS marks IP routing traffic to DSCP CS6. Is there some mapping between DSCP and CoS bits enabled by default? However, there can be no question of DSCP in STP frames. Where can I read what else is marked by default and how? Thanks in advance for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] VTP Pruning and VTPv3
Colleagues, Are there any known problems with VTP pruning in a VTP version 3 domain? Should I expect any problems if I enable it? I know about a caveat that "With VTP versions 1 and 2, when you enable pruning on the VTP server, it is enabled for the entire VTP domain. In VTP version 3, you must manually enable pruning on each switch in the domain." Any other issues? TIA for any input. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] L2 car/policing on C3560X (IOS 15.0(1)SE3, ip services licence)
Terry Cheema wrote: > Yes, you should be able to do that, but on 3560/3750 I think there's > a limitation, it's not going to show the output of show policy-map > interface correctly. You can use show mls qos int g0/4 instead - it > should give you a view of whats going on... > > Another thing, By default qos is disabled on 3560, so no > classification occurs, make sure to add "mls qos" to enable, just in > case you havent done that... Thanks a lot, "mls qos" did the job, at least policing works. "show mls qos int g0/4" shows that there is a policy map, but it is not as informative as "show policy-map interface" would be. Could you advice a good white paper on QoS on L3 switches? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] L2 car/policing on C3560X (IOS 15.0(1)SE3, ip services licence)
Colleagues, Is it possible to police traffic on L2 ports? I have configured a policy map, but "sh policy-map interface" counters are all 0 and traffic is not being policed (which is confirmed by iperf). Could you please refer me to the relevant documentation? Thanks a lot in advance. = ! policy-map ITSO description ITSO traffic class class-default police 200 8000 exceed-action drop ! ! interface GigabitEthernet0/4 description Energy Monitoring switchport access vlan 10 service-policy input ITSO ! = sw-parabel#sh policy-map interface gi 0/4 GigabitEthernet0/4 Service-policy input: ITSO Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any sw-parabel# -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] VTP and shared medium
Hitesh Vinzoda wrote: > > And second question. If one port is in trunk mode and the other in > > access mode, shouldn't the untagged native Vlan1 traffic still flow as > > normal? > > Can you please share the output of show interface xxx trunk Sorry, I can't reproduce the problem any more since I have reconfigured PASOLINK from a shared medium to point-to-point links between switches. It was a rather desperate solution because any failed switch will now break the connectivity to other switches behind it. But the DTP/VTP problems have disappeared. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] VTP and shared medium
Hitesh Vinzoda wrote: > > Can you post the configuration on the other end. Seems like it hasn't > negotiated the trunk. Further you can also DTP using below command > > Switchport nonegotiate I had the impression that the "switchport mode trunk" command is an unconditional trunk mode. How can the following be possible? Switchport: Enabled Administrative Mode: trunk Operational Mode: static access And second question. If one port is in trunk mode and the other in access mode, shouldn't the untagged native Vlan1 traffic still flow as normal? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] VTP and shared medium
> > I have configured a VTP domain and a VTP password on all the switches, > however changes to the vlan database and other VTP information are not > propagated to all the switches, or sometimes to some of the switches. The possible reason is that some ports are in access mode though configured for trunk mode? Why could that be? ! interface GigabitEthernet0/1 switchport trunk encapsulation dot1q switchport mode trunk #sh int GigabitEthernet0/1 switchport Switchport: Enabled Administrative Mode: trunk Operational Mode: static access Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: native Negotiation of Trunking: On Access Mode VLAN: 1 (default) Why is the port in static access mode while it is configured as "switchport mode trunk" and has the administrative mode "trunk"? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] VTP and shared medium
Colleagues, I have several WS-C3560X-24P switches connected by dot1q trunks to a shared medium: NEC's PASOLINK microwave system. This PASOLINK is essentially configured as a big dumb transparent switch. Is VTP supposed to work in such a configuration between the Catalysts? I have configured a VTP domain and a VTP password on all the switches, however changes to the vlan database and other VTP information are not propagated to all the switches, or sometimes to some of the switches. E.g. I have changed vtp version from 1 to 2 on one of the switches, it did propagate only to some of the switches, and not to all of them. Any help is greatly appreciated. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] router does not see IGMP joins
Hitesh Vinzoda wrote: > > > > It seems that the problem disappeared after the host sending IGMP > > joins was moved from a hub (10BASE-T HD) to a switch (100BASE-T FD). > > > > I am still confused about the possible cause of the problem. > > > > Is PIM enabled on that interface ? I posted the output of "sh ip igmp interface fastEthernet 0/0" here https://puck.nether.net/pipermail/cisco-nsp/2012-March/084031.html as you probably remember. It says "Multicast routing is enabled on interface". If PIM were not enabled on the interface, how could moving the host from a hub to a switch (without any changes in the router configuration) have solved the problem? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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] router does not see IGMP joins
Victor Sudakov wrote: > > What could be the reason that a Cisco 1841 router (IOS 12.4(13r)T) > does not see IGMP joins to a particular group? tcpdump shows that the > joins are being sent to the network, however "debug ip igmp 224.0.1.3" > does not show them. It seems that the problem disappeared after the host sending IGMP joins was moved from a hub (10BASE-T HD) to a switch (100BASE-T FD). I am still confused about the possible cause of the problem. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ 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/
