Re: [j-nsp] JFlow / IPFIX / Mac Addresses, IX Fabrics
You can also do v9, but that comes with a load of restrictions. Better to do ipfix IMO. L2 info is only grabbed off of L2 interfaces if I remember correctly. Dan https://www.juniper.net/documentation/en_US/junos/topics/concept/inline-sampling-overview.html On Fri, Dec 29, 2017 at 1:01 PM John Brown wrote: > Hello all you wonderful JUNOS geeks :) > Happy New Year! > > Couple of quick questions: > > Current platform > MX480 > RE-1800x4 > MPC3-3D > MPC2-3D > 1Gig and 10Gig MIC's > SCBE > > Wanting to get flow data for both IPv4 and IPv6. Seems I need IPFIX > for this > > I'm also trying to get MAC addresses into my flows so that I can sort out > which peer at a shared IX fabric (Think Equinix IBX, or LINX) is sending me > packets of love. > > I'm ingesting into ELK and similar OS tools. > Would like to do 1:1 for good resolution. > The data is for security, forensics, historical, troubleshooting, back > tracing DDOS, etc. > > Any tips / suggestions / sample configs would be greatly appreciated. > > Thanks.. > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Anyone uses Adaptive Load Balancing?
Same. Worked fine on 4x10Gb ring with large research flows. On Mon, Nov 20, 2017 at 7:11 AM, Michael Hare wrote: > Alex- > > I've used it AS wide in 14.1 for ~2+ years without observing any negative > side effects. My main driver was a connector's SAN replication MPLS > service across an Nx10 bundle mixed with regular IP traffic with the SAN > wanting to be one big flow. > > -Michael > > >>-Original Message- > >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > >>Of Alex K. > >>Sent: Saturday, November 18, 2017 1:09 AM > >>To: serge vautour > >>Cc: juniper-nsp > >>Subject: Re: [j-nsp] Anyone uses Adaptive Load Balancing? > >> > >>Hello Serge and thank you. > >> > >>Yes, there are indeed, not that many cases for ALB. That's why I turned > to > >>community. > >> > >>Thank you for sharing your experience. > >> > >>בתאריך 18 בנוב' 2017 1:41 AM, "serge vautour" > >> > >>כתב: > >> > >>> Hello, > >>> > >>> We have been using it for a while. Works great. We have a few small > links > >>> in a LAG bundle with a small number of fat flows over them. Without > >>> adaptive LAG the flows would sometimes hash on the same link. With > >>adaptive > >>> LAG they are always split. > >>> > >>> I agree that there probably aren't many use cases for this. We ran into > >>> one and this solution worked. > >>> > >>> Serge > >>> > >>> > >>> On Fri, Nov 17, 2017 at 6:36 PM, Alex K. wrote: > >>> > Hello everyone, > > A customer of mine, is looking forward for a technology able to load > balance a traffic across a LAG. > > The LAG in question comprised of Ethernet link and can grow from a few > links (4) to say, 20 - as required bandwidth grows. The gear is MX > boxes. > > Since I'm familiar with adaptive load balancing but never used it > myself, > I'll glad if someone here can share his/her experience using it? Can > it > deliver pretty good load balancing across a LAG between routers? Is it > stable? Is there any caveats one should avoid? Anything else we should > consider, before deploying this thing into production? Feel free to > share > (off list/on list) your experience and everything else you think > relevant. > > Thank you. > ___ > 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] l2circuit down one side/up another
Also, after your physical change, was ospf/isis up on both sides? On Fri, Oct 20, 2017 at 6:12 AM Daniel Rohan wrote: > Did you change any of the physical interfaces as part of your topology > change? And if so, is family mpls configured on that new port? Is that new > port configured under protocols ldp and protocols mpls along with the > loopback used for signaling? > > Do your control plane filters still permit ldp on both ends? > > > > Dan > > On Fri, Oct 20, 2017 at 3:26 AM Caio wrote: > >> Hello people, >> >> There's a weird problem I would like to share with you. >> I have the following scenario: >> >> MX104 -> L2 SW (1) -> L2 SW (2) -> MX80 >> >> Both L2 SW are Extreme X460 and they're doing nothing except forwarding >> frames at layer 2. >> >> In order to simplify our topology, we have changed the MX104 uplink to L2 >> SW (2) so the topology went to MX104 -> L2 SW (2) -> MX80. >> >> After that, the BGP sessions went up and all the traffic has returned as >> expected, however I have three l2circuit connections (vlan-ccc mode) and >> they went to "Down (OL)" status at one side and Up at another. In order to >> reestablish them we had to do a rollback of the physical changes we did. >> >> As it just don't make any sense to me, I summon you experts to help me >> with >> that, so we can try to figure out what went wrong. >> >> Additional details: I'm using LDP signaling at both sides. It' a point to >> point L3 connection, so I have the loopback interfaces configured at both >> sides and a /30 between them, also I have static routes to reach their >> loopback interface's addresses. >> >> Any help will be appreciated. >> >> Cheers, >> Caio >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp >> > -- > Thanks, Dan > -- Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] l2circuit down one side/up another
Did you change any of the physical interfaces as part of your topology change? And if so, is family mpls configured on that new port? Is that new port configured under protocols ldp and protocols mpls along with the loopback used for signaling? Do your control plane filters still permit ldp on both ends? Dan On Fri, Oct 20, 2017 at 3:26 AM Caio wrote: > Hello people, > > There's a weird problem I would like to share with you. > I have the following scenario: > > MX104 -> L2 SW (1) -> L2 SW (2) -> MX80 > > Both L2 SW are Extreme X460 and they're doing nothing except forwarding > frames at layer 2. > > In order to simplify our topology, we have changed the MX104 uplink to L2 > SW (2) so the topology went to MX104 -> L2 SW (2) -> MX80. > > After that, the BGP sessions went up and all the traffic has returned as > expected, however I have three l2circuit connections (vlan-ccc mode) and > they went to "Down (OL)" status at one side and Up at another. In order to > reestablish them we had to do a rollback of the physical changes we did. > > As it just don't make any sense to me, I summon you experts to help me with > that, so we can try to figure out what went wrong. > > Additional details: I'm using LDP signaling at both sides. It' a point to > point L3 connection, so I have the loopback interfaces configured at both > sides and a /30 between them, also I have static routes to reach their > loopback interface's addresses. > > Any help will be appreciated. > > Cheers, > Caio > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX for subscriber aggregation
Ross, You might want to try searching the archives for ACX. A few of us have posted the good, the bad, the ugly. TL;DR: look at the ASR920. Dan On Monday, October 31, 2016, Ross Halliday < ross.halli...@wtccommunications.ca> wrote: > Hi list, > > We run a bunch of fixed wireless broadband towers where we bring MPLS > right to the site. Subscribers are terminated right there. Today we use > Cisco 7301 in a PPPoE LAC capacity for dynamic subscribers and deal with > BGP sessions to higher end customers that have managed CE. > > We're looking at the ACX1100 to replace said 7301 and additional switches. > Because of the lack of PPPoE-related features we're considering using DHCP > for subscriber access. > > Does anyone have any experience with the ACX routers doing this kind of > thing? Particularly the DHCP relay side, features supported in IRBs, and > practical experience with the MPLS features is what I'm wondering about. > We'd load it up with maybe half a dozen VRFs. > > > Thanks! > Ross > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ldp transport address 0.0.0.0
You already check that you're allowing ldp and rsvp through on your lo0 control plane filter? On Tuesday, August 9, 2016, Mohammad Salbad wrote: > yes it is, and as I mentioned before mpls lsp is already up between the acx > and mx and carrying traffic, I want the ldp only between the nodes loopback > addresses for l2circuits and I'm not using it for mpls transport, noting > that I'm using rsvp for signling and mpls transport > > On 9 August 2016 at 14:00, BESSALA TSALA Mathurin > wrote: > > > Hi, > > Does each lo0 @ IP is visible via ISIS ? > > On 8 Aug 2016 12:59, "Mohammad Salbad" > wrote: > > > >> Hi experts > >> > >> I have mx and acx routers both running isis and rsvp and I have mpls lsp > >> configured between their loopbacks. > >> when trying to establish ldp and l2circuits it does not work and when I > do > >> show ldp neighbor details from both sided it gives me trasport address > >> 0.0.0.0 > >> noting that I have almost similar setup in my lab and it is working! > >> any ideas what could make the transport address to be 0.0.0.0 while the > >> neighbor address is ok? > >> ___ > >> 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 > -- Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ACX5048 - protect remote access (telnet, ssh, http, snmp)
BTW, this appears to now be fixed in 12.3X54-D25.7. ne@ACX1000-lab# load set terminal [Type ^D at a new line to end input] set firewall family inet filter local_acl term terminal_access from address 172.17.143.0/24 set firewall family inet filter local_acl term terminal_access from protocol tcp set firewall family inet filter local_acl term terminal_access from port ssh set firewall family inet filter local_acl term terminal_access from port telnet set firewall family inet filter local_acl term terminal_access then accept set firewall family inet filter local_acl term terminal_access_denied from protocol tcp set firewall family inet filter local_acl term terminal_access_denied from port ssh set firewall family inet filter local_acl term terminal_access_denied from port telnet set firewall family inet filter local_acl term terminal_access_denied then log set firewall family inet filter local_acl term terminal_access_denied then reject set firewall family inet filter local_acl term default-term then accept set interfaces lo0 unit 0 family inet filter input local_acl load complete [edit] ne@ACX1000-lab# commit check configuration check succeeds [edit] ne@ACX1000-lab# run show version Hostname: ACX1000-lab Model: acx1100 JUNOS Crypto Software Suite [12.3X54-D25.7] JUNOS Base OS Software Suite [12.3X54-D25.7] JUNOS Kernel Software Suite [12.3X54-D25.7] JUNOS Base OS boot [12.3X54-D25.7] JUNOS Packet Forwarding Engine Support (ACX) [12.3X54-D25.7] JUNOS Online Documentation [12.3X54-D25.7] JUNOS Routing Software Suite [12.3X54-D25.7] [edit] ne@ACX1000-lab# On Sat, Apr 2, 2016 at 2:59 AM, Mark Tinka wrote: > > > On 2/Apr/16 11:04, Saku Ytti wrote: > > > > > I've always wondered why is this a hard problem, especially in low > > end? Naively I'd think that from your ASIC waste one revenue port as > > host-bound facing and implement normal port ACLs there. > > It is exactly for that reason. Vendors will assume all low-end > requirements place more emphasis on cost than security (however basic) > or generally well-practiced network operational requirements. > > They'll further justify it by saying, "If you want all the bells & > whistles, we have box for that". > > Mark. > ___ > 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] flow collisions?
Hi all: Can anyone help me define some of these counters I'm seeing on our FPCs? When I run request pfe execute target fpc2 command "show jnh 0 sample-inline statistics ipv4" SENT: Ukern command: show jnh 0 sample-inline statistics ipv4 GOT: GOT: GOT: Protocol:2 GOT: Flow Packet Count :5789149275620 GOT: Flow Byte Count :5673740587208686 GOT: Total inserted Flows:176810413029 GOT: Total deleted Flows :176793898277 GOT: Inactive Timed Out Flows:162771518964 GOT: Active Timed Out Flows :14023413845 GOT: Active Flows:16514752 GOT: Export Packet Count :34359297776 GOT: Flows Exported Count:171053892730 GOT: Flow Collision Error:12960957608 GOT: Flow Insert Error :243576966918 GOT: Flow Delete Error :0 GOT: AS Lookup Error :1968 GOT: RR Lookup Error :151348580782 GOT: Flow Export Error :0 GOT: Flow insert Policer Drops :278853233 LOCAL: End of file Flow insert Policer Drops, AS Lookup Error, RR Lookup Error, Flow Collision Error, Flow Insert Error are all incrementing. I can kind of infer what these mean if I think of a flow export table that fills up with flow data and then is sent off in a record to the collector (ie, policer makes sure the table capacity is never overrun), but am completely clueless about flow collisions, insert errors RR Lookup Errors (what's a route reflector got to do with exporting IPFIX?) and whether or not my assumptions about the table and policers are right or wrong. Googling these doesn't really turn up much aside from old j-nsp posts where most folks seem as confused as I as to what precisely these mean. Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] RSVP signaled LSPs across LACP bundles
Hi all, Quick question for those who might have run across this. I have a 4x10Gb backbone based on Juniper MX routers. The 10Gb interfaces are LAG'd with LACP using the default layer4 hash. It works wonderfully under normal conditions. I'm using RSVP to signal dedicated LSPs for a bunch of pseudowires/l2circuits across our network. The bandwidth for a few of these pseudowires is as high as 10Gbps. When one of the 10Gb LSPs starts to get close to 9.4 or 9.5 Gbps of utilization, we start to see other customer traffic drop, RTT latency increase etc. The 10Gb flow starts to drop packets as well. The cause appears to be obvious: the 10G flow is getting hashed onto one of my four links in the LACP bundle, and there it stays (it's a single TCP session). Any other customer traffic that is unlucky enough to be hashed onto that link contends with that mammoth flow and everyone loses. I'm trying to find a way to work around this and looking for ideas. Per-packet spray hashing is not an option. Would adaptive load balancing help? Something else? I'm trying to avoid the scenario where I have to dedicate specific 10Gb links just for these bursty psuedowires in order to protect other traffic. That seems regressive, although the remainder of this customer traffic *would* handily fit on a 30Gb LACP bundle. -Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] vMX availability
The good advice I got when I asked this question a few months back was "talk to your SE". I did, and it was fruitful. On Thu, Apr 30, 2015 at 12:35 PM, Chris Chance wrote: > Was wondering the same > > Sent from my BlackBerry 10 smartphone. > From: Josh Baird > Sent: Thursday, April 30, 2015 3:28 PM > To: juniper-nsp@puck.nether.net > Subject: [j-nsp] vMX availability > > > Does anyone know if vMX is out in the wild yet? I was under the impression > that lab/trial versions would be available through re-sellers in early > March, but I haven't had any luck getting my hands on anything. > > Josh > ___ > 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] Broken/trashed/junk Juniper MX5/80 and Cisco 2921 chassis?
Hey all, Sorry for the x-post with NANOG, but I'm looking for something that seems to be a bit hard to find and I'm hoping that someone in the larger community might be able to help. I'm trying to find a totally broken, cheap, MX5/80 and a Cisco 2921 chassis that I can use for demonstration trainings with our edge technicians. We're currently running the demos with spare gear, but even though we transport this gear in shock-mounted cases, I'd much rather be transporting dummy equipment. Our SEs don't have a line on this kind of gear either. Aparently this type of gear is destroyed or refurbished, but there isn't much demand for broken equipment sitting around staying broken. If you have a line on some of this gear that you'd be willing to share, I'd appreciate it. Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] VMX: Available or not?
Has anyone gotten their hands on a VMX license? My reseller isn't getting traction on a timeline or definitive pricing. I'm thinking through options for a deployment lab and the VMX seemed like it *might* be ideal assuming that the pricing wasn't through the roof. I don't want to use an Olive because of all of the features that don't work in that environment. We'd like to have the lab as true to life while still remaining virtual. Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MVPN and anycast-rp
Hi all, We currently run anycast-rp in our master routing instance. As such, we maintain a full mesh of MSDP between all of the RPs. I'm looking to integrate internet multicast into an L3VPN and wondering if I can get the same functionality out of the Juniper MVPN protocol/config chunk. Ie, will the 'set routing-instances blah protocols mvpn' configuration stanza provide the same functionality as a full mesh of MSDP within the VRFs, or do I need to re-create the full-mesh in order to keep anycast-rp state consistent within the context of a bgp mvpn? I can't seem to find any documentation that speaks to this point specifically. Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Strategies for migrating lots of customers into L3VPN / route-leaking
Hi all, I'm working on virtualizing a regional network with about 500 customer sites into an L3VPN. All of my customer routes (plus our internet routes) currently exist in inet.0 on our routers. The end-state I’d like to achieve is to have our provider's Internet routes isolated into a VRF and our customers isolated into their own VRF with vrf-import policies leaking the routes between the two. Before someone asks “why?” I’ll just stop that and say that it’s likely that in the near future I’ll have different customer classes demanding different upstream providers on the same physical gear but still wanting the same path/latency to the other customer classes we provide today. So- I’d like to move our customer routes piecemeal into a VRF in as controlled a way as possible without causing network segmentation or having to constrain traffic through specific paths. That way we could move reasonable sections of the network into the L3VPN over a period of a few weeks. My first thought was to set up route leaking between the VRFs and inet.0, but looking back at a recent threads on j-nsp as well as Juniper docs, I realize it's not possible to export MP-BGP learned routes into inet.0 using rib groups. I'm currently looking into using bgp between lt interfaces on inet.0 and a vrf to accomplish the route sharing, and that seems like a good possibility, but I’m curious about a few things: 1) Does anyone run production traffic through lt interfaces between inet.0 and routing instances? (we’re using fairly lightly-loaded MX480s) 2) Does any one have a smarter strategy that I could borrow to accomplish this transition? It all feels so kludge-y and brittle. -Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Identifying the egress interface for a flow using LACP
Hi all, I seem to remember a great thread where someone asked how to identify which interface from a LAG or LACP group a flow would take or is taking based upon the tupple. IIRC, the answer provided was involved and included some hidden pfe execute commands, but I could be wrong. In any case, I can't find the thread. Does anyone know how to do this? Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Dear Juniper...
I have to agree, but from a different angle. The "How Do We" section made me laugh out loud, so filled with buzzwords: 'multi-dimensional core' 'super-core', 'service-centric'. Better question is "how do I make sense of what question is being asked here without reading each and every article?" I actually didn't have any trouble getting to the spec sheets of the products I care most about though. On Thu, Sep 25, 2014 at 12:25 PM, Michael Loftis wrote: > Your web site now sucks rocks. Like who decided to ship this? One > single page for the entire EX switch lineup? Can't find CRAP anymore. > > Seriously? Did ANYONE think about actually USING the site, or did you > just say "make it preettyyy"? > > > > -- > > "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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] LDP + RSVP & DSCP
Would anyone running LDP + RSVP + QoS on their network mind contacting me on or off list to share their experiences? I'm contemplating a design that would involve using LDP for L3VPNs and RSVP for some minor traffic engineering + L2 services on a small (10 router) ring topology. The reason I'd like to use LDP is because one of the L3VPNs would have a presence on every single router on the ring and setting up a full RSVP mesh seems cumbersome, and the RSVP auto-mesh features seem poorly documented on Juniper's end. But my major concerns are with QoS; it would appear that RSVP lends itself to an IntServ set up, but to keep consistent with the way we run a few other networks, I'd like to keep a standard DS environment on this backbone. My concern is that I can't find resources that talk specifically on how to make RSVP DSCP aware short of setting up a DS-TE RDM/MAM environment, and I don't want to get into a situation where one signaling protocol isn't aware of the traffic on the links. Maybe someone on this list will have a pointer or two. Thanks, Dan ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
