Re: [j-nsp] Urgent

[Masood Shah]

Here you go...
 
http://www.juniper.net/techpubs/software/junos/junos91/swconfig-system-basics/configuring-a-dhcp-server.html
 
 



From: juniper-nsp-boun...@puck.nether.net on behalf of chandrasekaran iyer
Sent: Thu 12/17/2009 6:39
To: juniper-nsp@puck.nether.net
Subject: [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


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] ad1 msg on Juniper M series

[Masood Shah]

TENSION-Not:) The write cache is disabled by default. If you're a Unix guy then 
mpt manpage holds more information.
Just keep in mind that turning the disk's write cache on puts your data at 
risk. :-(

Regards,
Masood



From: juniper-nsp-boun...@puck.nether.net on behalf of Shankar
Sent: Wed 11/4/2009 13:33
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] ad1 msg on Juniper M series



Hi All, Of late I had replaced the Internal compact flash on Juniper M7is
and Juniper 10is. The root is mounted on ad0 (CF), but found that 'write
cache' is disabled on ad1...has anyone seen this before..No impact on box
performance...
truncated o/p of 'show system boot-messaged
sio3 at port 0x2e8-0x2ef irq 7 on isa0
sio3: type 16550A
fxp0: Ethernet address 00:a0:a5:5c:3c:66
fxp1: Ethernet address 02:00:00:00:00:04
DEVFS: ready to run
*ad0: 999MB  [2030/16/63] at ata0-master PIO4
ad1: found HTS548020M9AT00, disabling write cache
ad1: 19077MB  [38760/16/63] at ata0-slave UDMA33*
Mounting root from ufs:/dev/ad0s1a

Cheers
___
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] Block traceroute and Allow Ping

[Masood Shah]

Truman is correct, blocking traceroute is not straightforward...

To block traceroute on Linux, start by DROPping ports 33434 to 33600. Of 
course, Truman makes a good point that this range can be overridden, for 
example in Linux with the -p option. If you are REALLY paranoid, you can DROP 
all UDP traffic and then only open the ports that you have services running on. 
Sometimes this is easier said than done though.

Windows uses "normal" ICMP echo requests with low TTL values. And the replies 
are ICMP type 11 (TTL exceeded), or ICMP type 0 (echo reply, when the 
destination has been reached). 

So if you want to block both Windows and *NIX traceroutes, you need to either:
-block outgoing messages destined to UDP ports 33434 to 33534, AND outgoing 
ICMP echo-request messages 
or
-block incoming ICMP type 11 and type 0 messages

To avoid a long discussion on this topic I would add that UNIX version of 
Tracert performs the same function as the Windows version except that the IP 
payload is a UDP packet. According to RFC1393, traceroute implementations are 
supposed to use the ICMP protocol. Indeed, the windows implementation does use 
ICMP. However, by default, the Linux implementation uses UDP, unless you apply 
the "-I" option, in which case it will use ICMP.

Regards,
Masood
Blog: http://weblogs.com.pk/jahil/



-Original Message-
From: juniper-nsp-boun...@puck.nether.net on behalf of Truman Boyes
Sent: Wed 9/30/2009 10:34
To: Iftikhar Ahmed
Cc: juniper-nsp@puck.nether.net; Pekka Savola
Subject: Re: [j-nsp] Block traceroute and Allow Ping
 
This will block some types of traceroute, but a client can always use  
different ports.

Why do you want to block traceroute?

On 29/09/2009, at 8:42 PM, Iftikhar Ahmed wrote:

> Atif,
>
> Try to apply a filter to loop-back interface with somthing like
>
>
> term traceroute {   /* permit traceroute udp packets */
>from {
> protocol udp;
>destination-port 33434-33678;
>}
>then {
> count traceroute;
>discard;
>}
> term default
> then {
> accept
> }
> }
>
>
>
> Regards,
> iftikhar Ahmed
>
> On Tue, Sep 29, 2009 at 3:23 PM, Pekka Savola   
> wrote:
>
>> On Tue, 29 Sep 2009, Muhammad Atif Jauahar wrote:
>>
>>> I want to block traceroute transit traffic on router but I want to  
>>> allow
>>> ping transit traffic. Kindly let me know ICMP Type and Code for  
>>> traceroute
>>> and kindly let me know procedure to block traceroute but allow ping.
>>>
>>
>> You can't if you want to support all flavours of traceroute as some  
>> of
>> those use the equivalent of ping.  Maybe you could match by both  
>> TTL and
>> ICMP type/code but that would be hackish.  To learn more about how
>> traceroute works, see:
>>
>> http://en.wikipedia.org/wiki/Traceroute
>>
>> --
>> Pekka Savola "You each name yourselves king, yet the
>> Netcore Oykingdom bleeds."
>> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>>
>> ___
>> 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

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] EX4200 and Broadcom NICs on Linux Server

[Masood Shah]

what kind of routing issue this is? 

-Original Message-
From: juniper-nsp-boun...@puck.nether.net on behalf of Shane Ronan
Sent: Sat 9/26/2009 23:54
To: juniper-nsp
Subject: [j-nsp] EX4200 and Broadcom NICs on Linux Server
 
Has any else experienced routing issues with Broadcom NICS on a Linux  
Server connected to an EX4200?


Shane

___
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] E120 Configure single domain to authenticate from adifferent RADIUS

[Masood Shah]

You can use one RADIUS server (cluster as well) for all the domains and decide 
on the RADIUS instead of RAS/BRAS. You can use your primary RADIUS as n proxy 
for particular domain,user,subnet  to redirect/out-source the auth,authrozn,acc 
of dial-in user,realm etc to another RADIUS server, which is more scalable and 
reliable than having a separate server for a specific domain. And this way 
server farm can act as both a primary and backup at the same time.
 
Regards,
Masood
 
 


From: juniper-nsp-boun...@puck.nether.net on behalf of Jason Alex
Sent: Wed 8/12/2009 9:13 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] E120 Configure single domain to authenticate from adifferent 
RADIUS



Dear All,
   How can i configure on the E120 Router to make some users with a
specific doman (i.e .com) to authenticate from a different RADIUS
Servers using pppoe other than the RADIUS Server used by all the other users

Appreciate your help

Thanks
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] lsp required for vpls?

[Masood Shah]

After the last post I feel it's worth mentioning that both vendors 
(juniper/cisco) are supporting LDP/RSVP. So what makes you think you can use 
either LDP or RSVP for transport layer signaling. Even you can use both of thm 
lke when you run LDP over LSPs established by RSVP nd there is much 
more..Unfortunately, life is not so easy :)
 
Regards,
Masood



From: juniper-nsp-boun...@puck.nether.net on behalf of Derick Winkworth
Sent: Sun 8/9/2009 8:06 PM
To: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] lsp required for vpls?



MPLS does not "depend" on RSVP. 

MPLS itself has "multiple" layers.  The most basic model is the "transport" 
layer underneath an "application" layer.  This is the model many service 
providers use.

Each "layer" has its own signaling.  So, for instance, the transport layer in a 
service provider network gets traffic between the edges of the provider's 
network (PE to PE).  Routing between PEs is based on a routed loopback on each 
of the PEs.  At the transport layer, from hop-to-hop, signalling can be LDP or 
RSVP or even BGP (not VPNv4, but BGP signalled labels).

At the application layer (VPLS, L3VPN, etc), a second MPLS label is added.  
VPNv4 is used between PEs to signal labels for L3VPN routes.  VPLS signals its 
labels with either "directed" LDP or BGP.  This label becomes the "inner" label 
of a dual-label stack.  The outer label is the transport layer.

Now you can have multiple transport layers for instance in the case of 
different Inter-AS options or CSC, if you are doing those things...  And in any 
case you can have multiple application layers running in parallel...

Juniper, of course, recommends RSVP for the transport layer so their 
troubleshooting documentation reflects that.  Cisco recommends LDP, which is a 
standard version of TDP which is Cisco proprietary.

I hope this helps.





From: Simon Chen 
To: snort bsd 
Cc: "juniper-nsp@puck.nether.net" 
Sent: Sunday, August 9, 2009 11:22:14 AM
Subject: Re: [j-nsp] lsp required for vpls?

According to this document, MPLS depends on RSVP...

http://www.juniper.net/techpubs/software/nog/nog-mpls-model/html/mpls-model2.html#1035142

I'm really confused and want to figure out exactly what the dependency is...

Thanks.
-Simon

On Fri, Aug 7, 2009 at 10:25 AM, snort bsd wrote:
>
> I think you got confused with concepts of signaling protocol and lsp istelf.
>
> mpls is foundation of all new technologies that rely on mpls label switching. 
> but mpls lsp depends on signaling protocols such as rsvp or ldp for the label 
> swapping. bgp is still the protocol that utilize the lsp (in the table 
> inet.3).
>
> vpls can be implemented via either ldp based (martini) or bgp driven 
> (kompella).
>
>
>
> --- On Fri, 7/8/09, Simon Chen  wrote:
>
>> From: Simon Chen 
>> Subject: Re: [j-nsp] lsp required for vpls?
>> To: "Harry Reynolds" 
>> Cc: "juniper-nsp@puck.nether.net" 
>> Received: Friday, 7 August, 2009, 5:09 AM
>> Thank you all for the reply.
>>
>> Do I need to explicitly configure MPLS LSPs between the PEs
>> (using
>> protocols/mpls/label-swithing-path)? Or just configure RSVP
>> or LDP on
>> the PEs so that LSPs can be automatically established by
>> VPLS?
>>
>> Thanks.
>> -Simon
>>
>> On Thu, Aug 6, 2009 at 1:12 PM, Harry Reynolds
>> wrote:
>> > Ldp can both signal vpls (ldp based vpls control
>> plane) and establish lsps. You either single vpls with ldp
>> or bgp, and then transport via a lsp between pes. This
>> transport lsp can be rsvp or ldp signaled.
>> >
>> > Regards
>> >
>> >
>> >
>> > -Original Message-
>> > From: juniper-nsp-boun...@puck.nether.net
>> [mailto:juniper-nsp-boun...@puck.nether.net]
>> On Behalf Of Simon Chen
>> > Sent: Thursday, August 06, 2009 9:35 AM
>> > To: juniper-nsp@puck.nether.net
>> > Subject: [j-nsp] lsp required for vpls?
>> >
>> > Hi all,
>> >
>> > I read in the VPN configuration guide that LSPs
>> between PEs are required for VPLS. However, I am able to
>> establish a VPLS setup using LDP signalling, but without
>> MPLS-LSP between PEs.
>> >
>> > Does anyone know why? My guess is that LSP is only
>> required if you're going for the BGP signalling, but not
>> required if you're doing LDP.
>> > Can anyone clarify this?
>> >
>> > Thanks.
>> > -Simon
>> > ___
>> > 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
>>
>
>
>  
> __
> Find local businesses and services in your area with Yahoo!7 Local.
> Get started: http://local.yahoo.com.au  
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.n