[j-nsp] Correct config for SRX port channel -> Cisco

Stacy W. Smith stacy at acm.org
Wed Jul 24 10:48:21 EDT 2013


In general, I see no problems with your AE configuration.

Could you define "never comes up"? Is it the ae0 interface, or the ae0.999 unit that is in a down state?

The output of "show interfaces terse" (at least for the member and ae interfaces)

and the output of "show lacp interfaces" might be helpful.

FWIW, the two ends of your link are in different subnets. 192.168.1.1/31 and 192.168.1.2/31 are not in the same subnet.

--Stacy


On Jul 24, 2013, at 7:27 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> If I have a single SRX3600 device (NOT a cluster), what config (if any...) can I use to match a config on the Cisco side:
> 
> int <member>
>  lacp rate fast
>  channel-group 20 mode active
> int Po20
>  switchport
>  switchport mode trunk
>  switchport trunk allowed vlan 999
> int Vlan999
>  ip address 192.168.1.1 255.255.255.254
> 
> I would have thought it would be something like:
> 
> chassis {
>    aggregated-devices {
>        ethernet {
>            device-count 2;
>        }
>    }
> }
> interfaces {
>    xe-1/0/0 {
>        gigether-options {
>            802.3ad ae0;
>        }
>    }
>    xe-1/0/1 {
>        disable;
>    }
>    xe-4/0/0 {
>        gigether-options {
>            802.3ad ae0;
>        }
>    }
>    xe-4/0/1 {
>        disable;
>    }
>    ae0 {
>        vlan-tagging;
>        aggregated-ether-options {
>            lacp {
>                active;
>                periodic fast;
>            }
>        }
>        unit 999 {
>            vlan-id 999;
>            family inet {
>                address 192.168.1.2/31;
>            }
>        }
>    }
> }
> 
> ...but this never comes up. I've seen this before, and I think it's because there's something in the LACP PDUs which disagrees about trunk/access mode. The config works if I set the Cisco side to "access", but obviously that's not what I want.
> 
> Can you even do this on SRX? I see lots of documents talking about reth interfaces, but AFAICT those are all for chassis clustering, which we don't want to use.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp




More information about the juniper-nsp mailing list