Re: [j-nsp] Tower top switch/router recommendation..
I would have to look into it, but you should be able to set a max
bandwidth/transmit under cos then use filters + policers per customer.
-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 5:49 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
Hi Doug,
Thanks for responding..
I need to be able to do something like this;
Customer BW Pool of 20 Mbps up and down
Customer A, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available
Customer B, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available..
If both customers attempt 15 Mbps at the same time, the switch should give
each 10 Mbps..
Easy to do in HTB using RATE= and CEIL= statements, but I can't figure out
how to do it in JunOS..
Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 5:13 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
Maybe someone else can chime in, as I'm not an expert with MIR.
Junos policers use the token bucket algorithm and allow you to configure a
bandwidth-limit and burst-size-limit.
You can create firewall filters to match traffic and apply these filters as
coarse or as granular as you need.
Here's an example of a 1m policer:
policer 1m {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 125k;
}
then discard;
Doug
-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 4:43 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
It seems like on the EX platform, I would need each customer in a separate
VLAN for this to work (All customers on one port are on the same VLAN, and
only split by subnets).. Also don't see how one goes about setting up a
MIR.. CIR seems straight forward..
Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 4:29 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do
this, although is requires an advanced license for BGP (EX-48-AFL).
CoS is pretty much the same for all Junos devices. Take a look at the
technical documentation for the EX and CoS.
http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway
-pages/ex-series/cos.html
[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf
Doug
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..
I'm wondering if this is something that could be done with Junipers;
On our mountain top sites, we currently have dual 48 port POE switches, and
dual Dell 1950's running Quagga/Zebra routing suites..
The sites support wimax access points and redundant microwave backhauls to
other towers or our data centers..
OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route
failover..
Each access point (one per port on the switch) can have up to 75 customers
on them, and we use HTB on Linux to apply CIR and MIR rules to each customer
at a subnet level..
Over the years, this solution has proven to be reliable, and surprisingly
high performance, but as traffic volumes to the towers grow with
next-generation products, we are starting to push 400-600 Mbps to the
towers. Additionally, it's a bit of a pain to rebuild failed linux routers
in the field, or replace power supplies, hard drives, etc..
So, I'm looking for some form of stacking router/switch solution that could
handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by
customer subnet (they are all on the same interface and vlan)/and tcpdump
for easy debug of customer connectivity problems..
Possible with Juniper? Is so, what device, and what QOS rules?
Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
___
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] Tower top switch/router recommendation..
Hi Doug,
Thanks for responding..
I need to be able to do something like this;
Customer BW Pool of 20 Mbps up and down
Customer A, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available
Customer B, 5 Mbps committed information rate CIR, burstable to 15
Mbps as long as resources are available..
If both customers attempt 15 Mbps at the same time, the switch should give
each 10 Mbps..
Easy to do in HTB using RATE= and CEIL= statements, but I can't figure out
how to do it in JunOS..
Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 5:13 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
Maybe someone else can chime in, as I'm not an expert with MIR.
Junos policers use the token bucket algorithm and allow you to configure a
bandwidth-limit and burst-size-limit.
You can create firewall filters to match traffic and apply these filters as
coarse or as granular as you need.
Here's an example of a 1m policer:
policer 1m {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 125k;
}
then discard;
Doug
-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 4:43 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
It seems like on the EX platform, I would need each customer in a separate
VLAN for this to work (All customers on one port are on the same VLAN, and
only split by subnets).. Also don't see how one goes about setting up a
MIR.. CIR seems straight forward..
Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 4:29 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do
this, although is requires an advanced license for BGP (EX-48-AFL).
CoS is pretty much the same for all Junos devices. Take a look at the
technical documentation for the EX and CoS.
http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway
-pages/ex-series/cos.html
[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf
Doug
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..
I'm wondering if this is something that could be done with Junipers;
On our mountain top sites, we currently have dual 48 port POE switches, and
dual Dell 1950's running Quagga/Zebra routing suites..
The sites support wimax access points and redundant microwave backhauls to
other towers or our data centers..
OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route
failover..
Each access point (one per port on the switch) can have up to 75 customers
on them, and we use HTB on Linux to apply CIR and MIR rules to each customer
at a subnet level..
Over the years, this solution has proven to be reliable, and surprisingly
high performance, but as traffic volumes to the towers grow with
next-generation products, we are starting to push 400-600 Mbps to the
towers. Additionally, it's a bit of a pain to rebuild failed linux routers
in the field, or replace power supplies, hard drives, etc..
So, I'm looking for some form of stacking router/switch solution that could
handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by
customer subnet (they are all on the same interface and vlan)/and tcpdump
for easy debug of customer connectivity problems..
Possible with Juniper? Is so, what device, and what QOS rules?
Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
___
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 Failover Test Issue
Sounds like the interface did not put into group, and should use fxp0 ip instead Regards -mike On Mar 22, 2011, at 12:05, Pavel Lunin wrote: >> >> While testing the failover in SRX650 cluster. I have removed the control >> link between the primary and secondary. The secondary node went to >> ineligible mode. The secondry FW is still accessible through OoB >> interface. When I returned back the control link I couldn't reach the FW >> through OoB interface "ge-0/0/0". The only way to access the box is >> through console and found the secondary firewall is in disable mode. >> Then when I rebooted the whole firewall, it worked normally. Is it >> normal? And how to reach the secondary firewall remotely in case of >> control link flap? I have faced the same issue when removing the fab >> link. >> >> >> > Looks like a routing issue. Try to check it out with "show route a.b.c.d" > command, when you access the disabled box through the console port, where > a.b.c.d is IP address of the machine, you are trying to get remote access > form. Most probably it will show you something different from a route > pointing through fxp0. If this is the case, you need to configure a backup > router, which would make the disabled node (which does not run rpd) to route > packets to the management station through fxp0. > > http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-system-basics/backup-router-configuring.html > > BTW, next time you want the public to guess the solution for your issue, try > to be a bit more informative in providing basic troubleshooting details. E. > g. instead of just saying "I couldn't reach the FW through OoB interface > "ge-0/0/0"", it would've been better to say something like "I checked the > whole path from my machine a.b.c.d/24 to the fxp0 interface of the node1, > which has address w.x.y.z/24 and… I see the packets coming to the > penultimate hop router, but the FW's fxp0 interface, which is the next and > last hop, does [not] respond to ARP requests… Than I tried to ping my > machine back from the FW with "ping a.b.c.d interface fxp0", and got the > following output… than I performed a traceroute… I checked what comes to the > fxp0 interface with "monitor traffic interface fxp0" and saw…", etc. > > Otherwise, I'm afraid, this sort of gambling-style troubleshooting, in which > you ask us to help you, will not be much effective anyway. Monte-Carlo is a > good method but it's too slow in convergence. > > -- > Pavel > ___ > 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] Tower top switch/router recommendation..
Maybe someone else can chime in, as I'm not an expert with MIR.
Junos policers use the token bucket algorithm and allow you to configure a
bandwidth-limit and burst-size-limit.
You can create firewall filters to match traffic and apply these filters as
coarse or as granular as you need.
Here's an example of a 1m policer:
policer 1m {
if-exceeding {
bandwidth-limit 1m;
burst-size-limit 125k;
}
then discard;
Doug
-Original Message-
From: Peter Kranz [mailto:pkr...@unwiredltd.com]
Sent: Tuesday, March 22, 2011 4:43 PM
To: Doug Hanks; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
It seems like on the EX platform, I would need each customer in a separate
VLAN for this to work (All customers on one port are on the same VLAN, and
only split by subnets).. Also don't see how one goes about setting up a
MIR.. CIR seems straight forward..
Peter Kranz
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
-Original Message-
From: Doug Hanks [mailto:dha...@juniper.net]
Sent: Tuesday, March 22, 2011 4:29 PM
To: Peter Kranz; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] Tower top switch/router recommendation..
The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do
this, although is requires an advanced license for BGP (EX-48-AFL).
CoS is pretty much the same for all Junos devices. Take a look at the
technical documentation for the EX and CoS.
http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway
-pages/ex-series/cos.html
[1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf
Doug
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz
Sent: Tuesday, March 22, 2011 3:20 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Tower top switch/router recommendation..
I'm wondering if this is something that could be done with Junipers;
On our mountain top sites, we currently have dual 48 port POE switches, and
dual Dell 1950's running Quagga/Zebra routing suites..
The sites support wimax access points and redundant microwave backhauls to
other towers or our data centers..
OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route
failover..
Each access point (one per port on the switch) can have up to 75 customers
on them, and we use HTB on Linux to apply CIR and MIR rules to each customer
at a subnet level..
Over the years, this solution has proven to be reliable, and surprisingly
high performance, but as traffic volumes to the towers grow with
next-generation products, we are starting to push 400-600 Mbps to the
towers. Additionally, it's a bit of a pain to rebuild failed linux routers
in the field, or replace power supplies, hard drives, etc..
So, I'm looking for some form of stacking router/switch solution that could
handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by
customer subnet (they are all on the same interface and vlan)/and tcpdump
for easy debug of customer connectivity problems..
Possible with Juniper? Is so, what device, and what QOS rules?
Peter Kranz
Founder/CEO - Unwired Ltd
www.UnwiredLtd.com
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com
___
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] Tower top switch/router recommendation..
It seems like on the EX platform, I would need each customer in a separate VLAN for this to work (All customers on one port are on the same VLAN, and only split by subnets).. Also don't see how one goes about setting up a MIR.. CIR seems straight forward.. Peter Kranz www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207- pkr...@unwiredltd.com -Original Message- From: Doug Hanks [mailto:dha...@juniper.net] Sent: Tuesday, March 22, 2011 4:29 PM To: Peter Kranz; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] Tower top switch/router recommendation.. The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do this, although is requires an advanced license for BGP (EX-48-AFL). CoS is pretty much the same for all Junos devices. Take a look at the technical documentation for the EX and CoS. http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway -pages/ex-series/cos.html [1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf Doug -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz Sent: Tuesday, March 22, 2011 3:20 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Tower top switch/router recommendation.. I'm wondering if this is something that could be done with Junipers; On our mountain top sites, we currently have dual 48 port POE switches, and dual Dell 1950's running Quagga/Zebra routing suites.. The sites support wimax access points and redundant microwave backhauls to other towers or our data centers.. OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route failover.. Each access point (one per port on the switch) can have up to 75 customers on them, and we use HTB on Linux to apply CIR and MIR rules to each customer at a subnet level.. Over the years, this solution has proven to be reliable, and surprisingly high performance, but as traffic volumes to the towers grow with next-generation products, we are starting to push 400-600 Mbps to the towers. Additionally, it's a bit of a pain to rebuild failed linux routers in the field, or replace power supplies, hard drives, etc.. So, I'm looking for some form of stacking router/switch solution that could handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by customer subnet (they are all on the same interface and vlan)/and tcpdump for easy debug of customer connectivity problems.. Possible with Juniper? Is so, what device, and what QOS rules? Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207- pkr...@unwiredltd.com ___ 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] Tower top switch/router recommendation..
The EX4200-48P - supports virtual-chassis[1] - or the EX3200-48P can do this, although is requires an advanced license for BGP (EX-48-AFL). CoS is pretty much the same for all Junos devices. Take a look at the technical documentation for the EX and CoS. http://www.juniper.net/techpubs/en_US/junos10.4/information-products/pathway-pages/ex-series/cos.html [1] http://www.juniper.net/us/en/local/pdf/datasheets/1000215-en.pdf Doug -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Peter Kranz Sent: Tuesday, March 22, 2011 3:20 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Tower top switch/router recommendation.. I'm wondering if this is something that could be done with Junipers; On our mountain top sites, we currently have dual 48 port POE switches, and dual Dell 1950's running Quagga/Zebra routing suites.. The sites support wimax access points and redundant microwave backhauls to other towers or our data centers.. OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route failover.. Each access point (one per port on the switch) can have up to 75 customers on them, and we use HTB on Linux to apply CIR and MIR rules to each customer at a subnet level.. Over the years, this solution has proven to be reliable, and surprisingly high performance, but as traffic volumes to the towers grow with next-generation products, we are starting to push 400-600 Mbps to the towers. Additionally, it's a bit of a pain to rebuild failed linux routers in the field, or replace power supplies, hard drives, etc.. So, I'm looking for some form of stacking router/switch solution that could handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by customer subnet (they are all on the same interface and vlan)/and tcpdump for easy debug of customer connectivity problems.. Possible with Juniper? Is so, what device, and what QOS rules? Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207- pkr...@unwiredltd.com ___ 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] about 10.4R3 on EX
On Tue, Mar 22, 2011 at 03:46:36PM -0500, Richard A Steenbergen wrote: > The process of upgrading to a resilient dual-root partitions release > takes longer due to the additional step of upgrading the loader software > and a longer reboot time while the disk is reformattedto four partitions > during the reboot of the switch that completes the Junos OS upgrade. The > reformat increases the reboot time for EX2200, EX3200, EX4200, and > EX4500 switches by 5 to 10 minutes. For EX8200 switches, the reboot time > increases by 10 to 25 minutes per Routing Engine, and additional reboots > are required. Also, in reading the upgrade process for the new boot loader, it says: For an EX8200 switch with redundant Routing Engines, you must upgrade the loader software on both Routing Engines. You can upgrade the loader software on a Routing Engine only when it is master. Make sure that graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) are disabled before you begin the upgrade. The requirement that you can only upgrade it when the RE is the master is a pretty serious issue. This means you can't just pre-stage the upgrade on the backup RE and then switch over to it in a single move, you've got to take down the entire device for the duration of multiple reloads (4 apparently, 2 per RE * 2 REs) to complete the upgrade. Is there some other interpretation of this that I'm missing? From my quick lab testing it looks like you can at least get the jinstall and 25 minute reformatting out of the way beforehand, but you've still got to be master to upgrade the actual loader. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Tower top switch/router recommendation..
I'm wondering if this is something that could be done with Junipers; On our mountain top sites, we currently have dual 48 port POE switches, and dual Dell 1950's running Quagga/Zebra routing suites.. The sites support wimax access points and redundant microwave backhauls to other towers or our data centers.. OSPF/BGP is used to mesh the sites with Quagga/Zebra handling the route failover.. Each access point (one per port on the switch) can have up to 75 customers on them, and we use HTB on Linux to apply CIR and MIR rules to each customer at a subnet level.. Over the years, this solution has proven to be reliable, and surprisingly high performance, but as traffic volumes to the towers grow with next-generation products, we are starting to push 400-600 Mbps to the towers. Additionally, it's a bit of a pain to rebuild failed linux routers in the field, or replace power supplies, hard drives, etc.. So, I'm looking for some form of stacking router/switch solution that could handle BGP/OSPF/~75 MIR and CIR rules per interface with enforcement by customer subnet (they are all on the same interface and vlan)/and tcpdump for easy debug of customer connectivity problems.. Possible with Juniper? Is so, what device, and what QOS rules? Peter Kranz Founder/CEO - Unwired Ltd www.UnwiredLtd.com Desk: 510-868-1614 x100 Mobile: 510-207- pkr...@unwiredltd.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4200 BPDU on access port
This is perfectly normal spanning-tree behaviour - if edge ports didn't send BPDUs and you looped a cable between two edge ports then broadcast storm hilarity would ensue. If you want to stop this from occurring (and have a good understanding of the implications of doing this between two switches), disable RSTP on the interface: set protocols rstp interface ge-0/0/0 disable If you're just trying to keep your RSTP topology separate but want to keep the protection mechanisms in place, use root-guard: set protocols rstp interface ge-0/0/0.0 mode point-to-point set protocols rstp interface ge-0/0/0.0 no-root-port If you're carrying traffic for your customer from one site to another (Q-in-Q) and they need their spanning-tree topology maintained transparently across your network, then you'll need to use dot1q-tunneling: set vlans CUST-A-OUTER dot1q-tunneling layer2-protocol-tunneling stp set vlans CUST-A-OUTER dot1q-tunneling layer2-protocol-tunneling vstp On 23/03/2011, at 8:10 AM, Pavel Dimow wrote: > Hi, > > I have strange situation where my customer receives bpdu's on his > cisco switch from my ex4200 despite the fact that I have configured my > port as access (default in JUNOS) > and as edge on rstp configuration. Is this normal or I don't have luck > with 10.3 version? > ___ > 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] EX4200 BPDU on access port
All the edge knob does is transition the port directly to the FWD state.
{master:0}[edit]
dhanks@EX4500-2# run show spanning-tree interface xe-0/0/38
Spanning tree interface parameters for instance 0
InterfacePort IDDesignated Designated PortState Role
port IDbridge ID Cost
xe-0/0/38.0128:551 128:551 32768.50c58ea24540 2000 FWDROOT
{master:0}[edit]
dhanks@EX4500-2# set protocols rstp interface xe-0/0/38 edge
{master:0}[edit]
dhanks@EX4500-2# commit
configuration check succeeds commit complete
{master:0}[edit]
dhanks@EX4500-2# run show spanning-tree interface xe-0/0/38
Spanning tree interface parameters for instance 0
InterfacePort IDDesignated Designated PortState Role
port IDbridge ID Cost
xe-0/0/38.0128:551 128:551 32768.50c58ea24540 2000 FWDROOT
{master:0}[edit]
dhanks@EX4500-2#
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Pavel Dimow
Sent: Tuesday, March 22, 2011 3:11 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] EX4200 BPDU on access port
Hi,
I have strange situation where my customer receives bpdu's on his
cisco switch from my ex4200 despite the fact that I have configured my
port as access (default in JUNOS)
and as edge on rstp configuration. Is this normal or I don't have luck
with 10.3 version?
___
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] about 10.4R3 on EX
Another feature of the dual root partition is that it will allow you to switch between software versions using "request system software rollback" without reinstalling the image. Don't forget in production to keep both the partitions in sync with "request system snapshot slice" You can check to see what versions are installed on each partition with "show system snapshot media internal" Doug -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Doug Hanks Sent: Tuesday, March 22, 2011 2:45 PM To: t...@muppetz.com; Kaj Niemi Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] about 10.4R3 on EX Yes the resilient dual root partition was implemented to deal with this issue on the EX. I believe this is pretty similar to what the branch SRX do today. Doug -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of TiM Sent: Tuesday, March 22, 2011 1:15 PM To: Kaj Niemi Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] about 10.4R3 on EX On Wed, March 23, 2011 8:54 am, Kaj Niemi wrote: > Hi, > > > To whomever who decided to introduce new features in a R3 release, thanks > ;-( Specifically installing jloader separately is highly appreciated. > You'll probably be thanking them when your switch loses power* and when you restore it, you find your bootable filesystem isn't corrupted. At least I'm _hoping_ that's what this 4th partition is designed to fix. Context: http://www.gossamer-threads.com/lists/nsp/juniper/25513 Tim *Yes, I know you should have a working UPS etc. ___ 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
[j-nsp] EX4200 BPDU on access port
Hi, I have strange situation where my customer receives bpdu's on his cisco switch from my ex4200 despite the fact that I have configured my port as access (default in JUNOS) and as edge on rstp configuration. Is this normal or I don't have luck with 10.3 version? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
Yes the resilient dual root partition was implemented to deal with this issue on the EX. I believe this is pretty similar to what the branch SRX do today. Doug -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of TiM Sent: Tuesday, March 22, 2011 1:15 PM To: Kaj Niemi Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] about 10.4R3 on EX On Wed, March 23, 2011 8:54 am, Kaj Niemi wrote: > Hi, > > > To whomever who decided to introduce new features in a R3 release, thanks > ;-( Specifically installing jloader separately is highly appreciated. > You'll probably be thanking them when your switch loses power* and when you restore it, you find your bootable filesystem isn't corrupted. At least I'm _hoping_ that's what this 4th partition is designed to fix. Context: http://www.gossamer-threads.com/lists/nsp/juniper/25513 Tim *Yes, I know you should have a working UPS etc. ___ 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] snmp fan bug? and are environmental thresholds configurable?
Hi, On Sun, Mar 20, 2011 at 9:50 PM, bas wrote: > > We have a bunch of mx480's running either 10.3r3 and 10.4r2 > About 20 times a day the fans in these boxes switch from normal speed > to intermediate speed. Sorry for hijacking your thread, but do you (or does anyone) know why the fan speed changes like this? I've noticed on EX-series, the fans go from 'spinning at normal speed' to 'spinning at high speed' on a regular schedule even when the ambient temperature hasn't significantly changed and the box isn't doing much in particular. We've got some EX2200 switches in physical spaces where the jet engine-like noise the EX4200 generates isn't desirable. Unfortunately the EX2200s make quite a racket when their fans spin at high speed as well. Cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
Hi, On Wed, Mar 23, 2011 at 7:48 AM, Kaj Niemi wrote: > It took 838 seconds on a 2 member EX4200 VC bundle. Yes, I did time it. ;-) That does sound a bit painful, but not as painful as the file system corruption this feature aims to fix. I wonder what happened to the idea of implementing NANDFS? Cheers, Dale (..looking forward to putting 10.4R3 in the lab.) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] netflow collector on linux
flow-tools On 2011-03-22, at 2:03 PM, Michael Lee wrote: > Hello: > > I am trying to eval netflow collector for multi-vendor hardwares, anyone > could suggest any good commercial netflow collector running on Linux? > > Thanks, > > ~mike > ___ > 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] about 10.4R3 on EX
On Tue, Mar 22, 2011 at 3:54 PM, Kaj Niemi wrote: > Hi, > > > To whomever who decided to introduce new features in a R3 release, thanks > ;-( Specifically installing jloader separately is highly appreciated. > > > > I think they've begun outsourcing their dev to microsoft. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
On Wed, March 23, 2011 8:54 am, Kaj Niemi wrote: > Hi, > > > To whomever who decided to introduce new features in a R3 release, thanks > ;-( Specifically installing jloader separately is highly appreciated. > You'll probably be thanking them when your switch loses power* and when you restore it, you find your bootable filesystem isn't corrupted. At least I'm _hoping_ that's what this 4th partition is designed to fix. Context: http://www.gossamer-threads.com/lists/nsp/juniper/25513 Tim *Yes, I know you should have a working UPS etc. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
It took 838 seconds on a 2 member EX4200 VC bundle. Yes, I did time it. ;-) Kaj On 22/3/2011 22:46, "Richard A Steenbergen" wrote: >On Tue, Mar 22, 2011 at 12:54:25PM -0700, Kaj Niemi wrote: >> Hi, >> >> >> To whomever who decided to introduce new features in a R3 release, >>thanks >> ;-( Specifically installing jloader separately is highly appreciated. >> > >Sadly, they've been silently introducing new features in the middle of a >bug fix release (and introducing new bugs too, which is how I find out >about them) for a while now. But for extra bonus points, be prepared for >the upgrade to take a REALLY long time to complete too. :) > >From the release notes: > >How Long Will the Upgrade Process Take? > >The process of upgrading to a resilient dual-root partitions release >takes longer due to the additional step of upgrading the loader software >and a longer reboot time while the disk is reformattedto four partitions >during the reboot of the switch that completes the Junos OS upgrade. The >reformat increases the reboot time for EX2200, EX3200, EX4200, and >EX4500 switches by 5 to 10 minutes. For EX8200 switches, the reboot time >increases by 10 to 25 minutes per Routing Engine, and additional reboots >are required. > >-- >Richard A Steenbergenhttp://www.e-gerbil.net/ras >GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] about 10.4R3 on EX
On Tue, Mar 22, 2011 at 12:54:25PM -0700, Kaj Niemi wrote: > Hi, > > > To whomever who decided to introduce new features in a R3 release, thanks > ;-( Specifically installing jloader separately is highly appreciated. > Sadly, they've been silently introducing new features in the middle of a bug fix release (and introducing new bugs too, which is how I find out about them) for a while now. But for extra bonus points, be prepared for the upgrade to take a REALLY long time to complete too. :) >From the release notes: How Long Will the Upgrade Process Take? The process of upgrading to a resilient dual-root partitions release takes longer due to the additional step of upgrading the loader software and a longer reboot time while the disk is reformattedto four partitions during the reboot of the switch that completes the Junos OS upgrade. The reformat increases the reboot time for EX2200, EX3200, EX4200, and EX4500 switches by 5 to 10 minutes. For EX8200 switches, the reboot time increases by 10 to 25 minutes per Routing Engine, and additional reboots are required. -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] about 10.4R3 on EX
Hi, To whomever who decided to introduce new features in a R3 release, thanks ;-( Specifically installing jloader separately is highly appreciated. Kaj ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX650 Failover Test Issue
> > While testing the failover in SRX650 cluster. I have removed the control > link between the primary and secondary. The secondary node went to > ineligible mode. The secondry FW is still accessible through OoB > interface. When I returned back the control link I couldn't reach the FW > through OoB interface "ge-0/0/0". The only way to access the box is > through console and found the secondary firewall is in disable mode. > Then when I rebooted the whole firewall, it worked normally. Is it > normal? And how to reach the secondary firewall remotely in case of > control link flap? I have faced the same issue when removing the fab > link. > > > Looks like a routing issue. Try to check it out with "show route a.b.c.d" command, when you access the disabled box through the console port, where a.b.c.d is IP address of the machine, you are trying to get remote access form. Most probably it will show you something different from a route pointing through fxp0. If this is the case, you need to configure a backup router, which would make the disabled node (which does not run rpd) to route packets to the management station through fxp0. http://www.juniper.net/techpubs/en_US/junos10.0/information-products/topic-collections/config-guide-system-basics/backup-router-configuring.html BTW, next time you want the public to guess the solution for your issue, try to be a bit more informative in providing basic troubleshooting details. E. g. instead of just saying "I couldn't reach the FW through OoB interface "ge-0/0/0"", it would've been better to say something like "I checked the whole path from my machine a.b.c.d/24 to the fxp0 interface of the node1, which has address w.x.y.z/24 and… I see the packets coming to the penultimate hop router, but the FW's fxp0 interface, which is the next and last hop, does [not] respond to ARP requests… Than I tried to ping my machine back from the FW with "ping a.b.c.d interface fxp0", and got the following output… than I performed a traceroute… I checked what comes to the fxp0 interface with "monitor traffic interface fxp0" and saw…", etc. Otherwise, I'm afraid, this sort of gambling-style troubleshooting, in which you ask us to help you, will not be much effective anyway. Monte-Carlo is a good method but it's too slow in convergence. -- Pavel ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX650 Failover Test Issue
Hi Experts While testing the failover in SRX650 cluster. I have removed the control link between the primary and secondary. The secondary node went to ineligible mode. The secondry FW is still accessible through OoB interface. When I returned back the control link I couldn't reach the FW through OoB interface "ge-0/0/0". The only way to access the box is through console and found the secondary firewall is in disable mode. Then when I rebooted the whole firewall, it worked normally. Is it normal? And how to reach the secondary firewall remotely in case of control link flap? I have faced the same issue when removing the fab link. BR, ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote: > >From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as > the better choice, and people who talk to JTAC say 10.4r2 is the > better choice. Oh and btw, I have multiple confirmed reports of YET ANOTHER major memory leak in mib2d in 10.4R2. Hope everyone learned their lesson about trusting JTAC version recommendations. :) >From 10.4R3 release notes: The mib2d process leaks memory during SNMP walks. [PR/586074: This issue has been resolved.] I'm going to assume it's that. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] 10.0 or 10.4?
On Tue, Mar 22, 2011 at 05:18:47PM +0100, bas wrote: > Hi All, > > Well, after this thread I still didn't know which version I should > choose for our 960 with MPC's only. > >From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as > the better choice, and people who talk to JTAC say 10.4r2 is the > better choice. > > (Of course it depends on configuration and config.) > > But we chose to upgrade to 10.3r3, and installed the version this morning. > The upgrade seemed to have gone smooth, but after all BGP sessions had > been re-established, and prefixes re-learnt the CPU stayed at 100%. > > Dropping to shell I saw rpd consuming 99% CPU. > Looking at task accounting and rtsockmon I saw no obvious causes. > A failover to the backup RE had no effect, the new master RE consumed > 100% within a couple of minutes. > > A colleague of mine did a trace of the process saw that the cycles are > being consumed by "getrusage" system calls. > > Tomorrow morning we'll try to restart routing, if that has no effect > we will try 10.4r2. Haven't seen that here. Both 10.3R3 and 10.4R2 picked up a very similar set of fixes (they have very close release dates) for major PRs which were giving us grief, but 10.3R3 seemed to introduce less new ones in the process. 10.4R3 just came out yesterday, so feel free to give it a shot and report back, but most of our 10.3R3 issues have been relatively "less bad" than normal. Occasional logging of these junk messages: Mar 22 11:47:12.629 re1.xx1.xxx1 /kernel: %KERN-3: Unlist request: unilist(nh index = 1049538) found on the rnhlist_deleted_root patnode, hence returning Logging of these junk messages (note the incorrect timestamps too, these were actually logged AFTER the Mar 22 output above :P): Mar 4 10:29:50.527 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:07.860442 Mar 4 10:47:22.577 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:22.570405 Mar 4 10:55:44.479 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:21.765648 Mar 4 10:59:59.056 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:19.371199 Mar 4 11:02:04.228 re1.cr1.xxx1 rpd[89570]: %DAEMON-4: , hold timer 1:18.704278 Weird stuff like that. Probably the worst issue we've seen so far is that on MX w/MPC cards (not sure if its the sw or hw) doing an l2circuit to a vlan-ccc endpoint and then confusing vlan-maps to push/pop the vlan tag off of the packet before encapsulating in the pseudowire (so you can mismatch vlan IDs on the endpoints) seems to block ISIS packets from being transported (most likely blocking 802.3 LLC frames is my guess). On EX there is a definite problem with the power supplies getting stuck 110v "low power" mode as far as the chassis is concerned, which is an issue if you need 220v power to fully and redundantly power your FPCs. But at least this code hasn't crashed or blown up massively yet (or failed to do some really important operation like say correctly counting packets in SNMP so you can bill your customers), which is definitely an improvement over a lot of other recent JUNOS code. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] netflow collector on linux
Hello: I am trying to eval netflow collector for multi-vendor hardwares, anyone could suggest any good commercial netflow collector running on Linux? Thanks, ~mike ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SXR 650 Redundancy Group Problem
Thanks, the problem was in the router interface configuration that is facing
the firewall, now its working fine.
BR,
-Original Message-
From: ben b [mailto:benboyd.li...@gmail.com]
Sent: Monday, March 21, 2011 12:25 AM
To: Walaa Abdel razzak
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] SXR 650 Redundancy Group Problem
Try removing preempt. I've seen issues with preemption.
On Saturday, March 19, 2011, Walaa Abdel razzak wrote:
> Hi Experts
>
>
>
> I am configuring redundancy group to trigger failover in case of interface
> failure. I have reth interface for trust zone that has two physical
> interfaces, one interface on the active node and the other on the passive and
> the same for reth1 on untrust zone. The target is to make traffic go through
> the passive node in case of any physical interface failure in the active
> node. The problem I am facing is that the failover happen normally when any
> interface goes down but there is no traffic from trust to untrust or vice
> versa, when the down interface comes to up again, the traffic flows without
> problems.
>
>
>
> The RG configuration is as follows:
>
>
>
> test@FW1# show chassis
>
> cluster {
>
> reth-count 2;
>
> redundancy-group 0 {
>
> node 0 priority 100;
>
> node 1 priority 1;
>
> }
>
> redundancy-group 1 {
>
> node 0 priority 100;
>
> node 1 priority 1;
>
> preempt;
>
> gratuitous-arp-count 4;
>
> interface-monitor {
>
> ge-2/0/0 weight 255; à Interface on the active node
>
> ge-2/0/1 weight 255; à Interface on the active node
>
> }
>
> }
>
> }
>
>
>
> When the active interface goes down:
>
>
>
> Mar 20 03:43:51 FW1 jsrpd[1085]: JSRPD_RG_STATE_CHANGE:
> Redundancy-group 1 transitioned from 'primary' to 'secondary-hold'
> state due to Monitor failed: IF
>
> Mar 20 03:43:52 FW1 jsrpd[1085]: JSRPD_RG_STATE_CHANGE:
> Redundancy-group 1 transitioned from 'secondary-hold' to 'secondary'
> state due to Back to back failover interval expired
>
>
>
>
>
> Interface belonging to the reth:
>
>
>
> test@ FW1# show interfaces ge-2/0/0 à active node
>
> gigether-options {
>
> redundant-parent reth1;
>
> }
>
>
>
> {primary:node0}[edit]
>
> test@ FW1# show interfaces ge-2/0/1 à active node
>
> gigether-options {
>
> redundant-parent reth0;
>
> }
>
>
>
> {primary:node0}[edit]
>
> test@ FW1# show interfaces ge-11/0/0 à passive node
>
> gigether-options {
>
> redundant-parent reth1;
>
> }
>
>
>
> {primary:node0}[edit]
>
> test@ FW1# show interfaces ge-11/0/1 à passive node
>
> gigether-options {
>
> redundant-parent reth0;
>
> }
>
>
>
> test@FW1# run show interfaces terse | match reth
>
> ge-2/0/0.15 up down aenet --> reth1.15 à active
> interface down
>
> ge-2/0/0.20 up down aenet --> reth1.20
>
> ge-2/0/0.32767 up down aenet --> reth1.32767
>
> ge-2/0/1.5 up up aenet --> reth0.5
>
> ge-2/0/1.32767 up up aenet --> reth0.32767
>
> ge-11/0/0.15 up up aenet --> reth1.15
>
> ge-11/0/0.20 up up aenet --> reth1.20
>
> ge-11/0/0.32767 up up aenet --> reth1.32767
>
> ge-11/0/1.5 up up aenet --> reth0.5
>
> ge-11/0/1.32767 up up aenet --> reth0.32767
>
> reth0 up down
>
> reth0.5 up down inet 172.16.0.2/30
>
> reth0.32767 up down
>
> reth1 up down
>
> reth1.15 up down inet 192.168.0.2/30
>
> reth1.20 up down inet 192.168.1.2/30
>
> reth1.32767 up down
>
>
>
> Any suggestions?
>
>
>
> BR,
>
>
>
> ___
> 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] 10.0 or 10.4?
Hi All, Well, after this thread I still didn't know which version I should choose for our 960 with MPC's only. >From what I read it was; In the field (Ras, Raphael) we see 10.3r3 as the better choice, and people who talk to JTAC say 10.4r2 is the better choice. (Of course it depends on configuration and config.) But we chose to upgrade to 10.3r3, and installed the version this morning. The upgrade seemed to have gone smooth, but after all BGP sessions had been re-established, and prefixes re-learnt the CPU stayed at 100%. Dropping to shell I saw rpd consuming 99% CPU. Looking at task accounting and rtsockmon I saw no obvious causes. A failover to the backup RE had no effect, the new master RE consumed 100% within a couple of minutes. A colleague of mine did a trace of the process saw that the cycles are being consumed by "getrusage" system calls. Tomorrow morning we'll try to restart routing, if that has no effect we will try 10.4r2. I'll post tomorrow our findings.. Bas ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vpls and virtual switches (vlan-id none) not supported
If vlan tags are to be removed in VPLS PW how to demultiplex b/w bridge
domains in a virtual switch ?
Krasi
On Tue, Mar 22, 2011 at 1:28 PM, wrote:
> Hi there,
>
> I have the following issue:
>
> switch1--(ciscoPE)-(MX80)switch2
> switch3
>
> Switch1 is connected to a Cisco PE
> Switch2 and switch 2 are connected to a MX80 in the same bridge domain.
>
> The bridge-domain is configured in the virtual-switch and VPLS is
> activated.
>
> Now the problem is, previously when I did not needed bridging for VPLS
> (and this virtual-switches) I had enabled the command "vlan-id none" under
> the VPLS routing-instance.
>
> This command ensures that packets send over the VPLS cloud have their
> vlan-tag removed.This ensures interop with Cisco.
>
> Now with virtual switches this command is not supported. This means that
> the switches behind the MX have connectiviy but not towards the switch
> behind the Cisco PE.
>
> How can I resolve this issue?
>
> My config looks like:
>
> ge-1/0/0 {
>native-vlan-id 500;
>speed 100m;
>mtu 1504;
>unit 0 {
>family bridge {
>interface-mode trunk;
>vlan-id-list 500;
>}
>}
> }
> ge-1/0/1 {
>native-vlan-id 500;
>speed 100m;
>mtu 1504;
>unit 0 {
>family bridge {
>interface-mode trunk;
>vlan-id-list 500;
>}
>}
> }
>
> vpls1 {
>instance-type virtual-switch;
>interface ge-1/0/0.0;
>interface ge-1/0/1.0;
>protocols {
>vpls {
>no-tunnel-services;
>vpls-id 500;
>mtu 1600;
>neighbor 10.110.0.2;
> }
>}
>bridge-domains {
>vpls1 {
>domain-type bridge;
>vlan-id 500;
>}
>}
> }
>
>
> Thanks
>
> ___
> 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] vpls and virtual switches (vlan-id none) not supported
Hi there,
I have the following issue:
switch1--(ciscoPE)-(MX80)switch2
switch3
Switch1 is connected to a Cisco PE
Switch2 and switch 2 are connected to a MX80 in the same bridge domain.
The bridge-domain is configured in the virtual-switch and VPLS is activated.
Now the problem is, previously when I did not needed bridging for VPLS
(and this virtual-switches) I had enabled the command "vlan-id none" under
the VPLS routing-instance.
This command ensures that packets send over the VPLS cloud have their
vlan-tag removed.This ensures interop with Cisco.
Now with virtual switches this command is not supported. This means that
the switches behind the MX have connectiviy but not towards the switch
behind the Cisco PE.
How can I resolve this issue?
My config looks like:
ge-1/0/0 {
native-vlan-id 500;
speed 100m;
mtu 1504;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 500;
}
}
}
ge-1/0/1 {
native-vlan-id 500;
speed 100m;
mtu 1504;
unit 0 {
family bridge {
interface-mode trunk;
vlan-id-list 500;
}
}
}
vpls1 {
instance-type virtual-switch;
interface ge-1/0/0.0;
interface ge-1/0/1.0;
protocols {
vpls {
no-tunnel-services;
vpls-id 500;
mtu 1600;
neighbor 10.110.0.2;
}
}
bridge-domains {
vpls1 {
domain-type bridge;
vlan-id 500;
}
}
}
Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
