Re: [j-nsp] M7i DHCP Relay
Hi, This is supposedly fixed in PR/523902 which is resolved in 10.2R2 10.3R1 10.1R3 10.0R4 10.4R1. It includes two hidden commands which should allow the forwarding of DHCP traffic on interfaces that are not configured for DHCP (when using dhcp-relay or dhcp-local-server). I haven't had the time to test it out yet. On another note, does anyone have unnumbered and helpers bootp working on MX? All I can coax out of them is "request from 0.0.0.0 if ge-1/0/3.2070 no useful gateway address" in fud log with maximum logging, "show helper statistics" claiming the reason being "Due to no valid local address: " and incrementing drop counters. There's a ticket open on that, too. Kaj On 18/3/2010 21:26, "sth...@nethelp.no" wrote: > > Yes. This is a serious bug which basically makes M/MX routers unusable > if you want to have DHCP relay agent functionality *on the router* at > the same time as you have other DHCP unicast traffic (for instance > generated by a Cisco CPE with "ip helper", or a client sending its > renewal request directly to the DHCP server) passing *through* the > router. > > I find it absolutely incredible that Juniper with its ERX history has > managed to botch the M/MX DHCP functionality this badly. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bgp summary outq
> -Original Message- > From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- > boun...@puck.nether.net] On Behalf Of David DeSimone > Sent: Wednesday, August 11, 2010 11:09 AM > To: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] bgp summary outq > > > I think this is just a presentation/column-alignment problem. The > columns are intended to be "Peer" then "AS" then "InPkt" then "OutPkt" > then "OutQ", but due to the wide IPV6 address in the "Peer" column, the > "OutPkt" numbers are appearing underneath the "OutQ" label. *facepalm* -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] which permission to set to activate "show configuration | display commit-scripts"
> > I've went through the documentation on the Juniper site > http://www.juniper.net/techpubs/en_US/junos10.2/topics/concept/access- > privileges-levels-overview.html > but I can't figure out which permission I need to make the display > command work. > It looks to me like it requires the maintenance permission bit, so basically super-user. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] which permission to set to activate "show configuration | display commit-scripts"
you could use the "allow-command "
might be faster for you than searching through which permission gives you
this commands
On 11 August 2010 14:45, Jeroen Valcke wrote:
> Hello,
>
> I've created a restricted user class. Basically users in this class
> should only be able to view the configuration and run show commands.
>
> This is the code.
>
>class student {
>permissions [ access admin firewall interface network routing
> security snmp system view ];
>}
>user student {
>uid 2300;
>class student;
>}
>
> Users in this class can display the configuration (show configuration).
> However we have a lot of code that is generated by commit-scripts. Usage
> of the 'display commit-scripts' command doesn't seem to work with the
> above permissions.
>
> So the option commit-scripts is not available for users in this
> 'student' class.
>
>stud...@ar1.kor> show configuration | display ?
>Possible completions:
> changed Tag changes with junos:changed attribute (XML
> only)
> detail Show configuration data detail
> inheritance Show inherited configuration data and source
> group
> omit Emit configuration statements with the 'omit'
> option
> set Show 'set' commands that create configuration
> xml Show output as XML tags
>
>
> I've went through the documentation on the Juniper site
>
> http://www.juniper.net/techpubs/en_US/junos10.2/topics/concept/access-privileges-levels-overview.html
> but I can't figure out which permission I need to make the display
> command work.
>
> Kind regards,
> -Jeroen-
>
> --
> Jeroen Valcke
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
--
Humair
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Provisioning and managing TE and L2/L3 vpns
A lot of shops use custom tools. EMC makes a multi-vendor MPLS management tool. http://www.emc.com/products/detail/software/mpls-manager.htm From: Ethan Whitt To: juniper-nsp@puck.nether.net Sent: Wed, August 11, 2010 2:00:07 AM Subject: [j-nsp] Provisioning and managing TE and L2/L3 vpns We operate a dual vendor network and am looking for recommendations on provisioning and managing TE, layer 2 vpns, and layer 3 vpns for Juniper routers. Today we use Cisco IP solution center for these functions on our Cisco routers. We have had mixed experiences with IP solution center, so we would consider a dual vendor tool. Any lessons learned from real world experiences on either topic would be appreciated. thanks. ~elw ___ 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] which permission to set to activate "show configuration | display commit-scripts"
Hello,
I've created a restricted user class. Basically users in this class
should only be able to view the configuration and run show commands.
This is the code.
class student {
permissions [ access admin firewall interface network routing
security snmp system view ];
}
user student {
uid 2300;
class student;
}
Users in this class can display the configuration (show configuration).
However we have a lot of code that is generated by commit-scripts. Usage
of the 'display commit-scripts' command doesn't seem to work with the
above permissions.
So the option commit-scripts is not available for users in this
'student' class.
stud...@ar1.kor> show configuration | display ?
Possible completions:
changed Tag changes with junos:changed attribute (XML
only)
detail Show configuration data detail
inheritance Show inherited configuration data and source
group
omit Emit configuration statements with the 'omit'
option
set Show 'set' commands that create configuration
xml Show output as XML tags
I've went through the documentation on the Juniper site
http://www.juniper.net/techpubs/en_US/junos10.2/topics/concept/access-privileges-levels-overview.html
but I can't figure out which permission I need to make the display
command work.
Kind regards,
-Jeroen-
--
Jeroen Valcke
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] bgp summary outq
Eric Van Tol wrote: > > I noticed this morning that all my IPv6 BGP neighbors have what appear > to be thousands of messages in the 'OutQ'. It's only IPv6 neighbors. > The numbers continue to climb and I'm curious as to why. I'm not > dropping sessions and I can't imagine that the v6 route table > fluctuates so much that all these messages would queue up: > > ber2.ss.sls.md# run show bgp summary > Groups: 6 Peers: 8 Down peers: 0 > Table Tot Paths Act Paths SuppressedHistory Damp State > Pending > inet.0644649 322548 0 0 0 > 24 > inet6.04 2 0 0 0 > 0 > Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn > State|#Active/Received/Accepted/Damped... > :::::d0401234 168393 172216 0 1 > 7w5d20h Establ > inet6.0: 1/2/2/0 > :::::d0411234 205620 210491 0 1 > 9w3d23h Establ > inet6.0: 1/2/2/0 > :::::d0441234 2431 2433 0 2 > 18:35:32 Establ > inet6.0: 0/0/0/0 I think this is just a presentation/column-alignment problem. The columns are intended to be "Peer" then "AS" then "InPkt" then "OutPkt" then "OutQ", but due to the wide IPV6 address in the "Peer" column, the "OutPkt" numbers are appearing underneath the "OutQ" label. -- David DeSimone == Network Admin == f...@verio.net "I don't like spinach, and I'm glad I don't, because if I liked it I'd eat it, and I just hate it." -- Clarence Darrow This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Default SRX Behaviour
>From my understanding this will only impact your stateful packet filtering >options. If you disable syn checking, the firewall portion will no longer >check if there was an associated syn packet before creating a session in its >state table. Here's the description from Screenos which for all intents and purposes is the same application in Junos: tcp-syn-check (description for ScreenOS 6.0 and above) Checks the TCP SYN bit before creating a session, and refreshes the session after the TCP three-way handshake. If the SYN bit is not set, the security device drops the packet. If I recall correctly it could allow someone malicious to send packets to/or through the security device without properly establishing a session via the 3 way handshake. I think I ran into this a while back because I had some asymmetric routing, which was causing packets to be sent back to my security device that did not have an established session. You could also alternatively see if you increase the session durations on a certain policy and see if that will fix the issue without disabling the syn checking altogether. Hope that helps, Sven -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Tuesday, August 10, 2010 10:46 PM To: 'William Jackson'; 'Scott T. Cameron'; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Default SRX Behaviour I just wanted to respond back on-list about this .. thank you to everyone who made suggestions on this issue. The "set security flow tcp-session no-syn-check" resolved our issue as suggested below. My last question is to understand the "risk" associated to disabling the syn-check. Does this effect any screen options, intrusion or firewall filters? Thanks, Paul -Original Message- From: William Jackson [mailto:wjack...@sapphire.gi] Sent: Friday, August 06, 2010 12:20 AM To: Paul Stewart; Scott T. Cameron; juniper-nsp@puck.nether.net Subject: RE: [j-nsp] Default SRX Behaviour I am suffering exactly the same symptoms for nearly exactly the same reasons, I have a JTAC case open and they have told me to implement: >Set security flow tcp-session no-syn-check But it doesn't seem to have made a difference :-( We are running srx240s in a cluster with 10.0R3.10 code. Best Regards William Jackson ___ 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] bgp summary outq
Hi all, I noticed this morning that all my IPv6 BGP neighbors have what appear to be thousands of messages in the 'OutQ'. It's only IPv6 neighbors. The numbers continue to climb and I'm curious as to why. I'm not dropping sessions and I can't imagine that the v6 route table fluctuates so much that all these messages would queue up: ber2.ss.sls.md# run show bgp summary Groups: 6 Peers: 8 Down peers: 0 Table Tot Paths Act Paths SuppressedHistory Damp StatePending inet.0644649 322548 0 0 0 24 inet6.04 2 0 0 0 0 Peer AS InPkt OutPktOutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... :::::d0401234 168393 172216 0 1 7w5d20h Establ inet6.0: 1/2/2/0 :::::d0411234 205620 210491 0 1 9w3d23h Establ inet6.0: 1/2/2/0 :::::d0441234 2431 2433 0 2 18:35:32 Establ inet6.0: 0/0/0/0 I'm running 9.5R4.3 on various platforms (M-Series / MX-Series). Is this normal? If it is, I guess I just never noticed it. None of my v4 neighbors show this behavior. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MS-DPC export flows have 0 as dest interface
Jim, in my experience, the destination interface ifIndex can be 0 in the following cases: - traffic dropped - traffic destined locally - multicast Thanks, Luca. On Tue, 2010-08-10 at 16:06 -0700, Jim Devane wrote: > RAS, > > 10.0R2 > I opened a case and we will see what happens. I have zero issue with moving > to new code if it will solve the issue. This router doesn't do a whole lot > (and even less without correct flow reporting) > > Thanks, > Jim > > > -Original Message- > From: Richard A Steenbergen [mailto:r...@e-gerbil.net] > Sent: Tuesday, August 10, 2010 4:04 PM > To: Jim Devane > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] MS-DPC export flows have 0 as dest interface > > On Tue, Aug 10, 2010 at 01:01:48PM -0700, Jim Devane wrote: > > > > However, The Juniper is not reporting the dest interface and instead > > putting in a zero. This is confusing our flow collector (Peakflow SP) > > Arbor takes the dest intf and source interface both being zero as a > > drop. The traffic is not in fact being dropped, however. > > > > Has anyone dealt with this particular or type of problem? I was trying > > What code are you running? We had a similar issue a while back, infact > we had a case open on it for over a year before it finally got fixed, > but I'm pretty sure our version of the issue has been fixed for a couple > years now. > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Provisioning and managing TE and L2/L3 vpns
We operate a dual vendor network and am looking for recommendations on provisioning and managing TE, layer 2 vpns, and layer 3 vpns for Juniper routers. Today we use Cisco IP solution center for these functions on our Cisco routers. We have had mixed experiences with IP solution center, so we would consider a dual vendor tool. Any lessons learned from real world experiences on either topic would be appreciated. thanks. ~elw ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
