[j-nsp] Firewall Filters + Counters Missing From SNMP Query

[Mark Tinka]

Hi all.

I am querying an MX480 running Junos 14.2R5.8 via SNMPv3 for firewall
filters and their associated counters.

I notice that the query is skipping a number of firewall filters and
counters from the results. I have modified some firewall filter and
counter names so that they are short (less than 24x characters), but the
SNMP query still omits them.

Anyone know what this could be? The OID's in question are:

.1.3.6.1.4.1.2636.3.5.2.1.6
.1.3.6.1.4.1.2636.3.5.2.1.7
.1.3.6.1.4.1.2636.3.5.2.1.4
.1.3.6.1.4.1.2636.3.5.2.1.5

All help appreciated.

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

Re: [j-nsp] Optimizing the FIB on MX

[Olivier Benghozi]

I think that this recommandation makes sense: I don't see any good reason to 
have, by default, eBGP routes with a better administrative distance 
("preference", in Junos) than your IGP (OSPF or ISIS).

This been said, in all BGP implementations, the BGP best path selection algo 
includes a [prefer eBGP routes] item, whatever the admin-distance value is set 
when BGP pushes its routes to the RIB.
Both things are different.

So eBGP _is_ preferred over iBGP (at a certain point in the selection algo). 
According to the protocol definition, in fact (RFC 4271 page 81).


> 18 feb 2016 at 12:12, sth...@nethelp.no wrote :
> 
>> *not sure what was Juniper and ALU thinking when they came up with the same 
>> protocol preference for eBGP and iBGP routes, there's a ton of reasons why 
>> you always want to prefer closest AS-EXIT.
> 
> Probably the same as Cisco, when Cisco on multiple occasions have
> promoted using the same administrative distance (200) for both EBGP
> and IBGP as "best practice".

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

Re: [j-nsp] Optimizing the FIB on MX

[Vincent Bernat]

 ❦ 18 février 2016 10:50 GMT, Adam Vitkovsky  :

>> You are right. I didn't understand your answer the first time as I thought 
>> that
>> PIC was for "programmable integrated circuit", so I thought this was a plan
>> for Juniper to fix the problem with some dedicated piece of hardware.

> Sorry about that, I'll try to be more explicit in my future posts.
>
> The setup is really easy
[...]

Oh, many thanks for the detailed setup! I'll need some time to update to
15.1 and I'll get back to you with the results once this is done.

> 5)always prefer eBGP over iBGP*
> set policy-options policy-statement FROM_TRANSIT term INGRESS_POLICY_A then 
> preference 169 <
> -by default,
> If the MX140-A from our previous example loses its Transit link it will (via 
> BGP-PIC) immediately reroute traffic to MX140-B
> However by default MX140-B has a best path via MX140-A -so until it
> receives withdrawn from MX140-A it'll loop traffic back to MX140-A.
> That's why you want MX140-B to prefer it's local exit.
>
> *not sure what was Juniper and ALU thinking when they came up with the
> same protocol preference for eBGP and iBGP routes, there's a ton of
> reasons why you always want to prefer closest AS-EXIT.

Unfortunately, I don't have the same upstream on both MX and for some
routes, one of them may have a better route than the other. The two MX
are advertising just a default, so they can attract traffic that would
be better routed by their neighbor. I'll try to think a bit about what's
more important.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Vincent Bernat]

 ❦ 18 février 2016 07:31 -0600, Colton Conor  :

> So is the MX-104 processor really that underpowered? I have heard
> reports that is was too underpowered for its pricepoint, and now I am
> starting to believe it. Vincent what are your thoughts? 

Well, I don't have enough experience with it. However, it's unfortunate
that it needs a pricey license to handle a full view but is not able to
accomodate it efficiently (without BGP PIC).
-- 
Work consists of whatever a body is obliged to do.
Play consists of whatever a body is not obliged to do.
-- Mark Twain
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Vincent Bernat]

 ❦ 17 février 2016 21:07 GMT, Alexander Arseniev  :

> True, one cannot match on "next-hop" in "condition", only on exact
> prefix+table name.
> But this can be done using "route isolation" approach.
> So, the overall approach is:
> 1/ create a separate table and leak a 0/0 route there matching on 0/0
> exact + next-hop ("isolate the interested route"). Use
> "instance-import" + policy.
> 2/ create condition
>
> policy-options {
>  condition default-to-upstream {
>   if-route-exists {
>0.0.0.0/0;
>table isolate-0/0.inet.0;
>   }
>  }
>
> 3/ use condition to match & reject the specifics:
>
> policy-options {
>  policy-statement reject-same-nh-as-0/0 {
>   term 1  {
>   from {
> protocol bgp;
>route-filter 0/0 longer;
> condition default-to-upstream;
>   next-hop 198.18.1.1;
> }
> then reject;
> }
>  term 2  {
>   from {
> protocol bgp;
>route-filter 0/0 longer;
>   next-hop 198.18.1.1;
> }
> then accept;
> }

Just by curiosity, I tried your approach and it almost work. However,
for some reason, the condition can match when there is no route in the
associated table. I didn't do exactly as you proposed, so maybe I am
doing something wrong. I am not really interested in getting to the
bottom of this matter. I just post my current configuration in case
somebody is interested:

 
https://github.com/vincentbernat/network-lab/blob/d984d6c5f847b96a131b240d91346b46bfaecac9/lab-vmx-fullview/vMX1.conf#L106-L115

If I enable term 4, it catches all routes whose next-hop is
192.0.2.129 despite the condition being false. In the RIB, I have many
routes whose next-hop is 192.0.2.129:

root@vMX1# run show route next-hop 192.0.2.129

inet.0: 1110 destinations, 1869 routes (1110 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0   [BGP/140] 00:38:12, MED 10, localpref 100
  AS path: 65002 ?, validation-state: unverified
> to 192.0.2.129 via ge-0/0/1.0
[OSPF/150] 00:37:31, metric 10, tag 0
> to 192.0.2.129 via ge-0/0/1.0
1.0.240.0/20   *[BGP/140] 00:38:12, MED 10, localpref 100
  AS path: 65002 3257 3356 4651 9737 23969 I, 
validation-state: unverified
> to 192.0.2.129 via ge-0/0/1.0
1.1.1.0/24 *[BGP/140] 00:38:12, MED 10, localpref 100
  AS path: 65002 8758 15576 6772 13030 226 I, 
validation-state: unverified
> to 192.0.2.129 via ge-0/0/1.0
[...]

But none of them make it to the FIB:

root@vMX1# run show route forwarding-table matching 1.1.1.0/24
Routing table: default.inet
Internet:

Routing table: __master.anon__.inet
Internet:

The peer.inet.0 table is empty:

root@vMX1# run show route summary
Autonomous system number: 64512
Router ID: 192.0.2.128

inet.0: 1110 destinations, 1869 routes (1110 active, 0 holddown, 0 hidden)
  Direct:  3 routes,  3 active
   Local:  3 routes,  3 active
OSPF:  2 routes,  1 active
 BGP:   1861 routes,   1103 active

upstream.inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
 BGP:  1 routes,  1 active

Adding a static route to peer.inet.0 doesn't help (I added a discard
route). Switching the default to the peer doesn't change anything (term
3 also matches anything). Tested on vMX 14.1R1. Maybe a bug in
if-route-exists?
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Enable EVPN on existing mpls l3vpn network

[Olivier Benghozi]

> 19 feb 2016 at 00:02, Chuck Anderson  wrote :
> 
>> recommended 13.3R8 code.  I read NSR is not supported for EVPN.  If i
>> enable family evpn signalling will NSR be supported for existing l3vpn
>> functionality?
> 
> Yes.

No.
But there's a workaround:

> Yes, the BGP session will reset.  Alternatively, you can set up a
> separate BGP session for just EVPN so that you don't affect your L3VPN
> BGP session.

The workaround to use in order to keep NSR for other address families, and it 
also avoids iBGP flap. Additional loopback is needed.

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

Re: [j-nsp] Enable EVPN on existing mpls l3vpn network

[Chuck Anderson]

On Thu, Feb 18, 2016 at 10:44:16AM -0800, tim tiriche wrote:
> I have an existing L3VPN network with NSR.
> 
> If i want to enable EVPN, is it just a matter of enabling family evpn
> signalling on the bgp neighbors?

Yes, but you probably want at least Junos 14.1 for EVPN.

> Will doing so, cause a session reset or affect existing production services
> or something else i need to be aware of?  this will be on the junos

Yes, the BGP session will reset.  Alternatively, you can set up a
separate BGP session for just EVPN so that you don't affect your L3VPN
BGP session.

> recommended 13.3R8 code.  I read NSR is not supported for EVPN.  If i
> enable family evpn signalling will NSR be supported for existing l3vpn
> functionality?

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

Re: [j-nsp] Optimizing the FIB on MX

[Raphael Mazelier]

Very interresting topic.

Some questions about your setup :

In 2) you set advertise-external, is it working the same by using 
multipath ?


In 3) you set 'unicast protection'. It is the same thing as PIC 'protect 
core' knob ?


If I understand correctly, before 15.1 PIC is only available on l3vpn, 
so my question is :


Is it advisable to run the dmz/internet table in a vrf/routing instance 
on juniper ? and what are the pros/cons of doing that ?


pros : PIC, more flexibily ?
cons : more complex setup, performance issue (I've heard some storie 
about that) ?


Best,

--
Raphael Mazelier

Le 18/02/2016 11:50, Adam Vitkovsky a écrit :



The setup is really easy


1) carve up the FIB so that it allows for multiple next-hops (in our case 
pointer to a backup path)
set routing-options forwarding-table export lb
set policy-options policy-statement lb then load-balance per-packet


2)advertise the best external routes
set protocols bgp group MX140-IBGP advertise-external <<
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Alexander Marhold]

Hi folks

To make the discussion clearer and comming back to the Juniper MX 104 
implementation

Here is a picture of 2 PEs on P  and 2 peers (ISP1 and IX1)
let´s assume we want to prefer routes from IX1 over ISP1
MX1 is EBGP (lpref 100) to  ISP1 and IBGP to MX2 and MX3
MX2 is EBGP (lpref 110) to IX1 and IBGP to MX1 and MX3

  ISP1   IX1
| locpref ^ locpref 
|   100  |   110
   MX1->-MX2
|   |
|   |
+--MX3--->--+


In my opinion if you need also  the MX3 then  for this MX3 you need "PIC-CORE" 
to quickly switch between both paths

On MX1 you need "best-external" to advertise the external routes whereas the 
best is the internal route pointing to MX2

On MX1 and MX2 you need "PIC-EDGE" to quickly switch when IX1 goes down

Do we all agree on that picture and the named mechanisms ( put in "") ?


So now what versions of Junos is needed and what additional "unnecessary" 
methods like MPLS or LDP is now needed ?

regards

alexander

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

[j-nsp] Enable EVPN on existing mpls l3vpn network

[tim tiriche]

Hello,

I have an existing L3VPN network with NSR.

If i want to enable EVPN, is it just a matter of enabling family evpn
signalling on the bgp neighbors?

Will doing so, cause a session reset or affect existing production services
or something else i need to be aware of?  this will be on the junos
recommended 13.3R8 code.  I read NSR is not supported for EVPN.  If i
enable family evpn signalling will NSR be supported for existing l3vpn
functionality?

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

Re: [j-nsp] Optimizing the FIB on MX

[Sebastian Becker]

Hi Ytti,

I meant 9001 to 9010 and mx104 to mx240.
cpu to cpu works, but than there is the software you mentioned.

Back to Juniper. ;-)

-- 
Sebastian Becker
s...@lab.dtag.de

> Am 18.02.2016 um 16:39 schrieb Saku Ytti :
> 
> 
> On 18 February 2016 at 17:29, Sebastian Becker  wrote:
> 
> Hey Sebastian,
> 
>> As AS9001 and AS9006/9010 have a different cpu architecture as MX104 and 
>> MX240/480/960 the comparison is not easy just by the type of the cpu itself.
> 
> ASR9001 and MX104 use same Freescale QorIQ family, so it's very direct
> comparison. Specsheets are publically available.
> Larger MX and ASR9k use Intel X86/AMD64, so easy to compare.
> 
> But of course the software is very different, and this MX104 issue
> thread is about, does not exist in IOS-XR, regardless how slow CPU it
> is rocking.
> 
> -- 
>  ++ytti

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

Re: [j-nsp] Optimizing the FIB on MX

[Adam Vitkovsky]

> sth...@nethelp.no [mailto:sth...@nethelp.no]
> Sent: Thursday, February 18, 2016 11:13 AM
>
> Just commenting on a couple things:
>
> > If the MX140-A from our previous example loses its Transit link it
> > will (via BGP-PIC) immediately reroute traffic to MX140-B However by
> default MX140-B has a best path via MX140-A -so until it receives withdrawn
> from MX140-A it'll loop traffic back to MX140-A.
> > That's why you want MX140-B to prefer it's local exit.
> >
> > *not sure what was Juniper and ALU thinking when they came up with the
> same protocol preference for eBGP and iBGP routes, there's a ton of reasons
> why you always want to prefer closest AS-EXIT.
>
> Probably the same as Cisco, when Cisco on multiple occasions have
> promoted using the same administrative distance (200) for both EBGP and
> IBGP as "best practice".
>
Well the bottom line is the sanity won.


> > Caveats:
> > "vrf-table-label" must be enabled at the routing-instance on the
> > MX140s - just another stupidity in this script kiddie OS of Junos
>
> You are of course free to call JunOS whatever you want. Calling JunOS a
> "script kiddie OS" may not the best way to be taken seriously.
>
> In any case, vrf-table-label is *much* older than PIC (around 10 years, if I
> remember correctly).
>
And that makes vrf-table-label a prerequisite for PIC?
My point is that if a packet is received with a VRF label the label points to 
an indirect next hop pointer
And the pointer points to a forwarding next-hop i.e.  IP edge-interface and 
adjacent L2 rewrite
and as a backup could point to an MPLS core-interface and adjacent label stack 
(NH label to backup PE(if any) and VRF label that backup PE advertised)
-basically an ASBR option B label swap operation
Why would I need to run an unnecessary IP lookup in the VRF table to derive 
info about the backup path?

adam








Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

Re: [j-nsp] Optimizing the FIB on MX

[Saku Ytti]

On 18 February 2016 at 17:29, Sebastian Becker  wrote:

Hey Sebastian,

> As AS9001 and AS9006/9010 have a different cpu architecture as MX104 and 
> MX240/480/960 the comparison is not easy just by the type of the cpu itself.

ASR9001 and MX104 use same Freescale QorIQ family, so it's very direct
comparison. Specsheets are publically available.
Larger MX and ASR9k use Intel X86/AMD64, so easy to compare.

But of course the software is very different, and this MX104 issue
thread is about, does not exist in IOS-XR, regardless how slow CPU it
is rocking.

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

Re: [j-nsp] Optimizing the FIB on MX

[Sebastian Becker]

Hi Ytti / Colton,

ASR9001-RP
cisco ASR9K Series (P4040) processor with 8388608K bytes of memory.
P4040 processor at 1500MHz, Revision 3.0

This box ist only available as SE (service enhanced) version.

A9K-RSP440-SE
cisco ASR9K Series (Intel 686 F6M14S4) processor with 12582912K bytes of memory.
Intel 686 F6M14S4 processor at 2135MHz, Revision 2.174

There is a TR (transport) version with half the memory:
http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/data_sheet_c78-674143.html

A9K-RSP880-SE
cisco ASR9K Series (Intel 686 F6M14S4) processor with 33554432K bytes of memory.
Intel 686 F6M14S4 processor at 1904MHz, Revision 2.174

There is a TR (transport) version with half the memory:
http://www.cisco.com/c/en/us/products/collateral/routers/asr-9000-series-aggregation-services-routers/datasheet-c78-733763.html

As AS9001 and AS9006/9010 have a different cpu architecture as MX104 and 
MX240/480/960 the comparison is not easy just by the type of the cpu itself. 

-- 
Sebastian Becker
s...@lab.dtag.de

> Am 18.02.2016 um 16:06 schrieb Saku Ytti :
> 
> 
> On 18 February 2016 at 16:21, Colton Conor  wrote:
> 
> Hey Colton,
> 
>> What processor is in the Cisco 9001, and how does it compare to a MX104 in
>> terms of speed and BGP Performance?
> 
> ASR9001 is P4040 on RP, lower single core performance than MX104
> P5021. But the problem this thread addresses is not a problem IOS-XR
> has.
> 
>> What about a Cisco 9010 ASR9K Route Switch Processor with 440G/slot Fabric
>> and 6GB?
> 
> RSP440 is 4 core Intel, at about 2GHz. I'm actually sure which
> specific Intel CPU.
> 
> -- 
>  ++ytti
> ___
> 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] Optimizing the FIB on MX

[Saku Ytti]

On 18 February 2016 at 16:21, Colton Conor  wrote:

Hey Colton,

> What processor is in the Cisco 9001, and how does it compare to a MX104 in
> terms of speed and BGP Performance?

ASR9001 is P4040 on RP, lower single core performance than MX104
P5021. But the problem this thread addresses is not a problem IOS-XR
has.

> What about a Cisco 9010 ASR9K Route Switch Processor with 440G/slot Fabric
> and 6GB?

RSP440 is 4 core Intel, at about 2GHz. I'm actually sure which
specific Intel CPU.

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

Re: [j-nsp] Optimizing the FIB on MX

[sthaug]

> >http://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/use-case-for-bgp-pic-for-inet-inet6-lu.html
> 
> >>From 
> http://www.juniper.net/techpubs/en_US/junos15.1/topics/task/configuration/bgp-configuring-bgp-pic-for-inet.html
> 
> "Note: The BGP PIC edge feature is supported only on routers with
> MPC interfaces."
> 
> AIUI, this excludes MX80/MX104 - arguably where one would need it
> most...

MX80/MX104 is a "fixed config" MPC.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Sascha Luck [ml]]

On Wed, Feb 17, 2016 at 03:18:59PM -0500, Chuck Anderson wrote:

Can you use Junos 15.1?  Try this:

http://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/use-case-for-bgp-pic-for-inet-inet6-lu.html


From 

http://www.juniper.net/techpubs/en_US/junos15.1/topics/task/configuration/bgp-configuring-bgp-pic-for-inet.html

"Note: The BGP PIC edge feature is supported only on routers with
MPC interfaces."

AIUI, this excludes MX80/MX104 - arguably where one would need it
most...

cheers,
s.

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

Re: [j-nsp] Optimizing the FIB on MX

[Colton Conor]

Saku,

You seems to know a bit about processors to say the least.

What processor is in the Cisco 9001, and how does it compare to a MX104 in
terms of speed and BGP Performance?

What about a Cisco 9010 ASR9K Route Switch Processor with 440G/slot Fabric
and 6GB?

On Thu, Feb 18, 2016 at 8:12 AM, Saku Ytti  wrote:

> On 18 February 2016 at 15:31, Colton Conor  wrote:
> > So is the MX-104 processor really that underpowered? I have heard reports
> > that is was too underpowered for its pricepoint, and now I am starting to
> > believe it. Vincent what are your thoughts?
>
> Define underpowered?
>
> MX80 has 8572, also sported by platforms such as sup7, sup2t, nexus7k,
> me3600x, sfm3-12@alu
> RSP720, EX8200 RE have even slower spec cpu 8548
>
> MX104 has faster cpu than any of these, P5021. Yet RSP720 runs circles
> around MX104 in terms of BGP performance.
>
> I'd say it is underpowered for JunOS (All PPC's are, but is that HW or
> SW issue, that's debatable), but it really can't be considered
> particularly slow cpu in this market generally, especially during its
> launch year.
>
> --
>   ++ytti
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] Getting unusual log in juniper MX480 router / fpc0 Next-hop resolution requests from interface throttled

[Md. Jahangir Hossain via juniper-nsp]

Dear all ,
I'm getting unusual log in juniper MX480 router  like ,
 /kernel: agg_pfe_get_fwd_options: lt-0/0/0: ifd is NULL or ifl is not aggregate
 /kernel: agg_pfe_fwd_options_proc: AE forwarding options not found and not 
created


RPD_KRT_Q_RETRIES: Route Update: No buffer space available
RPD_KRT_Q_RETRIES: kqp 0x330793b0: op change queue low-change table inet.0 
attempts 10 91.x.x.0/24 -> {103.x.x.61}=>{103.21.x.x} 
RPD_KRT_Q_RETRIES: Route Update: No buffer space available

/kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, 
rtsm_id 5:-1, msg type 2
/kernel: rt_pfe_veto: Possible slowest client is xdpc0. States processed - 
809041490. States to be processed - 832671

/kernel: KERN_ARP_ADDR_CHANGE: arp info overwritten for 59.x.x.5 from 
a0:42:3f:x:x:b5 to a0:42:3f:x:x:b4
 fpc0 Next-hop resolution requests from interface 466 throttled
 fpc0 Next-hop resolution requests from interface 547 throttled
 fpc0 Next-hop resolution requests from interface 411 throttled

My Current MX480 OS version ,
Model: mx480
Junos: 14.1R4.10
JUNOS Base OS boot [14.1R4.10]
JUNOS Base OS Software Suite [14.1R4.10]
JUNOS Packet Forwarding Engine Support (M/T/EX Common) [14.1R4.10]
JUNOS Packet Forwarding Engine Support (MX Common) [14.1R4.10]
JUNOS platform Software Suite [14.1R4.10]
JUNOS Runtime Software Suite [14.1R4.10]
JUNOS Online Documentation [14.1R4.10]
JUNOS Services AACL Container package [14.1R4.10]
JUNOS Services Application Level Gateways [14.1R4.10]
JUNOS AppId Services [14.1R4.10]
JUNOS Border Gateway Function package [14.1R4.10]
JUNOS Services Captive Portal and Content Delivery Container package [14.1R4.10]
JUNOS Services HTTP Content Management package [14.1R4.10]
JUNOS IDP Services [14.1R4.10]
JUNOS Services Jflow Container package [14.1R4.10]
JUNOS Services LL-PDF Container package [14.1R4.10]
JUNOS Services MobileNext Software package [14.1R4.10]
JUNOS Services Mobile Subscriber Service Container package [14.1R4.10]
JUNOS Services NAT [14.1R4.10]
JUNOS Services PTSP Container package [14.1R4.10]
JUNOS Services RPM [14.1R4.10]
JUNOS Services Stateful Firewall [14.1R4.10]
JUNOS Voice Services Container package [14.1R4.10]
JUNOS Services Crypto [14.1R4.10]
JUNOS Services SSL [14.1R4.10]
JUNOS Services IPSec [14.1R4.10]
JUNOS py-base-i386 [14.1R4.10]
JUNOS 64-bit Kernel Software Suite [14.1R4.10]
JUNOS Crypto Software Suite [14.1R4.10]
JUNOS 64-bit Runtime Software Suite [14.1R4.10]
JUNOS Routing Software Suite [14.1R4.10]

It would be very much helpful if anyone please share their experience and 
suggestion for resolve this .


Regards / Jahangir 

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

Re: [j-nsp] Optimizing the FIB on MX

[Saku Ytti]

On 18 February 2016 at 15:31, Colton Conor  wrote:
> So is the MX-104 processor really that underpowered? I have heard reports
> that is was too underpowered for its pricepoint, and now I am starting to
> believe it. Vincent what are your thoughts?

Define underpowered?

MX80 has 8572, also sported by platforms such as sup7, sup2t, nexus7k,
me3600x, sfm3-12@alu
RSP720, EX8200 RE have even slower spec cpu 8548

MX104 has faster cpu than any of these, P5021. Yet RSP720 runs circles
around MX104 in terms of BGP performance.

I'd say it is underpowered for JunOS (All PPC's are, but is that HW or
SW issue, that's debatable), but it really can't be considered
particularly slow cpu in this market generally, especially during its
launch year.

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

Re: [j-nsp] Optimizing the FIB on MX

[Dave Bell]

I've not used the MX104, but the MX80 is incredibly slow to commit
changes, and from discussion on this mailing list slow to converge
also. As has been mentioned though, this can be got around by using
things like BGP PIC, and LFA to maintain a valid forwarding path while
the control plane sorts itself out though.

What I would be interested to know though is do these technologies use
additional FIB slots? IE by enabling BGP PIC, are you effectively
cutting your FIB capacity in half, from 1 million routes to 0.5
million?

Regards,
Dave

On 18 February 2016 at 13:31, Colton Conor  wrote:
> So is the MX-104 processor really that underpowered? I have heard reports
> that is was too underpowered for its pricepoint, and now I am starting to
> believe it. Vincent what are your thoughts?
>
> On Wed, Feb 17, 2016 at 5:14 PM, Vincent Bernat  wrote:
>
>>  ❦ 17 février 2016 22:56 GMT, Adam Vitkovsky > > :
>>
>> >> Being a bit unsatisfied with a pair of MX104 turning themselves as a
>> blackhole
>> >> during BGP convergence, I am trying to reduce the size of the FIB.
>> >>
>> > You mentioned earlier that this is a new installation so why not use
>> > routing instance for Internet which allows you to use PIC with your
>> > current version of code and save you all this trouble duck-taping the
>> > solution together.
>>
>> You are right. I didn't understand your answer the first time as I
>> thought that PIC was for "programmable integrated circuit", so I thought
>> this was a plan for Juniper to fix the problem with some dedicated piece
>> of hardware.
>> --
>> Truth is the most valuable thing we have -- so let us economize it.
>> -- Mark Twain
>> ___
>> 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] Optimizing the FIB on MX

[Colton Conor]

So is the MX-104 processor really that underpowered? I have heard reports
that is was too underpowered for its pricepoint, and now I am starting to
believe it. Vincent what are your thoughts?

On Wed, Feb 17, 2016 at 5:14 PM, Vincent Bernat  wrote:

>  ❦ 17 février 2016 22:56 GMT, Adam Vitkovsky  > :
>
> >> Being a bit unsatisfied with a pair of MX104 turning themselves as a
> blackhole
> >> during BGP convergence, I am trying to reduce the size of the FIB.
> >>
> > You mentioned earlier that this is a new installation so why not use
> > routing instance for Internet which allows you to use PIC with your
> > current version of code and save you all this trouble duck-taping the
> > solution together.
>
> You are right. I didn't understand your answer the first time as I
> thought that PIC was for "programmable integrated circuit", so I thought
> this was a plan for Juniper to fix the problem with some dedicated piece
> of hardware.
> --
> Truth is the most valuable thing we have -- so let us economize it.
> -- Mark Twain
> ___
> 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] Optimizing the FIB on MX

[sthaug]

Just commenting on a couple things:

> If the MX140-A from our previous example loses its Transit link it will (via 
> BGP-PIC) immediately reroute traffic to MX140-B
> However by default MX140-B has a best path via MX140-A -so until it receives 
> withdrawn from MX140-A it'll loop traffic back to MX140-A.
> That's why you want MX140-B to prefer it's local exit.
> 
> *not sure what was Juniper and ALU thinking when they came up with the same 
> protocol preference for eBGP and iBGP routes, there's a ton of reasons why 
> you always want to prefer closest AS-EXIT.

Probably the same as Cisco, when Cisco on multiple occasions have
promoted using the same administrative distance (200) for both EBGP
and IBGP as "best practice".

> Caveats:
> "vrf-table-label" must be enabled at the routing-instance on the MX140s - 
> just another stupidity in this script kiddie OS of Junos

You are of course free to call JunOS whatever you want. Calling JunOS a
"script kiddie OS" may not the best way to be taken seriously.

In any case, vrf-table-label is *much* older than PIC (around 10 years,
if I remember correctly).

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] Optimizing the FIB on MX

[Adam Vitkovsky]

> Vincent Bernat
> Sent: Wednesday, February 17, 2016 11:14 PM
>
>  17 février 2016 22:56 GMT, Adam Vitkovsky
>  :
>
> >> Being a bit unsatisfied with a pair of MX104 turning themselves as a
> >> blackhole during BGP convergence, I am trying to reduce the size of the
> FIB.
> >>
> > You mentioned earlier that this is a new installation so why not use
> > routing instance for Internet which allows you to use PIC with your
> > current version of code and save you all this trouble duck-taping the
> > solution together.
>
> You are right. I didn't understand your answer the first time as I thought 
> that
> PIC was for "programmable integrated circuit", so I thought this was a plan
> for Juniper to fix the problem with some dedicated piece of hardware.
> --
Sorry about that, I'll try to be more explicit in my future posts.

The setup is really easy


1) carve up the FIB so that it allows for multiple next-hops (in our case 
pointer to a backup path)
set routing-options forwarding-table export lb
set policy-options policy-statement lb then load-balance per-packet


2)advertise the best external routes
set protocols bgp group MX140-IBGP advertise-external <

Re: [j-nsp] Optimizing the FIB on MX

[Adam Vitkovsky]

> Alexander Marhold
> Sent: Thursday, February 18, 2016 9:31 AM
>
> Hi Chuck !
>
> Followed with interest the problem and especially your solution and I have
> looked into the docu BUT:
>
> DOCU says:
> " Before you begin:
>
> Configure the device interfaces.
> Configure OSPF or any other IGP protocol.
> Configure MPLS and LDP. <-- REALLY
> 
> Configure BGP.
> "
>
> Why do you need to enable MPLS and LDP for PIC ?
>
Well because Junos implementation of PIC sucks big times :)

> IMHO this is a documentation error , or do I miss something ?
>
> Regarding you suggestion of using it in a routing instance with version
> <15.1 I am not sure if that works as documentation says that it only works for
> vpnv4-BGP routes
>
> DOCU says
> "Before you begin:
>
> Configure LDP.
> Configure an IGP, either OSPF or IS-IS.
> Configure a Layer 3 VPN.
> Configure multiprotocol BGP for either an IPv4 VPN or an IPv6 VPN.
> < nthis seems to be a restriction regarding your proposed
> solution "
>
And I was hoping that Junos would finally support BGP PIC for v4 and V6 (not a 
VRF-lite).


adam


Adam Vitkovsky
IP Engineer

T:  0333 006 5936
E:  adam.vitkov...@gamma.co.uk
W:  www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of 
this email are confidential to the ordinary user of the email address to which 
it was addressed. This email is not intended to create any legal relationship. 
No one else may place any reliance upon it, or copy or forward all or any of it 
in any form (unless otherwise notified). If you receive this email in error, 
please accept our apologies, we would be obliged if you would telephone our 
postmaster on +44 (0) 808 178 9652 or email postmas...@gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with 
limited liability, with registered number 04340834, and whose registered office 
is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at 
Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.


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

Re: [j-nsp] Optimizing the FIB on MX

[Alexander Marhold]

Hi Chuck !

Followed with interest the problem and especially your solution and I have
looked into the docu BUT:

DOCU says:
" Before you begin:

Configure the device interfaces.
Configure OSPF or any other IGP protocol.
Configure MPLS and LDP. <-- REALLY

Configure BGP.
"

Why do you need to enable MPLS and LDP for PIC ?

IMHO this is a documentation error , or do I miss something ?

Regarding you suggestion of using it in a routing instance with version
<15.1 I am not sure if that works as documentation says that it only works
for vpnv4-BGP routes

DOCU says
"Before you begin:

Configure LDP.
Configure an IGP, either OSPF or IS-IS.
Configure a Layer 3 VPN.
Configure multiprotocol BGP for either an IPv4 VPN or an IPv6 VPN.
< nthis seems to be a restriction regarding your proposed
solution
"

Any more info on that available ?

Regards

alexander

-Ursprüngliche Nachricht-
Von: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] Im Auftrag von
Chuck Anderson
Gesendet: Mittwoch, 17. Februar 2016 21:19
An: juniper-nsp@puck.nether.net
Betreff: Re: [j-nsp] Optimizing the FIB on MX

On Wed, Feb 17, 2016 at 08:51:23PM +0100, Vincent Bernat wrote:
> Being a bit unsatisfied with a pair of MX104 turning themselves as a 
> blackhole during BGP convergence, I am trying to reduce the size of 
> the FIB.
> 
> I am in a simple situation: one upstream on each router, an iBGP 
> session between the two routers. I am also receiving a default route 
> along the full feed.

Can you use Junos 15.1?  Try this:

http://www.juniper.net/techpubs/en_US/junos15.1/topics/concept/use-case-for-
bgp-pic-for-inet-inet6-lu.html
___
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