Re: [j-nsp] Mixing v4/v6 neighbors in BGP groups
We try to keep IPv4 and IPv6 configuration always distinct from each other, where possible. Thus, not mixing v4 and v6 peerings in the same groups. This kind of ships in the night approach makes it much more comfortable to operate the network as it minimizes the risk that changes related to one family impacts the other one too. Antti On 29.06.2018 18:01, Rob Foehl wrote: > Wondering aloud a bit... I've seen plenty of cases where wedging > parallel v4/v6 sessions into the same BGP group and letting the router > sort out which AFI it's supposed to be using on each session works fine, > and nearly as many where configuring anything family-specific starts to > get ugly without splitting them into separate v4/v6 groups. Are there > any particularly compelling reasons to prefer one over the other? > > I can think of a bunch of reasons for and against on both sides, and > several ways to handle it with apply-groups or commit scripts. Curious > what others are doing here. > > Thanks! > > -Rob > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > > -- CSC - Tieteen tietotekniikan keskus Oy:n asiakas- seka sidosryhmarekisterien henkilotietojen kasittely kuvataan tietosuojaselosteissa: https://www.csc.fi/tietosuoja CSC - IT Center for Science Ltd processes customer and other stakeholder personal information in the following way: https://www.csc.fi/privacy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
On Jun 29, 2018, at 8:49 AM, adamv0...@netconsultings.com wrote: > > Just wondering what's the latest on the GPU for packet forwarding front (or > is that deemed legacy now)? Waiting for the bare-metal version of this to land (you can test it on AWS right now): https://www.netgate.com/products/tnsr/ https://www.netgate.com/blog/the-behemoth-router-is-here.html Jason ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF export/import of eBGP learned route
Hi, thanks for adding to this.
I've just removed the loops statement in there to see what would happen. It
seems to me like the AS number in routing-options is pretty much the source
of the looping trigger that occurs (the addition of a second internal AS to
the path).
Everything works well and loop free without the loops statement, seems I
won't have to go the tunnel way.
Thanks again!
On Fri, Jun 29, 2018 at 5:39 PM Niall Donaghy
wrote:
> Hi Alexander,
>
> In our network, inet.0 is AS20965 and IAS.inet.0 is AS21320.
> The IAS routing instance contains all commercial routes - public, private,
> and upstream peerings.
>
> Between inet.0 and IAS.inet.0 we have logical tunnels with BGP peerings.
>
> The routers are all configured with autonomous-system 20965, but to
> networks
> external to AS21320, we appear as AS21320, with the following
> configuration:
>
> set routing-instances IAS protocols bgp group SOMEGROUP neighbor x.x.x.x
> local-as 21320
> set routing-instances IAS protocols bgp group SOMEGROUP neighbor x.x.x.x
> local-as private
> set routing-instances IAS protocols bgp group SOMEGROUP neighbor x.x.x.x
> local-as no-prepend-global-as
>
> This keeps things tidy, loop-free, and BGP all the way, ie: no RIB groups
> or
> 'loops 2' statements, and we benefit from BGP path loop detection, and BGP
> policy controls between the two ASes.
>
> We've been running with 2.6M routes this way for 2.5 years+ and no issues.
>
> Happy to share if ever you want to refine your solution.
>
> Br,
> Niall
>
> -Original Message-
> From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf
> Of
> Philippe Girard
> Sent: 29 June 2018 15:15
> To: Alexander Arseniev
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] VRF export/import of eBGP learned route
>
> Hello everyone
>
> Thank you so much for your suggestions. The solution in this case is to
> remove the autonomous-system statement completely from the routing-instance
> routing-options and apply the local-as statement under bgp with the private
> knob.
>
> protocols {
> bgp {
> local-as 456 loops 2 private
>
> This creates an internal table that looks just like it would under regular
> bgp inet.0.
>
> Thanks again!
>
> On Fri, Jun 29, 2018 at 4:07 AM Alexander Arseniev via juniper-nsp <
> juniper-nsp@puck.nether.net> wrote:
>
> > Hello,
> >
> > Does "no-prepend-global-as" help?
> >
> >
> > https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-l
> > ocal-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 lab and I'm pretty sure I saw this same issue.
> > >
> > > Sounds like something I saw with my internet boundary pe's, would
> > > add my
> > AS
> > > on routes were learned from internet and send as vpnv4 routes into
> > > my internal ibgp environment and internal pe's were seeing their own
> > > AS and routes were being hidden as looped...
> > >
> > > Try this on PE1
> > >
> > > If pe1 ebgp group is called "ebgp-to-ix"...
> > > If IX ip that you neighbor with is 1.2.3.4...
> > > If vrf on PE1 and PE2 is called "my-vrf"...
> > >
> > > ...do this on PE1...
> > > set routing-instances my-vrf protocols bgp group ebgp-to-ix neighbor
> > 1.2.3.4
> > > local-as private
> > >
> > > ...now see if PE2 is still seeing its own AS as looped
> > >
> > > - Aaron
> > >
> > >
> > > ___
> > > 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] Mixing v4/v6 neighbors in BGP groups
Hi, As far as the saying goes : divide to conquer ! Best regards. > Le 29 juin 2018 à 23:28, Rolf Hanßen a écrit : > > Hi, > > started with a "everything configured separately" network (on > Cisco/Quagga) but now I prefer both together in one group (started with it > during a vendor replacement (Cisco to Juniper) and new config from scratch > 2 years ago). > > Because it is easier to handle (shut only one group, do not forget that > there may be somebody really using IPv6 you forget to shutdown). > Because it makes sure both have the same routing policies (I don't want > them to behave different). > Because it reduces the config size (we do not have hundreds of routers > deployed by some scripts). > > I set families and source address (if using loopback) with an apply-group: > set groups blablabla protocols bgp group <*> neighbor <*:*> local-address ... > set groups blablabla protocols bgp group <*> neighbor <*:*> family inet6 > unicast > > In case I need some v4/v6 sepcific stuff in a policy I create 2 terms in > one policy. > > but that's more like "do you prefer vanilla or chocolate ?" than an > essential question. > > kind regards > Rolf > > PS: Would be great if Juniper would allow both families together in a > single route-filter. > >> Wondering aloud a bit... I've seen plenty of cases where wedging parallel >> v4/v6 sessions into the same BGP group and letting the router sort out >> which AFI it's supposed to be using on each session works fine, and nearly >> as many where configuring anything family-specific starts to get ugly >> without splitting them into separate v4/v6 groups. Are there any >> particularly compelling reasons to prefer one over the other? >> >> I can think of a bunch of reasons for and against on both sides, and >> several ways to handle it with apply-groups or commit scripts. Curious >> what others are doing here. >> >> Thanks! >> >> -Rob >> ___ >> 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] VRF export/import of eBGP learned route
Hi Alexander,
In our network, inet.0 is AS20965 and IAS.inet.0 is AS21320.
The IAS routing instance contains all commercial routes - public, private,
and upstream peerings.
Between inet.0 and IAS.inet.0 we have logical tunnels with BGP peerings.
The routers are all configured with autonomous-system 20965, but to networks
external to AS21320, we appear as AS21320, with the following configuration:
set routing-instances IAS protocols bgp group SOMEGROUP neighbor x.x.x.x
local-as 21320
set routing-instances IAS protocols bgp group SOMEGROUP neighbor x.x.x.x
local-as private
set routing-instances IAS protocols bgp group SOMEGROUP neighbor x.x.x.x
local-as no-prepend-global-as
This keeps things tidy, loop-free, and BGP all the way, ie: no RIB groups or
'loops 2' statements, and we benefit from BGP path loop detection, and BGP
policy controls between the two ASes.
We've been running with 2.6M routes this way for 2.5 years+ and no issues.
Happy to share if ever you want to refine your solution.
Br,
Niall
-Original Message-
From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of
Philippe Girard
Sent: 29 June 2018 15:15
To: Alexander Arseniev
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] VRF export/import of eBGP learned route
Hello everyone
Thank you so much for your suggestions. The solution in this case is to
remove the autonomous-system statement completely from the routing-instance
routing-options and apply the local-as statement under bgp with the private
knob.
protocols {
bgp {
local-as 456 loops 2 private
This creates an internal table that looks just like it would under regular
bgp inet.0.
Thanks again!
On Fri, Jun 29, 2018 at 4:07 AM Alexander Arseniev via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> Hello,
>
> Does "no-prepend-global-as" help?
>
>
> https://www.juniper.net/documentation/en_US/junos/topics/concept/bgp-l
> ocal-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 lab and I'm pretty sure I saw this same issue.
> >
> > Sounds like something I saw with my internet boundary pe's, would
> > add my
> AS
> > on routes were learned from internet and send as vpnv4 routes into
> > my internal ibgp environment and internal pe's were seeing their own
> > AS and routes were being hidden as looped...
> >
> > Try this on PE1
> >
> > If pe1 ebgp group is called "ebgp-to-ix"...
> > If IX ip that you neighbor with is 1.2.3.4...
> > If vrf on PE1 and PE2 is called "my-vrf"...
> >
> > ...do this on PE1...
> > set routing-instances my-vrf protocols bgp group ebgp-to-ix neighbor
> 1.2.3.4
> > local-as private
> >
> > ...now see if PE2 is still seeing its own AS as looped
> >
> > - Aaron
> >
> >
> > ___
> > 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] Mixing v4/v6 neighbors in BGP groups
Hi, started with a "everything configured separately" network (on Cisco/Quagga) but now I prefer both together in one group (started with it during a vendor replacement (Cisco to Juniper) and new config from scratch 2 years ago). Because it is easier to handle (shut only one group, do not forget that there may be somebody really using IPv6 you forget to shutdown). Because it makes sure both have the same routing policies (I don't want them to behave different). Because it reduces the config size (we do not have hundreds of routers deployed by some scripts). I set families and source address (if using loopback) with an apply-group: set groups blablabla protocols bgp group <*> neighbor <*:*> local-address ... set groups blablabla protocols bgp group <*> neighbor <*:*> family inet6 unicast In case I need some v4/v6 sepcific stuff in a policy I create 2 terms in one policy. but that's more like "do you prefer vanilla or chocolate ?" than an essential question. kind regards Rolf PS: Would be great if Juniper would allow both families together in a single route-filter. > Wondering aloud a bit... I've seen plenty of cases where wedging parallel > v4/v6 sessions into the same BGP group and letting the router sort out > which AFI it's supposed to be using on each session works fine, and nearly > as many where configuring anything family-specific starts to get ugly > without splitting them into separate v4/v6 groups. Are there any > particularly compelling reasons to prefer one over the other? > > I can think of a bunch of reasons for and against on both sides, and > several ways to handle it with apply-groups or commit scripts. Curious > what others are doing here. > > Thanks! > > -Rob > ___ > 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] Mixing v4/v6 neighbors in BGP groups
On Fri, Jun 29, 2018 at 8:26 PM, Rob Foehl wrote:
> On Fri, 29 Jun 2018, Job Snijders wrote:
>
>> For the purpose of inter-domain routing I'd advise against mixing warm
>> mayonnaise and jagermeister. uh.. i mean IPv4 and IPv6.
>>
>> Keeping things separate maybe makes debugging easier.
>
>
> I may have been insufficiently specific... I'm referring to:
>
> group example {
> neighbor 192.0.2.0;
> neighbor 2001:db8::;
> }
>
> vs.
>
> group example-ipv4 {
> neighbor 192.0.2.0;
> }
>
> group example-ipv6 {
> neighbor 2001:db8::;
> }
>
>
> The former is (operationally) simpler to deal with, until it isn't -- think
> "deactivate group example", etc. I'm tempted to just be explicit about the
> split everywhere, but I already spend enough time explaining that there are
> two of everything and it's been that way for a while now...
I'd be explicit about this split. You'll maybe have routing policies
applied on the group level, perhaps also on the neighbor level - maybe
not always. What happens when you put a policy designed for only IPv4
on IPv6 neighbors? What will happen on the other vendors you'll later
pull into your network?
If the network is automated the split doesn't matter that much anyway.
Kind regards,
Job
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixing v4/v6 neighbors in BGP groups
On Fri, 29 Jun 2018, Mark Tinka wrote:
I prefer not to find out whether walking on hot coal will kill all
feeling in my feet, or just numb them for 2hrs :-).
So... Is that a vote for or against, and which one? ;)
On Fri, 29 Jun 2018, Job Snijders wrote:
For the purpose of inter-domain routing I'd advise against mixing warm
mayonnaise and jagermeister. uh.. i mean IPv4 and IPv6.
Keeping things separate maybe makes debugging easier.
I may have been insufficiently specific... I'm referring to:
group example {
neighbor 192.0.2.0;
neighbor 2001:db8::;
}
vs.
group example-ipv4 {
neighbor 192.0.2.0;
}
group example-ipv6 {
neighbor 2001:db8::;
}
The former is (operationally) simpler to deal with, until it isn't --
think "deactivate group example", etc. I'm tempted to just be explicit
about the split everywhere, but I already spend enough time explaining
that there are two of everything and it's been that way for a while now...
-Rob
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixing v4/v6 neighbors in BGP groups
For the purpose of inter-domain routing I'd advise against mixing warm mayonnaise and jagermeister. uh.. i mean IPv4 and IPv6. Keeping things separate maybe makes debugging easier. Kind regards, Job ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Mixing v4/v6 neighbors in BGP groups
On 29/Jun/18 17:01, Rob Foehl wrote: > Wondering aloud a bit... I've seen plenty of cases where wedging > parallel v4/v6 sessions into the same BGP group and letting the router > sort out which AFI it's supposed to be using on each session works > fine, and nearly as many where configuring anything family-specific > starts to get ugly without splitting them into separate v4/v6 groups. > Are there any particularly compelling reasons to prefer one over the > other? > > I can think of a bunch of reasons for and against on both sides, and > several ways to handle it with apply-groups or commit scripts. > Curious what others are doing here. I prefer not to find out whether walking on hot coal will kill all feeling in my feet, or just numb them for 2hrs :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Router for full routes
On 29/Jun/18 17:10, Rob Foehl wrote: > > Thanks for the detailed reply, Mark. > > By "ancient", I mean boxes still running RE-S-1300s, original SCBs, > and either DPCs or older MPC2s -- basically, everything EOL except the > chassis, and running a mix of 1G and 10G interfaces. The limited slot > count isn't much of an issue, especially with the possibility of > moving to at least MPC3Es with 10x10G MICs. > > The REs are the biggest issue, stuck on old code and not nearly enough > memory. 1G interfaces are also a problem, but switches are cheap... > > I do like the idea of the MX204 as an edge box, currently have some > MX80s in that role that wouldn't be missed. Fair point, bringing an MX240/480/960 chassis from 2009 up-to-scratch in 2018 could be costlier than going for an MX204. My suggestion would be that if you want to retain the benefits of a chassis, dump the MX240 and move to an MX480, and put in the new line cards and RE. Otherwise, if you have a limited budget and need more bang for you $$ right away, the MX204 will be a better option. But keep in my mind that this may or may not be good enough for your long term plans, depending on your use-case. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX10k8 GRE tunnels
Is anyone successfully using GRE tunnels on a QFX10008 running 17.4? I configured one, and traffic works normally from the control plane, however data plane traffic seems to just get dropped. So, ping from the router itself works fine, but it won't actually route any other traffic over the tunnel. `show interfaces gr-0/0/0.0` shows that it's attempting to output packets, but they never actually arrive at the remote end of the tunnel. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
On 29 June 2018 at 13:55, Gert Doering wrote: > Hi, > > On Fri, Jun 29, 2018 at 01:49:46PM +0100, adamv0...@netconsultings.com wrote: >> Just wondering what's the latest on the GPU for packet forwarding front (or >> is that deemed legacy now)? > > Last I've heard is that pixel shaders do not map really nicely to the > work needed for packet forwarding - so it works, but the performance gain > is not what you'd expect to see. Which is to be expected right? Typical GPU instruction sets and ALUs are great for floating point operations which we don't need for packet processing. Packets typically need low complexity tasks performed at high rates. Various high end DC switches like Nexus boxes use GDDR5 RAM just as a graphics card would but the processing is done by an ASIC, which makes sense to me, that is not the place for general purpose x86 compute chips. This is a specific task. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Router for full routes
On Wed, 27 Jun 2018, Mark Tinka wrote: But to your question, there is nothing ancient about the MX240. It's just small. Look at your future needs and consider whether having those 2 line card slots running the latest-generation Trio chip will scale better than migrating to the MX204, and that should answer your question. Thanks for the detailed reply, Mark. By "ancient", I mean boxes still running RE-S-1300s, original SCBs, and either DPCs or older MPC2s -- basically, everything EOL except the chassis, and running a mix of 1G and 10G interfaces. The limited slot count isn't much of an issue, especially with the possibility of moving to at least MPC3Es with 10x10G MICs. The REs are the biggest issue, stuck on old code and not nearly enough memory. 1G interfaces are also a problem, but switches are cheap... I do like the idea of the MX204 as an edge box, currently have some MX80s in that role that wouldn't be missed. -Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Mixing v4/v6 neighbors in BGP groups
Wondering aloud a bit... I've seen plenty of cases where wedging parallel v4/v6 sessions into the same BGP group and letting the router sort out which AFI it's supposed to be using on each session works fine, and nearly as many where configuring anything family-specific starts to get ugly without splitting them into separate v4/v6 groups. Are there any particularly compelling reasons to prefer one over the other? I can think of a bunch of reasons for and against on both sides, and several ways to handle it with apply-groups or commit scripts. Curious what others are doing here. Thanks! -Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] VRF export/import of eBGP learned route
Hello everyone
Thank you so much for your suggestions. The solution in this case is to
remove the autonomous-system statement completely from the routing-instance
routing-options and apply the local-as statement under bgp with the private
knob.
protocols {
bgp {
local-as 456 loops 2 private
This creates an internal table that looks just like it would under regular
bgp inet.0.
Thanks again!
On Fri, Jun 29, 2018 at 4:07 AM Alexander Arseniev via juniper-nsp <
juniper-nsp@puck.nether.net> wrote:
> 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 lab and I'm pretty sure I saw this same issue.
> >
> > Sounds like something I saw with my internet boundary pe's, would add my
> AS
> > on routes were learned from internet and send as vpnv4 routes into my
> > internal ibgp environment and internal pe's were seeing their own AS and
> > routes were being hidden as looped...
> >
> > Try this on PE1
> >
> > If pe1 ebgp group is called "ebgp-to-ix"...
> > If IX ip that you neighbor with is 1.2.3.4...
> > If vrf on PE1 and PE2 is called "my-vrf"...
> >
> > ...do this on PE1...
> > set routing-instances my-vrf protocols bgp group ebgp-to-ix neighbor
> 1.2.3.4
> > local-as private
> >
> > ...now see if PE2 is still seeing its own AS as looped
> >
> > - Aaron
> >
> >
> > ___
> > 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] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
Hi, On Fri, Jun 29, 2018 at 01:49:46PM +0100, adamv0...@netconsultings.com wrote: > Just wondering what's the latest on the GPU for packet forwarding front (or > is that deemed legacy now)? Last I've heard is that pixel shaders do not map really nicely to the work needed for packet forwarding - so it works, but the performance gain is not what you'd expect to see. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] [c-nsp] Leaked Video or Not (Linux and Cisco for internal Sales folks)
> From: Tails Pipes [mailto:tailsnpi...@gmail.com] > Sent: Thursday, June 28, 2018 5:29 PM > > No, things changed there as well. Lookup merchant sillicon, and revise this > post every 6 months. Nah > have you heard of Barefoot networks? Yes I have heard of barefoot, but have you heard of barefoot queuing architecture or pre-classifier granularity and queuing strategy or packet size based pps performance graph, well yeah neither did I. > The days of > ASICs from Cisco are gone and we are glad, we tested the P4 DSL (cisco never > got that right with mantel) on Nexus and its wonderful. > > The asics you speak of are no longer important or valuable because people > realized that in many networking planets and galaxies, the asic is reflects > the > network design, they are related, and specifically for the data center, the > clos > fabric design won, and that does not require fancy asics. Well there are use cases for fancy asics and use cases for simple asics. > I guess your knowledge is out dated a bit. Cisco itself is using those > merchant > sillicon ASICs happily. Yup and those are dirt cheap compared to their home grown asics , this is because for a given pps rate they have lot less smarts. > (lookup Chuck's comments on nexus9000, best selling > cisco switch ever)...guess it is a good switch, because bright box pushed > cisco > to do that, and if any one on this list can disagree with me here, i'm up to > that > challenge. > > What i have discovered recently is that things happen in following way. > > Your boss or his boss picks a work culture (no one gets fired for buying > IBM/Cisco), that culture (buying the shiny suits) impacts how you do work, it > makes you select vendors (the ones that sends me to vegas every year) and > not the right network design, you select cisco and you are stuck there for > life, > because once they tell you how things should work (aka : certificates), things > are worse, now every time you make a new network purchase (afraid of new > CLI ), you will not be able to look the other way because you just dont know > any thing else (and loosing your certificate value). > Well I guess that could be a story of some of the smaller shops that can't afford investing in R and thus rely on well-trodden paths, but certainly not my problem. > I wish the culture would change to, no one got fired for buying closed but > didnt get promoted either. change requires boldness. > > https://toolr.io/2018/06/18/stop-abusing-the-word-open/ > I understand your passion for open sw and open hw architecture, but routing high pps rates on x86 will always be impractical compared to specialized asics. Yes going x86 certainly makes sense for low pps use cases - a uCPE is a good example of such a use case. And as far as the high pps rate use cases goes, reading other posts in this thread, it seems that the current state of the art with regards to any linux OS driving any white-box ASICs is not quite ready for primetime yet. A viable alternative might be the FPGA NICs -but seems still not financially attractive. Just wondering what's the latest on the GPU for packet forwarding front (or is that deemed legacy now)? adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
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 lab and I'm pretty sure I saw this same issue. Sounds like something I saw with my internet boundary pe's, would add my AS on routes were learned from internet and send as vpnv4 routes into my internal ibgp environment and internal pe's were seeing their own AS and routes were being hidden as looped... Try this on PE1 If pe1 ebgp group is called "ebgp-to-ix"... If IX ip that you neighbor with is 1.2.3.4... If vrf on PE1 and PE2 is called "my-vrf"... ...do this on PE1... set routing-instances my-vrf protocols bgp group ebgp-to-ix neighbor 1.2.3.4 local-as private ...now see if PE2 is still seeing its own AS as looped - Aaron ___ 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] VRF export/import of eBGP learned route
I don't see this issue. Does it only happen when you have a different ASN inside the VRF? On Thu, Jun 28, 2018 at 10:44:07PM -0400, Philippe Girard wrote: > Grettings > > I'm setting up this VRF that hosts the full routing table. I have other > peerings or remote PEs that import IX routes through eBGP as well. > > The problem resides on something TAC tells me is Juniper specific, which is > to add my own internal ASN to the as-path when using vrf-import to get a > route that was learned through eBGP from another router to avoid potential > loops. > > So, let's say IX has AS 123 and I have AS 456 in the VRF, and my real > inet.0 AS is 789, what is seen by another PE than the one learning the > route directly from the IX is: > > IX -- eBGP - PE1 - iBGP inet-vpn - PE2 > > Route as-path seen by PE1: 123 XXX YYY I > Route as-path seen by PE2: 456 123 XXX YYY I > > The behaviour is the same on all Junos routing devices in my core (MX + > QFX5100) and I have to configure routing-options autonomous-system 456 > loops 2 for the other peers to accept routes imported by eBGP on another > node. > > Obviously, the "real" as-path is as follows, since the AS doing the > underlay iBGP has ASN 789. > > 456 [789] 456 123 XXX YYY I > > I've tried independant domain but that makes me unable to filter any bgp > attribute in vrf-imports and exports. I've also tried an "option A" peering > between the routers and that revealed the underlay AS in the path. Using > remove-private created a loop by re-sending the learned routes towards the > edge. > > Would anybody have an idea on how to achieve the equivalent of having and > inet.0 iBGP mesh and importing routes without the own as prepending that > takes place as described? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
