Re: [j-nsp] Experience with QFX5100 13.2 14.1
On Thu, Jan 15, 2015 at 6:43 AM, Tim Jackson jackson@gmail.com wrote: L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any traffic that would have been sent an ICMP redirect (even with that turned off) will be duplicated.. One copy forwarded through the RE, one copy through T2 caused by PR1022354 (there are other scenarios that can cause this, too.. and this is still unfixed).. I think in 13.x there is an LDP bug (PR889585), but it's easy to work around. L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25 in L2 will be silently discarded (punted to the RE as you can see this traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe 13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR for that one yet. Do you have DHCPv4 enabled in any other way? Ex dhcp-relay? I ask, b/c, on an unrelated platform (nd entirely different JunOS versions- MX960s and EX9214s) we ran into - turning on dhcp-relay will cause them to punt all UDP port 67 traffic. Even if it's on an interface that isn't mentioned in the config. I haven't had a chance yet to see if that happens to all logical instances or just the LI that the dhcp-relay or dhcp features are enabled on. Like I said, unrelated platform, but, effectively the same thing. I've also had several QFX5100-96S boxes reboot without reason (on software all the way up to 14.1X53-D10), 0 logs, like they were powered off.. Still haven't found the root cause of this one yet, we're suspecting a bad batch of hardware possibly. I have several that are about to enter a mixed L2+L3/MPLS P/PE role soon.. MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there haven't been any issues outside of the previously mentioned L2 gotchas. In general the experience has been pretty positive with them outside of a few L2 snafus.. I'm also not using the boxes in a traditional DC role, these are all SP roles.. On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann richih.mailingl...@gmail.com wrote: Dear all, I was wondering what experience, if any, you have had with QFX5100. Of special interest would be what JunOS version you are running, what features you have enabled, and if you consider them production-ready. This question is open-ended on purpose. Thanks, Richard ___ 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 -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Experience with QFX5100 13.2 14.1
For DHCPv4 that was the case, but it still persisted after disabling dhcp-relay. For DHCPv6, ipv6 isn't even configured on the box. -- Tim On Fri, Jan 16, 2015 at 11:15 AM, Michael Loftis mlof...@wgops.com wrote: On Thu, Jan 15, 2015 at 6:43 AM, Tim Jackson jackson@gmail.com wrote: L3/MPLS LSR - Great experience, one issue currently in 14.1X53-D15 is any traffic that would have been sent an ICMP redirect (even with that turned off) will be duplicated.. One copy forwarded through the RE, one copy through T2 caused by PR1022354 (there are other scenarios that can cause this, too.. and this is still unfixed).. I think in 13.x there is an LDP bug (PR889585), but it's easy to work around. L2 - Several issues with it.. DHCPv4 Traffic in I think up to 13.2X53-D25 in L2 will be silently discarded (punted to the RE as you can see this traffic by doing monitor traffic).. 14.1X53-D10+ fixes this (maybe 13.2X53-D25). DHCPv6 traffic is still broken in even 14.1X53-D15, no PR for that one yet. Do you have DHCPv4 enabled in any other way? Ex dhcp-relay? I ask, b/c, on an unrelated platform (nd entirely different JunOS versions- MX960s and EX9214s) we ran into - turning on dhcp-relay will cause them to punt all UDP port 67 traffic. Even if it's on an interface that isn't mentioned in the config. I haven't had a chance yet to see if that happens to all logical instances or just the LI that the dhcp-relay or dhcp features are enabled on. Like I said, unrelated platform, but, effectively the same thing. I've also had several QFX5100-96S boxes reboot without reason (on software all the way up to 14.1X53-D10), 0 logs, like they were powered off.. Still haven't found the root cause of this one yet, we're suspecting a bad batch of hardware possibly. I have several that are about to enter a mixed L2+L3/MPLS P/PE role soon.. MC-LAG+L2+L3/MPLS+L3VPN all on a pair.. So far with testing that there haven't been any issues outside of the previously mentioned L2 gotchas. In general the experience has been pretty positive with them outside of a few L2 snafus.. I'm also not using the boxes in a traditional DC role, these are all SP roles.. On Thu, Jan 15, 2015 at 1:30 AM, Richard Hartmann richih.mailingl...@gmail.com wrote: Dear all, I was wondering what experience, if any, you have had with QFX5100. Of special interest would be what JunOS version you are running, what features you have enabled, and if you consider them production-ready. This question is open-ended on purpose. Thanks, Richard ___ 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 -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Merging routes from VRF to inet.0
Hi Guys,
I have found an answer why my rib-groups and everything is not working:
All fiddling with RIB-groups is for PE-CE, and not for PE-PE.
As the primary route is in bgp.l3vpn.0, I cannot leak from vrf.inet.0,
which is the secondary table for the route.
(If somebody asks why I can't do the leaking on the CE-PE router - there
is non. The other side of the
VPN is a contrail controller, which only speaks inet-vpn.).
I also discussed with this my SE, and they didn't had a quick answer but
have to discuss internally,
but I hope that our community here maybe also has an idea howto leak
routes received via inet-vpn to inet.0...
Thanks,
Tom
PS:
No, rib-groups between bgp.l3vpn.0 and inet.0 doesn't work, tried that
already.
Am 14/01/15 um 17:15 schrieb Chuck Anderson:
I just found this excellent post that describes how rib-groups and
auto-export work, including the differences between them. I don't
think auto-export will work for going to the main/default inet.0 table
(it relies on route-distinguishers, so it only works between VRFs),
but instance-import/export may work instead if you'd rather not use
rib-groups:
http://forums.juniper.net/t5/TheRoutingChurn/Using-rib-groups-or-auto-export-for-route-leaking/ba-p/202349
On Wed, Jan 14, 2015 at 10:52:40AM -0500, Chuck Anderson wrote:
I do this with rib-groups directly, not auto-export. You need to
mention both the VRF and inet.0 tables in the rib-group, with the VRF
one first (primary table):
Main routing-options:
routing-options {
rib-groups {
vrf_and_inet0 {
import-rib [ vrf.inet.0 inet.0 ];
import-policy my_pol;
}
}
}
You also need to add the rib-group to the direct routes, and BGP
protocol (and/or OSPF or whatever the PE-CE protocol is) inside the
VRF:
routing-instances vrf {
routing-options {
interface-routes {
rib-group {
inet vrf_and_inet0;
}
}
}
protocols {
bgp {
family inet {
unicast {
rib-group vrf_and_inet0;
}
}
}
}
}
Add other families and/or multicast as needed.
On Wed, Jan 14, 2015 at 04:01:50PM +0100, Tom Eichhorn wrote:
Hi Dave j-nsp,
I tried your example,
but it does not work - and I am a little bit helpless:
http://0bin.net/paste/lpH6zV8Pk2EXnI9L#F5xzmKZTpl9hA5QjZipHfz83-xdG6qexK4MGyM6SSCU
I also tried having an accept all import policy, but that doesn't
changed anything.
Thanks for your help,
Tom
PS: This is a MX running 12.3R5.7
Am 14/01/15 um 11:37 schrieb Dave Bell:
rib-groups is indeed the simplest way to do this. Something like this
should work for you:
routing-options {
rib-groups {
import_inet0 {
import-rib inet.0;
import-policy my_pol;
}
}
policy-options {
policy-statement my_pol {
term 10 {
from {
route-filter a.b.c.d/32 exact;
}
then accept;
}
term 30 {
then reject;
}
}
}
routing-instances {
my_instance {
routing-options {
static {
route 0.0.0.0/0 next-table inet.0;
}
auto-export {
family inet {
unicast {
rib-group import_inet0;
}
}
}
}
}
On 14 January 2015 at 09:31, Tom Eichhorn t...@wirkbetrieb.net wrote:
Hi Guys,
I am currently facing a problem,
to which I do not have currently a clean solution:
I have routes in some L3 VPN vrf, and I need to merge some of them to
inet.0,
but I have no real clue how to do that.
RIB-groups would only merge all, and tbh, I never understood rib-groups and
the
documentation is a little bit unclear how they work.
My current solution is having a lt-interface between the inet.0 and
vrf.inet.0 and speaking BGP,
but that limits the traffic volume to one PFE (yes, I could have
lt-interfaces on each PFE and do ECMP, but
that would be that dirty...)
I tried also instance-import under routing-options, but that doesn't work
for some reason, instance-export
in the vrf is not supported - this only works for virtual routers, but not
VRFs...
I also tried some bad hacks on the bgp configuration, e.g. deleting the
vrf-community before importing etc,
but all of that also did not work :(
Any hint or idea?
Thanks,
Tom
PS: For the other way round, getting the default route to the VRF, I simply
use a next-table inet.0 route in the vrf.
___
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] Merging routes from VRF to inet.0
Hi, Am 16.01.2015 um 20:49 schrieb Tom Eichhorn: I have found an answer why my rib-groups and everything is not working: All fiddling with RIB-groups is for PE-CE, and not for PE-PE. As the primary route is in bgp.l3vpn.0, I cannot leak from vrf.inet.0, which is the secondary table for the route. (If somebody asks why I can't do the leaking on the CE-PE router - there is non. The other side of the VPN is a contrail controller, which only speaks inet-vpn.). I also discussed with this my SE, and they didn't had a quick answer but have to discuss internally, but I hope that our community here maybe also has an idea howto leak routes received via inet-vpn to inet.0... From my research there is no way to leak routes that were learned via inet-vpn to inet.0 besides running routing protocols between instances. I did a dirty hack the other day where i needed to move routes from inet.0 to vrf.inet.0 and leaking was no option (do not ask) It is the other way around from your setup but the concept should be similar. I configured a static route (e.g. something from the documentation prefix or other bogus prefix) with next-table statement (in your case in inet.0 with next-table vrf.inet.0), setup BGP via lt- between the instances and used an import policy to change the next-hop to point to the prefix of the static route configured earlier. The BGP needs to be multihop or to have the accept-remote-nexthop knob configured because the next-hop is remote. You will need to be able to match the routes you want to leak/export via policy to do so. This way forwarding is done directly to/from inet.0 (without) using the lt- interface and all the bandwidth constraints it suffers. Also 1G tunneling is basically always free (on MX) even with DPCs so you will not loose any interfaces when activating tunnels. Maybe you can derive something from that for your setup. This will not work if there is already a static route with next table from vrf.inet.0 to inet.0 because the config parser will deny it for possible loops. But maybe you can use rib-groups or other leaking methods for that direction. -- Kind Regards Tobias Heister ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
