Re: [c-nsp] MSDP and my limited knowledge question
Msdp source active messages are sent to peers in response to pim registers the router receives. Pim registers are the responsibility of the DR on the same subnet as the source. When you have the static route the c4900 sees the source as directly attached, making it both the RP and the DR responsible for sending the registers (to itself). Without the static route the router receives the data stream, but doesn't know that it should be the router advertising it to the RP, and the RP doesn't know the stream originates in its domain. Paul. On 3 Sep 2012 20:55, David Prall d...@dcptech.com wrote: PIM is running between the two systems or you have a static mroute configured. What does sh ip rpf 10.10.10.1 David -- http://dcp.dcptech.com -Original Message- From: Mihai Tanasescu [mailto:mi...@duras.ro] Sent: Monday, September 03, 2012 3:32 PM To: David Prall Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MSDP and my limited knowledge question On 9/3/12 9:02 PM, David Prall wrote: You're using a GLOP group, so you are AS number 57370? You do have ip pim rp-address 192.168.1.2 configured? I am assuming the 192.168.1.2 is the MSDP source-address and the BGP source-address. Yes, that's configured. This issue only happens when that subnet is not directly connected on the interface toward the source and when I have a static route toward it. I can also see that my source is sending the stream (it is a Linux that I use for testing and as such I can easily do a tcpdump). David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mihai Tanasescu Sent: Monday, September 03, 2012 2:13 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] MSDP and my limited knowledge question Hi all, I have a simple test setup where I'm most likely failing to do something right. It basically looks like this: My PC --- CPE --- L3 transport network not under my control -- their router (MSDP + BGP + RP here) ( MSDP+ BGP + RP here) C4900 (192.168.1.1) -- (192.168.1.2) - multicast source (S) I announce (and originate on the C4900) through BGP the multicast sources subnet let's call it: 10.10.10.0/29 which I send to my provider (along with the RP/MSDP IP). MSDP peers are up, everything seems ok. a) if I put the 10.10.10.0/29 class as directly connected (between C4900 and S) instead of the 192.168.1.1 and 192.168.1.2 from above - all works ok and I can view the stream on my PC with VLC. I also see: (10.10.10.1, 233.224.26.1), 00:00:09/00:02:58, flags: PTA Incoming interface: GigabitEthernet1/48, RPF nbr 0.0.0.0 Outgoing interface list: Null b) if I put: 10.10.10.1/29 or /32 configured on S on a Loopback interface and on C4900: ip route 10.10.10.0 255.255.255.240 192.168.1.2 then I only have: (10.10.10.1, 233.224.26.1), 00:00:05/00:02:57, flags: PT Incoming interface: GigabitEthernet1/48, RPF nbr 192.168.1.2 Outgoing interface list: Null the A flag - MSDP Adv candidate is missing and if I do a: show ip msdp peer peer ip advertise-sa, then I see nothing. What am I missing ? Am I running into any check that I am failing ? Can you help me out ? This subject is quite new to me. Thanks, Mihai ___ 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/
Re: [c-nsp] MSDP and my limited knowledge question
Oops think i misread there... thought you were fixing it with a static to the interface (a method which it just occurred to me may not work). Your indirect static means the c4900 RP will not be DR. If you are using a router as a test source, with no other intermediate router acting as DR, adding the RP definition to that is worth a try but may not help if the SRC IP is local . The source IP will probably need to be within a connected range of the incoming interface for the register to be sent. On 3 Sep 2012 21:18, Paul Cosgrove paul.cosgrove.li...@gmail.com wrote: Msdp source active messages are sent to peers in response to pim registers the router receives. Pim registers are the responsibility of the DR on the same subnet as the source. When you have the static route the c4900 sees the source as directly attached, making it both the RP and the DR responsible for sending the registers (to itself). Without the static route the router receives the data stream, but doesn't know that it should be the router advertising it to the RP, and the RP doesn't know the stream originates in its domain. Paul. On 3 Sep 2012 20:55, David Prall d...@dcptech.com wrote: PIM is running between the two systems or you have a static mroute configured. What does sh ip rpf 10.10.10.1 David -- http://dcp.dcptech.com -Original Message- From: Mihai Tanasescu [mailto:mi...@duras.ro] Sent: Monday, September 03, 2012 3:32 PM To: David Prall Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] MSDP and my limited knowledge question On 9/3/12 9:02 PM, David Prall wrote: You're using a GLOP group, so you are AS number 57370? You do have ip pim rp-address 192.168.1.2 configured? I am assuming the 192.168.1.2 is the MSDP source-address and the BGP source-address. Yes, that's configured. This issue only happens when that subnet is not directly connected on the interface toward the source and when I have a static route toward it. I can also see that my source is sending the stream (it is a Linux that I use for testing and as such I can easily do a tcpdump). David -- http://dcp.dcptech.com -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mihai Tanasescu Sent: Monday, September 03, 2012 2:13 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] MSDP and my limited knowledge question Hi all, I have a simple test setup where I'm most likely failing to do something right. It basically looks like this: My PC --- CPE --- L3 transport network not under my control -- their router (MSDP + BGP + RP here) ( MSDP+ BGP + RP here) C4900 (192.168.1.1) -- (192.168.1.2) - multicast source (S) I announce (and originate on the C4900) through BGP the multicast sources subnet let's call it: 10.10.10.0/29 which I send to my provider (along with the RP/MSDP IP). MSDP peers are up, everything seems ok. a) if I put the 10.10.10.0/29 class as directly connected (between C4900 and S) instead of the 192.168.1.1 and 192.168.1.2 from above - all works ok and I can view the stream on my PC with VLC. I also see: (10.10.10.1, 233.224.26.1), 00:00:09/00:02:58, flags: PTA Incoming interface: GigabitEthernet1/48, RPF nbr 0.0.0.0 Outgoing interface list: Null b) if I put: 10.10.10.1/29 or /32 configured on S on a Loopback interface and on C4900: ip route 10.10.10.0 255.255.255.240 192.168.1.2 then I only have: (10.10.10.1, 233.224.26.1), 00:00:05/00:02:57, flags: PT Incoming interface: GigabitEthernet1/48, RPF nbr 192.168.1.2 Outgoing interface list: Null the A flag - MSDP Adv candidate is missing and if I do a: show ip msdp peer peer ip advertise-sa, then I see nothing. What am I missing ? Am I running into any check that I am failing ? Can you help me out ? This subject is quite new to me. Thanks, Mihai ___ 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/
Re: [c-nsp] Maximum traffic on Gigabit Ethernet
Hi Nick, I think you may have an error there. Your calculations suggest that traffic in on a 1Gbps interface will fill a 1.3M Byte receive buffer in a little under a 1/10 of a second. While the preamble and inter frame gap will slow the buffer fill rate (the degree depending on the packet size), that seems very slow. Presumably the buffer would also be processed by the router, and that would need to be accounted for over a 5 min interval. Paul. On Mon, Oct 3, 2011 at 4:37 PM, Nick Hilliard n...@foobar.org wrote: On 03/10/2011 14:47, Manaf Al Oqlah wrote: What is the maximum traffic that a gigabit Ethernet interface can handle on Cisco 7600 router RSP720-3C-GE before dropping packets . we are able to reach 750 mbps / 125 mbps input/out rate! The maximum traffic that a gigabit Ethernet interface can handle before dropping packets on any interface capable of handling line rate transmission is exactly 1,000,000,000 bits per second - no more, no less. I think you're confusing maximum traffic with maximum traffic averaged out over a period of X seconds, where X is larger than the deterministically longest buffer time available on that specific port. To understand why your question is meaningless, consider the situation where a GE port receives exactly 2gbit/sec for one second, then spends the next 299 seconds with no traffic at all. Because the port could only handle 1Gbit/sec out of the 2Gbit/sec received, this will register as a total of 1Gbit/sec of traffic over 300 seconds, i.e. 3.333 mbit/sec. However you will see 50% packet loss, because the port could only handle half the traffic it expected to process. Actually, it won't be quite 50% due to packet buffering, but you get the idea... So from a mathematical point of view, let's say you're using a WS-6748-GE-TX card which has 1.3M of buffer space per port and that you're using 5 minute load counters. This works out as 96ms worth of traffic. So you are guaranteed that regardless of the input traffic load, the first 96ms worth of traffic received on the port will not have any packet drops - note that this is not the same as the first 96ms worth of traffic transmitted to the port. If you figure out the maths, it means that without prior knowledge of the traffic profile, the maximum 5 minute load average on that GE port where you are _guaranteed_ not to have packet drops is 320kbit/sec. Freaky, huh? This is nit-picking though. In real life, the number is highly variable, and usually ranges from about 650mbit/sec upwards, depending on traffic type. imix traffic is usually much more forgiving than bursty lan traffic. Nick ___ 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] MACFLAP Message
The switches learn the source mac address of incoming frames, and record the interface and vlan on which they are received. A switch will associate only one interface per vlan with a particular mac address, and will use that information to deliver any frames destined for that mac (e.g. return traffic). If the switch later receives a frame with the same source mac address on a different interface in the vlan, then the switch believes that the topology connecting the host has changed and overwrites its entry with the new interface information. If repeated changes are occurring quickly, then the switch kindly informs you that the address is flapping so you can correct the problem. To avoid mac entry flapping on the switch you should have only one interface (physical or logical) receive frames with a given source mac address. For failover you may have another device use the same mac if your first server fails, but you should not have two devices sending using the same mac at the same time in the same vlan. Similarly a server which uses a single mac address for multiple interfaces in the same vlan (i.e. etherchannel) should not use those interfaces to connect to switch ports which are not in the same port channel. You can connect a server etherchannel to different switches only if the switches are in a stack and the switch ports in the same port channel within that stack. Paul On Sun, Jun 27, 2010 at 3:54 PM, Bill Blackford bblackf...@nwresd.k12.or.us wrote: Had an issue the other day that may or may not be related to the following message. Jun 24 11:30:37.354: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.1761.8140 in vlan 311 is flapping between port Po4 and port Po5 Jun 24 11:30:51.665: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.176f.a6e4 in vlan 311 is flapping between port Po4 and port Po5 Jun 24 11:30:52.672: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.1761.8140 in vlan 311 is flapping between port Po5 and port Po4 Jun 24 11:32:18.924: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.176f.a742 in vlan 311 is flapping between port Po5 and port Po4 Jun 24 11:32:24.460: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.176f.adae in vlan 311 is flapping between port Po5 and port Po4 Jun 24 11:34:12.237: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.176f.a6e4 in vlan 311 is flapping between port Po4 and port Po5 Jun 24 11:34:12.900: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.176f.adae in vlan 311 is flapping between port Po5 and port Po4 Jun 24 11:34:13.278: %SW_MATM-4-MACFLAP_NOTIF: Host 0015.176f.a742 in vlan 311 is flapping between port Po5 and port Po4 VLAN311 is an Oracle heartbeat L2 vlan that spans across the data center. This message was logged on the 3750 VC stack (core). Each node is connected to access switches that each connect into the core via LACP bundles. Each of these MAC's are part of a Linux BOND group on various hosts. IOW, each bond interface member connects to each of the (in this case) two access switches. The topology is loop free from the perspective of the network switches as the LACP bundles eliminate the need for spanning tree. Now, this may be more of a question for how Linux bonding works across multiple access switches but I need to start here. I'm not finding a lot of information about this message. Does anyone on the group have any insight? Thank you in advance, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD Logged into reality and abusing my sudo priviledges ___ 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] Multicast trickery
Hi Mattias If I understand your topology correctly, the configuration should be very similar to what you would use for any other internal source. The difference in this case that the source in this case is the provider network, and being untrusted requires additional precautions on the input interface (only). Considering a conventional Anycast RP multicast topology for a moment, when the multicast packets are received by the DR, the DR encapsulates the packets as unicast register messages and sends them to the nearest RP for that group. The RP effectively converts the first register messages to a source active message, and then sends the SA to each configured MSDP peer. In this example the SA is originated because a register messages has been received for a new source. The register message is sent to that router because it is a active RP for the group. Since you are using BSR you have only one active RP for each group, and is may be important which that is in this case. Is your second C-RP is the active RP for the group you are having problems with? Tested a topology with a combined DR and RP, some years ago. It may work if you run PIM-SM and the RP is the DR for the subnet, but if I recall correctly, behaviour differed between different routers/software versions and it did not work well/often. You should be able to test this easily enough by debugging msdp and pinging an unused multicast group from a router connected to your RP. With pim-sm enabled on the RP's input interface, and the RP elected as DR, you may still find that no SA is originated. You could try to persuade your second provider to provide MSDP and BGP information, but I guess you have already tried that approach. Alternatively attach another router to your RP and have the provider present the multicast stream on that. As well as the bsr boundary, and acls to stop pim (inc unicast pim), make sure you have pim register rate-limit applied. You must also make sure that traffic to the auto rp groups is not permitted into your network. IP multicast boundary is useful. The method in the link that Hans provided should also work, though I would think it wise to test in a lab first if you are thinking of applying it to one of your main C-RP routers; or apply it on another router entirely. The acl you mentioned will not stop multicast packets sent by the router on which it is applied, and that is likely to be why multicast traffic is still leaking through. If this router is the RP for a particular multicast group, when one of your sources begins sending to a group, the first packet the RP router receives is as a unicast register message, which it decapsulates before transmission. The path of the packet through the router is not the same as for native multicast, since it is unicast to the RP and has to be punted to the CPU; it may be that these decapsulated packets are not being filtered. If you have static RP definitions anywhere in your network, traffic to groups without a configured RP might also be leaking out. IP multicast boundary may help. You mentioned Anycast-RP, and using that with static RP definitions is quite straightforward to configure and maintain, perhaps easier than you think. Paul. On Tue, Oct 20, 2009 at 6:03 PM, Wyatt Mattias Gyllenvarg wyatt.elias...@gmail.com wrote: Hi Hans I have set BSR-BORDER on the interface, so that should not be it. I want too run PIM-DM but as long as I send PIM-packets I can not. Anyone have a theory about the filter not biting? Im not at work now but it looks something like. Deny ip pim any any Deny ip any multicast Permit any any Best regards Mattias Gyllenvarg 2009/10/20 Hans Verkerk hverk...@winitu.com: Hi, If I run PIM-DM they call me in a hurry and tell me that my PIM packets are disturbing the network. Maybe your BSR packets are interfering with SP2's network, so include ip pim bsr-border on interface facing SP2. PIM DM sources can be distributed as follows into MSDP: http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_msdp _im_pim_sm_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp105549 3 HTH, Hans -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Wyatt Mattias Gyllenvarg Sent: Tuesday, October 20, 2009 6:23 PM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Multicast trickery Hi All I am in need of pointers regarding a multicast configuration that does not fit the models found online or in the literature I have at hand. The network is built on PIM-SM with 2 BSR-RP routers (core1 and core2). At Core1 we receive a set of Multicast streams from IPTV-Provider 1 via PIM-SM and MSDP, this works fine. The mroutes are announced to Core2 via MSDP, works fine. At Core2 we receive a set of Multicasts that are flooded too us, this is the problem source. I can't distribute this in MSDP if I run
Re: [c-nsp] best practices switches/Router
Hi Scott, Would have to recommend reading the document, as the NSA have produced very well written guides for many years. Then adopt whichever recommendations you like, or a cunning disguise if you prefer. Paul. On Tue, Oct 13, 2009 at 6:55 PM, Scott Granados gsgrana...@comcast.netwrote: NSA security policy, h, does that involve a lot of port mirroring and copying of data to non existant trunks. (shshshshshsh) Or use of encryption standards that are almost secure.;) Call me crazy (you wouldn't be the first) but I have to say I'm always skeptical when someone says Hi, we're from the Government and we're here to help! - Original Message - From: Kevin Graham kgra...@industrial-marshmallow.com To: jckdaniel...@gmail.com; cisco-nsp@puck.nether.net Sent: Tuesday, October 13, 2009 10:37 AM Subject: Re: [c-nsp] best practices switches/Router my aim is to do review of the configs of ROUTERS and Switches in my network. As a review , need to track down the best practices that should be configured and are not there in my network. Was: http://www.google.com/search?q=site%3Acisco.com+best+practices ...not sufficient? From a security standpoint, in addition to the NSA SNAC publications already mentioned, Cisco's Network Security Baseline is very much worth reading: https://www.cisco.com/en/US/docs/solutions/Enterprise/Security/Baseline_Security/securebasebook.html ___ 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/
Re: [c-nsp] BGP session resets if NLRI exchanged
Many thanks Harold! that does indeed look like the issue. We are using 32byte ASNs, but since the problem was occuring even after we filtered that advertisement we had begun looking elsewhere. Paul. Harold Ritter (hritter) wrote: Paul, You might be running into CSCsl72955. If so, you could try the workaround suggested by the following link or upgrade the code. http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method =fetchBugDetailsbugId=CSCsl72955 Regards -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Paul Cosgrove Sent: Wednesday, March 25, 2009 11:55 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] BGP session resets if NLRI exchanged We are attempting to establish a new BGP session between one of our CRS-1 routers, and a Redback SE800 router owned by another provider. Am not familiar with Redbacks myself and we have not peered with any before (as far as we know anyway). The BGP session only remains up if no NLRI is exchanged. If the other provider sends any prefixes to us we reply with a invalid length for attribute notification; if we send any prefixes to them they reply with invalid or corrupt AS path. The other provider uses VPNv4 within their network, though I understand that it is not configured on this peering. I'm wondering whether these errors could result if their router expects a RD (and sends one) on the advertisements, perhaps due to a software bug or typo in the config. Perhaps someone has seen this problem before? Paul. ___ 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/
[c-nsp] BGP session resets if NLRI exchanged
We are attempting to establish a new BGP session between one of our CRS-1 routers, and a Redback SE800 router owned by another provider. Am not familiar with Redbacks myself and we have not peered with any before (as far as we know anyway). The BGP session only remains up if no NLRI is exchanged. If the other provider sends any prefixes to us we reply with a invalid length for attribute notification; if we send any prefixes to them they reply with invalid or corrupt AS path. The other provider uses VPNv4 within their network, though I understand that it is not configured on this peering. I'm wondering whether these errors could result if their router expects a RD (and sends one) on the advertisements, perhaps due to a software bug or typo in the config. Perhaps someone has seen this problem before? Paul. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] VTP domain.
The behaviour regarding forwarding vtp messages is identical between transparent mode in either VTP versions; if the domain name is null all VTP messages are forwarded, while if it is set only messages for that domain are forwarded. Apparently this changed sometime in the distant past but the documentation was not updated (at least it wasn't the last time I looked). You can find more information about this here:- http://www.groupstudy.com/archives/ccielab/200704/msg01533.html You can see that there is also a mention there, apparently from a member of cisco TAC, that a capability to set a VTP domain name to Null had been considered but a decision was made not to implement it. To stop any VTP messages being forwarded, if you really need to, you can use mac acls matching the destination address(0100.0ccc.) and ethertype (0x2003). If on the other hand you need the VTP messages to be forwarded for multiple domains, without affecting this switch, then you may need to delete the vlan.dat, change to transparent mode and reload. Paul. steven.glog...@swisscom.com wrote: VTP transparent switches DO forward vtp messages (if using version 2). see: VTP transparent switches do not participate in VTP. A VTP transparent switch does not advertise its VLAN configuration and does not synchronize its VLAN configuration based on received advertisements. However, in VTP version 2, transparent switches do forward VTP advertisements that they receive from other switches from their trunk interfaces. dont forget: the VTP domain can be learned if NO domain is given - the switch takes the first domain he sees in a VTP message. make sure that you put switches in transparent mode if you want to prevent disasters. we all know that the highest revision number in a domain wins. a client can overwrite all other switches (incl. server) if the revision number is highter and if he has the same domain name vtp is evil as we all know ,-) to remove the domain name just set another one. -steven ps: your guide for any VTP questions: http://www.cisco.com/en/US/docs/switches/lan/catalyst3550/software/release/12.2_44_se/configuration/guide/swvtp.html -Original Message- From: cisco-nsp-boun...@puck.nether.net [mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Wednesday, February 11, 2009 12:54 AM To: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] VTP domain. On Wednesday 11 February 2009 03:02:41 am Keith wrote: The 3550 being replaced has no vtp domain name. Is it possible to remove the vtp domain name without deleting the vlan.dat file? I have looked over the TAC but see nothing really regarding removing a vtp domain name. Lots about adding one, not about removing one. No clear way to do this, today, without deleting the 'vlan.dat' file. Wish that could be fixed. But like you and others have said, maintaining VTP Transparent mode will ensure it stays away from VTP. We used to manually clear VTP domain names, but recently found a batch of switches that had them configured. It's too much work to clear that, but we just say no to VTP anyway. Cheers, Mark. ___ 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] BGP MSS=576 bytes
TCP sessions normally use 536 if they are established between IPs which are not directly connected. You may see the same on MSDP peerings. Enabling Path MTU Discovery allows the actual end to end MSS to be determined, provided the ICMP type 3 code 4 messages are not blocked along the way. Paul. Antonio M. Soares wrote: Hello group, I have a 6500 running 122-18.SXF7 with lots of BGP peers and all of the BGP sessions have negotiated a MSS of 536 bytes. Here's an example: ++ 6500sh ip bgp neighbors x.x.x.x ... Datagrams (max data segment is 536 bytes): Rcvd: 439340 (out of order: 252), with data: 406672, total data bytes: 94316052 Sent: 296303 (retransmit: 727), with data: 35046, total data bytes: 994215 6500 ++ The documentation says that PMTUD is enabled by default so this should not be happening: ++ BGP Neighbor Session TCP PMTUD TCP path MTU discovery is enabled by default for all BGP neighbor sessions, but there are situations when you may want to disable TCP path MTU discovery for one or all BGP neighbor sessions. While PMTUD works well for larger transmission links (for example, Packet over Sonet links), a badly configured TCP implementation or a firewall may slow or stop the TCP connections from forwarding any packets. In this type of situation, you may need to disable TCP path MTU discovery. In Cisco IOS Release 12.2(33)SRA, 12.2(31)SB, 12.2(33)SXH, 12.4(20)T, Cisco IOS XE Release 2.1, and later releases, configuration options were introduced to permit TCP path MTU discovery to be disabled, or subsequently reenabled, either for a single BGP neighbor session or for all BGP sessions. To disable the TCP path MTU discovery globally for all BGP neighbors, use the no bgp transport path-mtu-discovery command under router configuration mode. To disable the TCP path MTU discovery for a single neighbor, use the no neighbor transport path-mtu-discovery command under router or address family configuration modes. ++ I have for example a direct eBGP peering over TenGiga interfaces where i see the same problem: ++ 6500sh int tenGigabitEthernet x/x | inc MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec, 6500 6500 6500sh ip int tenGigabitEthernet x/x | inc MTU MTU is 1500 bytes 6500 ++ Any explanation to this strange behavior ? Thanks. Regards, Antonio Soares, CCIE #18473 (RS) amsoa...@netcabo.pt ___ 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] Weird problem w/ packet loss on QinQ ports
Hi Garry, We have seen something similar with 6500s connected using QinQ between one ME3400s running metroaccess 12.2(25)SEG3 and one 3750 running ip base 12.2(25)SEE2. Have copied this to my colleague Daniel who is working on the issue. As a matter of interest, are you using UDLD on the 4507? Paul. Garry wrote: One addendum - I've just removed the 4507 from the network, hooking up the ME3400's back-to-back ... turns out the packet loss is gone, so it must be something with the 4507 -- is there anything additional that needs to be configured so that QinQ encapsulated traffic passes through correctly? I activated l2protocol tunneling on the 4507 for testing purposes, that also works flawlessly, showing the remote neighbor instead of the 4507 ...but still, all double-tagged packets cause packet loss ... Any ideas? Tnx, -garry ___ 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/ Garry wrote: Hi, I'm currently fighting with a weird case of packet loss in a lab setup... here goes ... Setup is as follows, two ME3400 with MetraAccess IOS 12.2.46, are connected to a 4507 through GigE ports. Connections are Trunk links. VLANs (QinQ, plus other non-QinQ ones) used on the MEs are configured on the 4507. Now, when I hook up two PCs to one of the ME each, using a switchport access port, both being in the same vlan, everything is fine. Transfer rates are fine, no packet loss on floodpings even with large packets (1500). Now, plugging the PCs into the QinQ ports, which are just configured with the basic switchport access and switchport mode dot1q-tunnel, I get about 1% packet loss on flood pings with default packet size, with increasing loss while increasing packet size. Weird thing is, doing a tcpdump on the receiving end, I see the packets arriving, though some aren't answered by the PC. I assume they arrive with incorrect checksum and therefore are dropped by the stack ... Anybody have an idea what is going wrong here??? I'm out of ideas ... Tnx, -garry ___ 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] STP or HSRP problem ?
Charlie Allom wrote: On Thu, Dec 18, 2008 at 06:43:46AM -0800, Teller, Robert wrote: This appears to be related to hsrp. What is the exact problem your having, do your users report loss of connectivity momentarily or are you just looking in your log file and see this entry. It's hard to say without see your config what the problem is. I get this often on ISR routers with high CPU (2821's) Depending on how long it lasts it can knock out streaming but that's about all that notices. C. Hi Jack, There is a Cisco doc about troubleshooting HSRP problems which mentions that high CPU can cause HSRP flaps. http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml Case Study 7 describes a scenario where two routers are connected to a shared stub LAN, with both supporting multicast and running HSRP. Each has a route to a multicast source via another interface. The DR is sending multicast onto the shared LAN, and these are reaching the non-DR on a non-RPF interface. The non-DR may not have created any state for the group (I guess since the DR is handling joins), and so the non-RPF packets are punted to the CPU for processing. The increased CPU causes HSRP state changes on the non designated router. The suggested solution is to use an ACL on the standby router to prevent these multicasts being received via the multicast DR. Paul. ___ 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] security
Michael Simpson wrote: On 12/2/08, Adam Greene [EMAIL PROTECTED] wrote: How does one get around the side-effect of not allowing broadcasts; i.e. wouldn't this break ARP functionality? Not within the subnet using ethernet arp is only on the local segment and won't traverse the router no ip directed broadcast stops broadcasts from a different subnet snipped from http://www.cisco.com/en/US/docs/ios/12_3/ipaddr/command/reference/ip1_i1g.html#wp1081245 An IP directed broadcast is an IP packet whose destination address is a valid broadcast address for some IP subnet, but which originates from a node that is not itself part of that destination subnet. A router that is not directly connected to its destination subnet forwards an IP directed broadcast in the same way it would forward unicast IP packets destined to a host on that subnet. When a directed broadcast packet reaches a router that is directly connected to its destination subnet, that packet is exploded as a broadcast on the destination subnet. The destination address in the IP header of the packet is rewritten to the configured IP broadcast address for the subnet, and the packet is sent as a link-layer broadcast. mike ___ 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/ Or to put it another way... Arp uses a destination IP of 255.255.255.255, which is the 'limited broadcasts address'. Packets with this destination are never routed between subnets. Directed broadcast destination IPs begin with a subnet's network prefix, so for an interface with IP 192.168.10.1/24 the directed broadcast address of its attached subnet is 192.168.10.255. These can be routed between subnets. Paul. ___ 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] security
Gert Doering wrote: Hi, On Tue, Dec 02, 2008 at 03:29:58PM +, Paul Cosgrove wrote: Arp uses a destination IP of 255.255.255.255, which is the 'limited broadcasts address'. Packets with this destination are never routed between subnets. Actually, ARP does *not* use any IP broadcast address at all, neither limited or subnet broadcast. $ tcpdump -v -n -s0 -e 'arp' 16:35:21.981368 0:22:55:93:88:80 ff:ff:ff:ff:ff:ff 0806 60: arp who-has 195.30.1.10 tell 195.30.1.118 ... no IP address in here, except source and destination hosts. Ethernet broadcast, yes. gert Oops, shouldn't be getting that wrong. Thanks for the correction and appologies for the confusion. Paul. ___ 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] High CPU on 3750G-24-TS
Hi William, I would agree with Ozgur that you would be better off loosing the ip igmp join-group command. Also limit the number of register messages which can be created per second; it is only needed if you have sources attached, but personally I would apply this on every L3 multicast device: ip pim register-rate-limit 5 Have seen a case where register stop messages were lost whilst being sent to a 3750. Debugs on the adjacent device indicated they were all being transmitted to the switch, debugs SPAN on the 3750 indicated the switch was receiving very few of these. Paul. William wrote: We currently use ip igmp join-group x.x.x.x under the vlan interface. Cheers. W 2008/11/12 Ozgur Guler [EMAIL PROTECTED]: As far as i remember ip igmp static-group forces the packets to be process switched on the switch/router. You might need to replace it with ip igmp static-group which will do the same job (put the interface permanently into OIF). --- On Wed, 12/11/08, William [EMAIL PROTECTED] wrote: From: William [EMAIL PROTECTED] Subject: [c-nsp] High CPU on 3750G-24-TS To: cisco-nsp cisco-nsp@puck.nether.net Date: Wednesday, 12 November, 2008, 11:15 AM Hi List, We currently have a 3750G-E in our network which is experiencing a high CPU load and I'm trying to understand why, the CPU is over 50% all the time and at peak traffic times we are seeing around 85% on Cacti using 5 minute averages. When running a show proc cpu sorted I can see that IP Input is taking up most of the CPU time with Spanning Tree coming second however ST is only using a fraction of what IP Input is using. The switch is not in a stack, runs IOS version 12.2(25)SEB4 and the image is IPSERVICES, the configuration has one routed port to another site (with sparse-dense-mode on), has one EIGRP process, 19 static routes, access lists which are only used for SNMP/VTY and it has two VLAN interfaces. One of the VLAN interfaces has sparse-dense-mode enabled and a igmp join-group command. It pushes a lot of multicast traffic (around 10Mbits) which is probably the problem but I thought the 3750 would have been able to handle it without an issue. Any help is appreciated, I'd like to have a good understanding of what is causing the issue. Thank you for your time, W ___ 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/
Re: [c-nsp] [cisco-nsp] [OOT] Getting help to get the network acceptable
insan praja wrote: Hi, My company recently bought 202[dot]90[dot]194[dot]0/23 IPs, and since we start using this IPs, I can't access several site on the net. When check through robtex.com, a company in India seem to still include these IPs into their RADB database. I can't email them, browse their sites, maybe because of some antispoof things. We asked our upstream to include this IPs to their radb accounts, but it seem nothing changed, as we check to robtex.com, these IPs still originated as AS9829 route-object. I really appreciate if anyone in the list could help me getting these IPs to be correctly accepted to browse the internet. Best Regards, Insan ___ 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/ Can't you email them from the same account you are using here? If you send them an email from your yahoo web account it should not be affected by any antispoofing. You realise this seems a very perculiar request when you do not include your company name or any verifiable contact information. Paul. ___ 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] disabling 3750 mac address learning
Noticed that the 3750 ios 12.2(46)SE release supports the disabling of mac address learning per vlan. Does anyone have any experience with this release yet? The feature seems to have been introduced earlier in the 3650s and has obviously been in ME switches for a while. http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_46_se/command/reference/cli1.html#wp10289393 Paul. -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] disabling 3750 mac address learning
[EMAIL PROTECTED] wrote: Noticed that the 3750 ios 12.2(46)SE release supports the disabling of mac address learning per vlan. Does anyone have any experience with this release yet? The feature seems to have been introduced earlier in the 3650s and has obviously been in ME switches for a while. The feature has been there longer, in the form of an RSPAN-enabled VLAN. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] Thanks Steinar, I think there are a few differences between these. The command docs say the following about RSPAN VLANs: - All traffic in the RSPAN VLAN is always flooded. - No MAC address learning occurs on the RSPAN VLAN. - RSPAN VLAN traffic only flows on trunk ports. - RSPAN VLANs must be configured in VLAN configuration mode by using the remote-span VLAN configuration mode command. - STP can run on RSPAN VLAN trunks but not on SPAN destination ports. - An RSPAN VLAN cannot be a private-VLAN primary or secondary VLAN. The first and third points suggests that for RSPAN VLANs you: - cannot use static mac assignments - cannot use access ports Paul. -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] Interdomain Multicast Routing
Hi Mike, Normally MSDP will work with just unicast BGP, but then RPF check changed between IOS and IOS XR... In IOS a router performing an RPF check looks first at the multicast routing table, and if it doesn't find a match it then looks at the unicast table. In IOS XR if you have any routes in the multicast table, and you do not find the one you are looking for, RPF fails. Doesn't matter whether or not the prefix is in the unicast table. You may have a situation where you are given multicast feeds (e.g. IPTV) and are only supplied with multicast BGP routes because they do not want any of your unicast traffic. You may well wish to receive those feeds, and also receive multicasts from sources which only advertises unicast routes. If I understand the RPF correctly, this presents you with a problem and may have to look at statics/ACLs etc. Paul. Mike Louis wrote: This has been a confusing subject for me. If you enabled msdp between 2 pim sm domains and enabled mc routing on the intermediate bgp routers while using normal non-mbgp routing wouldn't mc still work? Why would you want to use mbgp unless you wanted mc routes to take a different path than unicast routes? Do most sp these days support mc in their networks for customers? Thanks mike -Original Message- From: Jeff Tantsura [EMAIL PROTECTED] Sent: Monday, September 01, 2008 4:53 AM To: 'Muarwi' [EMAIL PROTECTED]; cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Subject: Re: [c-nsp] Interdomain Multicast Routing Hi, The combination you've described has been working for many years, very well tested, supported by all major vendors. PIM (bidir as well) is used for intradomain multicast routing independently of interdomain multicast (MSDP/MBGP). Cisco does support PIM Bidir Cheers, Jeff P.S. Best book ever - Interdomain Mutlicast Routing by Edwards/Giuliano/Wright -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Muarwi Sent: maandag 1 september 2008 9:49 To: cisco-nsp@puck.nether.net Subject: [c-nsp] Interdomain Multicast Routing Hi guys, I'm sorry if my questions is rather out of cisco's things. I've read books about interdomain multicast routing (also one from cisco press). From what I get, the solutions offered is PIM SM - MBGP - MSDP. My questions is : 1. what about using PIM Bidir for interdomain multicast? Is it possible to implement it in Cisco? 2. Has BGMP been being implemented in vendors? Thanks a lot for your response ___ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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 2960G Issue
Hi Mike, As I understand it that is the way the ASICs are shared on most of the catalysts. Lightning striking an ethernet cable can affect connectivity in a similar, though more persistent way; switch survived but four adjacent ports were permanently disabled. Have you recently found any unexpected gaping holes in the roof? :) Paul. Matlock, Kenneth L wrote: Sorta sounds ike a bad chip on the chassis, since it's affecting 4 adjacent ports. 1-4 probably share an Asic (or part of one), 5-8, 9-12, etc. I'd call TAC on this one to get a replacement. Ken From: [EMAIL PROTECTED] on behalf of Mike Cooper Sent: Wed 8/27/2008 3:39 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] Cisco 2960G Issue Hi all, I've got a WS-C2960G-24TC-L switch running IOS 12.2(35)SE5 It's been in production for a couple of weeks in a fairly straight forward L2 environment. We noticed this afternoon a few hosts connected to the switch suffering persistent packet loss of ~20% After a bit of investigation we narrowed it down to ports 5, 6, 7, 8. The ports were configured as access ports, 1 @ 10M/FD 3 @ 1G/FD, all were in different vlans. My assumption is the switch runs six ASICs, and that the one that operates those 4 ports has faulted or degraded in some way causing the performance issues. None of the other machines connected to the switch were affected, and currently the switch is still operating. I've since relocated the affected machines to an alternate switch, resolving the loss issues. I'm interested if anyone is aware of this as a common problem with 2960G switches (or any switches for that matter), and if there are any tips for testing/troubleshooting before I return it as faulty. I bought 4 brand new 2960Gs in one go, 1 was DoA, and now this one has developed faults which is leaving me with some concerns for the others. Cheers, --Mike ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: [c-nsp] VTP and Vlan 1
Hi Michel, Appologies for confusing the issue. You are of course correct about VTP, which does use vlan 1. UDLD is not sent with a dot1q tag, but is associated with vlan 1 on ISL trunks. Changing the (dot1q) native vlan on the trunk has no effect on how UDLD is sent over ISL, it is still sent on vlan 1. Paul. Michel Grossenbacher wrote: Paul, indeed DTP is sent over the native VLAN, but VTP is pretty sure still over VLAN 1. I did a trace and mixed VTP with DTP, hence I said its using the native VLAN. But after I did some more traces the VTP packets did not show any VLAN informations anymore (actually they never did I only hit the wrong line within wireshark ;) ). So Im quite sure VTP and CDP are not sent via the native VLAN, after I changed it from VLAN 1 to VLAN 10. Probably have to have a look with ISL too. Mike, I think I know what you mean, per definition (AFAIK) all VLANs get encapsulated by ISL, while with dot1Q all but the native one get a Tag. But within an ISL trunk Cisco defines a native VLAN (default is VLAN 1, same as dot1Q) and you can configure it the same way as for a dot1Q one so I'd say UDLD will use that one. I guess it will still be encapsulated but I did never check that. Do a *show interface trunk* if you configured an ISL trunk and you'll see it at the top. Michel 2008/8/25 Paul Cosgrove [EMAIL PROTECTED] Hi Michel, You may have been right the first time there. I think VTP does indeed use the native vlan, not necessarily vlan 1. DTP is also sent on the native vlan, untagged and tagged in its case. Paul. Michel Grossenbacher wrote: A little correction on my answer, VTP does not use the Native VLAN :-) Here is what I found regarding the use of VTP and VLAN1: The Case of VLAN 1 You cannot apply VTP pruning to VLANs that need to exist everywhere and that need to be allowed on all switches in the campus, in order to be able to carry VTP, Cisco Discovery Protocol [CDP] traffic, and other control traffic. However, there is a way to limit the extent of VLAN 1. The feature is called VLAN 1 disable on trunk. The feature is available on Catalyst 4500/4000, 5500/5000, and 6500/6000 series switches in CatOS software release 5.4(x) and later. The feature allows you to prune VLAN 1 from a trunk, as you do for any other VLAN. This pruning does not include all the control protocol traffic that is still allowed on the trunk (DTP, PAgP, CDP, VTP, and others). However, the pruning does block all user traffic on that trunk. With this feature, you can keep the VLAN from spanning the entire campus. STP loops are limited in extent, even in VLAN 1. Configure VLAN 1 to be disabled, as you would configure other VLANs to be cleared from the trunk: UDLD uses native VLAN in order to talk to the neighbor. So, in a trunk port, the native VLAN must not be pruned in order for UDLD to work properly. http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080890613.shtml Sorry for the confusion. best regards Michel On 25/08/2008, Michel Grossenbacher [EMAIL PROTECTED] wrote: Hi Mike Actually VLAN 1 is not pruning-eligible so you can not prune VLAN 1 from a trunk. However you can remove it from the trunk. If you remove it from the trunk and change the native VLAN for the trunk, VTP will then use the new native VLAN for updates. best regards Michel On 25/08/2008, Mike Louis [EMAIL PROTECTED] wrote: List, I just read in a practice test for an upcoming cert that Vlan 1 is used to carry VTP advertisements. However, it is possible to prune vlan 1 from trunk links. Will VTP continue to function without Vlan 1 being enabled on the link? Has this changed in more recent IOS releases? Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please
Re: [c-nsp] VTP and Vlan 1
Hi Michel, You may have been right the first time there. I think VTP does indeed use the native vlan, not necessarily vlan 1. DTP is also sent on the native vlan, untagged and tagged in its case. Paul. Michel Grossenbacher wrote: A little correction on my answer, VTP does not use the Native VLAN :-) Here is what I found regarding the use of VTP and VLAN1: The Case of VLAN 1 You cannot apply VTP pruning to VLANs that need to exist everywhere and that need to be allowed on all switches in the campus, in order to be able to carry VTP, Cisco Discovery Protocol [CDP] traffic, and other control traffic. However, there is a way to limit the extent of VLAN 1. The feature is called VLAN 1 disable on trunk. The feature is available on Catalyst 4500/4000, 5500/5000, and 6500/6000 series switches in CatOS software release 5.4(x) and later. The feature allows you to prune VLAN 1 from a trunk, as you do for any other VLAN. This pruning does not include all the control protocol traffic that is still allowed on the trunk (DTP, PAgP, CDP, VTP, and others). However, the pruning does block all user traffic on that trunk. With this feature, you can keep the VLAN from spanning the entire campus. STP loops are limited in extent, even in VLAN 1. Configure VLAN 1 to be disabled, as you would configure other VLANs to be cleared from the trunk: UDLD uses native VLAN in order to talk to the neighbor. So, in a trunk port, the native VLAN must not be pruned in order for UDLD to work properly. http://www.cisco.com/en/US/tech/tk389/tk689/technologies_tech_note09186a0080890613.shtml Sorry for the confusion. best regards Michel On 25/08/2008, Michel Grossenbacher [EMAIL PROTECTED] wrote: Hi Mike Actually VLAN 1 is not pruning-eligible so you can not prune VLAN 1 from a trunk. However you can remove it from the trunk. If you remove it from the trunk and change the native VLAN for the trunk, VTP will then use the new native VLAN for updates. best regards Michel On 25/08/2008, Mike Louis [EMAIL PROTECTED] wrote: List, I just read in a practice test for an upcoming cert that Vlan 1 is used to carry VTP advertisements. However, it is possible to prune vlan 1 from trunk links. Will VTP continue to function without Vlan 1 being enabled on the link? Has this changed in more recent IOS releases? Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] OSPF point-to-point vs dr/bdr
I mistakenly thought you had replied to the previous message I received in that thread, which was about the RFC which covers multiple link state protocols. Can you explain what command you are advising us not to use, does it still exist? Is it a command which is protocol generic or are you talking about ip ospf network? Paul. Rodney Dunn wrote: Not sure. I didn't write it. ;) From a quick glance it seems to imply that type of behavior but I'm not aware it was ever really done. On Wed, Aug 20, 2008 at 07:42:13PM +0100, Paul Cosgrove wrote: I'm not sure I understand you there. Do you mean that the intention behind the draft RFC was for some form of point-to-point configuration command on the interface, which would apply to all link state routing protocols? Paul. Rodney Dunn wrote: There was a point to point configuration on the link itself and it caused a bunch of platform forwarding problems once. I wouldn't use that one. Note I'm not talking about the OSPF point to point control plane configuration. Rodney On Wed, Aug 20, 2008 at 07:43:51PM +0200, [EMAIL PROTECTED] wrote: These are all good points, and makes me wonder - if it's *known* that an Ethernet link will be used as a point to point link between two routers, why doesn't everybody configure it explicitly as a point to point link? I know we always do... The benefit/cost ratio is low. You aren't saving much be eliminating DR/BDR election, and it's just one more unnecessary tweak to keep track of. IMHO. Funny, we look at it exactly the opposite way. We're a service provider, and a large majority of the Ethernet links where we run an IGP are point to point links. So we have the point to point configuration as part of our standard config template, nothing extra to keep track of. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] OSPF point-to-point vs dr/bdr
Peter Rathlev wrote: On Wed, 2008-08-20 at 07:41 -0700, Kelvin Goei wrote: Want to ask, what is the benefit if we are using point-to-point for connection between each zones router to the core instead of using dr/bdr connection? Configuring a link as point-to-point means that OSPF skips the BR/BDR election, making the calculations a little simpler. Normally a multi-access media (like Ethernet) means the SPF algorithm has to use a trick to build a graph, since all graph links must exclusively be between two nodes. Electing a pseudo-node and treating the multi-access media like a star topology solves this, but makes the SPF graph more complex. Regards, Peter Just to add, just in case it isn't obvious from Peters comments, that the neighbor establishment can also be quicker since DR election does not occur. The wait timer, which is normally 40 seconds, does not need to be used. Paul. -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] OSPF point-to-point vs dr/bdr
I'm not sure I understand you there. Do you mean that the intention behind the draft RFC was for some form of point-to-point configuration command on the interface, which would apply to all link state routing protocols? Paul. Rodney Dunn wrote: There was a point to point configuration on the link itself and it caused a bunch of platform forwarding problems once. I wouldn't use that one. Note I'm not talking about the OSPF point to point control plane configuration. Rodney On Wed, Aug 20, 2008 at 07:43:51PM +0200, [EMAIL PROTECTED] wrote: These are all good points, and makes me wonder - if it's *known* that an Ethernet link will be used as a point to point link between two routers, why doesn't everybody configure it explicitly as a point to point link? I know we always do... The benefit/cost ratio is low. You aren't saving much be eliminating DR/BDR election, and it's just one more unnecessary tweak to keep track of. IMHO. Funny, we look at it exactly the opposite way. We're a service provider, and a large majority of the Ethernet links where we run an IGP are point to point links. So we have the point to point configuration as part of our standard config template, nothing extra to keep track of. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] multicast bringing big irons to their knees?
Hi Christian, You will need to explain more about the topology, your multicast setup and the traffic flows, for instance: - Are the foundary switches acting as your RPs? - Have you any other commands applied which will cause multicasts to be process switched? - Do you have high rates of multicast on the network? - Are you using any multicast groups which will appear the same as well known multicast groups at Layer 2 (e.g. x.0.0.1, x.0.0.2 etc)? If the Foundary switches are your RPs, the requirement to decapsulate register messages could explain why these are affected much more than your 6500s, 3750s and netscreens. 'ip pim register-rate-limit 5' applied to the cisco designated routers will help if that is the problem (not sure about equivalent netscreeen command). Paul. Christian MacNevin wrote: Hi I've only got the most superficial of ideas what's going on with this network, but i've been asked if there's any particular reason some Foundry switches would be being brought to their knees every time mcast is switched on in a network. 65s, 3750s and Netscreens all handle it fine. Given Foundry's marketing, they dobrag that everything's handled in port-based ASICs, but obviously it sounds like this stuff is going to the processor. Maybe it's PIM Sniffing not supported in hardware, not sure. Anyway, sorry for the amazing vagary here, but it's all I've got right now. Any thoughts? Cheers Christian___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] 2851 and full BGP
Hi Chuck, Jay will be able to clarify, but I took the following to mean that the two are separated via third party infrastructure: two 2851s connected to each other over gigabit Ethernet WAN. May well be a bug though. Paul. Church, Charles wrote: Wasn't the original problem the iBGP connection over his own network? Sounds like a bug more than anything else. Chuck - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Sun Aug 10 15:52:03 2008 Subject: Re: [c-nsp] 2851 and full BGP Keep in mind that if the peerings are not between directly connected IP, disabling PMTUd for BGP will cause it to use an MSS of 536 bytes. You could check the achievable MTU using extended pings with the DF bit set, and compare it with the segment size listed by BGP before you decide whether to make that change. Paul. Mark Tinka wrote: On Saturday 09 August 2008 10:28:40 Jay Nakamura wrote: Any ideas on what could be causing this issue? Is there a better IOS version to use? Sounds like an MTU issue. Try disabling TCP PMTUd for BGP and see if that helps: router bgp 1234 no bgp transport path-mtu-discovery If that works, consider checking with your provider on the supported MTU, end-to-end, and adjust your interface MTU if it helps. Cheers, Mark. ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] 2851 and full BGP
border2-indy#sh ip bgp neighbors X.X.X.X BGP neighbor is X.X.X.X, remote AS , internal link BGP version 4, remote router ID X.X.X.X BGP state = Established, up for 3d04h Last read 00:00:39, last write 00:00:31, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(new) Address family IPv4 Unicast: advertised and received Message statistics: InQ depth is 0 OutQ depth is 0 Sent Rcvd Opens: 9 9 Notifications: 1 4 Updates: 144559 224571 Keepalives: 4590 4585 Route Refresh: 0 0 Total: 149155 229172 Default minimum time between advertisement runs is 0 seconds For address family: IPv4 Unicast BGP table version 2377206, neighbor version 2377206/0 Output queue size : 0 Index 2, Offset 0, Mask 0x4 2 update-group member Inbound soft reconfiguration allowed Outgoing update prefix filter list is INDY_NET Sent Rcvd Prefix activity: Prefixes Current: 9 7 (Consumes 364 bytes) Prefixes Total: 9 8 Implicit Withdraw: 0 0 Explicit Withdraw: 0 1 Used as bestpath: n/a 7 Used as multipath:n/a 0 OutboundInbound Local Policy Denied Prefixes:--- prefix-list 458047 0 Bestpath from this peer: 9n/a Total: 458056 0 Number of NLRIs in the update sent: max 1135, min 0 Address tracking is enabled, the RIB does have a route to X.X.X.X Connections established 9; dropped 8 Last reset 3d04h, due to BGP Notification sent, illegal header length Transport(tcp) path-mtu-discovery is enabled Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255 Local host: Y.Y.Y.Y, Local port: 179 Foreign host: X.X.X.X, Foreign port: 51918 Connection tableid (VRF): 0 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0x10A0F458): Timer StartsWakeupsNext Retrans 4578 46 0x0 TimeWait0 0 0x0 AckHold 4532 4200 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger0 0 0x0 DeadWait0 0 0x0 Linger 0 0 0x0 ProcessQ0 0 0x0 iss: 3518332904 snduna: 3518419158 sndnxt: 3518419158 sndwnd: 16080 irs: 3264861958 rcvnxt: 3264948267 rcvwnd: 16004 delrcvwnd:380 SRTT: 304 ms, RTTO: 335 ms, RTV: 31 ms, KRTT: 0 ms minRTT: 4 ms, maxRTT: 468 ms, ACK hold: 200 ms Status Flags: passive open, gen tcbs Option Flags: nagle, path mtu capable IP Precedence value : 6 Datagrams (max data segment is 536 bytes): Rcvd: 8953 (out of order: 0), with data: 4533, total data bytes: 86308 Sent: 8920 (retransmit: 46, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 4532, total data bytes: 86253 Packets received in fast path: 0, fast processed: 0, slow path: 0 fast lock acquisition failures: 0, slow path: 0 On Mon, Aug 11, 2008 at 9:18 AM, Church, Charles [EMAIL PROTECTED]wrote: Oh, yeah. Sorry, I didn't catch the 'WAN' part of it the first time. That does make MTU a possibility. But didn't he get like 20% of his routes before the error message? Since it was 12.4(20)T (pretty bleeding edge), I'd lean towards that still. I'd think that an MTU problem would show up way before you got to 20%. Does BGP set the DF bit? Chuck -Original Message- From: Paul Cosgrove [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2008 4:33 AM To: Church, Charles Cc: [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 2851 and full BGP Hi Chuck, Jay will be able to clarify, but I took the following to mean that the two are separated via third party infrastructure: two 2851s connected to each other over gigabit Ethernet WAN. May well be a bug though. Paul. Church, Charles wrote: Wasn't the original problem the iBGP connection over his own network? Sounds like a bug more than anything else. Chuck - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Sun Aug 10 15:52:03 2008 Subject: Re: [c-nsp] 2851 and full BGP Keep in mind that if the peerings are not between directly connected IP, disabling PMTUd
Re: [c-nsp] 2851 and full BGP
Forgot to cc the list on this earlier email. Paul Cosgrove wrote: Hi Chuck, Indeed it is apparently more than that: Jay mentioned receiving 20,000 routes before he sees the issue, so I guess about 75%. I had similar thoughts about this but wasn't (and still am not) sure how frequently in practice BGP with a full table is likely to have to send large updates. My (admittedly basic) understanding is that individual update messages contain details about prefixes which share the same attributes. If the attributes are different, different update messages will be used. If I have this right, the number of update messages will vary according to the number of distinct attribute sets, and the size of each update varies according to the number of NLRI which have those particular attributes. This makes me think that MTU issues could indeed occur at any point during the update process. A software bug might indeed turn out to be the cause, but I wouldn't rule MTU issues out at this stage. Paul. Church, Charles wrote: Oh, yeah. Sorry, I didn't catch the 'WAN' part of it the first time. That does make MTU a possibility. But didn't he get like 20% of his routes before the error message? Since it was 12.4(20)T (pretty bleeding edge), I'd lean towards that still. I'd think that an MTU problem would show up way before you got to 20%. Does BGP set the DF bit? Chuck -Original Message- From: Paul Cosgrove [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2008 4:33 AM To: Church, Charles Cc: [EMAIL PROTECTED]; cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 2851 and full BGP Hi Chuck, Jay will be able to clarify, but I took the following to mean that the two are separated via third party infrastructure: two 2851s connected to each other over gigabit Ethernet WAN. May well be a bug though. Paul. Church, Charles wrote: Wasn't the original problem the iBGP connection over his own network? Sounds like a bug more than anything else. Chuck - Original Message - From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: cisco-nsp@puck.nether.net cisco-nsp@puck.nether.net Sent: Sun Aug 10 15:52:03 2008 Subject: Re: [c-nsp] 2851 and full BGP Keep in mind that if the peerings are not between directly connected IP, disabling PMTUd for BGP will cause it to use an MSS of 536 bytes. You could check the achievable MTU using extended pings with the DF bit set, and compare it with the segment size listed by BGP before you decide whether to make that change. Paul. Mark Tinka wrote: On Saturday 09 August 2008 10:28:40 Jay Nakamura wrote: Any ideas on what could be causing this issue? Is there a better IOS version to use? Sounds like an MTU issue. Try disabling TCP PMTUd for BGP and see if that helps: router bgp 1234 no bgp transport path-mtu-discovery If that works, consider checking with your provider on the supported MTU, end-to-end, and adjust your interface MTU if it helps. Cheers, Mark. ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] 2851 and full BGP
Hi Antal, Is that a workaround for a specific bug? Usually the IP MTU defaults to the MTU. You can check them with show int vs show ip int. If the TCP session is between directly connected IPs, a TCP MSS equal to 40 byte less than the IP MTU is used. In other cases (e.g. peerings between loopbacks) an MSS 536 bytes is used unless PMTUD is enabled and can determine a higher value. Paul. Antal Gergely wrote: Jay Nakamura wrote: Datagrams (max data segment is 536 bytes): put a ip mtu 1500 on the wan interface. its not the same as mtu ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] 2851 and full BGP
Keep in mind that if the peerings are not between directly connected IP, disabling PMTUd for BGP will cause it to use an MSS of 536 bytes. You could check the achievable MTU using extended pings with the DF bit set, and compare it with the segment size listed by BGP before you decide whether to make that change. Paul. Mark Tinka wrote: On Saturday 09 August 2008 10:28:40 Jay Nakamura wrote: Any ideas on what could be causing this issue? Is there a better IOS version to use? Sounds like an MTU issue. Try disabling TCP PMTUd for BGP and see if that helps: router bgp 1234 no bgp transport path-mtu-discovery If that works, consider checking with your provider on the supported MTU, end-to-end, and adjust your interface MTU if it helps. Cheers, Mark. ___ 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] 2621xm vs 1800?
There is a nice index including this and other similar product comparisions (switch performance, vpn performance etc.) at:- http://www.cisco.com/web/partners/tools/quickreference/index.html Paul. Paul Stewart wrote: Thanks... that's actually the document I was looking for ;) Our theory to date on the issues with the 2621XM's is possibly the vendor itself and the memory they have been using. We have had a number of problems with a particular batch of them purchased a while ago and the 3rd party memory they are using specifically (we use 3rd party all the time with great success normally). Want to swap one of the sites that is having repeated issues and prove it's in the router somewhere or in the next hop device (wireless backhaul). Thanks, Paul -Original Message- From: Paul Cosgrove [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 15, 2008 2:50 PM To: Paul Stewart Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] 2621xm vs 1800? Very much an upgrade judging from the following table. More than double the PPS Mbps for Fast/CEF switched packets:- http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerp erformance.pdf Would be interesting to know the cause of the issue though, Paul. Paul Stewart wrote: Hi there... We have some remote sites with 2621XM's running today. These routers are doing PPPOE termination primarily for 40-60 users. The 2621XM is handling the load just fine however we've been having random problems with them lately and wanted to swap out the 2621XM for a different, more current model to see if the problem goes away (traffic just stops passing on the FE interfaces after a few weeks - tried multiple IOS versions - happening at several sites). My question is whether or not an 1841 would be a downgrade or an upgrade for PPS and overall load? Or should we just bite the bullet and get 2801's instead? Thanks, Paul ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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 2851 bug ?
Hi Rodney, Is that safe to do even if the traffic rate and/or cpu is high? Looks like a nice feature. Paul. Rodney Dunn wrote: Or you could load the new 12.4(20)T and set up a packet capture on the punt path. ;) rtp-rodunn-871#monitor capture point ip process-switched test in ? cr rtp-rodunn-871#monitor capture point ip process-switched rodney in rtp-rodunn-871#mon rtp-rodunn-871#monitor cap rtp-rodunn-871#monitor capture buf rtp-rodunn-871#monitor capture buffer pakdump ? circular Circular Buffer clear Clear contents of capture buffer exportExport in Pcap format filterConfigure filters limit Limit the packets dumped to the buffer linearLinear Buffer(Default) max-size Maximum size of element in the buffer (in bytes) size Packet Dump buffer size (in Kbytes) cr rtp-rodunn-871#monitor capture buffer pakdump Start the capture and export it to pcap. ;) This is new functionality in 12.4(20)T so we've got some enhancements to add to it. Rodney On Tue, Jul 15, 2008 at 08:06:26AM +0200, Pavel Skovajsa wrote: Hi, IP Input spike is usually caused by abnormal 'IP input' traffic that gets punted into the RP from CEF for whatever reason. A very common cause is broadcast storm. You can see what what packet is holding the CPU with 'show buffers input interface fa0/1'. However you need to do this command during a real spike... Pavel On Fri, Jul 11, 2008 at 10:47 PM, Teller, Robert [EMAIL PROTECTED] wrote: Is anyone aware of a bug or configuration that could cause a sudden spike in IP input? uptime is 26 weeks, 3 days, 10 hours, 54 minutes System returned to ROM by reload at 01:40:08 PST Tue Jan 8 2008 System restarted at 01:41:34 PST Tue Jan 8 2008 System image file is flash:c2800nm-ipbasek9-mz.124-17a.bin Cisco 2851 (revision 53.51) with 251904K/10240K bytes of memory. PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 66 125056 2917547 42 0.00% 0.00% 0.00% 0 CDP Protocol 6728872876 373263867 77 0.08% 51.78% 47.36% 0 IP Input Seattle-WAN 01:00:26 PM Friday Jul 11 2008 DST 58988 555446598432 100 90 ** 80 70 60* 50* 40* 30* 20* 10 *** *** 0511223344556 05050505050 CPU% per second (last 60 seconds) 999 1 566333443445333434346534453335336645645556354344 100 *** 90 #*** 80 ##** 70 ##** 60 ##** 50 ##** 40 ##** 30 ##** 20 ### * # 10 ###*** * * ** ** * # 0511223344556 05050505050 CPU% per minute (last 60 minutes) * = maximum CPU% # = average CPU% 1 1 11 1 111 11 11 1 712 1112 111 11211 691760977743309128787415602150180091972430809462896712922076244160072513 100 90 80 * 70 * 60 * 50 * 40 * 30 * * 20 * * * * ** ** * * * * ** * * * * * 10 051122334455667. . 050505050505 0 CPU% per hour (last 72 hours) * = maximum CPU% # = average CPU% # The information contained in this e-mail and subsequent attachments may be privileged, confidential and protected from disclosure. This transmission is intended
Re: [c-nsp] 2621xm vs 1800?
Very much an upgrade judging from the following table. More than double the PPS Mbps for Fast/CEF switched packets:- http://www.cisco.com/web/partners/downloads/765/tools/quickreference/routerperformance.pdf Would be interesting to know the cause of the issue though, Paul. Paul Stewart wrote: Hi there... We have some remote sites with 2621XM's running today. These routers are doing PPPOE termination primarily for 40-60 users. The 2621XM is handling the load just fine however we've been having random problems with them lately and wanted to swap out the 2621XM for a different, more current model to see if the problem goes away (traffic just stops passing on the FE interfaces after a few weeks - tried multiple IOS versions - happening at several sites). My question is whether or not an 1841 would be a downgrade or an upgrade for PPS and overall load? Or should we just bite the bullet and get 2801's instead? Thanks, Paul ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] Filter OSPF routes
Hi Ruben, What is the topology of the the border between you and the ISP? If there is a single connection between the ISP and (only) one of your routers there is no requirement for a dynamic protocol, just use static routes. No point waiting for routing protocol convergence if you don't need to. Sorry if this sounds obvious but the requirement isn't clear in your email. If you do need a dynamic protocol then you will want to minimise the possibility of changes elsewhere affecting the border routers (and vice versa). This might include link flaps causing spf recalculations, too many prefixes being advertised, duplicate router-ids, accidently injecting more specific routes etc. Using the same OSPF process would be a bad idea. Creating a separate OSPF process will certainly help. Using BGP would give you even more control, though you will need to look at reducing the default timers or using BFD to speed up BGP failover. BGP is often the preferred solution when connecting to a network you do not trust, but will need a little tweaking to speed it up (such as disabling fast-external-fallover on secondary paths). If you settle on OSPF then when selecting the network type, keep in mind that as well as not having slow hello/dead timers, you should also try to use a network type which does not require a DR. Using a DR when you don't need to slows down recovery after a failed link has been restored. Paul. Ruben Montes (Europe) wrote: Hello, We are running one OSPF process with several areas. The service provider is going to install one router on my network to provide an IPT service. We want this new router to only learn a group of networks where IP phones inside our network are located. We don't want them to learn any other route or have a default route to our network. I've been reviewing all the possibilities and I think the best approach is configure a second OSPF process and only allow redistribution of the desired networks. Prefix-list, distribute-list and different types of areas doesn't fit to our needs. Do you think the best approach is to use a second OSPF process? What things should I take care of? I can give more details if necessary. Regards, Ruben ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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 packets drop
Hi Alex, You mentioned changing the MTU on one interface, but to get a full adjacency this would of course need to on both routers (or set OSPF to ignore MTU values). I guess this is what you meant. Intermittent loss of small packets does not sound like an MTU problem though. When you ping across without using the tunnel, are you using the source and destination IP addresses which are configured on the tunnel? If parallel links and load sharing are used anywhere along the path the src/dst ip details may affect which link your pings traverse (and one could be dropping packets). If a hundred or so two hundred byte test pings do not show any errors, and if there is nothing unusual about the tunnel routers (e.g. high cpu, very low ospf timers or uplinks exceeding their provisioned rate), then it would be worth checking if the problem occurs any more frequently during working hours. There might be a QoS misconfiguration somewhere along the transit path. Are you using any form of encryption on this traffic? Something to consider once the packet loss is resolved perhaps. Paul. Alex Wa wrote: Hi, We're having a weird problem in one of our remote offices, connected through a GRE tunnel (using internet). The remote ISP, aparently is dropping randomly (or selectively) some GRE packets. when we ping the remote physical interface through the tunnel some packet drops are observed, but if icmp packets don't get into the tunnel they are never dropped. this is causing the ospf adjacencies to go down for no reason and is giving us a hard time. We've changed the tunel interface MTU to 1400, but it didn't work. besides OSPF's hello are less than a hundred octets, and i don't see a reason for the ISP dropping so small packets. The interface connected to the provider is a Gigabit Ethernet. Any suggestion to avoid this behaviour? any hint? Alejandro Wainshtok Network Engineer CCNP ___ 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] Multiple AS numbers
Hi Gary, I'm not completely clear on what your requirements are, but you may want to have a look at the 'local-as' bgp neighbor option. Will let your router behave like another ASN on that single peering. http://www.cisco.com/en/US/docs/ios/iproute/command/reference/irp_bgp3.html#wp1014448 Paul Gary Roberton wrote: Hello All I run an AS number but also want to run a second AS to advertise specific networks to an external BGP peer which I will do with a tunnel. However, can I run a second AS or do I specifically need to set up a stand alone router running its own instance of BGP just to send updates. Thanks Gary ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] ICMP Packet too big attack
Hi Alaerte, The attack is intended to force PMTUD to lower the outgoing packet size. This increases fragmentation of outgoing packets and thus load on the processor. Cisco IOS was modified to mitigate against, but not prevent, such attacks. I think the change was just to delay the response to such packets. Forget in which versions this was first implemented in but think it was about 18 months ago. Paul. [EMAIL PROTECTED] wrote: Hi, Have you heard about attacks trying to explore generation of packet too big ICMP messages? Tks, Alaerte ___ 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/ -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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
Hi Alaerte, This will be dependent on the hardware, traffic types, throughput and software version/configuration. You may need to explain a little more in order to get an adequate answer to your question. Large numbers of packets from a handful of hosts running PMTUD may require a smaller number of ICMP notifications than would be necessary for a larger number of hosts sending less traffic. The difference in the MTUs, and the sizes of the incoming packets will also affect the proportion of traffic which triggers notifications. Similarly protocols running on the router itself may require their packets to be fragmented. Paul. [EMAIL PROTECTED] wrote: Hi, Any document about how is the processing of a packet received on interface A toward interface B, where interface B has lower MTU than received packet and DF bit is set? (like description of the process) (considering CPU impact and if default limitation of ICMP generation enough when the number of packets is very high) Thanks, Alaerte ___ 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] Blocking VTP
Phil Mayers wrote: I'm sorry to say whether you believe it or not has little to do with the reality of the situation. To the best of my (by no means encyclopaedic) knowledge, there is no such thing. In any event, Tassos has already suggested: 1) make the port an access port 2) block 01-00-0C-CC-CC-CC (used by CDP too) 3) use transparent vtp v1 different domain 4) block vlan 1 (although actually that's not possible) Have you tried those? It seems like number 2 in a MAC ACL ought to be pretty bulletproof. __ 01-00-0C-CC-CC-CC is also used by a number of other protocols including PAgP, UDLD, DTP as well as CDP. You can differentiate VTP from these by specifying it's protocol type (0x2003). Regards, Paul. ___ 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] Blocking VTP
Hi Skeeve, Here are a couple of alternative ways you should be able to block VTP. You can the following on a trunk link by setting up two vtp servers (with same domain etc.) and watching the vtp traffic using debug sw-vlan vtp xmit and debug sw-vlan vtp packet. Add a filter to one switch and create additional new vlans on each device. The vlan map here will filter VTP from transiting on any vlan, not just stopping VTP being received by your device. You probably do not want to do this but it is useful for comparison purposes. Note that the acl required to do that is matching the traffic with a permit, not denying it. # MAC ACL mac access-list extended DENY-VTP deny any host 0100.0ccc. 0x2003 0x0 permit any any interface FastEthernet0/13 mac access-group DENY-VTP in # VLAN MAP = mac access-list extended MATCH-VTP permit any host 0100.0ccc. 0x2003 0x0 vlan access-map DENY-VTP 10 action drop match mac address MATCH-VTP vlan access-map DENY-VTP 20 action forward ! vlan filter DENY-VTP vlan-list 1-4094 Paul. Skeeve Stevens wrote: Hey Paul, You got an examples on how you would block this on the port with the protocol type and the MAC? I've never done MAC blocking, or protocol type probably easy though. ...Skeeve -Original Message- From: Paul Cosgrove [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 April 2008 8:13 PM To: Phil Mayers Cc: [EMAIL PROTECTED]; 'Gert Doering'; cisco-nsp@puck.nether.net; [EMAIL PROTECTED] Subject: Re: [c-nsp] Blocking VTP Phil Mayers wrote: I'm sorry to say whether you believe it or not has little to do with the reality of the situation. To the best of my (by no means encyclopaedic) knowledge, there is no such thing. In any event, Tassos has already suggested: 1) make the port an access port 2) block 01-00-0C-CC-CC-CC (used by CDP too) 3) use transparent vtp v1 different domain 4) block vlan 1 (although actually that's not possible) Have you tried those? It seems like number 2 in a MAC ACL ought to be pretty bulletproof. __ 01-00-0C-CC-CC-CC is also used by a number of other protocols including PAgP, UDLD, DTP as well as CDP. You can differentiate VTP from these by specifying it's protocol type (0x2003). Regards, Paul. ___ 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] Blocking VTP
Thanks for testing that Tassos, The protocol identifier field is five bytes long, and is divided into a three byte OUI (which isn't used) and the two byte ethertype. Paul. Tassos Chatzithomaoglou wrote: Paul, To be honest, i didn't think the mac acl would work using 0x2003 as an ethertype, because the value 0x2003 refers to the Local Code field (or Protocol Identifier (PID)) of the LLC/SNAP header. But i tried it and it worked. It also worked for UDLD (0x0111). I then found out that IEEE made it for backwards compatibility reasons with the Ethernet Version II format which used first the ethertype field. -- Tassos Paul Cosgrove wrote on 24/4/2008 4:20 μμ: As you probably know, while VTP is not particularly chatty, you will find the debugs easier to read if you also specify the interface you want i.e. debug interface fa0/13 Paul. Paul Cosgrove wrote: Hi Skeeve, Here are a couple of alternative ways you should be able to block VTP. You can test the following on a trunk link by setting up two vtp servers (with same domain etc.) and watching the vtp traffic using debug sw-vlan vtp xmit and debug sw-vlan vtp packet. Add a filter to one switch and create additional new vlans on each device. The vlan map here will filter VTP from transiting on any vlan, not just stopping VTP being received by your device. You probably do not want to do this but it is useful for comparison purposes. Note that the acl required to do that is matching the traffic with a permit, not denying it. # MAC ACL mac access-list extended DENY-VTP deny any host 0100.0ccc. 0x2003 0x0 permit any any interface FastEthernet0/13 mac access-group DENY-VTP in # VLAN MAP = mac access-list extended MATCH-VTP permit any host 0100.0ccc. 0x2003 0x0 vlan access-map DENY-VTP 10 action drop match mac address MATCH-VTP vlan access-map DENY-VTP 20 action forward ! vlan filter DENY-VTP vlan-list 1-4094 Paul. Skeeve Stevens wrote: Hey Paul, You got an examples on how you would block this on the port with the protocol type and the MAC? I've never done MAC blocking, or protocol type probably easy though. ...Skeeve -Original Message- From: Paul Cosgrove [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 April 2008 8:13 PM To: Phil Mayers Cc: [EMAIL PROTECTED]; 'Gert Doering'; cisco-nsp@puck.nether.net; [EMAIL PROTECTED] Subject: Re: [c-nsp] Blocking VTP Phil Mayers wrote: I'm sorry to say whether you believe it or not has little to do with the reality of the situation. To the best of my (by no means encyclopaedic) knowledge, there is no such thing. In any event, Tassos has already suggested: 1) make the port an access port 2) block 01-00-0C-CC-CC-CC (used by CDP too) 3) use transparent vtp v1 different domain 4) block vlan 1 (although actually that's not possible) Have you tried those? It seems like number 2 in a MAC ACL ought to be pretty bulletproof. __ 01-00-0C-CC-CC-CC is also used by a number of other protocols including PAgP, UDLD, DTP as well as CDP. You can differentiate VTP from these by specifying it's protocol type (0x2003). Regards, Paul. ___ 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/
Re: [c-nsp] rpf failure
Are you running PIM on TE1/1? Paul. Jay Young wrote: Does anyone have any pointers on how a 7609 RSP720 running 122-33.SRB2 builds the rpf table. rtr3#sh ip rpf x.y.x.19 failed, no route exists rtr3#sh ip route x.y.z.19 Routing entry for x.y.z.16/28 Known via ospf xxx, distance 110, metric 13, type intra area Last update from a.b.c.194 on TenGigabitEthernet1/1, 1d02h ago Routing Descriptor Blocks: * a.b.c.194, from a.b.c.3, 1d02h ago, via TenGigabitEthernet1/1 Route metric is 13, traffic share count is 1 I would think the unicast ospf route would be used, and is for some routes but not this one. Thanks, Jay ___ 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] Blocking VTP
Or maybe the OUI is used for VTP... http://www.cisco.com/warp/public/473/21.html Paul Cosgrove wrote: Thanks for testing that Tassos, The protocol identifier field is five bytes long, and is divided into a three byte OUI (which isn't used) and the two byte ethertype. Paul. Tassos Chatzithomaoglou wrote: Paul, To be honest, i didn't think the mac acl would work using 0x2003 as an ethertype, because the value 0x2003 refers to the Local Code field (or Protocol Identifier (PID)) of the LLC/SNAP header. But i tried it and it worked. It also worked for UDLD (0x0111). I then found out that IEEE made it for backwards compatibility reasons with the Ethernet Version II format which used first the ethertype field. -- Tassos Paul Cosgrove wrote on 24/4/2008 4:20 μμ: As you probably know, while VTP is not particularly chatty, you will find the debugs easier to read if you also specify the interface you want i.e. debug interface fa0/13 Paul. Paul Cosgrove wrote: Hi Skeeve, Here are a couple of alternative ways you should be able to block VTP. You can test the following on a trunk link by setting up two vtp servers (with same domain etc.) and watching the vtp traffic using debug sw-vlan vtp xmit and debug sw-vlan vtp packet. Add a filter to one switch and create additional new vlans on each device. The vlan map here will filter VTP from transiting on any vlan, not just stopping VTP being received by your device. You probably do not want to do this but it is useful for comparison purposes. Note that the acl required to do that is matching the traffic with a permit, not denying it. # MAC ACL mac access-list extended DENY-VTP deny any host 0100.0ccc. 0x2003 0x0 permit any any interface FastEthernet0/13 mac access-group DENY-VTP in # VLAN MAP = mac access-list extended MATCH-VTP permit any host 0100.0ccc. 0x2003 0x0 vlan access-map DENY-VTP 10 action drop match mac address MATCH-VTP vlan access-map DENY-VTP 20 action forward ! vlan filter DENY-VTP vlan-list 1-4094 Paul. Skeeve Stevens wrote: Hey Paul, You got an examples on how you would block this on the port with the protocol type and the MAC? I've never done MAC blocking, or protocol type probably easy though. ...Skeeve -Original Message- From: Paul Cosgrove [mailto:[EMAIL PROTECTED] Sent: Thursday, 24 April 2008 8:13 PM To: Phil Mayers Cc: [EMAIL PROTECTED]; 'Gert Doering'; cisco-nsp@puck.nether.net; [EMAIL PROTECTED] Subject: Re: [c-nsp] Blocking VTP Phil Mayers wrote: I'm sorry to say whether you believe it or not has little to do with the reality of the situation. To the best of my (by no means encyclopaedic) knowledge, there is no such thing. In any event, Tassos has already suggested: 1) make the port an access port 2) block 01-00-0C-CC-CC-CC (used by CDP too) 3) use transparent vtp v1 different domain 4) block vlan 1 (although actually that's not possible) Have you tried those? It seems like number 2 in a MAC ACL ought to be pretty bulletproof. __ 01-00-0C-CC-CC-CC is also used by a number of other protocols including PAgP, UDLD, DTP as well as CDP. You can differentiate VTP from these by specifying it's protocol type (0x2003). Regards, Paul. ___ 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/
[c-nsp] EEM/TCL availability on 3560/3750 IOS
Does anyone know when EEM and TCL were introduced into 3560/3750 software? Am unable to find any mention of them when I try to search the software advisor or release notes but they are alive and kicking in 12.2(44)SE1. Thanks, Paul. ___ 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] Wanting to learn Juniper...
Of course we also have no neighbor x.x.x.x peer-group MYPEERS, which rather than disassociating the neighbor from the peer group, will instead do the same as no neighbor x.x.x.x. Ben Steele wrote: That seems very intuitive to me, as soon as you understand that no in IOS removes/negates , means less commands which makes sense. Unless the term shutdown doesn't seem clear in an interface? I would assume it does to the majority of people though, IOS familiar or not. On 11/04/2008, at 3:43 PM, Jeremy Stretch wrote: Tolstykh, Andrew wrote: Cisco IOS is in fact extremely intuitive, there is nothing intuitive about the JunOS IMHO. I can't speak on JunOS, but considering that the IOS command to enable an interface is no shutdown, IOS may not be as intuitive as you think. stretch http://packetlife.net ___ 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/
[c-nsp] IOS XR Multicast RPF Check
Does anyone know the algorithm used to calculate the RPF interface in IOS XR? It does not appear to select the route with the lowest AD, unlike other IOS versions such as 12.0S. Seems to simply prefer multicast routes over unicast routes (e.g. mbgp over unicast bgp) without performing any initial AD check. Thanks, Paul. -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] External Firewall
Hi Sridhar, I'm afraid I haven't understood the significant of the firewall in your performance comparison tests between the cisco router and a BSD PC. Is the BSD PC the firewall you are referring to? Is your main aim to discover the reason why existing performance differs between the cisco and a BSD PC/router, or to test topology difference in two sites (only one of which has a firewall)? Perhaps the cisco outperforms a powerful PC because of the hardware assisted switching. The cisco router will use fast switching methods (e.g. CEF) to reduce the number of lookups and overall processing required by the main CPU. If I understand option (3) correctly, you wish to perform Multilayer Switching between a router and a stateful firewall. One difficulty I see with this is that in order for the firewall to perform stateful inspection, you will need to provide it with the traffic necessary to monitor the state of flows. Shifting a flow over to a path which cuts out the firewall will then deprive it of this information. This will limit its ability to function, for instance the firewall would not be able to detect when ports are negotiated within a session, or when a session ended. Consequently I think the only inspection that you would be able to achieve with that approach would be basic ACL style filtering; which is something you could do on the router in any case. Shifting the firewall so that it is not in the main transit path will also expose the edge router and the infrastructure behind it. Paul. Sridhar Ayengar wrote: Fred Reimer wrote: Why, exactly? Performance of the firewall? Yes. I have two identical networks setup for one company in two different locations. One has a Cisco router (said 7200) talking upstream to a big WAN pipe and downstream to two gigabit ethernet networks. The second location has the same WAN and LAN configuration, WAN line distance and quality measurement numbers, etc. The only difference it is a BSD PC. The Cisco performs noticeably and measurably better in latency and throughput. Neither is running firewall code. Now, the BSD PC has gobs more processor horsepower, memory- and bus-bandwidth. Why should the Cisco outperform it? To find out, I wanted to set up a selection of scenarios in the lab. (1) I wanted to try setting up the firewall between the internal gigabit network and the 7200. (2) I then wanted to setup the firewall between the WAN interface and the router to see how that performs. (3) I wanted to setup what I described in my original message, with the firewall performing only stateful inspection functions, and allowing the router to perform packet switching functions without interference from the firewall once the session is operating. As far as I can see, the advantage of (1) is that traffic heading to the external gigabit LAN wouldn't come across the firewall PC. However, the disadvantage would be that traffic between the two LANs would have to pass through it. That might be unacceptable. The advantage of (2) might be that traffic between the internal and external LANs wouldn't come near the firewall PC. Also, the WAN pipe may not require the throughput advantage of the Cisco. (It may indeed, but it might not be as sensitive.) However, this does add a couple dozen ms to the latency of the upstream connection. As far as I can tell, (3) would be the best of both worlds, but I, for the life of me, can't figure out if there's a way to set a network up like that. Any ideas? Peace... Sridhar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sridhar Ayengar Sent: Monday, March 24, 2008 1:31 PM To: Masood Ahmad Shah Cc: 'Cisco NSPs' Subject: Re: [c-nsp] External Firewall Masood Ahmad Shah wrote: Normally people would put like show below.. WAN-Router-Firewall--LAN-Switch That's what I was hoping to avoid. Peace... Sridhar ___ 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/
Re: [c-nsp] IOS 12.2(33)SRB2 clear arp-table
Hi Andrey, How are you detecting that the arp-table is spontaneously cleared? I'm wondering whether it is increasing in size before it clears, and whether it then immediately begins to increase again to normal levels. If there is a scan taking place on your network (e.g. virus or network discovery), then the router connected to the scanned subnet will have to try to resolve each destination IP address. Each arp will be a broadcast. If the subnet is large, and the scanning rate fast, then the arp table may be filled with incomplete entries and (I guess) old entries forced out. Incomplete entries are only kept for a few seconds, so when they expire you may end up with a relatively sudden decrease in table size. Paul. Andrey O.Sokolov wrote: На Fri, 7 Mar 2008 10:40:07 -0500 Jeff Fitzwater [EMAIL PROTECTED] записано: There are two things that the router does with its arp table... 1 It clears each hosts arp entry at some age interval, which can be changed. 2 It periodically updates its arp-cache by sending out a unicast arp for each arp entry it has. The periodic refresh might be what you are seeing. Without more details that's all I know. I have cisco7606 with sup32, IOS 12.2(33)SRB2, c7600s3223_rp- ADVIPSERVICESK9-M Periodically (sometimes time some minutes) spontaneously cleared arp-table on this device, and I have big broadcast flow on my network. What is this? Could someone help me solve this problem? Intervals are very-very different. From some minutes to some hours. And my device in at case sending out near 300 arp who-has inquiry per some milliseconds. -- HEAnet Limited Ireland's Education Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301 Please consider the environment before printing this e-mail. ___ 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] 3550 Port Fault that only forwards small packets
min/avg/max = 4/4/4 ms Sending 5, 1000-byte ICMP Echos to xx.xx.xx.xx, timeout is 2 seconds: .!!.. Success rate is 40 percent (2/5), round-trip min/avg/max = 4/6/8 ms Sending 5, 2000-byte ICMP Echos to xx.xx.xx.xx, timeout is 2 seconds: ..!!! Success rate is 60 percent (3/5), round-trip min/avg/max = 12/12/12 ms Sending 5, 2000-byte ICMP Echos to xx.xx.xx.xx, timeout is 2 seconds: ! Success rate is 20 percent (1/5), round-trip min/avg/max = 12/12/12 ms Hi Kevin, Do the switches show high cpu or high throughput on those ports? If you post the interface stats (e.g. show int switching, sh int, sh vlan) perhaps it will help. Are the two limits exactly 500 1000? I wasn't clear from your email if this was the case or if you were giving an approx range. Is there a very clear cut off after 1000 bytes, with no replies at all after that? If the switch IP and PC were in the same vlan then the only differences I can think of are that the extended ping may be sending at a faster rate than a windows ping; the frame size is different if you enter 1000 for each (the frame sent by windows would be 28 bytes larger); and the switch may perhaps(?) drop or rate limit locally generated/destined icmp before cef switched transit traffic if it is under heavy load. ICMP is not normally considered high priority traffic. What kind of traffic would you expect on the network, much multicasts or broadcasts for instance? Paul. ** This transmission is confidential and must not be used or disclosed by anyone other than the intended recipient. Neither Corus Group Limited nor any of its subsidiaries can accept any responsibility for any use or misuse of the transmission by anyone. For address and company registration details of certain entities within the Corus group of companies, please visit http://www.corusgroup.com/entities ** -- Paul Cosgrove HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ ___ 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] 3550 Port Fault that only forwards small packets
Hi Kevin, Do the switches show high cpu or high throughput on those ports? If you post the interface stats (e.g. show int switching, sh int, sh vlan) perhaps it will help. Are the two limits exactly 500 1000? I wasn't clear from your email if this was the case or if you were giving an approx range. Is there a very clear cut off after 1000 bytes, with no replies at all after that? If the switch IP and PC were in the same vlan then the only differences I can think of are that the extended ping may be sending at a faster rate than a windows ping; the frame size is different if you enter 1000 for each (the frame sent by windows would be 28 bytes larger); and the switch may perhaps(?) drop or rate limit locally generated/destined icmp before cef switched transit traffic if it is under heavy load. ICMP is not normally considered high priority traffic. What kind of traffic would you expect on the network, much multicasts or broadcasts for instance? Paul. [EMAIL PROTECTED] 1wrote: We use 3550-FX for fibre distribution and have had a couple of instances whe we've been investigating user complaints of a sudden onset of poor perfomance and found a port which has no errors of any kind will pass pings 500-1000 (btw the failure point is not around 1500) but no larger, also telnet sessions would intermittantly stutter if a long output say show tech was used. On one occasion, after moving the feed onto another port ( all working fine) and hanging a 2940 on the faulty port to do some testing I was baffled by the fact that an extended ping of 1K from a switch through this port would fail but a 1K DOS ping from a PC on the same box I was pinging from would succeed! The only measurable symptom of the fault is RX drops on the 2950 that was connected to the faulty port but I have too many of those to monitor with Solarwinds! I've now had this on 3 of 3550s along with hard port failures so we are moving to 3560s with m/c racks :-( 2 down 10 to go! Suggestions or comments welcomed. Kevin ** This transmission is confidential and must not be used or disclosed by anyone other than the intended recipient. Neither Corus Group Limited nor any of its subsidiaries can accept any responsibility for any use or misuse of the transmission by anyone. For address and company registration details of certain entities within the Corus group of companies, please visit http://www.corusgroup.com/entities ** ___ 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/ -- Paul Cosgrove HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ ___ 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] Application based rate limiting
Dracul wrote: Hi all, Need advice from the QOS experts, is there a way in cisco to rate-limit based on applications? let's say for example I just want to limit all P2P traffic and let the rest flow normally. thanks, chris ___ 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/ You need to define a class-map matching the traffic you wish to limit, and then use a policy-map to set the QoS to be used for that class. Match protocol within the class-map utilises NBAR to identify the traffic. Unmatched traffic matches class-default which you do not need to create. class-map match-any P2P match protocol napster match protocol kazaa2 match protocol edonkey match protocol fasttrack match protocol gnutella match protocol winmx match protocol bittorrent policy-map P2P-Policy class P2P police cir 8000 bc 1000 be 1000 conform-action transmit exceed-action drop interface Fa0/0 service-policy input P2P-Policy Keep in mind that NBAR can incorrectly classify legitimate traffic, so it is worth checking the ports for anything you need to match by using show ip nbar port-map protocol. If necessary you can explicitly permit traffic which is being incorrectly detected by creating another class for it. The following example shows an exception created to prevent valid traffic being classed as napster. access-list 160 permit tcp any host 192.1.1.1 eq access-list 160 permit tcp host 192.1.1.1 eq any class-map match-all Legitimate-TCP- match access-group 160 ! ! policy-map P2P-Policy class Legitimate-TCP- police cir 1000 conform-action transmit exceed-action transmit class P2P police cir 8000 bc 1000 be 1000 conform-action transmit exceed-action drop Classification and other QoS capabilities are obviously different depending on your version of IOS, so you need to check the documention to see what is supported. You can find some more information at the following link: http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part05/ch05/hdtnbara.htm#wp1079748 You may need to load individual PDLM update files containing information on the protocols you wish to match, e.g. ip nbar pdlm flash:bittorrent.pdlm You will also want to test it out to check for any CPU hit http://www.cisco.com/en/US/products/ps6616/products_white_paper0900aecd8031b712.shtml Paul. -- Paul Cosgrove HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ ___ 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] securing a vrrp setup
The mac acl I included as an example should not have been so specific. The packet that the attacker sends does not need to be a VRRP IP packet. Any frame sent from the VRRP group mac address would cause an update in the switch CAM table, so the mac address acl should filter all frames with a source address in the VRRP range instead of just ARPs. The IP information does not need to match in order for this to happen, any IP details could be included as the switch is only being interested in layer 2. A frame sent with the VRRP group mac address as it's source, and another known mac address (say of a host) as the destination would not arrive at the legitimate VRRP router so would generate no messages. Paul. bangky wrote: Hi Paul, Thanks for suggesting IP source guard. I have previously heard of this but have only just read up on what exactly it does. It should be a suitable solution for this problem. Joerg mentioned that syslog traps will be activated if the master changes, however both routers will see themselves as the master and neither will relinquish that status for an apparently misconfigured neighbor. Btw, with regards to the above, while trapping may not occur as there is no change of master status, IIRC there will be notification of a VRRP message received with incorrect authentication information. Once again, thanks to all who have kindly suggested solutions to my query. -- bangky Paul Cosgrove wrote: Joerg mentioned that syslog traps will be activated if the master changes, however both routers will see themselves as the master and neither will relinquish that status for an apparently misconfigured neighbor. If an attacker configures a rogue VRRP server with the same virtual IP as the legitimate server, but different authentication, they may use the same or a different VRRP group number. With the same group number the switch would alternate between directing traffic to the legitimate server and to the rogue server, as its CAM entry was changed by packets being sent by each device (such as VRRP hellos). I guess that if the rogue server uses a different VRRP group as well then the ARP entries on other devices for the VRRP virtual IP address may also change. On occasions I think this can cause the two routers to continue repeating arp replies in an attempt to override the other router's response, resulting in flapping in the arp table of the client which originated the arp request. If I understand you correctly then the attack would really be aimed at a Virtual IP/MAC address, so it is a generic attack aimed at the layers underneath VRRP. Similar effects would be seen if you targeted an OSPF next hop or HSRP address instead. As Joerg mentioned, if you want to stop this you could apply mac and ip access-lists to switch access ports, e.g. ip access-list standard 1 deny vrrp ip address permit any mac access-list extended DENY-ARP-FROM-VRRP deny .5e00.0100 0.0.00FF any 0x806 0x0 permit any any int range fa0/1 ip access-group 1 in mac access-group DENY-ARP-FROM-VRRP in You could instead use IP Source Guard and Dynamic ARP inspection, which would offer broader protection. Paul. ___ 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] securing a vrrp setup
Joerg mentioned that syslog traps will be activated if the master changes, however both routers will see themselves as the master and neither will relinquish that status for an apparently misconfigured neighbor. If an attacker configures a rogue VRRP server with the same virtual IP as the legitimate server, but different authentication, they may use the same or a different VRRP group number. With the same group number the switch would alternate between directing traffic to the legitimate server and to the rogue server, as its CAM entry was changed by packets being sent by each device (such as VRRP hellos). I guess that if the rogue server uses a different VRRP group as well then the ARP entries on other devices for the VRRP virtual IP address may also change. On occasions I think this can cause the two routers to continue repeating arp replies in an attempt to override the other router's response, resulting in flapping in the arp table of the client which originated the arp request. If I understand you correctly then the attack would really be aimed at a Virtual IP/MAC address, so it is a generic attack aimed at the layers underneath VRRP. Similar effects would be seen if you targeted an OSPF next hop or HSRP address instead. As Joerg mentioned, if you want to stop this you could apply mac and ip access-lists to switch access ports, e.g. ip access-list standard 1 deny vrrp ip address permit any mac access-list extended DENY-ARP-FROM-VRRP deny .5e00.0100 0.0.00FF any 0x806 0x0 permit any any int range fa0/1 ip access-group 1 in mac access-group DENY-ARP-FROM-VRRP in You could instead use IP Source Guard and Dynamic ARP inspection, which would offer broader protection. Paul. ___ 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/
