Re: [j-nsp] *humor*. MX480 sound card options

[Dermot Williams]

Something new everyday!

IP Engineering and Network Operations Manager
Imagine Communications Group Ltd.


From: Matthew Crocker <matt...@corp.crocker.com>
Sent: Tuesday, October 10, 2017 1:06:10 AM
To: Dermot Williams; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] *humor*. MX480 sound card options


JunOS is BSD but on the NG-RE JunOS is running in a VM on Linux (KVM)

The message came during the Linux vmhost reboot, so linux driver

-Matt

--
Matthew Crocker
Crocker Communications, Inc.
President

From: Dermot Williams <dermot.willi...@imaginegroup.ie>
Date: Monday, October 9, 2017 at 7:44 PM
To: "juniper-nsp@puck.nether.net" <juniper-nsp@puck.nether.net>, Matthew 
Crocker <matt...@corp.crocker.com>
Subject: Re: [j-nsp] *humor*. MX480 sound card options

BSD, not Linux. If it was Linux then there'd be drivers for the card.
IP Engineering and Network Operations Manager
Imagine Communications Group Ltd.


From: juniper-nsp <juniper-nsp-boun...@puck.nether.net> on behalf of Matthew 
Crocker <matt...@corp.crocker.com>
Sent: Tuesday, October 10, 2017 12:34:52 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] *humor*. MX480 sound card options



I’m performing an upgrade on my MX480 NG-REs and I see this scroll through the 
console:

ALSA: Storing mixer settings...
/usr/sbin/alsactl: save_state:1590: No soundcards found...


So, the question is, what sound card options can I get on my MX480?  Is there a 
3D sound option for ‘SonicIP’?

Not sure why Juniper didn’t remove this from  their Linux install

-Matt

--
Matthew Crocker
Crocker Communications, Inc.
President
___
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] *humor*. MX480 sound card options

[Dermot Williams]

BSD, not Linux. If it was Linux then there'd be drivers for the card.

IP Engineering and Network Operations Manager
Imagine Communications Group Ltd.


From: juniper-nsp  on behalf of Matthew 
Crocker 
Sent: Tuesday, October 10, 2017 12:34:52 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] *humor*. MX480 sound card options



I’m performing an upgrade on my MX480 NG-REs and I see this scroll through the 
console:

ALSA: Storing mixer settings...
/usr/sbin/alsactl: save_state:1590: No soundcards found...


So, the question is, what sound card options can I get on my MX480?  Is there a 
3D sound option for ‘SonicIP’?

Not sure why Juniper didn’t remove this from  their Linux install

-Matt

--
Matthew Crocker
Crocker Communications, Inc.
President
___
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] sshd log messages !!

[Dermot Williams]

On Wed, Feb 26, 2014 at 02:21:46PM -0800, Harri Makela wrote:
 Hi There
 
 I am constantly getting these log messages for last few days:-
 
 sshd[21015]: Failed password for root from X.X.103.152 port 21067 ssh2
 sshd[21016]: Received disconnect from X.X.103.152: 11: Normal Shutdown, Thank 
 you for playing
 
 
 Are these indicating any brute-force attack ?Thanks
 HM

Most likely, yes.

Dermot

 
 
 
 
 On Wednesday, 26 February 2014, 21:15, juniper-nsp-requ...@puck.nether.net 
 juniper-nsp-requ...@puck.nether.net wrote:
  
 Send juniper-nsp mailing list submissions to
     juniper-nsp@puck.nether.net
 
 To subscribe or unsubscribe via the World Wide Web, visit
     https://puck.nether.net/mailman/listinfo/juniper-nsp
 or, via email, send a message with subject or body 'help' to
     juniper-nsp-requ...@puck.nether.net
 
 You can reach the person managing the list at
     juniper-nsp-ow...@puck.nether.net
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of juniper-nsp digest...
 
 
 Today's Topics:
 
    1. Re: proposed changes to clear bgp neighbor (ryanL)
    2. Re: proposed changes to clear bgp neighbor (Phil Shafer)
    3. Re: proposed changes to clear bgp neighbor (Eric Van Tol)
    4. Re: proposed changes to clear bgp neighbor (Jerry Dent)
    5. Re: proposed changes to clear bgp neighbor (Brent Sweeny)
    6. Re: proposed changes to clear bgp neighbor
       (Fernando Garcia Fernandez)
    7. Re: proposed changes to clear bgp neighbor (ryanL)
    8. Re: proposed changes to clear bgp neighbor
       (Jonas Frey (Probe Networks))
    9. Re: proposed changes to clear bgp neighbor (sth...@nethelp.no)
 
 
 --
 
 Message: 1
 Date: Wed, 26 Feb 2014 12:22:51 -0500
 From: ryanL ryan.lan...@gmail.com
 To: p...@juniper.net
 Cc: Juniper for Network Service Providers
     juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] proposed changes to clear bgp neighbor
 Message-ID:
     cak_-tsayrdjhuatsnbokn2nrkcrjjgb3zwtr_cljizkuxcx...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1
 
 it's a nice-to-have, maybe? but this sounds more like an opportunity for
 you to sell some JNCIA courses. i mean, how long has junos been around now?
 
 
 On Wed, Feb 26, 2014 at 10:36 AM, Phil Shafer p...@juniper.net wrote:
 
  Juniper users,
 
  We've been asked to make a change the clear bgp neighbor command
  to make the neighbor or all argument mandatory.  The root cause
  is the severe impact of clear bgp neighbor and the increasing
  accidental use of this command without a specific neighbor.
 
  In general, we avoid changing commands to add mandatory arguments,
  but my feeling is that the impact and severity of this specific
  command makes this an acceptable occasion for such a change.
 
  I'm looking for feedback about this change.  My working assumption
  is that clear bgp neighbor is a sufficiently rare command and
  would not be used in automation/scripts, so the impact of making
  the neighbor/all argument mandatory would be minimal.  Is this
  assumption accurate?
 
  Thanks,
   Phil
 
  [I've set reply-to to myself to avoid impacting the list]
 
  ___
  juniper-nsp mailing list juniper-nsp@puck.nether.net
  https://puck.nether.net/mailman/listinfo/juniper-nsp
 
 
 
 --
 
 Message: 2
 Date: Wed, 26 Feb 2014 13:44:42 -0500
 From: Phil Shafer p...@juniper.net
 To: ryanL ryan.lan...@gmail.com
 Cc: Juniper for Network Service Providers
     juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] proposed changes to clear bgp neighbor
 Message-ID: 201402261844.s1qiiggl031...@idle.juniper.net
 Content-Type: text/plain
 
 ryanL writes:
 it's a nice-to-have, maybe? but this sounds more like an opportunity for
 you to sell some JNCIA courses. i mean, how long has junos been around now?
 
 Not selling anything; just trying to solve a problem multiple
 customers have reported and escalated.  I'm a software developer,
 working on the UI code (CLI, MGD, configuration, XML API, scripting)
 for 17+ years.
 
 JUNOS 3.0 (the first release with the ui code) shipped during the
 summer of 1998, IIRC.
 
 Thanks,
 Phil
 
 
 
 --
 
 Message: 3
 Date: Wed, 26 Feb 2014 14:24:21 -0500
 From: Eric Van Tol e...@atlantech.net
 To: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] proposed changes to clear bgp neighbor
 Message-ID:
     2C05E949E19A9146AF7BDF9D44085B865F70CC1FB1@exchange.aoihq.local
 Content-Type: text/plain; charset=us-ascii
 
  it's a nice-to-have, maybe? but this sounds more like an opportunity for
  you to sell some JNCIA courses. i mean, how long has junos been around
  now?
 
 Confusing comment, since this enhancement isn't about CLI inexperience.  It 
 doesn't matter how long Junos has been around or how experienced someone is, 
 it's still too incredibly easy to hit 'Enter' too soon and 

[j-nsp] Problem with default route in L3VPN and Route Reflected Topology

[Dermot Williams]

Hello List,

We operate a route-reflected internal BGP topology and have a number of 
customers to whom we offer L3VPN services. We recently upgrade our route 
reflectors (M7i) to 11.4R3.7, per our support provider's advice (and, indeed, 
requirement). Since then we have run into a what appears to be a bug that has 
been introduced since the 9.x stream (I know, I know, we've been slack about 
upgrading and I'm sort of glad we have been).

Basically, a CE device advertises a default route to its PE neighbour. The PE 
device advertises the route, with an rd-prefix, to the route reflectors; the 
RRs load the route into the bgp.l3vpn.0 table as expected. If we look at this 
default route in an RR's table, everything looks fine: the protocol next-hop is 
the loopback of the PE router and the community is the normal 
'target:65535:12345' type that one would expect for a VRF route.

The problem arises when that route is advertised to other routers. For some 
reason, when the route reflector is exporting the route, it is changing the 
protocol next-hop and the community. In the case of the community, it becomes 
the standard 1234:567 format that one associates with routes in inet.0 and 
inet6.0. Obviously, the receiving PE device doesn't load the route into its 
VRF, since the community doesn't match, and this is causing problems for 
customers. This *only* happens with a default route that's been injected into a 
VRF - other routes injected by the CE devices in each VRF are re-advertised by 
the route reflectors with their protocol next-hop and community values intact.

Has anyone else come across this problem? Is it a bug or is there some new 
configuration knob that we have missed?

Thanks,

Dermot Williams
IP Engineering Manager
Imagine Communications Group Ltd.
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] IQ2 PIC won't stay online

[Dermot Williams]

(Apologies if this is a duplicate - my first mail doesn't appear to have
been posted to the list)

 

Hello List,

 

I've an IQ2 PIC (PE-4GE-TYPE1-SFP-IQ2) in an M7i that won't come online
for some reason. Or, rather, it seems to come online, stay on for
approximately 3 minutes, then resets, comes back online. It does this
last four times and then stays offline until the next time I run
'request pic online ...'.

 

Even when the PIC is showing as online, none of the inserted SFPs are
detected. I've inserted the PIC into the spare slot in an M10i, where it
came online - and stayed online - without problem so I'm certain that
the PIC itself is fine. My next step is obviously to try a different PIC
in the M7i to see if the slot itself is shagged.

 

Before I do that though, is there anything else I can check on the M7i?
I've looked in the chassisd log and there's nothing in there that would
indicate what the problem is:

 

  Nov 24 00:23:32 pic offline req, pic 2, fpc 0

  Nov 24 00:23:32 CHASSISD_IFDEV_DETACH_PIC: ifdev_detach_pic(0/2)

  Nov 24 00:23:32 ifd ge-0/2/0 marked as gone

  Nov 24 00:23:32 ifd ge-0/2/1 marked as gone

  Nov 24 00:23:32 ifd ge-0/2/2 marked as gone

  Nov 24 00:23:32 ifd ge-0/2/3 marked as gone

  Nov 24 00:23:32 ifd pc-0/2/0 marked as gone

  Nov 24 00:23:32 send pic_offline_ack fpc 0 pic 2 accept 1

  Nov 24 00:23:32 CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power
off (jnxFruContentsIndex 8, jnxFruL1Index 1, jnxFruL2Index 3,
jnxFruL3Index 0, jnxFruName PIC: 4x 1GE(LAN), IQ2 @ 0/2/*, jnxFruType
11, jnxFruSlot 0, jnxFruOfflineReason 2, jnxFruLastPowerOff 75357,
jnxFruLastPowerOn 62202)

  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: change. ifd count
3, flags 0x2 in mesg

  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: change. ifd count
1, flags 0x2 in mesg

  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: change. ifd count
0, flags 0 in mesg

  Nov 24 00:23:32 Time to clean up PIC FPC 0, PIC 2

  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: delete. ifd count
0, flags 0 in mesg

  Nov 24 00:23:32 pic_handle_message_idl: PIC fpc 0 pic 2 got deleted

  Nov 24 00:23:32 pic detach, pic 2, fpc 0

  Nov 24 00:23:32 set_pic_offline: fpc 0 pic 2 pic_retries 0
fru_timerset 0 pic_in_issu 0

  Nov 24 00:23:32 hwdb: entry for pic 673 at slot 2 in fpc 0 deleted

 

The M7i is fully-loaded (i.e., PE-1GE-SFP in every other port); it has
an RE-400-256-S (with 512MB RAM) and a built-in 1GE port.

 

I'm probably looking at a knackered slot here but any suggestions or
pointers would be appreciated.

 

Thanks in advance,

 

Dermot Williams

 

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

[j-nsp] IQ2 PIC won't stay online

[Dermot Williams]

Hello List,

I've an IQ2 PIC (PE-4GE-TYPE1-SFP-IQ2) in an M7i that won't come online for 
some reason. Or, rather, it seems to come online, stay on for approximately 3 
minutes, then resets, comes back online. It does this last four times and then 
stays offline until the next time I run 'request pic online ...'.

Even when the PIC is showing as online, none of the inserted SFPs are detected. 
I've inserted the PIC into the spare slot in an M10i, where it came online - 
and stayed online - without problem so I'm certain that the PIC itself is fine. 
My next step is obviously to try a different PIC in the M7i to see if the slot 
itself is shagged.

Before I do that though, is there anything else I can check on the M7i? I've 
looked in the chassisd log and there's nothing in there that would indicate 
what the problem is:

  Nov 24 00:23:32 pic offline req, pic 2, fpc 0
  Nov 24 00:23:32 CHASSISD_IFDEV_DETACH_PIC: ifdev_detach_pic(0/2)
  Nov 24 00:23:32 ifd ge-0/2/0 marked as gone
  Nov 24 00:23:32 ifd ge-0/2/1 marked as gone
  Nov 24 00:23:32 ifd ge-0/2/2 marked as gone
  Nov 24 00:23:32 ifd ge-0/2/3 marked as gone
  Nov 24 00:23:32 ifd pc-0/2/0 marked as gone
  Nov 24 00:23:32 send pic_offline_ack fpc 0 pic 2 accept 1
  Nov 24 00:23:32 CHASSISD_SNMP_TRAP10: SNMP trap generated: FRU power off 
(jnxFruContentsIndex 8, jnxFruL1Index 1, jnxFruL2Index 3, jnxFruL3Index 0, 
jnxFruName PIC: 4x 1GE(LAN), IQ2 @ 0/2/*, jnxFruType 11, jnxFruSlot 0, 
jnxFruOfflineReason 2, jnxFruLastPowerOff 75357, jnxFruLastPowerOn 62202)
  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: change. ifd count 3, 
flags 0x2 in mesg
  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: change. ifd count 1, 
flags 0x2 in mesg
  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: change. ifd count 0, 
flags 0 in mesg
  Nov 24 00:23:32 Time to clean up PIC FPC 0, PIC 2
  Nov 24 00:23:32 PIC (fpc 0 pic 2) message operation: delete. ifd count 0, 
flags 0 in mesg
  Nov 24 00:23:32 pic_handle_message_idl: PIC fpc 0 pic 2 got deleted
  Nov 24 00:23:32 pic detach, pic 2, fpc 0
  Nov 24 00:23:32 set_pic_offline: fpc 0 pic 2 pic_retries 0 fru_timerset 0 
pic_in_issu 0
  Nov 24 00:23:32 hwdb: entry for pic 673 at slot 2 in fpc 0 deleted

The M7i is fully-loaded (i.e., PE-1GE-SFP in every other port); it has an 
RE-400-256-S (with 512MB RAM) and a built-in 1GE port.

I'm probably looking at a knackered slot here but any suggestions or pointers 
would be appreciated.

Thanks in advance,

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

[j-nsp] MX80 throughput

[Dermot Williams]

Hello list,

I'm speccing out a replacement for our aging M10i platform. We're pulling about 
3.5Gbps in from our transit providers and sending about 0.5 out. I expect to 
see this increase to around 10 inbound in the short-term and possibly go to 20 
over the next couple of years.

I'm looking at the MX80 platform, specifically the model that has 48 electrical 
GigE ports baked in as opposed to taking MICs. However I've been told that this 
version doesn't have ASICs and does all of its forwarding in software.

Does anyone have any thoughts on the real-world performance of this box? Would 
it suffice for the traffic levels I'm talking about?

Thanks,

Dermot Williams
Imagine Communications Group Ltd.
--
Sent using BlackBerry
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] L2VPN MTU Issue

[Dermot Williams]

Hi Eric,

Unless it's sensitive, would you mind sharing how you arrived at that
number please?

Thanks,

Dermot

-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Eric Van Tol
Sent: 29 September 2010 15:34
To: juniper-nsp
Subject: Re: [j-nsp] L2VPN MTU Issue

 -Original Message-
 From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
 boun...@puck.nether.net] On Behalf Of Eric Van Tol
 Sent: Wednesday, September 29, 2010 6:19 AM
 To: juniper-nsp
 Subject: [j-nsp] L2VPN MTU Issue
 
 Hi all,
 I'm having an issue with an L2VPN customer at the moment. They need to
be
 able to pass 1500-byte IP packets between two locations connected via
an
 ethernet encapsulated L2VPN.  I am able to ping from PE to PE with
1500-byte
 sized packets with the df-bit set without a problem.  The L2VPN
connection is
 up and the customer can get a max of 1490-bytes through without
 fragmentation.  My LSP shows an MTU of 1500:

For historic purposes, the solution was to change my MPLS MTU to 1528
throughout the network.  Now that I see the number, it should have been
more obvious to me.

Thanks to those who responded, but public and private.

-evt

___
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] PPPoE

[Dermot Williams]

Hi,

 

Either I fail at searching the docs or the docs fail at providing the
info but I'm having a bit of trouble getting a working PPPoE
configuration on a J4300. 

 

Firstly, is it possible to use a logical interface (e.g., fe-0/0/0.128)
as a PPPoE interface? The router lets me set the encapsulation on the
interface to ppp-over-ethernet but I can't take it for granted that that
means I have a working config.

 

Also, how do I indicate to the router what packets should bring up the
PPP session? There doesn't seem to be a way in JunOS (8.1, admittedly)
to specify that the next-hop for a given subnet is an interface.

 

Any ideas?

 

Thanks,

 

Dermot

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

[j-nsp] 802.1ad over L2VPN

[Dermot Williams]

Hi List,

 

Does anyone have any experience of running 802.1ad (Q-in-Q) across
L2VPNs? Does it work?

 

Thanks in advance for any feedback/pointers,

 

Dermot Williams

Imagine Group Ltd.

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

Re: [j-nsp] DRAM for M7 / crash of M7

[Dermot Williams]

My question is a more general one about whether or not Juniper reserve
the right to refuse to support a chassis that has had non-Juniper
components installed, whether that's DRAM, SFPs or compact-flash cards.
Obviously if a problem is identified as originating with a dodgy
non-Juniper stick of RAM, I wouldn't expect them to provide a
replacement for the RAM but I would be wary about installing it in the
first place if I thought that they (or any other vendor) would refuse to
provide any support whatsoever once it became apparent that there was
one or more non-branded components present - even if the actual problem
isn't necessarily related to the component in question.

Dermot

-Original Message-
From: Boyd, Benjamin R [mailto:[EMAIL PROTECTED] 
Sent: 26 August 2008 15:06
To: Dermot Williams
Subject: RE: [j-nsp] DRAM for M7 / crash of M7

They don't cover after market upgrades.  The router is still covered
though.

From Juniper's Warranty Page: (http://www.juniper.net/support/warranty/)
IN ADDITION, JUNIPER NETWORKS SHALL NOT BE LIABLE FOR CUSTOMER'S OR ANY
THIRD PARTY'S SOFTWARE, FIRMWARE, INFORMATION, OR MEMORY DATA CONTAINED
IN, SORTED ON, OR INTEGRATED WITH ANY PRODUCT RETURNED TO JUNIPER
NETWORKS, WHETHER UNDER WARRANTY OR NOT.

-Ben


-Original Message-
From: Dermot Williams [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 26, 2008 8:59 AM
To: Boyd, Benjamin R
Subject: RE: [j-nsp] DRAM for M7 / crash of M7

What are the support implications - if any - of using 
non-branded memory?

Dermot





***

The information contained in this message, including attachments, may
contain 
privileged or confidential information that is intended to be delivered
only to the 
person identified above. If you are not the intended recipient, or the
person 
responsible for delivering this message to the intended recipient,
Windstream requests 
that you immediately notify the sender and asks that you do not read the
message or its 
attachments, and that you delete them without copying or sending them to
anyone else.

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

[j-nsp] Tunnel Services

[Dermot Williams]

Hi List,

 

This might seem like a stupid question but the Juniper docs are fairly
vague on this - is the built-in tunnel PIC in the M7i/M10i RE all that
is required to terminate GRE/IP-in-IP tunnels? Or does one also require
an AS PIC?

 

Thanks,

 

Dermot

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

Re: [j-nsp] Tunnel Services

[Dermot Williams]

Erdem,

From reading previous emails to the list, it looks like the ASM also
performs the TS function. If the ASM is present, the built-in FPC Tunnel
services slot is disabled.

http://puck.nether.net/pipermail/juniper-nsp/2006-September/006892.html

The ASM shows up in slot 1/2 as ASP - Integrated in place of the
Tunnel PIC. It doesn't appear that one is a pre-requisite for the other.

Regards,

Dermot

-Original Message-
From: Erdem Sener [mailto:[EMAIL PROTECTED] 
Sent: 15 July 2008 12:21
To: Dermot Williams
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Tunnel Services

Hello,

 IIRC, there are two bundles of M7i: either on-board Gigethernet OR
ASM (services module).

 So, it doesn't necessarily mean that all M7i's would have built-in
tunnel functionality. The best way would be
to do a 'show chassis hardware' on the M7i and look for something like:

  PIC 2  REV 07   750-009487   CJ6728ASP -
Integrated (Layer-2-3)

 Cheers,
 Erdem

On Tue, Jul 15, 2008 at 12:05 PM, Dermot Williams
[EMAIL PROTECTED] wrote:
 Yeah, it looks like the TS is on the built-in FPC and not on the RE.
My
 bad.

 Anyway, the main thrust of my question is answered - we can use our
M7i
 routers to terminate/initiate GRE/IP-in-IP tunnels.

 Thanks all

 Dermot

 -Original Message-
 From: Scott Morris [mailto:[EMAIL PROTECTED]
 Sent: 15 July 2008 12:03
 To: 'Eric Van Tol'; Dermot Williams; juniper-nsp@puck.nether.net
 Subject: RE: [j-nsp] Tunnel Services

 Well...  Ok.  So The tunnel pic (or built in one) serves that
function
 as
 well.  should be followed up with:

 Perform a show chassis hardware and make sure you have one!  :)  M5,
 M10,
 M20, etc. don't automatically have one either!

 Scott

 -Original Message-
 From: Eric Van Tol [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, July 15, 2008 6:57 AM
 To: '[EMAIL PROTECTED]'; 'Dermot Williams'; juniper-nsp@puck.nether.net
 Subject: RE: [j-nsp] Tunnel Services

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:juniper-nsp-
 [EMAIL PROTECTED] On Behalf Of Scott Morris
 Sent: Tuesday, July 15, 2008 6:52 AM
 To: 'Dermot Williams'; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] Tunnel Services

 An AS-PIC (or ASM) will terminate tunnels as well, but you don't need
 to have it.  The tunnel pic (or built in one) serves that function as
 well.

 Actually, you do need it on an M10i, as the M7i is the only M-Series
 platform with a built-in tunnel PIC.

 -evt



 ___
 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 Route Reflection and L3VPNs

[Dermot Williams]

Hi all,

 

Quick question, for validation more so than anything else - am I right
in saying that Juniper BGP route reflectors won't import routes
belonging to VRF routing instances?

 

Regards,

 

Dermot Williams






p class=MsoNormalspan lang=EN-GB 
style='font-size:10.0pt;font-family:Arial,sans-serif; color:#808080'
Note:br
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please immediately delete it and all copies of it from your system, destroy any 
hard copies of it and notify the sender. You must not, directly or indirectly, 
use, disclose, distribute, print, or copy any part of this message if you are 
not the intended recipient. Irish Broadband and any of its subsidiaries each 
reserve the right to monitor all e-mail communications through its networks. 
Any views expressed in this message are those of the individual sender, except 
where the message states otherwise and the sender is authorized to state them 
to be the views of any such entity.
/span
emspan lang=EN-GB style='font-size:7.5pt;font-family:Arial,sans-serif; 
color:#808080'
Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, 
Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, 
Dublin 18./span/emspan lang=EN-GBo:p/o:p/span/p
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] CFEB issue

[Dermot Williams]

Does anybody have any idea what symptoms - if any - this would cause?

Regards,

Dermot

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:juniper-nsp-
 [EMAIL PROTECTED] On Behalf Of Bourgeois, Jacob (Jake)** CTR **
 Sent: 14 June 2007 14:48
 To: andy; juniper-nsp@puck.nether.net
 Subject: Re: [j-nsp] CFEB issue
 
 The Packet Forwarding Engine throttled next-hop resolution requests
 from
 the indicated interface, because the high number of requests might
 constitute an attempted denial-of-service (DoS) attack. Examples of
 events that generate next-hop resolution requests include an attempt
to
 forward a packet without an Address Resolution Protocol (ARP) entry
and
 receiving a multicast data packet with no matching route. Normally,
the
 Packet Forwarding Engine forwards the requests to the Routing Engine.
 
 http://www.juniper.net/techpubs/software/junos/junos76/syslog-
 messages76
 /html/pfe12.html
 
 Thanks and Regards,
 Jake Bourgeois
 
 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of andy
 Sent: Thursday, June 14, 2007 8:44 AM
 To: juniper-nsp@puck.nether.net
 Subject: [j-nsp] CFEB issue
 
 Hi,
 
 we have an m7i that has a CFEB that appears to be failing and
 restarting.
 right before it happens we see this message in the logs:
 
 cfeb PFE_NH_RESOLVE_THROTTLED: Next-hop resolution requests from
 interface 66 throttled
 
 Can anyone please explain what this means?
 
 thanks
 
 --
 andy[EMAIL PROTECTED]
 ---
 Never argue with an idiot. They drag you down
 to their level, then beat you with experience.
 ---
 ___
 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





p class=MsoNormalspan lang=EN-GB 
style='font-size:10.0pt;font-family:Arial,sans-serif; color:#808080'
Note:br
This message is for the named person's use only. It may contain confidential, 
proprietary or legally privileged information. No confidentiality or privilege 
is waived or lost by any mistransmission. If you receive this message in error, 
please immediately delete it and all copies of it from your system, destroy any 
hard copies of it and notify the sender. You must not, directly or indirectly, 
use, disclose, distribute, print, or copy any part of this message if you are 
not the intended recipient. Irish Broadband and any of its subsidiaries each 
reserve the right to monitor all e-mail communications through its networks. 
Any views expressed in this message are those of the individual sender, except 
where the message states otherwise and the sender is authorized to state them 
to be the views of any such entity.
/span
emspan lang=EN-GB style='font-size:7.5pt;font-family:Arial,sans-serif; 
color:#808080'
Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, 
Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, 
Dublin 18./span/emspan lang=EN-GBo:p/o:p/span/p
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] RSVP-Signalled LSPs

[Dermot Williams]

Hello all,

 

I have a quick question about RSVP LSPs that one or more of you might be
able to answer for me. According to the JNCIS study guide when an
established LSP experiences a failure and is torn down, the traffic that
was transiting the LSP begins to be forwarded using native IPv4 lookups
in the network.

 

It's unclear from this sentence whether or not the LSP will be rebuilt
using an alternative path or if the router will forward packets using
the IGP indefinitely (requiring a manual clear in order to get it
rebuilt). Our experience is that the LSP will be rebuilt over an
alternative path fairly quickly but to date we have only used them to
carry Layer 2 VPNs so that may impact the behaviour.

 

Could anyone clarify this for me?

 

Dermot Williams

 

Senior Network Engineer

Irish Broadband Internet Services

 

Mobile:   +353 86 3887961

DDI: +353 1 4818481

 








Note:
This message is for the named person's use only.  It may contain confidential, 
proprietary or legally privileged information.  No confidentiality or privilege 
is waived or lost by any mistransmission.  If you receive this message in 
error, please immediately delete it and all copies of it from your system, 
destroy any hard copies of it and notify the sender.  You must not, directly or 
indirectly, use, disclose, distribute, print, or copy any part of this message 
if you are not the intended recipient. Irish Broadband and any of its 
subsidiaries each reserve the right to monitor all e-mail communications 
through its networks. Any views expressed in this message are those of the 
individual sender, except where the message states otherwise and the sender is 
authorized to state them to be the views of any such entity.
 
Thank You. 

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