From the Mankato Networks remote switch I'm able to get to everything except for carriers on the CNS remote switch.
On Sat, May 25, 2013 at 6:46 AM, Kelly Cochran (Hurricane Electric Internet Services) <noc@he.net> wrote:
Are you aware of any partitions on the exchange? We're only seeing other people on the CNS switch that we're on.
-- -H U R R I C A N E - E L E C T R I C- Kelly Cochran Sr. Network Engineer 510-580-4100 http://www.he.net/ AS6939
-- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke@mankatonetworks.net http://www.mankatonetworks.com http://www.neutralpath.net ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On 5/25/2013 9:13 AM, Jay Hanke wrote:
From the Mankato Networks remote switch I'm able to get to everything except for carriers on the CNS remote switch.
I can't ping HE (bgp session with them has been down since 00:58:04) who is on the remote switch, but I also see weirdness pinging the route servers: r-pop-min-1#ping 206.108.255.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms r-pop-min-1#ping 206.108.255.1 source loop1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: Packet sent with a source address of 205.173.182.62 ..... Success rate is 0 percent (0/5) r-pop-min-1# Do the route servers not use the routes they receive and use a provider on the CNS switch for transit? -James
On Sat, May 25, 2013 at 6:46 AM, Kelly Cochran (Hurricane Electric Internet Services)<noc@he.net> wrote:
Are you aware of any partitions on the exchange? We're only seeing other people on the CNS switch that we're on.
-- -H U R R I C A N E - E L E C T R I C- Kelly Cochran Sr. Network Engineer 510-580-4100 http://www.he.net/ AS6939
-- Jay Hanke CTO, CCIE #19093 Mankato Networks LLC PO Box 54 619 S Front St Mankato, MN 56001-3838 Google 530-618-2398 jayhanke@mankatonetworks.net http://www.mankatonetworks.com http://www.neutralpath.net
########################################################################
To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
On 05/25/2013 09:42 AM, James Stahr wrote:
On 5/25/2013 9:13 AM, Jay Hanke wrote:
From the Mankato Networks remote switch I'm able to get to everything except for carriers on the CNS remote switch.
I can't ping HE (bgp session with them has been down since 00:58:04) who is on the remote switch, but I also see weirdness pinging the route servers:
r-pop-min-1#ping 206.108.255.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms r-pop-min-1#ping 206.108.255.1 source loop1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: Packet sent with a source address of 205.173.182.62 ..... Success rate is 0 percent (0/5) r-pop-min-1#
Do the route servers not use the routes they receive and use a provider on the CNS switch for transit?
-James
On Sat, May 25, 2013 at 6:46 AM, Kelly Cochran (Hurricane Electric Internet Services)<noc@he.net> wrote:
Are you aware of any partitions on the exchange? We're only seeing other people on the CNS switch that we're on.
-- -H U R R I C A N E - E L E C T R I C- Kelly Cochran Sr. Network Engineer 510-580-4100 http://www.he.net/ AS6939
It looks like something happened last night between the CNS & Main CNS switches. The CNS switch showed the following in its log: May 24 21:31:26.315 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk TenGigabitEthernet0/10 VLAN847. May 24 21:31:26.315 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type. May 24 22:49:51.831 CDT: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking TenGigabitEthernet0/10 on VLAN0847. Port consistency restored. May 25 00:57:45.614 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk TenGigabitEthernet0/10 VLAN847. May 25 00:57:45.614 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type. I added a "spanning-tree bpdufilter enable" on the port that points toward the main CNS switch to solve the problem. This solved the problem for now. But, it might be nice if the technical committee could come up some technical guidelines for spanning-tree that will work for MICE. Thanks, Steve ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
I'm able to see HE now, and all of my other sessions have been up since last night…anyone aware of any maintenances or any changes made last night ~21:30 that may have caused this? While it worked for now, disabling spanning tree and/or bpdus on two switches that are in the same infrastructure seems like a band-aid…disabling facing client ports or uplinks I can see though. I think this could use a little more technical review at some point. Chris On May 25, 2013, at 10:23 AM, Steve Howard wrote: On 05/25/2013 09:42 AM, James Stahr wrote: On 5/25/2013 9:13 AM, Jay Hanke wrote:
From the Mankato Networks remote switch I'm able to get to everything except for carriers on the CNS remote switch.
I can't ping HE (bgp session with them has been down since 00:58:04) who is on the remote switch, but I also see weirdness pinging the route servers: r-pop-min-1#ping 206.108.255.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms r-pop-min-1#ping 206.108.255.1 source loop1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: Packet sent with a source address of 205.173.182.62 ..... Success rate is 0 percent (0/5) r-pop-min-1# Do the route servers not use the routes they receive and use a provider on the CNS switch for transit? -James On Sat, May 25, 2013 at 6:46 AM, Kelly Cochran (Hurricane Electric Internet Services)<noc@he.net<mailto:noc@he.net>> wrote: Are you aware of any partitions on the exchange? We're only seeing other people on the CNS switch that we're on. -- -H U R R I C A N E - E L E C T R I C- Kelly Cochran Sr. Network Engineer 510-580-4100 http://www.he.net/ AS6939 It looks like something happened last night between the CNS & Main CNS switches. The CNS switch showed the following in its log: May 24 21:31:26.315 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk TenGigabitEthernet0/10 VLAN847. May 24 21:31:26.315 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type. May 24 22:49:51.831 CDT: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking TenGigabitEthernet0/10 on VLAN0847. Port consistency restored. May 25 00:57:45.614 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk TenGigabitEthernet0/10 VLAN847. May 25 00:57:45.614 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type. I added a "spanning-tree bpdufilter enable" on the port that points toward the main CNS switch to solve the problem. This solved the problem for now. But, it might be nice if the technical committee could come up some technical guidelines for spanning-tree that will work for MICE. Thanks, Steve ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 Chris Scheidecker - Infrastructure Engineer Atomic Data 615 North 3rd Street Minneapolis, MN 55401 612.466.2000 Main Line 612.466.2044 Direct Dial Twitter<http://twitter.com/AtomicData> | Facebook<http://www.facebook.com/AtomicDataCenters> | LinkedIn<http://www.linkedin.com/companies/atomic-data-centers> Simple. Safe. Smart. www.atomicdata.com<http://www.atomicdata.com/> This message and any information or attachments included therewith is intended only for the individual or entity named above. If the reader is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copy of this message or any information attached or contained therein is strictly prohibited. If you have received this message in error, please notify the sender by return e-mail and destroy all copies of the message and any attachments. Thank you. Please consider the environment before printing this email. ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
There are some fun interoperability quirks with Cisco PVST where it will declare the port inconsistent if it receives a PVST BPDU with the wrong VLAN encoded in it (e.g. BPDU says VLAN 10, but tag is something different). In this case, it's a non-trunk port receiving a PVST BPDU. If someone originates such a BPDU towards their interface on a MICE cisco switch, then it will place just their port into this inconsistent state. If their port happens to be on a non-cisco switch that doesn't know what PVST is, it will happily "tunnel" it, usually causing the uplinks on any connected Cisco switches that receive it to go into this inconsistent state. An ingress MAC ACL on the customer-facing ports of the non-cisco switches to block 0100.0CCC.CCCD should prevent this from happening, while leaving IEEE STP BPDUs alone. There's no way to change this behavior in Cisco switches AFAIK (aside from running bpdufilter of course). If it's not this way already, it would be best to run MST for inter-op with the Cisco switches if multiple VLANs will be connected. Though even when running MST, Cisco switches still run "PVST+ Emulation," so tunneled PVST+ BPDUs will provide the same excitement as before. Regardless of any amount of STP tweaking on MICE switches, there is still the risk that a dual-connected customer could cause a loop. Storm-control can help there to at least constrain the amount of broadcast and multicast traffic that ends up looping. Steven Bertsch Engineer III VISI, a TDS® Company 24x7 Support: 612.395.9010 Direct: 612.395.8966 Main: 612.395.9000 Email: support@visi.com Web: www.visi.com -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Steve Howard Sent: Saturday, May 25, 2013 10:24 AM To: MICE-DISCUSS@LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] [#2175746] MICE reachability On 05/25/2013 09:42 AM, James Stahr wrote:
On 5/25/2013 9:13 AM, Jay Hanke wrote:
From the Mankato Networks remote switch I'm able to get to everything except for carriers on the CNS remote switch.
I can't ping HE (bgp session with them has been down since 00:58:04) who is on the remote switch, but I also see weirdness pinging the route servers:
r-pop-min-1#ping 206.108.255.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms r-pop-min-1#ping 206.108.255.1 source loop1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 206.108.255.1, timeout is 2 seconds: Packet sent with a source address of 205.173.182.62 ..... Success rate is 0 percent (0/5) r-pop-min-1#
Do the route servers not use the routes they receive and use a provider on the CNS switch for transit?
-James
On Sat, May 25, 2013 at 6:46 AM, Kelly Cochran (Hurricane Electric Internet Services)<noc@he.net> wrote:
Are you aware of any partitions on the exchange? We're only seeing other people on the CNS switch that we're on.
-- -H U R R I C A N E - E L E C T R I C- Kelly Cochran Sr. Network Engineer 510-580-4100 http://www.he.net/ AS6939
It looks like something happened last night between the CNS & Main CNS switches. The CNS switch showed the following in its log: May 24 21:31:26.315 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk TenGigabitEthernet0/10 VLAN847. May 24 21:31:26.315 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type. May 24 22:49:51.831 CDT: %SPANTREE-2-UNBLOCK_CONSIST_PORT: Unblocking TenGigabitEthernet0/10 on VLAN0847. Port consistency restored. May 25 00:57:45.614 CDT: %SPANTREE-7-RECV_1Q_NON_TRUNK: Received 802.1Q BPDU on non trunk TenGigabitEthernet0/10 VLAN847. May 25 00:57:45.614 CDT: %SPANTREE-7-BLOCK_PORT_TYPE: Blocking TenGigabitEthernet0/10 on VLAN0847. Inconsistent port type. I added a "spanning-tree bpdufilter enable" on the port that points toward the main CNS switch to solve the problem. This solved the problem for now. But, it might be nice if the technical committee could come up some technical guidelines for spanning-tree that will work for MICE. Thanks, Steve ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 ######################################################################## To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1
participants (5)
-
Bertsch, Steven -
Chris Scheidecker -
James Stahr -
Jay Hanke -
Steve Howard