Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 12/11/2014 12:11, Raphael Mazelier a écrit : Le 11/11/2014 21:08, Karl Brumund - lists a écrit : EX (and QFX) have limited MPLS capabilities. The data sheet is rather optimistic about the capabilities, and a bit misleading about such things as route limits Expecting a cheap switch with merchant silicon to do the same as an expensive MX with custom ASICs is asking for trouble. Seriously, just do L2. Customer port is access, MX80 is trunked. You’re just asking for trouble with MPLS and L2VPN. Much of the same opinion, from quite recent exposure. Cheers, mh Agreed on cheaper switch. High end EX series seems a bit different tought. Some big IX (Linx, FranceIX) run with vpls topologies on EX9200 series (with some issues :) ). Yep, the higher end ones have richer spec's, right. Anyway. Redesigning my network at this stage might be challenging. I will try to let this work, and think about a new design in //. I know. Maybe Chip's way? TTYS, mh Thks. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX4550 L2Circuit/VPN to MX80/lt Interface
Le 11/11/2014 21:08, Karl Brumund - lists a écrit : EX (and QFX) have limited MPLS capabilities. The data sheet is rather optimistic about the capabilities, and a bit misleading about such things as route limits Expecting a cheap switch with merchant silicon to do the same as an expensive MX with custom ASICs is asking for trouble. Seriously, just do L2. Customer port is access, MX80 is trunked. You’re just asking for trouble with MPLS and L2VPN. Much of the same opinion, from quite recent exposure. Cheers, mh …karl On Nov 11, 2014, at 5:22 AM, Raphael Mazelier r...@futomaki.net wrote: Speculation on my side, but given the limited MPLS capabilities on EX switchs, control plane may work fine due to common code within the Juniper product line, but the forwarding plane fails you. This could explain why things look up/up, but without traffic. Well, you should be right. On the other the spec of the EX4550 specifie that l2vpn (at least l2circuit) should be working... And some other guys on the list report some kind of success with that. Thks. -- Raphael Mazelier ___ 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] what is different between virtual router and logical-system
Le 24/06/2014 07:16, bruno a écrit : Hi guys, Hi Bruno, This thread might help you? = http://forums.juniper.net/t5/Routing/Difference-between-logical-router-and-virtual-router/td-p/18694 Cheers, mh i have use juniper for long time. but today my colleague ask me what is big different bwtween virtual router and logical-system? from my point of view, the big different is interface configuration . with virtual router , interface configuration under global config,while logical -system ,configure their interface under logical-system. anything else ? pls comment .thx. -- Best Regards, Bruno ___ 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] Community matching policy
Le 31/03/2014 13:47, Andrew Khan a écrit :
In addition to my last question, what I don't understand is that !A OR !B =
!(A AND B) /// how come it became AND operation rather than logical OR///
Think of them in terms of boolean truth tables.
From Juniper documentation:
You can include the names of multiple communities in the community match
condition. If you do this, only one community needs to match for a match to
occur (matching is effectively a logical OR operation).
Is it invert-match causing this behavior? What if I don't use invert-match,
will it be a logical OR operation e.g. A OR B = A OR B or will it be A OR B
= (A AND B)
Unless you find what you need at http://preview.tinyurl.com/o5fjmof,
welcome back to me.
Cheers,
mh
Thanks
From: good1...@outlook.com
To: kr...@smartcom.bg
Date: Mon, 31 Mar 2014 11:00:48 +
CC: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] Community matching policy
Hello Krasi,
Thanks for the reply, appreciated. Sorry I did not mention in my first email
that I'm trying to find a workaround while using invert-match. Any idea on
achieving the same results when using invert-match.
Kind regards,
Date: Mon, 31 Mar 2014 13:41:40 +0300
Subject: Re: [j-nsp] Community matching policy
From: kr...@smartcom.bg
To: good1...@outlook.com
CC: juniper-nsp@puck.nether.net
A match 100:100B match 101:101 Your TEST1 term match on !A OR !B = !(A AND
B), so it effectively rejects every route that has NO communities 100:100
AND 101:101 (at the same time)
Your target is to accept A OR B, so you can first match and accept on these
communities (TEST1 OR TEST2 defined without invert-match) and then reject
everything else.
Best Regards,
Krasi
On 31 March 2014 12:10, Andrew Khan good1...@outlook.com wrote:
Hi -
Let's say I want to reject everything except the following communities:
Either 100:100
OR 101:101
OR both 100:100 101:100
Tried to setup something:
[edit policy-options]
policy-statement TEST {
term TEST1 {
from community [ TEST1 TEST2 ]; ///Is not it logical OR, and
matching everything except what I want because of invert-match//
then reject;
}
term TEST2 {
then accept; And then this should accept what I wanted /
}
}
[edit policy-options]
community TEST1 {
invert-match;
members 100:100;
}
community TEST2 {
invert-match;
members 101:101;
}
However it is rejecting everything. Any thoughts what I'm missing here or
perhaps the approach is not correct.
Thanks in advance.
___
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] proposed changes to clear bgp neighbor
Le 26/02/2014 22:10, sth...@nethelp.no a écrit : We've been asked to make a change the clear bgp neighbor command to make the neighbor or all argument mandatory. The root cause is the severe impact of clear bgp neighbor and the increasing accidental use of this command without a specific neighbor. In general, we avoid changing commands to add mandatory arguments, but my feeling is that the impact and severity of this specific command makes this an acceptable occasion for such a change. I'm looking for feedback about this change. My working assumption is that clear bgp neighbor is a sufficiently rare command and would not be used in automation/scripts, so the impact of making the neighbor/all argument mandatory would be minimal. Is this assumption accurate? For us, yes. Fully support the idea of requiring an all argument. +1 mh Steinar Haug, AS 2116 ___ 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] proposed changes to clear bgp neighbor
Le 27/02/2014 18:58, Eric Van Tol a écrit : ast. :-) mh ___ 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] Policy-based IPSec tunnel and static routing
Le 22/11/2013 20:41, Klaus Groeger a écrit : In policy based VPN just rely on default route, witch points out the interface and zone where the VPN's outgoing interface resides. The packets have to hit the policy between the internal and external zone, then are injected to the VPN. No additional route is needed. Hi Klaus, OK, but does it rely on 0/0 _only_. What I saw appears to be a counter example, in the context of internal static route set and external route being a subnetwork of this internal one. ;-) Cheers, mh Klaus — Sent from Mailbox https://www.dropbox.com/mailbox for iPhone On Thu, Nov 21, 2013 at 4:29 PM, Per Westerlund p...@westerlund.se mailto:p...@westerlund.se wrote: Sorry, no automatic route-injection with SRX and policy-based IPsec VPN. The traffic has to be made to hit the security policy rules that allows the tunnel traffic, and that is normally manually. /Per 21 nov 2013 kl. 16:17 skrev Michael Hallgren m.hallg...@free.fr: Hi, I ran into the following: In a pretty much standard setup of a policy-based IPSec VPN between a SRX and a cisco ASA, pinging destination behind the SRX worked just fine from behind the ASA, the other way around didn't. Had few static routes set, among them a 0/0 pointing in the direction of the ASA, and a 10/8 pointing at SRX customers. The host behind the ASA, that I couldn't ping was in 10/24, say. Adding a static route 10/24 pointing at the ASA (not at the tunnel endpoint), fixed the flow from SRX to ASA. Was under the impression that policy-based setup is supposed to handle static route injection auto-magically. What am I missing? Cheers, mh ___ 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] eBGP with internet provider from DataCenters
Le 15/11/2013 14:18, Yham a écrit : Hi Guys, Hi, If we have two active/active DataCenters on different geographical locations and going to peer with the same provider for internet. What are the pros and cons of having same Autonomous Number on both data centers. In other word which is more scalable and practical, having both data cernter on single public ASN or should be two different when peering with same internet providers. Can you please share you thoughts on it. How are your data centers interconnected? mh Regards ___ 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] eBGP with internet provider from DataCenters
Le 15/11/2013 17:10, Dave Curado a écrit : Hi Yham, Thanks for the map -- your situation is a lot more interesting than it first appeared! I agree! :-) I'm guessing there may be some number of requirements and policy decisions that went into this. Without knowing all the back story, it makes it a little tricky to say what would be best solution. I realize I'm not answering the question you have asked, but I'm curious: Is there a reason that the BR-1 and BR-2 routers can't be part of the same AS as the Internal Internet with public ASN core? That would seem like a clean solution. If you can't do that, and you can't use private AS-es for the pair of BR-1/BR-2 routers, then when I look at your diagram, each BR-1/BR-2 pair *looks like* a single AS to me; while they are connected together through the MPLS network, that happens through a different private AS. Maybe wrapping things up in a BGP confederation architecture? Thoughts? So, somewhat ironically, I'm back at my original message with my same list of pros and cons. =-) mh HTHs, Dave ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP with internet provider from DataCenters
Le 15/11/2013 18:14, Dave Curado a écrit : Hi Yham, FYI - I think one of my email messages on this thread didn't go out, the body of the message was larger than some threshold, and it requires a moderator approval. (they'll get to it at some point =-) can you comments on how AS-confederation will benefit more over having all BRs part of single public AS with iBGP peering with neighbors. Datacenter-1 one is already on public AS so it will be difficult to make changes. The only reason with two AS is architectural complexity when you suggest one AS for both DCs or do you think any routing issues can also be encounters. The way your current topology uses a number of private-ASes, it starts to look like a BGP confederation. The benefit of a confederation is the ability to present your network as a single AS, while internally using a set of private ASes allowing a separation of administrative and policy choices for each private AS. But that flexibility does come with a bit more complexity. (I'm sure there are people on this list who have worked with confederations and will hopefully chime in on this.) Yes, I agree. Never do more complex than projected to be needed mid-term (or so). In other words, AS-confed if you feel that policing between your subs is or will become important, else: Since the two BR-1/BR-2 pairs are interconnected, and one already has a public ASN, making them all part of the same ASN and putting an ibgp mesh into place would be relatively easy, and would save a second public ASN from being used. At least, it looks relatively easy to me, and that is attractive. =-) Voilà ! Cheers, mh HTHs, Dave ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP with internet provider from DataCenters
Oups..., resend after ML police pointed out that message was too heavy. mh Le 15/11/2013 18:14, Michael Hallgren a écrit : Le 15/11/2013 17:53, Yham a écrit : can you comments on how AS-confederation will benefit more over having all BRs part of single public AS with iBGP peering with neighbors. cBGP (or whatever we call it) between your sub-AS would allow you to nicely, more flexibly than with IGP, manage how traffic flow between them. Datacenter-1 one is already on public AS so it will be difficult to make changes. Right. It's a good thing to introduce AS-confed early. Later migration may be a PITA... mh The only reason with two AS is architectural complexity when you suggest one AS for both DCs or do you think any routing issues can also be encounters. On Fri, Nov 15, 2013 at 11:40 AM, Dave Curado da...@curado.org mailto:da...@curado.org wrote: Hi Yham, Yes, with that link between the BR-1/BR-2 pair, I would tend to make them one AS. I just like keeping things as straight-forward as I can. =-) But using different ASes would work as well. That said, Michael Hallgren suggested doing an AS-confederation. I think that's a great idea to consider. Thanks, Dave snip/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] community set vs community add
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 01/11/2013 06:32, Mark Tinka a écrit : On Thursday, October 31, 2013 10:38:18 PM Michael Hallgren wrote: I apologize for not having followed this thread in detail, but generally we've avoided to allow iBGP route reflectors to manipulate a fair amont of attributes in out policies... Now, this being in an Internet routing context, your VP* needs may be different? For my culture, please let know. Modifying or updating communities on outbound sessions on route reflectors is routine. If you're referring to other BGP attributes, perhaps. Yes, maybe I was using a sledge hammer (promoting conservativeness). If it's ``good'' or ``bad'' to rewrite communities in this way, may depend on how you then use them. When running NG-MVPN on Juniper's, I had to rewrite the communities that NG-MVPN's set on ingress or egress PE routers because the routes that were reflected to Cisco routers that didn't understand these communities - at the time - meant they could not route unicast correctly within the l3vpn's that carried the NG-MVPN traffic. Rewriting the community (really, making it conform more to what Cisco could understand) was a tricky, sneaky fix that worked. Which sounds like an example of (forced to but yet) ``good'' to me. Cheers, mh IOS XE and IOS XR now have very good support for NG-MVPN's, but I haven't checked how it would respond to such an issue these days. Suffice it to say, that was IOS, then. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJzaosACgkQZNZ/rrgsqafgJQCfVbY0IEro1Z5PvFGEsobsSPqu YxwAoJK4fvObBW/tuzD57KIdF9V/mFtp =JEoA -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] community set vs community add
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 01/11/2013 06:32, Mark Tinka a écrit : On Thursday, October 31, 2013 10:38:18 PM Michael Hallgren wrote: I apologize for not having followed this thread in detail, but generally we've avoided to allow iBGP route reflectors to manipulate a fair amont of attributes in out policies... Now, this being in an Internet routing context, your VP* needs may be different? For my culture, please let know. Modifying or updating communities on outbound sessions on route reflectors is routine. If you're referring to other BGP attributes, perhaps. Maybe I used a sledge hammer, promoting being conservative. Such use of BGP communities, may be ``good'' or ``bad'' depending on how they are then used, I think. When running NG-MVPN on Juniper's, I had to rewrite the communities that NG-MVPN's set on ingress or egress PE routers because the routes that were reflected to Cisco routers that didn't understand these communities - at the time - meant they could not route unicast correctly within the l3vpn's that carried the NG-MVPN traffic. Rewriting the community (really, making it conform more to what Cisco could understand) was a tricky, sneaky fix that worked. Which appears being a ``good'' reason (in spite of being forced). Cheers, mh IOS XE and IOS XR now have very good support for NG-MVPN's, but I haven't checked how it would respond to such an issue these days. Suffice it to say, that was IOS, then. Mark. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJza84ACgkQZNZ/rrgsqafTEgCgm658C7s/m+6hVFOcP/7Eyh4s UuwAnAxavfvGmtgUO99XB4mmB4zGi076 =n+Rd -END PGP SIGNATURE- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] community set vs community add
Hi guys,
I apologize for not having followed this thread in detail, but generally
we've avoided to allow
iBGP route reflectors to manipulate a fair amont of attributes in out
policies... Now, this being
in an Internet routing context, your VP* needs may be different? For my
culture, please let
know.
Cheers,
mh
Le 31/10/2013 21:06, Mihai a écrit :
You are totally right, thank you very much.
Regards,
On 10/31/2013 09:50 PM, Harry Reynolds wrote:
Perhaps when you use set, which strips the existing comm. set as
mentioned, this includes the Layer2 Info Extended Community as per
rfc 4761, which is needed to signal bgp based vpls.
Seems you go from this:
Communities: target:10:10 Layer2-info: encaps:
VPLS, control flags:[0x0] , mtu: 0, site preference: 100
To this:
Communities: target:10:10
I belive that would explain why add, which leaves the existing set
intact, is working.
Regards
-Original Message-
From: Mihai [mailto:mihaigabr...@gmail.com]
Sent: Thursday, October 31, 2013 12:19 PM
To: Harry Reynolds
Cc: EXT - ipv6fre...@gmail.com; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] community set vs community add
I agree, but I don't think you understand what I am trying to do.
Let's take it step by step:
- z advertises l2vpn route to RR q
z show route advertising-protocol bgp 20.20.20.3 detail
mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
hidden)
* 20:20:2:1/96 (1 entry, 1 announced)
BGP group ibgp type Internal
Route Distinguisher: 20:20
Label-base: 80, range: 8
Nexthop: Self
Flags: Nexthop Change
Localpref: 100
AS path: [65550] I
Communities: target:20:20 Layer2-info: encaps: VPLS, control
flags:[0x0] , mtu: 0, site preference: 100
- the RR should replace the community target:20:20 advertised by z
with target:10:10 and the advertise the prefix to x (RR client)
q# run show route table bgp.l2vpn.0 detail
bgp.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden)
10:10:1:1/96 (1 entry, 1 announced)
*BGPPreference: 170/-101
Route Distinguisher: 10:10
Next hop type: Indirect
Address: 0x26ec814
Next-hop reference count: 1
Source: 20.20.20.1
Protocol next hop: 20.20.20.1
Indirect next hop: 2 no-forward INH Session ID: 0x0
State: Active Int Ext
Local AS: 65550 Peer AS: 65550
Age: 3:13:27 Metric2: 1
Validation State: unverified
Task: BGP_65550.20.20.20.1+58349
Announcement bits (1): 0-BGP_RT_Background
AS path: I
Communities: target:10:10 Layer2-info: encaps:
VPLS, control flags:[0x0] , mtu: 0, site preference: 100
Accepted
Label-base: 80, range: 8
Localpref: 100
Router ID: 20.20.20.1
- x accepts the l2vpn route from RR and place it in the vrf-l2vpn table
x show route receive-protocol bgp 20.20.20.3 table mihai-vpls.l2vpn.0
detail
mihai-vpls.l2vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0
hidden)
* 20:20:2:1/96 (1 entry, 0 announced)
Import Accepted
Route Distinguisher: 20:20
Label-base: 80, range: 8, status-vector: 0x0
Nexthop: 20.20.20.2
Localpref: 100
AS path: I (Originator)
Cluster list: 0.0.0.1
Originator ID: 20.20.20.2
Communities: target:10:10
Now, x should have a vpls connection up,but this is not the case when
the policy used on RR for changing the community target:20:20 to
target:10:10 is this:
q# show policy-statement from-z
term 10 {
from {
protocol bgp;
community vpls-z;
}
then {
community set vpls-x;
accept;
}
}
q# top show protocols bgp
group ibgp {
type internal;
local-address 20.20.20.3;
family l2vpn {
signaling;
}
cluster 0.0.0.1;
neighbor 20.20.20.1;
neighbor 20.20.20.2 {
import from-z;
export to-z;
}
}
x show vpls connections
Legend for interface status
Up -- operational
Dn -- down
Instance: mihai-vpls
Local site: a (1)
No connections found.
If I change the policy to:
q# show policy-statement from-z
term 10 {
from {
protocol bgp;
community vpls-z;
}
then {
community delete vpls-z;
community add vpls-x;
accept;
}
}
then vpls comes up:
Legend for interface status
Up -- operational
Dn -- down
Instance: mihai-vpls
Local site: a (1)
connection-site Type St Time last up #
Up trans
2
Re: [j-nsp] Curly braces in AS-path
Hi, AS-set normally. Used in context of aggregation.
Cheers
mh
Message d'origine
De : Vincent De Keyzer vinc...@dekeyzer.net
Date :
A : juniper-nsp@puck.nether.net
Objet : [j-nsp] Curly braces in AS-path
Hello all,
the following comes from the TeliaSonera looking glass (http://lg.telia.net/
):
Router: Hong Kong
Command: show route protocol bgp 1.38.0.0/17 table inet.0
inet.0: 518574 destinations, 1103564 routes (518516 active, 113 holddown,
1207 hidden)
+ = Active Route, - = Last Active, * = Both
1.38.0.0/17 *[BGP/170] 1w2d 17:44:34, MED 0, localpref 150
AS path: 1273 55410 38266 {38266} ?
to 80.239.130.206 via ge-2/1/1.0
What do the curly braces in the AS path mean? More generally, does someone
know a document explaining how to interpret the output of sh route prot
bgp?
Thanks,
Vincent
___
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] Best route reflector platform
Le 15/04/2013 18:20, Jeff Aitken a écrit : On Sun, Apr 14, 2013 at 06:47:41PM +0200, Mark Tinka wrote: ASR1001 with 16GB DRAM. What more do you want, really? Well, it fails my must run IOS-XR or JUNOS requirement, for starters. ;-) And seriously, who wants to implement routing policy in IOS?! Bletch. What I want is something based on a generic compute platform, ala JUNOSphere/VIRL. That lets me scale the control plane as big as I need to, avoids wasting money on purpose-built hardware optimized for forwarding, and comes with the added bonus of using the same OS policy language that's already widely deployed in my network, so at least I don't get any NEW interop issues. The downside is that neither vendor sells such a thing right now, and so we're stuck arguing about which square peg fits best into the round hole. (small ASR9k and MX here, FWIW) Oh and I also want a two-vendor solution so that I'm (hopefully) not completely screwed the next time one of them discovers a new attribute- handling bug. RAML? ;) mh --Jeff ___ 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] Back-reference in JunOS regular expressions
Le samedi 16 juillet 2011 à 15:17 -0700, Jonathan Lassoff a écrit : Jeff, Michael -- these are both totally reasonable cases I didn't even consider. The Juniper clue wiki article is a really good example as to why. I wonder why it's not implemented. It does seem relatively easy considering the fact that there is already some support for regular expressions anyway. Yes. I agree. Support even for back-reference in other context (like 'replace') than 'AS-path'... as a matter of fact. I guess a large-enough customer hasn't made an ultimatum for Juniper yet. :p About to formalize a feature request (not an ultimatum). ;) Cheers, mh --j ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Back-reference in JunOS regular expressions
Le mercredi 13 juillet 2011 à 18:25 +0200, Daniel Verlouw a écrit : see https://puck.nether.net/pipermail/juniper-nsp/2010-July/017473.html Not supported. I requested an ER back then, don't think it ever got implemented... Thanks Daniel, I'll do the same then... Must be considered pretty basic from a regexp point of view, I think. Right? :) Cheers, mh signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Back-reference in JunOS regular expressions
Le jeudi 14 juillet 2011 à 00:00 -0700, Jonathan Lassoff a écrit : On Wed, Jul 13, 2011 at 11:02 PM, Michael Hallgren m.hallg...@free.fr wrote: Le mercredi 13 juillet 2011 à 18:25 +0200, Daniel Verlouw a écrit : see https://puck.nether.net/pipermail/juniper-nsp/2010-July/017473.html Not supported. I requested an ER back then, don't think it ever got implemented... Thanks Daniel, I'll do the same then... Must be considered pretty basic from a regexp point of view, I think. Right? :) From a user and standardization perspective, they seem pretty simple, but are actually difficult to implement very efficiently since the time it takes to do the search is non-deterministic. Yes, I'm aware of the theoretical and the implementation sides of these things. To be more precise, I should rather have said basic from a functional point of view in this AS_PATH context. Here's a nice accessible write-up about DFA vs NFA regex engines that touches on this: http://swtch.com/~rsc/regexp/regexp1.html I good article. Thanks. Honestly, what's the use case of a backreference for an AS path? It seems like BGP loop detection would never allow a path like A X X A, in which case if it's just used to search for repetition (as mentioned above), why not just use the + and * operators? e.g. ^(701 )+ For one, you may want to enforce closest exit with a peer by assigning a common (higher) local preference to A, A A, A A A, etc. To catch any A with a single policy definition, you may want to filter what you import by (.)( \1)*$. If '\1' not available, you would have to define a specific filter for each (session with) A. (Yes, I know, this should not be needed in theory, because of peering agreements. But the world is not always perfect... And, yes, I agree, it's a question of choice: feature versus additional complexity...) Cheers, jof Cheers mh signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Back-reference in JunOS regular expressions
Hi, Is back-reference, like (.)( \1)*$, provided by the JunOS AS-path matching engine? (This should match, for instance, ^6453$, ^6453_6453$, ^6453_6453_6453$, and so on...) I can't find a firm statement in the JunOS documentation, and some tests makes me believe it's not implemented. Or am I mistaken with the syntax? (I can use back-reference in 'replace', etc, etc...) Cheers, mh signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] ASRe: Back-reference in JunOS regular expressions
Le mercredi 13 juillet 2011 à 15:15 +0100, Alexander Frolkin a écrit : Hi, Is back-reference, like (.)( \1)*$, provided by the JunOS AS-path matching engine? (This should match, for instance, ^6453$, ^6453_6453$, ^6453_6453_6453$, and so on...) Never tried this, but do you mean something like ([0-9]*)( \1)* ? No, in AS-path context, ASNs are the atoms (thus (.) above). This works with egrep: $ echo 123 123 | egrep '^([0-9]*)( \1)*$' 123 123 $ echo 123 124 | egrep '^([0-9]*)( \1)*$' $ Yes. mh Alex signature.asc Description: This is a digitally signed message part ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
