Re: [j-nsp] EX2300 Code
A note on that. Not only does the switch stop responding and needs to be power cycled, but in our case while this happens uplink ports on a redundant ring bridge BPDUs from working switches and you get a nice linerate traffic loop going. We also use those as OOB management for our MX routers and other gear, and without any l2 protection MX starts slipping and drops BGP and other important protocols while this happens. As per TAC recommendation, we've downgraded to the latest 15.X version, been stable for about a week. -Original Message- From: juniper-nsp On Behalf Of Nelson, Brian Sent: December 9, 2019 10:46 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX2300 Code If Juniper provides a version which is stable for more that a few weeks let me know. I've been chasing version upgrades for months now. Brian Nelson On 12/9/19 5:15 AM, William wrote: > Hi, > > I am in the process of getting our first stack of EX2300s ready for > production, can anyone recommend any specific versions of junos to run > on them? > > I'm not taking advantage of any advance features, just after something > stable :) > > Cheers, > > William > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Supervisor Computing Systems Support Dept of Computer Science ___ 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] Rock-solid JUNOS for QFX5100
I'd like to add to that, l2circuit hot standby needs 18+ to work, I had been waiting for some time now for 18 to be recommended to use it. Thanks for the info much appreciated! -phil -Original Message- From: Richard McGovern Sent: August 13, 2019 10:30 AM To: Philippe Girard ; Ross Halliday ; Andrey Kostin Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Rock-solid JUNOS for QFX5100 Just FYI for all, but 18.1R3-S6 is specifically needed for EVPN/VXLAN use cases with QFX5110, not so much QFX5100. For 5100 without EVPN/VXLAN 14.1x53-D[latest] is very stable AFAIK. There are no real added features/functionality for QFX5100 outside of EVPN/VXLAN, so if this is not your use case, 14.1x53 should be equivalent feature/functionality wise to 18.x. For both EX and QFX I [now] recommend staying away from 16.x or 17.x, as no added benefits. S-Releases are the new Standard 'recommended' for almost all products. For sure all EX and all QFX. Not happy with this, but it is what it is. Please also note that "TAC Recommended" is generic BEST (fewest cases, along with some deployment/downloads) from purely STABILITY point of view, and does not take into account specific use cases. Your best bet is to discuss any code upgrades with your local Juniper account team. Even if you just work only with a specific partner, that partner has a Juniper team with an SE supporting them. I am also of the firm believe that upgrade for upgrade sake or to stay most current is not always a great idea - if not broken why try to fix/change? Just FYI, Rich Richard McGovern Sr Sales Engineer, Juniper Networks 978-618-3342 I’d rather be lucky than good, as I know I am not good I don’t make the news, I just report it On 8/12/19, 11:31 AM, "Philippe Girard" wrote: Hi Ross We've recently switched our 5100s to 18.1R3-S5. 18.1 is stable with BGP/OSPF/LDP/RSVP/MPLS and LACP LAG in general. We don't use STP of any kind with the QFXs so I can't really help there. I was hesitant to upgrade to 18.X since the 5100 was still the only QFX not to have and 18 version recommended on KB21476, but recently they updated the KB to include that model, so I'd say it's pretty safe now. They've pushed out S6 in July, if I'd have to re-do it now I'd use that one instead of S5. The kind of problem you're describing sounds like what we've lived through with 14.X and VCF when we first started using these. We'd commit a change and some random ports would stop passing traffic, we'd then have to delete port config and re provision for traffic to resume. Lots of weird stuff like that kept happening until we go fed up with the architecture and moved to routed MPLS with almost no layer2 switching. Good luck. -phil -Original Message- From: juniper-nsp On Behalf Of Ross Halliday Sent: August 12, 2019 9:20 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Rock-solid JUNOS for QFX5100 Dear List, I'm curious if anybody can recommend a JUNOS release for QFX5100 that is seriously stable. Right now we're on the previously-recommended version 17.3R3-S1.5. Everything's been fine in testing, and suddenly out of the blue there will be weird issues when I make a change. I suspect maybe they are related to VSTP or LAG, or both. 1. Add a VLAN to a trunk port, all the access ports on that VLAN completely stopped moving packets. Disable/delete disable all of the broken interfaces restored function. This happened during the day. I opened a JTAC ticket and they'd never heard of an issue like this, of course we couldn't reproduce it. I no longer recall with confidence, but I think the trunk port may have been a one-member LAG (replacement of a downstream switch). 2. New trunk port (a two-port LACP LAG) not sending VSTP BPDUs for some VLANs. I'm not sure if it was coincidence or always broken as I had recently began feeding new VSTP BPDUs (thus the root bridge changed) before I even looked at this. Other trunk ports did not exhibit the same issue. Completely deleted the LAG and rolled back to fix. This was on a fresh turnup and luckily wasn't in a topology that could form a loop. Features I'm using include: - BGP - OSPF - PIM - VSTP - LACP - VRRP - IGMPv2 and v3 - Routing-instance - CoS for multicast - CoS for unicast - CoS classification by ingress filter - IPv4-only - ~7k routes in FIB (total of all tables) - ~1k multicast groups There are no automation features, no MPLS, no MC-LAG, no EVPN, VXLAN, etc. These switches are L3 boxes that hand off IP to an MX core. Management is in the default instance/table, everything else is in a routing instance. These boxes have us scared to touch them outside of a window as seemingly basic changes risk blowing the whole thing up.
Re: [j-nsp] Rock-solid JUNOS for QFX5100
Hi Ross We've recently switched our 5100s to 18.1R3-S5. 18.1 is stable with BGP/OSPF/LDP/RSVP/MPLS and LACP LAG in general. We don't use STP of any kind with the QFXs so I can't really help there. I was hesitant to upgrade to 18.X since the 5100 was still the only QFX not to have and 18 version recommended on KB21476, but recently they updated the KB to include that model, so I'd say it's pretty safe now. They've pushed out S6 in July, if I'd have to re-do it now I'd use that one instead of S5. The kind of problem you're describing sounds like what we've lived through with 14.X and VCF when we first started using these. We'd commit a change and some random ports would stop passing traffic, we'd then have to delete port config and re provision for traffic to resume. Lots of weird stuff like that kept happening until we go fed up with the architecture and moved to routed MPLS with almost no layer2 switching. Good luck. -phil -Original Message- From: juniper-nsp On Behalf Of Ross Halliday Sent: August 12, 2019 9:20 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Rock-solid JUNOS for QFX5100 Dear List, I'm curious if anybody can recommend a JUNOS release for QFX5100 that is seriously stable. Right now we're on the previously-recommended version 17.3R3-S1.5. Everything's been fine in testing, and suddenly out of the blue there will be weird issues when I make a change. I suspect maybe they are related to VSTP or LAG, or both. 1. Add a VLAN to a trunk port, all the access ports on that VLAN completely stopped moving packets. Disable/delete disable all of the broken interfaces restored function. This happened during the day. I opened a JTAC ticket and they'd never heard of an issue like this, of course we couldn't reproduce it. I no longer recall with confidence, but I think the trunk port may have been a one-member LAG (replacement of a downstream switch). 2. New trunk port (a two-port LACP LAG) not sending VSTP BPDUs for some VLANs. I'm not sure if it was coincidence or always broken as I had recently began feeding new VSTP BPDUs (thus the root bridge changed) before I even looked at this. Other trunk ports did not exhibit the same issue. Completely deleted the LAG and rolled back to fix. This was on a fresh turnup and luckily wasn't in a topology that could form a loop. Features I'm using include: - BGP - OSPF - PIM - VSTP - LACP - VRRP - IGMPv2 and v3 - Routing-instance - CoS for multicast - CoS for unicast - CoS classification by ingress filter - IPv4-only - ~7k routes in FIB (total of all tables) - ~1k multicast groups There are no automation features, no MPLS, no MC-LAG, no EVPN, VXLAN, etc. These switches are L3 boxes that hand off IP to an MX core. Management is in the default instance/table, everything else is in a routing instance. These boxes have us scared to touch them outside of a window as seemingly basic changes risk blowing the whole thing up. Is this a case where an ancient version might be a better choice or is this release a lemon? I recall that JTAC used to recommend two releases, one being for if you didn't require "new features". I find myself stuck between the adages of "If it ain't broke, don't fix it" and "Software doesn't age like wine". Given how poorly multicast seems to be understood by JTAC I'm very hesitant to upgrade to significantly newer releases. If anybody can give advice or suggestions I would appreciate it immensely! Thanks Ross ___ 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] l2circuit between QFX-5110 & MX204 - one way traffic
Hello
Some important information:
Top level encapsulation flex-eth and flex-vlan-tagging is not supported on
QFabric (QFX family) devices. That means you can't use a port that does ccc
with any other type of encap, i.e. vlan-bridge, ext-vlan-br, or set family inet
on a unit. Only MX with trio chipset can do that. If you did at *any other
point* configure some other units on there with different encaps, traffic will
remain one way. There is also a PR on the use of flex stuff on QFX that states
that at some points labels are not getting programmed properly and circuit will
stop working.
You don't need family ccc in the unit, only encap vlan-ccc
You should remove and RSVP-TE and static LSP config that you have to start
fresh and make it work only with LDP, then add complexity.
The pop/push operation on the unit is there to get a pure ethernet frame to
slap the LDP tag onto and possibly deliver untagged on the other side. It's not
necessary if you also deliver on a simple tagged unit on the other side. The
difference in the core network will be between ETHERNET-CCC and VLAN-CCC. You
don't need to force the encasulation type in config, this is automatic from
what you set on both sides.
Also, don't do ignore-mtu, but set the mtu to what you want as a value lower
than the physical interface mtu, the same on both sides.
I don't think QFX supports control-word.
Examples of what works:
Xe-X
vlan-tagging;
mtu 9216;
encapsulation vlan-ccc;
unit 538 {
encapsulation vlan-ccc;
no-traps;
vlan-id 538;
input-vlan-map pop;
output-vlan-map push;
}
interface xe-0/0/36.538 {
virtual-circuit-id 13911065;
no-control-word;
mtu 9000;
}
If you do use pop/push on the unit, make sure it's there on both sides. You can
also deliver untagged on the other side by doing something like this. It will
push the frame out untagged since you removed it accepting the packet
initially. Keep in mind this dedicates the port to that service.
mtu 9216;
encapsulation ethernet-ccc;
unit 0 {
no-traps;
family ccc;
}
interface xe-0/0/12.0 {
virtual-circuit-id 1385956;
no-control-word;
mtu 9000;
}
MX can have top flex-ethernet and flex-vlan tagging and mix and match stuff.
For the rest, config must stay the same.
Keep your stuff simple, leave as much as you can to the system to figure out
unless you absolutely need to force.
Cheers.
-Original Message-
From: juniper-nsp On Behalf Of Liam Farr
Sent: July 18, 2019 11:26 AM
To: Heng Chai, Tan
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] l2circuit between QFX-5110 & MX204 - one way traffic
Hi,
Tried as follows;
liam@NA-QFX5110-1# show interfaces xe-0/0/9 description "Temp Link to Arista";
vlan-tagging; mtu 9216; encapsulation flexible-ethernet-services; unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map pop;
output-vlan-map push;
family ccc;
}
liam@NA-QFX5110-1# show protocols l2circuit neighbor 192.168.68.3 {
interface xe-0/0/9.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
liam@WN-MX204-1# show interfaces xe-0/1/3 description "ISPCO-WN-PVE-1 C0/F3
enp6s0f1"; flexible-vlan-tagging; mtu 9216; encapsulation
flexible-ethernet-services; unit 123 {
encapsulation vlan-ccc;
vlan-id 123;
input-vlan-map push;
output-vlan-map pop;
family ccc;
}
liam@WN-MX204-1# show protocols l2circuit neighbor 192.168.68.5 {
interface xe-0/1/3.123 {
virtual-circuit-id 123;
no-control-word;
ignore-mtu-mismatch;
pseudowire-status-tlv;
}
}
When I removed the l2circuit encapsulation altogether from both ends I got an
EM -- encapsulation mismatch on the l2circuit
I also tried encapsulation internetworking / ethernet-vlan / ethernet
At some point I did get mac learning both ways in that at the QFX end I could
see mac from the MX end, but haven't successfully managed to pass icmp / ping.
NA-ARISTA#show mac address-table vlan 123
Mac Address Table
--
VlanMac Address TypePorts Moves Last Move
--- - - -
1233606.b737.b463DYNAMIC Et91 0:18:11 ago
1236c3b.6bf0.9b0fDYNAMIC Et41 8:55:37 ago
Total Mac Addresses for this criterion: 2
Multicast Mac Address Table
--
VlanMac Address TypePorts
--- -
Total Mac Addresses for this criterion: 0
I've got an option to borrow a QFX-5110 tomorrow and set it up in a bit better
of a LAB config with a MX I have locally, where I can break things a bit more
without affecting prod traffic. That might be the go and rebuild some
l2circuits from scratch.
Re: [j-nsp] Tail drop on EX3400
Thanks everyone for your input, very interesting. Reality is, we have ~300Mbps coming in the 10G port and ~50-100Mbps per customer port at peaks, really, not that much. Also, although tweaking TCP is nice, I can hardly go to each customer of mine telling them to augment their TCP window settings because they're triggering monitoring on my side. I'm still very much unsatisfied with what JTAC told me, even with all my very precise questions, I get few detailed answers and get told to increase buffer allocation to 100% in COS. I'll give that the shot after hours today. One thing that bugs me though is looking at default schedulers, still only 75% of buffer space is allocated to best effort traffic, so I'd still get only 3/4 of the actual 100% allocation, and since I'm not getting the answers I want, I don't know what the default allocation is VS that 100% they want me to configure, so I have no idea of the actual increase this will generate. My guess is that I'll have to create a custom scheduler and apply to interfaces to be able to have all that buffer space available for basic Internet... - Philippe Girard On Thu, May 30, 2019 at 9:27 AM Jason Healy wrote: > On May 30, 2019, at 2:23 AM, Saku Ytti wrote: > > > > 12MB / 1Gbps == 96ms. That would be massive buffer. > > Not if you're Arista... ;-) > > You're correct that it's 96ms for the 1Gbps side, but if packets are > arriving at 10Gbps then that's only 9.6ms (ish) before you run out of > buffer. It's the mismatch in speed more than the actual buffer itself > (assuming we're talking about megabytes of buffer, not gigabytes). > > For steady state at a rate less than 1Gbps, the switch has enough buffer > to handle the packets in flight. However, if packets arrive in microbursts > then you can exceed the buffer briefly even though the amount of traffic is > low on a larger timescale. 15MB of traffic evenly spread out over one > second is not an issue, but 15MB of traffic arriving at 10Gbps at the start > of a second, even with the rest of the second unused, is enough to overflow > a buffer. Both rates are "15MB/s", but the arrival rate makes a huge > difference. > > I've certainly seen tail drops on interfaces in bursts like this where it > quiets down very quickly, but is enough to trip monitoring alarms. We've > maxed out the buffer configs on specific ports and haven't been able to > eliminate the issue (not sure if it's reduced, as it's relatively > infrequent). > > Jason > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Tail drop on EX3400
Hi Been going back and forth with JTAC on an output drop issue. I have two ex3400-48t in a VC configuration and I got some ports reporting tail drop from time to time, but lately one customer pulling max 80m on a 1000M connection is generating some level of drops all day long. No complaints yet but enough for monitoring to trigger. The suggesting from TAC is to configure class-of-service shared-buffer percent 100. I'm used to QFX5k switches allowing you to clearly see the allocation and change it a bit, but this really isn't clear to me when I run // show system buffers or show interfaces queue, etc. I've been trying to ask, what's the default precentage allocation? Where does the rest of the unclaimed percentage live while it's not explicitely called for? Does calling out 100% take it away from ingress or some other important queue? Is round robin possible by configuring class-of-service? Would it avoid dedicating 100% of something to just one direction? I've asked all of those questions but I can't seem to get a clear answer. Thanks for your help. - Philippe Girard ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Junos 18.X on QFX5100
Thanks everyone for the advice, I went with 18.1R3-S5, it's been pretty stable and I didn't see any CPU abuse so far. - Philippe Girard 514-895-0877 On Tue, May 28, 2019 at 8:31 AM Franz Georg Köhler wrote: > On Sun, May 26, 2019 at 03:15:48PM +0200, Thomas Bellman < > bell...@nsc.liu.se> wrote: > > > > So far, the only problem I have seen is that the Jet Service Daemon > > (jsd) and the na-grpc-daemon starts eating 100% CPU after a few weeks > > on 18.3, but not the other versions. Restarting them helps; for a > > few weeks, then they suddenly eat CPU again. It should also be possible > > to disable them if you don't use them (I haven't gotten around to do > > that myself, though). > > We see the same behaviour with 18.3R1 and regularily need to kill jsd > and na-grpc-daemon. > > We run 18.2 to 19.1 and see those processes eating up CPU only on > 18.3R1. > > We see some IPV6 problems in a VC environment, i.E. PR1413543 and > PR1370329 (RA not working) > > We also see problems in IPV6 forwarding, when connected hosts would not > be able to reach the outside until they either ping the IRB gateway or > traffic comes in from the outside. > > > > > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Junos 18.X on QFX5100
Greetings Anyone running production Junos 18.X on QFX5100? JTAC recommended still says 17.3R3-S4 but I'd really like to jump to 18 for some new features it offers. Thanks for your help. - Philippe Girard ___ 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] 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
[j-nsp] VRF export/import of eBGP learned route
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? Thanks Phil. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
