Re: [j-nsp] Suppress particular messages from syslog
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Robert Hass
Sent: Friday, December 30, 2011 7:49 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Suppress particular messages from syslog
Hi
Is any way to configure something to suppress selected messages from
syslog [messages].
You should be able to use something similar to the following and just
change the matched string to suit your needs
I want to suppress this (running JunOS 10.4):
Dec 30 12:11:46 r02 /kernel: tcp_auth_ok: Packet from 62.77.4.5:179
missing MD5 digest
set system syslog host x.x.x.x match "!(.* Packet from 62.77.4.5:179
missing MD5 digest.*)"
and
Dec 30 15:08:34 r02 tfeb0 MIC(1/1) link 2 SFP receive power low alarm
set
Dec 30 15:08:55 r02 tfeb0 MIC(1/1) link 2 SFP receive power low alarm
cleared
set system syslog file messages match "!(.* MIC(1/1) link 2 SFP receive
power low.*)"
My current syslog configuration:
file messages {
any notice;
authorization info;
}
Rob
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Cheers,
Andy
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 troubles.
Keith, I have operated MX-480 networks installed with DPC's and within the last year have deployed MX-480's with MPC's/MIC's and haven't experienced the hardware issues you have run into. Based on my experiences with Juniper hardware, I would say you've just had unfortunate luck. Cheers, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Keith Sent: Wednesday, April 13, 2011 9:18 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] MX480 troubles. Hi. You folks have been great at answering some of my questions regarding our MX480, but have come across some big problems that me and the person who signed the PO are not very pleased about. A month or so ago I found we had a bad MPC card. Ok so we RMA'd it. This week I came on site to do some work on the MX. Long story short, new MPC card that had been installed and running for 15 days was flaky and possibly even the MIC too after I spent a day troubleshooting with Juniper TAC. So on a non production box, just sitting in the rack, powered up for a little more than 8 weeks, passing no traffic at all, it's on the 3rd MPC and 2nd MIC. I have to say at this point I am really not impressed with Juniper hardware. I'm sure the box is ok when its running properly, but at this point I'm having doubts about Juniper. We were pretty stoked about this box, now...not so much. Is this an anomaly and we got a lemon? Or have any others had to replace this many parts in so short of time? ___ 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] SNMP command: request snmp spoof-trap
I assume if it is in the logs as a trap, that a trap was indeed sent. Since the trap should have originated from the RE, you should be able to see it leave the router with 'monitor traffic interface ' on the interface that is the best route back to your NMS. Cheers, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Keith Sent: Wednesday, April 06, 2011 11:27 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] SNMP command: request snmp spoof-trap Just going through some SNMP things on the MX, 10.4. When doing a request snmp spoof-trap does the box actually send an SNMP trap to any configured targets? SNMP traps are setup for rmon-alarm and chassis alerts. I can see the SNMP trap being generated in the log file on the MX, but using Wireshark, I do not see any traps coming into the host I have setup to receive traps. I just want to be sure before I start digging through the trap host configs and PIX config in front of the NMS to make sure I have them setup correctly. Thanks, Keith. ___ 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] ifAlias on sub-interfaces
Serge, I saw this same behavior in 10.2R3.10 but didn't open a JTAC case on it. I haven't seen it since I moved to 10.2S6 but that doesn't mean it isn't still present ;-) My workaround for this was to edit the interface a time or two and commit the changes, eventually the ifAlias would be populated. Cheers, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Serge Vautour Sent: Tuesday, March 15, 2011 9:43 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] ifAlias on sub-interfaces Sorry about missing the details! I'm seeing this on 10.2S6. I've continued to test after sending the first post and found that it is only happening on some interfaces. I can't find anything yet that sets the "broken" interfaces apart. I'll continue to test and open a case with JTAC if necessary. My guess is this will in fact be some bug. Serge - Original Message From: Keegan Holley To: Chris Adams ; juniper-nsp@puck.nether.net Sent: Tue, March 15, 2011 1:16:24 PM Subject: Re: [j-nsp] ifAlias on sub-interfaces On Tue, Mar 15, 2011 at 11:53 AM, Chris Adams wrote: > Once upon a time, Serge Vautour said: > > I'm not seeing sub-interface descriptions show up in ifAlias. Has anyone > seen > > this before? > > No, I haven't had that problem. You didn't say what platform, JUNOS > version, etc. though. > I've had to look through release notes lately and I remember seeing a bunch of bugs related to the interface polling, ifIndex and the like. I agree though they are all JunOS and platform specific. Have you consulted Juniper and/or looked at the release notes for your Junos version? > > -- > Chris Adams > Systems and Network Administrator - HiWAAY Internet Services > I don't speak for anybody but myself - that's enough trouble. > ___ > 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] Aggregate Routes Revisited
Is ok to disagree as your captures below prove your point and that you
are correct.
Apologies for the misinfo
Andy
-Original Message-
From: Smith W. Stacy [mailto:st...@acm.org]
Sent: Wednesday, January 12, 2011 12:02 PM
To: Andy Vance
Cc: Paul Stewart; juniper-nsp
Subject: Re: [j-nsp] Aggregate Routes Revisited
Sorry, but I still disagree with you. Only the active route in the
routing table is evaluated by export policy. I think the captures below
illustrate my point.
--Stacy
u...@host> show configuration protocols bgp
group foo {
export static-bgp;
neighbor 192.168.0.2 {
peer-as 2;
}
}
u...@host> show configuration routing-options
static {
route 192.168.5.0/24 {
discard;
preference 240;
}
}
autonomous-system 1;
u...@host> show configuration policy-options policy-statement static-bgp
term static-routes {
from {
protocol static;
route-filter 192.168.5.0/24 exact;
}
then {
community add our_nets;
next-hop self;
accept;
}
}
term next-policy {
then next policy;
}
u...@host> show route 192.168.5.0/24
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.5.0/24 *[OSPF/150] 00:01:16, metric 0, tag 0
> via lt-0/0/0.2
[Static/240] 00:18:09
Discard
u...@host> show route advertising-protocol bgp 192.168.0.2
u...@host> configure
Entering configuration mode
[edit]
u...@host# delete routing-options static route 192.168.5.0/24 preference
[edit]
u...@host# commit and-quit
commit complete
Exiting configuration mode
u...@host> show route 192.168.5.0/24
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.5.0/24 *[Static/5] 00:00:10
Discard
[OSPF/150] 00:02:06, metric 0, tag 0
> via lt-0/0/0.2
u...@host> show route advertising-protocol bgp 192.168.0.2
inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED LclprefAS
path
* 192.168.5.0/24 SelfI
u...@host>
On Jan 12, 2011, at 12:19 PM, Andy Vance wrote:
> If Paul has an export policy picking up static routes, it should. An
> export policy such as this
>
> policy-statement static-bgp {
>term static-routes {
>from {
>protocol static;
>tag
>route-filter 192.168.5.0/24 exact;
>}
>then {
>community add ;
>next-hop self
>accept;
>}
>}
>term next-policy
>then {
>next policy;
>}
>}
>
> and applied as an export policy on the bgp groups, where it is needed,
> should pick up the static route set to discard and allow it to be
> exported to the neighbors as it is a valid static route known by
> protocol static. Agreed it isn't the best route in the routing table,
> the OSPF route is, and will not be used for forwarding.
>
> I don't have a lab available to test quickly, I'm going from memory, I
> could be wrong...
>
> Andy
>
>
>
> -Original Message-
> From: Smith W. Stacy [mailto:st...@netfigure.com]
> Sent: Wednesday, January 12, 2011 10:36 AM
> To: Andy Vance
> Cc: Paul Stewart; juniper-nsp
> Subject: Re: [j-nsp] Aggregate Routes Revisited
>
> I don't think this will accomplish what Paul is asking for.
>
> The static route /w preference 240 will not become the active route as
> long as the OSPF route for the same prefix is present, and only active
> routes are evaluated by the export policy.
>
> --Stacy
>
>
> On Jan 12, 2011, at 10:19 AM, Andy Vance wrote:
>
>> Paul,
>>
>> Assuming you have a static route policy to pick up static routes into
>> BGP, couldn't you just pin that /24 route down to discard, with a
high
>> priority of 240 or so, to inject it into BGP, then allow the routing
>> table to use the OSPF route for packets destined to that /24 once
>> received?
>>
>> Cheers,
>>
>> Andy Vance, IP Engineer
>> 360networks
>> 2101 4th Ave., Suite 2000
>> Seattle, WA 98121
>> 253.307.7546 (c)
>> andy.va...@360networks.com
>> www.360networks.com
>>
>> -Original Message-
>> From: juniper-nsp-boun...@puck.nether.net
>> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul
Stewart
>> Sent: Wednesday, January 12, 2011 8:59 AM
&
Re: [j-nsp] Aggregate Routes Revisited
If Paul has an export policy picking up static routes, it should. An
export policy such as this
policy-statement static-bgp {
term static-routes {
from {
protocol static;
tag
route-filter 192.168.5.0/24 exact;
}
then {
community add ;
next-hop self
accept;
}
}
term next-policy
then {
next policy;
}
}
and applied as an export policy on the bgp groups, where it is needed,
should pick up the static route set to discard and allow it to be
exported to the neighbors as it is a valid static route known by
protocol static. Agreed it isn't the best route in the routing table,
the OSPF route is, and will not be used for forwarding.
I don't have a lab available to test quickly, I'm going from memory, I
could be wrong...
Andy
-Original Message-
From: Smith W. Stacy [mailto:st...@netfigure.com]
Sent: Wednesday, January 12, 2011 10:36 AM
To: Andy Vance
Cc: Paul Stewart; juniper-nsp
Subject: Re: [j-nsp] Aggregate Routes Revisited
I don't think this will accomplish what Paul is asking for.
The static route /w preference 240 will not become the active route as
long as the OSPF route for the same prefix is present, and only active
routes are evaluated by the export policy.
--Stacy
On Jan 12, 2011, at 10:19 AM, Andy Vance wrote:
> Paul,
>
> Assuming you have a static route policy to pick up static routes into
> BGP, couldn't you just pin that /24 route down to discard, with a high
> priority of 240 or so, to inject it into BGP, then allow the routing
> table to use the OSPF route for packets destined to that /24 once
> received?
>
> Cheers,
>
> Andy Vance, IP Engineer
> 360networks
> 2101 4th Ave., Suite 2000
> Seattle, WA 98121
> 253.307.7546 (c)
> andy.va...@360networks.com
> www.360networks.com
>
> -Original Message-
> From: juniper-nsp-boun...@puck.nether.net
> [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
> Sent: Wednesday, January 12, 2011 8:59 AM
> To: 'juniper-nsp'
> Subject: [j-nsp] Aggregate Routes Revisited
>
> Hi folks..
>
>
>
> Earlier this year I posed a question to the list and never did things
> working the way I expected - so I'm revisiting the topic. I got
several
> helpful replies from folks but either am thick headed or misunderstood
> ;)
>
>
>
> In our Cisco network, we use the "network" statement in our BGP
> configurations. I'm looking to do similar on our MX platforms - my
> "saving
> grace" to date is that the Cisco 7600's are still online and
> contributing
> the routes. The 7600's are coming out shortly and I need to resolve
> this ;)
>
>
>
> Our BGP export is community driven and working fine today (with the
> contributed routes from the 7600 platform). Our own routes are tagged
> with
> 11666:5000 and our transit customers are tagged with 11666:4000 (both
> have
> some additional tags but these catch all - ie 5001 5002 etc)
>
>
>
> Typical upstream connection looks like this:
>
>
>
> type external;
>
> description Level3;
>
> advertise-inactive;
>
> import inbound-level3-v4;
>
> export outbound-level3-v4;
>
> neighbor x.xx.xxx.x {
>
>authentication-key "x"; ## SECRET-DATA
>
>peer-as 3356;
>
> }
>
>
>
> Typical export policy to an upstream looks like this (in this case
> Level3
> which we are prepending once at the moment):
>
>
>
> term lvl3-1 {
>
>from community our_nets;
>
>then {
>
>as-path-prepend 11666;
>
>accept;
>
>}
>
> }
>
> term lvl3-2 {
>
>from community customer_nets;
>
>then accept;
>
> }
>
> term lvl3-3 {
>
>then reject;
>
> }
>
>
>
> So now comes my problem and this is where I start to get confused with
> the
> aggregate route options.
>
>
>
> {master}[edit routing-options aggregate]
>
> route 192.168.0.0/19 community [ 11666:5000 11666:5001 ];
>
>
>
> This works today - we see the entire /19 exported to our
> upstreams/peers.
>
>
>
> Now, in our OSPF tables we have 192.168.0.5/24 for example which we
also
> want to advertise upstream.
>
>
>
> If I add "route 192.168.0.0/19 community [ 11666:5000 11666:5001 ]" to
> the
> aggregate, this won't work as I understand it because there isn't a
more
> specific route to contribute towards it's exis
Re: [j-nsp] Aggregate Routes Revisited
Paul,
Assuming you have a static route policy to pick up static routes into
BGP, couldn't you just pin that /24 route down to discard, with a high
priority of 240 or so, to inject it into BGP, then allow the routing
table to use the OSPF route for packets destined to that /24 once
received?
Cheers,
Andy Vance, IP Engineer
360networks
2101 4th Ave., Suite 2000
Seattle, WA 98121
253.307.7546 (c)
andy.va...@360networks.com
www.360networks.com
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart
Sent: Wednesday, January 12, 2011 8:59 AM
To: 'juniper-nsp'
Subject: [j-nsp] Aggregate Routes Revisited
Hi folks..
Earlier this year I posed a question to the list and never did things
working the way I expected - so I'm revisiting the topic. I got several
helpful replies from folks but either am thick headed or misunderstood
;)
In our Cisco network, we use the "network" statement in our BGP
configurations. I'm looking to do similar on our MX platforms - my
"saving
grace" to date is that the Cisco 7600's are still online and
contributing
the routes. The 7600's are coming out shortly and I need to resolve
this ;)
Our BGP export is community driven and working fine today (with the
contributed routes from the 7600 platform). Our own routes are tagged
with
11666:5000 and our transit customers are tagged with 11666:4000 (both
have
some additional tags but these catch all - ie 5001 5002 etc)
Typical upstream connection looks like this:
type external;
description Level3;
advertise-inactive;
import inbound-level3-v4;
export outbound-level3-v4;
neighbor x.xx.xxx.x {
authentication-key "x"; ## SECRET-DATA
peer-as 3356;
}
Typical export policy to an upstream looks like this (in this case
Level3
which we are prepending once at the moment):
term lvl3-1 {
from community our_nets;
then {
as-path-prepend 11666;
accept;
}
}
term lvl3-2 {
from community customer_nets;
then accept;
}
term lvl3-3 {
then reject;
}
So now comes my problem and this is where I start to get confused with
the
aggregate route options.
{master}[edit routing-options aggregate]
route 192.168.0.0/19 community [ 11666:5000 11666:5001 ];
This works today - we see the entire /19 exported to our
upstreams/peers.
Now, in our OSPF tables we have 192.168.0.5/24 for example which we also
want to advertise upstream.
If I add "route 192.168.0.0/19 community [ 11666:5000 11666:5001 ]" to
the
aggregate, this won't work as I understand it because there isn't a more
specific route to contribute towards it's existence. I opened a JTAC
ticket
and they suggested a policy similar to:
term bgp1 {
from {
protocol ospf;
route-filter 192.168.0.5/24 exact;
}
then {
community add our_nets;
accept;
}
}
term bgp99 {
then reject;
}
This doesn't work neither - there is no BGP route for that particular
192.168.0.5/24 for it to export.
So how do I "inject" this /24 into the BGP tables with a community so
that
it exports? I keep going around in circles on this one ;)
Thanks for your patience ;)
Paul
___
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] M20 JunOS Recommendation
We currently have all of our M20's on 8.5S4 and have had no issues whatsoever, we upgraded from 7.5-daily. 8.5S4 is an extended release and if you're not chasing features, I'd look into utilizing it. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct > 206.971.5144 . Fax > 206.728.1500 Email > ava...@hq.speakeasy.net . Web > www.speakeasy.net Voice . Data . Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jose Madrid Sent: Wednesday, July 21, 2010 7:42 AM To: Juniper List Subject: [j-nsp] M20 JunOS Recommendation I have an M20 that has been working fine for a few years with no real issues running 7.6 R4.3. I have been putting off upgrading this guy long enough and was wondering what you guys thought would be the best version of JunOS to goto now would be. I was thinking something in the 8.5 train, but I know even that is old now. Any recommendations would be much appreciated. Thank you. -- It has to start somewhere, it has to start sometime. What better place than here? What better time than now? ___ 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] Route-leaking between a virtual-router instance and VRF instance
If I'm not mistaken,
vrf-import VRFX_IMPORT;
vrf-export VRFX_EXPORT;
vrf-target {
import target:1:1;
export target:1:1;
isn't going to accomplish what your trying to do here. vrf-target commands
allow you to import/export routes without as many policy hooks but used
together like this, I believe vrf-import/vrf-export is overriding the
vrf-target commands. As well, I didn't see any policy-options config for the
VRFX_IMPORT or VRFX_EXPORT policy your calling. I assume this policy config
would allow your routes to be exported:
edit policy-options
policy-statement VRFX_EXPORT {
term out {
from protocol ospf;
then {
community add VRFX;
accept;
}
}
term reject {
then reject;
}
}
and this would allow your routes to be imported on R3
policy-statement VRFX_IMPORT {
term import {
from {
protocol bgp;
community VRFX;
}
then accept;
}
term reject {
then reject;
}
}
Cheers,
Andy Vance
Sr. Network Engineer
Speakeasy
Direct > 206.971.5144 * Fax > 206.728.1500
Email > ava...@hq.speakeasy.net * Web > www.speakeasy.net
Voice * Data * Managed Services
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ioan Branet
Sent: Thursday, February 11, 2010 8:38 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] Route-leaking between a virtual-router instance and VRF
instance
Hello Group,
I have the following setup:
R3(PE VRF X)R1---R2(PE VRF X)R5 (CE )
On R2 on the interface connecting to R5 i have a virtual-router instance and
run OSPF with R5 in this instance and also a VRF X instance.
I use rib-groups to leak the prefixes from virtual-router instance to VRF X
instance ,but when I want to export these prefixese tp R3 ot seems that I can't
do that,nothing is exported.
I see the prefixes in VRFX.inet.o from R5 but there are no VPNV4 prefixes
advertised to R3 PE.
Is there any posibility to make this leaking?
Here is my config:
R2:
Virtual-router instance between R2 and R5:
routing-instances
virtual-router {
instance-type virtual-router;
interface em2.0;
routing-options {
interface-routes {
rib-group inet virtual-router ->GRT_AND_VRFX;
}
static {
route 0.0.0.0/0 discard;
}
}
protocols {
ospf {
rib-group virtual-router ->GRT_AND_VRFX;
export DEFAULT_ORIGINATE_TAG_X;
area 0.0.0.0 {
interface em2.0;
}
}
}
VRF X routing instance (I do not use any protocol on VRFX and any
interfaces,this is only for export and import into VRFX)
instance-type vrf;
route-distinguisher 1:1;
vrf-import VRFX_IMPORT;
vrf-export VRFX_EXPORT;
vrf-target {
import target:1:1;
export target:1:1;
}
vrf-table-label;
routing-options {
interface-routes {
family inet {
export {
point-to-point;
lan;
}
}
}
I want to leak also routes from VRFX to Global routing table
r...@r2> show configuration routing-options rib-groups
VRFX->virtual-router {
import-rib [ VRFX.inet.0 virtual-router.inet.0 ]; }
virtual-router->GRT_AND_VRFX {
import-rib [virtual-router.inet.0 VRFX.inet.0 inet.0 ]; } r...@r2> show
configuration protocols ospf traceoptions {
file OSPF size 10k world-readable;
flag all;
}
area 0.0.0.0 {
interface em0.0;
interface lo0.0;
}
term CONNECTED {
from protocol direct;
then {
community add VRFX;
accept;
}
}
term OSPF {
from {
protocol ospf;
}
then {
community add VRFX ;
accept;
}
}
term REJECT {
then reject;
}
show configuration policy-options community VRFX members target:1:1;
Routes received on R2 from virtual-router instance from R5 :
r...@r2> show route table OSPF_6746_CASA.inet.0 next-hop 150.1.25.5
virtual_router.inet.0: 15 destinations, 15 routes (15 active, 0 holddown, 0
hidden)
+ = Active Route, - = Last Active, * = Both
5.5.5.5/32 *[OSPF/10] 00:33:40, metric 1
> to 150.1.25.5 via em2.0
10.210.192.0/20*[OSPF/10] 00:33:40, metric 1
> to 150.1.25.5 via em2.0
10.210.192.5/32*[OSPF/10] 00:33:40, metric 1
> to 150.1.25.5 via em2.0
These routes are leaked to VRFX ok:
r...@r2> show route table VRFX next-hop 150.1.25.5
VRFX.inet.0: 29 destinations, 29 routes (29 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
5.5.5.5/32 *[OSPF/10] 00:36:40, metric 1
> to 150.1.25.5 via em2.0
10.210.192.0/20*[OSPF/10] 00:36:40, metric 1
> t
Re: [j-nsp] local VS direct routes?
Direct routes are to the prefixes assigned to interfaces on the router, local routes are for the /32 interface addresses on those directly connected interfaces. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct > 206.971.5144 * Fax > 206.728.1500 Email > ava...@hq.speakeasy.net * Web > www.speakeasy.net Voice * Data * Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Wouter van den Bergh Sent: Friday, February 05, 2010 6:30 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] local VS direct routes? Hi all, I am new on this list and new to Juniper. Currently I'm following several Juniper courses to get known with Juniper devices. One thing we can't seem to figure out is the difference between local and direct routes. (both same '0' preference). Does anyone know why there is specified local and direct rather than just local or direct? 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] L3VPN advertises the directly connected subnet - why?
Without config snapshots of the VRF, the import policy and the export policy, it is difficult to say why you see this behavior, I have some ideas but I don't want to guess. Can you provide config snapshots? I don't want to assume and head down some road that may not be relevant. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct > 206.971.5144 * Fax > 206.728.1500 Email > ava...@hq.speakeasy.net * Web > www.speakeasy.net Voice * Data * Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeroen Valcke Sent: Tuesday, January 26, 2010 7:52 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] L3VPN advertises the directly connected subnet - why? Hi, I'm doing some testing with simple plain L3VPNs and ran into some weird behaviour. At least I think it's weird. Perhaps somebody can enlighten me. A CE router is exchanging routes with the PE through BGP. These routes are correctly advertised 'over' the L3VPN towards other CE routers. However the directly connected subnet between the CE and PE is also advertised to the other CE routers. Why is this? It was my understanding that only the routes learned from the BGP advertisement from the CE router would be advertised to the other CE routers. What's the reasoning behind this behaviour? Can I alter this behaviour? And if yes, is it safe to do so? Weirdly enough I've found a Juniper KB [1] which seems to document the exact opposite behaviour of what I'm experiencing. This KB describes a case where the directly connected subnet is not advertised over the L3VPN and how to 'fix' this. Thanks for any clues. Kind regards, -Jeroen- PS: JunOS version on the PE routers is 9.3R2.8 [1] http://kb.juniper.net/index?page=content&id=KB12430&cat=BGP&actp=LIST -- Jeroen Valcke ___ 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] How to delete the BGP Route for IPVPN
Which route are you trying to delete, an imported route into this routing
instance or an exported route that is advertised out of this routing instance?
You should be able to use a route filter in your policy-options
policy-statement to keep the route your trying to remove from being advertised
or accepted.
for example, I use an export filter such as this to not advertise certain routes
policy-statement andys-out {
term deny-default {
from {
protocol static;
route-filter 0.0.0.0/0 exact;
}
then reject;
}
term out {
from protocol [ direct static ];
then {
community add vpn-andy-router1;
accept;
}
}
term reject {
then reject;
Cheers,
Andy Vance
Sr. Network Engineer
Speakeasy
Direct > 206.971.5144 • Fax > 206.728.1500
Email > ava...@hq.speakeasy.net • Web > www.speakeasy.net
Voice • Data • Managed Services
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of venkata saranu
Sent: Thursday, January 21, 2010 12:19 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] How to delete the BGP Route for IPVPN
Hi Experts ,
Could you please help me in deleting the BGP Route which was configured like
below...
I want to delete only one route at a time ... please assist me here thanks in
advance
routing-instances
MS-2 {
instance-type vrf;
interface lo0.1;
route-distinguisher 2828:12002;
vrf-import IMPORT-VPN-12002-COMMUNITY;
vrf-export EXPORT-VPN-12002-COMMUNITY;
vrf-target import target:2828:2;
vrf-table-label;
protocols {
bgp {
group CE {
type external;
family inet {
any;
}
family inet6 {
unicast;
}
peer-as 2000;
neighbor 132.1.1.2;
}
}
pim {
vpn-group-address 120.1.1.99;
rp {
static {
address 114.1.5.2;
}
}
interface lo0.1 {
mode sparse;
version 2;
}
}
}
--
o__
-,>/'_
(_) \ (_) - - - - -వెంకట శరణు - - - -
___
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] junos-jseries-7.4R2.6
Does anyone happen to have the 7.4R2.6 jinstall for the J-series laying around? I need a copy and have yet to find one. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct > 206.971.5144 * Fax > 206.728.1500 Email > ava...@hq.speakeasy.net<mailto:ava...@hq.speakeasy.net> * Web > www.speakeasy.net<http://www.speakeasy.net/> Voice * Data * Managed Services ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Slot zero on the ERX chassis
None that I'm aware of, can you shoot a show hard and a show ver from that chassis with the card in? We have GE cards in slot 0 but I don't recall any card type limitation. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct > 206.971.5144 * Fax > 206.728.1500 Email > ava...@hq.speakeasy.net * Web > www.speakeasy.net Voice * Data * Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Scott Weeks Sent: Tuesday, September 01, 2009 1:01 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Slot zero on the ERX chassis Is there an issue where the ERX will not accept a DS3-4P I/O and OC3/OC12/DS3-ATM card set in slot zero? I am having no luck with search engines and our vendor's support folks. There is no problem when I put them in other slots. scott ___ 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] DPC-R-40GE-SFP and Transition Media Converter
I've seen this in the past with media converters and was able to work around it
using
gigether-options {
no-auto-negotiation;
Hope that helps,
Andy
-Original Message-
From: juniper-nsp-boun...@puck.nether.net
[mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ozgur Guler
Sent: Thursday, April 09, 2009 7:58 AM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] DPC-R-40GE-SFP and Transition Media Converter
Hi All,
I am having a problem to get the line protocol up between Juniper
DPC-R-40GE-SFP and my media converter (Transition multimode SFP). Has anyone
seen this previously? Is there a way to solve this ?
Thanks
Ozgur
___
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] Juniper BGP invalid attributes
Richard, Appears these are the releases that it has been fixed in. 8-1-4p0-4, 8-2-4p0-7, 9-0-2p0-1, 9-1-2p0-1, 9-2-1p0-1, 9-3-0p0-1, 10-0-0 This caused us problems this evening as well and some issues we continue to work on with JTAC at this time. Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Richard A Steenbergen Sent: Tuesday, March 17, 2009 6:23 PM To: Richard A Steenbergen Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Juniper BGP invalid attributes On Tue, Mar 17, 2009 at 07:54:37PM -0500, Richard A Steenbergen wrote: > Who else just noticed Juniper bgp sessions all over the place flapping > with: > > code 3 (Update Message Error) subcode 1 (invalid attribute list) code > 3 (Update Message Error) subcode 11 (AS path attribute problem) > Received BAD update for family inet-unicast(1), prefix 193.5.68.0/23 Ok got some packet captures of the invalid update, it looks like 193.5.68.0/23 was being announced and propagated globally with the leaked confederations in AS4_PATH issue described in PSN-2009-01-200. What code has the fix for this issue? The PSN doesn't say. Since these invalid attributes are now leaking out globally, it might be worth an update. :) -- Richard A Steenbergenhttp://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
