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

[Sanjay Sane (sanjays)]

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?

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.
>
>
>  
>