Re: [j-nsp] MX80 BGP performance after reboot
* Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-19 13:57]: Yes, I agree. But that's a design decision so ATAC is not interested. I'll try to get this to Juniper trough my SE but I don't know if that'll do any good. So Juniper is aware that this is a problem (at least for some people) and there are people working on it. It's not trivial so I don't expect any short-term solutions / improvement. There is also a NANOG discussion regarding this: http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html The current PR seems to be PR836197 https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR836197 Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
* Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-21 10:31]: There is also a NANOG discussion regarding this: http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html Sorry I just glanced at that. That's actually a post from this list. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
Interesting to see that the PR is listed as resolved in 13.1R1. -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Sebastian Wiesinger Sent: Thursday, 21 February 2013 8:32 PM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX80 BGP performance after reboot * Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-19 13:57]: Yes, I agree. But that's a design decision so ATAC is not interested. I'll try to get this to Juniper trough my SE but I don't know if that'll do any good. So Juniper is aware that this is a problem (at least for some people) and there are people working on it. It's not trivial so I don't expect any short-term solutions / improvement. There is also a NANOG discussion regarding this: http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html The current PR seems to be PR836197 https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR836197 Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Message protected by MailGuard: e-mail anti-virus, anti-spam and content filtering.http://www.mailguard.com.au/mg ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Routing loop with OSPFv3 NSSA and external routes
Hi list, I'm scratching my head over an OSPFv3 routing loop to an external NSSA destination that happens when extending the area to another router in the backbone. This is (hopefully) all the relevant parts of the currently (working) setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3, SW1 is an EX4200 VC running 10.4R6. 2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1 exports this route into OSPFv3. 2001:db8::1/128 | (RIPng-advertised) ~ | [SW1 - ID 192.0.2.40] | | (NSSA area 10.0.0.0) | | xe-1/2/0.5 [R2 - ID 192.0.2.4] | ae0.0 | xe-1/2/0.6 | | | (area 0) | (area 0) | | | ae0.0 | xe-1/2/0.6 [R1 - ID 192.0.2.5] On R2 I can see the external NSSA route appear fine: R2 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface xe-1/2/0.5, NH-addr fe80::3 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium ...and on R1 I can see that the ABR R2 translated it into a normal external route and advertised it into area 0: R1 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 NH-interface xe-1/2/0.6, NH-addr fe80::62:2 Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium The problem occurs when I attempt to include R1 into area 10.0.0.0. This I do by adding ae0.0 on R1 and R2 into the area in secondary mode. My problem is that as soon as I do so, traffic to 2001:db8::1/128 starts to loop between R1 and R2. As expected, R1 now sees the type-7 LSA generated by SW1 (and readvertises it into area 0 since it's now an ABR): R1 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium R2, on the other hand, for seam prefers the area 0 external route that was generated by R1 over the NSSA route generated by SW1: R2 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::1 NH-interface xe-1/2/0.6, NH-addr fe80::62:1 Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then R2 prefers the route it learned from SW1's Type-7 LSA within area 10.0.0.0, instead of the normal external route received from R1. I would have expected the same to happen with OSPFv3, but for some reason the priorities are the other way around. Anyone have an idea as to whether this is a bug or if I'm doing something wrong here? BR, -- Tore Anderson ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX2200 - LIBJNX_SNMP_ENGINE_SCAN_FAILURE
Joel Dahl writes: Hi, I installed a new Juniper EX2200 today, running Junos 11.4R5.7. Upon every commit I get the following error message (but the commit succeeds): root@testsw# commit check LIBJNX_SNMP_ENGINE_SCAN_FAILURE: snmp_engine_read: fscanf : /var/db/snmp_engine.db scann ing: full_engine_id Error: Unknown error: 0 configuration check succeeds It's also visible in the message log during boot. Is this something I should be worried about? I haven't seen it before. fscanf doesn't set errno, for the %m in the syslog message is meaningless (Unknown error: 0). The LIBJNX_SNMP_ENGINE_SCAN_FAILURE error is listed as: phil@dent help syslog LIBJNX_SNMP_ENGINE_SCAN_FAILURE Name: LIBJNX_SNMP_ENGINE_SCAN_FAILURE Message: function-name: fscanf : filename scanning: data Error: error-message Help: SNMP engine data file scan operation failed Description: A Junos process could not perform the scan operation on the indicated SNMP engine data file. Type: Error: An error occurred Severity: critical Facility: ANY Cause: An internal software failure occurred. Action:Contact your technical support representative. For more information, see http://kb.juniper.net/InfoCenter/index?page=contentid=KB18953. phil@dent I'm having trouble getting to this link, but my guess is that there's some broken data in your /var/db/snmp_engine.db file. Thanks, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 BGP performance after reboot
On Feb 21, 2013, at 2:31 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: * Sebastian Wiesinger juniper-...@ml.karotte.org [2013-02-19 13:57]: Yes, I agree. But that's a design decision so ATAC is not interested. I'll try to get this to Juniper trough my SE but I don't know if that'll do any good. So Juniper is aware that this is a problem (at least for some people) and there are people working on it. It's not trivial so I don't expect any short-term solutions / improvement. There is also a NANOG discussion regarding this: http://mailman.nanog.org/pipermail/nanog/2013-January/054694.html The current PR seems to be PR836197 https://prsearch.juniper.net/InfoCenter/index?page=prcontentid=PR836197 Sebastian, PR 836197 is a problem that some customers are seeing, but it is not the problem that you reported in this thread. Your issue appears to be (primarily) an issue with sampled. --Stacy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Routing loop with OSPFv3 NSSA and external routes
Hi, Section 4.8.5 http://tools.ietf.org/html/rfc5340#section-4.8.5. (Calculating AS External and NSSA Routes from OSPFv3) reference section 2.5 from NSSA http://tools.ietf.org/html/rfc3101#section-2.5 with the assumption RFC1583Compatibility is disabled. Seems like bug for me. Best Regards, Krasi On Thu, Feb 21, 2013 at 1:55 PM, Tore Anderson t...@fud.no wrote: Hi list, I'm scratching my head over an OSPFv3 routing loop to an external NSSA destination that happens when extending the area to another router in the backbone. This is (hopefully) all the relevant parts of the currently (working) setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3, SW1 is an EX4200 VC running 10.4R6. 2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1 exports this route into OSPFv3. 2001:db8::1/128 | (RIPng-advertised) ~ | [SW1 - ID 192.0.2.40] | | (NSSA area 10.0.0.0) | | xe-1/2/0.5 [R2 - ID 192.0.2.4] | ae0.0 | xe-1/2/0.6 | | | (area 0) | (area 0) | | | ae0.0 | xe-1/2/0.6 [R1 - ID 192.0.2.5] On R2 I can see the external NSSA route appear fine: R2 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface xe-1/2/0.5, NH-addr fe80::3 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium ...and on R1 I can see that the ABR R2 translated it into a normal external route and advertised it into area 0: R1 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 NH-interface xe-1/2/0.6, NH-addr fe80::62:2 Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium The problem occurs when I attempt to include R1 into area 10.0.0.0. This I do by adding ae0.0 on R1 and R2 into the area in secondary mode. My problem is that as soon as I do so, traffic to 2001:db8::1/128 starts to loop between R1 and R2. As expected, R1 now sees the type-7 LSA generated by SW1 (and readvertises it into area 0 since it's now an ABR): R1 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium R2, on the other hand, for seam prefers the area 0 external route that was generated by R1 over the NSSA route generated by SW1: R2 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::1 NH-interface xe-1/2/0.6, NH-addr fe80::62:1 Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then R2 prefers the route it learned from SW1's Type-7 LSA within area 10.0.0.0, instead of the normal external route received from R1. I would have expected the same to happen with OSPFv3, but for some reason the priorities are the other way around. Anyone have an idea as to whether this is a bug or if I'm doing something wrong here? BR, -- Tore Anderson ___ 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] PFE of EX4200 stack
Hi Experts, I know that in EX4200 switch 48T, we have 3 PFE. If we have two EX4200 Stacked : 1. is the number become 6 PFE ? 2. how can we locate them ? 3. how they are numbered ? mpfe0 to mpfe5 ? (because i have an alarm message in the log showing mpfe2 and i want to know wich PFE is it impacted ? in SW1 or SW2) *Kind Regards,* *Rachid DHOU* ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] PFE of EX4200 stack
We can run specific commands to get the virtual chassis topology *show virtual-chassis active-topology * *show virtual-chassis device-topology * *These show the members and associated links etc. * *If this doesnt do what you need have a look at **show virtual-chassis vc-path * *DO these help? I dont have a VC accessible to me at the moment to double check. * On 21 February 2013 17:35, Rachid DHOU rachid.d...@gmail.com wrote: Hi Experts, I know that in EX4200 switch 48T, we have 3 PFE. If we have two EX4200 Stacked : 1. is the number become 6 PFE ? 2. how can we locate them ? 3. how they are numbered ? mpfe0 to mpfe5 ? (because i have an alarm message in the log showing mpfe2 and i want to know wich PFE is it impacted ? in SW1 or SW2) *Kind Regards,* *Rachid DHOU* ___ 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] Routing loop with OSPFv3 NSSA and external routes
Looks like R2 has 2 equal-cost Ext routes, both with metric-type 2. What happens if you redistribute on SW1 with metric-type 1? Also, what do your link metrics look like? Are they BW-related or just 1 for any link (LAG or single 1/10GE)? Lastly, what happens if R1 has no-nssa-abr configured? Thanks Alex - Original Message - From: Tore Anderson t...@fud.no To: Juniper List juniper-nsp@puck.nether.net Sent: Thursday, February 21, 2013 11:55 AM Subject: [j-nsp] Routing loop with OSPFv3 NSSA and external routes Hi list, I'm scratching my head over an OSPFv3 routing loop to an external NSSA destination that happens when extending the area to another router in the backbone. This is (hopefully) all the relevant parts of the currently (working) setup. The two routers R1 and R2 are MX-es running JUNOS 12.2R3, SW1 is an EX4200 VC running 10.4R6. 2001:db8::1/128 gets advertised to SW1 by a host using RIPng, and SW1 exports this route into OSPFv3. 2001:db8::1/128 | (RIPng-advertised) ~ | [SW1 - ID 192.0.2.40] | | (NSSA area 10.0.0.0) | | xe-1/2/0.5 [R2 - ID 192.0.2.4] | ae0.0 | xe-1/2/0.6 | | | (area 0) | (area 0) | | | ae0.0 | xe-1/2/0.6 [R1 - ID 192.0.2.5] On R2 I can see the external NSSA route appear fine: R2 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface xe-1/2/0.5, NH-addr fe80::3 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium ...and on R1 I can see that the ABR R2 translated it into a normal external route and advertised it into area 0: R1 show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 NH-interface xe-1/2/0.6, NH-addr fe80::62:2 Area 0.0.0.0, Origin 192.0.2.4, Fwd NZ, Priority medium The problem occurs when I attempt to include R1 into area 10.0.0.0. This I do by adding ae0.0 on R1 and R2 into the area in secondary mode. My problem is that as soon as I do so, traffic to 2001:db8::1/128 starts to loop between R1 and R2. As expected, R1 now sees the type-7 LSA generated by SW1 (and readvertises it into area 0 since it's now an ABR): R1 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::2 Area 10.0.0.0, Origin 192.0.2.40, Type 7, P-bit, Fwd NZ, Priority medium R2, on the other hand, for seam prefers the area 0 external route that was generated by R1 over the NSSA route generated by SW1: R2 run show ospf3 route 2001:db8::1 extensive Prefix Path Route NH Metric Type Type Type 2001:db8::1/128 Ext2 NetworkIP 2 NH-interface ae0.0, NH-addr fe80::1 NH-interface xe-1/2/0.6, NH-addr fe80::62:1 Area 0.0.0.0, Origin 192.0.2.5, Fwd NZ, Priority medium I have the exact same topology set up for IPv4/OSPFv3/RIPv2, and then R2 prefers the route it learned from SW1's Type-7 LSA within area 10.0.0.0, instead of the normal external route received from R1. I would have expected the same to happen with OSPFv3, but for some reason the priorities are the other way around. Anyone have an idea as to whether this is a bug or if I'm doing something wrong here? BR, -- Tore Anderson ___ 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] MX80 BGP performance after reboot
* Stacy W. Smith st...@acm.org [2013-02-21 15:57]: Sebastian, PR 836197 is a problem that some customers are seeing, but it is not the problem that you reported in this thread. Your issue appears to be (primarily) an issue with sampled. Yes, but the underlying issue seems to be RIB/FIB sync time. And I hope that that will get fixed. As ATAC tells me it's working as designed that's the only thing to look forward to. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX Remote log denied traffic
So fingers crossed that this is an easy one for you guys,
Device is an SRX210BE running 11.4R5.5 code.
ive added the syslog host to the config
meeks@MeeksNet-SRX210 show configuration system syslog
archive size 100k files 3;
user * {
any emergency;
}
host 192.168.1.12 {
any any;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
file security {
security any;
}
file default-log-messages {
any any;
match (requested 'commit' operation)|(copying configuration to
juniper.save)|(commit complete)|ifAdminStatus|(FRU power)|(FRU
removal)|(FRU insertion)|(link UP)|(vc add)|(vc
delete)|transitioned|Transferred|transfer-file|QFABRIC_NETWORK_NODE_GROUP|QFABRIC_SERVER_NODE_GROUP|QFABRIC_NODE|(license
add)|(license delete)|(package -X update)|(package -X
delete)|GRES|CFMD_CCM_DEFECT|LFMD_3AH|MEDIA_FLOW_ERROR|RPD_MPLS_PATH_BFD;
structured-data;
}
and implemented the default deny template i found here:
http://kb.juniper.net/InfoCenter/index?page=contentid=KB20778actp=RSS
meeks@MeeksNet-SRX210 show configuration groups
default-deny-template {
security {
policies {
from-zone untrust to-zone trust {
policy default-deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
}
}
}
}
meeks@MeeksNet-SRX210 show configuration apply-groups
## Last commit: 2013-02-21 16:05:36 EST by meeks
apply-groups default-deny-template;
however, when i log on to the syslog host, and tail the syslog file i do
not see denies being logged remotely.
if i apply the session-init and session-close options to permitted traffic,
it does get logged remotely.
Alternatively,
creating a new policy has the same result, regardless if i use reject or
deny
meeks@MeeksNet-SRX210# show security policies from-zone untrust to-zone
trust policy deny-all
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
my google-foo is failing, so i hope you guys can help.
Looking forward to hearing back from you,
Mike
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] DEJUG Mailinglists
Hi list, shameless plug incoming! Please excuse me switching to german. (this is about introducing a german juniper user group including several mailinglists). Um diverse Themen um Juniper Networks im deutschsprachigen Raum zu diskutieren, moechte ich gerne zunaechst im Rahmen einer Akzeptanzpruefung eine deutsche Juniper User Group (DEJUG) ins Leben rufen. Dazu gibt es einige Mailinglisten, die thematisch in mehrere Themenbereiche aufgeteilt sind: - nsp - ent - sec - certs Sollte selbsterklaerend sein. Zu erreichen unter: https://martini.dejug.net/mailman Ich bitte um Andrang und weiterfuehrende Propaganda ;) Viele Gruesse, Sven ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
