|
nzspambot posted:oh I love those, there are some terrible terrible ones which makes me wonder wtf they were thinking when they allowed them through I ran into some stupid next-hop bug on EX 4200's that caused them to refuse to forward the traffic even though the config was correct. I had to update to JunOS 11.1 to fix it. If you get stuck I can try and find my notes but I remember seeing a bunch of j-net posts on how to leak routes between VRF's and you can probably Google those easily.
|
#
?
Feb 8, 2012 09:17
|
|
|
|
| # ? May 14, 2024 05:27 |
|
|
Zuhzuhzombie!! posted:For the time being I've turned off ip unreachables on the interfaces heading out to our ASRs. Where as IP input has been hovering around 40% all day, now it's down to 15%. Dunno if that's a coincidence or not. Coincidence. Back up to 50% IP Input utilization. EDIT May have tracked it down. We have HSRP setup for a big time customer and on their vlan and SVI there's no IP caching, CEF is turned off, etc. Gonna see if that's by design and if I get the go ahead gonna see about getting fast switching and the like turned on. EDIT EDIT Found it. NetDr is a drat useful utility. Zuhzuhzombie!! fucked around with this message at 17:40 on Feb 8, 2012 |
|
#
?
Feb 8, 2012 16:02
|
|
|
Ninja Rope posted:I ran into some stupid next-hop bug on EX 4200's that caused them to refuse to forward the traffic even though the config was correct. I had to update to JunOS 11.1 to fix it. If you get stuck I can try and find my notes but I remember seeing a bunch of j-net posts on how to leak routes between VRF's and you can probably Google those easily. this would be on a SRX, I need 11.1+ for ST endpoints in a VR anyway. But almost there I think looks like static routes might have to work for me. And leak the interface route as well. Zuhzuhzombie!! posted:CEF is turned off, etc. Sadistic nzspambot fucked around with this message at 20:29 on Feb 8, 2012 |
|
#
?
Feb 8, 2012 20:27
|
|
|
Still not sure why CEF is turned off at the SVI. It's enabled globally.
|
|
#
?
Feb 8, 2012 21:04
|
|
|
Is the SVI involved in any NAT or high touch type features? Disabling CEF tends to be a fix for bugs.
|
|
#
?
Feb 8, 2012 21:18
|
|
|
tortilla_chip posted:Is the SVI involved in any NAT or high touch type features? Disabling CEF tends to be a fix for bugs. or disabled for debugging and forgotten about
|
|
#
?
Feb 8, 2012 23:59
|
|
|
tortilla_chip posted:Is the SVI involved in any NAT or high touch type features? Disabling CEF tends to be a fix for bugs. IIRC it depends on the SUP you are talking about but typically it's handled in HW. The problem then being recirculation on the back plane which leads to reduced forwarding rate.
|
|
#
?
Feb 9, 2012 03:47
|
|
|
Welp, being that this is our lovely Cisco thread, I figured I'd share that we recently received our UCS platform, fabric interconnects, and 5ks. We'll see how it all goes down. We ended up, and quite at the last minute, having to preserve our investment in fibrechannel because of a legacy vsan requirement in combination with our new VNX not being able to do both FCoE and fibrechannel simultaneously. Dragging all of this back to a Sup720 6500 core with 6704 10gig cards (with little itty bitty baby buffers!), it'll be an interesting experience.
|
|
#
?
Feb 9, 2012 07:06
|
|
|
Tremblay posted:IIRC it depends on the SUP you are talking about but typically it's handled in HW. The problem then being recirculation on the back plane which leads to reduced forwarding rate. WS-SUP720-3B 2 ports Supervisor Engine 720 Rev. 5.3 This is the SUP. No NAT on this 6500. This is an HSRP SVI that handles high amounts of bandwidth only. What would be a High Touch Type feature?
|
|
#
?
Feb 9, 2012 15:46
|
|
|
High touch features take the slow forwarding path becuase they need to be punted to the CPU. Typically they involve some sort of complicated packet rewrite so NAT, IPSec, PBR, tunneling in various flavors. If they are CEF switched, there are often a variety of caveats with regard to how the feature can be implemented.
tortilla_chip fucked around with this message at 16:58 on Feb 9, 2012 |
|
#
?
Feb 9, 2012 16:37
|
|
|
Zuhzuhzombie!! posted:WS-SUP720-3B 2 ports Supervisor Engine 720 Rev. 5.3 720 supports NAT in HW, I'm pretty sure. Well, HSRP I think would be slowpath since the heartbeats are destined to the control plane. jwh posted:Welp, being that this is our lovely Cisco thread, I figured I'd share that we recently received our UCS platform, fabric interconnects, and 5ks. My god man. Where has your sense of adventure gone?
|
|
#
?
Feb 9, 2012 17:14
|
|
|
We've got a combination of bits we've been trying: 7606 chassis 6506 chassis 3x sup720 6708 blade I've found that with any of the supervisors in the 6500, the 6708 works in any slot. With one of the supervisors in the 7600, plugging the 6708 into any slot powers the chassis off - so I assume that supervisor is bad. With either of the other 2 supervisors the 6708 works fine in any slot of the 7600 EXCEPT slot 1 - in that it gives ASIC-DUMP errors. I believe this is using 12.2 SXJ. Does anyone know why it would have these errors in just one of the slots? Where does this suggest the error lies? Sorry if there aren't enough details, I'm the one who's got this job because I need to learn about the hardware.
|
|
#
?
Feb 9, 2012 17:23
|
|
|
The whole chassis powers off? Or just the linecard? sh power sh diagnostic events sh diagnostic sanity
|
|
#
?
Feb 9, 2012 17:37
|
|
|
If the SUPs work in the 6500 with no issues, but not in the 7600, that tells me you have a bad backplane in the 7600. As far as why one of the sups takes a dump compared to the other two, you've got me. But I'm still leaning towards an issue with the actual 7600 Chassis.
|
|
#
?
Feb 9, 2012 17:38
|
|
|
I included the powering off bit in case it was of use - unfortunately we got rid of that supervisor today. It only exhibited that powering off problem when I plugged the 6708 in - the entire chassis powered off, not just the line card. So we assume that is a bad supervisor. Since we got rid of that supervisor it still leaves us with the problem about slot 1 though. I wasn't involved with the previous tests, but I believe that it exhibited a similar problem in several slots of another 7606 too - I am not certain if it was several slots though or just the top 1. Sorry, I know it's nebulous. Also, 6704s work fine in the top slot. Unfortunately we don't have another 6708 to test with as they've had to be put into production. Basically it seems like we have data that simultaneously seems to suggest one of several things: 1. That it's a problem with that particular chassis (but it had the problem in another, too - and we sent the chassis off, the repair people couldn't find anything wrong with it at all) 2. That it's a problem with that line card (but it works fine in the 6500) 3. That it's a problem with 7600s (but why?) It was briefly suggested that it may be related to the version of rommon, but I don't know anything about that to suggest whether that's plausible or not.
|
|
#
?
Feb 9, 2012 18:05
|
|
|
Can you take a look at the backplane of the 7600 with a flashlight? We once had an issue where the pins on the backplane were bent, and killed any linecard inserted in that particular slot. Fun TAC case.
tortilla_chip fucked around with this message at 22:39 on Feb 9, 2012 |
|
#
?
Feb 9, 2012 18:19
|
|
|
tortilla_chip posted:Can you take a look at the backplane of the 7600 with a flashlight? We once had an issue where the pins on the backplane were bent, and killed any linecard insterted in that particular slot. Fun TAC case. We inspected the last 7600 and it was fine, I'll inspect this one tomorrow. If this problem hadn't happened in the last 7600 chassis and was only happening in this one then I wouldn't even bother checking - I'd just assume it was this. But I suppose it is possible that they were bent in both.
|
|
#
?
Feb 9, 2012 18:48
|
|
|
Tremblay posted:720 supports NAT in HW, I'm pretty sure. It does, uses netflow tcam so you can't do netflow and NAT at the same time.
|
|
#
?
Feb 9, 2012 19:14
|
|
|
I've done some more testing on my problem and this is what I've found: We can get other blades (6704, a couple of different gigE blades) working in slot 1 of our 7600. As soon as the 6708 is plugged into any other slot, the blade in slot 1 crashed giving the errors mentioned before. However, the 6708 will still work in the other slot at this point. Edit: We've sent the 6708 off for repair. Sir Sidney Poitier fucked around with this message at 17:59 on Feb 10, 2012 |
|
#
?
Feb 10, 2012 11:28
|
|
|
I am trying to figure something out. I have a remote site that I need to provide some redundancy to for their vpn connectivity. I know for a crypto map you can set a secondary peer ip to enable failover for the endpoint. WHat if I want to provide failover for the internet connection at the remote site as well though?
|
|
#
?
Feb 10, 2012 21:44
|
|
|
Quick question. Lemme see what you guys think. Got a customer who currently has a circuit with us and between my network and his the circuit rides my company's Calix network as transportation. His current setup is that we have a /28 routed to a 3750 from our core. On that 3750 we have the first usable IP on an SVI, have an interface on that SVI, and cat5 from that interface to the Calix transport. Customer has the second usable IP from that /28 for his side of the P2P. Everything works fine. I want to "clean" this up a bit as he was originally placed on hardware we use for the general public and not businesses. The new solution is similar. On the same Core I placed that same first usable IP from the /28 on an interface. That interface was cabled to a 3750 and the int on the 3750 was placed in a VLAN. That VLAN is allowed on a trunk that carries the circuit to the same Calix transport. However, it did not work. I assumed maybe there was an issue routing the subnet. For example: ip route 80.1.1.1 255.255.255.240 80.1.1.2 I did not advertise this range in my core since it belongs to the customer. I didn't think that would actually work and may have been the issue. So. Attempt number 2: Customer has an ONT that hands off the transport. That ONT has two rj45s on it. So I keep the same setup for the new solution but instead I also use a /30 (we'll say 66.1.1.0 /30). First half of the /30 on the core interface, second half on customers outside interface, and I was gonna route the 8.1.1.0 /28 subnet to his side of the P2P. Customer plugs a laptop into the second interface on the ONT with his side of the P2P and he can browse the net, ping, etc fine. All day. So he makes some changes on his ASA. Changes his default gateway to my side of the P2P and changed the IP on his outside interface to his side of the P2P. He has NAT statements for the /28 range and didn't make any changes to them. Figured it was unnecessary. ip route 8.1.1.0 255.255.255.240 66.1.1.2 interface Ethernet0/0 nameif outside security-level 0 ip address 80.1.1.2 255.255.255.240 Changed to 66.1.1.2 255.255.255.252 _________________________________ route outside 0.0.0.0 0.0.0.0 80.1.1.1 1 Changed to 66.1.1.1 (where 80.1.1.1 and 6.1.1.1 are my side, old and new respectively) Problem is, I couldn't ping his ASA after he made these changes. He said he may need to reboot, and did, but I sitll could not ping and he could not get out. If he placed a laptop back on that interface with the right IPs he could get out just fine. So... I'm at a loss as to what I do now. I'm not super familiar with ASA's just yet and I know this customer inherited a really weird situation on his end that caused problems in the past. The circuit is obviously working. Any suggestions are appreciated. EDIT Okay that wasn't quick. I hope I was clear enough. Thanks again! Zuhzuhzombie!! fucked around with this message at 23:24 on Feb 10, 2012 |
|
#
?
Feb 10, 2012 22:45
|
|
|
Zuhzuhzombie!! posted:SNIP Is the routed interface or SVI for the customer directly attached to the ASA or is it one or more layer 2 segments away? I'm wondering the ARP entry is invalid. Tremblay fucked around with this message at 00:53 on Feb 11, 2012 |
|
#
?
Feb 11, 2012 00:50
|
|
|
I have a FWSM module in a 6513 that has an allow any/any firewall rule in one of the contexts that I'd like to get rid of. Logging is enabled and several hundred connections per second are hitting that rule at the bottom of the access list. My idea was to put more specific rules above it with logging disabled until there's no more traffic logged. I'm familiar enough with the network and apps that once I see a syslog entry I can write an effective rule. However, this does not appear to be working -- the traffic is still logged. What are some "correct" ways to do this?
|
|
#
?
Feb 11, 2012 06:29
|
|
|
You're sure that the rule you wrote is correct and it's not at the end of the ACL?
|
|
#
?
Feb 11, 2012 15:36
|
|
|
Tremblay posted:Is the routed interface or SVI for the customer directly attached to the ASA or is it one or more layer 2 segments away? I'm wondering the ARP entry is invalid. The routed interface on either solution goes through multiple layer 2 segments on it's way to the customer. I had thought about ARP entries myself. Would a simple clearing of the arp cache on that interface Cisco side work? I dunno if its applicable Calix side since Calix is L2 only.
|
|
#
?
Feb 11, 2012 16:48
|
|
|
falz posted:You're sure that the rule you wrote is correct and it's not at the end of the ACL? It seems like the "allowed" connection logs (setup/teardown, severity 6) are global. I don't know how to enable/disable them per rule.
|
|
#
?
Feb 11, 2012 21:46
|
|
|
KS posted:It seems like the "allowed" connection logs (setup/teardown, severity 6) are global. I don't know how to enable/disable them per rule. Login with ASDM and look at the hit count column on the right. It will let you know if the rule is being used or not.
|
|
#
?
Feb 12, 2012 01:22
|
|
|
CaptainGimpy posted:Login with ASDM and look at the hit count column on the right. It will let you know if the rule is being used or not. Depending on the SW version on the FWSM those counters can be inaccurate due to the HW arch. Do you guys have a Netflow collector or beefy capture box?
|
|
#
?
Feb 13, 2012 18:48
|
|
|
Zuhzuhzombie!! posted:The routed interface on either solution goes through multiple layer 2 segments on it's way to the customer. Well I'd look at the arp table first to make sure that there was an offending entry.
|
|
#
?
Feb 13, 2012 18:48
|
|
|
Tremblay posted:720 supports NAT in HW, I'm pretty sure. My sense of adventure went EOL a long time ago!
|
|
#
?
Feb 13, 2012 18:50
|
|
|
6509 fa cabled to a 3750 gig e. 3750 is trunked to ATT transport. When using the exact same setup in all of my tests I was able to clearly see a bandwidth limitation via iPerf output AND PRTG graph. Graph would flatten/plateau at approx 50 meg with srr queue bandwidth limit 50 set. When I put the srr queue command on a customer's interface but have it set to 10 it doesn't seem to be working. I keep seeing customer push over 10meg. Spikes, no plateau. The only difference is that customer is transported from ATT cloud and my tests are to my laptop. Interface from same core to 3750, core and laptop facing ints on 3750 in the same vlan. Works great with my laptop, doesn't work at all with customer. Both test int and customer in are switchport access vlan ###. Related but not. policy-map test class access-match police rate 54600000 bps burst 400000 bytes conform-action drop Placing this on the core interface itself kills all traffic. Int stays up but can not get anything across. access-match just points to an access list that permits any any. I need a good QoS/rate limit/policing primer. Open to anything, at this point, as I can't get poo poo to work some days, some stuff doesn't work as I understand it, etc. Took a GK switching course and not even the instructor could adequately tell me how in bloody hell I'm supposed to setup something to limit bandwidth. 
Zuhzuhzombie!! fucked around with this message at 19:34 on Feb 15, 2012 |
|
#
?
Feb 14, 2012 20:11
|
|
|
What are you trying to do, limit customer bandwidth to 10 megabits?
|
|
#
?
Feb 15, 2012 19:41
|
|
|
Zuhzuhzombie!! posted:policy-map test Try this: policy-map test class class-default police rate 54600000 bps burst 400000 bytes conform-action transmit exceed-action drop Edit: removed line break in policer statement. ruro fucked around with this message at 00:34 on Feb 16, 2012 |
|
#
?
Feb 16, 2012 00:11
|
|
|
jwh posted:What are you trying to do, limit customer bandwidth to 10 megabits? Essentially. 10 meg, 20, etc. Whatever the customer wants. We were using policy maps with a defined cir, be, and bc rate. However, we kept encountering issues where some customers who had it provisioned on their circuit would suddenly have incredibly reduced bandwidth. No changes, as far as I am aware, took place on our core on some of the days we've had customers call in with bandwidth issues. Removing the policy map with cir, bc, and be rates "solved" the issue for them, so I've tasked myself with looking into it and an alternative. Will definitely test yours today, ruro. Thank you!
|
|
#
?
Feb 16, 2012 16:07
|
|
|
ruro posted:Why are you dropping packets that conform to the policer? You should be dropping packets that exceed it. You also don't need a class-map if you just want to match all traffic, you can use the special "class-default" for that. This is pretty much how we do it on our network. Small CLEC in the Midwest.
|
|
#
?
Feb 16, 2012 16:16
|
|
|
Should I consider TC timing with that policy? Also still curious as to why srr queue works on test circuit but not customer circuit. EDIT Just ran both: srr-queue bandwidth shape 5 0 0 0 srr-queue bandwidth share 50 50 1 1 On the interface and ran iPerf for egress and ingress traffic shaping. No change. Interface was wide open passing full bandwidth. EDIT srr-queue bandwidth shape 5 5 5 5 This seems to be working where as 5 0 0 0 did not. show mls qos interfaces queue shows that the int is in "queue set 1", which I assumed was the first digit. changing to 10 10 10 10 has also limited me down to 10meg. Good deal so far. My only concern is, as with the limit command simply not working, what will happen when I apply it to a customer? Zuhzuhzombie!! fucked around with this message at 20:43 on Feb 16, 2012 |
|
#
?
Feb 16, 2012 17:05
|
|
|
Zuhzuhzombie!! posted:Should I consider TC timing with that policy? On a 3750/3560 there are four egress queues with a queueing strategy known as 1p3q3t. This stands for 1 priority queue, 3 srr queues, and 3 threshold levels in each srr queue. The priority queue can also be used as an srr queue, which is likely how it is configured on your customer's interface. Inside each queue there are three thresholds which can have packets mapped to them to instruct the switch to tail drop packets associated with these thresholds when the queue's memory buffer reaches a certain threshold. There are default mappings that enqueue frames into each of the queues against certain thresholds depending upon Class of Service value set in the frame header. srr-queue bandwidth shape/share <queue 1> <queue 2> <queue 3> <queue 4> control the behavior of each of the queues, and any shape settings override share settings. Share is used to indicate the relative importance of network traffic in a queue and controls how often that queue will be serviced by the egress queue to hardware queue scheduler. Shape instructs the switch to transfer network traffic from a queue as soon as possible and use a maximum of x% of total interface bandwidth. So the reason srr-queue bandwidth shape 5 0 0 0 didn't work is because the vast majority of your traffic is likely marked with a CoS value of 0, which doesn't go into the first queue by default (although I can't remember off the top of my head which queue it goes into, Google should help), and a value of 0 for the other queues instructs the switch to use the shape configuration, and as almost traffic is going into one egress queue it is able to use 100% of available interface bandwidth. srr-queue bandwidth shape 10 10 10 10 should work, as long as your customer's switch is configured to not trust incoming CoS values on its other ports if your customer is using QoS in their network. Beware that the switch will set routing protocols etc to CoS 6 automatically so you might want to make sure you map all CoS values to a single queue: mls qos srr-queue output cos-map queue <queue number> threshold <threshold number, I suggest using 3 here as by default it will tail drop at 100% buffer utilization> 0 1 2 3 4 5 6 7. Finally I haven't tried using any of these commands without mls qos enabled, so that might be required on your customer's switch. And obviously test all this to ensure the behavior is what you want. Edit: Just checked on the default CoS mapping for CoS 0. It's mapped to queue 2 threshold 1, which is why srr-queue shape 5 0 0 0 didn't work. Edit edit: Forgot to mention that all of this configuration is egress only. You will need to control the throughput to your customer's switch on your device. ruro fucked around with this message at 01:11 on Feb 17, 2012 |
|
#
?
Feb 17, 2012 00:54
|
|
|
Good deal. This helps tremendously. Thank you! EDIT Follow up question. What if my customer doesn't have QoS or srr-queue set on their edge device? I did all of my testing on 3750s with and without global mls qos applied. EDIT Testing with policy-map test class class-default police rate 42000000 bps burst 300000 bytes conform-action transmit exceed-action drop Expecting approx 40mb of traffic, but barely got over 20. Changing it as iPerf was running resulted in no change at all. policy-map test class class-default police rate 60000000 bps burst 400000 bytes conform-action transmit exceed-action drop Is what I changed it to, but no difference. service-policy output test - on interface Zuhzuhzombie!! fucked around with this message at 21:10 on Feb 17, 2012 |
|
#
?
Feb 17, 2012 15:28
|
|
|
There's nothing wrong with your policer configuration other Edit: I'm assuming that the policer is on your 6500? To determine your burst rate for an ethernet network on a 6500 use the following formula: burst = whichever is greater out of: (<desired rate in bps> * 0.00025) or (1518 * 8) So for a police rate of 42000000bps: burst = which ever is greater out of: (42000000 * 0.00025) or (1518 * 8) ! 1518 assumes your MTU is set to 1518 burst = which ever is greater out of: (10500) or (12144) burst = 12144 bytes ruro fucked around with this message at 23:30 on Feb 17, 2012 |
|
#
?
Feb 17, 2012 23:10
|
|
|
|
| # ? May 14, 2024 05:27 |
|
|
MTU is 1500. What should I tailor most burst rates to be?
|
|
#
?
Feb 20, 2012 17:40
|
|