Re: [j-nsp] RSTP over logical-system.
David,
I don't think you can run RSTP in logical routers. As you can see from your
outputs below, RSTP instances in all the LRs are using same system MAC. You
can probably try MSTP but don't think RSTP will work in LRs.
BTW, what JUNOS version is this?
Thanks,
Nilesh.
> n...@mx960-lab-re0> ...ge logical-system SW1 routing-instance 11
> STP bridge parameters
> Routing instance name : SW1/11
> Context ID : 1
> Enabled protocol: STP
> Root ID : 0.80:71:1f:8c:7f:d0
> Hello time: 2 seconds
> Maximum age : 20 seconds
> Forward delay : 15 seconds
> Message age : 0
> Number of topology changes: 2
> Time since last topology change : 388 seconds
> Local parameters
> Bridge ID : 0.80:71:1f:8c:7f:d0 <<<
> Extended system ID : 0
>
> {master}
> n...@mx960-lab-re0> ...tree bridge logical-system SW2 routing-instance 12
> STP bridge parameters
> Routing instance name : SW2/12
> Context ID : 2
> Enabled protocol: STP
> Root ID : 8192.80:71:1f:8c:7f:d0
> Hello time: 2 seconds
> Maximum age : 20 seconds
> Forward delay : 15 seconds
> Message age : 0
> Number of topology changes: 1
> Time since last topology change : 396 seconds
> Local parameters
> Bridge ID : 8192.80:71:1f:8c:7f:d0 <<<
> Extended system ID : 0
On 11/2/10 7:08 PM, "David Lockuan" wrote:
> Hi guys,
>
> I'm testing the protocols rstp over logical-systems, but when I set the
> priority over one interface for it work as root, it is not change the status
> in the protocols rstp and the other interface don't change to Blocking.
> theirs always keep on Forwarding state.
>
> The topology that I am using it is the next:
>
> SW1 (logical)---ge-3/0/2loop
> fisicoge-3/0/3--SW2(logical)
> SW1 (logical)---ge-3/0/4loop
> fisicoge-3/0/5--SW2(logical)
>
> I want to put the interface ge-3/0/2 as root interface.
>
> These are configuration of both logical-systems:
>
**>
*
> {master}
> n...@mx960-lab-re0> show configuration interfaces
> ge-3/0/2 {
> encapsulation ethernet-bridge;
> }
> ge-3/0/3 {
> encapsulation ethernet-bridge;
> }
> ge-3/0/4 {
> encapsulation ethernet-bridge;
> }
> ge-3/0/5 {
> encapsulation ethernet-bridge;
> }
>
> {master}
> n...@mx960-lab-re0> show configuration logical-systems SW1
> interfaces {
> ge-3/0/2 {
> unit 0 {
> family bridge;
> }
> }
> ge-3/0/4 {
> unit 0 {
> family bridge;
> }
> }
> }
> routing-instances {
> 11 {
> instance-type virtual-switch;
> protocols {
> rstp {
> bridge-priority 0;
> interface ge-3/0/2 {
> priority 0;
> mode point-to-point;
> }
> interface ge-3/0/4 {
> mode point-to-point;
> }
> force-version stp;
> }
> }
> bridge-domains {
> br1 {
> interface ge-3/0/2.0;
> interface ge-3/0/4.0;
> }
> }
> }
> }
>
> {master}
> n...@mx960-lab-re0> show configuration logical-systems SW2
> interfaces {
> ge-3/0/3 {
> unit 0 {
> family bridge;
> }
> }
> ge-3/0/5 {
> unit 0 {
> family bridge;
> }
> }
> }
> routing-instances {
> 12 {
> instance-type virtual-switch;
> protocols {
> rstp {
> bridge-priority 8k;
> interface ge-3/0/3 {
> mode point-to-point;
> }
> interface ge-3/0/5 {
> mode point-to-point;
> }
> force-version stp;
> }
> }
> bridge-domains {
> br1 {
> interface ge-3/0/3.0;
> interface ge-3/0/5.0;
> }
> }
> }
> }
>
> {master}
> n...@mx960-lab-re0>
>
**>
*
>
> The output of the show spanning-tree commands:
>
>
**>
*
> {master}
> n...@mx960-lab-re0> ...e interface logical-system SW1 routing-instance 11
>
> Spanning tree interface parameters for instance 0
>
> InterfacePort IDDesignated Designated PortState
[j-nsp] RSTP over logical-system.
Hi guys,
I'm testing the protocols rstp over logical-systems, but when I set the
priority over one interface for it work as root, it is not change the status
in the protocols rstp and the other interface don't change to Blocking.
theirs always keep on Forwarding state.
The topology that I am using it is the next:
SW1 (logical)---ge-3/0/2loop
fisicoge-3/0/3--SW2(logical)
SW1 (logical)---ge-3/0/4loop
fisicoge-3/0/5--SW2(logical)
I want to put the interface ge-3/0/2 as root interface.
These are configuration of both logical-systems:
***
{master}
n...@mx960-lab-re0> show configuration interfaces
ge-3/0/2 {
encapsulation ethernet-bridge;
}
ge-3/0/3 {
encapsulation ethernet-bridge;
}
ge-3/0/4 {
encapsulation ethernet-bridge;
}
ge-3/0/5 {
encapsulation ethernet-bridge;
}
{master}
n...@mx960-lab-re0> show configuration logical-systems SW1
interfaces {
ge-3/0/2 {
unit 0 {
family bridge;
}
}
ge-3/0/4 {
unit 0 {
family bridge;
}
}
}
routing-instances {
11 {
instance-type virtual-switch;
protocols {
rstp {
bridge-priority 0;
interface ge-3/0/2 {
priority 0;
mode point-to-point;
}
interface ge-3/0/4 {
mode point-to-point;
}
force-version stp;
}
}
bridge-domains {
br1 {
interface ge-3/0/2.0;
interface ge-3/0/4.0;
}
}
}
}
{master}
n...@mx960-lab-re0> show configuration logical-systems SW2
interfaces {
ge-3/0/3 {
unit 0 {
family bridge;
}
}
ge-3/0/5 {
unit 0 {
family bridge;
}
}
}
routing-instances {
12 {
instance-type virtual-switch;
protocols {
rstp {
bridge-priority 8k;
interface ge-3/0/3 {
mode point-to-point;
}
interface ge-3/0/5 {
mode point-to-point;
}
force-version stp;
}
}
bridge-domains {
br1 {
interface ge-3/0/3.0;
interface ge-3/0/5.0;
}
}
}
}
{master}
n...@mx960-lab-re0>
***
The output of the show spanning-tree commands:
***
{master}
n...@mx960-lab-re0> ...e interface logical-system SW1 routing-instance 11
Spanning tree interface parameters for instance 0
InterfacePort IDDesignated Designated PortState
Role
port IDbridge ID Cost
ge-3/0/2 0:1230:123 0.80711f8c7fd0 2 FWD
DESG
ge-3/0/4 128:125 128:125 0.80711f8c7fd0 2 FWD
DESG
{master}
n...@mx960-lab-re0> ...e interface logical-system SW2 routing-instance 12
Spanning tree interface parameters for instance 0
InterfacePort IDDesignated Designated PortState
Role
port IDbridge ID Cost
ge-3/0/3 128:124 128:124 8192.80711f8c7fd0 2 FWD
DESG
ge-3/0/5 128:126 128:126 8192.80711f8c7fd0 2 FWD
DESG
{master}
n...@mx960-lab-re0> show spanning-tree bridge logical-system SW1
Spanning-tree is not enabled in layer2-control instance SW1/default.
{master}
n...@mx960-lab-re0> ...ge logical-system SW1 routing-instance 11
STP bridge parameters
Routing instance name : SW1/11
Context ID : 1
Enabled protocol: STP
Root ID : 0.80:71:1f:8c:7f:d0
Hello time: 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Message age : 0
Number of topology changes: 2
Time since last topology change : 388 seconds
Local parameters
Bridge ID : 0.80:71:1f:8c:7f:d0
Extended system ID : 0
{master}
n...@mx960-lab-re0> ...tree bridge logical-system SW2 routing-instance 12
STP bridge parameters
Routing instance name : SW2/12
Context ID : 2
Enabled protocol: STP
Root ID : 8192.80:71:1f:8c:7f:d0
Hello time: 2 seconds
Maximum age : 20 seconds
Forward delay : 15 seconds
Message age : 0
Number of topology changes: 1
Time since last topo
Re: [j-nsp] Good practice for EX-series interface config management
On Nov 2, 2010, at 5:31 PM, Dale Shaw wrote: > Hi all, > > I'm curious about what people have found is the best way to manage > interface configurations on EX-series devices. There are a number of > ways to apply configuration to interfaces -- direct to each interface, > using interface-ranges etc. > > We've been burnt a couple of times with people making adjustments to > interface-ranges and not paying close enough attention to the net > effect of their change (e.g. leaving out all interfaces on a switch). > Direct application of config to interfaces, while precise, kind of > feels 'wrong' as JUNOS provides more elegant ways to achieve the same > end result. Maybe in carefully planned, static environments where > access port VLAN assignments and other port specific configs rarely > change, interface-ranges are more workable. Or maybe we're just doing > it wrong. > I suppose it depends on what you use the switch for. We mostly use them as access in hosting environments. I like using config groups where you can group anything related to a particular customer together. But that's just my preference. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Clustering - IPv6
Ah yes this one really annoyed me. In 10.1 and earlier IPv6 is supported on
VLAN interfaces. When you upgrade to 10.2 or later they stop you being able to
apply this configuration, however EXISTING configuration still works just fine:
bd...@srx210# show interfaces vlan.10
description "LAN RVI Interface";
family inet {
address 172.16.10.254/24;
}
family inet6 {
address 2001:a4b0:d0d:77a::1/64;
}
[edit]
bd...@srx210# set interfaces vlan.10 family inet6
^
syntax error.
bd...@srx210# set interfaces vlan.10 family inet6
bd...@srx210# run show route
...
inet6.0: 18 destinations, 19 routes (18 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
...
2001:a4b0:d0d:77a::/64*[Direct/0] 6d 21:51:58
> via vlan.10
On 03/11/2010, at 6:39 AM, Paul Stewart wrote:
> Hmmm.. interesting - I thought I had reviewed 10.2 for this support... will
> dig deeper. So then comes the question - anyone actually *using* IPv6 on
> clustered SRX? Any real-world feedback?
>
> I have an SRX210H at home and recently discovered an annoying "bug" that IPv6
> isn't supported on VLAN interfaces... that was kind of a shock to be blunt..
>
> Thanks,
> Paul
>
>
> -Original Message-
> From: Crist Clark [mailto:crist.cl...@globalstar.com]
> Sent: Tuesday, November 02, 2010 3:22 PM
> To: Paul Stewart; juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] SRX650 Clustering - IPv6
>
> I just happened to be looking at the 10.2 release notes after
> seeing your email.
>
> "IPv6 Support
>[snip]
>
>* Chassis cluster—In JUNOS Release 10.2, we support chassis
> cluster in an active-passive (failover) deployment. [Junos OS Security
> Configuration Guide]"
>
> You may want to have a closer look at the 10.2 documentation
> (the current recommended release for SRXs). I am not using
> this feature so I have no personal experience whether it actually
> works.
>
>
> On 11/2/2010 at 10:43 AM, "Paul Stewart" wrote:
>> Hi there.
>>
>>
>>
>> We are looking to bring on an additional SRX650 at a site by
> clustering.
>> One of the requirements though is IPv6 traffic and it appears it's
> not
>> supported?
>>
>>
>>
>> From
>>
> http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c
>
>> ollections/release-notes/10/topic-39007.html :
>>
>>
>>
>> Chassis Cluster
>>
>> On SRX Series and J Series devices, the following features are not
> supported
>> when chassis clustering is enabled on the device:
>>
>> *All packet-based protocols, such as MPLS, Connectionless
> Network
>> Service (CLNS), and IP version 6 (IPv6)
>>
>>
>>
>>
>>
>>
>>
>> Do any of the SRX boxes support clustering with IPv6? Is there any
> timeline
>> on this being fixed that anyone knows of?
>>
>>
>>
>> Our goal is redundant routing engines should something happen - makes
> more
>> $$$ sense to add an additional SRX650 when there is one existing..
>>
>>
>>
>> Thanks in advance,
>>
>>
>>
>> Paul
>>
>>
>>
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> --
>
> Crist Clark
> Network Security Specialist, Information Systems
> Globalstar
> 408 933 4387
>
>
>
> ___
> 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] Good practice for EX-series interface config management
On Tue, Nov 2, 2010 at 2:31 PM, Dale Shaw wrote: > Hi all, > > I'm curious about what people have found is the best way to manage > interface configurations on EX-series devices. There are a number of > ways to apply configuration to interfaces -- direct to each interface, > using interface-ranges etc. > > We've been burnt a couple of times with people making adjustments to > interface-ranges and not paying close enough attention to the net > effect of their change (e.g. leaving out all interfaces on a switch). > Direct application of config to interfaces, while precise, kind of > feels 'wrong' as JUNOS provides more elegant ways to achieve the same > end result. Maybe in carefully planned, static environments where > access port VLAN assignments and other port specific configs rarely > change, interface-ranges are more workable. Or maybe we're just doing > it wrong. > > I'm hoping that this sparks some discussion. What works best for you? > > Cheers, > Dale We use apply group to manage EX interfaces. In case we change settings in a specific group, it will only affect those member interfaces who explicitly have the group configed. -- Michel~ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Good practice for EX-series interface config management
On Wed, Nov 03, 2010 at 08:31:27AM +1100, Dale Shaw wrote:
> Direct application of config to interfaces, while precise, kind of
> feels 'wrong' as JUNOS provides more elegant ways to achieve the same
> end result. Maybe in carefully planned, static environments where
> access port VLAN assignments and other port specific configs rarely
> change, interface-ranges are more workable. Or maybe we're just doing
> it wrong.
>
> I'm hoping that this sparks some discussion. What works best for you?
I avoid interface-ranges because it is too error-prone as you mention.
What JUNOS really needs is a way to expand a list of interface ranges
when you type CLI commands, without storing that range in the
candidate or commited configuration. E.g.:
set interfaces {ge-0/0/0-ge-0/0/3,ge-0/0/5-ge-0/0/7} unit 0 family
ethernet-switching vlan members 10
would create the following expanded candidate configuration:
ge-0/0/0 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
ge-0/0/1 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
ge-0/0/2 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
ge-0/0/3 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
ge-0/0/5 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
ge-0/0/6 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
ge-0/0/7 {
unit 0 {
family ethernet-switching {
vlan {
members 10;
}
}
}
}
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Good practice for EX-series interface config management
Hi all, I'm curious about what people have found is the best way to manage interface configurations on EX-series devices. There are a number of ways to apply configuration to interfaces -- direct to each interface, using interface-ranges etc. We've been burnt a couple of times with people making adjustments to interface-ranges and not paying close enough attention to the net effect of their change (e.g. leaving out all interfaces on a switch). Direct application of config to interfaces, while precise, kind of feels 'wrong' as JUNOS provides more elegant ways to achieve the same end result. Maybe in carefully planned, static environments where access port VLAN assignments and other port specific configs rarely change, interface-ranges are more workable. Or maybe we're just doing it wrong. I'm hoping that this sparks some discussion. What works best for you? Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Dynamic DB
On Wed, Oct 27, 2010 at 11:25:27PM +0400, Pavel Lunin writes: PL> Anyone here uses dynamic-db? Works? or as always? :) We're using dynamic-db for prefix-lists, it works good. On 9.5 there was a fault with corrupted dynamic.db and mpd coredump. Now on 10.3 there were no faults (yet?). Quick commit, no periodic prefix-lists updates in rollback history, avoid collisions between prefix-lists auto-updates and manual config changes. But no "show dynamic-config" command or something like that (only "configure dynamic" and then "show"). More detailed about my expirience with dynamic-db here: http://gul-tech.livejournal.com/4908.html (in russian). -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Clustering - IPv6
Found it .. sorry folks - there was a document on their site that explained limitations on 10.2 and IPv6 clustered WAS listed there as not implemented. Now I find new information at http://www.juniper.net/us/en/community/junos/releases/10-2/#security IPv6 Release 10.2 adds several new IPv6 capabilities to SRX and J Series devices, including support for: * Address books and address set entries that contain any combination of IPv4 addresses, IPv6 addresses, and Domain Name System (DNS) names * Chassis clusters in active-passive (failover) deployments * Using IPv6 DiffServ code points in class of service (CoS) classifier rules and re-write rules * Flow-based processing, which enables SRX and J Series security features to process IPv6 traffic * The ability to configure a logical interface with an IPv4 address, and IPv6 address or both Any feedback on those folks who have deployed it and have it working is appreciated customer is a bit concerned about cost - I'm just concerned about it actually working properly ;) Cheers, Paul -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, November 02, 2010 4:39 PM To: 'Crist Clark'; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 Clustering - IPv6 Hmmm.. interesting - I thought I had reviewed 10.2 for this support... will dig deeper. So then comes the question - anyone actually *using* IPv6 on clustered SRX? Any real-world feedback? I have an SRX210H at home and recently discovered an annoying "bug" that IPv6 isn't supported on VLAN interfaces... that was kind of a shock to be blunt.. Thanks, Paul -Original Message- From: Crist Clark [mailto:crist.cl...@globalstar.com] Sent: Tuesday, November 02, 2010 3:22 PM To: Paul Stewart; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 Clustering - IPv6 I just happened to be looking at the 10.2 release notes after seeing your email. "IPv6 Support [snip] * Chassis cluster—In JUNOS Release 10.2, we support chassis cluster in an active-passive (failover) deployment. [Junos OS Security Configuration Guide]" You may want to have a closer look at the 10.2 documentation (the current recommended release for SRXs). I am not using this feature so I have no personal experience whether it actually works. On 11/2/2010 at 10:43 AM, "Paul Stewart" wrote: > Hi there. > > > > We are looking to bring on an additional SRX650 at a site by clustering. > One of the requirements though is IPv6 traffic and it appears it's not > supported? > > > > From > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c > ollections/release-notes/10/topic-39007.html : > > > > Chassis Cluster > > On SRX Series and J Series devices, the following features are not supported > when chassis clustering is enabled on the device: > > * All packet-based protocols, such as MPLS, Connectionless Network > Service (CLNS), and IP version 6 (IPv6) > > > > > > > > Do any of the SRX boxes support clustering with IPv6? Is there any timeline > on this being fixed that anyone knows of? > > > > Our goal is redundant routing engines should something happen - makes more > $$$ sense to add an additional SRX650 when there is one existing.. > > > > Thanks in advance, > > > > Paul > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ 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] SRX650 Clustering - IPv6
Hmmm.. interesting - I thought I had reviewed 10.2 for this support... will dig deeper. So then comes the question - anyone actually *using* IPv6 on clustered SRX? Any real-world feedback? I have an SRX210H at home and recently discovered an annoying "bug" that IPv6 isn't supported on VLAN interfaces... that was kind of a shock to be blunt.. Thanks, Paul -Original Message- From: Crist Clark [mailto:crist.cl...@globalstar.com] Sent: Tuesday, November 02, 2010 3:22 PM To: Paul Stewart; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX650 Clustering - IPv6 I just happened to be looking at the 10.2 release notes after seeing your email. "IPv6 Support [snip] * Chassis cluster—In JUNOS Release 10.2, we support chassis cluster in an active-passive (failover) deployment. [Junos OS Security Configuration Guide]" You may want to have a closer look at the 10.2 documentation (the current recommended release for SRXs). I am not using this feature so I have no personal experience whether it actually works. On 11/2/2010 at 10:43 AM, "Paul Stewart" wrote: > Hi there. > > > > We are looking to bring on an additional SRX650 at a site by clustering. > One of the requirements though is IPv6 traffic and it appears it's not > supported? > > > > From > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c > ollections/release-notes/10/topic-39007.html : > > > > Chassis Cluster > > On SRX Series and J Series devices, the following features are not supported > when chassis clustering is enabled on the device: > > * All packet-based protocols, such as MPLS, Connectionless Network > Service (CLNS), and IP version 6 (IPv6) > > > > > > > > Do any of the SRX boxes support clustering with IPv6? Is there any timeline > on this being fixed that anyone knows of? > > > > Our goal is redundant routing engines should something happen - makes more > $$$ sense to add an additional SRX650 when there is one existing.. > > > > Thanks in advance, > > > > Paul > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4200 Air Flow
I have several EX3200's and EX4200's installed in my Data Center. In comparing the two, they both intake from the sides and exhaust out the back. Actually, the EX3200 has intakes on both sides, the EX4200 only on one side. Using a very low-tech method for measuring air flow (my hand and a small strip of paper), it really seems like the EX3200 has better air flow than it's big brother. The removable fan assembly on the 4200 is barely moving any air. The Power supply fan on the 4200 has higher air flow, but the overall flow seems to be much less than the 3200. Has anyone experienced heat issues with these? Thanks, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD Logged into reality and abusing my sudo priviledges ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Clustering - IPv6
I just happened to be looking at the 10.2 release notes after seeing your email. "IPv6 Support [snip] * Chassis cluster—In JUNOS Release 10.2, we support chassis cluster in an active-passive (failover) deployment. [Junos OS Security Configuration Guide]" You may want to have a closer look at the 10.2 documentation (the current recommended release for SRXs). I am not using this feature so I have no personal experience whether it actually works. On 11/2/2010 at 10:43 AM, "Paul Stewart" wrote: > Hi there. > > > > We are looking to bring on an additional SRX650 at a site by clustering. > One of the requirements though is IPv6 traffic and it appears it's not > supported? > > > > From > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c > ollections/release-notes/10/topic-39007.html : > > > > Chassis Cluster > > On SRX Series and J Series devices, the following features are not supported > when chassis clustering is enabled on the device: > > * All packet-based protocols, such as MPLS, Connectionless Network > Service (CLNS), and IP version 6 (IPv6) > > > > > > > > Do any of the SRX boxes support clustering with IPv6? Is there any timeline > on this being fixed that anyone knows of? > > > > Our goal is redundant routing engines should something happen - makes more > $$$ sense to add an additional SRX650 when there is one existing.. > > > > Thanks in advance, > > > > Paul > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX310 PPPoE and multiple Virtual-rout ers
There should be a loopback with a valid ipv4/ipv6 address. This address is used as unnumbered source for _any_ created pppoe subinterface. Kimd regards, Hendrik Am 02.11.2010 um 18:52 schrieb Tom Teeuwen : > Hello Hendrik, > > Thnx, it works !! > > The local-interface loopback, the IP-adres.. .does it matters ? > > Kind regards, > Tom > > > > > Van: juniper-nsp-boun...@puck.nether.net > [juniper-nsp-boun...@puck.nether.net] namens Hendrik Kahmann > [hendrik.kahm...@ewetel.de] > Verzonden: dinsdag 2 november 2010 8:07 > Aan: Diogo Montagner; juniper-nsp@puck.nether.net > Onderwerp: Re: [j-nsp] ERX310 PPPoE and multiple Virtual-routers > > Hello, > > as far as i know, this might be your solution: > > aaa domain-map "ABC" > router-name "ABC" > local-interface loopback 101 > ipv6-router-name default > strip-domain enable > ! > aaa domain-map "DEF" > router-name "DEF" > local-interface loopback 102 > ipv6-router-name default > strip-domain enable > ! > profile pppoe-defaults > ip mtu 1492 > ip sa-validate > ip tcp adjust-mss 1400 > ppp authentication pap > ! > interface gigabitEthernet 1/0.10 > vlan id 10 > pppoe > pppoe auto-configure > pppoe remote-circuit-id > pppoe profile any pppoe-defaults > ! > interface gigabitEthernet 1/0.20 > vlan id 20 > pppoe > pppoe auto-configure > pppoe remote-circuit-id > pppoe profile any pppoe-defaults > ! > > Users would be j...@abc or j...@def > > > Kind regards, > > Hendrik > > > Am 02.11.2010 05:23, schrieb Diogo Montagner: >> AFAIK, you need different subinterfaces for each virtual-router. >> >> Eg.: >> >> Vlan 10 - VR ABC >> Vlan 20 - VR DEF >> ... >> >> Rgs >> >> On 11/2/10, Tom Teeuwen wrote: >>> Hello, >>> >>> >>> >>> I'm configuring an ERX310 for PPPoE termination. >>> >>> From the all DSLAM's we get about 190 tagged VLAN's. >>> >>> So for every VLAN i need to create a subinterface. >>> >>> >>> >>> Now we want to create multiple virtual-routers for customers who want to get >>> an VPN. >>> >>> In the basic setup without VR's(only the default) i have a profile bounded >>> to an subinterface. >>> >>> The profile config: >>> >>> profile Test >>> ip unnumbered gigabitEthernet 1/1.102 >>> ppp authentication virtual-router default pap >>> >>> >>> >>> Now I created a VR and a domain-map and mapped a domain to the VR >>> >>> But the PPPoE request is comming from the same subinterface as above >>> specified (where i attached a profile to the subinterface) >>> >>> Problem is that I only can attach one profile to a subinterface. >>> >>> I want the following: >>> >>> - based on a domain attach the PPPoE session to a specific VR >>> >>> - PPPoE request can come from different subinterfaces >>> >>> >>> >>> Example: >>> >>> Customer 1 form subif 1 to VR-A >>> >>> Customer 2 from subif 1 to VR-B >>> >>> Customer 3 from subif 2 to VR-A >>> >>> Customer 4 from subif 2 to VR-B >>> >>> >>> >>> Kind regards, >>> >>> Tom >>> ___ >>> juniper-nsp mailing list juniper-nsp@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/juniper-nsp >>> > > > -- > Hendrik Kahmann > B.Sc. Wirtschaftsinformatik > > Planung - Technische Produktentwicklung > Telefon: +49 441 8000 2778 > > mailto:hendrik.kahm...@ewetel.de > > ___ > > EWE TEL GmbH > Cloppenburger Straße 310 > 26133 Oldenburg > > Handelsregister Amtsgericht Oldenburg HRB 3723 > Vorsitzender des Aufsichtsrates: Dr. Werner Brinker > Geschäftsführung: Hans-Joachim Iken (Vorsitzender), > Ulf Heggenberger, Dr. Norbert Schulz, Dirk Thole > > Homepage: http://www.ewetel.de > > ___ > > ___ > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX310 PPPoE and multiple Virtual-rout ers
Hello Hendrik, Thnx, it works !! The local-interface loopback, the IP-adres.. .does it matters ? Kind regards, Tom Van: juniper-nsp-boun...@puck.nether.net [juniper-nsp-boun...@puck.nether.net] namens Hendrik Kahmann [hendrik.kahm...@ewetel.de] Verzonden: dinsdag 2 november 2010 8:07 Aan: Diogo Montagner; juniper-nsp@puck.nether.net Onderwerp: Re: [j-nsp] ERX310 PPPoE and multiple Virtual-routers Hello, as far as i know, this might be your solution: aaa domain-map "ABC" router-name "ABC" local-interface loopback 101 ipv6-router-name default strip-domain enable ! aaa domain-map "DEF" router-name "DEF" local-interface loopback 102 ipv6-router-name default strip-domain enable ! profile pppoe-defaults ip mtu 1492 ip sa-validate ip tcp adjust-mss 1400 ppp authentication pap ! interface gigabitEthernet 1/0.10 vlan id 10 pppoe pppoe auto-configure pppoe remote-circuit-id pppoe profile any pppoe-defaults ! interface gigabitEthernet 1/0.20 vlan id 20 pppoe pppoe auto-configure pppoe remote-circuit-id pppoe profile any pppoe-defaults ! Users would be j...@abc or j...@def Kind regards, Hendrik Am 02.11.2010 05:23, schrieb Diogo Montagner: > AFAIK, you need different subinterfaces for each virtual-router. > > Eg.: > > Vlan 10 - VR ABC > Vlan 20 - VR DEF > ... > > Rgs > > On 11/2/10, Tom Teeuwen wrote: >> Hello, >> >> >> >> I'm configuring an ERX310 for PPPoE termination. >> >> From the all DSLAM's we get about 190 tagged VLAN's. >> >> So for every VLAN i need to create a subinterface. >> >> >> >> Now we want to create multiple virtual-routers for customers who want to get >> an VPN. >> >> In the basic setup without VR's(only the default) i have a profile bounded >> to an subinterface. >> >> The profile config: >> >> profile Test >> ip unnumbered gigabitEthernet 1/1.102 >> ppp authentication virtual-router default pap >> >> >> >> Now I created a VR and a domain-map and mapped a domain to the VR >> >> But the PPPoE request is comming from the same subinterface as above >> specified (where i attached a profile to the subinterface) >> >> Problem is that I only can attach one profile to a subinterface. >> >> I want the following: >> >> - based on a domain attach the PPPoE session to a specific VR >> >> - PPPoE request can come from different subinterfaces >> >> >> >> Example: >> >> Customer 1 form subif 1 to VR-A >> >> Customer 2 from subif 1 to VR-B >> >> Customer 3 from subif 2 to VR-A >> >> Customer 4 from subif 2 to VR-B >> >> >> >> Kind regards, >> >> Tom >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> -- Hendrik Kahmann B.Sc. Wirtschaftsinformatik Planung - Technische Produktentwicklung Telefon: +49 441 8000 2778 mailto:hendrik.kahm...@ewetel.de ___ EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Hans-Joachim Iken (Vorsitzender), Ulf Heggenberger, Dr. Norbert Schulz, Dirk Thole Homepage: http://www.ewetel.de ___ ___ 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
[j-nsp] SRX650 Clustering - IPv6
Hi there. We are looking to bring on an additional SRX650 at a site by clustering. One of the requirements though is IPv6 traffic and it appears it's not supported? From http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-c ollections/release-notes/10/topic-39007.html : Chassis Cluster On SRX Series and J Series devices, the following features are not supported when chassis clustering is enabled on the device: * All packet-based protocols, such as MPLS, Connectionless Network Service (CLNS), and IP version 6 (IPv6) Do any of the SRX boxes support clustering with IPv6? Is there any timeline on this being fixed that anyone knows of? Our goal is redundant routing engines should something happen - makes more $$$ sense to add an additional SRX650 when there is one existing.. Thanks in advance, Paul ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Radius Tunnel Switching
Hey, I'm attempting to dynamically tunnel switch some of our users. The requirement is that the tunnel is initiated from a different virtual router and it appears that the radius attribute that I'm using simply doesn't work. t...@teksavvy.com Cleartext-Password := "test123" Tunnel-Medium-Type := IP, Tunnel-Type := L2TP, ERX-Tunnel-Virtual-Router := "mlppp", Tunnel-Password := "", Tunnel-Server-Endpoint := 206.248.155.212, Auth-Type := Accept Everything above works, except for the ERX-Tunnel-Virtual-Router attribute. Here is what my ERX is seeing bsr1.tor2:pppoe#test aaa ppp t...@teksavvy.com test123 Authentication Grant with Tunnel Attributes user attributes * idle Timeout - 0 session Timeout - 0 accounting Timeout - 21600 Tunnel Set - 1 Tunnel Tag set - 0 Tunnel Type set - 3 Tunnel Medium set - 1 Tunnel peer set - 206.248.155.212 Tunnel Password set - Tunnel Router context - pppoe Tunnel calling number - atm 2/0.42:100.167#184549476#this is a What am I doing wrong? -Gabe ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] (no subject)
___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX310 PPPoE and multiple Virtual-rout ers
Hello, as far as i know, this might be your solution: aaa domain-map "ABC" router-name "ABC" local-interface loopback 101 ipv6-router-name default strip-domain enable ! aaa domain-map "DEF" router-name "DEF" local-interface loopback 102 ipv6-router-name default strip-domain enable ! profile pppoe-defaults ip mtu 1492 ip sa-validate ip tcp adjust-mss 1400 ppp authentication pap ! interface gigabitEthernet 1/0.10 vlan id 10 pppoe pppoe auto-configure pppoe remote-circuit-id pppoe profile any pppoe-defaults ! interface gigabitEthernet 1/0.20 vlan id 20 pppoe pppoe auto-configure pppoe remote-circuit-id pppoe profile any pppoe-defaults ! Users would be j...@abc or j...@def Kind regards, Hendrik Am 02.11.2010 05:23, schrieb Diogo Montagner: AFAIK, you need different subinterfaces for each virtual-router. Eg.: Vlan 10 - VR ABC Vlan 20 - VR DEF ... Rgs On 11/2/10, Tom Teeuwen wrote: Hello, I'm configuring an ERX310 for PPPoE termination. From the all DSLAM's we get about 190 tagged VLAN's. So for every VLAN i need to create a subinterface. Now we want to create multiple virtual-routers for customers who want to get an VPN. In the basic setup without VR's(only the default) i have a profile bounded to an subinterface. The profile config: profile Test ip unnumbered gigabitEthernet 1/1.102 ppp authentication virtual-router default pap Now I created a VR and a domain-map and mapped a domain to the VR But the PPPoE request is comming from the same subinterface as above specified (where i attached a profile to the subinterface) Problem is that I only can attach one profile to a subinterface. I want the following: - based on a domain attach the PPPoE session to a specific VR - PPPoE request can come from different subinterfaces Example: Customer 1 form subif 1 to VR-A Customer 2 from subif 1 to VR-B Customer 3 from subif 2 to VR-A Customer 4 from subif 2 to VR-B Kind regards, Tom ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Hendrik Kahmann B.Sc. Wirtschaftsinformatik Planung - Technische Produktentwicklung Telefon: +49 441 8000 2778 mailto:hendrik.kahm...@ewetel.de ___ EWE TEL GmbH Cloppenburger Straße 310 26133 Oldenburg Handelsregister Amtsgericht Oldenburg HRB 3723 Vorsitzender des Aufsichtsrates: Dr. Werner Brinker Geschäftsführung: Hans-Joachim Iken (Vorsitzender), Ulf Heggenberger, Dr. Norbert Schulz, Dirk Thole Homepage: http://www.ewetel.de ___ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
