From foundry-nsp at pgmail.net Thu Sep 2 07:53:53 2010 From: foundry-nsp at pgmail.net (Philipp Geschke) Date: Thu, 02 Sep 2010 13:53:53 +0200 Subject: [f-nsp] Problem with IPv6 anycast Message-ID: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Hello, I seem to have issues understanding IPv6 anycast on NI MLX/XMR. My understanding is, that any router that does have an IPv6 address in a subnet should be listening on the Subnet-Router anycast address (RFC3513 section 2.6.1). When I configure an IPv6 unicast address on a MLX VE it shows that it joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): Interface VE 200 is up, line protocol is up [...] IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 [Preferred] Global unicast address(es): 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 Joined group address(es): ff02::1:ff00:1 ff02::1:ff00:0 ff02::1:ff00:2 ff02::1:ffe1:2f00 ff02::2 ff02::1 [...] Now when I try to ping that address from a client within the network 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX announcing it's UNIcast address: 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:f1:c:: source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags [router, solicited] destination link-address option (2), length 8 (1): 00:0c:db:e1:2f:00 0x0000: 000c dbe1 2f00 This causes the asking client to create an entry in its neighbour cache for the routers unicast address, but not realising, that this was the answer to its question, hence it keeps on sending solicitation messages for the anycast address. In my understanding the neighbour advertisement should have the unicast address as source, but should announce the anycast address. If I take a Linux box and enable ip6 forwarding in the kernel, it also joins that very same anycast group. If I do the same test again, you can see, that the Linux box answers with its unicast address, announcing the anycast address: 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, solicited] destination link-address option (2), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 This works and the client creates an entry in its neighbour cache for the anycast address and can now communicate with the address. Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 you can see in the output of the interface. If it matters, I do have ipv6 nd suppress-ra active on that VE. So what does this mean, is it a) Me not understanding the concept of the anycast address (basicaly I want to use it as a default gateway)? b) A problem with my configuration (which is pretty plain for v6 right now)? c) A bug? d) ?? Does anyone have experience with that they are able to share? Thanks for any hints, Philipp From rob.lister at netsumo.com Thu Sep 2 13:32:03 2010 From: rob.lister at netsumo.com (Rob Lister) Date: Thu, 2 Sep 2010 18:32:03 +0100 Subject: [f-nsp] Enabling Q-in-Q on RX Message-ID: <20100902173203.GA12418@netsumo.com> Greetings, I have a customer that would like us to enable a q-in-q trunk across a network of RX-8s, and the documentation seems a little vague in places. If anyone has enabled this on RX / XMR platform, I would greatly appreciate any advice on what happens when it's enabled. The documentation for RX suggests doing: BigIron RX(config)# tag-type 9100 e3/1 to 3/2 BigIron RX(config)# aggregated-vlan 1. What is the interaction between the 'aggregated-vlan' command and the default-max-frame-size on RX? Behaviour of the smaller (non-RX) switches: SW3(config)#default-mtu 1600 Aggregated VLAN is in effect.10/100M ports will be set to default MTU 1530. SW3#show int ethe 3 FastEthernet3 is down, line protocol is down ... MTU 1530 bytes, encapsulation ethernet ... ... After reload, however, it sets it back to 1600. The RX doesn't quite have the same options, however, but doesn't suggest a frame limit for aggregated-vlan. So.. on an RX q-in-q port, what can the maximum MTU be? What's the default "mini-jumbo" frame size? RX: SSH at RX-8(config)#agg? aggregated-vlan Allow mini-jumbo frames to allow multiple vlan tags FI4802: SW3(config)#agg aggregated-vlan support for larger Ethernet frame up to 1530 bytes 2. Changing tag-type on the RX. Documentation points out that it will change it for a port region, not just the ports involved. "Note that since ports 11 and 12 belong to the port region 1 ? 12, the 802.1Q tag actually applies to ports 1 ? 12." It doesn't say what happens to the other ports, though. Does this mean that we cannot use the other ports not involved in the q-in-q configuration for normal (non q-n-q traffic?) What happens if it receives normal untagged frames? The documentation is also unclear about port regions, as it then suggests, under "enabling 802.1q tag-type translation": "Note that since ports 11 and 12 belong to the port region 9 ? 16, the 802.1q tag-type actually applies to ports 9 ? 16." So which is it? A port region of 8 or 12 ports? I am thinking it's 12, as there is more mention of that. If anyone has set this up I would appreciate any pointers/hints! thanks, Rob From harbor235 at gmail.com Thu Sep 2 14:16:40 2010 From: harbor235 at gmail.com (harbor235) Date: Thu, 2 Sep 2010 14:16:40 -0400 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: Good question, RFC2526 hs more meat concerning anycast reserver addresses, I have a couple questions too; 1) Can you allocate additional anycast addresses out of the unicast space other than the 127-n bits identified? 2) how does your client machine behave when a reservered anycast address is used? On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke wrote: > Hello, > > I seem to have issues understanding IPv6 anycast on NI MLX/XMR. > My understanding is, that any router that does have an IPv6 address in a > subnet should be listening on the Subnet-Router anycast address (RFC3513 > section 2.6.1). > > When I configure an IPv6 unicast address on a MLX VE it shows that it > joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): > > Interface VE 200 is up, line protocol is up > [...] > IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 > [Preferred] > Global unicast address(es): > 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 > 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 > 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 > 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 > Joined group address(es): > ff02::1:ff00:1 > ff02::1:ff00:0 > ff02::1:ff00:2 > ff02::1:ffe1:2f00 > ff02::2 > ff02::1 > [...] > > Now when I try to ping that address from a client within the network > 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX announcing > it's UNIcast address: > > 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor > solicitation, length 32, who has 2001:db8:f1:c:: > source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload > length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, > neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags [router, > solicited] > destination link-address option (2), length 8 (1): > 00:0c:db:e1:2f:00 > 0x0000: 000c dbe1 2f00 > > This causes the asking client to create an entry in its neighbour cache > for the routers unicast address, but not realising, that this was the > answer to its question, hence it keeps on sending solicitation messages for > the anycast address. > In my understanding the neighbour advertisement should have the unicast > address as source, but should announce the anycast address. > > If I take a Linux box and enable ip6 forwarding in the kernel, it also > joins that very same anycast group. If I do the same test again, you can > see, > that the Linux box answers with its unicast address, announcing the > anycast address: > > 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor > advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, solicited] > destination link-address option (2), length 8 (1): > 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > > This works and the client creates an entry in its neighbour cache for the > anycast address and can now communicate with the address. > > Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 > you can see in the output of the interface. > > If it matters, I do have ipv6 nd suppress-ra active on that VE. > > > So what does this mean, is it > > a) Me not understanding the concept of the anycast address (basicaly I > want to use it as a default gateway)? > b) A problem with my configuration (which is pretty plain for v6 right > now)? > c) A bug? > d) ?? > > Does anyone have experience with that they are able to share? > > > Thanks for any hints, > Philipp > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Thu Sep 2 14:20:35 2010 From: harbor235 at gmail.com (harbor235) Date: Thu, 2 Sep 2010 14:20:35 -0400 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: There is more ....... On Thu, Sep 2, 2010 at 2:16 PM, harbor235 wrote: > Good question, RFC2526 hs more meat concerning anycast reserver addresses, > I have a couple questions too; > > 1) Can you allocate additional anycast addresses out of the unicast space > other than the 127-n bits identified? (n bits = subnet prefix) > > 2) how does your client machine behave when a reservered anycast address is > used? > all bits of the interface identifier are set to ones except the last 7 bits which range in value from 0-125 (126 and 127 are reserverd or assigned) 3) What OS was the original client machine? harbor235 ;} > > > > On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke wrote: > >> Hello, >> >> I seem to have issues understanding IPv6 anycast on NI MLX/XMR. >> My understanding is, that any router that does have an IPv6 address in a >> subnet should be listening on the Subnet-Router anycast address (RFC3513 >> section 2.6.1). >> >> When I configure an IPv6 unicast address on a MLX VE it shows that it >> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): >> >> Interface VE 200 is up, line protocol is up >> [...] >> IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 >> [Preferred] >> Global unicast address(es): >> 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 >> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >> 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 >> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >> Joined group address(es): >> ff02::1:ff00:1 >> ff02::1:ff00:0 >> ff02::1:ff00:2 >> ff02::1:ffe1:2f00 >> ff02::2 >> ff02::1 >> [...] >> >> Now when I try to ping that address from a client within the network >> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX >> announcing >> it's UNIcast address: >> >> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) >> 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor >> solicitation, length 32, who has 2001:db8:f1:c:: >> source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 >> 0x0000: 0016 3e19 16a9 >> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload >> length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, >> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags [router, >> solicited] >> destination link-address option (2), length 8 (1): >> 00:0c:db:e1:2f:00 >> 0x0000: 000c dbe1 2f00 >> >> This causes the asking client to create an entry in its neighbour cache >> for the routers unicast address, but not realising, that this was the >> answer to its question, hence it keeps on sending solicitation messages >> for >> the anycast address. >> In my understanding the neighbour advertisement should have the unicast >> address as source, but should announce the anycast address. >> >> If I take a Linux box and enable ip6 forwarding in the kernel, it also >> joins that very same anycast group. If I do the same test again, you can >> see, >> that the Linux box answers with its unicast address, announcing the >> anycast address: >> >> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) >> 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor >> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, >> solicited] >> destination link-address option (2), length 8 (1): >> 00:16:3e:19:16:a9 >> 0x0000: 0016 3e19 16a9 >> >> This works and the client creates an entry in its neighbour cache for the >> anycast address and can now communicate with the address. >> >> Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 >> you can see in the output of the interface. >> >> If it matters, I do have ipv6 nd suppress-ra active on that VE. >> >> >> So what does this mean, is it >> >> a) Me not understanding the concept of the anycast address (basicaly I >> want to use it as a default gateway)? >> b) A problem with my configuration (which is pretty plain for v6 right >> now)? >> c) A bug? >> d) ?? >> >> Does anyone have experience with that they are able to share? >> >> >> Thanks for any hints, >> Philipp >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foundry-nsp at pgmail.net Fri Sep 3 04:01:07 2010 From: foundry-nsp at pgmail.net (Philipp Geschke) Date: Fri, 03 Sep 2010 10:01:07 +0200 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: Hi, Thank you for your reply! On Thu, 2 Sep 2010 14:20:35 -0400, harbor235 wrote: > On Thu, Sep 2, 2010 at 2:16 PM, harbor235 wrote: > >> I have a couple questions too; >> >> 1) Can you allocate additional anycast addresses out of the unicast space >> other than the 127-n bits identified? (n bits = subnet prefix) >> If I get you correct (sorry if not, I am not a native speaker ;-)), then "ipv6 address 2001:db8:f1:c:1:2:3:fe/64 anycast" qualifies for this test? The result is pretty much the same, with the interesting fact, that the MLX announces it Link-Local address now: 09:55:10.233664 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > ff02::1:ff03:fe: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:f1:c:1:2:3:fe source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 09:55:10.233664 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:dbff:fee1:2f00 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, Flags [router, solicited, override] destination link-address option (2), length 8 (1): 00:0c:db:e1:2f:00 0x0000: 000c dbe1 2f00 >> 2) how does your client machine behave when a reservered anycast address >> is >> used? >> > all bits of the interface identifier are set to ones except the last > 7 bits which range in > value from 0-125 (126 and 127 are reserverd or assigned) > Using "ipv6 address 2001:db8:f1:c:ffff:ffff:ffff:ff7a/64 anycast", which, I think, qualifies for this test? 09:17:09.939237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > ff02::1:ffff:ff7a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:f1:c:ffff:ffff:ffff:ff7a source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 09:17:09.939237 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:dbff:fee1:2f00 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, Flags [router, solicited, override] destination link-address option (2), length 8 (1): 00:0c:db:e1:2f:00 0x0000: 000c dbe1 2f00 > 3) What OS was the original client machine? Everything used in my tests is either NI MLX with IronWare 05000b or plain Debian GNU/Linux Lenny: # uname -r 2.6.26-2-amd64 Thanks for your help! Regards, Philipp > > > harbor235 ;} > >> >> >> >> On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke >> wrote: >> >>> Hello, >>> >>> I seem to have issues understanding IPv6 anycast on NI MLX/XMR. >>> My understanding is, that any router that does have an IPv6 address in a >>> subnet should be listening on the Subnet-Router anycast address (RFC3513 >>> section 2.6.1). >>> >>> When I configure an IPv6 unicast address on a MLX VE it shows that it >>> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): >>> >>> Interface VE 200 is up, line protocol is up >>> [...] >>> IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 >>> [Preferred] >>> Global unicast address(es): >>> 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 >>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>> 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 >>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>> Joined group address(es): >>> ff02::1:ff00:1 >>> ff02::1:ff00:0 >>> ff02::1:ff00:2 >>> ff02::1:ffe1:2f00 >>> ff02::2 >>> ff02::1 >>> [...] >>> >>> Now when I try to ping that address from a client within the network >>> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX >>> announcing >>> it's UNIcast address: >>> >>> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>> 32) >>> 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor >>> solicitation, length 32, who has 2001:db8:f1:c:: >>> source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 >>> 0x0000: 0016 3e19 16a9 >>> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) >>> payload >>> length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, >>> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags >>> [router, >>> solicited] >>> destination link-address option (2), length 8 (1): >>> 00:0c:db:e1:2f:00 >>> 0x0000: 000c dbe1 2f00 >>> >>> This causes the asking client to create an entry in its neighbour cache >>> for the routers unicast address, but not realising, that this was the >>> answer to its question, hence it keeps on sending solicitation messages >>> for >>> the anycast address. >>> In my understanding the neighbour advertisement should have the unicast >>> address as source, but should announce the anycast address. >>> >>> If I take a Linux box and enable ip6 forwarding in the kernel, it also >>> joins that very same anycast group. If I do the same test again, you can >>> see, >>> that the Linux box answers with its unicast address, announcing the >>> anycast address: >>> >>> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>> 32) >>> 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor >>> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, >>> solicited] >>> destination link-address option (2), length 8 (1): >>> 00:16:3e:19:16:a9 >>> 0x0000: 0016 3e19 16a9 >>> >>> This works and the client creates an entry in its neighbour cache for >>> the >>> anycast address and can now communicate with the address. >>> >>> Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 >>> you can see in the output of the interface. >>> >>> If it matters, I do have ipv6 nd suppress-ra active on that VE. >>> >>> >>> So what does this mean, is it >>> >>> a) Me not understanding the concept of the anycast address (basicaly I >>> want to use it as a default gateway)? >>> b) A problem with my configuration (which is pretty plain for v6 right >>> now)? >>> c) A bug? >>> d) ?? >>> >>> Does anyone have experience with that they are able to share? >>> >>> >>> Thanks for any hints, >>> Philipp >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> foundry-nsp at puck.nether.net >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >> >> From dana at zeroloops.com Fri Sep 3 04:46:44 2010 From: dana at zeroloops.com (Dana) Date: Fri, 03 Sep 2010 10:46:44 +0200 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: <4C80B5F4.4010002@zeroloops.com> Hello, Let me share this information (from Brocade TAC). """"" Code 5.1 will have support for vrrp-e and vrrpv3 for IPv6. Current schedule for the code is by end of September. """"" However, Brocade will support vrrpv3 + vrrp-e for IPv6 only in the Netiron models for now (code 5.1). Unfortunately, for any other models, they do not have any plans yet whether they are going to support this. On the other hand, I need this support for our BigIron RXes, but I get the following reply: """"" I just got words from the developers where it is mentioned that Engineering is planning very limited enhancements in RX code; therefore, no plans to support this feature on RX platform. This is a case where customer may submit a feature request for this protocol to be included in a future code release. For a workaround, they were no sure how could be done, if there is no way to test reliable. Let you know """"" Another reply was: """"" First. To submit a Feature Request, please talk to our account team in your area, I think you have that information available about who are those persons. They will then communicate with our developers to see the course of action. I agree with you tha IPv6 is being used more and more by our customer specially in Europe. Not having support for VRRP and IPv6 make this system somehow limited for redundancy. I did a brain storming with our team here, and no solution possible to make redundancy like VRRP """"" Dana Dana ZeroLoops - Webhosting Provider http://www.zeroloops.com dana at zeroloops.com +31 62 692 5403 On 9/3/2010 10:01 AM, Philipp Geschke wrote: > Hi, > > Thank you for your reply! > > On Thu, 2 Sep 2010 14:20:35 -0400, harbor235 wrote: >> On Thu, Sep 2, 2010 at 2:16 PM, harbor235 wrote: >> >>> I have a couple questions too; >>> >>> 1) Can you allocate additional anycast addresses out of the unicast > space >>> other than the 127-n bits identified? (n bits = subnet prefix) >>> > If I get you correct (sorry if not, I am not a native speaker ;-)), then > "ipv6 address 2001:db8:f1:c:1:2:3:fe/64 anycast" qualifies for this test? > The result is pretty much the same, with the interesting fact, that the > MLX announces it Link-Local address now: > > 09:55:10.233664 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160> ff02::1:ff03:fe: [icmp6 sum ok] ICMP6, neighbor > solicitation, length 32, who has 2001:db8:f1:c:1:2:3:fe > source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > 09:55:10.233664 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload > length: 32) fe80::20c:dbff:fee1:2f00> 2001:db8:f1:c::160: [icmp6 sum ok] > ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, > Flags [router, solicited, override] > destination link-address option (2), length 8 (1): > 00:0c:db:e1:2f:00 > 0x0000: 000c dbe1 2f00 > >>> 2) how does your client machine behave when a reservered anycast > address >>> is >>> used? >>> >> all bits of the interface identifier are set to ones except the > last >> 7 bits which range in >> value from 0-125 (126 and 127 are reserverd or assigned) >> > Using "ipv6 address 2001:db8:f1:c:ffff:ffff:ffff:ff7a/64 anycast", which, > I think, qualifies for this test? > > 09:17:09.939237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160> ff02::1:ffff:ff7a: [icmp6 sum ok] ICMP6, neighbor > solicitation, length 32, who has 2001:db8:f1:c:ffff:ffff:ffff:ff7a > source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > 09:17:09.939237 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload > length: 32) fe80::20c:dbff:fee1:2f00> 2001:db8:f1:c::160: [icmp6 sum ok] > ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, > Flags [router, solicited, override] > destination link-address option (2), length 8 (1): > 00:0c:db:e1:2f:00 > 0x0000: 000c dbe1 2f00 > > >> 3) What OS was the original client machine? > Everything used in my tests is either NI MLX with IronWare 05000b or plain > Debian GNU/Linux Lenny: > > # uname -r > 2.6.26-2-amd64 > > > Thanks for your help! > > Regards, > Philipp > >> >> harbor235 ;} >> >>> >>> >>> On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke >>> wrote: >>> >>>> Hello, >>>> >>>> I seem to have issues understanding IPv6 anycast on NI MLX/XMR. >>>> My understanding is, that any router that does have an IPv6 address in > a >>>> subnet should be listening on the Subnet-Router anycast address > (RFC3513 >>>> section 2.6.1). >>>> >>>> When I configure an IPv6 unicast address on a MLX VE it shows that it >>>> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): >>>> >>>> Interface VE 200 is up, line protocol is up >>>> [...] >>>> IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 >>>> [Preferred] >>>> Global unicast address(es): >>>> 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 >>>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>>> 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 >>>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>>> Joined group address(es): >>>> ff02::1:ff00:1 >>>> ff02::1:ff00:0 >>>> ff02::1:ff00:2 >>>> ff02::1:ffe1:2f00 >>>> ff02::2 >>>> ff02::1 >>>> [...] >>>> >>>> Now when I try to ping that address from a client within the network >>>> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX >>>> announcing >>>> it's UNIcast address: >>>> >>>> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>>> 32) >>>> 2001:db8:f1:c::160> ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor >>>> solicitation, length 32, who has 2001:db8:f1:c:: >>>> source link-address option (1), length 8 (1): > 00:16:3e:19:16:a9 >>>> 0x0000: 0016 3e19 16a9 >>>> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) >>>> payload >>>> length: 32) 2001:db8:f1:c::2> 2001:db8:f1:c::160: [icmp6 sum ok] > ICMP6, >>>> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags >>>> [router, >>>> solicited] >>>> destination link-address option (2), length 8 (1): >>>> 00:0c:db:e1:2f:00 >>>> 0x0000: 000c dbe1 2f00 >>>> >>>> This causes the asking client to create an entry in its neighbour > cache >>>> for the routers unicast address, but not realising, that this was the >>>> answer to its question, hence it keeps on sending solicitation > messages >>>> for >>>> the anycast address. >>>> In my understanding the neighbour advertisement should have the > unicast >>>> address as source, but should announce the anycast address. >>>> >>>> If I take a Linux box and enable ip6 forwarding in the kernel, it also >>>> joins that very same anycast group. If I do the same test again, you > can >>>> see, >>>> that the Linux box answers with its unicast address, announcing the >>>> anycast address: >>>> >>>> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>>> 32) >>>> 2001:db8:f1:c::160> 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor >>>> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, >>>> solicited] >>>> destination link-address option (2), length 8 (1): >>>> 00:16:3e:19:16:a9 >>>> 0x0000: 0016 3e19 16a9 >>>> >>>> This works and the client creates an entry in its neighbour cache for >>>> the >>>> anycast address and can now communicate with the address. >>>> >>>> Same goes for the explicitly configured anycast address > 2001:db8:f1:c::1 >>>> you can see in the output of the interface. >>>> >>>> If it matters, I do have ipv6 nd suppress-ra active on that VE. >>>> >>>> >>>> So what does this mean, is it >>>> >>>> a) Me not understanding the concept of the anycast address (basicaly I >>>> want to use it as a default gateway)? >>>> b) A problem with my configuration (which is pretty plain for v6 right >>>> now)? >>>> c) A bug? >>>> d) ?? >>>> >>>> Does anyone have experience with that they are able to share? >>>> >>>> >>>> Thanks for any hints, >>>> Philipp >>>> >>>> _______________________________________________ >>>> foundry-nsp mailing list >>>> foundry-nsp at puck.nether.net >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>>> >>> > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp From jchome at jc-ix.net Fri Sep 3 05:30:06 2010 From: jchome at jc-ix.net (Frederic Jaeckel) Date: Fri, 03 Sep 2010 11:30:06 +0200 Subject: [f-nsp] CES/CER 2000 and VRRP Message-ID: <4C80C01E.1020108@jc-ix.net> Hey, I just looked through my docs and they are saying that VRRP is not supported by the CER/CES 2000 systems. Can someone please say it's not true and my docs are just too old? :) Best regards, Frederic Jaeckel From lee.pedder at gmail.com Fri Sep 3 06:27:49 2010 From: lee.pedder at gmail.com (Lee Pedder) Date: Fri, 3 Sep 2010 12:27:49 +0200 Subject: [f-nsp] CES/CER 2000 and VRRP In-Reply-To: <4C80C01E.1020108@jc-ix.net> References: <4C80C01E.1020108@jc-ix.net> Message-ID: Hi Frederic, The release notes I have for 4.1.00d say that VRRP and VRRPE are both supported on the CER / CES right the way through from BASE to PREM. Regards, Lee On 3 September 2010 11:30, Frederic Jaeckel wrote: > Hey, > > I just looked through my docs and they are saying that VRRP is not > supported by the CER/CES 2000 systems. Can someone please say it's not > true and my docs are just too old? :) > > Best regards, > Frederic Jaeckel > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > From Neil.Robst at ioko.com Fri Sep 3 07:32:34 2010 From: Neil.Robst at ioko.com (Neil Robst) Date: Fri, 3 Sep 2010 12:32:34 +0100 Subject: [f-nsp] CES/CER 2000 and VRRP In-Reply-To: References: <4C80C01E.1020108@jc-ix.net> Message-ID: <7A57DCAA71129142A6EF9C0074D38A8F2C057CD1D4@INTCL1EX01.uk.ioko365.com> Yeah - seems to be working fine on my CES2024's running v5 :-) System: NetIron CES (Serial #: xxxxxxxxx, Part #: 35701-002A) License: L3_PREM (LID: XXXXXXXXX) Boot : Version 5.0.0T185 Copyright (c) 1996-2009 Brocade Communications Systems, Inc. #sh ip vrrp-extended brief Total number of VRRP-Extended routers defined: 1 Inte- VRID Current P State Master IP Backup IP Virtual IP Short- rface Priority Address Address Address Path-Fwd -------------------------------------------------------------------------------------- v10 66 120 P Master Local xx.xx.xx.35 xx.xx.xx.46 Regards, Neil -----Original Message----- From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Lee Pedder Sent: 03 September 2010 11:28 To: Frederic Jaeckel Cc: foundry-nsp at puck.nether.net Subject: Re: [f-nsp] CES/CER 2000 and VRRP Hi Frederic, The release notes I have for 4.1.00d say that VRRP and VRRPE are both supported on the CER / CES right the way through from BASE to PREM. Regards, Lee On 3 September 2010 11:30, Frederic Jaeckel wrote: > Hey, > > I just looked through my docs and they are saying that VRRP is not > supported by the CER/CES 2000 systems. Can someone please say it's not > true and my docs are just too old? :) > > Best regards, > Frederic Jaeckel > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp From jeroen at easyhosting.nl Fri Sep 3 08:39:15 2010 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Fri, 03 Sep 2010 14:39:15 +0200 Subject: [f-nsp] IPv6 subnets flapping on Bigiron 4000 jetcore Message-ID: <4C80EC73.4010104@easyhosting.nl> We have two Bigiron 4000 Jetcores running B2P08.0.01s firmware and we're experiencing very unstable IPv6 behaviour. These Bigirons have several ve's with customer subnets on there in a dual stack config (/24 for IPv4 and /64 for IPv6) and OSPF as IGP between devices. (Also two XMR's, but they work just fine) On at least one of of these Bigirons, one or more /64 IPv6 subnets frequently becomes unavailable, the /24 IPv4 subnet on the ve works fine, but IPv6 enabled servers are suddenly unable to ping the ve's IPv6 address (which is the gateway) and the Bigiron is unable to ping the host's address over IPv6. It's happening on the whole subnet, we have three servers with IPv6 connectivity monitoring this and they all report the ve's IP becoming unreachable. Removing the ve's IPv6 address and adding it back solves it for a while, but after a day or so it starts acting up again. Yet it's not all subnets at once, one time it's a customer subnet, at other times it's the /126 subnet between XMR and Bigiron I've been going over the release notes for the Bigiron (since the latest release is 08.0.01w), but I can't find any IPv6 related fixes that match this. Anyone else seeing odd IPv6 behaviour on Bigirons ? (yes we have future MLX upgrade plans, but for now these units will have to suffice :-) -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From foundry-nsp at pgmail.net Fri Sep 3 10:52:01 2010 From: foundry-nsp at pgmail.net (Philipp Geschke) Date: Fri, 03 Sep 2010 16:52:01 +0200 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: <4C80B5F4.4010002@zeroloops.com> References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> <4C80B5F4.4010002@zeroloops.com> Message-ID: Hi, On Fri, 03 Sep 2010 10:46:44 +0200, Dana wrote: > """"" > Code 5.1 will have support for vrrp-e and vrrpv3 for IPv6. > Current schedule for the code is by end of September. > """"" Thanks for sharing this information. The lack of VRRP support for v6 was the reason why I turned to the subnet router anycast address in the first place. If 5.1 will support VRRPv3 then I will most likely just wait for that. But still this does not explain to me, why the MLX has such a strange behaviour on the subnet router anycast address. If no one else has an idea, I will propably open a bug report. Thanks, Philipp From frnkstr at gmail.com Sat Sep 4 15:15:50 2010 From: frnkstr at gmail.com (Frank Suter) Date: Sat, 4 Sep 2010 21:15:50 +0200 Subject: [f-nsp] MPLS feasibility Message-ID: Dear all, I am writing to this list, because I am using Brocade/Foundry routers and switches. This is maybe not the most accurate list, if so, please accept my apologies. Here is the context: I am currently having a datacenter presence where I do run my own AS with three ISPs, each with full BGP table and a /23 PI dedicated to the servers and Internet access. Because this is considered as the consolidated Internet access and datacenter, I would like to hub the office with this connection. Now my goal is to connect the office with the datacenter using a symmetric 100/100 Mbit link running MPLS service from my ISP. This will be delivered as a service. Now, because redundancy is important for me, I would link to have a second link 100/100 Mbit, but rather than asking the same provider to secure the path, I would like to ask this to a second provider because I do not trust one provider to do redundancy for me. I know that each provider are using physical different path to reach the Data Center. Questions: 1) Can I build a redundant MPLS access with two different providers and aggregate them together on each end? Thus having two paths of 100 Mbit symmetric each. Possible? 2) What equipment do I need on the office side to do this? 3) How long is the convergence time to expect in case of major failure on one of the links? Thank you for your time and advices. Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Sat Sep 4 17:57:52 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 4 Sep 2010 22:57:52 +0100 Subject: [f-nsp] MPLS feasibility In-Reply-To: References: Message-ID: Hi Frank, Are you talking about an lan extension service / pseudowires / vpls / etc ie. Ethernet that the carriers are tunneling over MPLS? If that is the case, it should be delivered as a simple ethernet circuit to you. Of course you can do load balancing over 2 ethernet links, you can play with metrics and have redundancy too. You cannot have both though obviously (if you use >100Mb/s). Something to consider if you are load balancing like this: the circuits will have different latency and packets *will* get out of order. The best advice however is you should contract a consultant or a company to fully understand what you want to achieve and give you case specific guidance. If everyone in your situation got free 'professional services' on these forums, we would all be out of jobs! :) Best of luck Heath On 4 September 2010 20:15, Frank Suter wrote: > Dear all, > > I am writing to this list, because I am using Brocade/Foundry routers and > switches. This is maybe not the most accurate list, if so, please accept my > apologies. > > Here is the context: I am currently having a datacenter presence where I do > run my own AS with three ISPs, each with full BGP table and a /23 PI > dedicated to the servers and Internet access. Because this is considered as > the consolidated Internet access and datacenter, I would like to hub the > office with this connection. > > Now my goal is to connect the office with the datacenter using a symmetric > 100/100 Mbit link running MPLS service from my ISP. This will be delivered > as a service. Now, because redundancy is important for me, I would link to > have a second link 100/100 Mbit, but rather than asking the same provider to > secure the path, I would like to ask this to a second provider because I do > not trust one provider to do redundancy for me. > > I know that each provider are using physical different path to reach the > Data Center. > > Questions: > > 1) Can I build a redundant MPLS access with two different providers and > aggregate them together on each end? Thus having two paths of 100 Mbit > symmetric each. Possible? > 2) What equipment do I need on the office side to do this? > 3) How long is the convergence time to expect in case of major failure on > one of the links? > > Thank you for your time and advices. > > Frank > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkstr at gmail.com Mon Sep 6 10:36:24 2010 From: frnkstr at gmail.com (Frank Suter) Date: Mon, 6 Sep 2010 16:36:24 +0200 Subject: [f-nsp] MPLS feasibility In-Reply-To: References: Message-ID: Hello Heath, Thanks for your input. Yes this is a LAN extension and I am obviously going to discuss this with a proper consultant, but there are not millions of them around here so I am trying to touch base here so I can brief accurately my ISP/integrator about what I want to achieve and make sure it is possible. I might be asking one of my ISPs to do the redundancy and implementation for me, as they are more or less neutral with this, but I know that if I would ask my ISP about redundancy, they would be offering me a "protected" ring on their network, which would be like a waste of money for me from past experience. Usually when things goes wrong, they go totally wrong and I have already seen two carriers going down together for physical path damage although they were not supposed to share it. Based on the facts, I know that in the building there are two different carriers that bring each their own FO. They are competitors and hate each other and will never work together, which is good for me. Each of them makes us of a different physical path to reach the end-point for legacy reasons. I am quite confident about both being able to deliver this service with an RTT of 3 ms maximum. I am thinking about all options possible here. I am thinking about having for instance one of the MPLS line dedicated for voice and the other one dedicated for the data with a pre-configured QoS, so that I can have a fail-over mechanism in case of worst event without risk of hours and hours of downtime in worst case scenario. Once again, thank you Heath. Frank 2010/9/4 Heath Jones > Hi Frank, > > Are you talking about an lan extension service / pseudowires / vpls / etc > ie. Ethernet that the carriers are tunneling over MPLS? > If that is the case, it should be delivered as a simple ethernet circuit to > you. Of course you can do load balancing over 2 ethernet links, you can play > with metrics and have redundancy too. You cannot have both though obviously > (if you use >100Mb/s). Something to consider if you are load balancing like > this: the circuits will have different latency and packets *will* get out of > order. > > The best advice however is you should contract a consultant or a company to > fully understand what you want to achieve and give you case specific > guidance. > > If everyone in your situation got free 'professional services' on these > forums, we would all be out of jobs! :) > > > Best of luck > Heath > > > > On 4 September 2010 20:15, Frank Suter wrote: > >> Dear all, >> >> I am writing to this list, because I am using Brocade/Foundry routers and >> switches. This is maybe not the most accurate list, if so, please accept my >> apologies. >> >> Here is the context: I am currently having a datacenter presence where I >> do run my own AS with three ISPs, each with full BGP table and a /23 PI >> dedicated to the servers and Internet access. Because this is considered as >> the consolidated Internet access and datacenter, I would like to hub the >> office with this connection. >> >> Now my goal is to connect the office with the datacenter using a symmetric >> 100/100 Mbit link running MPLS service from my ISP. This will be delivered >> as a service. Now, because redundancy is important for me, I would link to >> have a second link 100/100 Mbit, but rather than asking the same provider to >> secure the path, I would like to ask this to a second provider because I do >> not trust one provider to do redundancy for me. >> >> I know that each provider are using physical different path to reach the >> Data Center. >> >> Questions: >> >> 1) Can I build a redundant MPLS access with two different providers and >> aggregate them together on each end? Thus having two paths of 100 Mbit >> symmetric each. Possible? >> 2) What equipment do I need on the office side to do this? >> 3) How long is the convergence time to expect in case of major failure on >> one of the links? >> >> Thank you for your time and advices. >> >> Frank >> >> >> _______________________________________________ >> foundry-nsp mailing list >> >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vinny_Abello at dell.com Tue Sep 7 12:00:01 2010 From: Vinny_Abello at dell.com (Abello, Vinny) Date: Tue, 7 Sep 2010 11:00:01 -0500 Subject: [f-nsp] XMR CoPP or equivalent? Message-ID: Hi all, I have been trying to locate any documentation for something equivalent to Cisco's CoPP (control-plane policing) for the Foundry/Brocade NetIron XMR and haven't had much success. Does such a feature even exist or is it even needed on this platform? I can't imagine the control-plane is completely immune to attack out of the box. Any pointers to documentation or what the feature or features are called? Thanks! -Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vinny_Abello at dell.com Thu Sep 9 19:24:48 2010 From: Vinny_Abello at dell.com (Abello, Vinny) Date: Thu, 9 Sep 2010 18:24:48 -0500 Subject: [f-nsp] XMR CoPP or equivalent? In-Reply-To: References: Message-ID: <413A9D29-BDF1-411D-B008-80490E35685F@dell.com> I have my answer after contacting Brocade and will post it here for the benefit of anyone else seeking the same answer. What I was looking for was rACLs although there are a few other features as specified below. This was the response from Brocade: Here are some of the security features that can be used to protect CPU. This is in addition to the access policies and rate limiting of traffic. Please note that each of these functions has benefits and restrictions. Hence please go through the documentation prior implementing any of these. IP Receive ACLs The IP receive access-control list feature (rACL) provides hardware-based filtering capability for IPv4 traffic destined for the CPU in the default VRF such as management traffic. Its purpose is to protect the management module's CPU from overloading due to large amounts of traffic sent to one of the NetIron router's IP interfaces. Using the rACL command, the specified ACL is applied to every interface on the NetIron router. This eliminates the need to add an ACL to each interface on a NetIron router. Transparent VLAN Flooding You can configure your NetIron router for transparent VLAN flooding. This feature allows packets to be forwarded without any form of CPU intervention including MAC learning and MAC destination lookups VLAN CPU Protection VLAN CPU protection is recommended for the VLANs which are intended for pure Layer2 use. This feature will protect the CPU from the flooding of unknown-unicast/multicast/broadcast L2 packets on that VLAN. Protecting Against Denial of Service Attacks Denial of Smurf/TCP SYN/Reset attacks are explained here. All these features are explained in the documentation gude and can be downloaded using the following link http://kp.foundrynet.com/Portal/software/default.asp?ACT=DIR&NAME=NetIronXMR-MLX.700\05000.700\05000.700\Manuals.700 On Sep 7, 2010, at 12:00 PM, Abello, Vinny wrote: Hi all, I have been trying to locate any documentation for something equivalent to Cisco?s CoPP (control-plane policing) for the Foundry/Brocade NetIron XMR and haven?t had much success. Does such a feature even exist or is it even needed on this platform? I can?t imagine the control-plane is completely immune to attack out of the box. Any pointers to documentation or what the feature or features are called? Thanks! -Vinny _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sat Sep 11 15:02:03 2010 From: georgeb at gmail.com (George B.) Date: Sat, 11 Sep 2010 12:02:03 -0700 Subject: [f-nsp] Odd MRP problem Message-ID: See this diagram for reference: http://tinypic.com/r/kb93lj/7 This is pretty simple. I have one vlan in an MRP ring through 4 MLX units. I configure the master, and it works as expected. I then configure the members. The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second. It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire. Here is what my master currently shows: RHPs sent RHPs rcvd TC RBPDUs rcvd 509883 4193162 3684318 As you can see, it has sent about a half a million RHPs but received over 4 million of them! Only one unit is configured as "master". As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan. I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate! Anyone else seen anything like this? It is just plain wacky! George -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Sat Sep 11 15:39:09 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 11 Sep 2010 20:39:09 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: Hi George I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 (close to 8). Is that worth noting? If the ring ID was different on all 4 devices, not converging so sending out both interfaces, that would mean that each device should show 8 times(ish) the figure of what is sending out?? Packet captures might be the way to go, if we can find the protocol spec from foundry.. Heath On 11 September 2010 20:02, George B. wrote: > See this diagram for reference: > > http://tinypic.com/r/kb93lj/7 > > This is pretty simple. I have one vlan in an MRP ring through 4 MLX > units. I configure the master, and it works as expected. I then configure > the members. The problem is when the last "member" (non-master) is > configured in the ring, the master begins to receive thousands of RHP and TC > RBPDUs per second. It doesn't matter which one is the last member > configured but as soon as I enable RHP on that last member, the count of RHP > and TC RBPDUs goes haywire. Here is what my master currently shows: > > RHPs sent RHPs rcvd TC RBPDUs rcvd > 509883 4193162 3684318 > > As you can see, it has sent about a half a million RHPs but received over 4 > million of them! > > Only one unit is configured as "master". As long as I have MRP > unconfigured on one of the members, the ring works as expected. There is no > spanning tree of any sort running on that vlan. I am just in awe of how RHP > packets can seemingly be created in the network somewhere at such an amazing > rate! > > Anyone else seen anything like this? It is just plain wacky! > > George > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sat Sep 11 15:41:35 2010 From: georgeb at gmail.com (George B.) Date: Sat, 11 Sep 2010 12:41:35 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: I have MRP in production without this issue, too. I have never seen anything like it. I can't understand how I can receive more RHP packets than I send. CPU goes up on the line cards, the state of the secondary interface flaps between blocking and forwarding, it just gets into a bad state. As long as I don't have all the members configured and leave at least one not configured with MRP, it works as expected. The one thing I haven't done is to try to make a different unit the master. On Sat, Sep 11, 2010 at 12:31 PM, Peter Olsen wrote: > Strange, > > > > We have 150+rings active, never seen anything like this. > > Except for the very strange numbers, is the ring working ? (is it only a > ?counting? issue) > > > > *Br,* > > *Peter* > > * * > > > > *From:* foundry-nsp-bounces at puck.nether.net [mailto: > foundry-nsp-bounces at puck.nether.net] *On Behalf Of *George B. > *Sent:* 11. september 2010 21:02 > *To:* foundry-nsp > *Subject:* [f-nsp] Odd MRP problem > > > > See this diagram for reference: > > http://tinypic.com/r/kb93lj/7 > > This is pretty simple. I have one vlan in an MRP ring through 4 MLX > units. I configure the master, and it works as expected. I then configure > the members. The problem is when the last "member" (non-master) is > configured in the ring, the master begins to receive thousands of RHP and TC > RBPDUs per second. It doesn't matter which one is the last member > configured but as soon as I enable RHP on that last member, the count of RHP > and TC RBPDUs goes haywire. Here is what my master currently shows: > > RHPs sent RHPs rcvd TC RBPDUs rcvd > 509883 4193162 3684318 > > As you can see, it has sent about a half a million RHPs but received over 4 > million of them! > > Only one unit is configured as "master". As long as I have MRP > unconfigured on one of the members, the ring works as expected. There is no > spanning tree of any sort running on that vlan. I am just in awe of how RHP > packets can seemingly be created in the network somewhere at such an amazing > rate! > > Anyone else seen anything like this? It is just plain wacky! > > George > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sat Sep 11 15:45:56 2010 From: georgeb at gmail.com (George B.) Date: Sat, 11 Sep 2010 12:45:56 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: They are all using the same ring ID (ring 2) and this is extremely simple as the vlan exists only on the units in the ring and the ring ports are the only members of the vlan. That number ratio isn't going to mean anything as I have been running in a stable mode now with one of the units not configured for MRP for well over 24 hours now. The topology keeps flapping if I have all members configured. As long as I leave one unconfigured, it works just fine. The equipment involved has been in service without issues for a long time. We recently added the second metroE and I wanted to run MRP as I have had good results with it everywhere else I have used it. Never seen anything like this before. George On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones wrote: > Hi George > > I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 > (close to 8). Is that worth noting? > If the ring ID was different on all 4 devices, not converging so sending > out both interfaces, that would mean that each device should show 8 > times(ish) the figure of what is sending out?? > > Packet captures might be the way to go, if we can find the protocol spec > from foundry.. > > Heath > > On 11 September 2010 20:02, George B. wrote: > >> See this diagram for reference: >> >> http://tinypic.com/r/kb93lj/7 >> >> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >> units. I configure the master, and it works as expected. I then configure >> the members. The problem is when the last "member" (non-master) is >> configured in the ring, the master begins to receive thousands of RHP and TC >> RBPDUs per second. It doesn't matter which one is the last member >> configured but as soon as I enable RHP on that last member, the count of RHP >> and TC RBPDUs goes haywire. Here is what my master currently shows: >> >> RHPs sent RHPs rcvd TC RBPDUs rcvd >> 509883 4193162 3684318 >> >> As you can see, it has sent about a half a million RHPs but received over >> 4 million of them! >> >> Only one unit is configured as "master". As long as I have MRP >> unconfigured on one of the members, the ring works as expected. There is no >> spanning tree of any sort running on that vlan. I am just in awe of how RHP >> packets can seemingly be created in the network somewhere at such an amazing >> rate! >> >> Anyone else seen anything like this? It is just plain wacky! >> >> George >> >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Sat Sep 11 16:01:29 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 11 Sep 2010 21:01:29 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: So for it to be flapping between blocking / forwarding, the unit would have to either be receiving (or thinking its receiving) tcn's? On 11 September 2010 20:45, George B. wrote: > They are all using the same ring ID (ring 2) and this is extremely simple > as the vlan exists only on the units in the ring and the ring ports are the > only members of the vlan. That number ratio isn't going to mean anything as > I have been running in a stable mode now with one of the units not > configured for MRP for well over 24 hours now. The topology keeps flapping > if I have all members configured. As long as I leave one unconfigured, it > works just fine. > > The equipment involved has been in service without issues for a long time. > We recently added the second metroE and I wanted to run MRP as I have had > good results with it everywhere else I have used it. Never seen anything > like this before. > > George > > > > On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones wrote: > >> Hi George >> >> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >> (close to 8). Is that worth noting? >> If the ring ID was different on all 4 devices, not converging so sending >> out both interfaces, that would mean that each device should show 8 >> times(ish) the figure of what is sending out?? >> >> Packet captures might be the way to go, if we can find the protocol spec >> from foundry.. >> >> Heath >> >> On 11 September 2010 20:02, George B. wrote: >> >>> See this diagram for reference: >>> >>> http://tinypic.com/r/kb93lj/7 >>> >>> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >>> units. I configure the master, and it works as expected. I then configure >>> the members. The problem is when the last "member" (non-master) is >>> configured in the ring, the master begins to receive thousands of RHP and TC >>> RBPDUs per second. It doesn't matter which one is the last member >>> configured but as soon as I enable RHP on that last member, the count of RHP >>> and TC RBPDUs goes haywire. Here is what my master currently shows: >>> >>> RHPs sent RHPs rcvd TC RBPDUs rcvd >>> 509883 4193162 3684318 >>> >>> As you can see, it has sent about a half a million RHPs but received over >>> 4 million of them! >>> >>> Only one unit is configured as "master". As long as I have MRP >>> unconfigured on one of the members, the ring works as expected. There is no >>> spanning tree of any sort running on that vlan. I am just in awe of how RHP >>> packets can seemingly be created in the network somewhere at such an amazing >>> rate! >>> >>> Anyone else seen anything like this? It is just plain wacky! >>> >>> George >>> >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> foundry-nsp at puck.nether.net >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.Olsen at GlobalConnect.dk Sat Sep 11 15:31:12 2010 From: Peter.Olsen at GlobalConnect.dk (Peter Olsen) Date: Sat, 11 Sep 2010 21:31:12 +0200 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: Strange, We have 150+rings active, never seen anything like this. Except for the very strange numbers, is the ring working ? (is it only a 'counting' issue) Br, Peter From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of George B. Sent: 11. september 2010 21:02 To: foundry-nsp Subject: [f-nsp] Odd MRP problem See this diagram for reference: http://tinypic.com/r/kb93lj/7 This is pretty simple. I have one vlan in an MRP ring through 4 MLX units. I configure the master, and it works as expected. I then configure the members. The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second. It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire. Here is what my master currently shows: RHPs sent RHPs rcvd TC RBPDUs rcvd 509883 4193162 3684318 As you can see, it has sent about a half a million RHPs but received over 4 million of them! Only one unit is configured as "master". As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan. I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate! Anyone else seen anything like this? It is just plain wacky! George -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan.Pedersen at GlobalConnect.dk Sun Sep 12 03:46:43 2010 From: Jan.Pedersen at GlobalConnect.dk (Jan Pedersen) Date: Sun, 12 Sep 2010 09:46:43 +0200 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Hi George, We once had a similar issue, and that was caused by a faulty 4X10G XMR Module. Have you checked that you have valid PBIF, XPP and XGMAC versions on all 10GE modules in the ring? Can you pass normal (non-mrp) traffic across that ring without problems. Do you have a topology group and member-vlans attached to that metro-ring? If yes, double check that the topology group is equally configured on all nodes. You might want to enable byte accounting on the MRP master vlan on all nodes or try the "dm metro-rhp" debug command to get more information from the nodes. Best regards Jan Pedersen Senior Network Specialist D: +45 7730 2932 M: +45 2550 7321 From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Heath Jones Sent: 11. september 2010 21:39 To: George B. Cc: foundry-nsp Subject: Re: [f-nsp] Odd MRP problem Hi George I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 (close to 8). Is that worth noting? If the ring ID was different on all 4 devices, not converging so sending out both interfaces, that would mean that each device should show 8 times(ish) the figure of what is sending out?? Packet captures might be the way to go, if we can find the protocol spec from foundry.. Heath On 11 September 2010 20:02, George B. wrote: See this diagram for reference: http://tinypic.com/r/kb93lj/7 This is pretty simple. I have one vlan in an MRP ring through 4 MLX units. I configure the master, and it works as expected. I then configure the members. The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second. It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire. Here is what my master currently shows: RHPs sent RHPs rcvd TC RBPDUs rcvd 509883 4193162 3684318 As you can see, it has sent about a half a million RHPs but received over 4 million of them! Only one unit is configured as "master". As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan. I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate! Anyone else seen anything like this? It is just plain wacky! George _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sun Sep 12 04:10:25 2010 From: georgeb at gmail.com (George B.) Date: Sun, 12 Sep 2010 01:10:25 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: All of those units have been in service for over a year passing traffic without problems. We recently added the second metroE and I wanted to use MRP as I have had good results with it elsewhere. MRP works fine as long as I have at least one unit that is NOT configured for MRP. One thing I noticed today is that two of the units (the bottom two in the diagram) are running 4.0.0 and the top two are running 5.0.0 so my next step is to get them all up to current (though a new release for MLX/XMR is due on or about Wednesday, Sept 15, according to my little birdies so I might delay for a couple of days). The configuration is as simple as I can get it ... one single vlan running MRP, no topology group, only ports in the vlan are the ports running MRP (two ports per unit). Thanks for your response, Jan. George On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < Jan.Pedersen at globalconnect.dk> wrote: > Hi George, > > > > We once had a similar issue, and that was caused by a faulty 4X10G XMR > Module. > > > > Have you checked that you have valid PBIF, XPP and XGMAC versions on all > 10GE modules in the ring? > > > > Can you pass normal (non-mrp) traffic across that ring without problems. Do > you have a topology group and member-vlans attached to that metro-ring? If > yes, double check that the topology group is equally configured on all > nodes. > > > > You might want to enable byte accounting on the MRP master vlan on all > nodes or try the ?dm metro-rhp? debug command to get more information from > the nodes. > > > > > > *Best regards > > **Jan Pedersen > **Senior Network Specialist > D: +45 7730 2932 > M: +45 2550 7321 > > * > > *From:* foundry-nsp-bounces at puck.nether.net [mailto: > foundry-nsp-bounces at puck.nether.net] *On Behalf Of *Heath Jones > *Sent:* 11. september 2010 21:39 > *To:* George B. > *Cc:* foundry-nsp > *Subject:* Re: [f-nsp] Odd MRP problem > > > > Hi George > > > > I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 > (close to 8). Is that worth noting? > > If the ring ID was different on all 4 devices, not converging so sending > out both interfaces, that would mean that each device should show 8 > times(ish) the figure of what is sending out?? > > > > Packet captures might be the way to go, if we can find the protocol spec > from foundry.. > > > > Heath > > On 11 September 2010 20:02, George B. wrote: > > See this diagram for reference: > > http://tinypic.com/r/kb93lj/7 > > This is pretty simple. I have one vlan in an MRP ring through 4 MLX > units. I configure the master, and it works as expected. I then configure > the members. The problem is when the last "member" (non-master) is > configured in the ring, the master begins to receive thousands of RHP and TC > RBPDUs per second. It doesn't matter which one is the last member > configured but as soon as I enable RHP on that last member, the count of RHP > and TC RBPDUs goes haywire. Here is what my master currently shows: > > RHPs sent RHPs rcvd TC RBPDUs rcvd > 509883 4193162 3684318 > > As you can see, it has sent about a half a million RHPs but received over 4 > million of them! > > Only one unit is configured as "master". As long as I have MRP > unconfigured on one of the members, the ring works as expected. There is no > spanning tree of any sort running on that vlan. I am just in awe of how RHP > packets can seemingly be created in the network somewhere at such an amazing > rate! > > Anyone else seen anything like this? It is just plain wacky! > > George > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Sun Sep 12 08:39:30 2010 From: harbor235 at gmail.com (harbor235) Date: Sun, 12 Sep 2010 08:39:30 -0400 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: Is spanning tree disabled on vlan 2? harbor235 On Sun, Sep 12, 2010 at 4:10 AM, George B. wrote: > All of those units have been in service for over a year passing traffic > without problems. We recently added the second metroE and I wanted to use > MRP as I have had good results with it elsewhere. MRP works fine as long as > I have at least one unit that is NOT configured for MRP. One thing I > noticed today is that two of the units (the bottom two in the diagram) are > running 4.0.0 and the top two are running 5.0.0 so my next step is to get > them all up to current (though a new release for MLX/XMR is due on or about > Wednesday, Sept 15, according to my little birdies so I might delay for a > couple of days). > > The configuration is as simple as I can get it ... one single vlan running > MRP, no topology group, only ports in the vlan are the ports running MRP > (two ports per unit). > > Thanks for your response, Jan. > > George > > > > On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < > Jan.Pedersen at globalconnect.dk> wrote: > >> Hi George, >> >> >> >> We once had a similar issue, and that was caused by a faulty 4X10G XMR >> Module. >> >> >> >> Have you checked that you have valid PBIF, XPP and XGMAC versions on all >> 10GE modules in the ring? >> >> >> >> Can you pass normal (non-mrp) traffic across that ring without problems. >> Do you have a topology group and member-vlans attached to that metro-ring? >> If yes, double check that the topology group is equally configured on all >> nodes. >> >> >> >> You might want to enable byte accounting on the MRP master vlan on all >> nodes or try the ?dm metro-rhp? debug command to get more information from >> the nodes. >> >> >> >> >> >> *Best regards >> >> **Jan Pedersen >> **Senior Network Specialist >> D: +45 7730 2932 >> M: +45 2550 7321 >> >> * >> >> *From:* foundry-nsp-bounces at puck.nether.net [mailto: >> foundry-nsp-bounces at puck.nether.net] *On Behalf Of *Heath Jones >> *Sent:* 11. september 2010 21:39 >> *To:* George B. >> *Cc:* foundry-nsp >> *Subject:* Re: [f-nsp] Odd MRP problem >> >> >> >> Hi George >> >> >> >> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >> (close to 8). Is that worth noting? >> >> If the ring ID was different on all 4 devices, not converging so sending >> out both interfaces, that would mean that each device should show 8 >> times(ish) the figure of what is sending out?? >> >> >> >> Packet captures might be the way to go, if we can find the protocol spec >> from foundry.. >> >> >> >> Heath >> >> On 11 September 2010 20:02, George B. wrote: >> >> See this diagram for reference: >> >> http://tinypic.com/r/kb93lj/7 >> >> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >> units. I configure the master, and it works as expected. I then configure >> the members. The problem is when the last "member" (non-master) is >> configured in the ring, the master begins to receive thousands of RHP and TC >> RBPDUs per second. It doesn't matter which one is the last member >> configured but as soon as I enable RHP on that last member, the count of RHP >> and TC RBPDUs goes haywire. Here is what my master currently shows: >> >> RHPs sent RHPs rcvd TC RBPDUs rcvd >> 509883 4193162 3684318 >> >> As you can see, it has sent about a half a million RHPs but received over >> 4 million of them! >> >> Only one unit is configured as "master". As long as I have MRP >> unconfigured on one of the members, the ring works as expected. There is no >> spanning tree of any sort running on that vlan. I am just in awe of how RHP >> packets can seemingly be created in the network somewhere at such an amazing >> rate! >> >> Anyone else seen anything like this? It is just plain wacky! >> >> George >> >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> >> >> > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sun Sep 12 15:09:56 2010 From: georgeb at gmail.com (George B.) Date: Sun, 12 Sep 2010 12:09:56 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: Oops, meant to reply all. No spanning tree anywhere on that vlan. In this case it is vlan 111 and metro ring 2 On Sun, Sep 12, 2010 at 5:39 AM, harbor235 wrote: > Is spanning tree disabled on vlan 2? > > harbor235 > > > On Sun, Sep 12, 2010 at 4:10 AM, George B. wrote: > >> All of those units have been in service for over a year passing traffic >> without problems. We recently added the second metroE and I wanted to use >> MRP as I have had good results with it elsewhere. MRP works fine as long as >> I have at least one unit that is NOT configured for MRP. One thing I >> noticed today is that two of the units (the bottom two in the diagram) are >> running 4.0.0 and the top two are running 5.0.0 so my next step is to get >> them all up to current (though a new release for MLX/XMR is due on or about >> Wednesday, Sept 15, according to my little birdies so I might delay for a >> couple of days). >> >> The configuration is as simple as I can get it ... one single vlan running >> MRP, no topology group, only ports in the vlan are the ports running MRP >> (two ports per unit). >> >> Thanks for your response, Jan. >> >> George >> >> >> >> On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < >> Jan.Pedersen at globalconnect.dk> wrote: >> >>> Hi George, >>> >>> >>> >>> We once had a similar issue, and that was caused by a faulty 4X10G XMR >>> Module. >>> >>> >>> >>> Have you checked that you have valid PBIF, XPP and XGMAC versions on all >>> 10GE modules in the ring? >>> >>> >>> >>> Can you pass normal (non-mrp) traffic across that ring without problems. >>> Do you have a topology group and member-vlans attached to that metro-ring? >>> If yes, double check that the topology group is equally configured on all >>> nodes. >>> >>> >>> >>> You might want to enable byte accounting on the MRP master vlan on all >>> nodes or try the ?dm metro-rhp? debug command to get more information from >>> the nodes. >>> >>> >>> >>> >>> >>> *Best regards >>> >>> **Jan Pedersen >>> **Senior Network Specialist >>> D: +45 7730 2932 >>> M: +45 2550 7321 >>> >>> * >>> >>> *From:* foundry-nsp-bounces at puck.nether.net [mailto: >>> foundry-nsp-bounces at puck.nether.net] *On Behalf Of *Heath Jones >>> *Sent:* 11. september 2010 21:39 >>> *To:* George B. >>> *Cc:* foundry-nsp >>> *Subject:* Re: [f-nsp] Odd MRP problem >>> >>> >>> >>> Hi George >>> >>> >>> >>> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >>> (close to 8). Is that worth noting? >>> >>> If the ring ID was different on all 4 devices, not converging so sending >>> out both interfaces, that would mean that each device should show 8 >>> times(ish) the figure of what is sending out?? >>> >>> >>> >>> Packet captures might be the way to go, if we can find the protocol spec >>> from foundry.. >>> >>> >>> >>> Heath >>> >>> On 11 September 2010 20:02, George B. wrote: >>> >>> See this diagram for reference: >>> >>> http://tinypic.com/r/kb93lj/7 >>> >>> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >>> units. I configure the master, and it works as expected. I then configure >>> the members. The problem is when the last "member" (non-master) is >>> configured in the ring, the master begins to receive thousands of RHP and TC >>> RBPDUs per second. It doesn't matter which one is the last member >>> configured but as soon as I enable RHP on that last member, the count of RHP >>> and TC RBPDUs goes haywire. Here is what my master currently shows: >>> >>> RHPs sent RHPs rcvd TC RBPDUs rcvd >>> 509883 4193162 3684318 >>> >>> As you can see, it has sent about a half a million RHPs but received over >>> 4 million of them! >>> >>> Only one unit is configured as "master". As long as I have MRP >>> unconfigured on one of the members, the ring works as expected. There is no >>> spanning tree of any sort running on that vlan. I am just in awe of how RHP >>> packets can seemingly be created in the network somewhere at such an amazing >>> rate! >>> >>> Anyone else seen anything like this? It is just plain wacky! >>> >>> George >>> >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> foundry-nsp at puck.nether.net >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >>> >>> >> >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at linx.net Mon Sep 13 06:23:52 2010 From: mike at linx.net (Mike Hughes) Date: Mon, 13 Sep 2010 11:23:52 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> --On 12 September 2010 12:09 -0700 "George B." wrote: > Oops, meant to reply all.? No spanning tree anywhere on that vlan.? In > this case it is vlan 111 and metro ring 2 Is there any link-aggregation present on this ring? It could be something like source-port suppression failing on a LAG group. Mike -- Mike Hughes Chief Technical Officer London Internet Exchange Ltd. mike at linx.net http://www.linx.net/ Registered in England 3137929 at Trinity Court, Peterborough, PE1 1DA From tdonahue at vonsystems.com Mon Sep 13 18:07:35 2010 From: tdonahue at vonsystems.com (tdonahue at vonsystems.com) Date: Mon, 13 Sep 2010 18:07:35 -0400 (EDT) Subject: [f-nsp] BigIron RX Management Interface In-Reply-To: <14801116.901284415060049.JavaMail.tdonahue@midgard> Message-ID: <9324361.921284415649240.JavaMail.tdonahue@midgard> Hi all, Sorry for such a basic question, but I can't seem to find the answer to this question from Google or in the Configuration Guide. We have the management interface on our BigIron RX-4 connected to an internal network and we are trying to figure out how to add a default route for that interface. Can anyone point me to the documentation or send me a quick sample for setting up the routes for the management interface? Thank you, Tim From boards188 at gmail.com Mon Sep 13 21:20:18 2010 From: boards188 at gmail.com (Jason Pope) Date: Mon, 13 Sep 2010 20:20:18 -0500 Subject: [f-nsp] BigIron RX Management Interface In-Reply-To: <9324361.921284415649240.JavaMail.tdonahue@midgard> References: <14801116.901284415060049.JavaMail.tdonahue@midgard> <9324361.921284415649240.JavaMail.tdonahue@midgard> Message-ID: I believe it would just be: ip default-network [A.B.C.D or A.B.C.D/L] Jason On Mon, Sep 13, 2010 at 5:07 PM, wrote: > Hi all, > > Sorry for such a basic question, but I can't seem to find the answer to > this question from Google or in the Configuration Guide. > > We have the management interface on our BigIron RX-4 connected to an > internal network and we are trying to figure out how to add a default route > for that interface. Can anyone point me to the documentation or send me a > quick sample for setting up the routes for the management interface? > > Thank you, > > Tim > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hidden at xmission.com Mon Sep 13 22:07:54 2010 From: hidden at xmission.com (Jared Valentine) Date: Mon, 13 Sep 2010 20:07:54 -0600 Subject: [f-nsp] BigIron RX Management Interface In-Reply-To: References: <14801116.901284415060049.JavaMail.tdonahue@midgard> <9324361.921284415649240.JavaMail.tdonahue@midgard> Message-ID: <0E888D03-1404-4BAA-83F2-DB87B1C39E18@xmission.com> You actually add routes for the management module exactly like you would for an interface module. It goes in the global routing table: ip route x.x.x.x/x y.y.y.y Because y.y.y.y is in the same network as your management module, it gets installed as a management route and not a line card route. The box will keep line card and mgmt module routes separate. The gotcha here is that you can't have "two default routes". So as long as your RX doesn't have a default route already, and you don't need it to, then specifying the management module's default route would be: ip route 0.0.0.0/0 y.y.y.y However, if that's not acceptable then you have some other choices: Use a static route (non-default) that points to y.y.y.y as next hop. You would have to add a static to each of the networks you want to manage from The other choice is to just use in-band management and not use the mgmt port. You could also use a bastion host as a hop-off point that lives in the mgmt module subnet. That way you don't need to worry about routes. The bastion host has its own default gateway. Good luck, Jared On Sep 13, 2010, at 7:20 PM, Jason Pope wrote: > I believe it would just be: > > ip default-network [A.B.C.D or A.B.C.D/L] > > Jason > > > > On Mon, Sep 13, 2010 at 5:07 PM, wrote: > Hi all, > > Sorry for such a basic question, but I can't seem to find the answer to this question from Google or in the Configuration Guide. > > We have the management interface on our BigIron RX-4 connected to an internal network and we are trying to figure out how to add a default route for that interface. Can anyone point me to the documentation or send me a quick sample for setting up the routes for the management interface? > > Thank you, > > Tim > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Wed Sep 15 13:31:18 2010 From: harbor235 at gmail.com (harbor235) Date: Wed, 15 Sep 2010 13:31:18 -0400 Subject: [f-nsp] multicast and GRE Message-ID: Does anyone know if Brocade/Foundry supports multicast over GRE tunnels? My setup is simple, L2 access switch connected to distribution switch (L3), conencted to a Core switch (L3). If I hang the source off the Core, enable PIM on the connencting interfaces all works well. If I add a GRE tunnel that terminates upstream of the core switch to remote router, add the appropriate PIM sparse mode commands on the tunnel interfaces and locate the source on the same remote router, all is broken. If I follow the Cisco docs for enabling multicast over GRE, add mroutes for the RP and the source pointing to the tunnel, I still get no joy. I can see the group address and the RP in the PIM cache as well IGMP. I have performed packet traces and can see IGMP V2 requests, creates, etc. Then pretty much 23 seconds later I see the XP receiver send a IGMP leave, thoughts? Are there any good docs for Foundry multicast over GRE? Troubleshooting? help from someone who has implemented multicast on Foundry? harbor235 ;} -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Wed Sep 22 08:07:25 2010 From: harbor235 at gmail.com (harbor235) Date: Wed, 22 Sep 2010 08:07:25 -0400 Subject: [f-nsp] ACLs Message-ID: I was reading through the Netiron user guide and came across the following; You cannot enable any of the following features on the interface if an ACL is already applied to that interface: ? ACL-based rate limiting ? Policy-based routing (PBR) ? VLAN ID Translation or Inner VLAN ID translation feature IP inbound and L2 inbound ACLs are mutually exclusive on the NetIron MLX and NetIron XMR, but both may be bound to the same port on the NetIron CES and NetIron CER. IP outbound and L2 outbound ACLs are mutually exclusive on all platforms. This is very limiting, how is everyone getting around this limitation? harbor235 ;} -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarratt at socket.net Thu Sep 23 18:15:59 2010 From: abarratt at socket.net (Adam E Barratt (Sales Engineering)) Date: Thu, 23 Sep 2010 17:15:59 -0500 Subject: [f-nsp] Gray Market Foundry In-Reply-To: References: Message-ID: <4C9BD19F.7020600@socket.net> I was wondering if anyone has any experience with Gray Market Brocade equipment? (specifically on the MLX line?) -Adam From abarratt at socket.net Thu Sep 23 19:30:05 2010 From: abarratt at socket.net (Adam E Barratt (Network Operations)) Date: Thu, 23 Sep 2010 18:30:05 -0500 Subject: [f-nsp] Gray Market Foundry In-Reply-To: <071201cb5b74$64c1d670$2e458350$@net> References: <4C9BD19F.7020600@socket.net> <071201cb5b74$64c1d670$2e458350$@net> Message-ID: <41A28584-86C5-4DA7-93FB-5F7314DCF287@socket.net> Specifically on the support side. How does brocade deal with software upgrades on hardware not sold through traditional channels / used equipment etc? Is it worth it or does it cause headaches? Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for > over 7 years to end-users, dealers and brokers, worldwide. (Gray > market is a > bit of a misnomer in my opinion.) I have sold lots of MLX, XMR, RX, > SuperX > and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt > (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for > over 7 years to end-users, dealers and brokers, worldwide. (Gray > market is a > bit of a misnomer in my opinion.) I have sold lots of MLX, XMR, RX, > SuperX > and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt > (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > > From brian at terabitsystems.net Thu Sep 23 19:09:36 2010 From: brian at terabitsystems.net (Brian Stadtmiller) Date: Thu, 23 Sep 2010 16:09:36 -0700 Subject: [f-nsp] Gray Market Foundry In-Reply-To: <4C9BD19F.7020600@socket.net> References: <4C9BD19F.7020600@socket.net> Message-ID: <071201cb5b74$64c1d670$2e458350$@net> I have sold new, used, and refurbished Foundry (now Brocade IP) hardware for over 7 years to end-users, dealers and brokers, worldwide. (Gray market is a bit of a misnomer in my opinion.) I have sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized companies. (Literally millions of dollars worth of Foundry/Brocade hardware.) Anyhow, Do you have specific concerns or questions you would like addressed? regards, Brian Stadtmiller Terabit Systems 2565 3rd Street #334 San Francisco, CA 94107 415-230-4353 main 415-652-2888 cell AIM: bstadtmiller9609 -----Original Message----- From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E Barratt (Sales Engineering) Sent: Thursday, September 23, 2010 3:16 PM To: foundry-nsp at puck.nether.net Subject: [f-nsp] Gray Market Foundry I was wondering if anyone has any experience with Gray Market Brocade equipment? (specifically on the MLX line?) -Adam _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: 09/22/10 23:34:00 From mdixon at nkc.org Fri Sep 24 10:17:18 2010 From: mdixon at nkc.org (Michienne Dixon) Date: Fri, 24 Sep 2010 09:17:18 -0500 Subject: [f-nsp] Gray Market Foundry Message-ID: <6316CD198EC8BC44A9D200F375869F1E012FB331@nkc-mailsrv.nkc.org> Prior to Foundry becoming Brocade, they had a recertification process for their equipment that was not too painful. I have not purchased any used Foundry equipment since that time though. It used to be that if you were purchasing from a reseller that has a maintenance agreement with Foundry then they could upgrade the software for you. I would ask your reseller. We have maintenance on our MLX routers and I have a couple of used Big Irons and 4802s. Even though I do not have maintenance/support of the used equipment I still have access to the software and config guides. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E Barratt (Network Operations) Sent: Thursday, September 23, 2010 6:30 PM To: Brian Stadtmiller Cc: Subject: Re: [f-nsp] Gray Market Foundry Specifically on the support side. How does brocade deal with software upgrades on hardware not sold through traditional channels / used equipment etc? Is it worth it or does it cause headaches? Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for over 7 years to end-users, dealers and brokers, > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for over 7 years to end-users, dealers and brokers, > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > > _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp From rsm at fast-serv.com Fri Sep 24 11:52:27 2010 From: rsm at fast-serv.com (Randy McAnally) Date: Fri, 24 Sep 2010 11:52:27 -0400 Subject: [f-nsp] Gray Market Foundry In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E012FB331@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E012FB331@nkc-mailsrv.nkc.org> Message-ID: <20100924155038.M55511@fast-serv.com> I'm not interested in direct support with grey market equipment (obviously it's use-at-your-own-risk type of thing). The vendor should always sell it to you with the latest software and provide support as needed (within the warranty period of course) -- and this has always been the case for us. -- Randy M. www.FastServ.com ---------- Original Message ----------- From: "Michienne Dixon" To: N/A Cc: Sent: Fri, 24 Sep 2010 09:17:18 -0500 Subject: Re: [f-nsp] Gray Market Foundry > Prior to Foundry becoming Brocade, they had a recertification process > for their equipment that was not too painful. I have not purchased any > used Foundry equipment since that time though. It used to be that if > you were purchasing from a reseller that has a maintenance agreement > with Foundry then they could upgrade the software for you. I would > ask your reseller. > > We have maintenance on our MLX routers and I have a couple of used > Big Irons and 4802s. Even though I do not have maintenance/support > of the used equipment I still have access to the software and config > guides. > > - > Michienne Dixon > Network Administrator > liNKCity > 312 Armour Rd. > North Kansas City, MO 64116 > www.linkcity.org > (816) 412-7990 > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E Barratt > (Network Operations) > Sent: Thursday, September 23, 2010 6:30 PM > To: Brian Stadtmiller > Cc: > Subject: Re: [f-nsp] Gray Market Foundry > > Specifically on the support side. How does brocade deal with > software upgrades on hardware not sold through traditional channels / > used equipment etc? > > Is it worth it or does it cause headaches? > > Adam > > On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" > wrote: > > > I have sold new, used, and refurbished Foundry (now Brocade IP) > > hardware for over 7 years to end-users, dealers and brokers, > > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > > > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > > > companies. (Literally millions of dollars worth of Foundry/Brocade > > hardware.) > > > > Anyhow, Do you have specific concerns or questions you would like > > addressed? > > > > regards, > > > > > > Brian Stadtmiller > > Terabit Systems > > 2565 3rd Street #334 > > San Francisco, CA 94107 > > 415-230-4353 main > > 415-652-2888 cell > > AIM: bstadtmiller9609 > > > > > > > > > > > > -----Original Message----- > > From: foundry-nsp-bounces at puck.nether.net > > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > > Barratt (Sales Engineering) > > Sent: Thursday, September 23, 2010 3:16 PM > > To: foundry-nsp at puck.nether.net > > Subject: [f-nsp] Gray Market Foundry > > > > I was wondering if anyone has any experience with Gray Market Brocade > > > equipment? (specifically on the MLX line?) > > > > -Adam > > _______________________________________________ > > foundry-nsp mailing list > > foundry-nsp at puck.nether.net > > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > > > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > > 09/22/10 > > 23:34:00 > > > > Adam > > On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" > wrote: > > > I have sold new, used, and refurbished Foundry (now Brocade IP) > > hardware for over 7 years to end-users, dealers and brokers, > > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > > > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > > > companies. (Literally millions of dollars worth of Foundry/Brocade > > hardware.) > > > > Anyhow, Do you have specific concerns or questions you would like > > addressed? > > > > regards, > > > > > > Brian Stadtmiller > > Terabit Systems > > 2565 3rd Street #334 > > San Francisco, CA 94107 > > 415-230-4353 main > > 415-652-2888 cell > > AIM: bstadtmiller9609 > > > > > > > > > > > > -----Original Message----- > > From: foundry-nsp-bounces at puck.nether.net > > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > > Barratt (Sales Engineering) > > Sent: Thursday, September 23, 2010 3:16 PM > > To: foundry-nsp at puck.nether.net > > Subject: [f-nsp] Gray Market Foundry > > > > I was wondering if anyone has any experience with Gray Market Brocade > > > equipment? (specifically on the MLX line?) > > > > -Adam > > _______________________________________________ > > foundry-nsp mailing list > > foundry-nsp at puck.nether.net > > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > > > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > > 09/22/10 > > 23:34:00 > > > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp ------- End of Original Message ------- From georgeb at gmail.com Mon Sep 27 04:26:31 2010 From: georgeb at gmail.com (George B.) Date: Mon, 27 Sep 2010 01:26:31 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> Message-ID: On Mon, Sep 13, 2010 at 3:23 AM, Mike Hughes wrote: > --On 12 September 2010 12:09 -0700 "George B." wrote: > > > Oops, meant to reply all. No spanning tree anywhere on that vlan. In > > this case it is vlan 111 and metro ring 2 > > Is there any link-aggregation present on this ring? > > It could be something like source-port suppression failing on a LAG group. > > Mike > > Yes, there is a LAG in the ring. There are two 1G ports aggregated between two routers at one site. George. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at smashing.net Mon Sep 27 05:04:22 2010 From: mike at smashing.net (Mike Hughes) Date: Mon, 27 Sep 2010 10:04:22 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> Message-ID: <423C206E9753E0D862FE257E@two-one-four.se18.smashing.net> --On 27 September 2010 01:26:31 -0700 "George B." wrote: > Yes, there is a LAG in the ring.? There are two 1G ports aggregated > between two routers at one site. Okay, so what this could be is either: a) Failure of source-port suppression for the LAG - so usually, when a frame arrives to a broadcast, multicast, or unknown unicast address, it is forwarded out of all ports in that vlan other than the one it arrived on. This behaviour is obviously modified for a LAG, so that other ports in the same LAG as the incoming port do not get a copy of the frame. However, I have seen this behaviour fail on some Brocade equipment (Mostly Jetcore/MG8, I think once on RX), which causes the flooded frames to "trombone" along the LAG. This would create lots of extra copies of the RHPs. It's likely to break control protocols using broadcast/multicast DAs, and cause a lot of what looks like station movement, so look for high CPU, and MAC addresses flipping between source ports. b) The other option is a bad FID being programmed for the destination MAC address for the MRP RHP, which is causing the RHPs to be forwarded out of the wrong port on one of the switches. Just some ideas to investigate. Mike From foundry-nsp at pgmail.net Thu Sep 2 07:53:53 2010 From: foundry-nsp at pgmail.net (Philipp Geschke) Date: Thu, 02 Sep 2010 13:53:53 +0200 Subject: [f-nsp] Problem with IPv6 anycast Message-ID: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Hello, I seem to have issues understanding IPv6 anycast on NI MLX/XMR. My understanding is, that any router that does have an IPv6 address in a subnet should be listening on the Subnet-Router anycast address (RFC3513 section 2.6.1). When I configure an IPv6 unicast address on a MLX VE it shows that it joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): Interface VE 200 is up, line protocol is up [...] IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 [Preferred] Global unicast address(es): 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 Joined group address(es): ff02::1:ff00:1 ff02::1:ff00:0 ff02::1:ff00:2 ff02::1:ffe1:2f00 ff02::2 ff02::1 [...] Now when I try to ping that address from a client within the network 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX announcing it's UNIcast address: 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:f1:c:: source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags [router, solicited] destination link-address option (2), length 8 (1): 00:0c:db:e1:2f:00 0x0000: 000c dbe1 2f00 This causes the asking client to create an entry in its neighbour cache for the routers unicast address, but not realising, that this was the answer to its question, hence it keeps on sending solicitation messages for the anycast address. In my understanding the neighbour advertisement should have the unicast address as source, but should announce the anycast address. If I take a Linux box and enable ip6 forwarding in the kernel, it also joins that very same anycast group. If I do the same test again, you can see, that the Linux box answers with its unicast address, announcing the anycast address: 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, solicited] destination link-address option (2), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 This works and the client creates an entry in its neighbour cache for the anycast address and can now communicate with the address. Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 you can see in the output of the interface. If it matters, I do have ipv6 nd suppress-ra active on that VE. So what does this mean, is it a) Me not understanding the concept of the anycast address (basicaly I want to use it as a default gateway)? b) A problem with my configuration (which is pretty plain for v6 right now)? c) A bug? d) ?? Does anyone have experience with that they are able to share? Thanks for any hints, Philipp From rob.lister at netsumo.com Thu Sep 2 13:32:03 2010 From: rob.lister at netsumo.com (Rob Lister) Date: Thu, 2 Sep 2010 18:32:03 +0100 Subject: [f-nsp] Enabling Q-in-Q on RX Message-ID: <20100902173203.GA12418@netsumo.com> Greetings, I have a customer that would like us to enable a q-in-q trunk across a network of RX-8s, and the documentation seems a little vague in places. If anyone has enabled this on RX / XMR platform, I would greatly appreciate any advice on what happens when it's enabled. The documentation for RX suggests doing: BigIron RX(config)# tag-type 9100 e3/1 to 3/2 BigIron RX(config)# aggregated-vlan 1. What is the interaction between the 'aggregated-vlan' command and the default-max-frame-size on RX? Behaviour of the smaller (non-RX) switches: SW3(config)#default-mtu 1600 Aggregated VLAN is in effect.10/100M ports will be set to default MTU 1530. SW3#show int ethe 3 FastEthernet3 is down, line protocol is down ... MTU 1530 bytes, encapsulation ethernet ... ... After reload, however, it sets it back to 1600. The RX doesn't quite have the same options, however, but doesn't suggest a frame limit for aggregated-vlan. So.. on an RX q-in-q port, what can the maximum MTU be? What's the default "mini-jumbo" frame size? RX: SSH at RX-8(config)#agg? aggregated-vlan Allow mini-jumbo frames to allow multiple vlan tags FI4802: SW3(config)#agg aggregated-vlan support for larger Ethernet frame up to 1530 bytes 2. Changing tag-type on the RX. Documentation points out that it will change it for a port region, not just the ports involved. "Note that since ports 11 and 12 belong to the port region 1 ? 12, the 802.1Q tag actually applies to ports 1 ? 12." It doesn't say what happens to the other ports, though. Does this mean that we cannot use the other ports not involved in the q-in-q configuration for normal (non q-n-q traffic?) What happens if it receives normal untagged frames? The documentation is also unclear about port regions, as it then suggests, under "enabling 802.1q tag-type translation": "Note that since ports 11 and 12 belong to the port region 9 ? 16, the 802.1q tag-type actually applies to ports 9 ? 16." So which is it? A port region of 8 or 12 ports? I am thinking it's 12, as there is more mention of that. If anyone has set this up I would appreciate any pointers/hints! thanks, Rob From harbor235 at gmail.com Thu Sep 2 14:16:40 2010 From: harbor235 at gmail.com (harbor235) Date: Thu, 2 Sep 2010 14:16:40 -0400 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: Good question, RFC2526 hs more meat concerning anycast reserver addresses, I have a couple questions too; 1) Can you allocate additional anycast addresses out of the unicast space other than the 127-n bits identified? 2) how does your client machine behave when a reservered anycast address is used? On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke wrote: > Hello, > > I seem to have issues understanding IPv6 anycast on NI MLX/XMR. > My understanding is, that any router that does have an IPv6 address in a > subnet should be listening on the Subnet-Router anycast address (RFC3513 > section 2.6.1). > > When I configure an IPv6 unicast address on a MLX VE it shows that it > joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): > > Interface VE 200 is up, line protocol is up > [...] > IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 > [Preferred] > Global unicast address(es): > 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 > 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 > 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 > 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 > Joined group address(es): > ff02::1:ff00:1 > ff02::1:ff00:0 > ff02::1:ff00:2 > ff02::1:ffe1:2f00 > ff02::2 > ff02::1 > [...] > > Now when I try to ping that address from a client within the network > 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX announcing > it's UNIcast address: > > 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor > solicitation, length 32, who has 2001:db8:f1:c:: > source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload > length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, > neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags [router, > solicited] > destination link-address option (2), length 8 (1): > 00:0c:db:e1:2f:00 > 0x0000: 000c dbe1 2f00 > > This causes the asking client to create an entry in its neighbour cache > for the routers unicast address, but not realising, that this was the > answer to its question, hence it keeps on sending solicitation messages for > the anycast address. > In my understanding the neighbour advertisement should have the unicast > address as source, but should announce the anycast address. > > If I take a Linux box and enable ip6 forwarding in the kernel, it also > joins that very same anycast group. If I do the same test again, you can > see, > that the Linux box answers with its unicast address, announcing the > anycast address: > > 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor > advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, solicited] > destination link-address option (2), length 8 (1): > 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > > This works and the client creates an entry in its neighbour cache for the > anycast address and can now communicate with the address. > > Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 > you can see in the output of the interface. > > If it matters, I do have ipv6 nd suppress-ra active on that VE. > > > So what does this mean, is it > > a) Me not understanding the concept of the anycast address (basicaly I > want to use it as a default gateway)? > b) A problem with my configuration (which is pretty plain for v6 right > now)? > c) A bug? > d) ?? > > Does anyone have experience with that they are able to share? > > > Thanks for any hints, > Philipp > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Thu Sep 2 14:20:35 2010 From: harbor235 at gmail.com (harbor235) Date: Thu, 2 Sep 2010 14:20:35 -0400 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: There is more ....... On Thu, Sep 2, 2010 at 2:16 PM, harbor235 wrote: > Good question, RFC2526 hs more meat concerning anycast reserver addresses, > I have a couple questions too; > > 1) Can you allocate additional anycast addresses out of the unicast space > other than the 127-n bits identified? (n bits = subnet prefix) > > 2) how does your client machine behave when a reservered anycast address is > used? > all bits of the interface identifier are set to ones except the last 7 bits which range in value from 0-125 (126 and 127 are reserverd or assigned) 3) What OS was the original client machine? harbor235 ;} > > > > On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke wrote: > >> Hello, >> >> I seem to have issues understanding IPv6 anycast on NI MLX/XMR. >> My understanding is, that any router that does have an IPv6 address in a >> subnet should be listening on the Subnet-Router anycast address (RFC3513 >> section 2.6.1). >> >> When I configure an IPv6 unicast address on a MLX VE it shows that it >> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): >> >> Interface VE 200 is up, line protocol is up >> [...] >> IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 >> [Preferred] >> Global unicast address(es): >> 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 >> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >> 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 >> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >> Joined group address(es): >> ff02::1:ff00:1 >> ff02::1:ff00:0 >> ff02::1:ff00:2 >> ff02::1:ffe1:2f00 >> ff02::2 >> ff02::1 >> [...] >> >> Now when I try to ping that address from a client within the network >> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX >> announcing >> it's UNIcast address: >> >> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) >> 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor >> solicitation, length 32, who has 2001:db8:f1:c:: >> source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 >> 0x0000: 0016 3e19 16a9 >> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload >> length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, >> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags [router, >> solicited] >> destination link-address option (2), length 8 (1): >> 00:0c:db:e1:2f:00 >> 0x0000: 000c dbe1 2f00 >> >> This causes the asking client to create an entry in its neighbour cache >> for the routers unicast address, but not realising, that this was the >> answer to its question, hence it keeps on sending solicitation messages >> for >> the anycast address. >> In my understanding the neighbour advertisement should have the unicast >> address as source, but should announce the anycast address. >> >> If I take a Linux box and enable ip6 forwarding in the kernel, it also >> joins that very same anycast group. If I do the same test again, you can >> see, >> that the Linux box answers with its unicast address, announcing the >> anycast address: >> >> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) >> 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor >> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, >> solicited] >> destination link-address option (2), length 8 (1): >> 00:16:3e:19:16:a9 >> 0x0000: 0016 3e19 16a9 >> >> This works and the client creates an entry in its neighbour cache for the >> anycast address and can now communicate with the address. >> >> Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 >> you can see in the output of the interface. >> >> If it matters, I do have ipv6 nd suppress-ra active on that VE. >> >> >> So what does this mean, is it >> >> a) Me not understanding the concept of the anycast address (basicaly I >> want to use it as a default gateway)? >> b) A problem with my configuration (which is pretty plain for v6 right >> now)? >> c) A bug? >> d) ?? >> >> Does anyone have experience with that they are able to share? >> >> >> Thanks for any hints, >> Philipp >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foundry-nsp at pgmail.net Fri Sep 3 04:01:07 2010 From: foundry-nsp at pgmail.net (Philipp Geschke) Date: Fri, 03 Sep 2010 10:01:07 +0200 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: Hi, Thank you for your reply! On Thu, 2 Sep 2010 14:20:35 -0400, harbor235 wrote: > On Thu, Sep 2, 2010 at 2:16 PM, harbor235 wrote: > >> I have a couple questions too; >> >> 1) Can you allocate additional anycast addresses out of the unicast space >> other than the 127-n bits identified? (n bits = subnet prefix) >> If I get you correct (sorry if not, I am not a native speaker ;-)), then "ipv6 address 2001:db8:f1:c:1:2:3:fe/64 anycast" qualifies for this test? The result is pretty much the same, with the interesting fact, that the MLX announces it Link-Local address now: 09:55:10.233664 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > ff02::1:ff03:fe: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:f1:c:1:2:3:fe source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 09:55:10.233664 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:dbff:fee1:2f00 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, Flags [router, solicited, override] destination link-address option (2), length 8 (1): 00:0c:db:e1:2f:00 0x0000: 000c dbe1 2f00 >> 2) how does your client machine behave when a reservered anycast address >> is >> used? >> > all bits of the interface identifier are set to ones except the last > 7 bits which range in > value from 0-125 (126 and 127 are reserverd or assigned) > Using "ipv6 address 2001:db8:f1:c:ffff:ffff:ffff:ff7a/64 anycast", which, I think, qualifies for this test? 09:17:09.939237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2001:db8:f1:c::160 > ff02::1:ffff:ff7a: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2001:db8:f1:c:ffff:ffff:ffff:ff7a source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 0x0000: 0016 3e19 16a9 09:17:09.939237 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::20c:dbff:fee1:2f00 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, Flags [router, solicited, override] destination link-address option (2), length 8 (1): 00:0c:db:e1:2f:00 0x0000: 000c dbe1 2f00 > 3) What OS was the original client machine? Everything used in my tests is either NI MLX with IronWare 05000b or plain Debian GNU/Linux Lenny: # uname -r 2.6.26-2-amd64 Thanks for your help! Regards, Philipp > > > harbor235 ;} > >> >> >> >> On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke >> wrote: >> >>> Hello, >>> >>> I seem to have issues understanding IPv6 anycast on NI MLX/XMR. >>> My understanding is, that any router that does have an IPv6 address in a >>> subnet should be listening on the Subnet-Router anycast address (RFC3513 >>> section 2.6.1). >>> >>> When I configure an IPv6 unicast address on a MLX VE it shows that it >>> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): >>> >>> Interface VE 200 is up, line protocol is up >>> [...] >>> IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 >>> [Preferred] >>> Global unicast address(es): >>> 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 >>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>> 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 >>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>> Joined group address(es): >>> ff02::1:ff00:1 >>> ff02::1:ff00:0 >>> ff02::1:ff00:2 >>> ff02::1:ffe1:2f00 >>> ff02::2 >>> ff02::1 >>> [...] >>> >>> Now when I try to ping that address from a client within the network >>> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX >>> announcing >>> it's UNIcast address: >>> >>> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>> 32) >>> 2001:db8:f1:c::160 > ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor >>> solicitation, length 32, who has 2001:db8:f1:c:: >>> source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 >>> 0x0000: 0016 3e19 16a9 >>> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) >>> payload >>> length: 32) 2001:db8:f1:c::2 > 2001:db8:f1:c::160: [icmp6 sum ok] ICMP6, >>> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags >>> [router, >>> solicited] >>> destination link-address option (2), length 8 (1): >>> 00:0c:db:e1:2f:00 >>> 0x0000: 000c dbe1 2f00 >>> >>> This causes the asking client to create an entry in its neighbour cache >>> for the routers unicast address, but not realising, that this was the >>> answer to its question, hence it keeps on sending solicitation messages >>> for >>> the anycast address. >>> In my understanding the neighbour advertisement should have the unicast >>> address as source, but should announce the anycast address. >>> >>> If I take a Linux box and enable ip6 forwarding in the kernel, it also >>> joins that very same anycast group. If I do the same test again, you can >>> see, >>> that the Linux box answers with its unicast address, announcing the >>> anycast address: >>> >>> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>> 32) >>> 2001:db8:f1:c::160 > 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor >>> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, >>> solicited] >>> destination link-address option (2), length 8 (1): >>> 00:16:3e:19:16:a9 >>> 0x0000: 0016 3e19 16a9 >>> >>> This works and the client creates an entry in its neighbour cache for >>> the >>> anycast address and can now communicate with the address. >>> >>> Same goes for the explicitly configured anycast address 2001:db8:f1:c::1 >>> you can see in the output of the interface. >>> >>> If it matters, I do have ipv6 nd suppress-ra active on that VE. >>> >>> >>> So what does this mean, is it >>> >>> a) Me not understanding the concept of the anycast address (basicaly I >>> want to use it as a default gateway)? >>> b) A problem with my configuration (which is pretty plain for v6 right >>> now)? >>> c) A bug? >>> d) ?? >>> >>> Does anyone have experience with that they are able to share? >>> >>> >>> Thanks for any hints, >>> Philipp >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> foundry-nsp at puck.nether.net >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >> >> From dana at zeroloops.com Fri Sep 3 04:46:44 2010 From: dana at zeroloops.com (Dana) Date: Fri, 03 Sep 2010 10:46:44 +0200 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> Message-ID: <4C80B5F4.4010002@zeroloops.com> Hello, Let me share this information (from Brocade TAC). """"" Code 5.1 will have support for vrrp-e and vrrpv3 for IPv6. Current schedule for the code is by end of September. """"" However, Brocade will support vrrpv3 + vrrp-e for IPv6 only in the Netiron models for now (code 5.1). Unfortunately, for any other models, they do not have any plans yet whether they are going to support this. On the other hand, I need this support for our BigIron RXes, but I get the following reply: """"" I just got words from the developers where it is mentioned that Engineering is planning very limited enhancements in RX code; therefore, no plans to support this feature on RX platform. This is a case where customer may submit a feature request for this protocol to be included in a future code release. For a workaround, they were no sure how could be done, if there is no way to test reliable. Let you know """"" Another reply was: """"" First. To submit a Feature Request, please talk to our account team in your area, I think you have that information available about who are those persons. They will then communicate with our developers to see the course of action. I agree with you tha IPv6 is being used more and more by our customer specially in Europe. Not having support for VRRP and IPv6 make this system somehow limited for redundancy. I did a brain storming with our team here, and no solution possible to make redundancy like VRRP """"" Dana Dana ZeroLoops - Webhosting Provider http://www.zeroloops.com dana at zeroloops.com +31 62 692 5403 On 9/3/2010 10:01 AM, Philipp Geschke wrote: > Hi, > > Thank you for your reply! > > On Thu, 2 Sep 2010 14:20:35 -0400, harbor235 wrote: >> On Thu, Sep 2, 2010 at 2:16 PM, harbor235 wrote: >> >>> I have a couple questions too; >>> >>> 1) Can you allocate additional anycast addresses out of the unicast > space >>> other than the 127-n bits identified? (n bits = subnet prefix) >>> > If I get you correct (sorry if not, I am not a native speaker ;-)), then > "ipv6 address 2001:db8:f1:c:1:2:3:fe/64 anycast" qualifies for this test? > The result is pretty much the same, with the interesting fact, that the > MLX announces it Link-Local address now: > > 09:55:10.233664 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160> ff02::1:ff03:fe: [icmp6 sum ok] ICMP6, neighbor > solicitation, length 32, who has 2001:db8:f1:c:1:2:3:fe > source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > 09:55:10.233664 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload > length: 32) fe80::20c:dbff:fee1:2f00> 2001:db8:f1:c::160: [icmp6 sum ok] > ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, > Flags [router, solicited, override] > destination link-address option (2), length 8 (1): > 00:0c:db:e1:2f:00 > 0x0000: 000c dbe1 2f00 > >>> 2) how does your client machine behave when a reservered anycast > address >>> is >>> used? >>> >> all bits of the interface identifier are set to ones except the > last >> 7 bits which range in >> value from 0-125 (126 and 127 are reserverd or assigned) >> > Using "ipv6 address 2001:db8:f1:c:ffff:ffff:ffff:ff7a/64 anycast", which, > I think, qualifies for this test? > > 09:17:09.939237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) > 2001:db8:f1:c::160> ff02::1:ffff:ff7a: [icmp6 sum ok] ICMP6, neighbor > solicitation, length 32, who has 2001:db8:f1:c:ffff:ffff:ffff:ff7a > source link-address option (1), length 8 (1): 00:16:3e:19:16:a9 > 0x0000: 0016 3e19 16a9 > 09:17:09.939237 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) payload > length: 32) fe80::20c:dbff:fee1:2f00> 2001:db8:f1:c::160: [icmp6 sum ok] > ICMP6, neighbor advertisement, length 32, tgt is fe80::20c:dbff:fee1:2f00, > Flags [router, solicited, override] > destination link-address option (2), length 8 (1): > 00:0c:db:e1:2f:00 > 0x0000: 000c dbe1 2f00 > > >> 3) What OS was the original client machine? > Everything used in my tests is either NI MLX with IronWare 05000b or plain > Debian GNU/Linux Lenny: > > # uname -r > 2.6.26-2-amd64 > > > Thanks for your help! > > Regards, > Philipp > >> >> harbor235 ;} >> >>> >>> >>> On Thu, Sep 2, 2010 at 7:53 AM, Philipp Geschke >>> wrote: >>> >>>> Hello, >>>> >>>> I seem to have issues understanding IPv6 anycast on NI MLX/XMR. >>>> My understanding is, that any router that does have an IPv6 address in > a >>>> subnet should be listening on the Subnet-Router anycast address > (RFC3513 >>>> section 2.6.1). >>>> >>>> When I configure an IPv6 unicast address on a MLX VE it shows that it >>>> joins the Subnet-Router anycast address (2001:db8:f1:c:: [Anycast]): >>>> >>>> Interface VE 200 is up, line protocol is up >>>> [...] >>>> IPv6 is enabled, link-local address is fe80::20c:dbff:fee1:2f00 >>>> [Preferred] >>>> Global unicast address(es): >>>> 2001:db8:f1:c::2 [Preferred], subnet is 2001:db8:f1:c::/64 >>>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>>> 2001:db8:f1:c::1 [Anycast], subnet is 2001:db8:f1:c::/64 >>>> 2001:db8:f1:c:: [Anycast], subnet is 2001:db8:f1:c::/64 >>>> Joined group address(es): >>>> ff02::1:ff00:1 >>>> ff02::1:ff00:0 >>>> ff02::1:ff00:2 >>>> ff02::1:ffe1:2f00 >>>> ff02::2 >>>> ff02::1 >>>> [...] >>>> >>>> Now when I try to ping that address from a client within the network >>>> 2001:db8:f1:c::/64, I get a neighbour advertisement from the MLX >>>> announcing >>>> it's UNIcast address: >>>> >>>> 16:02:40.548719 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>>> 32) >>>> 2001:db8:f1:c::160> ff02::1:ff00:0: [icmp6 sum ok] ICMP6, neighbor >>>> solicitation, length 32, who has 2001:db8:f1:c:: >>>> source link-address option (1), length 8 (1): > 00:16:3e:19:16:a9 >>>> 0x0000: 0016 3e19 16a9 >>>> 16:02:40.548719 IP6 (class 0xc0, hlim 255, next-header ICMPv6 (58) >>>> payload >>>> length: 32) 2001:db8:f1:c::2> 2001:db8:f1:c::160: [icmp6 sum ok] > ICMP6, >>>> neighbor advertisement, length 32, tgt is 2001:db8:f1:c::2, Flags >>>> [router, >>>> solicited] >>>> destination link-address option (2), length 8 (1): >>>> 00:0c:db:e1:2f:00 >>>> 0x0000: 000c dbe1 2f00 >>>> >>>> This causes the asking client to create an entry in its neighbour > cache >>>> for the routers unicast address, but not realising, that this was the >>>> answer to its question, hence it keeps on sending solicitation > messages >>>> for >>>> the anycast address. >>>> In my understanding the neighbour advertisement should have the > unicast >>>> address as source, but should announce the anycast address. >>>> >>>> If I take a Linux box and enable ip6 forwarding in the kernel, it also >>>> joins that very same anycast group. If I do the same test again, you > can >>>> see, >>>> that the Linux box answers with its unicast address, announcing the >>>> anycast address: >>>> >>>> 12:50:36.194948 IP6 (hlim 255, next-header ICMPv6 (58) payload length: >>>> 32) >>>> 2001:db8:f1:c::160> 2001:db8:f1:c::21: [icmp6 sum ok] ICMP6, neighbor >>>> advertisement, length 32, tgt is 2001:db8:f1:c::, Flags [router, >>>> solicited] >>>> destination link-address option (2), length 8 (1): >>>> 00:16:3e:19:16:a9 >>>> 0x0000: 0016 3e19 16a9 >>>> >>>> This works and the client creates an entry in its neighbour cache for >>>> the >>>> anycast address and can now communicate with the address. >>>> >>>> Same goes for the explicitly configured anycast address > 2001:db8:f1:c::1 >>>> you can see in the output of the interface. >>>> >>>> If it matters, I do have ipv6 nd suppress-ra active on that VE. >>>> >>>> >>>> So what does this mean, is it >>>> >>>> a) Me not understanding the concept of the anycast address (basicaly I >>>> want to use it as a default gateway)? >>>> b) A problem with my configuration (which is pretty plain for v6 right >>>> now)? >>>> c) A bug? >>>> d) ?? >>>> >>>> Does anyone have experience with that they are able to share? >>>> >>>> >>>> Thanks for any hints, >>>> Philipp >>>> >>>> _______________________________________________ >>>> foundry-nsp mailing list >>>> foundry-nsp at puck.nether.net >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>>> >>> > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp From jchome at jc-ix.net Fri Sep 3 05:30:06 2010 From: jchome at jc-ix.net (Frederic Jaeckel) Date: Fri, 03 Sep 2010 11:30:06 +0200 Subject: [f-nsp] CES/CER 2000 and VRRP Message-ID: <4C80C01E.1020108@jc-ix.net> Hey, I just looked through my docs and they are saying that VRRP is not supported by the CER/CES 2000 systems. Can someone please say it's not true and my docs are just too old? :) Best regards, Frederic Jaeckel From lee.pedder at gmail.com Fri Sep 3 06:27:49 2010 From: lee.pedder at gmail.com (Lee Pedder) Date: Fri, 3 Sep 2010 12:27:49 +0200 Subject: [f-nsp] CES/CER 2000 and VRRP In-Reply-To: <4C80C01E.1020108@jc-ix.net> References: <4C80C01E.1020108@jc-ix.net> Message-ID: Hi Frederic, The release notes I have for 4.1.00d say that VRRP and VRRPE are both supported on the CER / CES right the way through from BASE to PREM. Regards, Lee On 3 September 2010 11:30, Frederic Jaeckel wrote: > Hey, > > I just looked through my docs and they are saying that VRRP is not > supported by the CER/CES 2000 systems. Can someone please say it's not > true and my docs are just too old? :) > > Best regards, > Frederic Jaeckel > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > From Neil.Robst at ioko.com Fri Sep 3 07:32:34 2010 From: Neil.Robst at ioko.com (Neil Robst) Date: Fri, 3 Sep 2010 12:32:34 +0100 Subject: [f-nsp] CES/CER 2000 and VRRP In-Reply-To: References: <4C80C01E.1020108@jc-ix.net> Message-ID: <7A57DCAA71129142A6EF9C0074D38A8F2C057CD1D4@INTCL1EX01.uk.ioko365.com> Yeah - seems to be working fine on my CES2024's running v5 :-) System: NetIron CES (Serial #: xxxxxxxxx, Part #: 35701-002A) License: L3_PREM (LID: XXXXXXXXX) Boot : Version 5.0.0T185 Copyright (c) 1996-2009 Brocade Communications Systems, Inc. #sh ip vrrp-extended brief Total number of VRRP-Extended routers defined: 1 Inte- VRID Current P State Master IP Backup IP Virtual IP Short- rface Priority Address Address Address Path-Fwd -------------------------------------------------------------------------------------- v10 66 120 P Master Local xx.xx.xx.35 xx.xx.xx.46 Regards, Neil -----Original Message----- From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Lee Pedder Sent: 03 September 2010 11:28 To: Frederic Jaeckel Cc: foundry-nsp at puck.nether.net Subject: Re: [f-nsp] CES/CER 2000 and VRRP Hi Frederic, The release notes I have for 4.1.00d say that VRRP and VRRPE are both supported on the CER / CES right the way through from BASE to PREM. Regards, Lee On 3 September 2010 11:30, Frederic Jaeckel wrote: > Hey, > > I just looked through my docs and they are saying that VRRP is not > supported by the CER/CES 2000 systems. Can someone please say it's not > true and my docs are just too old? :) > > Best regards, > Frederic Jaeckel > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp From jeroen at easyhosting.nl Fri Sep 3 08:39:15 2010 From: jeroen at easyhosting.nl (Jeroen Wunnink) Date: Fri, 03 Sep 2010 14:39:15 +0200 Subject: [f-nsp] IPv6 subnets flapping on Bigiron 4000 jetcore Message-ID: <4C80EC73.4010104@easyhosting.nl> We have two Bigiron 4000 Jetcores running B2P08.0.01s firmware and we're experiencing very unstable IPv6 behaviour. These Bigirons have several ve's with customer subnets on there in a dual stack config (/24 for IPv4 and /64 for IPv6) and OSPF as IGP between devices. (Also two XMR's, but they work just fine) On at least one of of these Bigirons, one or more /64 IPv6 subnets frequently becomes unavailable, the /24 IPv4 subnet on the ve works fine, but IPv6 enabled servers are suddenly unable to ping the ve's IPv6 address (which is the gateway) and the Bigiron is unable to ping the host's address over IPv6. It's happening on the whole subnet, we have three servers with IPv6 connectivity monitoring this and they all report the ve's IP becoming unreachable. Removing the ve's IPv6 address and adding it back solves it for a while, but after a day or so it starts acting up again. Yet it's not all subnets at once, one time it's a customer subnet, at other times it's the /126 subnet between XMR and Bigiron I've been going over the release notes for the Bigiron (since the latest release is 08.0.01w), but I can't find any IPv6 related fixes that match this. Anyone else seeing odd IPv6 behaviour on Bigirons ? (yes we have future MLX upgrade plans, but for now these units will have to suffice :-) -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl From foundry-nsp at pgmail.net Fri Sep 3 10:52:01 2010 From: foundry-nsp at pgmail.net (Philipp Geschke) Date: Fri, 03 Sep 2010 16:52:01 +0200 Subject: [f-nsp] Problem with IPv6 anycast In-Reply-To: <4C80B5F4.4010002@zeroloops.com> References: <1c20193785b7c99093cad1729e56a420@yoshi.blafaselblub.net> <4C80B5F4.4010002@zeroloops.com> Message-ID: Hi, On Fri, 03 Sep 2010 10:46:44 +0200, Dana wrote: > """"" > Code 5.1 will have support for vrrp-e and vrrpv3 for IPv6. > Current schedule for the code is by end of September. > """"" Thanks for sharing this information. The lack of VRRP support for v6 was the reason why I turned to the subnet router anycast address in the first place. If 5.1 will support VRRPv3 then I will most likely just wait for that. But still this does not explain to me, why the MLX has such a strange behaviour on the subnet router anycast address. If no one else has an idea, I will propably open a bug report. Thanks, Philipp From frnkstr at gmail.com Sat Sep 4 15:15:50 2010 From: frnkstr at gmail.com (Frank Suter) Date: Sat, 4 Sep 2010 21:15:50 +0200 Subject: [f-nsp] MPLS feasibility Message-ID: Dear all, I am writing to this list, because I am using Brocade/Foundry routers and switches. This is maybe not the most accurate list, if so, please accept my apologies. Here is the context: I am currently having a datacenter presence where I do run my own AS with three ISPs, each with full BGP table and a /23 PI dedicated to the servers and Internet access. Because this is considered as the consolidated Internet access and datacenter, I would like to hub the office with this connection. Now my goal is to connect the office with the datacenter using a symmetric 100/100 Mbit link running MPLS service from my ISP. This will be delivered as a service. Now, because redundancy is important for me, I would link to have a second link 100/100 Mbit, but rather than asking the same provider to secure the path, I would like to ask this to a second provider because I do not trust one provider to do redundancy for me. I know that each provider are using physical different path to reach the Data Center. Questions: 1) Can I build a redundant MPLS access with two different providers and aggregate them together on each end? Thus having two paths of 100 Mbit symmetric each. Possible? 2) What equipment do I need on the office side to do this? 3) How long is the convergence time to expect in case of major failure on one of the links? Thank you for your time and advices. Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Sat Sep 4 17:57:52 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 4 Sep 2010 22:57:52 +0100 Subject: [f-nsp] MPLS feasibility In-Reply-To: References: Message-ID: Hi Frank, Are you talking about an lan extension service / pseudowires / vpls / etc ie. Ethernet that the carriers are tunneling over MPLS? If that is the case, it should be delivered as a simple ethernet circuit to you. Of course you can do load balancing over 2 ethernet links, you can play with metrics and have redundancy too. You cannot have both though obviously (if you use >100Mb/s). Something to consider if you are load balancing like this: the circuits will have different latency and packets *will* get out of order. The best advice however is you should contract a consultant or a company to fully understand what you want to achieve and give you case specific guidance. If everyone in your situation got free 'professional services' on these forums, we would all be out of jobs! :) Best of luck Heath On 4 September 2010 20:15, Frank Suter wrote: > Dear all, > > I am writing to this list, because I am using Brocade/Foundry routers and > switches. This is maybe not the most accurate list, if so, please accept my > apologies. > > Here is the context: I am currently having a datacenter presence where I do > run my own AS with three ISPs, each with full BGP table and a /23 PI > dedicated to the servers and Internet access. Because this is considered as > the consolidated Internet access and datacenter, I would like to hub the > office with this connection. > > Now my goal is to connect the office with the datacenter using a symmetric > 100/100 Mbit link running MPLS service from my ISP. This will be delivered > as a service. Now, because redundancy is important for me, I would link to > have a second link 100/100 Mbit, but rather than asking the same provider to > secure the path, I would like to ask this to a second provider because I do > not trust one provider to do redundancy for me. > > I know that each provider are using physical different path to reach the > Data Center. > > Questions: > > 1) Can I build a redundant MPLS access with two different providers and > aggregate them together on each end? Thus having two paths of 100 Mbit > symmetric each. Possible? > 2) What equipment do I need on the office side to do this? > 3) How long is the convergence time to expect in case of major failure on > one of the links? > > Thank you for your time and advices. > > Frank > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From frnkstr at gmail.com Mon Sep 6 10:36:24 2010 From: frnkstr at gmail.com (Frank Suter) Date: Mon, 6 Sep 2010 16:36:24 +0200 Subject: [f-nsp] MPLS feasibility In-Reply-To: References: Message-ID: Hello Heath, Thanks for your input. Yes this is a LAN extension and I am obviously going to discuss this with a proper consultant, but there are not millions of them around here so I am trying to touch base here so I can brief accurately my ISP/integrator about what I want to achieve and make sure it is possible. I might be asking one of my ISPs to do the redundancy and implementation for me, as they are more or less neutral with this, but I know that if I would ask my ISP about redundancy, they would be offering me a "protected" ring on their network, which would be like a waste of money for me from past experience. Usually when things goes wrong, they go totally wrong and I have already seen two carriers going down together for physical path damage although they were not supposed to share it. Based on the facts, I know that in the building there are two different carriers that bring each their own FO. They are competitors and hate each other and will never work together, which is good for me. Each of them makes us of a different physical path to reach the end-point for legacy reasons. I am quite confident about both being able to deliver this service with an RTT of 3 ms maximum. I am thinking about all options possible here. I am thinking about having for instance one of the MPLS line dedicated for voice and the other one dedicated for the data with a pre-configured QoS, so that I can have a fail-over mechanism in case of worst event without risk of hours and hours of downtime in worst case scenario. Once again, thank you Heath. Frank 2010/9/4 Heath Jones > Hi Frank, > > Are you talking about an lan extension service / pseudowires / vpls / etc > ie. Ethernet that the carriers are tunneling over MPLS? > If that is the case, it should be delivered as a simple ethernet circuit to > you. Of course you can do load balancing over 2 ethernet links, you can play > with metrics and have redundancy too. You cannot have both though obviously > (if you use >100Mb/s). Something to consider if you are load balancing like > this: the circuits will have different latency and packets *will* get out of > order. > > The best advice however is you should contract a consultant or a company to > fully understand what you want to achieve and give you case specific > guidance. > > If everyone in your situation got free 'professional services' on these > forums, we would all be out of jobs! :) > > > Best of luck > Heath > > > > On 4 September 2010 20:15, Frank Suter wrote: > >> Dear all, >> >> I am writing to this list, because I am using Brocade/Foundry routers and >> switches. This is maybe not the most accurate list, if so, please accept my >> apologies. >> >> Here is the context: I am currently having a datacenter presence where I >> do run my own AS with three ISPs, each with full BGP table and a /23 PI >> dedicated to the servers and Internet access. Because this is considered as >> the consolidated Internet access and datacenter, I would like to hub the >> office with this connection. >> >> Now my goal is to connect the office with the datacenter using a symmetric >> 100/100 Mbit link running MPLS service from my ISP. This will be delivered >> as a service. Now, because redundancy is important for me, I would link to >> have a second link 100/100 Mbit, but rather than asking the same provider to >> secure the path, I would like to ask this to a second provider because I do >> not trust one provider to do redundancy for me. >> >> I know that each provider are using physical different path to reach the >> Data Center. >> >> Questions: >> >> 1) Can I build a redundant MPLS access with two different providers and >> aggregate them together on each end? Thus having two paths of 100 Mbit >> symmetric each. Possible? >> 2) What equipment do I need on the office side to do this? >> 3) How long is the convergence time to expect in case of major failure on >> one of the links? >> >> Thank you for your time and advices. >> >> Frank >> >> >> _______________________________________________ >> foundry-nsp mailing list >> >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vinny_Abello at dell.com Tue Sep 7 12:00:01 2010 From: Vinny_Abello at dell.com (Abello, Vinny) Date: Tue, 7 Sep 2010 11:00:01 -0500 Subject: [f-nsp] XMR CoPP or equivalent? Message-ID: Hi all, I have been trying to locate any documentation for something equivalent to Cisco's CoPP (control-plane policing) for the Foundry/Brocade NetIron XMR and haven't had much success. Does such a feature even exist or is it even needed on this platform? I can't imagine the control-plane is completely immune to attack out of the box. Any pointers to documentation or what the feature or features are called? Thanks! -Vinny -------------- next part -------------- An HTML attachment was scrubbed... URL: From Vinny_Abello at dell.com Thu Sep 9 19:24:48 2010 From: Vinny_Abello at dell.com (Abello, Vinny) Date: Thu, 9 Sep 2010 18:24:48 -0500 Subject: [f-nsp] XMR CoPP or equivalent? In-Reply-To: References: Message-ID: <413A9D29-BDF1-411D-B008-80490E35685F@dell.com> I have my answer after contacting Brocade and will post it here for the benefit of anyone else seeking the same answer. What I was looking for was rACLs although there are a few other features as specified below. This was the response from Brocade: Here are some of the security features that can be used to protect CPU. This is in addition to the access policies and rate limiting of traffic. Please note that each of these functions has benefits and restrictions. Hence please go through the documentation prior implementing any of these. IP Receive ACLs The IP receive access-control list feature (rACL) provides hardware-based filtering capability for IPv4 traffic destined for the CPU in the default VRF such as management traffic. Its purpose is to protect the management module's CPU from overloading due to large amounts of traffic sent to one of the NetIron router's IP interfaces. Using the rACL command, the specified ACL is applied to every interface on the NetIron router. This eliminates the need to add an ACL to each interface on a NetIron router. Transparent VLAN Flooding You can configure your NetIron router for transparent VLAN flooding. This feature allows packets to be forwarded without any form of CPU intervention including MAC learning and MAC destination lookups VLAN CPU Protection VLAN CPU protection is recommended for the VLANs which are intended for pure Layer2 use. This feature will protect the CPU from the flooding of unknown-unicast/multicast/broadcast L2 packets on that VLAN. Protecting Against Denial of Service Attacks Denial of Smurf/TCP SYN/Reset attacks are explained here. All these features are explained in the documentation gude and can be downloaded using the following link http://kp.foundrynet.com/Portal/software/default.asp?ACT=DIR&NAME=NetIronXMR-MLX.700\05000.700\05000.700\Manuals.700 On Sep 7, 2010, at 12:00 PM, Abello, Vinny wrote: Hi all, I have been trying to locate any documentation for something equivalent to Cisco?s CoPP (control-plane policing) for the Foundry/Brocade NetIron XMR and haven?t had much success. Does such a feature even exist or is it even needed on this platform? I can?t imagine the control-plane is completely immune to attack out of the box. Any pointers to documentation or what the feature or features are called? Thanks! -Vinny _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sat Sep 11 15:02:03 2010 From: georgeb at gmail.com (George B.) Date: Sat, 11 Sep 2010 12:02:03 -0700 Subject: [f-nsp] Odd MRP problem Message-ID: See this diagram for reference: http://tinypic.com/r/kb93lj/7 This is pretty simple. I have one vlan in an MRP ring through 4 MLX units. I configure the master, and it works as expected. I then configure the members. The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second. It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire. Here is what my master currently shows: RHPs sent RHPs rcvd TC RBPDUs rcvd 509883 4193162 3684318 As you can see, it has sent about a half a million RHPs but received over 4 million of them! Only one unit is configured as "master". As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan. I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate! Anyone else seen anything like this? It is just plain wacky! George -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Sat Sep 11 15:39:09 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 11 Sep 2010 20:39:09 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: Hi George I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 (close to 8). Is that worth noting? If the ring ID was different on all 4 devices, not converging so sending out both interfaces, that would mean that each device should show 8 times(ish) the figure of what is sending out?? Packet captures might be the way to go, if we can find the protocol spec from foundry.. Heath On 11 September 2010 20:02, George B. wrote: > See this diagram for reference: > > http://tinypic.com/r/kb93lj/7 > > This is pretty simple. I have one vlan in an MRP ring through 4 MLX > units. I configure the master, and it works as expected. I then configure > the members. The problem is when the last "member" (non-master) is > configured in the ring, the master begins to receive thousands of RHP and TC > RBPDUs per second. It doesn't matter which one is the last member > configured but as soon as I enable RHP on that last member, the count of RHP > and TC RBPDUs goes haywire. Here is what my master currently shows: > > RHPs sent RHPs rcvd TC RBPDUs rcvd > 509883 4193162 3684318 > > As you can see, it has sent about a half a million RHPs but received over 4 > million of them! > > Only one unit is configured as "master". As long as I have MRP > unconfigured on one of the members, the ring works as expected. There is no > spanning tree of any sort running on that vlan. I am just in awe of how RHP > packets can seemingly be created in the network somewhere at such an amazing > rate! > > Anyone else seen anything like this? It is just plain wacky! > > George > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sat Sep 11 15:41:35 2010 From: georgeb at gmail.com (George B.) Date: Sat, 11 Sep 2010 12:41:35 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: I have MRP in production without this issue, too. I have never seen anything like it. I can't understand how I can receive more RHP packets than I send. CPU goes up on the line cards, the state of the secondary interface flaps between blocking and forwarding, it just gets into a bad state. As long as I don't have all the members configured and leave at least one not configured with MRP, it works as expected. The one thing I haven't done is to try to make a different unit the master. On Sat, Sep 11, 2010 at 12:31 PM, Peter Olsen wrote: > Strange, > > > > We have 150+rings active, never seen anything like this. > > Except for the very strange numbers, is the ring working ? (is it only a > ?counting? issue) > > > > *Br,* > > *Peter* > > * * > > > > *From:* foundry-nsp-bounces at puck.nether.net [mailto: > foundry-nsp-bounces at puck.nether.net] *On Behalf Of *George B. > *Sent:* 11. september 2010 21:02 > *To:* foundry-nsp > *Subject:* [f-nsp] Odd MRP problem > > > > See this diagram for reference: > > http://tinypic.com/r/kb93lj/7 > > This is pretty simple. I have one vlan in an MRP ring through 4 MLX > units. I configure the master, and it works as expected. I then configure > the members. The problem is when the last "member" (non-master) is > configured in the ring, the master begins to receive thousands of RHP and TC > RBPDUs per second. It doesn't matter which one is the last member > configured but as soon as I enable RHP on that last member, the count of RHP > and TC RBPDUs goes haywire. Here is what my master currently shows: > > RHPs sent RHPs rcvd TC RBPDUs rcvd > 509883 4193162 3684318 > > As you can see, it has sent about a half a million RHPs but received over 4 > million of them! > > Only one unit is configured as "master". As long as I have MRP > unconfigured on one of the members, the ring works as expected. There is no > spanning tree of any sort running on that vlan. I am just in awe of how RHP > packets can seemingly be created in the network somewhere at such an amazing > rate! > > Anyone else seen anything like this? It is just plain wacky! > > George > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sat Sep 11 15:45:56 2010 From: georgeb at gmail.com (George B.) Date: Sat, 11 Sep 2010 12:45:56 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: They are all using the same ring ID (ring 2) and this is extremely simple as the vlan exists only on the units in the ring and the ring ports are the only members of the vlan. That number ratio isn't going to mean anything as I have been running in a stable mode now with one of the units not configured for MRP for well over 24 hours now. The topology keeps flapping if I have all members configured. As long as I leave one unconfigured, it works just fine. The equipment involved has been in service without issues for a long time. We recently added the second metroE and I wanted to run MRP as I have had good results with it everywhere else I have used it. Never seen anything like this before. George On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones wrote: > Hi George > > I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 > (close to 8). Is that worth noting? > If the ring ID was different on all 4 devices, not converging so sending > out both interfaces, that would mean that each device should show 8 > times(ish) the figure of what is sending out?? > > Packet captures might be the way to go, if we can find the protocol spec > from foundry.. > > Heath > > On 11 September 2010 20:02, George B. wrote: > >> See this diagram for reference: >> >> http://tinypic.com/r/kb93lj/7 >> >> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >> units. I configure the master, and it works as expected. I then configure >> the members. The problem is when the last "member" (non-master) is >> configured in the ring, the master begins to receive thousands of RHP and TC >> RBPDUs per second. It doesn't matter which one is the last member >> configured but as soon as I enable RHP on that last member, the count of RHP >> and TC RBPDUs goes haywire. Here is what my master currently shows: >> >> RHPs sent RHPs rcvd TC RBPDUs rcvd >> 509883 4193162 3684318 >> >> As you can see, it has sent about a half a million RHPs but received over >> 4 million of them! >> >> Only one unit is configured as "master". As long as I have MRP >> unconfigured on one of the members, the ring works as expected. There is no >> spanning tree of any sort running on that vlan. I am just in awe of how RHP >> packets can seemingly be created in the network somewhere at such an amazing >> rate! >> >> Anyone else seen anything like this? It is just plain wacky! >> >> George >> >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hj1980 at gmail.com Sat Sep 11 16:01:29 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 11 Sep 2010 21:01:29 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: So for it to be flapping between blocking / forwarding, the unit would have to either be receiving (or thinking its receiving) tcn's? On 11 September 2010 20:45, George B. wrote: > They are all using the same ring ID (ring 2) and this is extremely simple > as the vlan exists only on the units in the ring and the ring ports are the > only members of the vlan. That number ratio isn't going to mean anything as > I have been running in a stable mode now with one of the units not > configured for MRP for well over 24 hours now. The topology keeps flapping > if I have all members configured. As long as I leave one unconfigured, it > works just fine. > > The equipment involved has been in service without issues for a long time. > We recently added the second metroE and I wanted to run MRP as I have had > good results with it everywhere else I have used it. Never seen anything > like this before. > > George > > > > On Sat, Sep 11, 2010 at 12:39 PM, Heath Jones wrote: > >> Hi George >> >> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >> (close to 8). Is that worth noting? >> If the ring ID was different on all 4 devices, not converging so sending >> out both interfaces, that would mean that each device should show 8 >> times(ish) the figure of what is sending out?? >> >> Packet captures might be the way to go, if we can find the protocol spec >> from foundry.. >> >> Heath >> >> On 11 September 2010 20:02, George B. wrote: >> >>> See this diagram for reference: >>> >>> http://tinypic.com/r/kb93lj/7 >>> >>> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >>> units. I configure the master, and it works as expected. I then configure >>> the members. The problem is when the last "member" (non-master) is >>> configured in the ring, the master begins to receive thousands of RHP and TC >>> RBPDUs per second. It doesn't matter which one is the last member >>> configured but as soon as I enable RHP on that last member, the count of RHP >>> and TC RBPDUs goes haywire. Here is what my master currently shows: >>> >>> RHPs sent RHPs rcvd TC RBPDUs rcvd >>> 509883 4193162 3684318 >>> >>> As you can see, it has sent about a half a million RHPs but received over >>> 4 million of them! >>> >>> Only one unit is configured as "master". As long as I have MRP >>> unconfigured on one of the members, the ring works as expected. There is no >>> spanning tree of any sort running on that vlan. I am just in awe of how RHP >>> packets can seemingly be created in the network somewhere at such an amazing >>> rate! >>> >>> Anyone else seen anything like this? It is just plain wacky! >>> >>> George >>> >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> foundry-nsp at puck.nether.net >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Peter.Olsen at GlobalConnect.dk Sat Sep 11 15:31:12 2010 From: Peter.Olsen at GlobalConnect.dk (Peter Olsen) Date: Sat, 11 Sep 2010 21:31:12 +0200 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: Strange, We have 150+rings active, never seen anything like this. Except for the very strange numbers, is the ring working ? (is it only a 'counting' issue) Br, Peter From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of George B. Sent: 11. september 2010 21:02 To: foundry-nsp Subject: [f-nsp] Odd MRP problem See this diagram for reference: http://tinypic.com/r/kb93lj/7 This is pretty simple. I have one vlan in an MRP ring through 4 MLX units. I configure the master, and it works as expected. I then configure the members. The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second. It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire. Here is what my master currently shows: RHPs sent RHPs rcvd TC RBPDUs rcvd 509883 4193162 3684318 As you can see, it has sent about a half a million RHPs but received over 4 million of them! Only one unit is configured as "master". As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan. I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate! Anyone else seen anything like this? It is just plain wacky! George -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan.Pedersen at GlobalConnect.dk Sun Sep 12 03:46:43 2010 From: Jan.Pedersen at GlobalConnect.dk (Jan Pedersen) Date: Sun, 12 Sep 2010 09:46:43 +0200 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: Message-ID: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Hi George, We once had a similar issue, and that was caused by a faulty 4X10G XMR Module. Have you checked that you have valid PBIF, XPP and XGMAC versions on all 10GE modules in the ring? Can you pass normal (non-mrp) traffic across that ring without problems. Do you have a topology group and member-vlans attached to that metro-ring? If yes, double check that the topology group is equally configured on all nodes. You might want to enable byte accounting on the MRP master vlan on all nodes or try the "dm metro-rhp" debug command to get more information from the nodes. Best regards Jan Pedersen Senior Network Specialist D: +45 7730 2932 M: +45 2550 7321 From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Heath Jones Sent: 11. september 2010 21:39 To: George B. Cc: foundry-nsp Subject: Re: [f-nsp] Odd MRP problem Hi George I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 (close to 8). Is that worth noting? If the ring ID was different on all 4 devices, not converging so sending out both interfaces, that would mean that each device should show 8 times(ish) the figure of what is sending out?? Packet captures might be the way to go, if we can find the protocol spec from foundry.. Heath On 11 September 2010 20:02, George B. wrote: See this diagram for reference: http://tinypic.com/r/kb93lj/7 This is pretty simple. I have one vlan in an MRP ring through 4 MLX units. I configure the master, and it works as expected. I then configure the members. The problem is when the last "member" (non-master) is configured in the ring, the master begins to receive thousands of RHP and TC RBPDUs per second. It doesn't matter which one is the last member configured but as soon as I enable RHP on that last member, the count of RHP and TC RBPDUs goes haywire. Here is what my master currently shows: RHPs sent RHPs rcvd TC RBPDUs rcvd 509883 4193162 3684318 As you can see, it has sent about a half a million RHPs but received over 4 million of them! Only one unit is configured as "master". As long as I have MRP unconfigured on one of the members, the ring works as expected. There is no spanning tree of any sort running on that vlan. I am just in awe of how RHP packets can seemingly be created in the network somewhere at such an amazing rate! Anyone else seen anything like this? It is just plain wacky! George _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sun Sep 12 04:10:25 2010 From: georgeb at gmail.com (George B.) Date: Sun, 12 Sep 2010 01:10:25 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: All of those units have been in service for over a year passing traffic without problems. We recently added the second metroE and I wanted to use MRP as I have had good results with it elsewhere. MRP works fine as long as I have at least one unit that is NOT configured for MRP. One thing I noticed today is that two of the units (the bottom two in the diagram) are running 4.0.0 and the top two are running 5.0.0 so my next step is to get them all up to current (though a new release for MLX/XMR is due on or about Wednesday, Sept 15, according to my little birdies so I might delay for a couple of days). The configuration is as simple as I can get it ... one single vlan running MRP, no topology group, only ports in the vlan are the ports running MRP (two ports per unit). Thanks for your response, Jan. George On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < Jan.Pedersen at globalconnect.dk> wrote: > Hi George, > > > > We once had a similar issue, and that was caused by a faulty 4X10G XMR > Module. > > > > Have you checked that you have valid PBIF, XPP and XGMAC versions on all > 10GE modules in the ring? > > > > Can you pass normal (non-mrp) traffic across that ring without problems. Do > you have a topology group and member-vlans attached to that metro-ring? If > yes, double check that the topology group is equally configured on all > nodes. > > > > You might want to enable byte accounting on the MRP master vlan on all > nodes or try the ?dm metro-rhp? debug command to get more information from > the nodes. > > > > > > *Best regards > > **Jan Pedersen > **Senior Network Specialist > D: +45 7730 2932 > M: +45 2550 7321 > > * > > *From:* foundry-nsp-bounces at puck.nether.net [mailto: > foundry-nsp-bounces at puck.nether.net] *On Behalf Of *Heath Jones > *Sent:* 11. september 2010 21:39 > *To:* George B. > *Cc:* foundry-nsp > *Subject:* Re: [f-nsp] Odd MRP problem > > > > Hi George > > > > I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 > (close to 8). Is that worth noting? > > If the ring ID was different on all 4 devices, not converging so sending > out both interfaces, that would mean that each device should show 8 > times(ish) the figure of what is sending out?? > > > > Packet captures might be the way to go, if we can find the protocol spec > from foundry.. > > > > Heath > > On 11 September 2010 20:02, George B. wrote: > > See this diagram for reference: > > http://tinypic.com/r/kb93lj/7 > > This is pretty simple. I have one vlan in an MRP ring through 4 MLX > units. I configure the master, and it works as expected. I then configure > the members. The problem is when the last "member" (non-master) is > configured in the ring, the master begins to receive thousands of RHP and TC > RBPDUs per second. It doesn't matter which one is the last member > configured but as soon as I enable RHP on that last member, the count of RHP > and TC RBPDUs goes haywire. Here is what my master currently shows: > > RHPs sent RHPs rcvd TC RBPDUs rcvd > 509883 4193162 3684318 > > As you can see, it has sent about a half a million RHPs but received over 4 > million of them! > > Only one unit is configured as "master". As long as I have MRP > unconfigured on one of the members, the ring works as expected. There is no > spanning tree of any sort running on that vlan. I am just in awe of how RHP > packets can seemingly be created in the network somewhere at such an amazing > rate! > > Anyone else seen anything like this? It is just plain wacky! > > George > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Sun Sep 12 08:39:30 2010 From: harbor235 at gmail.com (harbor235) Date: Sun, 12 Sep 2010 08:39:30 -0400 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: Is spanning tree disabled on vlan 2? harbor235 On Sun, Sep 12, 2010 at 4:10 AM, George B. wrote: > All of those units have been in service for over a year passing traffic > without problems. We recently added the second metroE and I wanted to use > MRP as I have had good results with it elsewhere. MRP works fine as long as > I have at least one unit that is NOT configured for MRP. One thing I > noticed today is that two of the units (the bottom two in the diagram) are > running 4.0.0 and the top two are running 5.0.0 so my next step is to get > them all up to current (though a new release for MLX/XMR is due on or about > Wednesday, Sept 15, according to my little birdies so I might delay for a > couple of days). > > The configuration is as simple as I can get it ... one single vlan running > MRP, no topology group, only ports in the vlan are the ports running MRP > (two ports per unit). > > Thanks for your response, Jan. > > George > > > > On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < > Jan.Pedersen at globalconnect.dk> wrote: > >> Hi George, >> >> >> >> We once had a similar issue, and that was caused by a faulty 4X10G XMR >> Module. >> >> >> >> Have you checked that you have valid PBIF, XPP and XGMAC versions on all >> 10GE modules in the ring? >> >> >> >> Can you pass normal (non-mrp) traffic across that ring without problems. >> Do you have a topology group and member-vlans attached to that metro-ring? >> If yes, double check that the topology group is equally configured on all >> nodes. >> >> >> >> You might want to enable byte accounting on the MRP master vlan on all >> nodes or try the ?dm metro-rhp? debug command to get more information from >> the nodes. >> >> >> >> >> >> *Best regards >> >> **Jan Pedersen >> **Senior Network Specialist >> D: +45 7730 2932 >> M: +45 2550 7321 >> >> * >> >> *From:* foundry-nsp-bounces at puck.nether.net [mailto: >> foundry-nsp-bounces at puck.nether.net] *On Behalf Of *Heath Jones >> *Sent:* 11. september 2010 21:39 >> *To:* George B. >> *Cc:* foundry-nsp >> *Subject:* Re: [f-nsp] Odd MRP problem >> >> >> >> Hi George >> >> >> >> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >> (close to 8). Is that worth noting? >> >> If the ring ID was different on all 4 devices, not converging so sending >> out both interfaces, that would mean that each device should show 8 >> times(ish) the figure of what is sending out?? >> >> >> >> Packet captures might be the way to go, if we can find the protocol spec >> from foundry.. >> >> >> >> Heath >> >> On 11 September 2010 20:02, George B. wrote: >> >> See this diagram for reference: >> >> http://tinypic.com/r/kb93lj/7 >> >> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >> units. I configure the master, and it works as expected. I then configure >> the members. The problem is when the last "member" (non-master) is >> configured in the ring, the master begins to receive thousands of RHP and TC >> RBPDUs per second. It doesn't matter which one is the last member >> configured but as soon as I enable RHP on that last member, the count of RHP >> and TC RBPDUs goes haywire. Here is what my master currently shows: >> >> RHPs sent RHPs rcvd TC RBPDUs rcvd >> 509883 4193162 3684318 >> >> As you can see, it has sent about a half a million RHPs but received over >> 4 million of them! >> >> Only one unit is configured as "master". As long as I have MRP >> unconfigured on one of the members, the ring works as expected. There is no >> spanning tree of any sort running on that vlan. I am just in awe of how RHP >> packets can seemingly be created in the network somewhere at such an amazing >> rate! >> >> Anyone else seen anything like this? It is just plain wacky! >> >> George >> >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> >> >> > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georgeb at gmail.com Sun Sep 12 15:09:56 2010 From: georgeb at gmail.com (George B.) Date: Sun, 12 Sep 2010 12:09:56 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: Oops, meant to reply all. No spanning tree anywhere on that vlan. In this case it is vlan 111 and metro ring 2 On Sun, Sep 12, 2010 at 5:39 AM, harbor235 wrote: > Is spanning tree disabled on vlan 2? > > harbor235 > > > On Sun, Sep 12, 2010 at 4:10 AM, George B. wrote: > >> All of those units have been in service for over a year passing traffic >> without problems. We recently added the second metroE and I wanted to use >> MRP as I have had good results with it elsewhere. MRP works fine as long as >> I have at least one unit that is NOT configured for MRP. One thing I >> noticed today is that two of the units (the bottom two in the diagram) are >> running 4.0.0 and the top two are running 5.0.0 so my next step is to get >> them all up to current (though a new release for MLX/XMR is due on or about >> Wednesday, Sept 15, according to my little birdies so I might delay for a >> couple of days). >> >> The configuration is as simple as I can get it ... one single vlan running >> MRP, no topology group, only ports in the vlan are the ports running MRP >> (two ports per unit). >> >> Thanks for your response, Jan. >> >> George >> >> >> >> On Sun, Sep 12, 2010 at 12:46 AM, Jan Pedersen < >> Jan.Pedersen at globalconnect.dk> wrote: >> >>> Hi George, >>> >>> >>> >>> We once had a similar issue, and that was caused by a faulty 4X10G XMR >>> Module. >>> >>> >>> >>> Have you checked that you have valid PBIF, XPP and XGMAC versions on all >>> 10GE modules in the ring? >>> >>> >>> >>> Can you pass normal (non-mrp) traffic across that ring without problems. >>> Do you have a topology group and member-vlans attached to that metro-ring? >>> If yes, double check that the topology group is equally configured on all >>> nodes. >>> >>> >>> >>> You might want to enable byte accounting on the MRP master vlan on all >>> nodes or try the ?dm metro-rhp? debug command to get more information from >>> the nodes. >>> >>> >>> >>> >>> >>> *Best regards >>> >>> **Jan Pedersen >>> **Senior Network Specialist >>> D: +45 7730 2932 >>> M: +45 2550 7321 >>> >>> * >>> >>> *From:* foundry-nsp-bounces at puck.nether.net [mailto: >>> foundry-nsp-bounces at puck.nether.net] *On Behalf Of *Heath Jones >>> *Sent:* 11. september 2010 21:39 >>> *To:* George B. >>> *Cc:* foundry-nsp >>> *Subject:* Re: [f-nsp] Odd MRP problem >>> >>> >>> >>> Hi George >>> >>> >>> >>> I'm really quite a newbie when it comes to MRP. RHP rcvd / sent = 8.22 >>> (close to 8). Is that worth noting? >>> >>> If the ring ID was different on all 4 devices, not converging so sending >>> out both interfaces, that would mean that each device should show 8 >>> times(ish) the figure of what is sending out?? >>> >>> >>> >>> Packet captures might be the way to go, if we can find the protocol spec >>> from foundry.. >>> >>> >>> >>> Heath >>> >>> On 11 September 2010 20:02, George B. wrote: >>> >>> See this diagram for reference: >>> >>> http://tinypic.com/r/kb93lj/7 >>> >>> This is pretty simple. I have one vlan in an MRP ring through 4 MLX >>> units. I configure the master, and it works as expected. I then configure >>> the members. The problem is when the last "member" (non-master) is >>> configured in the ring, the master begins to receive thousands of RHP and TC >>> RBPDUs per second. It doesn't matter which one is the last member >>> configured but as soon as I enable RHP on that last member, the count of RHP >>> and TC RBPDUs goes haywire. Here is what my master currently shows: >>> >>> RHPs sent RHPs rcvd TC RBPDUs rcvd >>> 509883 4193162 3684318 >>> >>> As you can see, it has sent about a half a million RHPs but received over >>> 4 million of them! >>> >>> Only one unit is configured as "master". As long as I have MRP >>> unconfigured on one of the members, the ring works as expected. There is no >>> spanning tree of any sort running on that vlan. I am just in awe of how RHP >>> packets can seemingly be created in the network somewhere at such an amazing >>> rate! >>> >>> Anyone else seen anything like this? It is just plain wacky! >>> >>> George >>> >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> foundry-nsp at puck.nether.net >>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>> >>> >>> >> >> >> _______________________________________________ >> foundry-nsp mailing list >> foundry-nsp at puck.nether.net >> http://puck.nether.net/mailman/listinfo/foundry-nsp >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at linx.net Mon Sep 13 06:23:52 2010 From: mike at linx.net (Mike Hughes) Date: Mon, 13 Sep 2010 11:23:52 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> Message-ID: <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> --On 12 September 2010 12:09 -0700 "George B." wrote: > Oops, meant to reply all.? No spanning tree anywhere on that vlan.? In > this case it is vlan 111 and metro ring 2 Is there any link-aggregation present on this ring? It could be something like source-port suppression failing on a LAG group. Mike -- Mike Hughes Chief Technical Officer London Internet Exchange Ltd. mike at linx.net http://www.linx.net/ Registered in England 3137929 at Trinity Court, Peterborough, PE1 1DA From tdonahue at vonsystems.com Mon Sep 13 18:07:35 2010 From: tdonahue at vonsystems.com (tdonahue at vonsystems.com) Date: Mon, 13 Sep 2010 18:07:35 -0400 (EDT) Subject: [f-nsp] BigIron RX Management Interface In-Reply-To: <14801116.901284415060049.JavaMail.tdonahue@midgard> Message-ID: <9324361.921284415649240.JavaMail.tdonahue@midgard> Hi all, Sorry for such a basic question, but I can't seem to find the answer to this question from Google or in the Configuration Guide. We have the management interface on our BigIron RX-4 connected to an internal network and we are trying to figure out how to add a default route for that interface. Can anyone point me to the documentation or send me a quick sample for setting up the routes for the management interface? Thank you, Tim From boards188 at gmail.com Mon Sep 13 21:20:18 2010 From: boards188 at gmail.com (Jason Pope) Date: Mon, 13 Sep 2010 20:20:18 -0500 Subject: [f-nsp] BigIron RX Management Interface In-Reply-To: <9324361.921284415649240.JavaMail.tdonahue@midgard> References: <14801116.901284415060049.JavaMail.tdonahue@midgard> <9324361.921284415649240.JavaMail.tdonahue@midgard> Message-ID: I believe it would just be: ip default-network [A.B.C.D or A.B.C.D/L] Jason On Mon, Sep 13, 2010 at 5:07 PM, wrote: > Hi all, > > Sorry for such a basic question, but I can't seem to find the answer to > this question from Google or in the Configuration Guide. > > We have the management interface on our BigIron RX-4 connected to an > internal network and we are trying to figure out how to add a default route > for that interface. Can anyone point me to the documentation or send me a > quick sample for setting up the routes for the management interface? > > Thank you, > > Tim > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hidden at xmission.com Mon Sep 13 22:07:54 2010 From: hidden at xmission.com (Jared Valentine) Date: Mon, 13 Sep 2010 20:07:54 -0600 Subject: [f-nsp] BigIron RX Management Interface In-Reply-To: References: <14801116.901284415060049.JavaMail.tdonahue@midgard> <9324361.921284415649240.JavaMail.tdonahue@midgard> Message-ID: <0E888D03-1404-4BAA-83F2-DB87B1C39E18@xmission.com> You actually add routes for the management module exactly like you would for an interface module. It goes in the global routing table: ip route x.x.x.x/x y.y.y.y Because y.y.y.y is in the same network as your management module, it gets installed as a management route and not a line card route. The box will keep line card and mgmt module routes separate. The gotcha here is that you can't have "two default routes". So as long as your RX doesn't have a default route already, and you don't need it to, then specifying the management module's default route would be: ip route 0.0.0.0/0 y.y.y.y However, if that's not acceptable then you have some other choices: Use a static route (non-default) that points to y.y.y.y as next hop. You would have to add a static to each of the networks you want to manage from The other choice is to just use in-band management and not use the mgmt port. You could also use a bastion host as a hop-off point that lives in the mgmt module subnet. That way you don't need to worry about routes. The bastion host has its own default gateway. Good luck, Jared On Sep 13, 2010, at 7:20 PM, Jason Pope wrote: > I believe it would just be: > > ip default-network [A.B.C.D or A.B.C.D/L] > > Jason > > > > On Mon, Sep 13, 2010 at 5:07 PM, wrote: > Hi all, > > Sorry for such a basic question, but I can't seem to find the answer to this question from Google or in the Configuration Guide. > > We have the management interface on our BigIron RX-4 connected to an internal network and we are trying to figure out how to add a default route for that interface. Can anyone point me to the documentation or send me a quick sample for setting up the routes for the management interface? > > Thank you, > > Tim > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Wed Sep 15 13:31:18 2010 From: harbor235 at gmail.com (harbor235) Date: Wed, 15 Sep 2010 13:31:18 -0400 Subject: [f-nsp] multicast and GRE Message-ID: Does anyone know if Brocade/Foundry supports multicast over GRE tunnels? My setup is simple, L2 access switch connected to distribution switch (L3), conencted to a Core switch (L3). If I hang the source off the Core, enable PIM on the connencting interfaces all works well. If I add a GRE tunnel that terminates upstream of the core switch to remote router, add the appropriate PIM sparse mode commands on the tunnel interfaces and locate the source on the same remote router, all is broken. If I follow the Cisco docs for enabling multicast over GRE, add mroutes for the RP and the source pointing to the tunnel, I still get no joy. I can see the group address and the RP in the PIM cache as well IGMP. I have performed packet traces and can see IGMP V2 requests, creates, etc. Then pretty much 23 seconds later I see the XP receiver send a IGMP leave, thoughts? Are there any good docs for Foundry multicast over GRE? Troubleshooting? help from someone who has implemented multicast on Foundry? harbor235 ;} -------------- next part -------------- An HTML attachment was scrubbed... URL: From harbor235 at gmail.com Wed Sep 22 08:07:25 2010 From: harbor235 at gmail.com (harbor235) Date: Wed, 22 Sep 2010 08:07:25 -0400 Subject: [f-nsp] ACLs Message-ID: I was reading through the Netiron user guide and came across the following; You cannot enable any of the following features on the interface if an ACL is already applied to that interface: ? ACL-based rate limiting ? Policy-based routing (PBR) ? VLAN ID Translation or Inner VLAN ID translation feature IP inbound and L2 inbound ACLs are mutually exclusive on the NetIron MLX and NetIron XMR, but both may be bound to the same port on the NetIron CES and NetIron CER. IP outbound and L2 outbound ACLs are mutually exclusive on all platforms. This is very limiting, how is everyone getting around this limitation? harbor235 ;} -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarratt at socket.net Thu Sep 23 18:15:59 2010 From: abarratt at socket.net (Adam E Barratt (Sales Engineering)) Date: Thu, 23 Sep 2010 17:15:59 -0500 Subject: [f-nsp] Gray Market Foundry In-Reply-To: References: Message-ID: <4C9BD19F.7020600@socket.net> I was wondering if anyone has any experience with Gray Market Brocade equipment? (specifically on the MLX line?) -Adam From abarratt at socket.net Thu Sep 23 19:30:05 2010 From: abarratt at socket.net (Adam E Barratt (Network Operations)) Date: Thu, 23 Sep 2010 18:30:05 -0500 Subject: [f-nsp] Gray Market Foundry In-Reply-To: <071201cb5b74$64c1d670$2e458350$@net> References: <4C9BD19F.7020600@socket.net> <071201cb5b74$64c1d670$2e458350$@net> Message-ID: <41A28584-86C5-4DA7-93FB-5F7314DCF287@socket.net> Specifically on the support side. How does brocade deal with software upgrades on hardware not sold through traditional channels / used equipment etc? Is it worth it or does it cause headaches? Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for > over 7 years to end-users, dealers and brokers, worldwide. (Gray > market is a > bit of a misnomer in my opinion.) I have sold lots of MLX, XMR, RX, > SuperX > and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt > (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for > over 7 years to end-users, dealers and brokers, worldwide. (Gray > market is a > bit of a misnomer in my opinion.) I have sold lots of MLX, XMR, RX, > SuperX > and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt > (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > > From brian at terabitsystems.net Thu Sep 23 19:09:36 2010 From: brian at terabitsystems.net (Brian Stadtmiller) Date: Thu, 23 Sep 2010 16:09:36 -0700 Subject: [f-nsp] Gray Market Foundry In-Reply-To: <4C9BD19F.7020600@socket.net> References: <4C9BD19F.7020600@socket.net> Message-ID: <071201cb5b74$64c1d670$2e458350$@net> I have sold new, used, and refurbished Foundry (now Brocade IP) hardware for over 7 years to end-users, dealers and brokers, worldwide. (Gray market is a bit of a misnomer in my opinion.) I have sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized companies. (Literally millions of dollars worth of Foundry/Brocade hardware.) Anyhow, Do you have specific concerns or questions you would like addressed? regards, Brian Stadtmiller Terabit Systems 2565 3rd Street #334 San Francisco, CA 94107 415-230-4353 main 415-652-2888 cell AIM: bstadtmiller9609 -----Original Message----- From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E Barratt (Sales Engineering) Sent: Thursday, September 23, 2010 3:16 PM To: foundry-nsp at puck.nether.net Subject: [f-nsp] Gray Market Foundry I was wondering if anyone has any experience with Gray Market Brocade equipment? (specifically on the MLX line?) -Adam _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: 09/22/10 23:34:00 From mdixon at nkc.org Fri Sep 24 10:17:18 2010 From: mdixon at nkc.org (Michienne Dixon) Date: Fri, 24 Sep 2010 09:17:18 -0500 Subject: [f-nsp] Gray Market Foundry Message-ID: <6316CD198EC8BC44A9D200F375869F1E012FB331@nkc-mailsrv.nkc.org> Prior to Foundry becoming Brocade, they had a recertification process for their equipment that was not too painful. I have not purchased any used Foundry equipment since that time though. It used to be that if you were purchasing from a reseller that has a maintenance agreement with Foundry then they could upgrade the software for you. I would ask your reseller. We have maintenance on our MLX routers and I have a couple of used Big Irons and 4802s. Even though I do not have maintenance/support of the used equipment I still have access to the software and config guides. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -----Original Message----- From: foundry-nsp-bounces at puck.nether.net [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E Barratt (Network Operations) Sent: Thursday, September 23, 2010 6:30 PM To: Brian Stadtmiller Cc: Subject: Re: [f-nsp] Gray Market Foundry Specifically on the support side. How does brocade deal with software upgrades on hardware not sold through traditional channels / used equipment etc? Is it worth it or does it cause headaches? Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for over 7 years to end-users, dealers and brokers, > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > Adam On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" wrote: > I have sold new, used, and refurbished Foundry (now Brocade IP) > hardware for over 7 years to end-users, dealers and brokers, > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > companies. (Literally millions of dollars worth of Foundry/Brocade > hardware.) > > Anyhow, Do you have specific concerns or questions you would like > addressed? > > regards, > > > Brian Stadtmiller > Terabit Systems > 2565 3rd Street #334 > San Francisco, CA 94107 > 415-230-4353 main > 415-652-2888 cell > AIM: bstadtmiller9609 > > > > > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > Barratt (Sales Engineering) > Sent: Thursday, September 23, 2010 3:16 PM > To: foundry-nsp at puck.nether.net > Subject: [f-nsp] Gray Market Foundry > > I was wondering if anyone has any experience with Gray Market Brocade > equipment? (specifically on the MLX line?) > > -Adam > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > 09/22/10 > 23:34:00 > > _______________________________________________ foundry-nsp mailing list foundry-nsp at puck.nether.net http://puck.nether.net/mailman/listinfo/foundry-nsp From rsm at fast-serv.com Fri Sep 24 11:52:27 2010 From: rsm at fast-serv.com (Randy McAnally) Date: Fri, 24 Sep 2010 11:52:27 -0400 Subject: [f-nsp] Gray Market Foundry In-Reply-To: <6316CD198EC8BC44A9D200F375869F1E012FB331@nkc-mailsrv.nkc.org> References: <6316CD198EC8BC44A9D200F375869F1E012FB331@nkc-mailsrv.nkc.org> Message-ID: <20100924155038.M55511@fast-serv.com> I'm not interested in direct support with grey market equipment (obviously it's use-at-your-own-risk type of thing). The vendor should always sell it to you with the latest software and provide support as needed (within the warranty period of course) -- and this has always been the case for us. -- Randy M. www.FastServ.com ---------- Original Message ----------- From: "Michienne Dixon" To: N/A Cc: Sent: Fri, 24 Sep 2010 09:17:18 -0500 Subject: Re: [f-nsp] Gray Market Foundry > Prior to Foundry becoming Brocade, they had a recertification process > for their equipment that was not too painful. I have not purchased any > used Foundry equipment since that time though. It used to be that if > you were purchasing from a reseller that has a maintenance agreement > with Foundry then they could upgrade the software for you. I would > ask your reseller. > > We have maintenance on our MLX routers and I have a couple of used > Big Irons and 4802s. Even though I do not have maintenance/support > of the used equipment I still have access to the software and config > guides. > > - > Michienne Dixon > Network Administrator > liNKCity > 312 Armour Rd. > North Kansas City, MO 64116 > www.linkcity.org > (816) 412-7990 > > -----Original Message----- > From: foundry-nsp-bounces at puck.nether.net > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E Barratt > (Network Operations) > Sent: Thursday, September 23, 2010 6:30 PM > To: Brian Stadtmiller > Cc: > Subject: Re: [f-nsp] Gray Market Foundry > > Specifically on the support side. How does brocade deal with > software upgrades on hardware not sold through traditional channels / > used equipment etc? > > Is it worth it or does it cause headaches? > > Adam > > On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" > wrote: > > > I have sold new, used, and refurbished Foundry (now Brocade IP) > > hardware for over 7 years to end-users, dealers and brokers, > > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > > > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > > > companies. (Literally millions of dollars worth of Foundry/Brocade > > hardware.) > > > > Anyhow, Do you have specific concerns or questions you would like > > addressed? > > > > regards, > > > > > > Brian Stadtmiller > > Terabit Systems > > 2565 3rd Street #334 > > San Francisco, CA 94107 > > 415-230-4353 main > > 415-652-2888 cell > > AIM: bstadtmiller9609 > > > > > > > > > > > > -----Original Message----- > > From: foundry-nsp-bounces at puck.nether.net > > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > > Barratt (Sales Engineering) > > Sent: Thursday, September 23, 2010 3:16 PM > > To: foundry-nsp at puck.nether.net > > Subject: [f-nsp] Gray Market Foundry > > > > I was wondering if anyone has any experience with Gray Market Brocade > > > equipment? (specifically on the MLX line?) > > > > -Adam > > _______________________________________________ > > foundry-nsp mailing list > > foundry-nsp at puck.nether.net > > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > > > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > > 09/22/10 > > 23:34:00 > > > > Adam > > On Sep 23, 2010, at 6:09 PM, "Brian Stadtmiller" > wrote: > > > I have sold new, used, and refurbished Foundry (now Brocade IP) > > hardware for over 7 years to end-users, dealers and brokers, > > worldwide. (Gray market is a bit of a misnomer in my opinion.) I have > > > sold lots of MLX, XMR, RX, SuperX and FESX into small and medium sized > > > companies. (Literally millions of dollars worth of Foundry/Brocade > > hardware.) > > > > Anyhow, Do you have specific concerns or questions you would like > > addressed? > > > > regards, > > > > > > Brian Stadtmiller > > Terabit Systems > > 2565 3rd Street #334 > > San Francisco, CA 94107 > > 415-230-4353 main > > 415-652-2888 cell > > AIM: bstadtmiller9609 > > > > > > > > > > > > -----Original Message----- > > From: foundry-nsp-bounces at puck.nether.net > > [mailto:foundry-nsp-bounces at puck.nether.net] On Behalf Of Adam E > > Barratt (Sales Engineering) > > Sent: Thursday, September 23, 2010 3:16 PM > > To: foundry-nsp at puck.nether.net > > Subject: [f-nsp] Gray Market Foundry > > > > I was wondering if anyone has any experience with Gray Market Brocade > > > equipment? (specifically on the MLX line?) > > > > -Adam > > _______________________________________________ > > foundry-nsp mailing list > > foundry-nsp at puck.nether.net > > http://puck.nether.net/mailman/listinfo/foundry-nsp > > > > > > No virus found in this incoming message. > > Checked by AVG - www.avg.com > > Version: 9.0.856 / Virus Database: 271.1.1/3124 - Release Date: > > 09/22/10 > > 23:34:00 > > > > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp > > _______________________________________________ > foundry-nsp mailing list > foundry-nsp at puck.nether.net > http://puck.nether.net/mailman/listinfo/foundry-nsp ------- End of Original Message ------- From georgeb at gmail.com Mon Sep 27 04:26:31 2010 From: georgeb at gmail.com (George B.) Date: Mon, 27 Sep 2010 01:26:31 -0700 Subject: [f-nsp] Odd MRP problem In-Reply-To: <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> Message-ID: On Mon, Sep 13, 2010 at 3:23 AM, Mike Hughes wrote: > --On 12 September 2010 12:09 -0700 "George B." wrote: > > > Oops, meant to reply all. No spanning tree anywhere on that vlan. In > > this case it is vlan 111 and metro ring 2 > > Is there any link-aggregation present on this ring? > > It could be something like source-port suppression failing on a LAG group. > > Mike > > Yes, there is a LAG in the ring. There are two 1G ports aggregated between two routers at one site. George. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at smashing.net Mon Sep 27 05:04:22 2010 From: mike at smashing.net (Mike Hughes) Date: Mon, 27 Sep 2010 10:04:22 +0100 Subject: [f-nsp] Odd MRP problem In-Reply-To: References: <190209C36704414CB78B50B8D3AC6112420619@gc-exchange01.globalconnect.intra> <31DEA0F29D96A5D95A76CF7B@MIKE-LAPTOP.dyn.pbo.linx.net> Message-ID: <423C206E9753E0D862FE257E@two-one-four.se18.smashing.net> --On 27 September 2010 01:26:31 -0700 "George B." wrote: > Yes, there is a LAG in the ring.? There are two 1G ports aggregated > between two routers at one site. Okay, so what this could be is either: a) Failure of source-port suppression for the LAG - so usually, when a frame arrives to a broadcast, multicast, or unknown unicast address, it is forwarded out of all ports in that vlan other than the one it arrived on. This behaviour is obviously modified for a LAG, so that other ports in the same LAG as the incoming port do not get a copy of the frame. However, I have seen this behaviour fail on some Brocade equipment (Mostly Jetcore/MG8, I think once on RX), which causes the flooded frames to "trombone" along the LAG. This would create lots of extra copies of the RHPs. It's likely to break control protocols using broadcast/multicast DAs, and cause a lot of what looks like station movement, so look for high CPU, and MAC addresses flipping between source ports. b) The other option is a bad FID being programmed for the destination MAC address for the MRP RHP, which is causing the RHPs to be forwarded out of the wrong port on one of the switches. Just some ideas to investigate. Mike