Re: [c-nsp] Redistribute interface address as a /32 or /128 into BGP
>> Now some of my monitoring and management traffic, which is addressed to >> the customer facing interface addresses takes the shortest path into >> 10.0.0.0/24 and through this network and might then hit the interface of >> the router. But there is a ACL that blocks that, because it looks like >> the customer spoofed the source address of the monitoring system. > But you're doing it wrong. I'm not sure what is right without > understanding more accurately what you are doing, but some flavor of If I understand correctly, you are monitoring ICMP reachability of, say, 10.0.0.2, because reaching the router itself (e.g. its loopback or its backbone address) and getting via SNMP the state of its interface is not enough for you, you want to make sure to be able to reach addresses in the actual customer prefix, to detect routing problems with that specific prefix. If this is the case, I have a very similar situation and I did not come up with a solution. Injecting host routes, as you tried to do and Saku explained how to do, should work but is actually cheating: you will detect routing problems with the host route, not with the customer prefix. Or, maybe, the customer facing interface is in a VRF and the backbone/loopback is not, and you are monitoring from the VRF. Then the host route is OK, you could add a loopback in the VRF to distinguish router down vs. interface down. Regards, Bergonz -- Michele Bergonzoni Network Management and Security Network Design Team Leader Laboratori Guglielmo Marconi Via Porrettana 123 40037 Pontecchio Marconi (BO) - Italy Phone +39 051 6781926 Mobile +39 3484135807 ___ cisco-nsp 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] loop guard still useful?
> Using the dispute mechanism included in the IEEE 802.1D-2004 RSTP > standard... I'm wondering if there's any reason to keep loop guard configured I think the dispute mechanism can detect unidirectionality where data out of the designated bridge is lost (which is enough to prevent loops), not the unidirectionality in the other direction. So the dispute does half of what UDLD does, if I got it right. Loop guard is different, it protects only from self-looped ports. I don't know if the wording of RSTP are written in a way to protect you from that, but I'm sure that the original STP standard was written in such a way that any compliant implementation was unable to block the loop caused by a self-looped port. Most vendors quietly worked around this, and I don't know if 802.1d corrected this error in the previous standard. I know that it is very unlikely to find a switch whose STP can't protect you from such a situation. So I bet that if you use RSTP you can disable loopguard, and if you like UDLD there is still a reason to use it. My personal best practice when using this errdisable features is to always enable auto recovery after a suitable time. Cheers, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] 1000BASE-ZX/LH multi-manufacturer interconnection
> equipments of different vendors using 1000BASE-ZX/LH. Since 1000BASE-ZX > isn`t standardized by IEEE, ... Can I connect 2 equipments of different > manufactures > using their own manufactured transceiver? We do it all the time and never had any problem. Of course you have to comply with minumum attenuation requirements (don't test them with a short patch, you could damage your receivers). I too am curious to hear about stories of such incompatibilities, if any. The lack of a standard means that if it actually doesn't work, you will have a hard time to blame it on vendors. I'm afraid you have to accept this risk. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] loop guard still useful?
> On A-B link, where A=>B works but A<=B does not, A will go down and A > will assert RFI or remote fault indicator on the line. B will receive > this, and go down as well. You're right as usual. I actually happened to see a 1000baseLX port in dispute a few years ago, so you made me dig through old emails and tickets. It was a 6500 facing a 3750, and it was because MSTP BPDUs where incorrectly tagged, probably due to CSCta17209, we fixed upgrading the 3750. Probably UDLD wouldn't have helped either. Thanks, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] 1000BASE-ZX/LH multi-manufacturer interconnection
> From which manufacturers do you interconnect equipments with EX/ZX (or > ER/ZR)? I've seen working links among Cisco, Juniper and Extreme networks. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] loop guard still useful?
First of all, I have to admit that I confused loop guard with keepalives (the one that errdisables self looped switchport interfaces, and then people do "no keepalives"). Sorry. > So it seems like loop guard isn't needed if rstp is enabled. I have no operational experience with loop guard, but from the description it seems to me that in order to trigger it the interface must become unidirectional *after* link up. Thus, if your Joe Average while troubleshooting does a shut/no shut, he actually gets the loop. So it will protect you on the other unidirectionality side, but not in all possible sequences of events. If you are operating an all-cisco net you might take a look at bridge assurance. I have no operational experience with it as well (apart from disabling it in the nexus), but looks much more like a bidirectional keepalive at the STP layer. It is proprietary and violates the standard as I understand it. > No, I don't like UDLD at all - too many bad experiences with it In fact after what Saku said I would consider trusting the layer 1, but I usually work in a multivendor environment, YMMV. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] ME3400 Spanning-tree
> I have Cisco ME3400 switch which is limited to 4 ports NNI > I discovered that I cannot apply any spanning-tree commands on any interface > unless it's nni port Have you tried with "port-type eni" ? It makes many, but not all, NNI things work. Cheers, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Intermittent Port Forwarding Problems with New-Style NAT
What I'm randomly encountering is the port forward will stop working, and I have to remove and re-add the line: ip nat source static tcp 192.168.1.3 3389 interface Dialer1 3389 I had the same issue with an 831, my line is: ip nat inside source static tcp inside private IP 5900 interface Ethernet1 5900 but my eth1 has a static (public) IP. I had to remove and reapply the line every now and then, as you describe. I don't remember the version that had the issue, but it disappeared with the upgrade to 12.3(11)YZ2. Hope thie helps, Bergonz ___ cisco-nsp 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 the Nexus 3064PQ usable ?
Does anybody have success/horror stories about the [Nexus] 3064 or 3048 to share? If you email me in private, I can post an anonimized summary. I received two very helpful replies. One person told me about some new 3172PQ: I am loving them to death. This person is using them as L2, with vPC. One person is using the 3064X with OSPF, BGP VRRP and is happy with it. This is very similar to what I am trying to do. I still feel a bit uneasy, but I think we will end up trusting the datasheet. Cheers to all, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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 the Nexus 3064PQ usable ?
I've watched the recent thread about Cisco switch portfolio miss with interest, since I am in the process of replacing some old 6500s in the a data center and in a campus core. Requirements are reasonable: IPv4, few routes, 4-5 VRFs, BGP, OSPF, HSRP. Port and protocols requirements would be more than fulfilled with a 3064-X (N3K-C3064PQ-10GX) + a 3048TP (N3K-C3048TP-1GE). The price of these boxes appear to be much, much less than the equivalent 6800 or 4500 or any bigger Nexus. Raw performance is impressive. So my dilemma is: should I follow the data sheet, with the risk of having a buggy and unusable box, or should I buy the better known boxes, using more of my budget and giving up on other things? I remember when the Cisco logo on a box was enough to settle such doubts. Does anybody have success/horror stories about the 3064 or 3048 to share? If you email me in private, I can post an anonimized summary. Best regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] 7600 - Tunnel in VRF not working over MPLS
Could anyone explain why the following setup is not working, maybe there is a limitation on 7600 for this? PE1---[MPLS]--PE2tun99--CE Basically, Tunnel 99 is in VRF. All routes including tunnel are visible in VRF. Ping sourced from tunnel99 to CE works (directly connected), but when I ping from PE1 tunnel99 on CE, or any other route behind tunnel99 on CE, it doesn't work. I have mls mpls tunnel-recir configured on PE routers. You should probably take a very close look at the CEF and adjacency entries for the routes in Tu99 on PE2, and to the LFIB for the corresponding labels with sh mpls forwarding-table. If the labels for those routes are the same, and are the aggregate label for the VRF, I would try mls mpls recir-agg, if you can spare some switch capacity. If they aren't, I would try to make PE2 use only the aggregate for that VRF (if it is possible in you environment) with mpls label mode yourvrf protocol bgp-vpnv4 per-vrf, in addition to mls mpls recir-agg. If this doesn't work, try to post your routes, CEF, adjacencies, labels and mpls forwarding-table (for PE2). Best luck, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Help: attach a service-policy to an interface, without knowing which one is already attached
I am writing an automated configuration script, where I want to create a policy-map and attach it to an interface, in some ME 3400's. The environment is such that I would like to determine the configuration commands to give, using SNMP only, i.e. without any show command and without access to the CLI. I know this is terrible, but that's the situation I'm into. The problem is that to apply a service-policy I have to remove any existing service policy from that interface, and to do that I have to know its name. The 3400 does not support the CLASS-BASED-QOS-MIB so I don't know where to get this information. So, if I do: policy-map mymap class class-default (whatever) Switch(config)#int gi0/1 Switch(config-if)#service-policy output mymap Policy map hismap is already attached At this point I know that hismap was attached, but it's too late. What I would like to do is: Switch(config)#int gi0/1 Switch(config-if)#no service-policy output % Incomplete command. Or: Switch(config-if)#default service-policy output % Incomplete command. I cannot use default interface because it cleans too much. I could delete the policy-map, and that would automatically detach it from all ports, but to do that I still have to know its name. I tried to search in a complete dump of the SNMP tree (from .1) but the name of the attached policy is not present. So, if you read this far, and you know some smarter command that I'm missing, that would be of great help. Of course there are workarounds, but in this particular environment they are all very, very ugly. Thanks in advance, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Help: attach a service-policy to an interface, without knowing which one is already attached
Il 11/03/2014 14:03, Garrett Skjelstad ha scritto: Why not frequently pull the config using the config-copy-MiB, link and store the interface service-policy in a DB (or I guess CSV) and use that? I suppose you could also just in time pull the config, but for every transaction that would suck. You do need TFTP access for this... Thanks Garrett, this is one of the workarounds that can apply, it is not ugly per se, but it is impractical in my particular and strange environment: I would have to ask for SNMP write access, explain why I need it, have it approved and implemented, it will probably be the ugly SNMPv3, etc. It will take days. I can also have RANCID save configs and parse thems from my program, or retrieve data from IOS web interface, but all these workaround require bureaucracy in my particular environment. In fact, the workaround I will probably implement if the perfect solution turns out to be nonexistent is what you describe as that would suck. Thank you again for your help, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] ME3400 high cpu
are noticing a fairly high CPU load compared what we were used to on the older 3550's. It looks like we are punting packets like crazy... cpu-queue-frames retrieved droppedinvalidhol-block stray - -- -- -- -- -- rpc 0 0 0 0 0 stp 234154 0 0 0 0 ipc 0 0 0 0 0 routing protocol 18718180 0 0 0 L2 protocol 208159 0 0 0 0 remote console0 0 0 0 0 sw forwarding 14959846 0 0 0 0 host 305132 0 0 0 0 broadcast 17541970 0 0 0 cbt-to-spt0 0 0 0 0 igmp snooping 369150 0 0 0 0 icmp 73119 0 0 4 0 logging 0 0 0 0 0 rpf-fail 0 0 0 0 0 dstats0 0 0 0 0 cpu heartbeat 23207470 0 0 0 I think crazy punting would go into the sw forwarding line (and deliver high latency to your customers), but you appear to have a big icmp line. Maybe you are just generating a lot of ICMP unreachables for the usual reasons, and maybe this is more difficult for a 3400 than it is for a 3550. I would try to deb plat cpu-queues software-fwd-q (this is guaranteed to be a heavy debug for your CPU) to see what kind of packets the CPU is transmitting/receiving. I know this is not much but hope this helps somehow. Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] ASA SME
Il 12/06/2013 05:44, Phil Fagan ha scritto: Looking for some insight on how Cisco handles the VPN traffic; return traffic and possible routed tunnel interfaces for use with routing protocols. I don't see a whole lot out there about site-to-site VPNs and interop between Cisco and Juniper using dynamic routing protocols. AFAIK, ASA cannot do tunnels and cannot use routing protocols over IPsec: Cisco IOS routers do that. I would be very happy to be proved wrong. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] ASA SME
Il 12/06/2013 09:42, Mike Hale ha scritto: It looks like it's doable, but annoying for OSPF anyway. ospf network point-to-point non-broadcast neighbor 40.40.40.2 interface outside You proved me wrong, but for some reason I'm not so excited... I completely overlooked the internet-as-a-NBMA approach. It is intriguing, and I wonder if it actually provides working redundancy and what the routing table and the OSPF database will look like. What I really would be excited about would be From upcoming release xyz ASA has got GRE. Thank you for pointing this out. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Auto Negotiate
changed the Network Adapter Link Speed from Auto Neg to 100 meg Full ...pc aquires IP, Changed to 100 meg Half, pc works. On thing to check is the cable: old-style ethernet cross cables (with crossed pin 1-3 and 2-6) used with gigabit switch ports, can lead to issues similar to what you describe. It can happen when you have an old 100 meg switch and you upgrade it with a new 1G switch and there are forgotten cross cables. Hope this helps, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Need help with IPv6 CoPP
If I apply the policy-map after OSPF changes to FULL, it stays in that status. If I apply the map and clear OSPF process it flaps the whole time between EXSTART and DOWN: Are you using OSPFv3 authentication? In this case the first protocol in the packets is AH, and the next is OSPF. This doesn't fully explain what you're seeing, but is something to check. I have no clue for the other strangenesses you describe. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] 10gig Link Bouncing Consistently
Beginning several days ago both links began flapping every 5 and a half hours, both links have this happen within a couple of minutes of each other. They will flap for several minutes and then return to normal operation requiring no user action and the ports never enter err-disable or show any other symptoms. Your story popped me up a distant memory of a heating system that happened to leak steam on a fiber cable. That cable contained all the 4 fibers of a presumed redundant connection. I would not let the next predicted flapping time pass without: * show interface transc det when everything works, and when things go bad * technicians at both ends ready to disconnect one line and test the loss on the fibers with appropriate instruments, in the first window (~850 nm) * physical inspection of the fiber run, if feasible If the fibers turn out to be OK, when you have a Cisco 6509 on one end and a Netgear on the other, and you need to try to replace one of them, we all know where to start. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Nerdy SNMP/IPV6 question
Il 17/10/2012 14.14, Drew Weaver ha scritto: I was working on our IPv6 provisioning system and I'm having a hard time finding a way to poll the IPv6 routing table via SNMP (SXI 5 on SUP720-3BXL). Is there really no MIB for this yet? Try 1.3.6.1.2.1.4.24.7.1. I use it on 7600 with RSP720 and 15.1(2)S, where it shows VRF routes as well, with unfathomable zone (dest and next hop) fields. If you get some data, and understand the zone format, please share. My current experience with IPv6 and SNMP can be described as THIS PART CENSORED BY NOSY MIDDLEBOX ON PORT 25. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] IOS archive in addition to RANCID
Il 10/10/2012 2.52, Ian Henderson wrote: * Having two methods ensures that if one method breaks, we still have useful logs/archives. This is particularly nice in our environment I particularly appreciate this design principle. Please consider doing a periodic SCP of important files which are otherwise not backed up: - nvram:ifIndex-table, if you use ifindex persistency - flash:env_vars, for switches (as Matt pointed out) - flash:vlan.dat, if for some unlikely reason you use VTP Rancid does a dir, so you can see (grep, etc) there if these files exist on your switches. Also please take the time to try to restore a device from the backup you have: everybody can do a backup, but only the brave can actually restore. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] SNMP proxing in a VRF
I have core routers that implements several VRF. On theses VRF, I have several CPEs. I would like now to have a similar functionality to proxy a SNMP call to a distant router on a VRF thru a core router routing this VRF. I think there is no such functionality in Cisco nor Juniper. If I turn out to be wrong, please let me and this list know. Possible workarounds: - central services vrf with your management station. This is the standard workaround, and can be used for ping and ssh as well. Also called common services, for a complete googling experience. - A GRE tunnel from your management station to the nearest core router for each VRF (Linux can do that, don't know about windows). If the core router is in the same rack, a VLAN trunk is simpler. Again, if you come out with an SNMP proxy in a single box (not a distributed NMS with agents) that really supports VRFs (even with overlapping addresses) please let me know. Hope this helps, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] 3550, 3750, ME3400 storage of current sdm template and system mtu
Anybody knows where does a 3550, 3750 or 3400 store the information about: - sdm template at next boot - system mtu (inc. jumbo and routing) at next boot I ask because I just realized that backing up image, startup-config and letting rancid do its work are not enough to completely restore a switch in case of hardware failure. I did some sh boot, more on files I found in the flash and nvram, but I cannot find this info. Maybe it is in the private-config.text, which is unreadable (why?). I am going to add sh sdm prefer and sh system mtu to rancid, but I wonder why didn't they simply include it in the config and save me some troubleshooting. If you know more configuration parameters that are not stored in the config, or you know the logic behind this, please let me know. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-6781926 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] L3VPN works, but not default route
Il 18/04/2012 2.06, aar...@gvtc.com ha scritto: then i redis ospf into mp-ibgp and i see all of my ospf routes (about 490 routes total) advertised over the mpls core to the other pe on the other side of the cloud the only route that doesn't make it over is 0/0 If it's IOS, redistribute does not apply to the default route. You need to set default-information originate in the AF stanza of the bgp router, like this: router bgp x address-family ipv4 vrf CUSTOMER redistribute ospf etc... default-information originate Hope this helps, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] Management VLAN not working (2950T-24)
Il 13/12/2011 19.35, Lee Starnes ha scritto: that was working fine until we changed the device it is directly connected to for its uplink Just a quick attempt: clear arp-cache ? Maybe you discconnected the uplink in turn and vlan32 never went down, so it still remembers the old MAC. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Alternate setup for better HA
Il 27/10/2011 0.04, John Elliot ha scritto: Our usual setup would be to have a 2851 + 2960 as active, and manually copy the config across to the spare 2851+2960, and if one of the primary fails, it would require swapping cablesnot ideal. If the 2851s have independent connections to your core, you can connect the second 2851 to the first 2960 (and the first 2851 to the second 2960), create the SVI interfaces with the same IP address as the first 2851, and keep them in shutdown. Thus if your first 2851 fails, you can telnet to the second and manually no shut them: not a big deal, but usually faster than running at the POP. You can also make a clever HSRP + EEM setup to have this automatically done, but I personally would not use such a complicated setup for such a minor achievement. For the 2960s, if your carrier gives you only one physical connector there is not much that you can do to achieve redundancy: the connector has to be plugged in some device (here it's the 2960), and if it fails you have to move it. Hope this helps. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 3750 Metro internal vlan allocation for loopback?
Il 25/10/2011 21.39, Jared Gillis ha scritto: VLAN Usage 1006 Loopback1 interface Loopback1 description Primary Management/Peering IP ip address a.b.c.d 255.255.255.255 You might try to trade the Lo1 for a VLAN: vlan 4000 exit no spanning-tree vlan 4000 int Vlan4000 description Primary Management/Peering IP ip address a.b.c.d 255.255.255.255 Since autostate will put this VLAN in line protocol down if there are no physical ports, you should allow it in some trunks that you expect to be always up. Yes, it is an ugly workaround, inapplicable if you don't have such trunks. I don't think autostate can be turned off on the 3750ME, if it turns out to be possible, that's better. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] 15.0(SE) 3560 was ME3600X Netflow and WCCP?
Il 28/07/2011 9.35, Reuben Farrelly ha scritto: I've had some quite odd problems with IPv6 with 12.2(58)SE1 ... and two exhibited this problem whereas two others didn't Maybe trivial, but: did you check the SDM templates? Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] ip helper-address, VRF, and Windows 2008 DHCP Server
John Gill wrote: The DHCP DISCOVER should be a broadcast It should be a broadcast when exiting the client, i.e. on the client's subnet. The DHCP relay (helper-address funcionality) transforms it in an unicast packet from the (primary) IP of the router's interface facing the client, to the DHCP server. The server should reply to the source it sees, i.e. the IP of the router interface. The router should transform this into an IP broadcast to the MAC address of the client, or to the broadcast MAC address if the broadcast bit was set in the request. perhaps this is why your server doesn't reply to it. There must be some other reason, which I bet is buried in the event log or in some other log, if the server has a correct scope. I see nothing obviously wrong in that request. Client MAC address: Avaya_86:13:ed (b4:b0:17:86:13:ed) Option: (t=60,l=13) Vendor class identifier = ccp.avaya.com Maybe it's configured to avoid answering to Avaya phones or IP phones in general? This is not an uncommon setup. Bye, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] GRE tunnel to do span vlan across two datacenters?
Il 06/07/2011 18.08, Jason Gurtz ha scritto: A firm has proposed creating a GRE tunnel between two datacenters (using a 3750X stack at each) to create the spanned vlans needed for VMWare failover application. Remember that you cannot bridge over a GRE tunnel, and cannot terminate any kind of tunnel on a 3750 (pretty sure) or a 3750-x (less sure, but it's in the release notes). From what I understood of your pictures, you're planning to make a tunnel interface on V1 (unsupported on this platform), and put it in a bridge-group (unsupported anywhere AFAIK: the R in GRE stands for Routing). You could try with L2TPv3, but I think it is unsupported on the 3750[-x]. If I get the pictures right, you could get away with a VLAN on C1 with two ports in dot1q tunnel mode + l2protocol tunnel stp, and a similar situation in C2, so V1 and V2 will have their own spanning tree and C1 and C2 will not partecipate in it (if you need also L3 in V1/V2, you will have to use a different physical interface). But I'd rather use dark fiber if at all possible, as Gert said. Or elaborate on the fact that Layer 3 is by definition the layer where things like forwarding, routing around failures, etc. take place, and servers should learn to live with it: this is hard to swallow after years of VMware and Microsoft NLB, but that's the hard truth. Regards, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 Fax:+39-051-6153683 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Spanning-tree boundaries and configuration
Peter Rathlev ha scritto: Should I participate the customer STP in my topology for preventing loops and broadcast storms or ignoring his BPDU's totally? ... Otherwise there's AFAICT no way around joining the STP domain of your customers. In that case you should of course try to make sure that L2 problems coming in from one customer doesn't affect other customers. I think we all agree that joining the STP domain of the customer can be a major nightmare, and using pseudowires or enabling bpdufilter is the way to go for non redundant connections. I've never seen an MST multi region deployment in a carrier/customer scenario (I'm not even sure that MST was designed for that). For redundant connections, VPLS is the technology specifically designed for this environment. If it's not available, what can be done is to deploy two separate redundant circuits (or two separate redundant metro VLANs, if there are more than two endpoints), and let the customer use its STP of choice to avoid loops. You transport customer STP as any other customer traffic, with l2protocol-tunnel. This is not perfect, but mostly works. Regards, Bergonz ___ cisco-nsp 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] (SOLVED) Re: 7600 PFC MPLS - Aggregate label disposition + L3 FIB lookup + imposition: workaround?
Saku Ytti replied to me: Not 100% sure, but worth a shot, try 'mls mpls recir-agg' This is exactly what I was looking for, the packet is recirculated and the imposition takes place. The CLI help says that this command only impact new aggregated labels, but it worked immediately. Thank you again, Saku! Bergonz ___ cisco-nsp 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] 7600 PFC MPLS - Aggregate label disposition + L3 FIB lookup + imposition: workaround?
Hi, I have an MPLS network where some 7600 PEs (running 12.2(33)SRD) have the internet with full routing table in a VRF (I know many of you and the CPU don't like this), and I want to connect internet customers to small PEs that cannot take a full routing table. My current solution is to put a default route in each of the internet gateway PEs (those peering with our transits) on Null0 in the internet VRF, make a new VRF and leak that default route into it, and leak back customer routes from the new VRF to the internet VRF. Small PEs see the default route in the new VRF coming from vpnv4 BGP with the aggregate label of the internet VRF of the closest gateway PE. This almost works: routes are leaked OK, egress packets from the small PEs reach the gateway PE and, if BGP says that it should leave the MPLS cloud and take the transit link, it does and works. If BGP says to forward it to a different gateway PE (that has a different peering which is better for that route), the packet is lost. After careful perusal of this list's archive I understand the reason: an MPLS packet received with the aggregate label needs a L3 FIB lookup, and after this point it cannot be re-labeled and re-enter the MPLS (in a PFC based MPLS). Now I need a workaround, i.e. a way to make the packet received form the PE with the aggregate label, be forwarded to a different gateway PE. I would really appreciate your suggestions. What comes to my mind is: 1 - Loopback cable on the gateway PEs: extremely ugly (and highly visible). This is the minimal case of the more general add some piece of hardware outside the MPLS cloud, which I'd prefer to avoid if possible. 2 - Ensure connectivity among gateway PEs in the internet VRF, out of the MPLS cloud (this is possible in this network), and make them peer with ipv4 unicast IBGP in the internet VRF, in order to receive routes with a nexthop in the VRF and without labels. I wonder if this (IBGP over ipv4 in VRF) routes will be preferred over the MPLS (IBGP over vpnv4 with labels, RD and RT) ones. I also wonder if the 7600 CPU will finally give up and leave me alone: there is plenty of RAM free, but I am afraid my BGP table will double, doubling the time to scan it as well. I can also avoid the second VRF altogether, and the leaking between the two, with an import map on the internet VRF on the small PEs to limit the imported routes to the default (this is probably less ugly), but the situation would be exactly the same, since they will send packets to the wrong egress PE for some routes, using the aggregate label, and I still would need a workaround. Do you see any more intelligent/elegant workaround? Do you think workaround #2 could work without melting my CPU and flapping my adjacencies? Thanks in advance, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 Fax:+39-051-6153683 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp 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] Free NMS Tools
(no ifindex blues). Hope this helps, Bergonz -- Ing. Michele Bergonzoni - Laboratori Guglielmo Marconi S.p.a. Phone:+39-051-4392826 Fax:+39-051-6153683 e-mail: berg...@labs.it alt.advanced.networks.design.configure.operate ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
