Subject: [rbridge] Shared VLAN learning: What is it and why should we care?

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sun, 01 Apr 2007 00:02:38 -0700

Argh! I'm really confused.

We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D), 
it would be
forwarded by the IP router R. And that the RBridge is not doing this. 
Though someone could build
a project that was a combined router/RBridge.

But Sanjay -- I think you misunderstood my question. So let me restate it.

Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D, 
all in the same IP
subnet. The router R is in VLAN Z. The VLAN grouping is {primary=Z, 
secondaries = A, B, C, D}.
Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a 
secondary in the group goes
to all links in *that* secondary, plus Z.

Do we all understand and agree so far? So now my question.

a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged 
with VLAN A. The RBridges
forward it to all links in A, as well as Z (the VLAN tag of the primary 
in the group {Z, A, B, C, D}.
R, with MAC address r, responds to the ARP with a reply saying "ip-D has 
MAC address r".
So ip-A1 and ip-D talk through R.

b) case 2: ip-A1 wants to talk to ip-A2. It does an ARP as before, which 
is tagged with VLAN A.
The RBridges forward it to all links in A as well as Z.

But now both the real target, ip-A2, as well as the router R see the 
ARP. If R replies, then ip-A1 and
ip-A2 will be talking through R.

My question was -- how does R know *not* to respond to the ARP? Or does 
sometimes R wind up
forwarding between endnodes in the same VLAN unnecessarily and we don't 
care because it's
not *incorrect*, it's just suboptimal?

Even if R sees an ARP reply from ip-A2, I don't think R can tell what 
VLAN ip-A2 is in. Because the
packet, once it gets to R, either doesn't have a VLAN tag on it, or the 
VLAN tag says Z.

So...I'd really like to understand this...

Radia

Caitlin Bestler wrote:

>rbridge-bounces at postel.org wrote:
>  
>
>>To answer your quiz: the "enhanced" proxy arp feature is to
>>be supported by the router, NOT by the switch. The
>>enhancement is essentially to be able to proxy arp for local
>>hosts, i.e for those hosts which are on the same subnet as
>>the router interface. This is the "ip local proxy arp"
>>supported feature at least in Cisco implementations.
>>
>>This way, the L3 communication between the hosts belonging to
>>different secondary vlans, is achieved *only* via the router.
>>i.e. if host ip-A
>>(vlan-A) wants to talk to ip-D (vlan-D), it would take 2 hops:
>>mac-A --> mac-router
>>mac-router --> mac-D
>>I think we should preserve this behavior with rbridges.
>>Changing the vlans of the packet should NOT be done by rbridges, imo.
>>
>>-Sanjay
>>
>>
>>
>>    
>>
>I would agree that 'routing' between VLAN-A and VLAN-D
>should only be done as a result of an explicitly created
>'route', and that this is part of being a proxy ARP.
>
>I don't see any real problem with an RBridge doing so,
>as long as it only does so based on explicit instructions
>from the network administrators. It definitely must not
>just assume that it is ok to forward packets between
>two VLANs based upon their both using the same subnet.
>
>While this functionality is certainly more natural 
>in a router, is there any reason to forbid explicitly
>delegating this task to RBridges? It could save a few
>hops on the end-to-end path.
>
>
>  
>

---

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Sun, 1 Apr 2007 16:54:08 -0700

Yep, there are cases of such sub-optimal routing with private vlan. Host
can sometimes receive 2 arp responses, and then there is a chance of
host caching the arp response from the router. 

In private vlan, there are isolated secondary vlans and community
secondary vlans. Any port with isolated secondary vlan cannot tal to any
other port with same isolated secondary vlan. However, ports within the
same community secondary vlan can talk to each other. Of course, in
addition, these ports can talk to port of primary vlan (typically going
towards the router). So, in case ip-A1 and ip-A2 are sitting behind
community vlans, hosts may receive 2 arp responses. 

-Sanjay 

-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Sunday, April 01, 2007 12:03 AM
To: Caitlin Bestler
Cc: Sanjay Sane (sanjays); rbridge at postel.org
Subject: Re: [rbridge] Shared VLAN learning: What is it and why should
we care?

We are agreeing that when ip-A (VLAN A) wants to talk to IP-d (VLAN D),
it would be forwarded by the IP router R. And that the RBridge is not
doing this. 
Though someone could build
a project that was a combined router/RBridge.

But Sanjay -- I think you misunderstood my question. So let me restate
it.

Let's say endnodes ip-A1 and ip-a2 are in VLAN A, and ip-D is in VLAN D,
all in the same IP subnet. The router R is in VLAN Z. The VLAN grouping
is {primary=Z, secondaries = A, B, C, D}.
Anything tagged Z goes to Z, A, B, C, and D. Anything tagged with a
secondary in the group goes to all links in *that* secondary, plus Z.

a) case 1: ip-A1 wants to talk to ip-D. It does an ARP, which is tagged
with VLAN A. The RBridges forward it to all links in A, as well as Z
(the VLAN tag of the primary in the group {Z, A, B, C, D}.
R, with MAC address r, responds to the ARP with a reply saying "ip-D has
MAC address r".
So ip-A1 and ip-D talk through R.

My question was -- how does R know *not* to respond to the ARP? Or does
sometimes R wind up forwarding between endnodes in the same VLAN
unnecessarily and we don't care because it's not *incorrect*, it's just
suboptimal?

Even if R sees an ARP reply from ip-A2, I don't think R can tell what
VLAN ip-A2 is in. Because the packet, once it gets to R, either doesn't
have a VLAN tag on it, or the VLAN tag says Z.

Radia

Caitlin Bestler wrote:

>>To answer your quiz: the "enhanced" proxy arp feature is to be 
>>supported by the router, NOT by the switch. The enhancement is 
>>essentially to be able to proxy arp for local hosts, i.e for those 
>>hosts which are on the same subnet as the router interface. This is 
>>the "ip local proxy arp"
>I would agree that 'routing' between VLAN-A and VLAN-D should only be 
>done as a result of an explicitly created 'route', and that this is 
>part of being a proxy ARP.
>
>I don't see any real problem with an RBridge doing so, as long as it 
>only does so based on explicit instructions from the network 
>administrators. It definitely must not just assume that it is ok to 
>forward packets between two VLANs based upon their both using the same 
>subnet.
>
>While this functionality is certainly more natural in a router, is 
>there any reason to forbid explicitly delegating this task to RBridges?

>It could save a few hops on the end-to-end path.
>
>
>  
>

---

From: caitlinb at broadcom.com (Caitlin Bestler)
Date: Mon, 2 Apr 2007 11:21:28 -0700

Radia Perlman wrote:

> 
> My question was -- how does R know *not* to respond to the
> ARP? Or does sometimes R wind up forwarding between endnodes
> in the same VLAN unnecessarily and we don't care because it's

I'm not sure what the relevant specs are, but my understanding
has always been that a Proxy ARP only answers an ARP request
if it is somehow between the requester and the machine it
is proxying for.

My direct experience with this all relates to Cable Modems,
so I haven't thought about corner cases where the "between"
status might not be blatantly obvious. And in that case 
flooding irrelevant packets from every home network upstream
was not "suboptimal", it would have been a network killer.
So luckily the distinction between the home network and
the cable network was easily made.

---

From: jrrivers at nuovasystems.com (J. R. Rivers)
Date: Mon, 2 Apr 2007 12:15:49 -0700

More importantly is that sometimes R does reply to local ARPs and
sometimes it doesn't... as part of system vendor feature definitions.
Generally, I've always thought of ARP as a router/host function.  As the
lines blur between routers and switches, there have been many features
introduced into "switches" based on router functionality.

I'd argue that this is one great reason to leave ARP out of TRILL so
that any of these extensions can continue to work based on their
expectations of the underlying L2 network.

JR

> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Caitlin Bestler
> Sent: Monday, April 02, 2007 11:21 AM
> To: Radia Perlman
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Shared VLAN learning: What is it and 
> why should we care?
> 
> Radia Perlman wrote:
> 
> > 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: riw at cisco.com (Russ White)
Date: Tue, 03 Apr 2007 08:58:27 -0400

> Argh! I'm really confused.

Could we have a network diagram posted someplace on a web site? I'm
finding this hard to follow from text descriptions.... ??

:-)

Russ

- --
riw at cisco.com CCIE <>< Grace Alone

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 3 Apr 2007 08:17:59 -0500

Russ,

	I'm with you on that, but I doubt that a single diagram
would suffice to describe the many different things that people
are talking about.  Trying to come up with a single diagram to 
include all of the issues would result in a diagram too complex
to be useful in most cases.

	You may have seen the simplistic one I provided to show 
the potential problems that might arise from using inter-VLAN
Proxy ARP with RBridges - if one does not take into account a
real-world possibility that this may be done already using the
techniques that are deployed today.  But does that one serve
to illustrate the other problems discussed in this thread?  I
think not...

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White
> Sent: Tuesday, April 03, 2007 8:58 AM
> To: Radia Perlman
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGEk9zER27sUhU9OQRAs00AJwLav8FeqJ59QvW9/jGuyaCw9Pn8ACdFqFn
> CLWoXE/tUZ9ouCsFEhdTOqU=
> =e8Vh
> -----END PGP SIGNATURE-----

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Tue, 3 Apr 2007 08:25:38 -0500

Russ,

	Silvano provided a reference for a diagram that does
cover several of the issues.  Silvano said:

"Please review IEEE 802.1Q-2005 B.1.3 Asymmetric VLANs.  In 
 figure B-4 assume a router instead of the Server."

I don't think I am at liberty to disclose publicly how you 
can get direct access to that publication, but you can.  See
your local IEEE people to find out how...

--
Eric Gray
Principal Engineer
Ericsson

---

From: dwcarder at doit.wisc.edu (Dale W. Carder)
Date: Tue, 3 Apr 2007 08:50:16 -0500

> your local IEEE people to find out how...

They are now free to download after a 6 month period after
initial release:

http://standards.ieee.org/getieee802/802.1.html

Dale