|
Boogeyman posted:Output of sh int g0/43 trunk: from memory VTP is carried on VLAN1, you've pruned it out of your trunk, so maybe try adding it back in
|
#
?
Jun 9, 2011 08:17
|
|
|
|
| # ? May 28, 2024 04:22 |
|
|
nzspambot posted:from memory VTP is carried on VLAN1, you've pruned it out of your trunk, so maybe try adding it back in
|
|
#
?
Jun 9, 2011 08:47
|
|
|
ruro posted:Pretty sure you don't need to allow vlan1, it should just get sent regardless, like CDP. cisco sayz By default, VLANs 2 through 1000 are pruning eligible. VTP pruning does not prune traffic from pruning-ineligible VLANs. VLAN 1 is always pruning ineligible; traffic from VLAN 1 cannot be pruned so maybe its already allowed. so try: http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080890613.shtml#topic3 edit: this is what I remembered: quote:All switchports must be members of a VLAN, and, by default, it is VLAN 1. Because VLAN 1 was selected as the default VLAN for all switchports, it was also chosen to handle special traffic such as VLAN Trunking Protocol (VTP) advertisements, CDP, Port Aggregation Protocol (PAgP), or Link Aggregation Control Protocol messages (LACP). By default, in-band management interfaces such as sc0 are members of VLAN 1. nzspambot fucked around with this message at 09:07 on Jun 9, 2011 |
|
#
?
Jun 9, 2011 09:03
|
|
|
Anyone know of an equivalent command "sh int status" or even better "service unsupported-transceiver" for an ISR, specifically, a Cisco-3845? The scenario is I am taken a generic optic from a media converter, and plugging it directly into the router, for our mpls connection with Qwest. However, while the media converter sees the connection just fine, the 3845 does not. The SFP is certainly good, but I don't know if the ISR is recognizing the optic, or not. In anycase the link stays Down/Down. Can anyone shed some light on the correct set of commands to use? sh inv sh int gig0/0 transciever sh int status ? None of those work on an ISR: m3845a-slip#sh ver Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 12.4(21), RELEASE SOFTWARE (fc1)
|
|
#
?
Jun 10, 2011 06:42
|
|
|
copy usb0 bootflash *file name* *file name confirm* *copies file* *takes me back to console* I remove USB drive. KERNEL PANIC. D: D: D: Thank god a recopy and changing the config registers got it copied and loaded. That was hairy.
|
|
#
?
Jun 10, 2011 07:51
|
|
|
Powercrazy posted:Anyone know of an equivalent command "sh int status" or even better "service unsupported-transceiver" for an ISR, specifically, a Cisco-3845? igr-tg2#sh int gig0/1 GigabitEthernet0/1 is up, line protocol is up Hardware is PQ3_TSEC, address is e05f.b945.c381 (bia e05f.b945.c381) Description: xxxx MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is RJ45
|
|
#
?
Jun 10, 2011 09:37
|
|
|
I think there's a "show int capabilities" command.
|
|
#
?
Jun 10, 2011 12:47
|
|
|
Unable to rest right now, but what about "show controller <interface>"
|
|
#
?
Jun 10, 2011 14:59
|
|
|
m3845a-slip#sh controllers gig0/0 Interface GigabitEthernet0/0 (idb 0x64F404BC) Hardware is BCM1125 Internal MAC (Revision A3) Network connection mode is FORCE network link is down (UNKNOWN GBIC) Config is Auto Speed, Auto Duplex Selected media-type is SFP SFP type is unknown (type 0x21) Not bad. Anyway looks like this is some kind of GigE-PHY sfp, so the ISR can't use it. Basically I'm trying to take an optic from a media converter that is giving us MetroE, and plug it directly into the ISR. However the ISR doesn't recognize the optic, if I use a normal SMF GigE SFP, the ISR recognizes it, but I'll never get link, I assume because the framing/encapsulation is not ethernet. Maybe its metroE?
|
|
#
?
Jun 10, 2011 16:15
|
|
|
Quick Q. We have two ASRs that are each connected to one of two core network routers. We're currently using static routes between the cores and the ASR, however, this causes fail over issues. The ASRs receive full routes from Level 3 and partial from Cogent and XO. The ASRs advertise partial routes via BGP to the cores. We're wanting to setup a BGP Default Route between the ASRs and the Core so failover works automatically instead of requiring us to manually edit the static routes in case of failure. ASR1(config)# router bgp AS# ASR1(config-router)# neighbor *ip address 1* default-originate ASR2(config)# router bgp AS# ASR2(config-router)# neighbor *ip address 2* default-originate Is there anything I should do regarding the other advertised routes? Also looking into Reliable Static Route, but there seems to be some kinks that need to be worked out with it and BGP Default Route may be the better option.
|
|
#
?
Jun 10, 2011 16:32
|
|
|
Can your core routers take full tables?
|
|
#
?
Jun 10, 2011 16:38
|
|
|
I don't think so, but I can't say for certain. I do know that we got the ASRs specifically for any customer that wants to peer with us and receive full routes, and any customer that doesn't goes on the Core routers. Also, *ip address 1* and *ip address 2* are currently the loopbacks and not the IP for the physical interface, since all of our loopbacks are the peer addresses. This is not in production, just a mockup. Zuhzuhzombie!! fucked around with this message at 16:55 on Jun 10, 2011 |
|
#
?
Jun 10, 2011 16:52
|
|
|
It shounds like the core routers can't take full tables. If your ASRs have a routed path between them you should be fine in a failue scenario if you advertise defaults from both ASRs. This assumes you have a default route coming from your upstream providers as well.
|
|
#
?
Jun 10, 2011 17:00
|
|
|
Yup. Got that cleared out after L3's circuit died on us a while back and we found out Cogent wasn't advertising us a default route. I was worried about the routes we do send to the core being affected. Thanks for your advice!
|
|
#
?
Jun 10, 2011 17:06
|
|
|
Powercrazy posted:m3845a-slip#sh controllers gig0/0 I think you simply have a SFP that's not cisco compatible. Get a cisco-compatible SFP of the same media type and try again.
|
|
#
?
Jun 10, 2011 18:28
|
|
|
CrazyLittle posted:I think you simply have a SFP that's not cisco compatible. Get a cisco-compatible SFP of the same media type and try again. Well I'm not 100% positive of the correct layer2 framing. It's an SMF SFP, and I can plug a juniper SMF sfp in there with no issues but the link doesn't come up. Although the SFP is recognized.
|
|
#
?
Jun 10, 2011 18:51
|
|
|
Powercrazy posted:Well I'm not 100% positive of the correct layer2 framing. It's an SMF SFP, and I can plug a juniper SMF sfp in there with no issues but the link doesn't come up. Although the SFP is recognized. Ah I see. Hmmm.
|
|
#
?
Jun 10, 2011 18:53
|
|
|
I have a question for any network techs in this thread. I am looking for the following device: Ethernet network tap Gigabit speeds Provides PoE (NOT PoE pass-through) Has anyone seen such a device for under $500? I have seen a lot of gigabit network taps, but not many that can also provide PoE. I do a lot of VoIP troubleshooting and hate carrying around an old hub and a PoE injector, and I'm hoping to find one device that does both (and is gigabit to boot).
|
|
#
?
Jun 10, 2011 19:25
|
|
|
Gigabit PoE is a complicated and relatively new thing. It requires cooperation between the switch and the PoE device, in order to keep the power "pulses" on the right timing between the ethernet frames. for this reason the device you are looking for is difficult to create, and unlikely to be found for cheap.
|
|
#
?
Jun 10, 2011 19:36
|
|
|
Ugh I just spent 3 hours configuring a replacement CSS 11503 line by line from a backup of a running config (anyone whos configured these knows it just goes into full blown retard mode when you copy paste a config), just for the client to say "oh just swap the PCMCIA cards" since the certs were password protected and everyone forgot the passwords. I really wish the CSS series was more friendly like Kemps 
|
|
#
?
Jun 10, 2011 19:59
|
|
|
Powercrazy posted:Well I'm not 100% positive of the correct layer2 framing. It's an SMF SFP, and I can plug a juniper SMF sfp in there with no issues but the link doesn't come up. Although the SFP is recognized. Are you sure you have the correct wave lenghts on both sides? Does both sides come up if you loop them individually? (be a bit careful with this, use a attenuator if needed) Also check RX/TX, you never know 
|
|
#
?
Jun 10, 2011 20:41
|
|
|
nzspambot posted:from memory VTP is carried on VLAN1, you've pruned it out of your trunk, so maybe try adding it back in Problem resolved. After a week of dealing with the provider, they finally sent techs out to site C yesterday and discovered that they had some messed up config setting on their switch. It was set to strip off VLAN tags, which explains why I couldn't get my trunk to work. I wish they had listened to me on loving Monday when I told them that the problem was on their end, not too happy about wasting an entire week on this issue.
|
|
#
?
Jun 10, 2011 21:15
|
|
|
nex posted:Are you sure you have the correct wave lenghts on both sides? Does both sides come up if you loop them individually? (be a bit careful with this, use a attenuator if needed) Well I know the optic works in the media converter, but not in the router. In any case the LEC finally came out and replaced the Media Converter so now the link isn't bouncing anymore. code:
|
|
#
?
Jun 10, 2011 21:16
|
|
|
Ok, then I think the issue is as mentioned earlier that the ISR won't accept the SFP(but does not give the standard error messages.) Related to this: my favorite problem with this "feature" is 3rd party SFPs with duplicate serial numbers. Randomly disables one of the ports, yay.. Saw this 2 times from the same vendor, needless to say they are now banned from use.
|
|
#
?
Jun 10, 2011 21:47
|
|
|
We have switched to 100% Cisco optics because of weird poo poo like that. Yea it's more expensive, but budgetary decisions should be made on a device/capabilities level, and reliability isn't something to compromise on.
|
|
#
?
Jun 11, 2011 20:43
|
|
|
Powercrazy posted:We have switched to 100% Cisco optics because of weird poo poo like that. Yea it's more expensive, but budgetary decisions should be made on a device/capabilities level, and reliability isn't something to compromise on. Really? We use plusoptics (http://www.networkconnectors.com.au/) and never had a single problem. The place I used to work used agilstar and never had any issues either. I guess if you like throwing money away then that's cool!
|
|
#
?
Jun 12, 2011 06:55
|
|
|
Sometimes you have to use third party optics because Cisco's optics tend not to have quite the loss tolerance that some third party ones do. But sometimes you have to use Cisco's optics because your vendor who resells Cisco gear won't help you with issues if you're not using the Cisco optics they resell... EMC i'm looking at you.
|
|
#
?
Jun 12, 2011 07:04
|
|
|
ruro posted:Sometimes you have to use third party optics because Cisco's optics tend not to have quite the loss tolerance that some third party ones do. But sometimes you have to use Cisco's optics because your vendor who resells Cisco gear won't help you with issues if you're not using the Cisco optics they resell... EMC i'm looking at you. Most vendors I have worked with will not support an optics issue if it is not OEM branded. Even though most Cisco / Juniper optics are Finasar, if you ever have to RMA them, they will reject them. I know I'd rather not chance a 3rd party OC192 optic for $500, have issues, and still have to turn around and by the Juniper one for $1500 because Juniper will ultimately go "oh well you aren't using our optics, so we cannot help you"
|
|
#
?
Jun 12, 2011 21:16
|
|
|
routenull0 posted:Most vendors I have worked with will not support an optics issue if it is not OEM branded. Even though most Cisco / Juniper optics are Finasar, if you ever have to RMA them, they will reject them. Does this happen a lot for you guys? In my career I've probably seen like 3 bad optics and each one we've just replaced with the exact same type and it's worked fine.
|
|
#
?
Jun 13, 2011 07:01
|
|
|
abigserve posted:Does this happen a lot for you guys? In my career I've probably seen like 3 bad optics and each one we've just replaced with the exact same type and it's worked fine. It's not always the optics failing; TAC will see that you're using non-first party SFPs and then blame whatever issue you called in about on them.
|
|
#
?
Jun 13, 2011 07:10
|
|
|
madsushi posted:It's not always the optics failing; TAC will see that you're using non-first party SFPs and then blame whatever issue you called in about on them. This. I had fat fingered a PBR statement and since the counter for the route wasn't going up, it had to be the egress optics.
|
|
#
?
Jun 13, 2011 12:03
|
|
|
abigserve posted:Does this happen a lot for you guys? In my career I've probably seen like 3 bad optics and each one we've just replaced with the exact same type and it's worked fine. With all the transport I work on, swapping around optics is one of the first things we do, so we may RMA optics that are perfectly good, but it is just a standard procedure to rule stuff out. Over time, I've probably had 10 1Gbps SFPs go bad, but we are a lot more careful on the 10Gbps side, especially in the datacenters and make sure we use attenuators so we don't end up over powering stuff.
|
|
#
?
Jun 13, 2011 12:36
|
|
|
We were having HSRP flaps on our Edge and only one of the optics was non-cisco. So we RMAd the Cisco Optics and just bought a new Cisco optic and that fixed the problem. Was the problem definitely the non-cisco optic? No, but I do know that now we have all cisco and we aren't having the problem anymore. So that is good enough for me. Besides even Cisco optics are a trivial expense compared to the entire platform. Just a 6708 Line card is like 40K.
|
|
#
?
Jun 13, 2011 14:54
|
|
|
Not a Cisco-specific question, but I'm hoping a thread full of network pros might be able to help me out here We are upgrading our datacenter to 10G this summer, and Arista 7100T series looks like a winning proposition for racktop/access layer based on features and price. On paper they support everything we need, but I have zero experience with Arista and EOS, and was wondering if anyone here has any experiences with their boxes, especially in real-world deployments.
|
|
#
?
Jun 13, 2011 15:19
|
|
|
Powercrazy posted:Besides even Cisco optics are a trivial expense compared to the entire platform. Just a 6708 Line card is like 40K. This has been my thought all long as well.
|
|
#
?
Jun 13, 2011 16:15
|
|
|
Pussy Noise posted:Not a Cisco-specific question, but I'm hoping a thread full of network pros might be able to help me out here I looked heavily into Arista for out 10G deployment but had to back out since they are not Common Criteria, but you can setup a WebEX with the product group and they can get you into a system to play with. Their stuff is really nice and has a metric-ton of features. Their OS is a mimic of Cisco IOS in almost every way. I am pretty sure you can even take a cisco config and drop it over on the arista and it works for most of the switchport functions.
|
|
#
?
Jun 13, 2011 16:19
|
|
|
Pussy Noise posted:Not a Cisco-specific question, but I'm hoping a thread full of network pros might be able to help me out here No experience, but we had their sales guys in recently to tell us about their stuff. I was seriously impressed and would love to try the kit out. The capabilities and 10Gb density seems to blow the competition out of the water. The prices are really quite reasonable too!
|
|
#
?
Jun 13, 2011 17:09
|
|
|
What do you think of this? We tried to implement BGP Default Routes from our ASRs to our Core and this caused a routing loop some where. Currently, our two Cores share data through a trunk, and thus, see themselves as simply one huge switch. We have a 10 gig P2P between the two. Currently we're planning on switching the interface VLANS to be passive EIGRP interfaces so that the Cores see the P2P between each other and see that as "one hop" and thus route out of the BGP Default Route. My only concern with this would be whether or not in the event of a failure with the 10 Gig P2P data will pass over the trunk interface as well.
|
|
#
?
Jun 13, 2011 17:50
|
|
|
Zuhzuhzombie!! posted:What do you think of this? What do you mean as one big switch? Like VSS? You're changing the 10gbit ptp link into a routed link? Your ibgp speakers need to be fully meshed or rely on a route-reflector to avoid screwball behavior. If you're simply trying to get traffic to your edge, you could consider injecting a default backwards from your ASRs, as opposed to running BGP over the top of your IGP. Pros and cons. Unrelated question for everybody: who has looked at Talari networks equipment?
|
|
#
?
Jun 13, 2011 18:35
|
|
|
|
| # ? May 28, 2024 04:22 |
|
|
Currently the cores are linked via etherchannel. We want to put in a 10 gig P2P as the main way the two switches send traffic. We're hoping to save a little convergence time. http://packetlife.net/blog/2011/jan/24/convergence-delays-svi-vs-routed-interface/
|
|
#
?
Jun 13, 2011 18:51
|
|