September 2016 - mice-discuss

Call for Agenda

by Shaun Carlson

All, Please send me any agenda items you'd like added for next week's meeting. I'm working on assembling the agenda. Thanks! s *Shaun Carlson*Director of Information Technology | Arvig ph: (218) 346-8673 | em: shaun.carlson(a)arvig.com

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

I am in favor, THANKS GUYS!!! From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jason Hanke Sent: Tuesday, September 20, 2016 3:41 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants Compudyne has offered to donate an EX4200 with a 2x10G uplink card to MICE to help the cause. On Tue, Sep 20, 2016 at 3:31 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I am in favor of a regular layer 2 uplink. I think the main reason I feel this way is it is industry standard, and then the switch has its own forwarding table. We have seen issues in the past where if the link on a high volume port goes down, the MAC gets removed from the forwarding table, and then all of that traffic gets flooded to all other ports until BGP times out. This seems to be especially problematic when it hits the 1G ports. My vision of a future upgrade would be something along the lines of a 5200, or equiv from another manufacturer that has all of the other switches uplinked to it. Then we would have separate forwarding tables, a place to connect remote switches, as well as something that has some 40G, and 100G capabilities. All of the uplinks would then be easy to monitor/graph without excessive load on the switch. Copper SFP+/QSFP+ cables can be used between switches and they are affordable/easy to come by. Jeremy -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, September 20, 2016 3:15 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants On Tue, Sep 20, 2016 at 02:23:00PM -0500, Jeremy Lumby wrote: > That would make sense, then we are just down to how traffic can leave the 4200 without going across a vcp Most likely we'd have to kick off (umm. move) the three members that are fiber 1G connections in the expansion slot on the 4200, get a 10G card, optics for both sides, etc. Then decide if we are going to run virtual chassis protocol, or just layer-2 uplink into the two other switches. Or we move the 19 active 1G copper members + 3 1G fiber members off the 4200 altogether and eat up ports on the 4550 with 19 copper SFPs. Then we wouldn't have to do "Mixed-mode Virtual-Chassis" then either. > Although- it looks like so far all the paths with loss seem to have "vcp-1" in them? As I've stated multiple times, I think since VCP is active/passive, there is only one active ring around the the VC through VCP-1 now, and I would expect to see vcp-1 in all paths through the EX4200. We can swap active and passive with the command I posted previously. That way we can troubleshoot if there is a port/cable issue, or if it is an issue with the device itself. Or it could be a defect in this coderev (although I doubt it). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jason Hanke

Compudyne has offered to donate an EX4200 with a 2x10G uplink card to MICE to help the cause. On Tue, Sep 20, 2016 at 3:31 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I am in favor of a regular layer 2 uplink. I think the main reason I feel > this way is it is industry standard, and then the switch has its own > forwarding table. We have seen issues in the past where if the link on a > high volume port goes down, the MAC gets removed from the forwarding table, > and then all of that traffic gets flooded to all other ports until BGP > times out. This seems to be especially problematic when it hits the 1G > ports. > > My vision of a future upgrade would be something along the lines of a > 5200, or equiv from another manufacturer that has all of the other switches > uplinked to it. Then we would have separate forwarding tables, a place to > connect remote switches, as well as something that has some 40G, and 100G > capabilities. All of the uplinks would then be easy to monitor/graph > without excessive load on the switch. Copper SFP+/QSFP+ cables can be used > between switches and they are affordable/easy to come by. > > Jeremy > > -----Original Message----- > From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of > Doug McIntyre > Sent: Tuesday, September 20, 2016 3:15 PM > To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET > Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G > Participants > > On Tue, Sep 20, 2016 at 02:23:00PM -0500, Jeremy Lumby wrote: > > That would make sense, then we are just down to how traffic can leave > the 4200 without going across a vcp > > Most likely we'd have to kick off (umm. move) the three members that > are fiber 1G connections in the expansion slot on the 4200, get a 10G > card, optics for both sides, etc. Then decide if we are going to run > virtual chassis protocol, or just layer-2 uplink into the two other > switches. > > Or we move the 19 active 1G copper members + 3 1G fiber members off the > 4200 > altogether and eat up ports on the 4550 with 19 copper SFPs. Then we > wouldn't > have to do "Mixed-mode Virtual-Chassis" then either. > > > Although- it looks like so far all the paths with loss seem to have > "vcp-1" in them? > > As I've stated multiple times, I think since VCP is active/passive, > there is only one active ring around the the VC through VCP-1 now, > and I would expect to see vcp-1 in all paths through the EX4200. > > We can swap active and passive with the command I posted previously. > That way we can troubleshoot if there is a port/cable issue, or if it is > an issue with the device itself. > > Or it could be a defect in this coderev (although I doubt it). > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

I am in favor of a regular layer 2 uplink. I think the main reason I feel this way is it is industry standard, and then the switch has its own forwarding table. We have seen issues in the past where if the link on a high volume port goes down, the MAC gets removed from the forwarding table, and then all of that traffic gets flooded to all other ports until BGP times out. This seems to be especially problematic when it hits the 1G ports. My vision of a future upgrade would be something along the lines of a 5200, or equiv from another manufacturer that has all of the other switches uplinked to it. Then we would have separate forwarding tables, a place to connect remote switches, as well as something that has some 40G, and 100G capabilities. All of the uplinks would then be easy to monitor/graph without excessive load on the switch. Copper SFP+/QSFP+ cables can be used between switches and they are affordable/easy to come by. Jeremy -----Original Message----- From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Doug McIntyre Sent: Tuesday, September 20, 2016 3:15 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants On Tue, Sep 20, 2016 at 02:23:00PM -0500, Jeremy Lumby wrote: > That would make sense, then we are just down to how traffic can leave the 4200 without going across a vcp Most likely we'd have to kick off (umm. move) the three members that are fiber 1G connections in the expansion slot on the 4200, get a 10G card, optics for both sides, etc. Then decide if we are going to run virtual chassis protocol, or just layer-2 uplink into the two other switches. Or we move the 19 active 1G copper members + 3 1G fiber members off the 4200 altogether and eat up ports on the 4550 with 19 copper SFPs. Then we wouldn't have to do "Mixed-mode Virtual-Chassis" then either. > Although- it looks like so far all the paths with loss seem to have "vcp-1" in them? As I've stated multiple times, I think since VCP is active/passive, there is only one active ring around the the VC through VCP-1 now, and I would expect to see vcp-1 in all paths through the EX4200. We can swap active and passive with the command I posted previously. That way we can troubleshoot if there is a port/cable issue, or if it is an issue with the device itself. Or it could be a defect in this coderev (although I doubt it). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jason Hanke

I'd suggest that we pick up an additional EX4200 and uplink it at layer2 to the main stack at 2x10G. Then move all of the 1G copper links to the new switch. The current switch could then be a spare, VCed into a 4200 only cluster, or uplinked from another suite. If my math is correct, it will free up some VCP bandwidth and also eliminate the mixed mode configuration. On Tue, Sep 20, 2016 at 3:15 PM, Doug McIntyre <merlyn(a)iphouse.net> wrote: > On Tue, Sep 20, 2016 at 02:23:00PM -0500, Jeremy Lumby wrote: > > That would make sense, then we are just down to how traffic can leave > the 4200 without going across a vcp > > Most likely we'd have to kick off (umm. move) the three members that > are fiber 1G connections in the expansion slot on the 4200, get a 10G > card, optics for both sides, etc. Then decide if we are going to run > virtual chassis protocol, or just layer-2 uplink into the two other > switches. > > Or we move the 19 active 1G copper members + 3 1G fiber members off the > 4200 > altogether and eat up ports on the 4550 with 19 copper SFPs. Then we > wouldn't > have to do "Mixed-mode Virtual-Chassis" then either. > > > Although- it looks like so far all the paths with loss seem to have > "vcp-1" in them? > > As I've stated multiple times, I think since VCP is active/passive, > there is only one active ring around the the VC through VCP-1 now, > and I would expect to see vcp-1 in all paths through the EX4200. > > We can swap active and passive with the command I posted previously. > That way we can troubleshoot if there is a port/cable issue, or if it is > an issue with the device itself. > > Or it could be a defect in this coderev (although I doubt it). > > > -- > Doug McIntyre <merlyn(a)iphouse.net> > ~.~ ipHouse ~.~ > Network Engineer/Provisioning/Jack of all Trades > -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Doug McIntyre

On Tue, Sep 20, 2016 at 02:23:00PM -0500, Jeremy Lumby wrote: > That would make sense, then we are just down to how traffic can leave the 4200 without going across a vcp Most likely we'd have to kick off (umm. move) the three members that are fiber 1G connections in the expansion slot on the 4200, get a 10G card, optics for both sides, etc. Then decide if we are going to run virtual chassis protocol, or just layer-2 uplink into the two other switches. Or we move the 19 active 1G copper members + 3 1G fiber members off the 4200 altogether and eat up ports on the 4550 with 19 copper SFPs. Then we wouldn't have to do "Mixed-mode Virtual-Chassis" then either. > Although- it looks like so far all the paths with loss seem to have "vcp-1" in them? As I've stated multiple times, I think since VCP is active/passive, there is only one active ring around the the VC through VCP-1 now, and I would expect to see vcp-1 in all paths through the EX4200. We can swap active and passive with the command I posted previously. That way we can troubleshoot if there is a port/cable issue, or if it is an issue with the device itself. Or it could be a defect in this coderev (although I doubt it). -- Doug McIntyre <merlyn(a)iphouse.net> ~.~ ipHouse ~.~ Network Engineer/Provisioning/Jack of all Trades

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

That would make sense, then we are just down to how traffic can leave the 4200 without going across a vcp From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Jason Hanke Sent: Tuesday, September 20, 2016 2:11 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants I think the internal port is the opposite pfe in the same chassis. IIRC EX4200 is two pfe in the same box, EX3200 is one pfe On Tue, Sep 20, 2016 at 1:58 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: I agree, I am confused to what the second two mean as well. I was surprised to see internal 1/24, as well as no intermediate interface in the lossless ones. I expected to see all vcp-1 or vcp-0 in the middle From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Tuesday, September 20, 2016 1:51 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants Yeah, we should set aside the ae5 test data for the moment...because I agree it's confusing when it's split across 2 switches. I'd have to rely on someone who speaks Juniper as to what the various paths mean.... "vcp-1" vs "internal-1/24" vs nothing?... Although- it looks like so far all the paths with loss seem to have "vcp-1" in them? ~Matthew On Tue, Sep 20, 2016 at 1:28 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: Matthew, The switch throws out an error if I set the destination port as an agg port. However I did all of their member ports individually if that helps you. Personally I think AE bundles on different switches should probably be ignored as data points to keep the troubleshooting straightforward. jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-2/0/11 vc-path from ge-1/0/15 to xe-2/0/11 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 xe-2/0/11 {master:1} jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-0/0/35 vc-path from ge-1/0/15 to xe-0/0/35 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 1 3 internal-1/24 2 0 1 xe-0/0/35 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/3 vc-path from ge-1/0/15 to xe-0/0/3 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 vcp-1 2 0 0 xe-0/0/3 {master:1} jlumby@MICE-SW1> ...e-interface ge-1/0/15 destination-interface xe-0/0/13 vc-path from ge-1/0/15 to xe-0/0/13 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 vcp-1 2 0 0 xe-0/0/13 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/29 vc-path from ge-1/0/15 to xe-0/0/29 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 1 3 internal-1/24 2 0 1 xe-0/0/29 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/38 vc-path from ge-1/0/15 to xe-0/0/38 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 1 3 internal-1/24 2 0 1 xe-0/0/38 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-2/0/15 vc-path from ge-1/0/15 to xe-2/0/15 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 xe-2/0/15 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jason Hanke

I think the internal port is the opposite pfe in the same chassis. IIRC EX4200 is two pfe in the same box, EX3200 is one pfe On Tue, Sep 20, 2016 at 1:58 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > I agree, I am confused to what the second two mean as well. I was > surprised to see internal 1/24, as well as no intermediate interface in the > lossless ones. I expected to see all vcp-1 or vcp-0 in the middle > > > > *From:* MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] *On Behalf > Of *Matthew Beckwell > *Sent:* Tuesday, September 20, 2016 1:51 PM > *To:* MICE-DISCUSS(a)LISTS.IPHOUSE.NET > *Subject:* Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G > Participants > > > > Yeah, we should set aside the ae5 test data for the moment...because I > agree it's confusing when it's split across 2 switches. > > > > I'd have to rely on someone who speaks Juniper as to what the various > paths mean.... > > "vcp-1" vs "internal-1/24" vs nothing?... > > > > Although- it looks like so far all the paths with loss seem to have > "vcp-1" in them? > > ~Matthew > > > > > > On Tue, Sep 20, 2016 at 1:28 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > > Matthew, > > > > The switch throws out an error if I set the destination > port as an agg port. However I did all of their member ports individually > if that helps you. Personally I think AE bundles on different switches > should probably be ignored as data points to keep the troubleshooting > straightforward. > > > > jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-2/0/11 > > vc-path from ge-1/0/15 to xe-2/0/11 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 xe-2/0/11 > > > > {master:1} > > jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-0/0/35 > > vc-path from ge-1/0/15 to xe-0/0/35 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 1 3 internal-1/24 > > 2 0 1 xe-0/0/35 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/3 > > vc-path from ge-1/0/15 to xe-0/0/3 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 vcp-1 > > 2 0 0 xe-0/0/3 > > > > {master:1} > > jlumby@MICE-SW1> ...e-interface ge-1/0/15 destination-interface xe-0/0/13 > > vc-path from ge-1/0/15 to xe-0/0/13 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 vcp-1 > > 2 0 0 xe-0/0/13 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/29 > > vc-path from ge-1/0/15 to xe-0/0/29 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 1 3 internal-1/24 > > 2 0 1 xe-0/0/29 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/38 > > vc-path from ge-1/0/15 to xe-0/0/38 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 1 3 internal-1/24 > > 2 0 1 xe-0/0/38 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-2/0/15 > > vc-path from ge-1/0/15 to xe-2/0/15 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 xe-2/0/15 > > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > > ------------------------------ > > To unsubscribe from the MICE-DISCUSS list, click the following link: > http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1 > -- Jay Hanke CTO Neutral Path Communications 3 Civic Center Plaza, Suite 204 Mankato, MN 56001 (507) 327-2398 mobile jayhanke(a)neutralpath.net www.neutralpath.net

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Jeremy Lumby

I agree, I am confused to what the second two mean as well. I was surprised to see internal 1/24, as well as no intermediate interface in the lossless ones. I expected to see all vcp-1 or vcp-0 in the middle From: MICE Discuss [mailto:MICE-DISCUSS@LISTS.IPHOUSE.NET] On Behalf Of Matthew Beckwell Sent: Tuesday, September 20, 2016 1:51 PM To: MICE-DISCUSS(a)LISTS.IPHOUSE.NET Subject: Re: [MICE-DISCUSS] EX4200 (1G Switch) Packet Loss -> 10G Participants Yeah, we should set aside the ae5 test data for the moment...because I agree it's confusing when it's split across 2 switches. I'd have to rely on someone who speaks Juniper as to what the various paths mean.... "vcp-1" vs "internal-1/24" vs nothing?... Although- it looks like so far all the paths with loss seem to have "vcp-1" in them? ~Matthew On Tue, Sep 20, 2016 at 1:28 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: Matthew, The switch throws out an error if I set the destination port as an agg port. However I did all of their member ports individually if that helps you. Personally I think AE bundles on different switches should probably be ignored as data points to keep the troubleshooting straightforward. jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-2/0/11 vc-path from ge-1/0/15 to xe-2/0/11 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 xe-2/0/11 {master:1} jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-0/0/35 vc-path from ge-1/0/15 to xe-0/0/35 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 1 3 internal-1/24 2 0 1 xe-0/0/35 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/3 vc-path from ge-1/0/15 to xe-0/0/3 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 vcp-1 2 0 0 xe-0/0/3 {master:1} jlumby@MICE-SW1> ...e-interface ge-1/0/15 destination-interface xe-0/0/13 vc-path from ge-1/0/15 to xe-0/0/13 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 vcp-1 2 0 0 xe-0/0/13 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/29 vc-path from ge-1/0/15 to xe-0/0/29 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 1 3 internal-1/24 2 0 1 xe-0/0/29 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/38 vc-path from ge-1/0/15 to xe-0/0/38 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 1 3 internal-1/24 2 0 1 xe-0/0/38 {master:1} jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-2/0/15 vc-path from ge-1/0/15 to xe-2/0/15 Hop Member PFE-Device Interface 0 1 4 ge-1/0/15 1 2 6 xe-2/0/15 To unsubscribe from the MICE-DISCUSS list, click the following link: http://lists.iphouse.net/cgi-bin/wa?SUBED1=MICE-DISCUSS&A=1

Sept. 20, 2016

Re: EX4200 (1G Switch) Packet Loss -> 10G Participants

by Matthew Beckwell

Yeah, we should set aside the ae5 test data for the moment...because I agree it's confusing when it's split across 2 switches. I'd have to rely on someone who speaks Juniper as to what the various paths mean.... "vcp-1" vs "internal-1/24" vs nothing?... Although- it looks like so far all the paths with loss seem to have "vcp-1" in them? ~Matthew On Tue, Sep 20, 2016 at 1:28 PM, Jeremy Lumby <jlumby(a)mnvoip.com> wrote: > Matthew, > > > > The switch throws out an error if I set the destination > port as an agg port. However I did all of their member ports individually > if that helps you. Personally I think AE bundles on different switches > should probably be ignored as data points to keep the troubleshooting > straightforward. > > > > jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-2/0/11 > > vc-path from ge-1/0/15 to xe-2/0/11 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 xe-2/0/11 > > > > {master:1} > > jlumby@MICE-SW1> ...ce ge-1/0/15 destination-interface xe-0/0/35 > > vc-path from ge-1/0/15 to xe-0/0/35 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 1 3 internal-1/24 > > 2 0 1 xe-0/0/35 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/3 > > vc-path from ge-1/0/15 to xe-0/0/3 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 vcp-1 > > 2 0 0 xe-0/0/3 > > > > {master:1} > > jlumby@MICE-SW1> ...e-interface ge-1/0/15 destination-interface xe-0/0/13 > > vc-path from ge-1/0/15 to xe-0/0/13 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 vcp-1 > > 2 0 0 xe-0/0/13 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/29 > > vc-path from ge-1/0/15 to xe-0/0/29 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 1 3 internal-1/24 > > 2 0 1 xe-0/0/29 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-0/0/38 > > vc-path from ge-1/0/15 to xe-0/0/38 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 1 3 internal-1/24 > > 2 0 1 xe-0/0/38 > > > > {master:1} > > jlumby@MICE-SW1> ...-interface ge-1/0/15 destination-interface xe-2/0/15 > > vc-path from ge-1/0/15 to xe-2/0/15 > > Hop Member PFE-Device Interface > > 0 1 4 ge-1/0/15 > > 1 2 6 xe-2/0/15 >

Sept. 20, 2016