Re: [j-nsp] jtree0 Memory full on MX480?
Over the years, we have run into a couple of issues that translated to either
exhausting FPC memory or corrupting the JTree. Currently, life is good on
13.3R6, which we run on all MX's globally. I haven't run into this specific
issue, and I am just assuming that behavior is improved.
Best Regards,
-Phil
On Jul 21, 2015, at 8:49 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hi,
yes, an upgrade is absolutely possible but since there are no major issues
with that release, we didn't do that yet. Are you just assuming a newer
software improves that or did Juniper really do something on that side?
Best,
Jeff
Am 22.07.2015 um 02:45 schrieb Phil Rosenthal:
Disabling Basic-Table certainly bought you some time.
Agree that it still does not look good. I suspect that you are running into
a software issue. 11.4 is no longer a supported version, 12.3 is the
minimum supported today, with 13.3R6 as the recommended version. Is it
possible for you to upgrade?
Best Regards,
-Phil
On Jul 21, 2015, at 7:23 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hi Phil,
sure:
{master}
jeff@cr0 show configuration | display set | match rpf-check
{master}
nico@FRA4.cr0 show version
Hostname: cr0
Model: mx480
JUNOS Base OS boot [11.4R9.4]
JUNOS Base OS Software Suite [11.4R9.4]
JUNOS Kernel Software Suite [11.4R9.4]
JUNOS Crypto Software Suite [11.4R9.4]
JUNOS Packet Forwarding Engine Support (M/T Common) [11.4R9.4]
JUNOS Packet Forwarding Engine Support (MX Common) [11.4R9.4]
JUNOS Online Documentation [11.4R9.4]
JUNOS Voice Services Container package [11.4R9.4]
JUNOS Border Gateway Function package [11.4R9.4]
JUNOS Services AACL Container package [11.4R9.4]
JUNOS Services LL-PDF Container package [11.4R9.4]
JUNOS Services PTSP Container package [11.4R9.4]
JUNOS Services Stateful Firewall [11.4R9.4]
JUNOS Services NAT [11.4R9.4]
JUNOS Services Application Level Gateways [11.4R9.4]
JUNOS Services Captive Portal and Content Delivery Container package
[11.4R9.4]
JUNOS Services RPM [11.4R9.4]
JUNOS Services HTTP Content Management package [11.4R9.4]
JUNOS AppId Services [11.4R9.4]
JUNOS IDP Services [11.4R9.4]
JUNOS Services Crypto [11.4R9.4]
JUNOS Services SSL [11.4R9.4]
JUNOS Services IPSec [11.4R9.4]
JUNOS Runtime Software Suite [11.4R9.4]
JUNOS Routing Software Suite [11.4R9.4]
{master}
nico@FRA4.cr0 show route summary
Autonomous system number: X
Router ID: A.B.C.D
inet.0: 546231 destinations, 1747898 routes (545029 active, 11 holddown,
2994 hidden)
Direct: 1143 routes, 1140 active
Local: 1144 routes, 1144 active
OSPF: 81 routes, 18 active
BGP: 1745429 routes, 542631 active
Static:100 routes, 95 active
IGMP: 1 routes, 1 active
Basic-Table.inet.0: 212783 destinations, 215070 routes (212778 active, 5
holddown, 0 hidden)
Direct: 2283 routes, 1140 active
Local: 2288 routes, 1144 active
OSPF: 17 routes, 17 active
BGP: 210387 routes, 210382 active
Static: 95 routes, 95 active
inet6.0: 23331 destinations, 39242 routes (23330 active, 1 holddown, 113
hidden)
Direct:451 routes,368 active
Local:373 routes,373 active
OSPF3: 9 routes, 9 active
BGP: 38399 routes, 22571 active
Static: 10 routes, 9 active
Basic-Table.inet6.0: 12295 destinations, 12295 routes (12292 active, 3
holddown, 0 hidden)
Direct:366 routes,366 active
Local:373 routes,373 active
OSPF3: 8 routes, 8 active
BGP: 11539 routes, 11536 active
Static: 9 routes, 9 active
{master}
I actually thought this Basic-Table was inactive. It is not so I'm going
to deactive it now. Since it was holding 200k routes, this is for sure a
lot. Doing that made the syslog message disappear but it didn't actually
free up as much as I was hoping for:
GOT: Jtree memory segment 0 (Context: 0x44976cc8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT:14613176 bytes used
GOT: 2145824 bytes available (865792 bytes from free pages)
GOT:3024 bytes wasted
GOT: 15192 bytes unusable
GOT: 32768 pages total
GOT:6338 pages used (2568 pages used in page alloc)
GOT: 24739 pages partially used
GOT:1691 pages free (max contiguous = 380)
Still doesn't look to glorious, right?
Best,
Jeff
Am 22.07.2015 um 01:06 schrieb Phil Rosenthal:
Can you paste the output of these commands:
show conf | display set | match rpf-check
show ver
show route sum
DPC should have enough memory for ~1M FIB. This can get divided in half
if you
Re: [j-nsp] Proper Break of MPLS RSVP Ring
Chris, I do understand. My initial thoughts were all theoretical. Helping me understand RSVP and the MPLS more. With some help I did discover i had a typo between the links forcing them not to pull up any protocol even OSPF (my internal MPLS routing). So my entire config was right but I had that one mistake. Thank you all to those who provided their two cents and more. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Tue, Jul 21, 2015 at 5:44 PM, Chris Kawchuk juniperd...@gmail.com wrote: Post relevant configs and an actual diagram (Visio - PDF) Without this, anything we say is pure speculation -- and we end up playing '20 questions' with you. Getting an MPLS/RSVP/LDP/IGP/BGP/Mesh/TE network setup involves multiple steps and config-knobs being turned on and turned on correctly. Missing any one of them can result in undesirable behaviour. 1. RSVP priority/preference (?) has no bearing on forming an MPLS forwarding path adjacent between two LSRs. 2. There is no break in an MPLS network if it happens to be attached in a ring. This is not Spanning Tree. You have a fully routed network. Topology can be arbitrary. 3. How are you setting broken RSVP down? RSVP only goes up to a neighbour IF it actually has a reason to talk to it's neighbour. If you do not book an RSVP LSP across the link (due to ERO or following the IGP to the egress point), the two LSR's never exchange RSVP packets, because they have no reason to do so. This is known and expected behaviour. This is not LDP, which is 'chatty' and tries to reach out and touch it's neighbour and dynamically create FECs and transport label tables. RSVP only is invoked on an LSR-LSR link if an actual reservation needs to be made on that link. 4. What does your IGP suggest about the shortest path in the topology? 5. do you have family mpls enabled on all the relevant interfaces? 6. do you have all the relevant interfaces you want to run rsvp on, declared in protocols rsvp, and protocols mpls? etc.. ;) - Ck. On 22/07/2015, at 5:18 AM, Levi Pederson levipeder...@mankatonetworks.net wrote: All, Double Checked the Layer 2 ring today and it seems solid. Once again we have B and C co-located and A and D in remote locations with a link between them. Currently there is no RSVP between C and D and this is making my ring go right instead of left! I can Ping from D to C (it's next hop on the ring) if I force it out the MPLS interface. However when I ping the LSP interfaces (loopbacks) it takes the long way around). Short is 10ms and the long goes up to almost 26ms (pinging loops , again the long way around). Current production traffic backs this up. This leads me to believe there is not a Layer 2 issue but something more enigmatic. Currently reading up on RSVP priority/preference but that seems like taking a 2Ton Electromagnetic Sentient WreckingBall to hammer in a nail. Thank you, ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] jtree0 Memory full on MX480?
Disabling Basic-Table certainly bought you some time.
Agree that it still does not look good. I suspect that you are running into a
software issue. 11.4 is no longer a supported version, 12.3 is the minimum
supported today, with 13.3R6 as the recommended version. Is it possible for
you to upgrade?
Best Regards,
-Phil
On Jul 21, 2015, at 7:23 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hi Phil,
sure:
{master}
jeff@cr0 show configuration | display set | match rpf-check
{master}
nico@FRA4.cr0 show version
Hostname: cr0
Model: mx480
JUNOS Base OS boot [11.4R9.4]
JUNOS Base OS Software Suite [11.4R9.4]
JUNOS Kernel Software Suite [11.4R9.4]
JUNOS Crypto Software Suite [11.4R9.4]
JUNOS Packet Forwarding Engine Support (M/T Common) [11.4R9.4]
JUNOS Packet Forwarding Engine Support (MX Common) [11.4R9.4]
JUNOS Online Documentation [11.4R9.4]
JUNOS Voice Services Container package [11.4R9.4]
JUNOS Border Gateway Function package [11.4R9.4]
JUNOS Services AACL Container package [11.4R9.4]
JUNOS Services LL-PDF Container package [11.4R9.4]
JUNOS Services PTSP Container package [11.4R9.4]
JUNOS Services Stateful Firewall [11.4R9.4]
JUNOS Services NAT [11.4R9.4]
JUNOS Services Application Level Gateways [11.4R9.4]
JUNOS Services Captive Portal and Content Delivery Container package
[11.4R9.4]
JUNOS Services RPM [11.4R9.4]
JUNOS Services HTTP Content Management package [11.4R9.4]
JUNOS AppId Services [11.4R9.4]
JUNOS IDP Services [11.4R9.4]
JUNOS Services Crypto [11.4R9.4]
JUNOS Services SSL [11.4R9.4]
JUNOS Services IPSec [11.4R9.4]
JUNOS Runtime Software Suite [11.4R9.4]
JUNOS Routing Software Suite [11.4R9.4]
{master}
nico@FRA4.cr0 show route summary
Autonomous system number: X
Router ID: A.B.C.D
inet.0: 546231 destinations, 1747898 routes (545029 active, 11 holddown, 2994
hidden)
Direct: 1143 routes, 1140 active
Local: 1144 routes, 1144 active
OSPF: 81 routes, 18 active
BGP: 1745429 routes, 542631 active
Static:100 routes, 95 active
IGMP: 1 routes, 1 active
Basic-Table.inet.0: 212783 destinations, 215070 routes (212778 active, 5
holddown, 0 hidden)
Direct: 2283 routes, 1140 active
Local: 2288 routes, 1144 active
OSPF: 17 routes, 17 active
BGP: 210387 routes, 210382 active
Static: 95 routes, 95 active
inet6.0: 23331 destinations, 39242 routes (23330 active, 1 holddown, 113
hidden)
Direct:451 routes,368 active
Local:373 routes,373 active
OSPF3: 9 routes, 9 active
BGP: 38399 routes, 22571 active
Static: 10 routes, 9 active
Basic-Table.inet6.0: 12295 destinations, 12295 routes (12292 active, 3
holddown, 0 hidden)
Direct:366 routes,366 active
Local:373 routes,373 active
OSPF3: 8 routes, 8 active
BGP: 11539 routes, 11536 active
Static: 9 routes, 9 active
{master}
I actually thought this Basic-Table was inactive. It is not so I'm going to
deactive it now. Since it was holding 200k routes, this is for sure a lot.
Doing that made the syslog message disappear but it didn't actually free up
as much as I was hoping for:
GOT: Jtree memory segment 0 (Context: 0x44976cc8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT:14613176 bytes used
GOT: 2145824 bytes available (865792 bytes from free pages)
GOT:3024 bytes wasted
GOT: 15192 bytes unusable
GOT: 32768 pages total
GOT:6338 pages used (2568 pages used in page alloc)
GOT: 24739 pages partially used
GOT:1691 pages free (max contiguous = 380)
Still doesn't look to glorious, right?
Best,
Jeff
Am 22.07.2015 um 01:06 schrieb Phil Rosenthal:
Can you paste the output of these commands:
show conf | display set | match rpf-check
show ver
show route sum
DPC should have enough memory for ~1M FIB. This can get divided in half if
you are using RPF. If you have multiple routing instances, this also can
contribute to the problem.
Best Regards,
-Phil Rosenthal
On Jul 21, 2015, at 6:56 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hello list,
we seem to be running into limits with a MX480 with RE-2000 and 2x
DPCE-4XGE-R since we are seeing these new messages in the syslog:
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree
Instance:jtree0-seg0 Type:free-dwords Available:83072 is less than LWM
limit:104857, rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree
Instance:jtree1-seg0 Type:free-pages Available:1326 is less than LWM
limit:1638,
Re: [j-nsp] jtree0 Memory full on MX480?
Hi,
yes, an upgrade is absolutely possible but since there are no major
issues with that release, we didn't do that yet. Are you just assuming a
newer software improves that or did Juniper really do something on that
side?
Best,
Jeff
Am 22.07.2015 um 02:45 schrieb Phil Rosenthal:
Disabling Basic-Table certainly bought you some time.
Agree that it still does not look good. I suspect that you are running into a
software issue. 11.4 is no longer a supported version, 12.3 is the minimum
supported today, with 13.3R6 as the recommended version. Is it possible for
you to upgrade?
Best Regards,
-Phil
On Jul 21, 2015, at 7:23 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hi Phil,
sure:
{master}
jeff@cr0 show configuration | display set | match rpf-check
{master}
nico@FRA4.cr0 show version
Hostname: cr0
Model: mx480
JUNOS Base OS boot [11.4R9.4]
JUNOS Base OS Software Suite [11.4R9.4]
JUNOS Kernel Software Suite [11.4R9.4]
JUNOS Crypto Software Suite [11.4R9.4]
JUNOS Packet Forwarding Engine Support (M/T Common) [11.4R9.4]
JUNOS Packet Forwarding Engine Support (MX Common) [11.4R9.4]
JUNOS Online Documentation [11.4R9.4]
JUNOS Voice Services Container package [11.4R9.4]
JUNOS Border Gateway Function package [11.4R9.4]
JUNOS Services AACL Container package [11.4R9.4]
JUNOS Services LL-PDF Container package [11.4R9.4]
JUNOS Services PTSP Container package [11.4R9.4]
JUNOS Services Stateful Firewall [11.4R9.4]
JUNOS Services NAT [11.4R9.4]
JUNOS Services Application Level Gateways [11.4R9.4]
JUNOS Services Captive Portal and Content Delivery Container package [11.4R9.4]
JUNOS Services RPM [11.4R9.4]
JUNOS Services HTTP Content Management package [11.4R9.4]
JUNOS AppId Services [11.4R9.4]
JUNOS IDP Services [11.4R9.4]
JUNOS Services Crypto [11.4R9.4]
JUNOS Services SSL [11.4R9.4]
JUNOS Services IPSec [11.4R9.4]
JUNOS Runtime Software Suite [11.4R9.4]
JUNOS Routing Software Suite [11.4R9.4]
{master}
nico@FRA4.cr0 show route summary
Autonomous system number: X
Router ID: A.B.C.D
inet.0: 546231 destinations, 1747898 routes (545029 active, 11 holddown, 2994
hidden)
Direct: 1143 routes, 1140 active
Local: 1144 routes, 1144 active
OSPF: 81 routes, 18 active
BGP: 1745429 routes, 542631 active
Static:100 routes, 95 active
IGMP: 1 routes, 1 active
Basic-Table.inet.0: 212783 destinations, 215070 routes (212778 active, 5
holddown, 0 hidden)
Direct: 2283 routes, 1140 active
Local: 2288 routes, 1144 active
OSPF: 17 routes, 17 active
BGP: 210387 routes, 210382 active
Static: 95 routes, 95 active
inet6.0: 23331 destinations, 39242 routes (23330 active, 1 holddown, 113 hidden)
Direct:451 routes,368 active
Local:373 routes,373 active
OSPF3: 9 routes, 9 active
BGP: 38399 routes, 22571 active
Static: 10 routes, 9 active
Basic-Table.inet6.0: 12295 destinations, 12295 routes (12292 active, 3
holddown, 0 hidden)
Direct:366 routes,366 active
Local:373 routes,373 active
OSPF3: 8 routes, 8 active
BGP: 11539 routes, 11536 active
Static: 9 routes, 9 active
{master}
I actually thought this Basic-Table was inactive. It is not so I'm going to
deactive it now. Since it was holding 200k routes, this is for sure a lot. Doing that
made the syslog message disappear but it didn't actually free up as much as I was hoping for:
GOT: Jtree memory segment 0 (Context: 0x44976cc8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT:14613176 bytes used
GOT: 2145824 bytes available (865792 bytes from free pages)
GOT:3024 bytes wasted
GOT: 15192 bytes unusable
GOT: 32768 pages total
GOT:6338 pages used (2568 pages used in page alloc)
GOT: 24739 pages partially used
GOT:1691 pages free (max contiguous = 380)
Still doesn't look to glorious, right?
Best,
Jeff
Am 22.07.2015 um 01:06 schrieb Phil Rosenthal:
Can you paste the output of these commands:
show conf | display set | match rpf-check
show ver
show route sum
DPC should have enough memory for ~1M FIB. This can get divided in half if you
are using RPF. If you have multiple routing instances, this also can contribute
to the problem.
Best Regards,
-Phil Rosenthal
On Jul 21, 2015, at 6:56 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hello list,
we seem to be running into limits with a MX480 with RE-2000 and 2x DPCE-4XGE-R
since we are seeing these new messages in the syslog:
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-dwords Available:83072 is less than LWM limit:104857,
Re: [j-nsp] Proper Break of MPLS RSVP Ring
All, Double Checked the Layer 2 ring today and it seems solid. Once again we have B and C co-located and A and D in remote locations with a link between them. Currently there is no RSVP between C and D and this is making my ring go right instead of left! I can Ping from D to C (it's next hop on the ring) if I force it out the MPLS interface. However when I ping the LSP interfaces (loopbacks) it takes the long way around). Short is 10ms and the long goes up to almost 26ms (pinging loops , again the long way around). Current production traffic backs this up. This leads me to believe there is not a Layer 2 issue but something more enigmatic. Currently reading up on RSVP priority/preference but that seems like taking a 2Ton Electromagnetic Sentient WreckingBall to hammer in a nail. Thank you, *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net On Thu, Jul 16, 2015 at 2:58 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Levi, On 17 Jul 2015, at 5:22 am, Levi Pederson levipeder...@mankatonetworks.net wrote: This is displaying it self in my output by not having an RSVP Neighbor (neighbor down hellos sent) between CD (and therefore sending my traffic inefficiently 3/4 way around the ring instead of the 1/4 hop it could. Last bit of information is that D sees C as a neighbor but is down. C does not even see D as a neighbor at all. This sounds like an L2 issue, or perhaps a misconfiguration - all nodes should be RSVP neighbours in order to be able to signal LSPs across those interfaces. Check your protocols rsvp config for the logical interfaces between D. Use monitor traffic interface D-C interface on D to confirm that RSVP is being sent out of the box. Check any control-plane filtering/firewall filters you have configured on C (though it seems to be receiving just fine from B). I'm wondering how RSVP breaks that link. All the documentation I can find are focused on LSP validation/creation and not on Link Breaks to stop layer 2 loops (is my assumption). If one of my intervening links goes own I would like to correct it and then move the break to the specified point. But the RSVP documentation is rather...limited to only LSPs if I am reading it correctly. RSVP won’t break the link to stop loops (the LSPs will carry service labels which may not even be L2 services), it will simply establish the LSP across the best/shortest path between endpoints (based on your TE settings), and if this becomes unavailable (and depending on your configuration) it will simply re-establish over any alternate path (which it sounds like is working well). Cheers, Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 Limitations
Saku Ytti wrote: 1) It’s 3.5U high, making rack planning a little weird, and requiring me to buy a hard to find half-U blank panel It is targeting metro applications, where racks often are telco racks. job-1 and job-2 were thrilled to get MX104 form-factor, MX80 was very problematic and lead to 'creative' installations. Telco here. I love the MX104's format... in general. Most of our installations are DC so the .5U part is really negligible as approx. 1U is required off the bottom of the unit for clearance anyway. What drives me nuts about the height is actually the spacing of holes on the ears. Racking them is clumsy for this reason. I'd love to see a switch in a similar form factor. We've had to put some EX4200s in one of our COs, and man, what a pain in the cavity those are. Flimsy little ears and way too deep. 2) It uses unusual power connectors on its power supplies, so you have to plan to buy special power cords just for this. It's standard C15/C16 which is temperature enchanced (120c) version of standard C13/C14. Lot of vendors are doing that these days, I'd like to understand why. Is there some new recommendation for fire safety or what has triggered the change. Thank you for this explanation!!! We have one AC unit at a tower site and were wondering what the story was. Our company now has *TWO* NEMA 5-15P to IEC 320 C15 cables. About the only other thing that annoys me about the MX104 is the location of the chassis ground. Right in the corner with the fan tray. Seriously? In general I love these little routers. Cheers Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE switch master to backup
Gents, has anybody seen a dual RE MX gear switch the routing engine master to backup due to a “possibly bad console cable” ? Jul 1 11:21:29.941 2015 MX480LON_0 init: getty repeating too quickly on port /dev/ttyd0, sleeping 30 secs Did you happen to find a resolution for this? That message seems the most telling as to why it would fail over. On Sun servers there used to be a way cool method to get them to reboot: Send a trillion BREAKs over the console. Same thing could happen if you rebooted your console device a few times, or, indeed, if the cable was bad. I'm not sure if JUNOS operates like this internally, but as they have common BSD roots it could be related. Cheers Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE switch master to backup
Once upon a time, Ross Halliday ross.halli...@wtccommunications.ca said: On Sun servers there used to be a way cool method to get them to reboot: Send a trillion BREAKs over the console. Same thing could happen if you rebooted your console device a few times, or, indeed, if the cable was bad. I'm not sure if JUNOS operates like this internally, but as they have common BSD roots it could be related. That was related to OpenFirmware serial console behaivor, which would be unrelated to the Juniper BIOS (for x86 systems) or U-Boot (for the other) behavior. It didn't have anything to do with the OS that was running. Also, Solaris is System V, not BSD (/usr/ucb notwithstanding). On OpenFirmware, sending a BREAK would drop the system to the firmware prompt, which stopped the running OS (the firmware was essentially always loaded and running in the background). BIOS and U-Boot systems don't operate like that (well, there are things like SMM, but that's different). -- Chris Adams c...@cmadams.net ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Q-in-Q with VSTP
I'm bashing away at a conundrum here. I'm trying to lab a setup for a
multi-VLAN subscriber over some GPON gear. The setup is:
MX104 --2x-- OLT -- ONT -- subscriber
The ONT is able to strip the outer VLAN tag facing the subscriber, so the CE
can hit all of the inner VLANs directly. The OLT presents frames with both
outer and inner
tags to the MX, so I must strip the outer in order to work with the
subscriber's services. Link bundling/aggregation between the MX and OLT are
not an option, so I
need to use spanning tree.
So, I am trying to create a bridge domain with VSTP enabled for VLANs that
aren't accessible with a simple vlan-id-list or vlan-id.
I cannot get this to work. I've tried vlan-tags outer 9 inner 9 with
separate units per inner VLAN, as well as sending everything into a vswitch
like detailed here
http://www.juniper.net/techpubs/en_US/junos14.2/topics/topic-map/layer-2-services-stp-vstp-on-trunk-port-with-tagged-traffic-example.html
...but the STP
instance just doesn't seem to recognize the interface, and my CE doesn't see
any BPDUs on that VLAN.
I can't even find if this feature is supported - my searches on Juniper's
site don't show anything with spanning tree and Q-in-Q or double-tags or
inner tags etc on the
same page.
Is anybody else trying to do this? Or suggested solution? If the MX supported
Redundant Trunk Groups (like Cisco FlexLink) this would be so much easier.
Figured I should follow up on this in case someone tries similar in the future.
What ended up working was to run spanning tree on the outer VLAN. What I find
odd, being a Cisco graduate, is that the outer VLAN doesn't technically exist
as a bridge domain... just as something VSTP uses.
protocols {
vstp {
vlan 2090 {
bridge-priority 4k;
interface ge-1/0/2;
interface ge-1/1/2;
}
}
}
interfaces {
ge-1/0/2 {
description GPON Card 1;
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2090 {
description Q-in-Q to subscriber;
vlan-id 2090;
family bridge {
interface-mode trunk;
inner-vlan-id-list [ 100 200 300 ];
}
}
}
ge-1/1/2 {
description GPON Card 12;
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 2090 {
description Q-in-Q to subscriber;
vlan-id 2090;
family bridge {
interface-mode trunk;
inner-vlan-id-list [ 100 200 300 ];
}
}
}
}
bridge-domains {
Jimbob-Phones {
description Jimbob's IP phones;
vlan-id 100;
routing-interface irb.100;
}
Jimbob-Internet {
description Jimbob's Internet access;
vlan-id 200;
routing-interface irb.200;
}
Jimbob-TLS {
description Jimbob's L3VPN to remote offices;
vlan-id 300;
routing-interface irb.300;
}
}
Works great. VSTP on 2090 prevents loops between the MX and GPON access gear,
and since the access gear strips the outer tag going to the subscriber the CE
doesn't even know it's there. STP not required on the inner VLANs like I had
originally tried.
Hope this helps someone.
Cheers
Ross
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] jtree0 Memory full on MX480?
I know that a ton of fixes on BGP convergence time son MX80 is definitely a reason to be 'moving up'... however as you're on RE-2000s on MX480 may not be applicable. I see you're running DPC cards, have you considered shifting those links onto an MPC/Trio Card? (newer chip, more RAM, more horsepower, yadda yadda yadda =)..) DPC was EOL a while ago, and everything has been Trio (and now Trio-NG on the new -NG cards coming out now). As the FIB is pushed to hardware, it may be some silly DPC thing you're running into. For things like Fusion or BNG or any other new/advanced/this-is-what-PLM-is-thinking functions, we're already putting in 14.2 on any new device we turn up, and have already started testing 15.1 for the new NG cards we will likely be buying. Rest of our network is now on 12.3R8 or 13.3 in many cases. (lots of BFD bugs have been squashed, some HQoS issues fixed, host-outbound-traffic for BFD keepalives now honour the c-o-s knobs, and are finally out of Queue 3 and into the Queue we want (7), etc... preventing starvation if you happen to have re-used Queue 3 as not-so-high priority, etc)... the list goes on. It's not a case of if it aint broke, don't fix it once you get 4-5 years behind. You'll benefit from the years of Oh, we finally fixed LLDP ascii decoding stuff that ends up getting traction; plus JTAC would really really like it if you weren't on 11.4 =) - Ck. On 22 Jul 2015, at 10:49 am, Jeff Meyers jeff.mey...@gmx.net wrote: Hi, yes, an upgrade is absolutely possible but since there are no major issues with that release, we didn't do that yet. Are you just assuming a newer software improves that or did Juniper really do something on that side? Best, Jeff ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Proper Break of MPLS RSVP Ring
Post relevant configs and an actual diagram (Visio - PDF) Without this, anything we say is pure speculation -- and we end up playing '20 questions' with you. Getting an MPLS/RSVP/LDP/IGP/BGP/Mesh/TE network setup involves multiple steps and config-knobs being turned on and turned on correctly. Missing any one of them can result in undesirable behaviour. 1. RSVP priority/preference (?) has no bearing on forming an MPLS forwarding path adjacent between two LSRs. 2. There is no break in an MPLS network if it happens to be attached in a ring. This is not Spanning Tree. You have a fully routed network. Topology can be arbitrary. 3. How are you setting broken RSVP down? RSVP only goes up to a neighbour IF it actually has a reason to talk to it's neighbour. If you do not book an RSVP LSP across the link (due to ERO or following the IGP to the egress point), the two LSR's never exchange RSVP packets, because they have no reason to do so. This is known and expected behaviour. This is not LDP, which is 'chatty' and tries to reach out and touch it's neighbour and dynamically create FECs and transport label tables. RSVP only is invoked on an LSR-LSR link if an actual reservation needs to be made on that link. 4. What does your IGP suggest about the shortest path in the topology? 5. do you have family mpls enabled on all the relevant interfaces? 6. do you have all the relevant interfaces you want to run rsvp on, declared in protocols rsvp, and protocols mpls? etc.. ;) - Ck. On 22/07/2015, at 5:18 AM, Levi Pederson levipeder...@mankatonetworks.net wrote: All, Double Checked the Layer 2 ring today and it seems solid. Once again we have B and C co-located and A and D in remote locations with a link between them. Currently there is no RSVP between C and D and this is making my ring go right instead of left! I can Ping from D to C (it's next hop on the ring) if I force it out the MPLS interface. However when I ping the LSP interfaces (loopbacks) it takes the long way around). Short is 10ms and the long goes up to almost 26ms (pinging loops , again the long way around). Current production traffic backs this up. This leads me to believe there is not a Layer 2 issue but something more enigmatic. Currently reading up on RSVP priority/preference but that seems like taking a 2Ton Electromagnetic Sentient WreckingBall to hammer in a nail. Thank you, ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] jtree0 Memory full on MX480?
Hello list,
we seem to be running into limits with a MX480 with RE-2000 and 2x
DPCE-4XGE-R since we are seeing these new messages in the syslog:
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree
Instance:jtree0-seg0 Type:free-dwords Available:83072 is less than LWM
limit:104857, rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree
Instance:jtree1-seg0 Type:free-pages Available:1326 is less than LWM
limit:1638, rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc1 RSMON: Resource Category:jtree
Instance:jtree0-seg0 Type:free-pages Available:1316 is less than LWM
limit:1638, rsmon_syslog_limit()
Jul 22 00:50:37 cr0 fpc1 RSMON: Resource Category:jtree
Instance:jtree0-seg0 Type:free-dwords Available:84224 is less than LWM
limit:104857, rsmon_syslog_limit()
Jul 22 00:50:37 cr0 fpc0 RSMON: Resource Category:jtree
Instance:jtree1-seg0 Type:free-dwords Available:84864 is less than LWM
limit:104857, rsmon_syslog_limit()
Here is some more output from the FPC:
jeff@cr0 request pfe execute target fpc0 command show rsmon
SENT: Ukern command: show rsmon
GOT:
GOT: categoryinstancetypetotal lwm_limit hwm_limit free
GOT: --- - -
GOT:jtree jtree0-seg0 free-pages32768 1638 4915 1245
GOT:jtree jtree0-seg0 free-dwords 209715210485731457279680
GOT:jtree jtree0-seg1 free-pages32768 1638 491522675
GOT:jtree jtree0-seg1 free-dwords 2097152104857314572 1451200
GOT:jtree jtree1-seg0 free-pages32768 1638 4915 1267
GOT:jtree jtree1-seg0 free-dwords 209715210485731457281088
GOT:jtree jtree1-seg1 free-pages32768 1638 491523743
GOT:jtree jtree1-seg1 free-dwords 2097152104857314572 1519552
GOT:jtree jtree2-seg0 free-pages32768 1638 4915 1266
GOT:jtree jtree2-seg0 free-dwords 209715210485731457281024
GOT:jtree jtree2-seg1 free-pages32768 1638 491523732
GOT:jtree jtree2-seg1 free-dwords 2097152104857314572 1518848
GOT:jtree jtree3-seg0 free-pages32768 1638 4915 1232
GOT:jtree jtree3-seg0 free-dwords 209715210485731457278848
GOT:jtree jtree3-seg1 free-pages32768 1638 491523731
GOT:jtree jtree3-seg1 free-dwords 2097152104857314572 1518784
LOCAL: End of file
{master}
jeff@cr0 request pfe execute target fpc0 command show jtree 0 memory
extensive
SENT: Ukern command: show jtree 0 memory extensive
GOT:
GOT: Jtree memory segment 0 (Context: 0x44976cc8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT:15299920 bytes used
GOT: 1459080 bytes available (660480 bytes from free pages)
GOT:3024 bytes wasted
GOT: 15192 bytes unusable
GOT: 32768 pages total
GOT: 26528 pages used (2568 pages used in page alloc)
GOT:4950 pages partially used
GOT:1290 pages free (max contiguous = 373)
GOT:
GOT: Partially Filled Pages (In bytes):-
GOT: UnitAvail Overhead
GOT: 8 6743440
GOT: 16 1078400
GOT: 2413296 4792
GOT: 32 2880
GOT: 48 283210400
GOT:
GOT: Free Page Lists(Pg Size = 512 bytes):-
GOT:Page Bucket Avail(Bytes)
GOT:1-1 140288
GOT:2-2 112640
GOT:3-376800
GOT:4-449152
GOT:5-5 7680
GOT:6-615360
GOT:7-725088
GOT:8-8 8192
GOT: 9-11 5632
GOT: 12-17 6656
GOT: 18-2622016
GOT: 27-32768 190976
GOT:
GOT: Fragmentation Index = 0.869, (largest free = 190976)
GOT: Counters:
GOT: 465261655 allocs (0 failed)
GOT: 0 releases(partial 0)
GOT: 463785484 frees
GOT: 0 holds
GOT: 9 pending frees(pending bytes 88)
GOT: 0 pending forced
GOT: 0 times free blocked
GOT: 0 sync writes
GOT: Error Counters:-
GOT: 0 bad params
GOT: 0 failed frees
GOT: 0 bad cookie
GOT:
GOT: Jtree memory segment 1 (Context: 0x449f87e8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT: 5123760 bytes used
GOT:11650408 bytes available (11609600 bytes from free pages)
GOT:2704 bytes wasted
GOT: 344 bytes unusable
GOT: 32768 pages total
GOT:9912 pages used (8976 pages used in page alloc)
GOT: 181 pages partially used
GOT: 22675 pages free (max contiguous = 22672)
GOT:
GOT: Partially Filled Pages (In bytes):-
GOT: UnitAvail Overhead
GOT: 8253520
GOT:
Re: [j-nsp] jtree0 Memory full on MX480?
Can you paste the output of these commands:
show conf | display set | match rpf-check
show ver
show route sum
DPC should have enough memory for ~1M FIB. This can get divided in half if you
are using RPF. If you have multiple routing instances, this also can contribute
to the problem.
Best Regards,
-Phil Rosenthal
On Jul 21, 2015, at 6:56 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hello list,
we seem to be running into limits with a MX480 with RE-2000 and 2x
DPCE-4XGE-R since we are seeing these new messages in the syslog:
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-dwords Available:83072 is less than LWM limit:104857,
rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree1-seg0
Type:free-pages Available:1326 is less than LWM limit:1638,
rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc1 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-pages Available:1316 is less than LWM limit:1638,
rsmon_syslog_limit()
Jul 22 00:50:37 cr0 fpc1 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-dwords Available:84224 is less than LWM limit:104857,
rsmon_syslog_limit()
Jul 22 00:50:37 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree1-seg0
Type:free-dwords Available:84864 is less than LWM limit:104857,
rsmon_syslog_limit()
Here is some more output from the FPC:
jeff@cr0 request pfe execute target fpc0 command show rsmon
SENT: Ukern command: show rsmon
GOT:
GOT: categoryinstancetypetotal lwm_limit hwm_limit free
GOT: --- - -
GOT:jtree jtree0-seg0 free-pages32768 1638 4915 1245
GOT:jtree jtree0-seg0 free-dwords 209715210485731457279680
GOT:jtree jtree0-seg1 free-pages32768 1638 491522675
GOT:jtree jtree0-seg1 free-dwords 2097152104857314572 1451200
GOT:jtree jtree1-seg0 free-pages32768 1638 4915 1267
GOT:jtree jtree1-seg0 free-dwords 209715210485731457281088
GOT:jtree jtree1-seg1 free-pages32768 1638 491523743
GOT:jtree jtree1-seg1 free-dwords 2097152104857314572 1519552
GOT:jtree jtree2-seg0 free-pages32768 1638 4915 1266
GOT:jtree jtree2-seg0 free-dwords 209715210485731457281024
GOT:jtree jtree2-seg1 free-pages32768 1638 491523732
GOT:jtree jtree2-seg1 free-dwords 2097152104857314572 1518848
GOT:jtree jtree3-seg0 free-pages32768 1638 4915 1232
GOT:jtree jtree3-seg0 free-dwords 209715210485731457278848
GOT:jtree jtree3-seg1 free-pages32768 1638 491523731
GOT:jtree jtree3-seg1 free-dwords 2097152104857314572 1518784
LOCAL: End of file
{master}
jeff@cr0 request pfe execute target fpc0 command show jtree 0 memory
extensive
SENT: Ukern command: show jtree 0 memory extensive
GOT:
GOT: Jtree memory segment 0 (Context: 0x44976cc8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT:15299920 bytes used
GOT: 1459080 bytes available (660480 bytes from free pages)
GOT:3024 bytes wasted
GOT: 15192 bytes unusable
GOT: 32768 pages total
GOT: 26528 pages used (2568 pages used in page alloc)
GOT:4950 pages partially used
GOT:1290 pages free (max contiguous = 373)
GOT:
GOT: Partially Filled Pages (In bytes):-
GOT: UnitAvail Overhead
GOT: 8 6743440
GOT: 16 1078400
GOT: 2413296 4792
GOT: 32 2880
GOT: 48 283210400
GOT:
GOT: Free Page Lists(Pg Size = 512 bytes):-
GOT:Page Bucket Avail(Bytes)
GOT:1-1 140288
GOT:2-2 112640
GOT:3-376800
GOT:4-449152
GOT:5-5 7680
GOT:6-615360
GOT:7-725088
GOT:8-8 8192
GOT: 9-11 5632
GOT: 12-17 6656
GOT: 18-2622016
GOT: 27-32768 190976
GOT:
GOT: Fragmentation Index = 0.869, (largest free = 190976)
GOT: Counters:
GOT: 465261655 allocs (0 failed)
GOT: 0 releases(partial 0)
GOT: 463785484 frees
GOT: 0 holds
GOT: 9 pending frees(pending bytes 88)
GOT: 0 pending forced
GOT: 0 times free blocked
GOT: 0 sync writes
GOT: Error Counters:-
GOT: 0 bad params
GOT: 0 failed frees
GOT: 0 bad cookie
GOT:
GOT: Jtree memory segment 1 (Context: 0x449f87e8)
GOT: ---
GOT: Memory
Re: [j-nsp] jtree0 Memory full on MX480?
Hi Phil,
sure:
{master}
jeff@cr0 show configuration | display set | match rpf-check
{master}
nico@FRA4.cr0 show version
Hostname: cr0
Model: mx480
JUNOS Base OS boot [11.4R9.4]
JUNOS Base OS Software Suite [11.4R9.4]
JUNOS Kernel Software Suite [11.4R9.4]
JUNOS Crypto Software Suite [11.4R9.4]
JUNOS Packet Forwarding Engine Support (M/T Common) [11.4R9.4]
JUNOS Packet Forwarding Engine Support (MX Common) [11.4R9.4]
JUNOS Online Documentation [11.4R9.4]
JUNOS Voice Services Container package [11.4R9.4]
JUNOS Border Gateway Function package [11.4R9.4]
JUNOS Services AACL Container package [11.4R9.4]
JUNOS Services LL-PDF Container package [11.4R9.4]
JUNOS Services PTSP Container package [11.4R9.4]
JUNOS Services Stateful Firewall [11.4R9.4]
JUNOS Services NAT [11.4R9.4]
JUNOS Services Application Level Gateways [11.4R9.4]
JUNOS Services Captive Portal and Content Delivery Container package
[11.4R9.4]
JUNOS Services RPM [11.4R9.4]
JUNOS Services HTTP Content Management package [11.4R9.4]
JUNOS AppId Services [11.4R9.4]
JUNOS IDP Services [11.4R9.4]
JUNOS Services Crypto [11.4R9.4]
JUNOS Services SSL [11.4R9.4]
JUNOS Services IPSec [11.4R9.4]
JUNOS Runtime Software Suite [11.4R9.4]
JUNOS Routing Software Suite [11.4R9.4]
{master}
nico@FRA4.cr0 show route summary
Autonomous system number: X
Router ID: A.B.C.D
inet.0: 546231 destinations, 1747898 routes (545029 active, 11 holddown,
2994 hidden)
Direct: 1143 routes, 1140 active
Local: 1144 routes, 1144 active
OSPF: 81 routes, 18 active
BGP: 1745429 routes, 542631 active
Static:100 routes, 95 active
IGMP: 1 routes, 1 active
Basic-Table.inet.0: 212783 destinations, 215070 routes (212778 active, 5
holddown, 0 hidden)
Direct: 2283 routes, 1140 active
Local: 2288 routes, 1144 active
OSPF: 17 routes, 17 active
BGP: 210387 routes, 210382 active
Static: 95 routes, 95 active
inet6.0: 23331 destinations, 39242 routes (23330 active, 1 holddown, 113
hidden)
Direct:451 routes,368 active
Local:373 routes,373 active
OSPF3: 9 routes, 9 active
BGP: 38399 routes, 22571 active
Static: 10 routes, 9 active
Basic-Table.inet6.0: 12295 destinations, 12295 routes (12292 active, 3
holddown, 0 hidden)
Direct:366 routes,366 active
Local:373 routes,373 active
OSPF3: 8 routes, 8 active
BGP: 11539 routes, 11536 active
Static: 9 routes, 9 active
{master}
I actually thought this Basic-Table was inactive. It is not so I'm
going to deactive it now. Since it was holding 200k routes, this is
for sure a lot. Doing that made the syslog message disappear but it
didn't actually free up as much as I was hoping for:
GOT: Jtree memory segment 0 (Context: 0x44976cc8)
GOT: ---
GOT: Memory Statistics:
GOT:16777216 bytes total
GOT:14613176 bytes used
GOT: 2145824 bytes available (865792 bytes from free pages)
GOT:3024 bytes wasted
GOT: 15192 bytes unusable
GOT: 32768 pages total
GOT:6338 pages used (2568 pages used in page alloc)
GOT: 24739 pages partially used
GOT:1691 pages free (max contiguous = 380)
Still doesn't look to glorious, right?
Best,
Jeff
Am 22.07.2015 um 01:06 schrieb Phil Rosenthal:
Can you paste the output of these commands:
show conf | display set | match rpf-check
show ver
show route sum
DPC should have enough memory for ~1M FIB. This can get divided in half if you
are using RPF. If you have multiple routing instances, this also can contribute
to the problem.
Best Regards,
-Phil Rosenthal
On Jul 21, 2015, at 6:56 PM, Jeff Meyers jeff.mey...@gmx.net wrote:
Hello list,
we seem to be running into limits with a MX480 with RE-2000 and 2x DPCE-4XGE-R
since we are seeing these new messages in the syslog:
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-dwords Available:83072 is less than LWM limit:104857,
rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree1-seg0
Type:free-pages Available:1326 is less than LWM limit:1638, rsmon_syslog_limit()
Jul 22 00:50:36 cr0 fpc1 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-pages Available:1316 is less than LWM limit:1638, rsmon_syslog_limit()
Jul 22 00:50:37 cr0 fpc1 RSMON: Resource Category:jtree Instance:jtree0-seg0
Type:free-dwords Available:84224 is less than LWM limit:104857,
rsmon_syslog_limit()
Jul 22 00:50:37 cr0 fpc0 RSMON: Resource Category:jtree Instance:jtree1-seg0
Type:free-dwords Available:84864 is less than LWM limit:104857,
rsmon_syslog_limit()
Here
Re: [j-nsp] Cisco ME3600 migration to something with more 10 gig ports
What does the price point of the ME3600X/ASR920 platform look like? Looks like for at least the ASR920 and 10G SPF+ ports you have the buy the chassis and then upgrade licenses? Considering a Juniper GFX5100 is ~$11k brand new does it make any sense to go with something like an ASR920, or does the ASR have many more features than the Juniper QFX5100? The 5100 has a ton of port built in, but is more of a switch than router. On Tue, Jul 14, 2015 at 2:26 AM, Mark Tinka mark.ti...@seacom.mu wrote: On 13/Jul/15 17:40, Ivan Ivanov wrote: PTX1000 https://www.juniper.net/us/en/products-services/routing/ptx-series/ptx1000/ Looks good, but won't hit the ME3600X/ASR920 price-point. For cheaper option you can check ACX5000. ACX5000 https://www.juniper.net/us/en/products-services/routing/acx-series/acx5000/ Broadcom chipset, as I mentioned to the OP on c-nsp. Limits your options. Mark. ___ 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] Cisco ME3600 migration to something with more 10 gig ports
On 21/Jul/15 14:41, Colton Conor wrote: What does the price point of the ME3600X/ASR920 platform look like? Looks like for at least the ASR920 and 10G SPF+ ports you have the buy the chassis and then upgrade licenses? As with any vendor, the best deal you can do is one that won't be published on a public mailing list. But I'll tell you this, even with the various licenses the ASR920 has, it is way cheaper than the ACX or QFX. And certainly about half the cost of the ME3600X. Considering a Juniper GFX5100 is ~$11k brand new does it make any sense to go with something like an ASR920, or does the ASR have many more features than the Juniper QFX5100? I'll say this, in reference to a fully or even reasonably licensed ASR920, that QFX is over-priced. But then again, perhaps you can wrestle Juniper's pricing down to something low as well. It's hard to talk final prices as each deal is each deal. Feature-wise, the ASR920 will beat the QFX or ACX very easily. Even though it's a switch, it's really a router. The 5100 has a ton of port built in, but is more of a switch than router. Yes. I think the ACX5000 is more of the router, but again, it's that Broadcom job that gets in the way. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
