Re: [j-nsp] Urgent
Is it supported. On Thu, Dec 17, 2009 at 11:09 AM, chandrasekaran iyer wrote: > Hi, > > How to enable DHCP server in MX240:MX480:MX960 platforms > > -- > Thanks with regards > > Shekar.B > -- > -- Thanks with regards Shekar.B -- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Urgent
Hi, How to enable DHCP server in MX240:MX480:MX960 platforms -- Thanks with regards Shekar.B -- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Stealing from MX firewall jtree space
Hello,
route-memory-enhanced introduced in 9.6
What about terminating bgp neighbor in inet.0 with bgp operating over a
rib-group under family inet:
protocols bgp
group xy {
neighbor x.x.x.x {
import xy;
family inet {
unicast {
rib-group xy;
}
}
}
}
Then import routing-policy "xy" states:
policy-statement xy
term 1 {
from community to_inet_0;
to rib inet.0;
then accept;
}
term 2 {
to rib inet.0;
then reject;
}
term 3 {
from community to_vrf;
to rib vrf.inet.0;
then accept;
}
term 4 {
to rib vrf.inet.0;
then reject;
}
Best Regards,
Krasi
On Wed, Dec 16, 2009 at 10:25 PM, Richard A Steenbergen
wrote:
> On Wed, Dec 16, 2009 at 11:54:33AM -0800, Derick Winkworth wrote:
> > ##
> > To allocate more memory for routing tables, include the
> route-memory-enhanced
> > statement at the [edit chassis] hierarchy level:
> > [edit chassis]
> > route-memory-enhanced;
> > ##
> >
> > You have to restart the FPC once you do this...
>
> What code is that in? No love in 9.5.
>
> --
> 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
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bfd = busted failure detection :)
On Tue, Dec 15, 2009 at 11:03:08PM -0600, Kevin Day wrote: > > I went back and forth on this forever (pestering you while doing it), > because it was affecting us badly on old M20s. My "lab" boxes would > never ever show the problem, but it would happen in on the production > routers. I finally gave up and decided to figure out what the > difference was between my production configuration and the lab > simulation by slowly changing my production config to match the nearly > identical lab config. > > The problem went away when I removed a BGP session with a peer that > was extremely slow to accept routes, and we were exchanging full > tables with each other. I think it was some kind of deadlock where the > peer wasn't accepting routes because it was blocked trying to send me > stuff, and I was in the same boat. Snooping at the TCP layer, I didn't > see anything unusual except both peers ended up in a state where they > were advertising 0 window size to each other. The moment the KRT queue > cleared up, they finished exchanging routes and all was happy. > > I can't say for certain that was the problem, but shutting down that > peer was a pretty reliable way to clear the KRT queue problem whenever > it happened. What code was this? In theory shouldn't the routes be in a bgp queue regardless of whats happening with the tcp layer? Should see if we can reproduce this with modern hardware and 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
Re: [j-nsp] Stealing from MX firewall jtree space
On Wed, Dec 16, 2009 at 11:54:33AM -0800, Derick Winkworth wrote: > ## > To allocate more memory for routing tables, include the route-memory-enhanced > statement at the [edit chassis] hierarchy level: > [edit chassis] > route-memory-enhanced; > ## > > You have to restart the FPC once you do this... What code is that in? No love in 9.5. -- 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] Stealing from MX firewall jtree space
## To allocate more memory for routing tables, include the route-memory-enhanced statement at the [edit chassis] hierarchy level: [edit chassis] route-memory-enhanced; ## You have to restart the FPC once you do this... From: Richard A Steenbergen To: juniper-nsp@puck.nether.net Sent: Wed, December 16, 2009 1:26:55 PM Subject: [j-nsp] Stealing from MX firewall jtree space Anybody know the command on MX to steal unused memory from the firewall rldram segment to use it for routing data? I remember reading about this, I just can't remember the actual command. Last night I was trying to fire up a routing-instance and it ran out of fib memory much sooner than I expected, at around 750k routes total: Dec 16 07:42:14.831 re1.xxx. fpc3 RSMON: %PFE-4: Resource Category:jtree Instance:jtree2-seg0 Type:free-dwords Available:104576 is less than LWM limit:104857, rsmon_syslog_limit() With a main and logical-system each holding full v4/v6 routing tables it seems to have less than 4MB free on segment 0, but plenty left available in segment 1. ADPC3(re1.xxx. vty)# sh jtree 0 memory Jtree memory segment 0 (Context: 0x4430cfe0) --- Memory Statistics: 16777216 bytes total 10233192 bytes used 6539472 bytes available (3949056 bytes from free pages) 4032 bytes wasted 520 bytes unusable 32768 pages total 17138 pages used (2574 pages used in page alloc) 7917 pages partially used 7713 pages free (max contiguous = 693) Jtree memory segment 1 (Context: 0x4438ec20) --- Memory Statistics: 16777216 bytes total 4611728 bytes used 12162792 bytes available (12161024 bytes from free pages) 2664 bytes wasted 32 bytes unusable 32768 pages total 9007 pages used (9005 pages used in page alloc) 9 pages partially used 23752 pages free (max contiguous = 23743) Context: 0x42302f70 ADPC3(re1.xxx. vty)# sh jtree 0 summary Protocol Routes Bytes Used - -- -- IPv4 303043 4363344 IPv62533 46112 MPLS 1 16 Multi-service 1 16 Also bonus points if anyone can tell me how to accomplish the following without having to do a virtual-router routing-instance, and protocol bgp under that. I'm trying to take in ~150k of routes from a bgp neighbor, install ~50k of them into inet.0 with one policy, and install ~100k of them into another routing-instance with another policy. I can't just import the ones I want out of a single routing-instance, since instance-import only pulls the active routes. I also can't inject the routes into a particular rib w/rib-groups, since the rib-group requires inet.0, and won't let you do a per-rib policy only a per-rib-group policy. The best solution I could come up with was to make a routing-instance type virtual-router solely for the neighbor in question, run the protocols bgp under that routing-instance, and then instance-import the 50k routes I want from that rib into inet.0, and instance-import the other 100k routes I want into another routing-instance. There are two problems with this, #1 it burns memory to have a routing-instance that exists solely so I can import routes from there into other routing-instances, and #2 it is a major pain in the $%^& for my groups and commit scripts to deal with the protocols bgp config under a different hierarchy. I'm thinking I could at least block the installation of the routes to fib with a forwarding-table export policy term (from instance provider-vr, then reject), since I'm not forwarding with that rib, but I'm hoping there is a cleaner solution out there that I'm not aware of, like some way to inject the routes from one bgp neighbor directly into the ribs I want without an extra "adj rib in" holding rib. -- Richard A Steenbergen http://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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Stealing from MX firewall jtree space
Anybody know the command on MX to steal unused memory from the firewall rldram segment to use it for routing data? I remember reading about this, I just can't remember the actual command. Last night I was trying to fire up a routing-instance and it ran out of fib memory much sooner than I expected, at around 750k routes total: Dec 16 07:42:14.831 re1.xxx. fpc3 RSMON: %PFE-4: Resource Category:jtree Instance:jtree2-seg0 Type:free-dwords Available:104576 is less than LWM limit:104857, rsmon_syslog_limit() With a main and logical-system each holding full v4/v6 routing tables it seems to have less than 4MB free on segment 0, but plenty left available in segment 1. ADPC3(re1.xxx. vty)# sh jtree 0 memory Jtree memory segment 0 (Context: 0x4430cfe0) --- Memory Statistics: 16777216 bytes total 10233192 bytes used 6539472 bytes available (3949056 bytes from free pages) 4032 bytes wasted 520 bytes unusable 32768 pages total 17138 pages used (2574 pages used in page alloc) 7917 pages partially used 7713 pages free (max contiguous = 693) Jtree memory segment 1 (Context: 0x4438ec20) --- Memory Statistics: 16777216 bytes total 4611728 bytes used 12162792 bytes available (12161024 bytes from free pages) 2664 bytes wasted 32 bytes unusable 32768 pages total 9007 pages used (9005 pages used in page alloc) 9 pages partially used 23752 pages free (max contiguous = 23743) Context: 0x42302f70 ADPC3(re1.xxx. vty)# sh jtree 0 summary Protocol Routes Bytes Used - -- -- IPv4 303043 4363344 IPv62533 46112 MPLS 1 16 Multi-service 1 16 Also bonus points if anyone can tell me how to accomplish the following without having to do a virtual-router routing-instance, and protocol bgp under that. I'm trying to take in ~150k of routes from a bgp neighbor, install ~50k of them into inet.0 with one policy, and install ~100k of them into another routing-instance with another policy. I can't just import the ones I want out of a single routing-instance, since instance-import only pulls the active routes. I also can't inject the routes into a particular rib w/rib-groups, since the rib-group requires inet.0, and won't let you do a per-rib policy only a per-rib-group policy. The best solution I could come up with was to make a routing-instance type virtual-router solely for the neighbor in question, run the protocols bgp under that routing-instance, and then instance-import the 50k routes I want from that rib into inet.0, and instance-import the other 100k routes I want into another routing-instance. There are two problems with this, #1 it burns memory to have a routing-instance that exists solely so I can import routes from there into other routing-instances, and #2 it is a major pain in the $%^& for my groups and commit scripts to deal with the protocols bgp config under a different hierarchy. I'm thinking I could at least block the installation of the routes to fib with a forwarding-table export policy term (from instance provider-vr, then reject), since I'm not forwarding with that rib, but I'm hoping there is a cleaner solution out there that I'm not aware of, like some way to inject the routes from one bgp neighbor directly into the ribs I want without an extra "adj rib in" holding rib. -- 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] show route advertising-protocol on IPv6 peers
On Wednesday 16 December 2009 11:39:40 pm Daniel Verlouw wrote: > has anyone ever seen the behaviour below? I've been going > back and forth with JTAC for months now without any > result (which seems to be the norm nowadays...). We just > upgraded a few M-series boxes from 9.3 to 9.5R3 and the > issue still persists. It seems the issue was introduced > in one of the earlier 9.x releases. > > dan...@x> show route advertising-protocol bgp neighbor> error: timeout communicating with routing > daemon We've never seen this issue before. We have about 95% of our M7i/M10i routers running JUNOS 9.3R2.8, all with a full v6 table, no issues. The other 5% are running JUNOS 9.4R1.8 (yuk!), all with a full v6 table, no issues either. Control plane is an RE-850 with 1.5GB of DRAM, if that helps any. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] show route advertising-protocol on IPv6 peers
Hi all, has anyone ever seen the behaviour below? I've been going back and forth with JTAC for months now without any result (which seems to be the norm nowadays...). We just upgraded a few M-series boxes from 9.3 to 9.5R3 and the issue still persists. It seems the issue was introduced in one of the earlier 9.x releases. dan...@x> show route advertising-protocol bgp error: timeout communicating with routing daemon Dec 16 16:20:23.671 2009 X mgd[73749]: %INTERACT-6-UI_CMDLINE_READ_LINE: User 'daniel', command 'show route advertising-protocol bgp ' Dec 16 16:21:23.659 2009 X mgd[73749]: %DAEMON-5-UI_READ_TIMEOUT: Timeout on read of peer 'routing' It's most obvious with IPv6 neighbors receiving a full feed (+/- 2400 prefixes) from us, whereas the same command with an IPv4 neighbor receiving a full feed (>300k prefixes) is almost instantaneous. Cheers, Daniel. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper 10GE XFP
Thank you all. It is installed and working ;) Regards, Junaid On Wed, Dec 16, 2009 at 1:55 PM, Martin Levin wrote: > Yes, It does if the SFP is Juniper original (or coded as original). This > is from 10.0 and onwards, before that DOM doesn't exist on an EX. > > --- > Martin Levin > IT-strategy & planning > Mölndals stad > > > > > Från:"Jay Hanke" > Till:"'Chuck Anderson'" , > Datum:2009-12-16 01:02 > Ärende:Re: [j-nsp] Juniper 10GE XFP > Does it also work on a non uplink module ie EX 4200-24F? > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chuck > Anderson > Sent: Tuesday, December 15, 2009 4:41 PM > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Juniper 10GE XFP > > On Mon, Dec 14, 2009 at 03:53:16PM -0600, Jay Hanke wrote: >> The EX is a different animal, I think there is only support for DOM >> on the XFP ports unlike the MX where it is supported on all the SFP >> and XFP ports. Also, I think DOM support is recent (10.0?) on the >> EX. > > No, DOM works on SFP on EX4200 with 10.0. > > ex4200> show interfaces diagnostics optics ge-0/1/0 > Physical interface: ge-0/1/0 > Laser bias current : 23.140 mA > Laser output power : 0.2170 mW / -6.64 dBm > Module temperature : 47 degrees C / 117 > degrees > F > Module voltage : 3.2470 V > Receiver signal average optical power : 0.0006 mW / -32.22 > dBm > Laser bias current high alarm : Off > Laser bias current low alarm : Off > Laser bias current high warning : Off > Laser bias current low warning : Off > Laser output power high alarm : Off > Laser output power low alarm : Off > Laser output power high warning : Off > Laser output power low warning : Off > Module temperature high alarm : Off > Module temperature low alarm : Off > Module temperature high warning : Off > Module temperature low warning : Off > Module voltage high alarm : Off > Module voltage low alarm : Off > Module voltage high warning : Off > Module voltage low warning : Off > Laser rx power high alarm : Off > Laser rx power low alarm : On > Laser rx power high warning : Off > Laser rx power low warning : Off > Laser bias current high alarm threshold : 79.998 mA > Laser bias current low alarm threshold : 0.000 mA > Laser bias current high warning threshold : 69.998 mA > Laser bias current low warning threshold : 3.998 mA > Laser output power high alarm threshold : 0.7940 mW / -1.00 dBm > Laser output power low alarm threshold : 0.0790 mW / -11.02 > dBm > Laser output power high warning threshold : 0.6300 mW / -2.01 dBm > Laser output power low warning threshold : 0.1000 mW / -10.00 > dBm > Module temperature high alarm threshold : 85 degrees C / 185 > degrees > F > Module temperature low alarm threshold : -5 degrees C / 23 > degrees F > Module temperature high warning threshold : 80 degrees C / 176 > degrees > F > Module temperature low warning threshold : 0 degrees C / 32 > degrees F > Module voltage high alarm threshold : 3.599 V > Module voltage low alarm threshold : 3.000 V > Module voltage high warning threshold : 3.499 V > Module voltage low warning threshold : 3.100 V > Laser rx power high alarm threshold : 0.7943 mW / -1.00 dBm > Laser rx power low alarm threshold : 0.0079 mW / -21.02 > dBm > Laser rx power high warning threshold : 0.6309 mW / -2.00 dBm > Laser rx power low warning threshold : 0.0099 mW / -20.04 > dBm > > > ex4200> show interfaces ge-0/1/0 terse > Interface Admin Link Proto Local > Remote > ge-0/1/0 up down > ge-0/1/0.0 up down eth-switch > > ex4200> show chassis hardware > ... > PIC 0 BUILTIN BUILTIN 48x > 10/100/1000 > Base-T > PIC 1 REV 04 711-026017 4x GE SFP+ > Xcvr 0 REV 01 740-011614 . SFP-LX10 > > > ex4200> show chassis pic fpc-slot 0 pic-slot 1 > FPC slot 0, PIC slot 1 information: > Type 4x GE SFP+ > State Online > PIC version 1.4 > Uptime 18 hours, 12 minutes, 48 seconds > > PIC port information: > Fiber Xcvr vendor > Port Cable type type Xcvr vendor part number > Wavelength > 0 GIGE 1000LX10 SM OPNEXT INC TRF5736AALB214 > 1310 nm > > ___
[j-nsp] Invitation to connect on LinkedIn
LinkedIn zhonghai jin pidió añadirte como contacto en LinkedIn: -- Juniper, I'd like to add you to my professional network on LinkedIn. - zhonghai Aceptar invitación de zhonghai jin http://www.linkedin.com/e/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I467737091_3/6lColZJrmZznQNdhjRQnOpBtn9QfmhBt71BoSd1p65Lr6lOfPdvcjAMdPcTdPoQiiYQpA4OuCdjrOYQcPoUcj4QcPALrCBxbOYWrSlI/EML_comm_afe/ Ver invitación de zhonghai jin http://www.linkedin.com/e/XqZSB0oknt5cTYQCxwU5LkoQzUifoQRJSaUSlk19WH/blk/I467737091_3/0PnP4Vc3sPdPsSd4ALqnpPbOYWrSlI/svi/ -- ¿Por qué puede ser una buena idea conectar con zhonghai jin? La gente que conoce a zhonghai jin podría descubrir tu perfil: Conectar con zhonghai jin atraerá la atención de otros usuarios de LinkedIn. Averigua quién ha visto tu perfil: http://www.linkedin.com/e/wvp/inv18_wvmp/ -- (c) 2009, LinkedIn Corporation ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper 10GE XFP
Yes, It does if the SFP is Juniper original (or coded as original). This is from 10.0 and onwards, before that DOM doesn't exist on an EX. --- Martin Levin IT-strategy & planning Mölndals stad >>> Från:"Jay Hanke" Till:"'Chuck Anderson'" , Datum:2009-12-16 01:02 Ärende:Re: [j-nsp] Juniper 10GE XFP Does it also work on a non uplink module ie EX 4200-24F? -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Chuck Anderson Sent: Tuesday, December 15, 2009 4:41 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper 10GE XFP On Mon, Dec 14, 2009 at 03:53:16PM -0600, Jay Hanke wrote: > The EX is a different animal, I think there is only support for DOM > on the XFP ports unlike the MX where it is supported on all the SFP > and XFP ports. Also, I think DOM support is recent (10.0?) on the > EX. No, DOM works on SFP on EX4200 with 10.0. ex4200> show interfaces diagnostics optics ge-0/1/0 Physical interface: ge-0/1/0 Laser bias current: 23.140 mA Laser output power: 0.2170 mW / -6.64 dBm Module temperature: 47 degrees C / 117 degrees F Module voltage: 3.2470 V Receiver signal average optical power : 0.0006 mW / -32.22 dBm Laser bias current high alarm : Off Laser bias current low alarm : Off Laser bias current high warning : Off Laser bias current low warning: Off Laser output power high alarm : Off Laser output power low alarm : Off Laser output power high warning : Off Laser output power low warning: Off Module temperature high alarm : Off Module temperature low alarm : Off Module temperature high warning : Off Module temperature low warning: Off Module voltage high alarm : Off Module voltage low alarm : Off Module voltage high warning : Off Module voltage low warning: Off Laser rx power high alarm : Off Laser rx power low alarm : On Laser rx power high warning : Off Laser rx power low warning: Off Laser bias current high alarm threshold : 79.998 mA Laser bias current low alarm threshold: 0.000 mA Laser bias current high warning threshold : 69.998 mA Laser bias current low warning threshold : 3.998 mA Laser output power high alarm threshold : 0.7940 mW / -1.00 dBm Laser output power low alarm threshold: 0.0790 mW / -11.02 dBm Laser output power high warning threshold : 0.6300 mW / -2.01 dBm Laser output power low warning threshold : 0.1000 mW / -10.00 dBm Module temperature high alarm threshold : 85 degrees C / 185 degrees F Module temperature low alarm threshold: -5 degrees C / 23 degrees F Module temperature high warning threshold : 80 degrees C / 176 degrees F Module temperature low warning threshold : 0 degrees C / 32 degrees F Module voltage high alarm threshold : 3.599 V Module voltage low alarm threshold: 3.000 V Module voltage high warning threshold : 3.499 V Module voltage low warning threshold : 3.100 V Laser rx power high alarm threshold : 0.7943 mW / -1.00 dBm Laser rx power low alarm threshold: 0.0079 mW / -21.02 dBm Laser rx power high warning threshold : 0.6309 mW / -2.00 dBm Laser rx power low warning threshold : 0.0099 mW / -20.04 dBm ex4200> show interfaces ge-0/1/0 terse Interface Admin Link ProtoLocal Remote ge-0/1/0updown ge-0/1/0.0 updown eth-switch ex4200> show chassis hardware ... PIC 0 BUILTIN BUILTIN 48x 10/100/1000 Base-T PIC 1 REV 04 711-026017 4x GE SFP+ Xcvr 0 REV 01 740-011614 . SFP-LX10 ex4200> show chassis pic fpc-slot 0 pic-slot 1 FPC slot 0, PIC slot 1 information: Type 4x GE SFP+ StateOnline PIC version 1.4 Uptime 18 hours, 12 minutes, 48 seconds PIC port information: FiberXcvr vendor Port Cable typetype Xcvr vendorpart number Wavelength 0 GIGE 1000LX10 SMOPNEXT INC TRF5736AALB214 1310 nm ___ 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.n
