Skip to Content.
Sympa Menu

dynes-deployments - Re: [dynes-deployments] PVST+ and DYNES

Subject: DYNES-Deployments

List archive

Re: [dynes-deployments] PVST+ and DYNES


Chronological Thread 
  • From: "Garrison,Nic" <>
  • To: "<>" <>
  • Cc: "" <>, "Dale W. Carder" <>
  • Subject: Re: [dynes-deployments] PVST+ and DYNES
  • Date: Sat, 18 May 2013 00:17:55 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=neutral (message not signed) header.i=none

If I remember correctly the pvst dst MAC address is a hash of the vid, and
non pvst enabled devices just forward the packets. It's unlikely that I2 is
modifying bpdu information and retransmitting the packet. I'm not sure if I2
is filtering standard bpdus or not but passing any version of stp or similar
protocols over these links is asking for trouble.

-Nic

Sent from my iPhone

On May 17, 2013, at 5:07 PM, "Byron L. Hicks"
<>
wrote:

> On 05/17/2013 04:51 PM, Dale W. Carder wrote:
>
>> This has absolutely nothing to do with one protocol being proprietary
>> or not.
>
> Maybe. But if the Internet2 device was a Cisco Switch, would the vlan
> translation also modify the peer vlan id on the BPDU? Or, if the
> Juniper could speak PVST+, would it know to modify the peer vlan id on
> the BPDU. I'm more of a Juniper geek than a Cisco geek, so I don't know
> the answer to the questions. I think the proprietary nature of PVST+
> had some part to play.
>
> On the other hand, if the protocol chosen was RSTP or MSTP, would the
> BPDU just die at the Juniper. I'm not sure of that answer, either.
>
>> When any two interdomain sites are peering you need to pay attention
>> to the fine details. This is true whether for BGP or in this case
>> Spanning Tree. Both give you the tools to inflict damage.
>
> I agree. However, BGP has a little better defined borders. In this
> particular case, the two domains that didn't agree were Vanderbilt and
> SMU. Internet2 didn't strip the BPDU, nor did LEARN. Nor did we
> realize that we needed to until this week.
>
> Should Internet2 be looking for those BPDUs, or is this just up to the
> RoNs to take care of? Or the end sites? In the case of most of my
> DYNES connected community here in Texas, they are using the same path
> for commodity, Internet2, NLR, TR-CPS, and DYNES vlans. They may have a
> legitimate need to run spanning tree across that link, and to not filter
> all BPDUs.
>
>> For example, you probably don't want to accept arbitrary BPDU's any more
>> than you would accept arbitrary NLRI's.
>
> Yes, I agree, and will be pushing to implement the PVST+ BPDU filter on
> all my DYNES connections within LEARN.
>
> --
> Byron Hicks
> Lonestar Education and Research Network
> office: 972-883-4645
> google: 972-746-2549
> aim/skype: byronhicks
>



Archive powered by MHonArc 2.6.16.

Top of Page