Re: [j-nsp] MIC-3D-4XGE-XFP in a MX104?
On 4/Dec/17 12:26, Eric Van Tol wrote: > Also seems odd the 4-port MIC is listed as compatible on the MX80/MX104 on > the Hardware Compatibility List. This is why I put zero trust in these sorts > of tools when building systems. I can confirm that the MIC doesn't even show > up in the hardware listing if you install it into an MX80. This must have been a recently-introduced bug. I distinctly recall the 4-port MIC not being supported for the MX80 back in the day. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5100 ACLs
My version words bit differently: + Total TCAM entries available: 566 + Total TCAM entries needed : 424 Even when it is not programmed, it does say 'Programmed: YES', at least for me. But for me if needed > available, it has been accurate to predict if or not it's been correctly programmed. So indeed does not seem to be TCAM exhaustion issue in your case. On 4 December 2017 at 22:51, Brendan Mannella wrote: > + Programmed: YES > + Total TCAM entries available: 1788 > + Total TCAM entries installed : 516 > > Brendan Mannella > > TeraSwitch Inc. > Main - 1.412.945.7045 > Direct - 1.412.945.7049 > eFax - 1.412.945.7049 > Colocation . Cloud . Connectivity > > > > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the sender. Please note that any views or opinions presented in this > email are solely those of the author and do not necessarily represent > those of the company. Finally, the recipient should check this email > and any attachments for the presence of viruses. The company accepts > no liability for any damage caused by any virus transmitted by this > > On Mon, Dec 4, 2017 at 11:57 AM, Saku Ytti wrote: >> >> Hey Brendan, >> >> This is news to me, but plausible. Can you do this for me >> >> start shell pfe network fpc0 >> show filter >> >> show filter hw show_term_info >> >> Compare how many TCAM entries are needed, and how many are available. >> >> Also if you can take a risk of reloading the FPC run: >> show filter hw show_terms_brcm >> >> This may crash your PFE, if you actually did not have all of the >> entries programmed in HW. >> >> >> commit will succeed if you build filter which will not fit in HW, >> there should be syslog entry, but no complain during commit. You will >> end up having no filter or some mangled version of it. So it's just >> alternative theory on why you may be accepting something you thought >> you aren't. >> >> >> On 4 December 2017 at 18:02, Brendan Mannella >> wrote: >> > Hello, >> > >> > So i have been testing QFX5100 product for use as a core L3 >> > switch/router >> > with BGP/OSPF. I have my standard RE filter blocking various things >> > including BGP from any unknown peer. I started to receive errors in my >> > logs >> > showing BGP packets getting through from hosts that weren't allowed. >> > After >> > digging around i found that Juniper apparently has built in ACL to allow >> > BGP, which bypasses my ACLs, probably for VCF or something.. Is there >> > any >> > way to disable this behavior or does anyone have any other suggestions? >> > >> > root@XXX% cprod -A fpc0 -c "show filter hw dynamic 47 show_terms" >> > >> > Filter name : dyn-bgp-pkts >> > Filter enum : 47 >> > Filter location : IFP >> > List of tcam entries : [(total entries: 2) >> > Entry: 37 >> > - Unit 0 >> > - Entry Priority 0x7FFC >> > - Matches: >> > PBMP 0x0001fffc >> > PBMP xe >> > L4 SRC Port 0x00B3 mask 0x >> > IP Protocol 0x0006 mask 0x00FF >> > L3DestHostHit 1 1 >> > - Actions: >> > ChangeCpuQ >> > ColorIndependent param1: 1, param2: 0 >> > CosQCpuNew cosq: 30 >> > Implicit Counter >> > Entry: 38 >> > - Unit 0 >> > - Entry Priority 0x7FFC >> > - Matches: >> > PBMP 0x0001fffc >> > PBMP xe >> > L4 DST Port 0x00B3 mask 0x >> > IP Protocol 0x0006 mask 0x00FF >> > L3DestHostHit 1 1 >> > - Actions: >> > ChangeCpuQ >> > ColorIndependent param1: 1, param2: 0 >> > CosQCpuNew cosq: 30 >> > Implicit Counter >> >] >> > ___ >> > juniper-nsp mailing list juniper-nsp@puck.nether.net >> > https://puck.nether.net/mailman/listinfo/juniper-nsp >> >> >> >> -- >> ++ytti > > -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.
Hi Steinar,
I am using about the same settings from IPv4 with IPv6 just changing the
template version..
About the flow monitoring settings I as using the same one as you can see
below on IPv4 with IPv6, the current one was done after some tests...
sampling {
traceoptions {
file ipfix.log size 10k;
}
instance {
FLOW-INSTANCE {
input {
rate 1000;
max-packets-per-second 1;
}
family inet {
output {
flow-server xxx..xxx.xxx{
port 9995;
autonomous-system-type origin;
no-local-dump;
version-ipfix {
template {
ipv4;
}
}
}
inline-jflow {
source-address xxx.xxx.xxx.xxx;
}
}
}
family inet6 {
output {
flow-server xxx.xxx.xxx.xxx {
port 9995;
autonomous-system-type origin;
no-local-dump;
version-ipfix {
template {
ipv6;
}
}
}
inline-jflow {
source-address xxx.xxx.xxx.xxx;
}
}
}
}
vlan-id 2XX8;
family inet6 {
sampling {
input;
output;
}
address 2001:xxx:0:xxx::216/64;
}
flow-monitoring {
version-ipfix {
template ipv4 {
flow-active-timeout 600;
flow-inactive-timeout 30;
template-refresh-rate {
packets 48000;
seconds 60;
}
option-refresh-rate {
packets 48000;
seconds 60;
}
ipv4-template;
}
template ipv6 {
flow-active-timeout 150;
flow-inactive-timeout 100;
template-refresh-rate {
seconds 10;
}
option-refresh-rate {
seconds 10;
}
ipv6-template;
}
}
}
2017-12-01 15:10 GMT-03:00 :
> > Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX?
> >
> > Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 flow
> > monitoring is working as intended. With IPv6 , looks like the collector
> is
> > don´t know what to do with the data the Router is sending (MX480).
> >
> > After a Call , looks like the router is not sending the correct templates
> > to Scrutinizer, the only information it can identify is the current
> > interface traffic from the flows. But no source and destination ipv6
> > address.
>
> Can't comment on 16.1R4. We're running IPFIX flow collection on 15.1R6
> and it seems to be working reasonably well, both for IPv4 and IPv6. No
> problem showing IPv6 addresses with nfdump.
>
> You may want to show your config.
>
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
>
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.
I have an open case on JTAC about it, but it´s been slow... 2017-12-04 13:04 GMT-03:00 Michael Hare : > If anyone has contacted jtac and has a PR to reference I would appreciate > it (publically or privately). We are evaluating moving from 14.1 to 16.1R6 > but I haven't yet tested v6 IPFIX. > > -Michael > > >>-Original Message- > >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > >>Of João Lyma. > >>Sent: Friday, December 01, 2017 2:53 PM > >>To: juniper-nsp@puck.nether.net > >>Subject: Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector. > >> > >>Hi Gustavo, > >> > >>Same problem here... > >>I use nfdump with nfsen. > >>Router: MX480 with JUNOS 16.1R3.10 64-bit kernel > >>JNPR-10.3-20160927.337663_build > >> > >>Regards, > >> > >>Lyma > >> > >> > >>Em 30/11/2017 00:13, Gustavo Santos escreveu: > >>> Hi, > >>> > >>> Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX? > >>> > >>> Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 > >>> flow > >>> monitoring is working as intended. With IPv6 , looks like the collector > >>> is > >>> don´t know what to do with the data the Router is sending (MX480). > >>> > >>> After a Call , looks like the router is not sending the correct > >>> templates > >>> to Scrutinizer, the only information it can identify is the current > >>> interface traffic from the flows. But no source and destination ipv6 > >>> address. > >>> > >>> I already opened a JTAC support, but looks like the JTAC doesn´t even > >>> have > >>> a clue... I asked a friend that have the same router at another ISP and > >>> he > >>> have the same issue with NFSEN/FASTNETMON.. > >>> ___ > >>> 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] QFX5100 ACLs
+ Programmed: YES + Total TCAM entries available: 1788 + Total TCAM entries installed : 516 Brendan Mannella TeraSwitch Inc. Main - 1.412.945.7045 Direct - 1.412.945.7049 eFax - 1.412.945.7049 Colocation . Cloud . Connectivity This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this On Mon, Dec 4, 2017 at 11:57 AM, Saku Ytti wrote: > Hey Brendan, > > This is news to me, but plausible. Can you do this for me > > start shell pfe network fpc0 > show filter > > show filter hw show_term_info > > Compare how many TCAM entries are needed, and how many are available. > > Also if you can take a risk of reloading the FPC run: > show filter hw show_terms_brcm > > This may crash your PFE, if you actually did not have all of the > entries programmed in HW. > > > commit will succeed if you build filter which will not fit in HW, > there should be syslog entry, but no complain during commit. You will > end up having no filter or some mangled version of it. So it's just > alternative theory on why you may be accepting something you thought > you aren't. > > > On 4 December 2017 at 18:02, Brendan Mannella > wrote: > > Hello, > > > > So i have been testing QFX5100 product for use as a core L3 switch/router > > with BGP/OSPF. I have my standard RE filter blocking various things > > including BGP from any unknown peer. I started to receive errors in my > logs > > showing BGP packets getting through from hosts that weren't allowed. > After > > digging around i found that Juniper apparently has built in ACL to allow > > BGP, which bypasses my ACLs, probably for VCF or something.. Is there any > > way to disable this behavior or does anyone have any other suggestions? > > > > root@XXX% cprod -A fpc0 -c "show filter hw dynamic 47 show_terms" > > > > Filter name : dyn-bgp-pkts > > Filter enum : 47 > > Filter location : IFP > > List of tcam entries : [(total entries: 2) > > Entry: 37 > > - Unit 0 > > - Entry Priority 0x7FFC > > - Matches: > > PBMP 0x0001fffc > > PBMP xe > > L4 SRC Port 0x00B3 mask 0x > > IP Protocol 0x0006 mask 0x00FF > > L3DestHostHit 1 1 > > - Actions: > > ChangeCpuQ > > ColorIndependent param1: 1, param2: 0 > > CosQCpuNew cosq: 30 > > Implicit Counter > > Entry: 38 > > - Unit 0 > > - Entry Priority 0x7FFC > > - Matches: > > PBMP 0x0001fffc > > PBMP xe > > L4 DST Port 0x00B3 mask 0x > > IP Protocol 0x0006 mask 0x00FF > > L3DestHostHit 1 1 > > - Actions: > > ChangeCpuQ > > ColorIndependent param1: 1, param2: 0 > > CosQCpuNew cosq: 30 > > Implicit Counter > >] > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > > -- > ++ytti > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MIC-3D-4XGE-XFP in a MX104?
Hi, The 2 port / 4 ports are in the list, but only the 2 ports show up under MX80/104 and not the 4 ports. https://www.juniper.net/documentation/en_US/release-independent/junos/topics/reference/general/mic-mx-series-supported.html 10-Gigabit Ethernet - 10-Gigabit Ethernet MICs with XFP - *MIC-3D-2XGE-XFP* - 2 - 10.2 - 13.2R2 By ya, at the end of the day, they is place for improvement. PS: We have 2 x 4GXE in stock for our future MX240+ because of this. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 12/04/17 05:26, Eric Van Tol wrote: Seems odd they would choose the same form factor for incompatible designs, but that explains why the 2-port card is more expensive. Also seems odd the 4-port MIC is listed as compatible on the MX80/MX104 on the Hardware Compatibility List. This is why I put zero trust in these sorts of tools when building systems. I can confirm that the MIC doesn't even show up in the hardware listing if you install it into an MX80. -evt ___ 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] LACP between router VMs (James Bensley)
Amazon recently announced bare metal instances which provide access to the CPU virtual instruction set such as Intel VT-x, so although I haven't had a chance to look into it much just yet, I'm hoping one can spin up vMX/ASR9Kv etc. using these instances in Amazon and just offload the scaling issue to them: https://aws.amazon.com/about-aws/whats-new/2017/11/announcing-amazon-ec2-bare-metal-instances-preview/ Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] QFX5100 ACLs
Hey Brendan, This is news to me, but plausible. Can you do this for me start shell pfe network fpc0 show filter show filter hw show_term_info Compare how many TCAM entries are needed, and how many are available. Also if you can take a risk of reloading the FPC run: show filter hw show_terms_brcm This may crash your PFE, if you actually did not have all of the entries programmed in HW. commit will succeed if you build filter which will not fit in HW, there should be syslog entry, but no complain during commit. You will end up having no filter or some mangled version of it. So it's just alternative theory on why you may be accepting something you thought you aren't. On 4 December 2017 at 18:02, Brendan Mannella wrote: > Hello, > > So i have been testing QFX5100 product for use as a core L3 switch/router > with BGP/OSPF. I have my standard RE filter blocking various things > including BGP from any unknown peer. I started to receive errors in my logs > showing BGP packets getting through from hosts that weren't allowed. After > digging around i found that Juniper apparently has built in ACL to allow > BGP, which bypasses my ACLs, probably for VCF or something.. Is there any > way to disable this behavior or does anyone have any other suggestions? > > root@XXX% cprod -A fpc0 -c "show filter hw dynamic 47 show_terms" > > Filter name : dyn-bgp-pkts > Filter enum : 47 > Filter location : IFP > List of tcam entries : [(total entries: 2) > Entry: 37 > - Unit 0 > - Entry Priority 0x7FFC > - Matches: > PBMP 0x0001fffc > PBMP xe > L4 SRC Port 0x00B3 mask 0x > IP Protocol 0x0006 mask 0x00FF > L3DestHostHit 1 1 > - Actions: > ChangeCpuQ > ColorIndependent param1: 1, param2: 0 > CosQCpuNew cosq: 30 > Implicit Counter > Entry: 38 > - Unit 0 > - Entry Priority 0x7FFC > - Matches: > PBMP 0x0001fffc > PBMP xe > L4 DST Port 0x00B3 mask 0x > IP Protocol 0x0006 mask 0x00FF > L3DestHostHit 1 1 > - Actions: > ChangeCpuQ > ColorIndependent param1: 1, param2: 0 > CosQCpuNew cosq: 30 > Implicit Counter >] > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector.
If anyone has contacted jtac and has a PR to reference I would appreciate it (publically or privately). We are evaluating moving from 14.1 to 16.1R6 but I haven't yet tested v6 IPFIX. -Michael >>-Original Message- >>From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf >>Of João Lyma. >>Sent: Friday, December 01, 2017 2:53 PM >>To: juniper-nsp@puck.nether.net >>Subject: Re: [j-nsp] IPV6 IPFIX Flow issues "nodata" on flow collector. >> >>Hi Gustavo, >> >>Same problem here... >>I use nfdump with nfsen. >>Router: MX480 with JUNOS 16.1R3.10 64-bit kernel >>JNPR-10.3-20160927.337663_build >> >>Regards, >> >>Lyma >> >> >>Em 30/11/2017 00:13, Gustavo Santos escreveu: >>> Hi, >>> >>> Anyone else had issues with Junos 16.1R4 with IPV6 and IPFIX? >>> >>> Here we use Plixer Scrutinizer as Flow collector and analyzer. IPv4 >>> flow >>> monitoring is working as intended. With IPv6 , looks like the collector >>> is >>> don´t know what to do with the data the Router is sending (MX480). >>> >>> After a Call , looks like the router is not sending the correct >>> templates >>> to Scrutinizer, the only information it can identify is the current >>> interface traffic from the flows. But no source and destination ipv6 >>> address. >>> >>> I already opened a JTAC support, but looks like the JTAC doesn´t even >>> have >>> a clue... I asked a friend that have the same router at another ISP and >>> he >>> have the same issue with NFSEN/FASTNETMON.. >>> ___ >>> 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] QFX5100 ACLs
Hello, So i have been testing QFX5100 product for use as a core L3 switch/router with BGP/OSPF. I have my standard RE filter blocking various things including BGP from any unknown peer. I started to receive errors in my logs showing BGP packets getting through from hosts that weren't allowed. After digging around i found that Juniper apparently has built in ACL to allow BGP, which bypasses my ACLs, probably for VCF or something.. Is there any way to disable this behavior or does anyone have any other suggestions? root@XXX% cprod -A fpc0 -c "show filter hw dynamic 47 show_terms" Filter name : dyn-bgp-pkts Filter enum : 47 Filter location : IFP List of tcam entries : [(total entries: 2) Entry: 37 - Unit 0 - Entry Priority 0x7FFC - Matches: PBMP 0x0001fffc PBMP xe L4 SRC Port 0x00B3 mask 0x IP Protocol 0x0006 mask 0x00FF L3DestHostHit 1 1 - Actions: ChangeCpuQ ColorIndependent param1: 1, param2: 0 CosQCpuNew cosq: 30 Implicit Counter Entry: 38 - Unit 0 - Entry Priority 0x7FFC - Matches: PBMP 0x0001fffc PBMP xe L4 DST Port 0x00B3 mask 0x IP Protocol 0x0006 mask 0x00FF L3DestHostHit 1 1 - Actions: ChangeCpuQ ColorIndependent param1: 1, param2: 0 CosQCpuNew cosq: 30 Implicit Counter ] ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MIC-3D-4XGE-XFP in a MX104?
> Seems odd they would choose the same form factor for incompatible > designs, but that explains why the 2-port card is more expensive. Also seems odd the 4-port MIC is listed as compatible on the MX80/MX104 on the Hardware Compatibility List. This is why I put zero trust in these sorts of tools when building systems. I can confirm that the MIC doesn't even show up in the hardware listing if you install it into an MX80. -evt ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
