Re: [c-nsp] Wierd MPLS/VPLS issue
On Wed, Nov 23, 2016 at 12:04:35PM +, Nick Hilliard wrote: > Simon Lockhart wrote: > > It looks like the Nexus 92160YC-X is spotting the 4 or 6 there, assuming > > it's > > an IPv4 or IPv6 header next (Wireshark makes exactly the same incorrect > > assumption!), trying to decode it, and failing (because it's actually an > > Ethernet II header), and then fails to forward the packet. > > wouldn't be the first time a vendor messed this up: > > > https://www.nanog.org/meetings/nanog57/presentations/Tuesday/tues.general.SnijdersWheeler.MACaddresses.14.pdf Small correction: Juniper does check if packet starting with '4x:' is indeed ipv4 packet and falls back to 'outer' ethernet + mpls hash if this check fails. As a result, all eompls traffic to such address will be forwarded to the single link of aggregate interface and may cause congestion on this link despite there are plenty capacity on other links, but at least this does not lead to heavy reordering.. ___ 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
On Sat, Jan 23, 2016 at 01:06:12PM +0600, Victor Sudakov wrote: > 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? Dirty trick is to run MPLS over GRE. You shall never do this, but sometimes there are no other options :( MTU issues can be avoided by the means of fragmenting GRE packets itself: GRE is actually "GRE over IP" and IP packets can be fragmented and reassembled. Of course this means that tunnel ingress router must be able to fragment MPLSoGREoIP if it exceeds link MTU, and that tunnel egress router must be able to reassemble GRE thus restoring original MPLS frame. Not sure if it can be done with Cisco, with Juniper MX it's possible since JunOS 14.2. ___ 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] Peering + Transit Circuits
On Tue, Aug 18, 2015 at 08:29:31AM -0400, Tim Durack wrote: Question: What is the preferred practice for separating peering and transit circuits? We are using option 3 (QoS/QPPB) with some modifications: - being a Juniper shop, we don't have to mess CoS :) - customers are very unhappy when you blackhole their traffic :( So, instead of dropping packets at ingress, we are trying to find if there is any (less-specific) route pointing to customer and dropping traffic only when there are no such routes. To achieve that: customer's routes installed not only to global table, but also in semi-transparent vrf with exits over customer's interfaces only. Fraudulent traffic is directed to this vrf and either finds it's way to customer (when your peer is just not able to hold full-view with all specifics and uses aggregate routes for routing) or gets dropped (when your peer points default route to you...). Well, there is a potential for suboptimal routing in this scenario: your customer announces /16 and their branch office announces /24 to your competitor. Fraudulent traffic to /24 will be forwarded via aggregate route first, and then may re-enter your network to reach destination (traffic from a customer is [mostly] always legitimate, no chance for routing loops), but our practice shows no complaints (yet?). PS: as far as I know, most networks use option 4 (do not worry). 1. Terminate peering and transit on separate routers. 2. Terminate peering and transit circuits in separate VRFs. 3. QoS/QPPB ( https://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf ) 4. Don't worry about peers stealing transit. 5. What is peering? Your comments are appreciated. -- ___ 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] Nightmare for load balancing of L2VPN traffic on CRS (traffic from ME3600)
On Wed, Apr 15, 2015 at 10:50:14PM +0200, Daniel Verlouw wrote:
right, both trio and asr9k can do lag/ecmp balancing based on payload
inspection to some degree, but it's complicated and hacky.
getting offtopic, but wondering what you mean with complicated and
hacky about the load balancing algo on Trio?
Trio hash includes;
- upto 5 labels
- ipv4/v6 payload contents (and yes, it checks the packet' length to
avoid the 4 or 6 DMAC issue)
... and no, it does not revert back to ethernet parsing when DMAC starts
with 4x: or 6x: and length does not match :(
Run into this issue yesterday, PW with single DMAC 6x:... was not
balanced across aggregated ports at LSR at all. JunOS: 11.4R9.
On the other hand, this issue is rare enough to be happy with load-balancing
in most cases.
- for ethernet pw it can skip upto 2 vlans and still include its
ipv4/v6 payload (if any)
For our traffic mix (ymmv), this results in near-perfect load
balancing for PWs, without FAT.
My take on it is that FAT is a hack to cope with ASIC designs that
can't do proper deep inspection.
(granted, other JNPR platforms can't do the fancy Trio tricks).
DPC-based MX'es can do load-balancing based on MPLS payload too:
snar@RT show configuration forwarding-options hash-key
family mpls {
label-1;
label-2;
payload {
ether-pseudowire;
ip;
}
}
___
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] AToM/EoMPLS LDP on Sup2/MSFC2/PFC2
On Sun, Sep 19, 2010 at 11:26:10AM -0400, Jason Lixfeld wrote: I'm looking to potentially use a Sup2 based 6500 as a AToM/EoMPLS PE/LER with customers terminating on various X6248, X6348, X6516 and X6408A ports. Possible? Not with these cards. You need some OSM's connected to core to be able to run MPLS on Sup2-based 65xx. I think these cards can be found on ebay for cheap, but then please keep in mind that while it will work - MPLS is not officially supported on Sup2, and there is a reason for that: MPLS (and IPv6) is done in software on this platform, so you will not be able to push more than ~1Gbit of MPLS traffic through.. So, upgrading Sup2 to Sup720 (with power-supplies and fans upgrade) may be more future-proof idea. In a perfect world, port based and VLAN based (the implication being that interworking support would need to be there too), in either case, the far end of the VC would be to a NPE-G1 flavored PE/LER of some sort. Port-based EoMPLS is not possible with Sup2 at all. However, in real life I never experienced problems terminating on Sup2 SVI VC's coming from port-based equipment (Sup720 or even different vendor). Google has shown me configuration example of a Sup2 doing SVI based EoMPLS, but that confuses the heck out of me because I know that, for example, in Sup720 land, you can't do SVI based unless you have an ES card or a SIP. If this is true and it does actually work, would this just be the difference between the Sup2 doing it in software vs. the Sup720/ES|SIP doing it in hardware? OSM is the hardware required in case of Sup2. -- In theory, there is no difference between theory and practice. But, in practice, there is. ___ 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] VTY PROBLEM
On Wed, Jun 23, 2010 at 01:44:39PM +0500, Aftab Siddiqui wrote: same issue here, Line User Host(s) Idle Location 194 vty 0idle19w2d 201.240.122.39 195 vty 1idle17w1d 41.196.124.99 196 vty 2idle16w4d 94.50.81.100 197 vty 3idle17w0d 59.182.12.209 198 vty 4idle 2w5d 189.27.86.223 199 vty 5idle 1w0d 41.178.188.74 Platform 1841 IOS: c1841-advipservicesk9-mz.124-13b.bin clear tcp line vty 0 The above command doesn't work. You may try to 'clear tcp tcb N', as described here: http://www.gossamer-threads.com/lists/cisco/nsp/98894 Regards, Aftab A. Siddiqui On Wed, Jun 23, 2010 at 1:32 PM, bha Qaqish bha.qaq...@nitc.gov.jo wrote: I tried it. Same thing , the session still exist Eng. Bha Qaqish -Original Message- From: Pepa Verich [mailto:josef.ver...@cesnet.cz] Sent: Wednesday, June 23, 2010 10:35 AM To: bha Qaqish Subject: Re: [c-nsp] VTY PROBLEM Did you try command clear TCP line vty X ? Key word TCP is very important. Pepa Dne 23.6.2010 7:37, bha Qaqish napsal(a): I did it several times but did not do anything Eng. Bha Qaqish -Original Message- From: David Prall [mailto:d...@dcptech.com] Sent: Tuesday, June 22, 2010 11:13 PM To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] VTY PROBLEM Do a who and see who has a hold of it. Then put an acl on the ingress interface so deny it in and out. Your exec-timeout should eventually kick it off. If not, at least they won't be able to connect again. I'd also do clear line 3 and confirm a couple of times. David -- http://dcp.dcptech.com -Original Message- From: bha Qaqish [mailto:bha.qaq...@nitc.gov.jo] Sent: Tuesday, June 22, 2010 3:17 PM To: David Prall; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] VTY PROBLEM It's the same , not cleared Eng. Bha Qaqish -Original Message- From: David Prall [mailto:d...@dcptech.com] Sent: Tuesday, June 22, 2010 10:14 PM To: bha Qaqish; 'Jeff Wojciechowski'; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] VTY PROBLEM Should be clear line 3 David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of bha Qaqish Sent: Tuesday, June 22, 2010 2:48 PM To: Jeff Wojciechowski; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] VTY PROBLEM Yes I can see the session in this command , and when I make the clear line vty 3 for example , its not cleared. It still exist in the show command Eng. Bha Qaqish -Original Message- From: Jeff Wojciechowski [mailto:jeff.wojciechow...@midlandpaper.com] Sent: Tuesday, June 22, 2010 9:44 PM To: bha Qaqish; cisco-nsp@puck.nether.net Subject: RE: VTY PROBLEM Can you see the session using show line and then clear line X (where X= line number of stuck VTY session)? -Jeff -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp- boun...@puck.nether.net] On Behalf Of bha Qaqish Sent: Tuesday, June 22, 2010 1:27 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] VTY PROBLEM Dear I have a 7206 VXR WITH npeg2, there is a problem, there is a telnet vty sessions that stuck , I can not clear it , its stuck for 70 weeks , I can not restart the router cause we are an ISP, so how could I clear the sessions , I have a --- exec-timeout 60 0 --- on the vty. Please help ASAP BR Eng. Bha Qaqish * ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list
Re: [c-nsp] Inter-AS EoMPLS/VPLS
___ 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] C7600 power allocation
On Mon, Mar 30, 2009 at 11:51:43AM +0300, Dmitry Kiselev wrote: Hello! Could anybody explain me how exactly IOS choise which module to disable if system run in combined power mode and one of power inputs failed? http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/pwr_envr.html#wp1020384 However, if one power supply fails and there is not enough power for all of the previously powered-up modules, the system powers down those modules. Could I do some pre-configuration to point IOS to modules less critical for me? As per this letter, http://puck.nether.net/pipermail/cisco-nsp/2006-March/028767.html you can achieve this placing less critical modules in highest numbered slots and more critical - to lowest. ___ 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] 6513 SVI issues with SXH4 and SXI SUPs WS-SUP720-3BXL
On Tue, Jan 13, 2009 at 01:49:30PM -0500, Manuel Mar?n wrote: Hi Phil Attached are the SVI and interface configs #TRUNK TO CISCO 3750 interface GigabitEthernet6/24 description Barrancas switchport switchport trunk encapsulation dot1q switchport trunk native vlan 1000 mls qos vlan-based no cdp enable end #SUBint configured for EoMPLS interface GigabitEthernet2/2.578 encapsulation dot1Q 578 xconnect 172.16.10.2 4505 encapsulation mpls service-policy input 2Mbps service-policy output 2Mbps end interface GigabitEthernet2/2.576 encapsulation dot1Q 576 xconnect 172.16.10.4 4501 encapsulation mpls end #SVIS (Most of the have a policier and an access-list attached) interface Vlan102 description Victory Packaging [Voip] ip address 10.10.1.73 255.255.255.252 ip access-group Proteccion-VoipMngt out service-policy input 2Mbps service-policy output 2Mbps end Anyone else has experience running MUX-UNI with cisco 6500s or with a similar issue? We're running MUX-UNI on 6509's since SRA1 IOS, now some of new installations running SXH3[a]. No issues like yours. Those new installations usually have 30-50 vc's configured... PS: if MUX-UNI is required feature - you may try to downgrade to SRA7.. Thanks -Original Message- From: Phil Mayers [mailto:p.may...@imperial.ac.uk] Sent: Tuesday, January 13, 2009 4:36 AM To: Manuel Mar?n Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 6513 SVI issues with SXH4 and SXI SUPs WS-SUP720-3BXL Manuel Mar?n wrote: Hi, We are experiencing a weird issue with a cisco 6513 with either SXH or SXI software version. We have some SVI interfaces and a couple of trunks ports 802.1Qs connected to other ciscos 3750s. everything seems to be working but suddenly we get the following error and all SVIs change to administratively down. We can't downgrade to SXF because we have to use the MUX-UNI feature in order to use sub interfaces in a switch port. Jan 13 02:51:04.630 MST: %PM-SP-3-INTERNALERROR: Port Manager Internal Software Error (pm_vlan_port_forward_gbitlist_find_first(vd) == -1: ../switch/pm/pm_vlan_sm.c: 504: vlan_invalid_action) -Traceback= 40F0CC34 40F6E3CC 40698CB4 40F6E7BC 40F87BF8 40F84BE0 40F59780 40698CB4 40F5ECEC 40F436AC 41099040 40ACD52C 40AD41E8 413F3278 40AD33E4 40AD2C08 Jan 13 02:51:04.630 MST: %PM-SP-3-INTERNALERROR: Port Manager Internal Software Error (!pm_vlan_port_forward_gbitlist_test(vd, pd-globalNumber): ../switch/pm/pm_vlan.c: 1372: pm_vlan_rem_port) -Traceback= 40F0CC34 40F63C18 40F87C18 40F84BE0 40F59780 40698CB4 40F5ECEC 40F436AC 41099040 40ACD52C 40AD41E8 413F3278 40AD33E4 40AD2C08 40ACF674 40AD0120 Jan 13 02:51:04.630 MST: %PM-SP-3-INTERNALERROR: Port Manager Internal Software Error (pm_vlan_port_forward_gbitlist_find_first(vd) == -1: ../switch/pm/pm_vlan_sm.c: 504: vlan_invalid_action) That's a traceback, so you want to open a TAC case. If you could show more config i.e. of the gig ports as well it might give a hint, but if I had to take a wild guess I'd say it's a bug in the MUX-UNI. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] EoMPLS VC up on one side, not on the other.
On Sun, Nov 16, 2008 at 07:39:28AM +0800, Mark Tinka wrote: I seem to remember that there is a knob in recent SR* IOS trains that permits you to ignore MTU mismatches, but I have forgot the details - Ytti will know all the details (how to configure it plus availability). You might want to check this out: http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_any_transport_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1047362 cite Cisco IOS Release 12.2(33)SRC introduces the ability to specify MTU values in xconnect subinterface configuration mode. /cite So, that's for 12.2(33)SRC, and SRC is incompatible with 65xx, mentioned in original question... Welcome to Cisco BU split hell :) ___ 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] c2960g: flash gone mad ?
Hi! While trying to upgrade IOS on one of ours c2960g, I got strange message: SW088-022#verify flash:c2960-lanbase-mz.122-46.SE.bin File system hash verification failed for file flash:c2960-lanbase-mz.122-46.SE.bin(No such file or directory). however, MD5 verification of the same file succeeded: SW088-022#verify /md5 flash:c2960-lanbase-mz.122-46.SE.bin [] ...Done! verify /md5 (flash:c2960-lanbase-mz.122-46.SE.bin) = 27ad87f2c90595f3e682633c7985099a Well, I tried to format flash:, and re-upload IOS image - results were the same. And then switch refused to reload 'by command': SW088-022#reload %ERROR: Not able to process Signature in flash:. %ERROR: Aborting reload. so, I had to visit equipment room and reboot it by power cycle (booted normally, looks like that there are no signature check on boot). What is it ? Faulty flash ? Does not looks like - md5 check is just fine... And what to do with that switch ? Is it safe to leave it in network (on office one, without remote reboot ability it not qualified to remote installations) or better to RMA it ? ___ 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] c2960g: flash gone mad ?
On Thu, Oct 16, 2008 at 09:33:33AM -0500, Church, Charles wrote: I believe the IOS is to blame. I saw a similar thing with 12.2(44)SE2 on 3550, I believe. The verify never worked, but MD5 verify did. I don't remember the reload and signature issue though. I'm willing to bet it'll work ok from here on out. Well, it really looks like some 'new and cool IOS feature', reload /verify, which is broken in 12.2(46)SE. Tested that in lab: got another 2960 (non-g), running 12.2(35)SE5, uploaded and successfully verified 12.2(46)SE, reloaded, and got Switch#verify flash:c2960-lanbase-mz.122-46.SE.bin File system hash verification failed for file flash:c2960-lanbase-mz.122-46.SE.bin(No such file or directory). However, it reloaded just fine, so, it looks like there are two _different_ defaults: 2960 has default to reload /noverify and 2960g to reload /verify Chuck -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexandre Snarskii Sent: Thursday, October 16, 2008 9:21 AM To: Cisco-NSP Mailing List Subject: [c-nsp] c2960g: flash gone mad ? Hi! While trying to upgrade IOS on one of ours c2960g, I got strange message: SW088-022#verify flash:c2960-lanbase-mz.122-46.SE.bin File system hash verification failed for file flash:c2960-lanbase-mz.122-46.SE.bin(No such file or directory). however, MD5 verification of the same file succeeded: SW088-022#verify /md5 flash:c2960-lanbase-mz.122-46.SE.bin [] Done! verify /md5 (flash:c2960-lanbase-mz.122-46.SE.bin) = 27ad87f2c90595f3e682633c7985099a Well, I tried to format flash:, and re-upload IOS image - results were the same. And then switch refused to reload 'by command': SW088-022#reload %ERROR: Not able to process Signature in flash:. %ERROR: Aborting reload. so, I had to visit equipment room and reboot it by power cycle (booted normally, looks like that there are no signature check on boot). What is it ? Faulty flash ? Does not looks like - md5 check is just fine... And what to do with that switch ? Is it safe to leave it in network (on office one, without remote reboot ability it not qualified to remote installations) or better to RMA it ? ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] C2960G and output drops
On Wed, Oct 01, 2008 at 07:08:57AM -0400, McEvilly, Patrick wrote: IOS version on the switch is 12.2(46)SE, but I had (25)SEE on it before that, and observed the same symptoms (except that (25)SEE does not display the output drops in the counters). Counters problem is CSCsj53001: The Total output drops field in the show interfaces privileged EXEC command output now displays accurate ASIC drops. fixed-in 12.2(44)SE1. So, looks like we may face the same problem: our TDMoIP people reporting some minor packet loss, and we were just unable to find packet loss point - 12.2(35)SE1 just does not reports packet drops... Interesting enough, that our setup is quite differs with yours: we have no audio/video streaming, that's classic customer (and some colocation) aggregation switch with ~800Mbit of traffic: 5 minute input rate 22150 bits/sec, 65646 packets/sec 5 minute output rate 607959000 bits/sec, 83542 packets/sec (that's etherchannel, 2x 1Ge, utilisation of both ports is less than half: 5 minute input rate 109153000 bits/sec, 33306 packets/sec 5 minute output rate 342405000 bits/sec, 44080 packets/sec 5 minute input rate 11282 bits/sec, 31775 packets/sec 5 minute output rate 252582000 bits/sec, 38455 packets/sec ). -- Alexandre Snarskii If you ask a stupid question, you may feel stupid. If you don't ask a stupid question, you remain stupid. -Tony Rothman, Ph.D.U. Chicago, Physics ___ 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] EoMPLS with Port-channel with 8GE interfaces.
On Mon, Aug 25, 2008 at 04:07:48PM +0200, Oliver Boehmer (oboehmer) wrote: Maarten Moerman wrote on Monday, August 25, 2008 3:54 PM: Hi, I have a kind of problem at the moment which I'll try to explain here. Diagram: sw1 with 4 * GE-- 4 * GE @ r1 @ 10GE-- 10GE @ r2 4 * GE-- 4 * GEsw2 sw1 + sw2 = 6509 with 6748 blades r1 + r2 = 7604 with 6748 blades, and their interconnects are on 10GE xenpaks on 6704 10GE blades On sw1 +2 I have: Int port-channel1 Trunk encaps dot1q (multiple vlan) Int giga x/1-4 Channel-group 1 mode on On r1 + r2 I have: Int port-channel 1 mtu 9216 xconnect loopback IP other router mpls-tag encapsulation mpls Int giga x/1-4 mtu 9216 channel-group 1 mode on However, I'm currently facing the problem, that I cannot exceed the bandwith of that port-channel over 1gbit. The ingress is no problem, it tries to send, but the other side doesn't seem to pick up the traffic. Looks like you see the same problem as me: http://puck.nether.net/pipermail/cisco-nsp/2007-March/039451.html We solved this issue with avoiding eompls and transferring data over 10ge-link as simple switched vlan. Another (possible) solution - you can do some xconnect's from one sw to another (they're 6509, right ? So, you can load SRA or SXH IOS on them and do xconnects directly between switches). Why that solution not guaranteed to work - if you have to xconnect vlan with more than one gbit of traffic, you'll face the same problem not on rt egress, but on egress of the first sw. Does this have to do with the fact that the portchannel on the routers only see 1 source, and 1 destination address? So that it cannot correctly balance traffic among 4 interfaces? Anybody has an idea how to solve this? I've never done xconnect on a port-channel, but you could remove the channel on r1 and r2 and just configure regular EoMPLS PWs between each of the four GigE links. Channeling is then only performed on sw1 and sw2.. I would consider running LACP/PaGP on the channel between sw1/sw2.. This should work. Well, it should, but not in case when you need to xconnect only some vlan's from portchannel, and others you need to terminate locally or xconnect to another destinations... -- Alexandre Snarskii If you ask a stupid question, you may feel stupid. If you don't ask a stupid question, you remain stupid. -Tony Rothman, Ph.D.U. Chicago, Physics ___ 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] bgp router
On Fri, Jun 06, 2008 at 09:21:51AM -0700, bill fumerola wrote: Why is it, btw, that IOS doesn't use both CPU kernels there? Or did I miss an IOS version that started doing that? (still on 12.3T here) i believe the 2nd CPU can only be enabled for some very specific features: http://www.cisco.com/en/US/docs/routers/7300/install_and_upgrade/7301/7301_install_and_config_guide/5418c.html#wp1154543 %% The Cisco 7301 includes a dual-CPU-core BCM 1250. All Cisco IOS images for the Cisco 7301 platform use CPU-core 0. CPU-core 1 allows acceleration of specific feature sets via separately purchased special software. As of Cisco IOS Release 12.3(14)YM, multi-processor forwarding (MPF) accelerates the following broadband features: L2TP Access Concentrator (LAC), L2TP Network Server (LNS), and PPP Terminated Aggregation (PTA). Port adapters are not supported in the multi-processor forwarding (MPF) path on processor 1. %% As stated in this letter: http://puck.nether.net/pipermail/cisco-nsp/2006-December/036864.html MPF support is discontinued in IOS. [...] there were murmurs of a team at cisco porting freebsd mips, which would have given native SMP support. however, all the people who were supposedly working on that no longer work for cisco (or now work in groups whose bailiwick is clearly not core OS coding). read into that what you will. I suppose, You've heard not about Cisco, but about Juniper. They ported FreeBSD to MIPS and then donated MIPS code back to FreeBSD: http://www.freebsd.org/news/newsflash.html 25 December: Juniper Networks, Inc. (http://www.juniper.net) has donated a reference FreeBSD port to the MIPS architecture to The FreeBSD Project. This code will be used as one reference for creating an official project-supported FreeBSD/MIPS offering ___ 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] 6509 power supply question
On Fri, May 23, 2008 at 11:51:50AM +1000, Jarrod Friedland wrote: Hi All We have a 6509 with 2 x 1300W power supplies? rephrase we had :) - anyway, one of the power supplies has died, we are sourcing a replacement however, in the meantime I have another 6509 sitting next to me however it has 1800W power supplies. The question Can I run a 6509 with 1 x 1300W and 1 x 1800W (redundant)? Are the issues with doing this we should be aware of? I have asked this question of cisco integrators however all we get is The engineers have put their heads together and say NO We running different power supplies on one of our 6509 for years, no problems with that configuration: Switch#show power system power redundancy mode = redundant system power total = 2331.00 Watts (55.50 Amps @ 42V) system power used = 584.22 Watts (13.91 Amps @ 42V) system power available = 1746.78 Watts (41.59 Amps @ 42V) Power-Capacity PS-Fan Output Oper PS Type Watts A @42V Status Status State -- --- -- -- -- - 1WS-CDC-1300W 1153.32 27.46 OK OK on 2WS-CAC-2500W 2331.00 55.50 OK OK on ___ 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] 6509 power supply question
On Fri, May 23, 2008 at 11:51:30AM +0100, [EMAIL PROTECTED] wrote: Hi, We running different power supplies on one of our 6509 for years, no problems with that configuration: yes, you just need to be very careful that your blades dont draw too much power for the one not in use. eg if you are currently on a 2500W supply...and that fails , leaving you with only a 1300W then your blades may take too much for that and thus some will fail. Yes, I should note that this system is old one, Sup2 based, with old fans, using only 584.22 Watts, so even when we lose AC power - 1300Watt DC power supply provides enough power to run. eg in the scenario posted... Switch#show power system power redundancy mode = redundant system power total = 2331.00 Watts (55.50 Amps @ 42V) system power used = 584.22 Watts (13.91 Amps @ 42V) system power available = 1746.78 Watts (41.59 Amps @ 42V) so, system thinks its got 1746 available and 2331 supplied.. however: PS Type Watts A @42V Status Status State -- --- -- -- -- - 1WS-CDC-1300W 1153.32 27.46 OK OK on 2WS-CAC-2500W 2331.00 55.50 OK OK on that 1300W wont provide enough if the power used was eg 1341.55 Watts as the system THINKS its got 2500 ___ 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] Cisco Processing Regarding ICMP
On Sun, May 11, 2008 at 05:58:01PM +0200, Gert Doering wrote: On Sat, May 10, 2008 at 03:39:23PM -0500, [EMAIL PROTECTED] wrote: Because internal network design requirements, it is necessary decrease internal MTU to slight lower than 1500 bytes, Ugh. This is *really* unusual. Many networks increase their MTU to well above 1500, so that even tunneled connections still are able to carry full-MTU packets - but running a network below 1500 sounds like a Really Bad Plan to me. It's not so *really* unusual. Some parts of access layer in our network is PPPoE over some 'really cheap' switches, which have no option to support MTU of 1504 (1500 + PPPoE overhead). Expect fun with all the sites out there that have Issues with PMTUD. Lots. 'ip tcp adjust-mss' helps. Really helps. I never heard about MTU issue for years we running PPPoE... ___ 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] 6500/SRA: vpnv4 vs. equal-cost multipath ?
Hi!
Summary: looks like IOS 12.2(33)SRA* can't handle vpnv4 routes
which comes from peer reachable via two equal paths.
May be it's known issue, just run into it and want to share experience..
Our topology is really simple,
RouterA RouterB
||
||
RouterC RouterD
all routers are 65xx/Sup720/PFC3BXL, IOS version on RouterA is 12.2(33)SRA3,
on RouterD - 12.2(33)SRA1, all links are 10ge (6704-based, if it matters)
with same ospf cost of 4.
Configuring simple MPLS/BGP VPN between RouterA and RouterD,
configuration is straightforward. But I was unable to ping
one router from another within VPN... :(
After some digging, i found that however RouterA knows vpnv4 route
from RouterD:
RouterA#show ip bgp vpnv4 vrf LOCAL 192.168.103.120
BGP routing table entry for MyAS:230:192.168.103.120/29, version 14208
Paths: (1 available, best #1, table LOCAL)
Not advertised to any peer
Local
RouterD.234 (metric 20) from RouterD.234 (192.168.10.133)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:MyAS:230
mpls labels in/out nolabel/535
this route is not installed in MPLS Forwarding table (at least not
installed in correct way):
RouterA#show mpls forwarding-table vrf LOCAL 192.168.103.120 detail
Local Outgoing PrefixBytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
None 535 192.168.103.120/29[V] \
0
Recursive paths, Label Stack{535}
00217000
VPN route: LOCAL
No output feature configured
- you see, no outgoing interface mentioned in output, and label
stack is just incorrect - it consists only from one (final) label...
As insane as it sounds, source of problem was in the fact that RouterA
has two equal paths to RouterD:
RouterA#show ip route RouterD.234
Routing entry for RouterD.234/32
Known via ospf MyAS, distance 110, metric 20, type extern 2, forward metric
8
Last update from CoreNet.197 on TenGigabitEthernet6/4, 00:01:43 ago
Routing Descriptor Blocks:
CoreNet.197, from RouterD.234, 00:01:43 ago, via TenGigabitEthernet6/4
Route metric is 20, traffic share count is 1
* CoreNet.169, from RouterD.234, 00:01:43 ago, via TenGigabitEthernet6/1
Route metric is 20, traffic share count is 1
After lowering ospf metrics on one of our links and this getting rid of
ECMP, mpls forwarding table became normal:
RouterA#show mpls forwarding-table vrf LOCAL 192.168.103.120 detail
Local Outgoing PrefixBytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
None 535 192.168.103.120/29[V] \
0 Te6/1 CoreNet.169
MAC/Encaps=14/22, MRU=9212, Label Stack{1828 535}
00D02B18A504DEFEC8008847 007240217000
VPN route: LOCAL
No output feature configured
and now everything works just as expected...
PS: well, our topology is simple enough to easily avoid equal-cost path's
but in more complex networks this workaround may be inacceptable...
___
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] MUX-UNI IOS version
On Fri, Jan 18, 2008 at 01:07:16AM +0100, Peter Rathlev wrote: Hello, Anybody knows what software supports MUX-UNI? All our 7600/SRBx can do it, and none of our 6500/SXF6 can. Does any later SXF support MUX-UNI? Or do we have to make the jump to SXH? Or SRA on 6500? For me it works on 65xx/SRA. Documentation for SXH claims that there is support for MUX-UNI, but I never tried it myself. MUX-UNI has been mentioned in the archives as working on SRA, but I can't find any specific mention of supported IOS-versions; the feature guide for 12.2SX mentions it, but again no specifics, and Feature Navigator doesn't know MUX-UNI. BTW: It seems MUX-UNI is designed for xconnecting the subinterfaces, but using them as regular subinterfaces shouldn't be any problem, right? Using subinterfaces as 'regular' ones is just impossible: you have no ability to configure ip address on them: 65xx(config-subif)#ip ? Interface IP configuration subcommands: access-groupSpecify access control for packets admission Apply Network Admission Control auth-proxy Apply authenticaton proxy dhcpConfigure DHCP parameters for this interface header-compression IPHC options rsvpRSVP interface commands vrf VPN Routing/Forwarding parameters on the interface Just any easy way to make sure the specific PE-CE-connection isn't switched. Thanks, Peter ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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] VRF forwarding limits on SVI?
On Thu, Jul 19, 2007 at 11:02:46AM -0400, Jeff Kell wrote: 6500 Sup-II/MSFC2/PFC2 can't do SVI VRF forwarding? UTC-6509(config)#interface Vlan801 UTC-6509(config-if)# description No Man's LAN ring 1 UTC-6509(config-if)# ip vrf forwarding no-mans-lan %This interface does not support ip vrf forwarding Say it ain't so...? IOS c6sup22-jk2s-mz.121-26.E5. With sup2 you can only do vrf's on GE-WAN subinterfaces, and even then it's a bit tricky. In a most common (if not only possible) scenario, you must create 'hairpin' connection between lan-port (GigabitEthernetA/B) and wan-port (GE-WANc/D), put lan-port in 'switchport mode trunk' mode and allow vlan 801 on this trunk. On wan-port you create subinterface, interface GE-WANc/D.801 encaps dot 801 ip vrf forwarding no-mans-lan ip address and then it works. PS: not sure about 12.1(26)E5, but on 12.2(17d)SXB11 that trick works. ___ 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: yet another counters problem...
Hi! Looks like 12.2(33)SRB1 (or, may be, RSP720), introduced new semi-cosmetic bug with counters. Interfaces is not able to report speed and byte counters correctly when load is above 3.5Gbit/sec... For example, right now, show int te 1/4 shows me: 5 minute output rate 3416802000 bits/sec, 753529 packets/sec and snmp graphs shows the same picture - port sending nothing more than 3.5gbit, like it's congested, or router just unable to handle this load... Well, another side of this link terminated on a foundry switch, which reports that actual load is abour 4Gbit: 300 second input rate: 3962505208 bits/sec, 758136 packets/sec, 40.83% utilization link not congested and packetloss not occured.. ___ 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] ldp: label not assigned for eBGP-learned route..
Hi! While testing interAS mpls connectivity, I found interesting feature: router does not assign local label to route, learned via eBGP, even in case when got it with label... A bit more detailed description: I'm getting route with label, BGP routing table entry for AA.AAA.AA.5/32, version 5022 BB.BBB.B.49 from BB.BBB.B.49 (BB.BBB.B.6) Origin IGP, metric 0, localpref 100, valid, external, best Community: no-export mpls labels in/out nolabel/101824 and it's installed into mpls forwarding table with outgoing label: Routershow mpls forwarding-table AA.AAA.AA.5 Local Outgoing PrefixBytes Label Outgoing Next Hop Label Label or VC or Tunnel Id Switched interface None 101824AA.AAA.AA.5/320 Vl99 BB.BBB.B.49 But, as you can see, Local Label is not assigned to this route, so, even if that route redistributed with iBGP over my backbone, label for this route is not assigned at the edge, so, all other routers will not be able to establish LSP to remote side... Well, one workaround to this is to redistribute this route to ospf (this route get label assigned right after enabling bgp-ospf redistribution), but that workaround is potentially dangerous[1]. Are there any way to force local label assignment to eBGP-learned route without redistribution ? PS: IOS version is 12.2(33)SRA3, if it matters. [1]: Some years ago I saw a network meltdown caused by 'no redistribute bgp route-map BLAH', which removed not 'redistribute' command, but just 'route-map', thus allowing full-view leak into ospf.. With modern IOS behaviour (disable dCEF when there are not enough memory) such leaks are even more dangerous... ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] 6500: another eompls problem
On Thu, Apr 19, 2007 at 09:50:26PM +0300, Liviu Pislaru wrote: hello, first of all, i think the error INTERFACE_API-4-TBLERROR doesn't have anything in common with SPANTREE-2-RECV_PVID_ERR; because you use different VLANs at the ends of the EoMPLS tunnel and the BPDUs with vlan id 812 are encapsulated through the EoMPLS tunnel and decapsulated in vlan 4093, the port of the next switch that connects to Port-channel23.4093 will be put in STP bloking state and the end-to-end traffic will fail even if the EoMPLS tunnel is still UP. Well, that's my error to not providing picture :( Both portchannels are on the same PE device, like MPLS Core | v SW1 = Po42 PE = Po23 = SW2 Circuits comes from mpls core, one of them intended to go to SW1 over Po42, and the second to SW2 over Po23. We're using the same vlan ID on both ends of both circuits, so there is not renumbering with EoMPLS case. PS: just migrated this router to 12.2(33)SRA3, and problem disappeared. when you get Apr 19 20:03:29.356 MSD: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 812 on Port-channel23 VLAN4093 go to the switches that connects to Po42.812 and Po23.4023 and type: sh spanning-tree blockedports and you will see the port in STP blocking state. One workaround is to use the same VLANs on both ends. The second is to use spanning-tree bpdufilter enable on Port-channel ports (on PE) or to disable spanning-tree on PE, but be sure your topology is l2 loop free. If your topology permits to establish port-based EoMPLS or VLAN based (with SVI) with the clients directlly connected to the PE, this will be the third workaround. I'm sure there are others config tricks that you can use but i've only tested the three above. -- liviu. - Original Message - From: Alexandre Snarskii [EMAIL PROTECTED] To: Cisco-NSP Mailing List cisco-nsp@puck.nether.net Sent: Thursday, April 19, 2007 7:32 PM Subject: [c-nsp] 6500: another eompls problem Hi! Router in question is 6500, IOS 12.2(33)SRA1. We have a plenty of mux-uni eompls vc's, configured just by the book: interface Port-channel42.812 encapsulation dot1Q 812 xconnect XX.XXX.XXX.XX 812 encapsulation mpls Today, while adding another one, interface Port-channel23.4093 encapsulation dot1Q 4093 xconnect XX.XXX.XXX.XX 4093 encapsulation mpls we faced strange problem: a) New vc got blocked by spanning-tree on far side of etherchannel: Apr 19 20:03:29.356 MSD: %SPANTREE-2-RECV_PVID_ERR: Received BPDU with inconsistent peer vlan id 812 on Port-channel23 VLAN4093. b) Even worse: old vc (812) stopped functioning - while we saw mac-addresses from downstream on switch, terminating Portchannel42, but no mac-addresses were learned from eompls side.. Instead, we saw packets which should be forwarded to vc 812 (po42.812) appeared on vc 4093 (po23.4093).. Well, after deleting new vc, and re-creating old one (no int po42.812/ int po42.812) everything returned back to work. But, next try to configure new vc failed with the same reason.. Interesting note: when deleting new vc (no int po42.4093) next message appeared in log: Apr 19 20:03:54.321 MSD: %INTERFACE_API-4-TBLERROR: A error occurred while using the Index Table utility for Element Deletion. -Traceback= 41B38B88 41B41B04 41B4C3AC 404B7D74 404D964C 40F9B78C 40F9B778 So, i'm suppose that there is some another bug.. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ ___ 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/
