Re: [j-nsp] set MED only on empty

--- Begin Message --- Hello, Last time I tested it, "from metric 0" works only if MED is present and equals 0. Back then (around JUNOS 17) I developed a policy to detect missing MED which exploits metric2 rollover (basically, subtracting 1 from missing MED results in MED==4294967295) Example

Re: [j-nsp] DDOS_PROTOCOL_VIOLATION on DHCP - and it's not configured?

--- Begin Message --- Hello, 2 possibilities: 1/ Your MX240 loopback filter does not block udp/67 2/ You have DHCP traceoptions configured - it starts jdhcpd process even if there is no other DHCP config: set system processes dhcp-service traceoptions blah-blah Thanks Alex -- Original

Re: [j-nsp] Slow RE path 20 x faster then PFE path

NAT config possible. Hopefully that's enough to get You started , and without Your config I have no other ideas to share, perhaps others can chime in. Thanks Alex -- Original Message -- From: "Robert Raszuk" To: "Alexander Arseniev" Cc: "Juniper List" Sen

Re: [j-nsp] Slow RE path 20 x faster then PFE path

--- Begin Message --- Hello, Another interesting observation is that show command indicated services inline input traffic over 33 Mpps zero output while total coming to the box was at that time 1 Mpps Do You have inline NAT configured on this box? Is it possible to share the config

Re: [j-nsp] MX960 vs MX10K

actually not the PFE as "forwarding chip" but "PFE" as short way of saying "linecard CPU that runs PPMD" which processes BFD packets from all linecards. Thanks Alex -- Original Message -- From: "Saku Ytti" To: "Alexander Arseniev" Cc: "Ju

Re: [j-nsp] MX960 vs MX10K

--- Begin Message --- -- Original Message -- From: "Saku Ytti" IPSEC isn't stateful in any meaningful way If you can implement MACSec it shouldn't take much more transistors to do IPSEC. I always thought maintaining anti-replay counters/IKEv exchange sequences etc is a stateful

Re: [j-nsp] static arp with unnumbered-address

ed-address. Regards, Baldur Den tor. 13. feb. 2020 kl. 08.30 skrev Alexander Arseniev < arsen...@btinternet.com>: Hello, Firstly, Your example configuration with static /24 routes and qualified-NH to IFL does not commit - even after fixing the host portion - with error message &quo

Re: [j-nsp] static arp with unnumbered-address

--- Begin Message --- Hello, Firstly, Your example configuration with static /24 routes and qualified-NH to IFL does not commit - even after fixing the host portion - with error message "subnet routes are not allowed with MAC NH". Secondly, You could have second static 198.51.100.0/24 resolve

Re: [j-nsp] Help with BGP as-path regex

--- Begin Message --- Hello, Does this help? https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/m-mx-t-series-toc.html

Re: [j-nsp] EVPN - BGP attribute propagation on MXes

Hello, On 01/07/2019 15:38, Guillermo Fernando Cotone wrote: Our use-case is to connect BGP islands through an EVPN backbone, and we expect BGP attributes, such as communities, to be propagated over the backbone. Pretty much standard IP-VPN behavior. Also referenced here:

Re: [j-nsp] Avoid transit LSPs

Hello, On 25/01/2019 16:50, Luis Balbinot wrote: Please let me know if you find some other approach. The overload bit helps but in the absence of another path the RSVP FRR mechanism will setup a bypass LSP through a node with the overload bit set. And link coloring does not help, at least in

Re: [j-nsp] Junos Arp Expiration Timer Behavior & Active Flows

Hello, Few more ARP tidbits for You: 1/ JUNOS learns ARP not only from responses but from requests as well - this is according to RFC 826 "Packet reception" chapter (ARP opcode is examined AFTER the xlation table is updated).  Therefore, You may see that ARP entry for the remote node is

Re: [j-nsp] rate limiting per-user prefix lists

Hello, Well, the prefix-action policers would likely relieve congestion on Your backhaul MW links but the 100Mbps "last mile" will still be congested, with a mix of good and bad packets. And I would say more bad than good because good traffic (mainly HTTPS nowadays) will do TCP backoff at

Re: [j-nsp] DDoS Protection on MX204

Hello, Trio DDOS employs a hierarchy/chain of policers. Assuming flow detection is at default (and default==not configured), the first policer in a chain would be the FPC aggregate one, and it is 20Kpps by default. Your 188K offered BGP traffic is therefore rate-limited OUT OF FPC to

Re: [j-nsp] MX80 Input Scheduling/Shaping

Hello, Egress scheduling/shaping on MIC ports - correct, that's why I said "roughly" equal. Ingress scheduling/shaping requires Q or EQ MPC which is not supported on MX80. Thanks Alex -- Original Message -- From: sth...@nethelp.no To: arsen...@btinternet.com;

Re: [j-nsp] MX80 Input Scheduling/Shaping

Hello, Ingress scheduling is supported only on Q and EQ MPCs - Juniper MX series book, 2nd ed, page 598. MX80 COS capabilities are roughly equal to MPC1, without Q. HTH Thx Alex On 05/10/2018 11:21, Eric Van Tol wrote: Hi all, I've looked at the docs and can't find this, so maybe

Re: [j-nsp] PE-CE issue with OSPF routes not getting into routing table

Hello, LSA  172.16.64.0   has DN-bit set : "Opt 0xa2" xlates to 1010 0010 https://tools.ietf.org/html/rfc4576#page-4 As to whether You want DN bit cleared (which is possible) to fix Your problem - please carefully review Your design and make an informed decision afterwards, not before. HTH

Re: [j-nsp] L3VPN/RR/PE on Same router

Hello, Yes there is https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/advertise-from-main-vpn-table-edit-protocols-bgp.html Also, either don't configure "family route-target" on this combined PE/RR at all, or configure "family route-target

Re: [j-nsp] VRF export/import of eBGP learned route

Hello, Does "no-prepend-global-as" help? https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-local-as-introduction.html HTH Thx Alex On 29/06/2018 04:58, Aaron Gould wrote: Use with caution in live environment as I'm going off of some testing I was recently doing in my

Re: [j-nsp] SRX 550 BGP Flapping

Hello, BGP KA size is 19 bytes without authentication, circa 39 with. Plus IP overhead, plus Ethernet OVH - still below 100 B. SRX reth default MTU is 1500B. Are You sure that checking & setting MTU helps to fix BGP holdtime expiry? I would bet that either SRX550 reth interface is

Re: [j-nsp] filter based forwarding of self-generated traffic

Hello, FBF for self-originated traffic is not supported. The technical explanation is that all filters bar one are instantiated in the forwarding plane but self-generated traffic is routed & L2-encapsulated by RE itself. The only filter that is instantiated in the RE is fxp0 filter. Your

Re: [j-nsp] can i get junos file from device

Hello, Have a look into /var/sw/pkg: file list detail /var/sw/pkg HTH Thx Alex On 28/06/2017 18:21, Aaron Gould wrote: Thanks Thomasz, well, sort of, I’m wondering if there is a way to upgrade Junos from a box that is running the desired version ? So I was wondering how the following

Re: [j-nsp] inject unresolvable static route via bgp

Hello, Is 2.2.2.2 resolvable on a core router then? Via in interface/connected subnet perhaps? If yes then announce all conected subnets from core router(s) via iBGP to Your VMX. Then configure Your statics on VMX with "resolve" knob, and announce them via iBGP back to core router(s). Your

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

quite a hassle for ntp+internet, or maybe I'm missing something. +Dragan On Fri, May 5, 2017 at 11:02 AM, Alexander Arseniev <arsen...@btinternet.com <mailto:arsen...@btinternet.com>> wrote: Hello, to nitpick ^ 2, if You DON'T want Your conforming NTP traffic to be

Re: [j-nsp] Using IPv4/IPv6 combined filter/policy with layer4 filtering

Hello, to nitpick ^ 2, if You DON'T want Your conforming NTP traffic to be re-policed by AGG policer, You have to mark it somehow, i.e. with a forwarding-class. term ntp from ntp then policer 200m then next-term then forwarding-class MARKER term agg from forwarding-class-except

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

On 20/04/2017 09:43, adamv0...@netconsultings.com wrote: (b) even when BFD is down, the BGP session may be still up whereas You want the BFD to follow BGP Now how can that happen other than bug? To answer Your above question - when BFD goes down, BGP goes initially down too, but then it

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

Hi Dragan, As for default route, if its installed in FT, I don't see why the router wouldn't use this entry in the absence of more specific (bearing all other issues with such setup). Yes, the 0/0 will be used BUT when there are 100,000s of more specifics in the FIB BEING REMOVED (simplest

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

eally have two ABSR so I don't think PIC Core would accomplish anything? -Michael -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Alexander Arseniev Sent: Wednesday, April 19, 2017 8:12 AM To: adamv0...@netconsultings.com; juniper-nsp@puck.

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

com ::carrier-class solutions for the telecommunications industry:: *From:*Alexander Arseniev [mailto:arsen...@btinternet.com] *Sent:* Wednesday, April 19, 2017 1:28 PM *To:* adamv0...@netconsultings.com; 'Michael Hare'; juniper-nsp@puck.nether.net *Subject:* Re: [j-nsp] improving global

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

ugh, would rather recommend upgrading to 15.1 to get PIC capability for inet0. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: *From:*Alexander Arseniev [mailto:arsen...@btinternet.com] *Sent:* Wednesday, April 19, 2017 1:09 PM *To:* ada

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

ne uses ECMP, (r)LFA, RSVP FRR, etc. HTH Thx Alex On 19/04/2017 12:51, adamv0...@netconsultings.com wrote: Of Alexander Arseniev Sent: Wednesday, April 19, 2017 11:51 AM - then 203.0.113.0 will appear as "indirect" and You can have the usual INH benefits. Example from my lab: sho

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

enablement in this case. HTH Thx Alex On 19/04/2017 11:51, Alexander Arseniev wrote: Hello, indirect-next-hop being default on MPC but my understanding is this will not work for directly connected eBGP peers Not by default. You can make a directly-connected nexthop appear as "ind

Re: [j-nsp] improving global unicast convergence (with or without BGP-PIC)

Hello, indirect-next-hop being default on MPC but my understanding is this will not work for directly connected eBGP peers Not by default. You can make a directly-connected nexthop appear as "indirect" by using unnumbered interface with static /32 route pointing to the eBGP peer

Re: [j-nsp] Negative ARP caching, on an MX router (again)

to the router, and the router will mark the subinterface down. The associated static /32 will sink/disappear. JUNOS automation would help with repetitive subinterface configs. HTH Thanks Alex On 05/04/2017 14:27, Alexander Arseniev wrote: Hello, If You have control over Your L3 space

Re: [j-nsp] Negative ARP caching, on an MX router (again)

Hello, If You have control over Your L3 space assignments, have You tried point-to-point Ethernet interfaces with static /32 routes? Assuming 203.0.113.0/24 subnet, Your router IP is 203.0.113.1, and there are 2 hosts 203.0.113.2 + 203.0.113.3 directly connected to ge-0/0/0 and ge-0/0/1

Re: [j-nsp] conditional route import

to be looking at its attributes like IGP metric to a NH, then RR might have a different view than the PE that was supposed to introduce the route into a local AS. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: *From:*Alexander Arseniev [mailto:arsen...@

Re: [j-nsp] conditional route import

y:: *From:*Alexander Arseniev [mailto:arsen...@btinternet.com] *Sent:* Tuesday, March 14, 2017 5:57 PM *To:* adamv0...@netconsultings.com; juniper-nsp@puck.nether.net *Subject:* Re: [j-nsp] conditional route import Hello, If You pass this route to BGP RR and do modifications there before a

Re: [j-nsp] conditional route import

s industry:: *From:*Alexander Arseniev [mailto:arsen...@btinternet.com] *Sent:* Monday, March 13, 2017 12:28 PM *To:* adamv0...@netconsultings.com; juniper-nsp@puck.nether.net *Subject:* Re: [j-nsp] conditional route import Hello, You can do it easily in BGP Route Reflector export poli

Re: [j-nsp] conditional route import

Hello, You can do it easily in BGP Route Reflector export policy coupled with other features like ORR and NH rewriting. There could be complexities with PE config (obviously, the PE would prefer eBGP route direct from CE vs iBGP from RR) but they can be overcome with routing-instances.

Re: [j-nsp] Generating routes from inactive/hidden contributors

They will be - in .inet.0 virtual router, where the BGP session terminates. On 05/03/2017 14:53, Chuck Anderson wrote: Last time I checked the contributing routes have to be in the destination RIB for the aggregate/generate to go active. On Sun, Mar 05, 2017 at 11:26:18AM +, Alexander

Re: [j-nsp] BFD Session

interfaces diagnostics optics ge-2/1/0 Physical interface: ge-2/1/0 Optical diagnostics : N/A On 5 March 2017 at 13:23, Alexander Arseniev <arsen...@btinternet.com <mailto:arsen...@btinternet.com>> wrote: Hello, Check Your laser light levels : show interfaces diagno

Re: [j-nsp] Generating routes from inactive/hidden contributors

Hello, Have You tried putting all routes from that peer in a routing-instance? Then configure aggregate|generate in that instance and leak it into inet.0|whereever the other peers sit. You can leak the whole table from that peer as well, but that amounts to 2x route memory consumption by

Re: [j-nsp] BFD Session

Hello, Check Your laser light levels : show interfaces diagnostics optics ge-x/y/z HTH Thx Alex On 05/03/2017 10:51, Mohammad Khalil wrote: As well , I have checked the log messages , and I can see the below message: RPD_ISIS_ADJDOWN : ISIS lost L2 adjacency reason 3-way handshake BR,

Re: [j-nsp] L2 Channel Errors

Hello, By default, Cisco floods all VLANs to all trunk ports. SRX does not support VTP & VTP pruning so it cannot tell Cisco to stop sending useless frames to it. On 6500 port facing SRX, configure "cdp disable", "spanning-tree portfast trunk" & "switchport trunk allowed vlan BLAH1 BLAH2"

Re: [j-nsp] Block externals ip to firewall srx240

Hello, Last time I checked, the order of operations on branch SRX is: 1/ input interface filter 2/ self-traffic policy 3/ junos-host zone policy 4/ loopback filter Hence, the most CPU-effective way is to use interface filter to drop early. HTH Thx Alex On 10/01/2017 19:18, Karsten Thomann

Re: [j-nsp] Using multiple sources for flows on Logical Systems

.0.254.63636: UDP, length 445 17:16:15.281303 IP 1.1.1.1.50101 > 50.0.0.254.63636: UDP, length 105 17:16:15.286309 IP 1.1.1.1.50101 > 50.0.0.254.63636: UDP, length 105 17:16:15.288257 IP 1.1.1.1.50101 > 50.0.0.254.63636: UDP, length 105 *From: *Alexander Arseniev <arsen...@btinternet.com>

Re: [j-nsp] how to disconnect/kill tcp session from juniper router

Hello, Someone is brute-forcing Your router password, and that is very common nowadays. Good loopback filter would prevent this. In addition: 1/ You can only do "request system logout" for sessions that passed authentication+login+got TTY assigned. If You see "unsuccessful login" it means

Re: [j-nsp] Using multiple sources for flows on Logical Systems

Hello, Have You tried to duplicate Your LS IP on master system lo0.0, and explicitly set "source-address" for each LS-mapped Jflow instance to be one of these duplicated IPs? if You worry about leaking these IP to Your IGP, then JUNOS has tools to selectively disallow lo0.0 IP into IGP.

Re: [j-nsp] RR does not reflect the routes.

Hello, I guess You are concerned about this route: + 192.168.16.1/32 192.168.16.1 0 100 I + It is probably known to HK via IGP/static and You need "advertise-inactive"

Re: [j-nsp] Very basic question about MPLS and RSVP's place in the design

Hello, Some answers: A. bandwidth reservation is per outgoing interface that RSVP LSP takes and it is not truly global meaning that of course ingress LSR knows all the link bandwiths in given IGP domain but if there is "no bandwidth" signaled by upstream nodes, then ingress LSR router takes

Re: [j-nsp] IPV6 over MPLS

Hello, If You don't care whether IPv6 packets take RSVP or LDP LSP, then You could just enable LDPv6 everywhere (JUNOS 16.1 onwards) and save on rewriting NHs from IPv4-mapped IPv6 to proper IPv6. For VPNv6 You would still need NH rewriting as VPNv6 NH is still IPv4-mapped IPv6 even if

Re: [j-nsp] Monitoring Route Announcements

Hi, There are guys out there who already are monitoring You. https://www.bgpmon.net/ You can join them and get all their intel for free if You only announce 5 prefixes or less https://www.bgpmon.net/plans-and-pricing/ HTH Thx Alex On 29/08/2016 15:14, Theo Voss wrote: Hi folks, we’d

Re: [j-nsp] Limit on the number of BGP communities a route can be tagged with?

sure, you will never see the same community twice (unlike AS in AS-PATH). So your regex to match multiple occurrences of a community is not necessary. On Wednesday, August 24, 2016, Alexander Arseniev <arsen...@btinternet.com <mailto:arsen...@btinternet.com>> wrote: Hello,

Re: [j-nsp] Limit on the number of BGP communities a route can be tagged with?

ommunity additive - these are Cisco-like commands). Le 23 août 2016 à 14:03, Alexander Arseniev <arsen...@btinternet.com> a écrit : In BGP messages, a regular community is encoded in 7 bytes, and extended one in 11 bytes. Max BGP message size is 4096 bytes - this sets a limit for reg

Re: [j-nsp] Limit on the number of BGP communities a route can be tagged with?

Hello, In BGP messages, a regular community is encoded in 7 bytes, and extended one in 11 bytes. Max BGP message size is 4096 bytes - this sets a limit for regular communities number to about 4K/7=570, and for extended communities to about 4K/11=360, if You consider the minimal mandatory

Re: [j-nsp] SRX Deployment Questions

Hello, What is the JUNOS version? Are You using Services Offload/SOF? LAG with SOF is supported from JUNOS 12.1X47-D10. Thanks Alex On 23/08/2016 10:25, Jeffrey Nikoletich wrote: Thanks. I checked that and it all is clean. No matter what interface of the AE I disable, the results are the

Re: [j-nsp] SRX Deployment Questions

Hello there, Looks like You have a dirty optic/bent cable/incompletely plugged-in connector in that one. Check the light levels and PCS errors section in "show interfaces extensive xe-x/x/x" printout, it may get You some clues. HTH Thx Alex On 23/08/2016 09:43, Jeffrey Nikoletich wrote:

Re: [j-nsp] ldp transport address 0.0.0.0

Hello, Do You have "set routing-options router-id " line in Your config? Thanks Alex On 08/08/2016 12:58, Mohammad Salbad wrote: Hi experts I have mx and acx routers both running isis and rsvp and I have mpls lsp configured between their loopbacks. when trying to establish ldp and

Re: [j-nsp] BGP/MPLS Question MX Platform

Hello, On 03/08/2016 22:09, Dean B wrote: Thanks. I think the part I'm missing is associating the IP traffic to an LSP and how to prevent it from just going back to IGP routing when the LSP fails. There are several ways to do that. 1) use forwarding-table policy to associate BGP routes with a

Re: [j-nsp] BCP for filtering management access, system-wide

Hello, On 25/07/2016 23:34, Jason Lixfeld wrote: Hi Chris, et all who have suggested that lo0 is the correct place to put these filters, I’ve been through the Day One book previously, and I suspect Chip’s Safari link is much the same. Except here’s my problem after having gone through that

Re: [j-nsp] Basic NAT44 on MS-MPC implementation help

Hello, https://www.juniper.net/uk/en/training/jnbooks/day-one/networking-technologies-series/deploying-cgnat/ has all necessary info for MS-DPC CGNAT. To adapt CGNAT config for MS-MPC "MS" interfaces, all You need is to substitute SP interfaces for MS interfaces. Your service filters part

Re: [j-nsp] in-band management interface vs. re firewall concepts/bcp

Hello, On 07/07/2016 23:07, Clinton Work wrote: JunOS doesn't have an explicit control-plane interface Not exactly true. It does but You cannot attach filters directly to it. It is called fxp1/em1. and you attach your control-plane filter to lo0.0 instead. Depending on platform and

Re: [j-nsp] CGNat PBA - MX104 w/MS-MIC

gs set services service-set cgn-sset syslog host 172.22.14.54 source-address 10.101.12.243 -Original Message- From: Mark Tinka [mailto:mark.ti...@seacom.mu] Sent: Monday, April 25, 2016 9:10 PM To: Aaron <aar...@gvtc.com>; 'Nitzan Tzelniker' <nitzan.tzelni...@gmail.com>; dl

Re: [j-nsp] CGNat PBA - MX104 w/MS-MIC

Hello, These are taken from MX104 Routing Engine logs, correct? If yes then "2016-05-11 16:19:58" is added by syslogd on RE. And "2016-05-11 21:19:57" is WELF timestamp in syslog message from MS-MIC. MS-MIC always keeps UTC timezone and this cannot be changed. HTH Thx Alex On 11/05/2016 23:08,

Re: [j-nsp] CGNat PBA - MX104 w/MS-MIC

Hello, What is the JUNOS version? PBA on MS-MIC and MS-MPC is supported from 14.2R2 if memory serves but recommended is 14.1R5-S1 and newer. And DetNAT on MS-MIC (and MS-MPC) is a roadmap item. HTH Thx Alex On 23/04/2016 01:27, Aaron wrote: I'm trying to enable port block allocation (pba) for

Re: [j-nsp] cgnat on service module - interesting bgp advertisements

ns, 1915 routes (771 active, 0 holddown, 0 hidden) Prefix Nexthop MED LclprefAS path * 10.144.2.4/30 Self 100I * 1.2.3.128/25 Self 100 I [edit] *From:*Alexander Arseniev [mailto:arsen...@btinternet.com] *Sent

Re: [j-nsp] cgnat on service module - interesting bgp advertisements

Hello, MS-MIC (and MS-MPC NPUs as well) automatically cuts out network (in your case .128) and broadcast (in your case .255) IPs. The rest cannot be expressed as single prefix, hence a bunch of smaller prefixes is annonced instead. This was done as PR 1019354 fix

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

:59, Aaron wrote: Thanks Alex, does it work on vMX ? Aaron -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Alexander Arseniev Sent: Monday, April 18, 2016 11:26 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MPLS L2VPN Cisco

Re: [j-nsp] MPLS L2VPN Cisco and Juniper

Hello, If You are doing the below JUNOS config on Olive, L2circuit data plane does not work on Olive. And it never worked on Olive, to my knowledge. HTH Thx Alex On 18/04/2016 13:32, Mohammad Khalil wrote: I have configured the below set interfaces em0 mtu 1514 set interfaces em0 unit 0

Re: [j-nsp] cgnat routing architecture

Hello, Run BGP through MS-MIC and You'd have conditional scenarios covered plus the following: 1/ Service PIC is misconfigured (i.e. service-set does not exist) 2/ Service PIC has flow-control enabled because i.e. incoming PPS is above the rated value Thanks Alex On 11/04/2016 10:55, Faizal

Re: [j-nsp] EVPN and DPC line cards: Deciphering JUNOS docs?

Hello, This is logically correct. Since EVPN instance needs to be configured on PE router, then we have 2 interface categories for EVPN PE router: 1/ own CE-facing - referred to below as "CE device interfaces" 2/ another PE-facing - referred to below as "PE device interfaces". The (2) is also

Re: [j-nsp] nat - non-inline - service card ms-mic-16G in mx104

ay One doc that I’ve been reading since it’s based on the MS-DPC, the show service nat mapping detail doesn’t work either, but apparently the mx104 with ms-mic uses show services stateful-firewall flows is what I needed to use to see flows. Aaron *From:*Alexander Arseniev [mailto:arsen...@b

Re: [j-nsp] nat - non-inline - service card ms-mic-16G in mx104

Hello, MS-MIC service interfaces are called ms-*, not sp-*. Also, You don't need these lines with MS-MIC: set chassis fpc 1 pic 0 adaptive-services service-package layer-3 set interfaces sp-1/0/0 services-options cgn-pic And the recommended JUNOS version for MS-MIC CGNAT is 14.2R5 or newer.

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

Vincent Bernat wrote: ❦ 17 février 2016 21:07 GMT, Alexander Arseniev <arsen...@btinternet.com> : 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 appr

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

02/2016 21:50, Vincent Bernat wrote: ❦ 17 février 2016 21:07 GMT, Alexander Arseniev <arsen...@btinternet.com> : If the condition system would allow me to match a next-hop or an interface in addition to a route, I could do: 3. Reject any route with upstream as next-hop if th

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

Hello, On 17/02/2016 19:51, Vincent Bernat wrote: Hey! If the condition system would allow me to match a next-hop or an interface in addition to a route, I could do: 3. Reject any route with upstream as next-hop if there is a default route to upstream. 4. Reject any route with peer

Re: [j-nsp] Bandwidth aware using BGP on ISP transit

Hello, Please see below inline marked with [AA]. Thx Alex On 25/01/2016 07:08, Nathan Ward wrote: Hi, On 25/01/2016, at 19:48, Alexander Arseniev <arsen...@btinternet.com> wrote: On 24/01/2016 23:01, Nathan Ward wrote: This sort of works, except there’s a strong chance that the at

Re: [j-nsp] Bandwidth aware using BGP on ISP transit

Hello, I am working on it. This may be my next patent :-) Thx Alex On 25/01/2016 09:02, Nathan Ward wrote: Hi, It sounds like you’re quite positive that it works - perhaps you can provide some examples of when it’s worked in practice? -- Nathan Ward

Re: [j-nsp] Bandwidth aware using BGP on ISP transit

On 24/01/2016 23:01, Nathan Ward wrote: This sort of works, except there’s a strong chance that the attacker only gets advertised poisoned paths, and you’d drop all traffic. Do You mean attacker's ASN is non-existent? Or attacker's src IP is from RFC 1918/6598 space? Or attacker's src.IP are

Re: [j-nsp] Bandwidth aware using BGP on ISP transit

Hello, The problem lies in how do You make the attacker to prefer one of the links but the rest of the world to prefer all but the one preferred by attacker. I imagine this could be done if You know the attacker's source ASN: - do not prepend Your announcements out of the link picked by

Re: [j-nsp] Juniper and Cisco - BGP MPLS L2VPN VPLS interoperability

Hello, If You add an extra address family to the peering, the session is reset and this works as designed. This is not specific to Juniper or Cisco or vendor XYZ, this is BGP protocol spec. HTH Thx Alex On 20/11/2015 18:07, Aaron wrote: Can anyone share any experiences with interoperating

Re: [j-nsp] Routed VLAN Interfaces on MX

And don't forget to allocate linecard memory for LAG interfaces: set chassis aggregated-devices ethernet device-count 8 8 is a safe number. Don't overallocate by inflating "the device-count" - once allocated, this memory is not accessible to other linecard processes if Your actual device

Re: [j-nsp] Link with errors, how to fast detect ?

If that's CRC errors which cause the OSPF across the link to flap, then You could configure a RMON event with appropriate thresholds, the OID is in the ifJnxTable: aarseniev@labrouter> show snmp mib walk ifJnxTable ascii | grep crc ifJnxInHslCrcErrors.1 = 0 ifJnxInHslCrcErrors.4 = 0

Re: [j-nsp] Link with errors, how to fast detect ?

Hello, Not sure what exactly You are trying to achieve, looks like You want to delay announcing this link into OSPF (and by extension, using it for transit traffic) unless it has been stable for 3 secs. You could achieve this by defaulting this link to broadcast (if it is currently configured

Re: [j-nsp] exception traffic types for Juniper routers

Hello, For the "punted ICMP" stats, use "show system statistics icmp|icmp6". For the "non-punted" ICMP stats, use "show pfe statistics ip|ip6 icmp". As a general guidance for ICMP without IP options: - ICMP error replies are generated on linecards, they are rate-limited to 50pps per subinterface

Re: [j-nsp] purpose of "commit check"?

Hello, To add to what's been already covered - "commit check" runs the commit scripts as if it is an actual commit. And You can do pretty much everything with commit scripts, including logging to another node and comparing/changing the config there. One use case is to keep DetNAT pools &

Re: [j-nsp] Policy-statement to match on metrics less than, greater than, or within a range

There is a floor for MED and it is 0. What You could do is : term 1 then { metric subtract 1000; next term } term 2 from metric 0; then { local-preference 100; accept } You won't be able to keep the original MED though :-( HTH Thanks Alex On 27/08/2015 05:40, Mark Tinka wrote: On 27/Aug/15

Re: [j-nsp] dynamic prefix list based on as-path .. is it possible?

Hello, SCU can be used in this scenario http://www.juniper.net/documentation/en_US/junos14.2/topics/task/configuration/scu-or-dcu-configuring-junos-nm.html To drop traffic matching your chosen SCU in a firewall filter, use set forwarding-options family inet filter output YouRscUfilteRname

Re: [j-nsp] RSVP signaled LSPs across LACP bundles

Hello, In addition to what others said, You could use LB based on ip.id. To do that, You need to expose this flow as pure IPv4/IPv6 and do FBF with flexible-offset FW filters matching ip.id ranges:

Re: [j-nsp] MPLS Endpoint Discussion

On 03/07/2015 01:45, Ben Dale wrote: Always use loopbacks - if the link goes down (or the preceding node), the destination of the LSP goes with it - Junos will not maintain prefixes for downed interfaces. You mention this being a ring - if you target the LSP to a loopback, your IGP will

Re: [j-nsp] Reaching public IP addresses 'behind' an MS-DPC based CGNAT config in a MX480

Hello, You just need a MSDPC SFW rule to allow that, also explicit SFW rule is required for other subs if You don't have any: set services stateful-f rule Allow-subs-2-inet match-direction input set services stateful-f rule Allow-subs-2-inet term 1 then accept set services stateful-f rule

Re: [j-nsp] Setting CoS bits on ingress frames

the way frames are processed in the switch (queue assignment etc) or is this classification purely a marker? After you assign a forwarding-class with the first stanza, is there a show command to verify that the classifier has worked, that something in fact has happened? Alexander Arseniev wrote

Re: [j-nsp] Setting CoS bits on ingress frames

any packet enering this untagged port should be processed as if it has such and such CoS value. Alexander Arseniev wrote: Not on untagged ports - IEEE 802.1 PCP bits are only present in tagged frames. Thanks Alex On 23/06/2015 12:47, Victor Sudakov wrote: Alexander Arseniev wrote: On 17/06/2015

Re: [j-nsp] Setting CoS bits on ingress frames

Not on untagged ports - IEEE 802.1 PCP bits are only present in tagged frames. Thanks Alex On 23/06/2015 12:47, Victor Sudakov wrote: Alexander Arseniev wrote: On 17/06/2015 15:45, Victor Sudakov wrote: Would you care to give a simple example? Of course. Please try the below and see

Re: [j-nsp] disable “soft-reconf-inbound”

Yes it is. Cconfigure keep none under protocols bgp and You will have CSCO-like behaviour when after changing import policy You'd have to reset BGP session(s). keep none discards routes denied by import policy. Thanks Alex On 17/06/2015 11:56, Adam Vitkovsky wrote: Hi folks, Is it possible

Re: [j-nsp] Setting CoS bits on ingress frames

Hello, You can do it only on MX with JUNOS 14.2R3 and newer using new JUNOS feature policy-map, example config below: chassis { network-services enhanced-ip; } class-of-service { policy-map pm1 { dscp proto-ip code-point 110001; } forwarding-classes { queue 0 be;

Re: [j-nsp] Setting CoS bits on ingress frames

Hello, On 17/06/2015 15:10, Victor Sudakov wrote: All right, if I have Internet traffic in VLAN10 and video cameras in VLAN20, how do I mark on egress frames belonging to VLAN20 with CoS=1 and those belonging to VLAN20 with CoS=4 ? If You are doing it on EX-series, ingress interface is

Re: [j-nsp] Setting CoS bits on ingress frames

Hello, On 17/06/2015 15:45, Victor Sudakov wrote: Would you care to give a simple example? Of course. Please try the below and see if it works for You: class-of-service { forwarding-classes { queue 0 be; queue 1 ef; queue 2 af; queue 3 nc; queue 4

Re: [j-nsp] solution to a firewall question

Hello, next term does not work across member filters in a filter list last time I checked. So You have to combine/move these 2 functionalities into a single filter, which could be a member of filter-list. Thanks Alex On 23/04/2015 16:18, Vijesh Chandran wrote: Hi all, I am wondering if we

Re: [j-nsp] Merging routes from VRF to inet.0

There is a way but You may not like it :-) Basically, You need to announce same route twice - as inet-vpn unicast and as inet unicast from originating PE. On receiving PE, you have to do 2 things: 1/ adjust nexthop resolution set routing-options resolution rib inet.0 resolution-ribs [

  1   2   >