Re: [j-nsp] MX - Changing MAC address on different unit of the same interface

2013-04-06 Thread Nitzan Tzelniker
Another use case is for DPI or other transparent devices when your traffic
is not symmetrical (more downstream than upstream )
you are installing the DPI between two vrf on the same router and use
switch as port extender
This way you are using less ports on the router for almost the same amount
of traffic

btw IIRC one way to solve it is to use rvi interface as the L3 it
have different mac address then the physical port


  +-+
  +-+| |
  | |  +-++|
  | Router  |  |  ||
  | +--|SW| +--+-+
  | |  |  | |DPI |
  +-+  +-++ +--+-+
 | |
 +-+

Nitzan




On Sat, Apr 6, 2013 at 8:10 AM, Julien Goodwin jgood...@studio442.com.auwrote:

 On 06/04/13 03:59, sth...@nethelp.no wrote:
  No, this is not possible (and why would you need it?). If you think
  about this for a moment, it would require the ability to have 16k or
  so MAC addresses per physical interface. Highly unrealistic.

 I can think of one common case, many IX's and shared (colo usually)
 transit lans do static mac filters, and if you need to move the port
 being able to override the mac can get you back up far quicker then
 dealing with a support tech who may not understand the problem.

 If that's a low-speed circuit aggregating it can make sense which can
 easily lead to a request to do per-VLAN mac's.

 --
 Julien Goodwin
 Studio442
 Blue Sky Solutioneering


 ___
 juniper-nsp mailing list juniper-nsp@puck.nether.net
 https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] MX - Changing MAC address on different unit of the same interface

2013-04-05 Thread sthaug
 I've tried to find a solution but I'm afraid I've reached a dead-end : Is
 it possible to fix the MAC address on a aggregated interface PER UNIT? The
 mac command is available at interfaces level, not unit.
 JunOS version is 11.4

No, this is not possible (and why would you need it?). If you think
about this for a moment, it would require the ability to have 16k or
so MAC addresses per physical interface. Highly unrealistic.

If you need equipment that handles lots of different MAC addresses per
physical interface, you need to buy an Ixia tester or similar...

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] MX - Changing MAC address on different unit of the same interface

2013-04-05 Thread Saku Ytti
On (2013-04-05 18:59 +0200), sth...@nethelp.no wrote:

 No, this is not possible (and why would you need it?). If you think
 about this for a moment, it would require the ability to have 16k or
 so MAC addresses per physical interface. Highly unrealistic.

This is interesting question. The implication here is, that you believe
they are using PHY to limit what frames are received. Which is perfectly
sane thing to do in a router or in a host.

But MX can be switch and there is EoMPLS, which means, it would need often
need to be in 'promisc' mode anyhow.

I'm going to guess that PHY itself is always in promisc mode and MAC
address is handle like any other lookup key, i.e. I don't expect there to
be any particular HW imposed limit to this.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


Re: [j-nsp] MX - Changing MAC address on different unit of the same interface

2013-04-05 Thread Julien Goodwin
On 06/04/13 03:59, sth...@nethelp.no wrote:
 No, this is not possible (and why would you need it?). If you think
 about this for a moment, it would require the ability to have 16k or
 so MAC addresses per physical interface. Highly unrealistic.

I can think of one common case, many IX's and shared (colo usually)
transit lans do static mac filters, and if you need to move the port
being able to override the mac can get you back up far quicker then
dealing with a support tech who may not understand the problem.

If that's a low-speed circuit aggregating it can make sense which can
easily lead to a request to do per-VLAN mac's.

-- 
Julien Goodwin
Studio442
Blue Sky Solutioneering



signature.asc
Description: OpenPGP digital signature
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp