Hi Mike, Yes, confusing. :P I've run full circle on this today -- Andrew's hints have sent me in the right direction. Essentially, I'll be throwing out the bridge grouping at some stage, and attaching ARP and ND to individual sub interfaces. T -- http://about.me/terry.sweetser ------------------------------------------------------------------------ *From:* Mike Everest <mailto:%3Ca%3Emike@duxtel.com%3C/a%3E> *Sent:* Wednesday, April 22, 2015 4:16PM *To:* Terrence Sweetser, 'mikrotik Australia Public List' <mailto:%3Ca%3Eterry@skymesh.net.au%3C/a%3E,%20%3Ca%3Epublic@talk.mikrotik.com.au%3C/a%3E> *Subject:* Re: [MT-AU Public] L3 over QinQ and a Bridge -- too far?
I'm confused.. :-}
None of the ipv4 addresses can actually connect to or ping each other. I read that as the problem, not as "that works, check!" ;-)
Thus my strange remarks previous! :-D
Cheers!
Mike.
-----Original Message----- From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Terry Sweetser Sent: Wednesday, 22 April 2015 1:28 PM To: public@talk.mikrotik.com.au Subject: Re: [MT-AU Public] L3 over QinQ and a Bridge -- too far?
Hi Andrew,
Initially, the consideration is security -- I don't want L2 broadcast traffic to travel between client endpoints.
Setting horizon "1" on all of the AVCs ensures that, but then ARP no longer gets to sends queries from AVC to AVC.
Removing the horizon causes a massive ARP storm between 600+ interfaces all sending broadcasts.
I've also discovered that several brands of cheap CPE router do not respond well to seeing 600+ mac addresses from the WAN port.
Removing the point-to-point setting and swapping between "enabled" and "proxy-arp" has not changed the client to client routing situation.
Starting to think a bridge group of this size is not a good idea.
http://about.me/terry.sweetser
------------------------------------------------------------------------
*From:* Andrew Thrift <mailto:%3Ca%3Eandrew@networklabs.co.nz%3C/a%3E> *Sent:* Wednesday, April 22, 2015 10:02AM *To:* Terrence Sweetser, 'mikrotik Australia Public List' <mailto:%3Ca%3Eterry@skymesh.net.au%3C/a%3E,%20%3Ca%3Epublic@tal k.mikrotik.com.au%3C/a%3E> *Subject:* Re: [MT-AU Public] L3 over QinQ and a Bridge -- too far?
Hi Terry,
Am I correct in assuming you are trying to achieve PVLAN functionality ?
This currently does not specifically exist on RouterOS, but there is a work around that achieves the same result.
The trick is to drop packets from forwarding on the bridge, and use bridge NAT to re-write arp requests so all traffic between clients passes via the Mikrotik bridge MAC address e.g.
/interface bridge filter add action=drop chain=forward comment="Drop everything" in-bridge=bridge4 out-bridge=bridge4
/interface bridge nat add action=arp-reply chain=dstnat comment="Re-write MAC in ARP responses" in-bridge=bridge4 mac-protocol=arp to-arp-reply-mac-address=D4:CA:6D:01:3B:80
Where bridge4 is the bridge you are doing this on and "D4:CA:6D:01:3B:80" is the MAC address of the bridge.
I requested a "pvlan" arp option on bridges and Mikrotik came back that they will add this in RouterOS v7 which will negate the need for this workaround.
Regards,
Andrew
On Wed, Apr 22, 2015 at 11:16 AM, Terry Sweetser < terry+mikrotik@skymesh.net.au> wrote:
Hi Mike,
Yes, I'm of the opinion I have the proxy-arp and p2p issues muddled up somehow.
Changing to "enabled" for arp on the bridge makes no difference to the issue, less arp traffic is always good.
I've also got "horizon" set as well, to "1" on all ports.
So, what to try instead of point-to-point?
http://about.me/terry.sweetser
--------------------------------------------------------------------- ---
*From:* Mike Everest <mailto:%3Ca%3Emike@duxtel.com%3C/a%3E> *Sent:* Wednesday, April 22, 2015 8:51AM *To:* Terrence Sweetser, 'mikrotik Australia Public List' <mailto:%
.au %3C/a%3E> *Subject:* RE: [MT-AU Public] L3 over QinQ and a Bridge -- too far?
Hi Terry,
Any reason why you have proxy ARP enabled? I don't think you will want the bridge to be answering any ARP requests other than to its own address/es (do you?)
Also, I'm not certain what is the effect of point-to-point mode on bridge port, but I can't imagine that you would need to force it in
3Ca%3Eterry@skymesh.net.au%3C/a%3E,%20%3Ca%3Epublic@talk.mikrotik. com these cases.
Since you highlighted both attributes, I suspect that you have some focus on them already - can you add any comment on why you have selected them?
Cheers
Mike.
-----Original Message-----
From: Public [mailto:public-bounces@talk.mikrotik.com.au] On Behalf Of Terry Sweetser Sent: Wednesday, 22 April 2015 8:22 AM To: public@talk.mikrotik.com.au Subject: [MT-AU Public] L3 over QinQ and a Bridge -- too far?
Hello Mikrotikians,
I've been looking at this one for a while now.
I have several hundred QinQ vlans heading into a single bridge group.
ipv4 and ipv6 from the bridge interface into the individual links is
working
well.
None of the ipv4 addresses can actually connect to or ping each other.
Flags: X - disabled, R - running 0 R name="bridge136" mtu=auto actual-mtu=1500 l2mtu=1992 *arp=proxy-arp* mac-address=D4:CA:6D:01:38:C7 protocol-mode=none priority=0x8000 auto-mac=yes admin-mac=00:00:00:00:00:00 max-message-age=20s forward-delay=15s transmit-hold-count=6 ageing-time=5m
Flags: X - disabled, I - inactive, D - dynamic 0 interface=XXXXXX bridge=bridge136 priority=0x80 path-cost=10 edge=auto *point-to-point=yes* external-fdb=auto horizon=1 auto- isolate=no
A bridge too far?
_So, I'm looking for solution where the IPv* arrives at bridge136 and then goes straight back out the correct port.__ _ -- http://about.me/terry.sweetser
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.co m.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com .au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com. au
Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au
_______________________________________________ Public mailing list Public@talk.mikrotik.com.au http://talk.mikrotik.com.au/mailman/listinfo/public_talk.mikrotik.com.au