Re: [j-nsp] DHCPv6 Relay Prefix Delegation
I believe PD routes will be access route preference 13. DCHPv6 IA_NA routes will be access-internal preference type 12, like their IPv4 counterpart. Bjørn Aaron1 via juniper-nsp writes: > When you look in the route table, do you see the v6 PD routes there? If so, > are they access-internal route preference type 12? If so, perhaps create an > ospf3 export policy matching on that to get them advertised > > BTW, I fixed my v6 neighbor discovery with the windows pc… I bounced the > ethernet port on the ACX 5048 connected to the PC and apparently that woke up > the V6 neighbor discovery process. > > Aaron > >> On Jun 19, 2024, at 2:47 PM, Jan Bacher via juniper-nsp >> wrote: >> >> I am converting an older IOS-XE configuration to JunOS in a dual stack >> environment. >> >> What configuration statement(s) do I need to automatically import prefix >> delegations into ospf3? I see the WAN and PD in the relay bindings but no >> advertisement of the PD. >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DHCP server recommendation for subscribers management
Andrey Kostin via juniper-nsp writes: > Bjørn Mork via juniper-nsp писал 2021-08-06 15:27: >> Probably stupid question, but here goes... How does a central server >> make the IP usage more effective? Are you sharing pools between >> routers? > > Yes, going to have at least two routers as BNG and trying to find a > way to not lock IP addresses if they aren't needed. Yes, can make sense in some scenarios. Main problem is the number of host routes you must carry in your network, unless you have a level where you can aggregate routes from those BNGs. >> In any case, you can do that with a sufficiently smart RADIUS server >> too. You don't have to let JUNOS manage the address pools even if >> it is >> providing the DHCP frontend. > > I understand that it could be an option, but for vlan-per-customer > model radius authentication isn't really needed for DHCP clients. Auth > is done for a parent VLAN-demux interface, so for DHCP sessions BNG > will send only accounting. In this case it will require to develop > "smart-enough" radius backend. If there is any solution already > available I'd definitely look at it, but I'd try to avoid building a > homebrew solution. I don't know where to draw the line between config and programming, but RADIUS pool management exists as a feature: https://networkradius.com/doc/3.0.10/raddb/mods-available/ippool.html >> IMHO, having the DHCP frontend on the edge makes life so much easier. >> Building a sufficiently redundant and robust centralized DHCP >> service is >> hard. And the edge router still has to do most of the same work >> anyway, >> relaying broadcasts and injecting access routes. The centralized DHCP >> server just adds an unneccessary single point of failure. > > I agree that it's a complication, but imo it's a reasonable tradeoff > for effective IP space usage. For relatively big IP pools it would be > sufficient saving. From KEA DHCP server documentation I see that > different scenarios for HA are supported, so some redundancy can be > achieved. IMHO, DHCP server failover has traditionally created more problems than it solved. But I have no experience with KEA, so let's hope it's just working now. > Another question that puzzles me is how to use multiple discontinuous > pools with DHCP server. With Junos internal DHCP I can link DHCP pools > in the same way as for PPPoE and just assign additional GW IP to > lo0. With that Junos takes care of finding available IP in pools and > use proper GW address. In case of external DHCP server, router has to > insert relay option but how can it choose what subnet to use in this > case if there are more than one available? This problem should be also > actual for big cable segments, although for cable interface IP > addresses are directly configured on the interface, but for Junos BNG > a customer-facing interface is unnumbered. The subnet choice is always up to the DHCP server. You create a shared network with all the subnets and ranges that are supposed to share pools. This is similar to the linked pool in JUNOS. The server will select a free address in this shared network if the giaddr matches one of the configured subnets. Note that there doesn't have to be mathing range if you don't want to share giaddr and client subnets. All routers sharing a pool must have all the same GW addresses configured on lo0. I don't think this is any different whether you use the local DHCP server with RADIUS shared pool or a centralized DHCP server shared pool. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DHCP server recommendation for subscribers management
Andrey Kostin writes: > Bjørn Mork via juniper-nsp писал 2021-08-06 12:38: >> Andrey Kostin via juniper-nsp writes: >> >>> What DHCP server do you use/would recommend to deploy for subscriber >>> management? >> The one in JUNOS. Using RADIUS as backend. >> > > Thanks, currently using it but looking for a central server for more > effective IP usage. Probably stupid question, but here goes... How does a central server make the IP usage more effective? Are you sharing pools between routers? In any case, you can do that with a sufficiently smart RADIUS server too. You don't have to let JUNOS manage the address pools even if it is providing the DHCP frontend. IMHO, having the DHCP frontend on the edge makes life so much easier. Building a sufficiently redundant and robust centralized DHCP service is hard. And the edge router still has to do most of the same work anyway, relaying broadcasts and injecting access routes. The centralized DHCP server just adds an unneccessary single point of failure. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] DHCP server recommendation for subscribers management
Andrey Kostin via juniper-nsp writes: > What DHCP server do you use/would recommend to deploy for subscriber > management? The one in JUNOS. Using RADIUS as backend. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunOS interop problems with RFC5549
Brian Rak writes: > They both negotiate the Extended next hop capability, and JunOS > accepts the routes just fine if I make Cumulus only send 16 byte > nexthops (still IPv6, just not containing a link-local address) Ah, right. And the RFC2545 requirements are also fulfilled?: The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunOS interop problems with RFC5549
Brian Rak writes: > I'm running into an issue where JunOS will not accept BGP updates > containing a MP_REACH_NLRI attribute with a 32 byte nexthop. As soon > as I send one, the session gets closed and the following logged: > > rpd[16187]: bgp_read_v4_update:12111: NOTIFICATION sent to > fe80::ae1f:6bff:fe8a:435d (External AS 64555): code 3 (Update Message > Error) subcode 9 (error with optional attribute) > rpd[16187]: Received malformed update from fe80::ae1f:6bff:fe8a:435d > (External AS 64555) > rpd[16187]: Family inet-unicast, prefix 0.0.0.0/0 > rpd[16187]: Malformed Attribute MP_REACH(14) flag 0x80 length 42. > > The other end of the BGP session is a Cumulus router (or a linux > machine running FRR). If I patch that end to only send 16 byte > nexthops, JunOS accepts the route and seems to work just fine. > > RFC5549 states: > >> o Length of Next Hop Address = 16 or 32 >> o Next Hop Address = IPv6 address of next hop (potentially followed > by the link-local IPv6 address of the next hop). This field is to > be constructed as per Section 3 of [RFC2545]. and also: A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4 NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained via BGP Capability Advertisement that the BGP peer supports the Extended Next Hop Encoding capability for the relevant AFI/SAFI pair. And I guess your Cumulus router failed to do this? Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Chris Morrow writes: > tls brings with it cert issues. Well. How bad does it have to be? Yes, you have to manage private keys. That's the same for TCP-AO, SSH and TLS. Or any other transport security protocol. No real difference. I assume the perceived issue with TLS is that private keys have short life spans? But they don't have to in a RPKI setup. You will want to manage the CA(s) yourself, and can implement the policies you need. If you want keys with "infinite" life spans, then that's possible. The servers validating router certificates can easily check revoked keys, using a simple CRL or whatever. So you can issue a certificate to your router and just forget about ever updating it, just like you do with all your other passwords ;-) The only difference is that there is a way to actually withdraw that password. TLS is nice. Don't be fooled by all the lousy infrastructure implementations. Certificate management does not have to suck. And there is no reason to believe that TCP-AO key management will suck less - until we've seen it implemented. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Chris Morrow writes: > On Wed, 26 Dec 2018 14:11:19 -0500, > sth...@nethelp.no wrote: >> >> Now if Juniper could implement TCP-AO and then donate the implementation >> to FreeBSD? :-) > > This was sort of my point, yes. > Thanks, as always for your cogent point(s). I don't follow FreeBSD development, but googling for TCP-AO implementations a couple of months ago led me to believe they already did? Ref https://lists.freebsd.org/pipermail/freebsd-transport/2016-March/000101.html I'm sure someone will set me straight now ;-) > -chris > (without something to break the ao logjam we'll just keep on having > this argument, maybe we can isntead paste-bin this thread and just > refer all other callers there? :) ) The fact that the work was mostly done 10 years ago, but no one has bothered to finish the job, shows us what we should expect of the next 10 years: https://marc.info/?l=linux-netdev=121642691623828 https://marc.info/?l=linux-netdev=121642691723832 https://marc.info/?l=linux-netdev=121642691823836 I don't know why Adam never pushed this patch set further. There weren't any major objections to it AFAICS. Maybe I'm missing something? Getting traction after losing it is hard. The problem now is that even if you took this code, rebased it to current net-next and did the necessary fixups, then it would go into Linux v4.22 (or 5.whatever) released in April 2019. The feature would then go into the next major distro releases *after* the releases which are already being prepared for 2019. This means TCP-AO might be available for applications running on plain Debian stable or RHEL kernels in 2021. And that's being a bit of an optimist... Yes, another alternative is obviously running TCP in userspace. But I will gladly go to certificate hell if I can avoid that. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] About Secure Transport for RPKI on JUNOS
Chris Morrow writes: > On Sun, 23 Dec 2018 16:15:24 -0500, > Melchior Aelmans wrote: >> >> Hi Pyxis, >> >> On Sat, Dec 22, 2018 at 8:58 AM Pyxis LX wrote: >> >> > Does JUNOS support any secure transports mentioned in RFC6810 for rpki-rtr >> > protocol? (SSHv2/IPsec or TLS for rpki-rtr-tls?) >> > >> >> We are discussing internally what secure transport method to support. I'm >> happy to hear your ideas. > > 'tcp-ao' - yes... srsly. Huh? Why? No support on any server OS, AFAIK. Yes, there were patches for FreeBSD and Linux a few years ago, but I don't think they went anywhere? This will severely limit the usability. Let's have ssh, and optionally tls. We need something we can run on a server today. Not 8 year old foilware. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Helo Juniper, your docs need work..
Olivier Benghozi olivier.bengh...@wifirst.fr writes: By the way in current JunOS 12.3 it looks there's at least one fix; in: http://www.juniper.net/documentation/en_US/junos12.3/topics/concept/firewall-filter-ex-series-overview.html Yes, if there is one lesson I've learned the hard way about Juniper docs: They never correct errors in old documentation. At least it looks that way from the outside. Which means that you always should read the docs for the latest release no matter what version you actually use. You will of course have to keep your eyes open wrt actual feature changes. But that's much easier and less frustrating than stumbling through lots of already known and fixed doc bugs. There rarely are that many new features ;-) And the important ones tend to be flagged in a way that makes it obvious that they are new. So forget about the 12.1 and 12.3 docs. Read the 14.1 or whatever is the latest release for these things. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Security bugs in documentation
Julien Goodwin jgood...@studio442.com.au writes: On 30/10/12 20:21, Bjørn Mork wrote: Using an open source viewer, all I see in that document is a single page displaying For the best experience, open this PDF portfolio in Acrobat 9 or Adobe Reader 9, or later. and a link to Get Adobe Reader Now!. And sure enough, inspecting the pdf shows that it is a 5MB single page document: Evince (the Gnome PDF reader) recently got the ability to view these, it's somewhat non-obvious, but I figured it out when I downloaded $DWDMVENDOR's documentation which was all in this format (last time I encountered it was more then a year ago with $POWERSYSTEMSVENDOR when I had to figure out how to extract files with pdftk, much easier now) In the evince sidebar (Which normally shows Thumbnails or Index) select Attachments and you can then read the sub-PDFs. Thanks. That did the trick. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Security bugs in documentation
Yes, documentation itself maybe be a security risk... I am more than a bit pissed after attemting to view http://www.juniper.net/techpubs/en_US/junos12.2/information-products/topic-collections/config-guide-firewall-filter/config-guide-firewall-policer.pdf Using an open source viewer, all I see in that document is a single page displaying For the best experience, open this PDF portfolio in Acrobat 9 or Adobe Reader 9, or later. and a link to Get Adobe Reader Now!. And sure enough, inspecting the pdf shows that it is a 5MB single page document: bjorn@nemi:~/tmp$ pdfinfo config-guide-firewall-policer.pdf Title: Firewall Filter and Policer Configuration Guide Author: Juniper Networks Creator:Adobe Acrobat Pro 9.3.0 Producer: Adobe Acrobat Pro 9.3.0 CreationDate: Fri Jul 6 16:05:23 2012 ModDate:Fri Jul 6 16:07:53 2012 Tagged: yes Pages: 1 Encrypted: no Page size: 504 x 360 pts File size: 5257154 bytes Optimized: no PDF version:1.7 Yes, I understand what is going on here and I DO NOT APPROVE. I considere the above a malicious attempt to force me to use software I do not want to use. It is no better than any other phishing attemt. I was wondering if I should open a case with JTAC for this, but I fear that would only be ignored. This really deserves public humiliation. So, please Juniper and others: Do not use any Abobe program ever. They are deliberately buggy like demonstrated above, creating faulty documents which can only be read by their own buggy readers. If you continue distributing your documentation infected by the Adobe phishing virus, then I will have to manage without your documentation. That's a pity, because I think it will make it very diffcult for me to work with any Juniper equipment. I am sure you can figure out where that is going to end. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] GPL licensed software in juniper products
Thomas Eichhorn t...@te3networks.de writes: has anybody here asked JNPR for the source code of the GPL-licensed parts in their products? I currently just wonder which all parts they have used and maybe if there is some hidden web page containing that stuff. I don't want to go snail mailing them, as there EULA requires me - anybody with experiences in this? I don't think it ever *required* this. The text used may, indicating that this was an option but not necessarily the only one. Anyway, the snail mail suggestion is not there anymore: http://www.juniper.net/support/eula/ quote 17. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement, and such licensor or vendor shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such portions publicly available (such as the GNU General Public License (GPL) or the GNU Library General Public License (LGPL)), Juniper will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three years from the date of distribution. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL at http://www.gnu.org/licenses/lgpl.html. Open source information and information on contacting Juniper can be found at http://www.juniper.net/support/products/ as applicable. /quote So request the source the same way you would request an image, just like the GPL gives you the right to. I.e., open a JTAC case. Did you try this? Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] FreeRadius/ERX Question
Paul Stewart p...@paulstewart.org writes: We are trying to get a lite profile working on ERX platform for PPPOE clients. This would restrict their download/upload speeds on a per user basis via Radius attributes. I have a ticket running at JTAC now for a long time on this - they have now come back and told me I must run Unisphere attributes instead of ERX attributes from Radius. We are using FreeRadius FYI. They are probably referring to their official Steel-Belted Radius dictionary, which names the attributes like that. See e.g http://www.juniper.net/techpubs/software/junos/junos112/radius-dictionary/unisphereDictionary_for_JUNOS_v11-2.dct (for some reason the JUNOSe dictionary links now requires login while the one JUNOS dictionaries still can be downloaded by anyone, including the above vendorid 4874 one, which applies to both the ERX and the MX subscriber platform. Strange). Am I doing something wrong here? I checked and all the dictionary files appear to be intact including those attributes . seems like a FreeRadius issue possibly. The default FreeRADIUS dictionary use the ERX prefix everywhere, regardless of whether Juniper uses Unisphere, ERX or the recent Jnpr prefix. I am not sure which solution is least confusing. But I do not fancy having a mix of vendor prefixes in the same vendor specific dictionary. And Terje started the show by changing the Unisphere names to ERX int the first place. So when I recently sent an update to FreeRADIUS for the attributes added in JUNOS 11.2, I chose to continue using the ERX prefix despite Juniper using Jnpr. Anyway, if in doubt, check the actual attribute numbers. Anyone else doing something similar? Are you using these attributes? When we use ERX-Ingress-Policy-Name we can see the policy appearing on a debug with the ERX box but it doesn't work. ERX-Ingress-Policy-Name is correct. Define doesn't work. It is supposed to work. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper E Series, VRF assignment from RADIUS
Liam Murphy liam.mur...@easynet.com writes: I am setting up a Juniper E320 as a BRAS and have successful connectivity with users and routes being assigned from a RADIUS server. I want to continue using the default-router but want to be able to assign connecting users into different VRFs. Does anyone know how to do this in the RADIUS setup? (i.e. what the RADIUS attribute for this is?) ERX-Virtual-Router-Name if you're using FreeRADIUS with default dictionaries. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Radius - Static IP / ERX
Chris Adams cmad...@hiwaay.net writes: Once upon a time, Paul Stewart p...@paulstewart.org said: Getting ready to cut an ERX into production shortly and the only thing not working is static IP assignments via Radius. According to the docs, you can use Framed-IP-Address the same as we do in Cisco land today.. but it doesn't' work. Your example entry doesn't have a Framed-IP-Netmask set, which may be required. No, it's not if yoy want it to be /32. I just verified on a E320 running JUNOSe 10.1.2, and setting Framed-IP-Address does work as expected there. Using the following FreeRADIUS account: foo Cleartext-Password := bar Framed-IP-Address := 192.168.5.5 I get: e320#show subscribers username foo Subscriber List --- Virtual User Name Type Addr|Endpt Router Interface Login Time Circuit Id Remote Id --- - --- --- foo ppp 192.168.5.5/radius default GigabitEthernet 3/1/3.9:9 11/08/12 10:24:10 e320#sh ip route 192.168.5.5 Protocol/Route type codes: I1- ISIS level 1, I2- ISIS level2, I- route type intra, IA- route type inter, E- route type external, i- metric type internal, e- metric type external, P- periodic download, O- OSPF, E1- external type 1, E2- external type2, N1- NSSA external type1, N2- NSSA external type2 L- MPLS label, V- VRF, *- via indirect next-hop Prefix/Length Type Next Hop Dst/Met Interface -- - --- -- 192.168.5.5/32 AccIntern 0.0.0.0 2/0 GigabitEthernet3/1/3.9.12 You could turn on a bit of debugging. The test aaa command is also useful for eliminating the obvious. E.g. something like this (which is very easy to hit during testing of static IP accounts): e320#test aaa ppp foo bar Authentication Deny reason = Address assignment failure reply msg: duplicate address detected Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPv6 for PPP customers on ERX310
Amos Rosenboim a...@oasis-tech.net writes: ipv6 nd prefix-advertisement 2a02:ed0:1002:1::/64 3600 3000 autoconfig You may want to add onlink here Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Access to SNMP-Indexes outside the current routing-instance (Cross RI SNMP-Access)
Hendrik Kahmann hendrik.kahm...@ewetel.de writes:
I've got a J-Series with two routing-instances configured (voice, data). I
want to access all SNMP-Variables over the instance 'data'. For the
interfaces belonging to this instance everything works fine but I am not
able to access snmp-variables inside the instance 'voice' from here. I want
to check the interface counters of all uplink interfaces (some 'data', some
'voice').
Do I really need a separate snmp-uplink inside the instance 'voice' or am I
able to configure an access-list or something else to do this cross-connect?
My current configurations looks like this:
snmp {
view if-only {
oid .1.3.6.1.2.1;
}
community temporary-ro {
view if-only;
authorization read-only;
clients {
0.0.0.0/0;
}
routing-instance l3vpn-data;
}
routing-instance-access;
}
as long as you've got
snmp {
routing-instance-access;
}
you can use routing-instance@community as community when querying
a specific routing-instance. E.g.
snmpwalk -v2c -c vo...@public myrouter ifName
to get a list of interface names in the voice routing-instance of
myrouter using the public community.
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Need help on C2000 license server startup error
Joe Shen sj_h...@yahoo.com.cn writes: Caused by: java.io.IOException: Could not connect to the license directory 127.0.0.1:389 I've left just the relevant part of your trace. Guess you can figure it out from there. Either you don't run the jdb component (using a remote directory instead) or you've got the wrong credentials for the license service. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Internal Server Error on http://www.juniper.net/customers/support/
Trying to reach someone with the power to fix this... I did send a mail to web-feedb...@juniper.net, but has so far got no answer and the problem persists. I assume this problem is not local as it looks the same from two different ASes: bj...@nemi:~$ lynx -mime-header http://www.juniper.net/customers/support/ HTTP/1.0 500 Internal Server Error Content-Length: 675 Content-Type: text/html; charset=iso-8859-1 Server: Concealed by Juniper Networks DX Vary: Accept-Encoding Date: Mon, 05 Oct 2009 09:01:25 GMT Set-Cookie: CT_Akamai=georegion=165,country_code=NO,city=FORNEBU,lat=59.90,long=10.63,timezone=GMT+1,continent=EU,throughput=vhigh,bw=256,asnum=2119,location_id=0; path=/; domain=juniper.net !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title500 Internal Server Error/title /headbody h1Internal Server Error/h1 pThe server encountered an internal error or misconfiguration and was unable to complete your request./p pPlease contact the server administrator, web-feedb...@juniper.net and inform them of the time the error occurred, and anything you might have done that may have caused the error./p pMore information about this error may be available in the server error log./p pAdditionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request./p /body/html bj...@huey:~$ lynx -mime-header http://www.juniper.net/customers/support/ HTTP/1.0 500 Internal Server Error Content-Length: 675 Content-Type: text/html; charset=iso-8859-1 Server: Concealed by Juniper Networks DX Vary: Accept-Encoding Date: Mon, 05 Oct 2009 09:01:41 GMT Connection: close Set-Cookie: CT_Akamai=georegion=2,country_code=GB,region_code=EN,city=LONDON,lat=51.50,long=-0.12,timezone=GMT,continent=EU,throughput=vhigh,bw=256,asnum=31463,location_id=0; path=/; domain=juniper.net !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title500 Internal Server Error/title /headbody h1Internal Server Error/h1 pThe server encountered an internal error or misconfiguration and was unable to complete your request./p pPlease contact the server administrator, web-feedb...@juniper.net and inform them of the time the error occurred, and anything you might have done that may have caused the error./p pMore information about this error may be available in the server error log./p pAdditionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request./p /body/html Hoping for a fix RSN... Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] C2000 and E320 interaction problem
Joe Shen sj_h...@yahoo.com.cn writes:
hi,
we use C2000 with E320 to provide web based authentication service.
On a new site we found C2000 could not control E320 even after we
tried to configure both sides serval times.
If E320 is configured with
' sscc enable' , client could acquire IP address by DHCP (DHCP server
runs on E320) but no access control policy is pushed to sub-interface
, so our customer could accesss internet without any authentication ;
if E320 is configured with 'sscc enable cops-pr', client could not
get IP address at all. At this time , C2000 logs like
I would strongly recommend always using COPS PR, to enable shared
policies etc. But I guess you already knew that, and that using XDR was
just for testing.
'21:17:56.322 CST 29.09.2009 [CopsHandler-165/0x30003625] [AddressCtx] [10]
Will refuse address since SAP JunosESap { routerName =
vr_w...@bas-e320-3.man, interfaceName = GigabitEthernet12/0/2.13311073} is
not managed;
While, the interface is surely configured to be managed by C2000.
Would anybody do some favor to give some hints?
Does
C2K-2 show configuration shared network device BAS-E320-3.MAN
interface-classifier
give you anything useful? How do you decide which interfaces should be
managed?
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] passing RSA keys via Radius
Noah Garrett Wallach noah-l...@enabled.com writes: Is it really necessary to have RSA Auth Manager? I am hoping that I can send a key from any radius server to the Juniper. is that at all possible? I wonder if there was some confusion wrt what you're trying to achieve. I assume that you want to let RADIUS return a RSA public key which the router can use for ssh key authentication? If so, then I'm afraid it can't be done with JUNOS. At least I've searched for the same feature without finding it... There is no standardized RADIUS attribute for this AFAIK, and the list of Juniper VSAs does not include any such attribute either: http://www.juniper.net/techpubs/software/junos/junos93/swconfig-system-basics/configuring-radius-authentication.html Too bad. Having to configure all routers with the public keys of all users makes it unnecessarily difficult to use ssh key authentication. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRRP in Olive?
Patrick Lynchehaun patr...@lynchehaun.net writes: Bjørn Tks for this link. Got a reply from Sten Weil with an updated link: http://repo.or.cz/w/qemu/ar7.git?a=blob;f=hw/eepro100.c The quick/dirty fix below works for mcast traffic with current qemu cvs. Yes, but it probably doesn't stand much chance of ever being integrated, as it's plain wrong. Also the eepro100.c firmware is from 2007 from the current qemu cvs, what do we have to update/if any in this driver http://svn.berlios.de/viewcvs/ar7-firmware/qemu/trunk/hw/eepro100.c to allow mcast traffic, any improvements in performance. I guess the improvements are mostly theoretical. I haven't bothered measuring. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRRP in Olive?
pat lynch patr...@lynchehaun.net writes:
Since previous entries in other wikis, qemu's main tree has all of the
support on the ethernet adapter side, multicast side, etc, to work natively
out of the box.
No, it does not. There is no support for setting the multicast list in
the default QEMU/KVM eepro100 driver, and it will therefore ignore all
multicast frames.
In Qemu version 0.9.1, Stefan's multicast code has a check which i'm still
decoding to solve properly that exits nic_receive before multicast frames
make it to the CPU. I'm no developer, but this simple workaround will enable
native qemu without any patch files, shady chinese translated forums, or
modifications of jemu code.
Obtain the qemu source from the project website. The file hw/eepro100.c as
of 0.9.1 has this line in the function nic_receive, comment the 'return'
out.
int mcast_idx = compute_mcast_idx(buf);
if (!(s-mult[mcast_idx 3] (1 (mcast_idx 7 {
//Commented out by JP Senior (sartan) Wed June 23 2008, this
needs to be fixed
//return;
}
This will make the driver process *all* multicast frames, which will
sort of work, yes. But there are better approaches. Stefan Weil has
made several improvements to the driver since it was added to QEMU. His
version at
http://svn.berlios.de/viewcvs/ar7-firmware/qemu/trunk/hw/eepro100.c
has, among other stuff, a working set_multicast_list() function.
I'm hoping we can get these features merged into QEMU/KVM soon. But it
will take some work, as the versions have diverged quite a bit and the
improvements probably need to be split up in at least 4 parts before
merging:
1) multicast support
2) PXE booting
3) endianness fixes
4) misc
I asked Stefan about his plans for the driver in March 2008, and got a
reply that he wanted to clean up a few things before pushing it
upstream. I sent him a new email today, asking about the status and
whether he would be OK with e.g. me splitting out the multicast fix and
pushing it. I'd really like to get that into KVM before Debian freezes
again. But now this is getting a bit OT, I guess...
There is no Olive, you know :-)
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Add vlan to multiple interfaces on EX series
Cord MacLeod cordmacl...@gmail.com writes:
Park yourself in edit vlans vlan xxx
The run this on your local Linux machine:
for i in `seq 0 23`; do echo set interface ge-0/0/$i; done
Or just do it on the system everyone has:
% uname -sr
JUNOS 9.5R2.7
% awk 'BEGIN {for (x=0; x=23; x++) print set interface ge-0/0/ x}'
set interface ge-0/0/0
set interface ge-0/0/1
set interface ge-0/0/2
set interface ge-0/0/3
set interface ge-0/0/4
set interface ge-0/0/5
set interface ge-0/0/6
set interface ge-0/0/7
set interface ge-0/0/8
set interface ge-0/0/9
set interface ge-0/0/10
set interface ge-0/0/11
set interface ge-0/0/12
set interface ge-0/0/13
set interface ge-0/0/14
set interface ge-0/0/15
set interface ge-0/0/16
set interface ge-0/0/17
set interface ge-0/0/18
set interface ge-0/0/19
set interface ge-0/0/20
set interface ge-0/0/21
set interface ge-0/0/22
set interface ge-0/0/23
That's the way I mass edit.
Seriously though, you should do mass edits. Or edits at all. You
should use an offline configuration system and upload configuration
diffs from these system after following some sort of quality assurance
procedure. Direct edits are bound to give errors.
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Add vlan to multiple interfaces on EX series
Chuck Anderson c...@wpi.edu writes: On Fri, Jul 10, 2009 at 11:53:13AM +0200, Bjørn Mork wrote: Seriously though, you should do mass edits. Or edits at all. You should use an offline configuration system and upload configuration diffs from these system after following some sort of quality assurance procedure. Direct edits are bound to give errors. I would love to hear about systems people are using to do this. Are they custom or off-the-shelf? Who makes the software? We use or own home-brewed, loosely based on JUNOScript. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Using XML to query Junos
Bit Gossip bit.gos...@chello.nl writes: Experts, do you have pointers or examples on how to use XML to fetch data instead of snmp? http://www.juniper.net/support/xml/ IE I would like the output of this snmpwalk in a single XML document... l...@rc2 show snmp mib walk ifAlias Try show snmp mib walk ifAlias | display xml Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] switching to superuser after a logging in as a normal user
Chris Grundemann cgrundem...@gmail.com writes: On Thu, Feb 5, 2009 at 00:11, Samit janasa...@wlink.com.np wrote: Is there any way I can login to the router as a normal user and then switch to superuser by doing su something similar like in unix systems? with tacacs+ or without tacacs+. You can use su from the shell and then if wanted go back to the cli (depending of course on your user permissions). for example: m...@rtr start shell % su Password: r...@rtr% cli m...@rtr or just bj...@olive2 start shell user root Password: r...@olive2% Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX DHCP MIB?
Kari Asheim k...@mork.no writes:
On Tue, Jan 13, 2009 at 02:43:51PM +0100, Bjørn Mork wrote:
How about using juniAddressPoolInUse from
http://www.oidview.com/mibs/4874/Juniper-ADDRESS-POOL-MIB.html
instead?
According to the MIB itself, this MIB is deprecated. Also, it reports
reports only the 'first' pool. It definetely reports all pools on my
router, but this text may indicate that it will not be supported in
the future.
juniAddressPoolInUse OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS deprecated
Thanks. Didn't notice that.
DESCRIPTION
The number of addresses currently allocated from the 'first' pool
profile entry. This object is deprecated in favor of
juniAddressPoolProfileInUse because it applies to a single address
range
and can only show one of possibly many address ranges found in the
newer
juniAddressPoolProfileTable. The value in this table maps to the
value
in the juniAddressPoolProfileTable for the entry with
juniAddressPoolProfileIndex equal to 1.
::= { juniAddressPoolEntry 7 }
Damn. I actually find the current behaviour quite useful. See this
sample from a router with a single ppp pool with multiple address ranges
(router is an E320 running JUNOSe 7.3.4):
bj...@server:~$ snmpwalk -v2c -c comm router .1.3.6.1.4.1.4874.2.2.21
Juniper-ADDRESS-POOL-MIB::juniAddressPoolRowStatus.1 = INTEGER: active(1)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolName.1 = STRING: adsl
Juniper-ADDRESS-POOL-MIB::juniAddressPoolStart.1 = IpAddress: 0.0.0.0
Juniper-ADDRESS-POOL-MIB::juniAddressPoolEnd.1 = IpAddress: 0.0.0.0
Juniper-ADDRESS-POOL-MIB::juniAddressPoolSize.1 = INTEGER: 3574
Juniper-ADDRESS-POOL-MIB::juniAddressPoolInUse.1 = INTEGER: 2178
Juniper-ADDRESS-POOL-MIB::juniAddressPoolHighUtilThreshold.1 = INTEGER: 85
Juniper-ADDRESS-POOL-MIB::juniAddressPoolAbatedUtilThreshold.1 = INTEGER: 75
Juniper-ADDRESS-POOL-MIB::juniAddressPoolUtilPct.1 = INTEGER: 60
Juniper-ADDRESS-POOL-MIB::juniAddressPoolTrapEnable.1 = INTEGER: false(2)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolNextPoolProfileIndex.1 = INTEGER: 0
Juniper-ADDRESS-POOL-MIB::juniAddressPoolNextPoolIndex.0 = INTEGER: 0
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileRowStatus.1.15 = INTEGER:
active(1)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileRowStatus.1.16 = INTEGER:
active(1)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileRowStatus.1.18 = INTEGER:
active(1)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileRowStatus.1.19 = INTEGER:
active(1)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileRowStatus.1.20 = INTEGER:
active(1)
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileStart.1.15 = IpAddress:
10.89.195.1
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileStart.1.16 = IpAddress:
10.90.122.1
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileStart.1.18 = IpAddress:
10.164.144.1
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileStart.1.19 = IpAddress:
10.109.44.1
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileStart.1.20 = IpAddress:
10.167.24.1
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileEnd.1.15 = IpAddress:
10.89.195.254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileEnd.1.16 = IpAddress:
10.90.122.254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileEnd.1.18 = IpAddress:
10.164.147.254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileEnd.1.19 = IpAddress:
10.109.47.254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileEnd.1.20 = IpAddress:
10.167.27.254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileSize.1.15 = INTEGER: 254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileSize.1.16 = INTEGER: 254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileSize.1.18 = INTEGER: 1022
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileSize.1.19 = INTEGER: 1022
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileSize.1.20 = INTEGER: 1022
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileInUse.1.15 = INTEGER: 254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileInUse.1.16 = INTEGER: 254
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileInUse.1.18 = INTEGER: 1021
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileInUse.1.19 = INTEGER: 647
Juniper-ADDRESS-POOL-MIB::juniAddressPoolProfileInUse.1.20 = INTEGER: 2
The juniAddressPoolStart and juniAddressPoolEnd are of course useless
and you have to look at the juniAddressPoolProfileStart and
juniAddressPoolProfileEnd tables instead for the actual address ranges.
juniAddressPoolSize and juniAddressPoolInUse reports the totals for the
pool, which are the only numbers I'm really interested in. We could of
course sum up the per range numbers, but I fail to see why that should
be necessary. I hope we can keep juniAddressPool{Size,InUse}.
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX DHCP MIB?
Bjorn Tore Paulen b...@paulen.net writes: RIPE is eager to know the number of IPs I use at a given time. I can graph percent of pool (MRTG - juniDhcpLocalServerPoolUtilPct), but it seems that the OID I want isn't supported. Could this be a version issue? I run 8.2.3. Regarding http://www.oidview.com/mibs/4874/Juniper-DHCP-MIB.html the OID I'd want probably is juniDhcpLocalServerPoolInUse (1.3.6.1.4.1.4874.2.2.22.1.3.3.1.1.19) How about using juniAddressPoolInUse from http://www.oidview.com/mibs/4874/Juniper-ADDRESS-POOL-MIB.html instead? we don't use dhcp local server, but I assume the results will be the same as for ppp: bj...@server:~$ snmpwalk -v2c -c comm router .1.3.6.1.4.1.4874.2.2.21.1.1.1.1 Juniper-ADDRESS-POOL-MIB::juniAddressPoolRowStatus.1 = INTEGER: active(1) Juniper-ADDRESS-POOL-MIB::juniAddressPoolName.1 = STRING: adsl Juniper-ADDRESS-POOL-MIB::juniAddressPoolStart.1 = IpAddress: 0.0.0.0 Juniper-ADDRESS-POOL-MIB::juniAddressPoolEnd.1 = IpAddress: 0.0.0.0 Juniper-ADDRESS-POOL-MIB::juniAddressPoolSize.1 = INTEGER: 3574 Juniper-ADDRESS-POOL-MIB::juniAddressPoolInUse.1 = INTEGER: 2213 Juniper-ADDRESS-POOL-MIB::juniAddressPoolHighUtilThreshold.1 = INTEGER: 85 Juniper-ADDRESS-POOL-MIB::juniAddressPoolAbatedUtilThreshold.1 = INTEGER: 75 Juniper-ADDRESS-POOL-MIB::juniAddressPoolUtilPct.1 = INTEGER: 61 Juniper-ADDRESS-POOL-MIB::juniAddressPoolTrapEnable.1 = INTEGER: false(2) Juniper-ADDRESS-POOL-MIB::juniAddressPoolNextPoolProfileIndex.1 = INTEGER: 0 Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper ip host equivalent
Aamir Saleem aamirw...@gmail.com writes: Experts: I am looking for Cisco ip host test 1.1.1.1 equivalent in junos. once configured one must be able to ping host test instaed of IP without defining DNS. bj...@router show configuration system static-host-mapping test inet 1.1.1.1; bj...@router ping test PING test (1.1.1.1): 56 data bytes ping: sendto: No route to host ^C --- test ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX - IP LOCAL POOL
le van cuong [EMAIL PROTECTED] writes: I'm currently test IP assignment based on Frame-Pool from Radius for ERX310-Version: 8.2.2 Subcriber is denied to access when returned attribute IP-Pool-X from radius for this user, but this pool is exhausted on local router. Any Solution to ship this subcriber to another pool on ERX? For example: Case: there are two ip local pools configured on router, each pool include only 2 IP addresses. Pool P1: 192.168.10.1-2 Pool P2: 192.168.20.1-2 Why split in two pools if you want any user to use any of the pools? Maybe you really want a single pool with multiple ranges? Like this: ip local pool P 192.168.10.1 192.168.10.2 ip local pool P 192.168.20.1 192.168.20.2 Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Hardware Details on M/T Series
Abhi [EMAIL PROTECTED] writes: Is their any command similar to show tech on Junos platform which can collect all the software and hardware details on M/T Series Chassis. request support information Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS Perl API version?
Richard A Steenbergen [EMAIL PROTECTED] writes:
On Sat, Jul 05, 2008 at 09:51:35AM -0700, Shane Ronan wrote:
For us uninitiated, what is contained in this API?
At this point there is no real reason to keep running junoscript, it has
been replaced by the standardized multi-vendor version called netconf.
http://www.juniper.net/support/xml/netconf/index.html
I personally wish they wouldn't roll a new version with every junos
release, since the perl API rarely changes, and then when it does you have
no idea that an important change has occured.
Or that a less important change still may screw up existing
installations. Like a semi-recent change to JUNOS::Access::telnet,
which is shared between all versions and overwritten by default on every
install. It has the ugliest bit of buggy perl code I've ever seen:
my $script = use Expect; .
my \$exp = Expect-spawn(\telnet\); .
if (\$exp-expect($timeout_value, '-re', \telnet\)) { .
print \$exp \unset autologin\\r\ ; .
if (\$exp-expect($timeout_value, '-re', \telnet\)) { .
print \$exp \open $self-{hostname}\\r\ ; .
if (\$exp-expect($timeout_value, '-re', \[lL]ogin:\)) { .
print \$exp \$self-{login}\\r\ ; .
if (\$exp-expect($timeout_value, '-re', \[pP]assword:\)) { .
print \$exp \$self-{password}\\r\ ; .
\$exp-interact(); .
} .
} .
} .
};
my $command = perl -e ' . $script . ';
This will of course break for a number of reasons. I won't even try to
list them all.
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX1440, how to limit login to be able to show conf only
Joe Shen [EMAIL PROTECTED] writes: we are trying to set up ERX1440/E320 configuration backup and monitoring system. The system is implemented to fetch E320/E1440 configuration file every day. In order to confirm system security, the login account should ONLY be able to fech E1440/E320 configuration file. No privilege on configuration modification should be granted. Is that possible to implement above on E1440/E320? Don't think so. These are the access levels you can play with: http://www.juniper.net/techpubs/software/erx/junose91/swconfig-system-basics/html/passwords-security-config9.html Or, is it possible to fetch configuation file by RO SNMP community? You can probably create a limited view covering the Juniper-FILE-XFER-MIB and Juniper-HOST-MIB (and more?) and restrict RW access to it. But I don't think you'll gain any *real* security. Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Limiting of sessions per user
Yusif Okai [EMAIL PROTECTED] writes: How can one limit the number of PPPoE sessions per user on the ERX-710. http://www.juniper.net/techpubs/software/erx/junose90/swcmdref-n-z/html/opqr-commands127.html Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Juniper SDX-300 (interoperability with thrid party products like Cisco)
P.Narayana Swamy [EMAIL PROTECTED] writes: Though, the SDX-300 supports COPS / BEEP sessions, It can support only JunosE and Junos ( Both ERX and M-series). Eventhough the controlling session is COPS, the Command line are different for other vendors. It can be used, in theory, to manage other routers using SNMP and/or CLI: http://www.juniper.net/techpubs/software/management/src/src20x/sw-sdx-integration/html/network-devices-cli.html But I've never fealt like trying to do that... Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JunOS Bug list?
Pekka Savola [EMAIL PROTECTED] writes: On Fri, 1 Feb 2008, Jonathan Brashear wrote: A fellow list member pointed me to this: https://www.juniper.net/alerts/subscribe.jsp?actionBtn=Modify Which is exactly what I was looking for. Thanks Chris. You are hopefully aware that this is an extremely selected feed of JunOS bugs and there are almost no bugs reported through this channel that aren't security vulnerabilities. This discussion made me look at that page again, and I noticed something that others here might be unaware of: There's no automatic subscription of latest major release of X bug, even if you've selected the current latest release. Seems like there's been quite a few major JUNOS and JUNOSe releases since the last time I updated my subscriptions. Let's hope they all have been bug free :-) Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Monitor ppp interface
sunnyday [EMAIL PROTECTED] writes:
Is there any way find the ppp interface from this output from a specific
subscriber?
i want for example to see what policies are attached to subscriber test1
i have done the show ppp int gig 2/6 and could identify the ppp interface but
when i have thousands of subscribers what to do to find the ppp interface???
[EMAIL PROTECTED] GigabitEthernet 2/6.100:100
[EMAIL PROTECTED] GigabitEthernet 2/6.101:101
get the ip address from
show subscribers username [EMAIL PROTECTED]
and then do
sh ip route ipaddress
to get the ip interface
Bjørn
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ERX - Problem upgrading from 5.1.1 to newer release
Rolf Frøysa [EMAIL PROTECTED] writes: I`ve tried upgrading an ERX from 5.1.1 release to a newer release but I Contact JTAC. The End-of-Service date for JUNOSe 5-1-x was January 4, 2006. But I guess your request qualifies as a minor technical inquiry and therefore still will be accommodated on a best effort basis to quote the End of Life announcement (dated November 8, 2004). You should probably start reading read the JTAC technical bulletins on a more regular basis... Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] as4byte and JunOS
Sergey [EMAIL PROTECTED] writes: On Tuesday 29 May 2007, you wrote: 4 byte ASN is currently no supported in JUNOS. Does someone have information about implementation plans ? I am guessing that the next step on the implementation plan is something like 'do not dump core when stumbling across a 4 byte ASN'. ;-) This step was expected to be finished by the end of june... Bjørn ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
