Re: [j-nsp] Help with BGP as-path regex
Hi Alex, That looks like what I want, thanks! Here's a brief test I tried: Policy definitions: as-path 3257_originate "^3257+.*"; policy-statement as_3257_import { term gtt { from { protocol bgp; as-path 3257_originate; } then accept; } term reject-all { then reject; } } policy-statement as_3257_import-test { term gtt { from { protocol bgp; as-path 3257_originate; as-path-unique-count 2 orlower; } then accept; } term reject-all { then reject; } } This route has 3 unique AS hops and includes prepending, it should pass the as_3257_import policy, but fail the as_3257_import-test policy # run show route 1.32.208.0/24 inet.0: 760463 destinations, 1010435 routes (760460 active, 2 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 1.32.208.0/24 *[BGP/170] 1d 19:59:15, MED 1347, localpref 100 AS path: 3257 7473 7473 7473 64050 64050 I, validation-state: unverified As expected, the route passes as_3257_import policy test. This policy is not using the as-path-unique-count configuration knob: # run test policy as_3257_import 1.32.208.0/24 inet.0: 760502 destinations, 1010269 routes (760495 active, 6 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 1.32.208.0/24 *[BGP/170] 1d 20:02:52, MED 1347, localpref 100 AS path: 3257 7473 7473 7473 64050 64050 I, validation-state: unverified Policy as_3257_import: 1 prefix accepted, 0 prefix rejected As expected, the same route fails the test using the policy that includes the as-path-unique-count knob with value 2 orlower. The route has too many unique AS hops: # run test policy as_3257_import-test 1.32.208.0/24 Policy as_3257_import-test: 0 prefix accepted, 1 prefix rejected Now we update unique count to 3: policy-statement as_3257_import-test { term gtt { from { protocol bgp; as-path 3257_originate; as-path-unique-count 3 orlower; } then accept; } term reject-all { then reject; } } Now the test policy succeeds as expected: # run test policy as_3257_import-test 1.32.208.0/24 inet.0: 760500 destinations, 1010273 routes (760405 active, 94 holddown, 1 hidden) Restart Complete + = Active Route, - = Last Active, * = Both 1.32.208.0/24 *[BGP/170] 1d 20:03:02, MED 1347, localpref 100 AS path: 3257 7473 7473 7473 64050 64050 I, validation-state: unverified Policy as_3257_import-test: 1 prefix accepted, 0 prefix rejected kind regards, -andy On Thu, Sep 12, 2019 at 9:20 PM Alexander Arseniev wrote: > Hello, > > Does this help? > > > https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/m-mx-t-series-toc.html > <https://www.juniper.net/documentation/en_US/junos/information-products/topic-collections/release-notes/16.1/m-mx-t-series-toc.html#jd0e11155> > > Support for unique AS path count ( MX Series)—Starting with Junos OS > Release 16.1R4, you can configure a routing policy to determine the number > of unique autonomous systems (ASs) present in the AS path. The unique AS > path count helps determine whether a given AS is present in the AS path > multiple times, typically as prepended ASs. In earlier Junos releases it > was not possible to implement this counting behavior using the as-path regular > expression policy. This feature permits the user to configure a policy > based on the number of AS hops between the route originator and receiver. > This feature ignores ASs in the as-path that are confederation ASs, such > as confed_seq and confed_set. > > To configure AS path count, include the as-path-unique-count count (equal > | orhigher | orlower) configuration statement at the [edit policy-options > policy-statement policy_name from] hierarchy level. > > > Thanks > > Alex > > > On 13/09/2019 00:18, Andy Litzinger wrote: > > Hi All, > I thought this would be in a cookbook somewhere but I can't find it. Is > there a way to write an as-path regex so it will match a providers ASN > (e.g. 1234) one or more times and then 1 or 2 more ASNs zero or more > times? I'm hoping to be able to account for AS prepending. > > I'm an Enterprise network and one of my upstream ISPs is sending me full > routes + default. I want to filter the routes down to networks that are > directly connected or at most 2 hops away from my ISP, but also allow for > AS prepending. It's the prepending that is tripping me up or else I think > this would suffice: "^1234+ .{0,2}" > > I think with cisco you can do this with backreferences, but Junos doesn't > seem to support those. > > TI
[j-nsp] Help with BGP as-path regex
Hi All, I thought this would be in a cookbook somewhere but I can't find it. Is there a way to write an as-path regex so it will match a providers ASN (e.g. 1234) one or more times and then 1 or 2 more ASNs zero or more times? I'm hoping to be able to account for AS prepending. I'm an Enterprise network and one of my upstream ISPs is sending me full routes + default. I want to filter the routes down to networks that are directly connected or at most 2 hops away from my ISP, but also allow for AS prepending. It's the prepending that is tripping me up or else I think this would suffice: "^1234+ .{0,2}" I think with cisco you can do this with backreferences, but Junos doesn't seem to support those. TIA, -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] minimum permissions for napalm/pyez user
Hello! We are attempting to use Napalm which I understand is using pyez/netconf over ssh under the hood. We can get things to work with a full admin level user, but we'd like to pare down the access to only what is required. right now we are specifically hitting an issue where when we run the napalm open() method with our restricted user it fails because it's trying to drop into the shell and run the command "xml-mode netconf need-trailer" . We verified this by logging the interactive commands at our router and comparing what was run with an admin user vs our restricted user. We get a the following error: >>> import napalm_junos >>> mx_router = napalm_junos.JunOSDriver(hostname="ip.address",username="my_restricted_user",password="my_pass") >>> mx_router.open() Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/site-packages/napalm_junos/junos.py", line 106, in open self.device.open() File "/usr/local/lib/python2.7/site-packages/jnpr/junos/device.py", line 1291, in open raise cnx_err jnpr.junos.exception.ConnectError: ConnectError(host: ip.address, msg: Unexpected session close IN_BUFFER: ` error: unknown command: xml-mode error: permission denied: netconf `) TIA! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] source address selection for RE generated traffic addresses to direct neighbors
On 1/22/19 11:18 AM, Martin T wrote: Hi, how does Junos choose the source address for RE generated traffic addresses to direct neighbors if the application(for example ping utility) does not bind to specific address? Does it choose the first address configured on the egress interface which falls in the same network as the destination address? Hi Martin, If you are looking to be deterministic on your address selection, you will want to check out primary and preferred addresses: https://www.juniper.net/documentation/en_US/junos/topics/task/configuration/interfaces-configuring-default-primary-and-preferred-addresses-and-interfaces.html Hope that helps, Andy Andy Koch Hoyos Consulting LLC ofc: +1 608 616 9950 an...@hoyosconsulting.com http://www.hoyosconsulting.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Segment Routing Real World Deployment
On 7/7/18 7:37 AM, Mark Tinka wrote: Slightly off-topic, we tried the EX4600 as a way to move away from the now-EoS EX4550, Hi Mark, You mentioned a couple times in the thread that the EX4550 is EoS. I am not finding any reference to that on the Juniper site. In fact, they still tout the switch. Do you have a link to the EoS/EoL notices? Thanks, Andy Andy Koch Hoyos Consulting LLC ofc: +1 608 616 9950 an...@hoyosconsulting.com http://www.hoyosconsulting.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall filter with apply-path
Hi Ross, I essentially use the example straight from here: http://forums.juniper.net/t5/Day-One-Books/Day-One-Book-Securing-the-Routin g-Engine-on-M-MX-and-T-Series/ba-p/92276 and they work great. HTH, -andy On 7/27/15, 2:45 PM, juniper-nsp on behalf of Ross Halliday juniper-nsp-boun...@puck.nether.net on behalf of ross.halli...@wtccommunications.ca wrote: Hi list, Would someone be so kind as to apply a working example configuration to protect the RE using apply-path to generate prefix lists? I *THINK* I have the actual apply-path part working, as show configuration ... inheritance shows what should be in there, but when I set the firewall filter on lo0.0 it doesn't match any packets and everything is just dropped. :( I am new to JUNOS so a sanitized working example would be absolutely fantastic. I'm running MX104s on 13.3R4.6, if that matters. 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] sip calls through srx fail after approx 15 min
So far the culprit appears to have been the NAT setup. Contrary to my understanding a source NAT with a 1:1 mapping does still seem to use PAT. AFAICT there is no way to disable that for a single source NAT rule, only for all source NAT. This presumes that the 'security nat source port-randomization disable' knob has the effect of disabling PAT on a 1:1 source nat. I'm not able to test that as I'm relying on other source NATs that I don't want to interrupt. Anyway, I updated my config to use static NAT and we were immediately able to hold a test call for far longer than 15m (we let it go to 50m before we ended it). We'll continue to test and monitor and I'll report back here if we have issues. thanks to everyone for their help! -andy On Thu, May 28, 2015 at 12:10 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi Majdi, So are you saying that the sip alg can not be disabled? Or that I won't be able to get sip to work through the SRX without using the alg? Thanks for bringing up NAT, I did forget to mention our NAT setup. The provider requires that NAT and not PAT is used. I've accomplished that by source NAT for the pbx (perhaps I should switch to static NAT?). Presuming our provider has configured their SIP gateway to work properly with NAT and presuming I've configured NAT properly, are you saying there is no way make this work on the SRX with the sip alg disabled? here is my NAT setup: srx01 show configuration security nat source { pool pool-avaya-public-nat { address { x.x.x.x/32; } } rule-set internal-to-net { from zone internal; to zone external; rule avaya-pbx-to-net { match { source-address-name avaya-pbx; } then { source-nat { pool { pool-avaya-public-nat; } } } } proxy-arp { interface ge-0/0/0.0 { address { x.x.x.x/32; } } } thanks, -andy On Thu, May 28, 2015 at 11:41 AM, Majdi S. Abbas m...@latt.net wrote: On Thu, May 28, 2015 at 11:36:20AM -0700, Andy Litzinger wrote: We're configuring a new sip setup with a phone vendor. The provider pbx sits inside our network and makes connections out through our SRX to the provider sip gateways. Calls are working, but seem to drop at or near the 15 minute mark. The provider is sure that it's a setting on the SRX. The one issue we may have found is that it seems we might be having some trouble truly turning off the sip alg which is a requirement of the provider. Despite our best efforts I continue to see sessions when I issue the command 'show security flow session application sip'. Firstly, am I correct in assuming that if I see a session here that it indicates the sip alg is being used? SIP is not NAT friendly, so you are using the ALG. Now, as far as tuning that ALG, start with adjusting the timeout beyond the 3600s that most people use as their default: applications { application junos-sip { term t1 inactivity-timeout 7200; } } If you also experience one-way audio problems, you may need the following as well: security { alg { sip { application-screen { unknown-message { permit-nat-applied; permit-routed; } } } } } Cheers, --msa ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] sip calls through srx fail after approx 15 min
Hi Majdi, So are you saying that the sip alg can not be disabled? Or that I won't be able to get sip to work through the SRX without using the alg? Thanks for bringing up NAT, I did forget to mention our NAT setup. The provider requires that NAT and not PAT is used. I've accomplished that by source NAT for the pbx (perhaps I should switch to static NAT?). Presuming our provider has configured their SIP gateway to work properly with NAT and presuming I've configured NAT properly, are you saying there is no way make this work on the SRX with the sip alg disabled? here is my NAT setup: srx01 show configuration security nat source { pool pool-avaya-public-nat { address { x.x.x.x/32; } } rule-set internal-to-net { from zone internal; to zone external; rule avaya-pbx-to-net { match { source-address-name avaya-pbx; } then { source-nat { pool { pool-avaya-public-nat; } } } } proxy-arp { interface ge-0/0/0.0 { address { x.x.x.x/32; } } } thanks, -andy On Thu, May 28, 2015 at 11:41 AM, Majdi S. Abbas m...@latt.net wrote: On Thu, May 28, 2015 at 11:36:20AM -0700, Andy Litzinger wrote: We're configuring a new sip setup with a phone vendor. The provider pbx sits inside our network and makes connections out through our SRX to the provider sip gateways. Calls are working, but seem to drop at or near the 15 minute mark. The provider is sure that it's a setting on the SRX. The one issue we may have found is that it seems we might be having some trouble truly turning off the sip alg which is a requirement of the provider. Despite our best efforts I continue to see sessions when I issue the command 'show security flow session application sip'. Firstly, am I correct in assuming that if I see a session here that it indicates the sip alg is being used? SIP is not NAT friendly, so you are using the ALG. Now, as far as tuning that ALG, start with adjusting the timeout beyond the 3600s that most people use as their default: applications { application junos-sip { term t1 inactivity-timeout 7200; } } If you also experience one-way audio problems, you may need the following as well: security { alg { sip { application-screen { unknown-message { permit-nat-applied; permit-routed; } } } } } Cheers, --msa ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] sip calls through srx fail after approx 15 min
Hi all, We're configuring a new sip setup with a phone vendor. The provider pbx sits inside our network and makes connections out through our SRX to the provider sip gateways. Calls are working, but seem to drop at or near the 15 minute mark. The provider is sure that it's a setting on the SRX. The one issue we may have found is that it seems we might be having some trouble truly turning off the sip alg which is a requirement of the provider. Despite our best efforts I continue to see sessions when I issue the command 'show security flow session application sip'. Firstly, am I correct in assuming that if I see a session here that it indicates the sip alg is being used? srx01 show security flow session application sip Session ID: 45838, Policy name: avaya-pbx-to-sip-ports/36, Timeout: 60, Valid In: 172.x.x.x/5060 -- x.x.x.x/5060;udp, If: ge-0/0/1.24, Pkts: 3, Bytes: 2146 Out: x.x.x.x/5060 -- x.x.x.x/9675;udp, If: ge-0/0/0.0, Pkts: 3, Bytes: 1626 Total sessions: 1 the sip alg counters(show security alg sip counters) aren't increasing, and turning on sip traceoptions isn't logging anything but the existence of the flow in the session table makes me suspicious. I've attempted to disable use of the alg by doing the following: * disabling the alg globaly set security alg sip disable * create application groups that don't reference the alg * referenced those applications in the security policy that allows the pbx to contact the remote sip gateway Is my sip alg truly disabled? If so, any ideas why calls might be dropping at the 15m mark? The phone doesn't actually disconnect, but the call stops working. many thanks, -andy Here's some relevant config snippets: srx01 show security alg status ALG Status : DNS : Enabled FTP : Enabled H323 : Enabled MGCP : Enabled MSRPC: Enabled PPTP : Enabled RSH : Enabled RTSP : Enabled SCCP : Enabled SIP : Disabled snip srx01 show configuration applications application my-sip-tcp protocol tcp; destination-port 5060-5070; srx01 show configuration applications application my-sip-udp protocol udp; destination-port 5060-5070; srx01 show configuration security policies from-zone internal to-zone external policy avaya-pbx-to-sip-ports match { source-address avaya-pbx; destination-address sip-gateway; application [ my-sip-udp my-sip-tcp ]; } then { permit; } ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 JFlow Setup
The flow configuration is working as posted- i was testing this in a legacy setup and forgot there was another firewall in the path between my mx80s and my flow collector. thanks all for the help! -andy On Thu, Jan 15, 2015 at 9:44 AM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi Scott and all, can you give an example of what i might have to open? I have a reject-all and log statement at the end of my lo0.0 filter and I don't see any matches toward my flow-server ip. I'm also don't understand why an input filter on the loopback would impact outbound traffic to my flow-server? I forgot to mentions, but I'm running 13.3R4.6 I am running a tcpdump on my flow-server and no packets have arrived. It seems to me that flows are being captured and exported, even with the default template settings: # run show services accounting flow inline-jflow Flow information TFEB Slot: 0 Flow Packets: 5805, Flow Bytes: 3941343 Active Flows: 4, Total Flows: 3907 Flows Exported: 3457, Flow Packets Exported: 3453 Flows Inactive Timed Out: 3204, Flows Active Timed Out: 699 let a few seconds pass # run show services accounting flow inline-jflow Flow information TFEB Slot: 0 Flow Packets: 5806, Flow Bytes: 3942763 Active Flows: 2, Total Flows: 3907 Flows Exported: 3458, Flow Packets Exported: 3454 Flows Inactive Timed Out: 3206, Flows Active Timed Out: 699 regards, -andy On Thu, Jan 15, 2015 at 6:51 AM, Scott Granados sc...@granados-llc.net wrote: You will definitely have to poke a hole in your firewall on your loopback. Also, make sure the loopback is part of the main routing instance not in another grouting instance, your source until very recent releases has to be in the global table. Use TCPDump to make sure that flow packets are reaching your collector as well for testing. On Jan 15, 2015, at 12:18 AM, Andy Litzinger andy.litzin...@theplatform.com wrote: Yes I do. Sounds like I need to pole a hole? On Jan 14, 2015, at 6:14 PM, Eduardo Schoedler lis...@esds.com.br wrote: Do you have a firewall in your loopback? -- Eduardo Em quarta-feira, 14 de janeiro de 2015, Andy Litzinger andy.litzinger.li...@gmail.com escreveu: Levi, did you get this working? My MX80 appears to be collecting flows, but I don't see any output to my flow server. The server ip is reachable from my MX 80. # show chassis snip tfeb { slot 0 { sampling-instance tp-sampling-instance; } } # show forwarding-options sampling traceoptions { file ipfix.log size 10k; } instance { tp-sampling-instance { input { rate 1000; } family inet { output { flow-server my flow server { port 2055; version-ipfix { template { ipfix-ipv4-template; } } } inline-jflow { source-address my loopback; } } } } } # show services flow-monitoring { version-ipfix { template ipfix-ipv4-template { ipv4-template; } } } # show interfaces ge-1/0/0 snip unit 0 { family inet { sampling { input; } address isp-uplink-ip; } } # run show services accounting status inline-jflow Status information TFEB Slot: 0 IPV4 export format: Version-IPFIX, IPV6 export format: Not set VPLS export format: Not set IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4 Route Record Count: 516483, AS Record Count: 143756 Route-Records Set: Yes, Config Set: Yes # run show services accounting flow inline-jflow Flow information TFEB Slot: 0 Flow Packets: 1445, Flow Bytes: 1419455 Active Flows: 22, Total Flows: 935 Flows Exported: 764, Flow Packets Exported: 752 Flows Inactive Timed Out: 623, Flows Active Timed Out: 290 regards, -andy -- Eduardo Schoedler ___ 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] MX80 JFlow Setup
Levi, did you get this working? My MX80 appears to be collecting flows, but I don't see any output to my flow server. The server ip is reachable from my MX 80. # show chassis snip tfeb { slot 0 { sampling-instance tp-sampling-instance; } } # show forwarding-options sampling traceoptions { file ipfix.log size 10k; } instance { tp-sampling-instance { input { rate 1000; } family inet { output { flow-server my flow server { port 2055; version-ipfix { template { ipfix-ipv4-template; } } } inline-jflow { source-address my loopback; } } } } } # show services flow-monitoring { version-ipfix { template ipfix-ipv4-template { ipv4-template; } } } # show interfaces ge-1/0/0 snip unit 0 { family inet { sampling { input; } address isp-uplink-ip; } } # run show services accounting status inline-jflow Status information TFEB Slot: 0 IPV4 export format: Version-IPFIX, IPV6 export format: Not set VPLS export format: Not set IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4 Route Record Count: 516483, AS Record Count: 143756 Route-Records Set: Yes, Config Set: Yes # run show services accounting flow inline-jflow Flow information TFEB Slot: 0 Flow Packets: 1445, Flow Bytes: 1419455 Active Flows: 22, Total Flows: 935 Flows Exported: 764, Flow Packets Exported: 752 Flows Inactive Timed Out: 623, Flows Active Timed Out: 290 regards, -andy On Tue, Dec 23, 2014 at 9:16 AM, Levi Pederson levipeder...@mankatonetworks.net wrote: All, Trying to get an MX80 to output Flow to an external collector. I've been reading several pieces of documentation and I keep getting differing views and opinions on how this is supposed to be done. I'm looking for the simplest option right now and if I need to expand I can move to more detailed processes after I'm currently using the following [edit chassis] - tfeb { - slot 0 { - sampling-instance calix; - } - } [edit] - forwarding-options { - sampling { - instance { - calix { - input { - rate 50; - } - family inet { - output { - flow-server [ipaddress] { - port 2058; - version-ipfix { - template { - ipv4; - } - } - } - inline-jflow { - source-address [ipaddress]; - } - } - } - } - } - } - } - services { - flow-monitoring { - version-ipfix { - template ipv4 { - flow-active-timeout 60; - flow-inactive-timeout 70; - template-refresh-rate { - seconds 30; - } - option-refresh-rate { - seconds 30; - } - ipv4-template; - } - } - } - } Edited for Anonymity. Thank you, . *Levi Pederson* Mankato Networks LLC cell | 612.481.0769 work | 612.787.7392 levipeder...@mankatonetworks.net ___ 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] MX80 JFlow Setup
Yes I do. Sounds like I need to pole a hole? On Jan 14, 2015, at 6:14 PM, Eduardo Schoedler lis...@esds.com.br wrote: Do you have a firewall in your loopback? -- Eduardo Em quarta-feira, 14 de janeiro de 2015, Andy Litzinger andy.litzinger.li...@gmail.com escreveu: Levi, did you get this working? My MX80 appears to be collecting flows, but I don't see any output to my flow server. The server ip is reachable from my MX 80. # show chassis snip tfeb { slot 0 { sampling-instance tp-sampling-instance; } } # show forwarding-options sampling traceoptions { file ipfix.log size 10k; } instance { tp-sampling-instance { input { rate 1000; } family inet { output { flow-server my flow server { port 2055; version-ipfix { template { ipfix-ipv4-template; } } } inline-jflow { source-address my loopback; } } } } } # show services flow-monitoring { version-ipfix { template ipfix-ipv4-template { ipv4-template; } } } # show interfaces ge-1/0/0 snip unit 0 { family inet { sampling { input; } address isp-uplink-ip; } } # run show services accounting status inline-jflow Status information TFEB Slot: 0 IPV4 export format: Version-IPFIX, IPV6 export format: Not set VPLS export format: Not set IPv4 Route Record Count: 516479, IPv6 Route Record Count: 4 Route Record Count: 516483, AS Record Count: 143756 Route-Records Set: Yes, Config Set: Yes # run show services accounting flow inline-jflow Flow information TFEB Slot: 0 Flow Packets: 1445, Flow Bytes: 1419455 Active Flows: 22, Total Flows: 935 Flows Exported: 764, Flow Packets Exported: 752 Flows Inactive Timed Out: 623, Flows Active Timed Out: 290 regards, -andy -- Eduardo Schoedler ___ 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] controlling the source IP for the Dns Proxy feature
Hello, is anyone out there using the dns-proxy feature for the branch SRX? Are there any clever tricks for specifying the source address the SRX uses to query name servers? It does not appear to be a config option. with the default config it appears to use the IP of the outbound interface. If I add the config statement 'set system default address selection' i can influence it to use the lo0.0 address, which can solve my issue, but not in a way i prefer. my exact problem is the following: I have an SRX 220H in a remote office. It has an trust and untrust zone. users sit on the trust zone and receive dhcp from the SRX and use the SRX as their default gateway and dns server. There is a policy based vpn that connects from the untrust zone to our corp HQ. I have the dns-proxy config set up so that if a dns request is going to an intranet zone, e.g. corp.example.com, then it should use DNS servers that live across the tunnel in our corp HQ. If they are looking up anything else, they use google dns servers. here's the relevant config: dns-proxy { interface { interface facing users; } default-domain * { forwarders { 8.8.8.8; 8.8.4.4; } } default-domain corp.example.com { forwarders { corp hq name server1; corp hq name server 2; } } } the problem is without the 'default address selection' set the SRX tries to use the untrust interface IP as the source IP to query our corp HQ name servers, but the traffic doesn't enter the tunnel because it doesn't match the vpn policy. And I can't change the policy to allow it because the untrust interface IP is the endpoint of the tunnel. It looks like the source zone of the dns query is junos-host- is it possible maybe to set up a junos-host zone to untrust zone NAT when going to corp-hq IP space? or is there another clever solution? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] controlling the source IP for the Dns Proxy feature
I'd happily use route-based vpns if they are supported in my use case. Based on Kbs and internet lore, it seemed policy based was the best bet for stability. My two tunnel endpoint devices are the SRX and a Cisco ASA. On the SRX side I've got a single subnet but on the ASA side I've got two subnets. I would happily use a simple policy on the ASA side like 'permit ip any SRX side IP subnet SRX side mask' if i was confident I wasn't going to have squirrely issues with connectivity. What do you think? -andy On 10/15/14 3:22 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Andy, I have come across this exact issue using the feature. There was a good reason why we didn't use default address selection that escapes me just now, but I had a slight advantage in that I was using route-based VPNs, so I was able to number the st0 interface with a /32 from the corporate range and source my queries from there. Unfortunately policy-based VPNs are extremely limiting when it comes to things like this. I can't think of too many scenarios where I'd even use them any more. If you don't have too many sites, I'd seriously consider migrating them across. Cheers, Ben On 16 Oct 2014, at 1:28 am, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hello, is anyone out there using the dns-proxy feature for the branch SRX? Are there any clever tricks for specifying the source address the SRX uses to query name servers? It does not appear to be a config option. with the default config it appears to use the IP of the outbound interface. If I add the config statement 'set system default address selection' i can influence it to use the lo0.0 address, which can solve my issue, but not in a way i prefer. my exact problem is the following: I have an SRX 220H in a remote office. It has an trust and untrust zone. users sit on the trust zone and receive dhcp from the SRX and use the SRX as their default gateway and dns server. There is a policy based vpn that connects from the untrust zone to our corp HQ. I have the dns-proxy config set up so that if a dns request is going to an intranet zone, e.g. corp.example.com, then it should use DNS servers that live across the tunnel in our corp HQ. If they are looking up anything else, they use google dns servers. here's the relevant config: dns-proxy { interface { interface facing users; } default-domain * { forwarders { 8.8.8.8; 8.8.4.4; } } default-domain corp.example.com { forwarders { corp hq name server1; corp hq name server 2; } } } the problem is without the 'default address selection' set the SRX tries to use the untrust interface IP as the source IP to query our corp HQ name servers, but the traffic doesn't enter the tunnel because it doesn't match the vpn policy. And I can't change the policy to allow it because the untrust interface IP is the endpoint of the tunnel. It looks like the source zone of the dns query is junos-host- is it possible maybe to set up a junos-host zone to untrust zone NAT when going to corp-hq IP space? or is there another clever solution? thanks! -andy ___ 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] controlling the source IP for the Dns Proxy feature
I'm running 12.1X44-D40.2 right now (had to run newer 12.1X code to even use the dns-proxy feature :) ). I'll give X46-D10 a look; the traffic-selctors looks pretty interesting. As far as your comment regarding widening the crypto-map- that's what i was implying with my example acl- basically widening it on the cisco side to include every IP subnet ('any'). Not sure if that's allowed. Either way it looks like i've got some good options to try. Thank you! -andy On 10/15/14 3:50 PM, Ben Dale bd...@comlinx.com.au wrote: I've certainly had no issue with stability using route-based VPN. As far as multiple subnet (proxy-id / traffic selectors) support, as of 12.1X46-D10 this is now native in Junos - http://kb.juniper.net/InfoCenter/index?page=contentid=KB28820 and is dead simple to configure. If you're a little gun shy on 12.1X code and are still running old-faithful builds like 11.4RLate, then there are a couple of options: - If your subnets are contiguous, just widen the mask to include them in a single crypto-map on the Cisco side (even if that means widening the mask a LOT) - If your subnets are arbitrarily selected from different RFC1918 blocks (DOH!), then create separate P2 bindings for each subnet: http://kb.juniper.net/InfoCenter/index?page=contentid=KB20543 just be aware that this will only work if the multiple subnets are on the Cisco side (which seems to be true in your case) There are a few other hacks out there using FBF as well. J-NET has some good material: http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-multiple-proxy-ID-on -route-based-VPN-with-multiple-local/td-p/172002/page/2 Cheers, Ben On 16 Oct 2014, at 8:35 am, Andy Litzinger andy.litzin...@theplatform.com wrote: I'd happily use route-based vpns if they are supported in my use case. Based on Kbs and internet lore, it seemed policy based was the best bet for stability. My two tunnel endpoint devices are the SRX and a Cisco ASA. On the SRX side I've got a single subnet but on the ASA side I've got two subnets. I would happily use a simple policy on the ASA side like 'permit ip any SRX side IP subnet SRX side mask' if i was confident I wasn't going to have squirrely issues with connectivity. What do you think? -andy On 10/15/14 3:22 PM, Ben Dale bd...@comlinx.com.au wrote: Hi Andy, I have come across this exact issue using the feature. There was a good reason why we didn't use default address selection that escapes me just now, but I had a slight advantage in that I was using route-based VPNs, so I was able to number the st0 interface with a /32 from the corporate range and source my queries from there. Unfortunately policy-based VPNs are extremely limiting when it comes to things like this. I can't think of too many scenarios where I'd even use them any more. If you don't have too many sites, I'd seriously consider migrating them across. Cheers, Ben On 16 Oct 2014, at 1:28 am, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hello, is anyone out there using the dns-proxy feature for the branch SRX? Are there any clever tricks for specifying the source address the SRX uses to query name servers? It does not appear to be a config option. with the default config it appears to use the IP of the outbound interface. If I add the config statement 'set system default address selection' i can influence it to use the lo0.0 address, which can solve my issue, but not in a way i prefer. my exact problem is the following: I have an SRX 220H in a remote office. It has an trust and untrust zone. users sit on the trust zone and receive dhcp from the SRX and use the SRX as their default gateway and dns server. There is a policy based vpn that connects from the untrust zone to our corp HQ. I have the dns-proxy config set up so that if a dns request is going to an intranet zone, e.g. corp.example.com, then it should use DNS servers that live across the tunnel in our corp HQ. If they are looking up anything else, they use google dns servers. here's the relevant config: dns-proxy { interface { interface facing users; } default-domain * { forwarders { 8.8.8.8; 8.8.4.4; } } default-domain corp.example.com { forwarders { corp hq name server1; corp hq name server 2; } } } the problem is without the 'default address selection' set the SRX tries to use the untrust interface IP as the source IP to query our corp HQ name servers, but the traffic doesn't enter the tunnel because it doesn't match the vpn policy. And I can't change the policy to allow it because the untrust interface IP is the endpoint of the tunnel. It looks like the source zone of the dns query is junos-host- is it possible maybe to set up a junos-host zone to untrust zone NAT when going to corp-hq IP space? or is there another clever solution? thanks! -andy
Re: [j-nsp] Drawbacks when using QFX5100 and EX4300 in mixed VCF mode
+1 regarding input on VCF Does anyone have any practical experience with a VCF either mixed-mode or not? We're evaluating it as a replacement for legacy 6509s. Cisco is pitching a Nexus 6004 + FEX solution. regards, -andy On Tue, Aug 19, 2014 at 8:54 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: * Sebastian Wiesinger juniper-...@ml.karotte.org [2014-08-19 17:51]: Hello, Juniper supports mixing QFX5100 and EX4300 in a Virtual Chassis Fabric mixed mode but they talk about some vague performance and/or impact when doing so: Aaand after I sent this, I get the link to a page listing the features for mixed/non-mixed VCF: http://www.juniper.net/techpubs/en_US/junos13.2/topics/reference/general/ex-qfx-series-software-features-overview-vcf.html Still, if someone has practical input on VCF in general or caveats I'd like to hear it. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] SRX Active/Passive cluster with redundant route based IPSec - connectivity to AWS VPC
Hi All, Two related questions. I have a pair of SRX 3400s in an Active/Passive cluster. They rely on an external gateway for internet access (i.e. my ISPs don't terminate on the SRXs). I am setting up redundant tunnels to an AWS VPC. Amazon has an example for J-Series ( http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Juniper.html), but I don't think it's for a cluster set-up. Here are my questions: 1 - If I want to set up a redundant secure tunnel interface (e.g. st0), should i bind it to an reth interface? 2 - Has anyone connected an Active/Passive SRX cluster to an AWS VPC? Any tips or tricks you care to share? regards, -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX Active/Passive cluster with redundant route based IPSec - connectivity to AWS VPC
Hi Morgan, I presume that with regards to the loopback you are referring to the external interface I use as my IPSec peer toward Amazon? what about the internal logical st interface that I need to create in order to route my internal traffic into the tunnel? How do I make that redundant? thanks! -andy On Mon, May 5, 2014 at 3:30 PM, Morgan McLean wrx...@gmail.com wrote: Use your loopback and put that in a reth. Thanks, Morgan On Mon, May 5, 2014 at 3:23 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi All, Two related questions. I have a pair of SRX 3400s in an Active/Passive cluster. They rely on an external gateway for internet access (i.e. my ISPs don't terminate on the SRXs). I am setting up redundant tunnels to an AWS VPC. Amazon has an example for J-Series ( http://docs.aws.amazon.com/AmazonVPC/latest/NetworkAdminGuide/Juniper.html ), but I don't think it's for a cluster set-up. Here are my questions: 1 - If I want to set up a redundant secure tunnel interface (e.g. st0), should i bind it to an reth interface? 2 - Has anyone connected an Active/Passive SRX cluster to an AWS VPC? Any tips or tricks you care to share? regards, -andy ___ 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] SA SSL VPN vulnerable to Heartbleed?
I opened a JTAC case for the same issue. JTAC said their security team is aware of the CVE and they are waiting for fix/recommendation. -andy On 4/8/14 2:51 PM, David B Funk dbf...@engineering.uiowa.edu wrote: We have a SA4500 SSL VPN box with the JTAC recommended 7.4R8.0 release. Testing by tools such as https://www.ssllabs.com/ssltest/; shows it to be vulnerable to the Heartbleed attack (http://heartbleed/). Checking software downloads at juniper.net does not even seem to have an alert for this problem, let alone a fix. Does Juniper have a clue about this? Is anybody else worried? -- Dave Funk University of Iowa dbfunk (at) engineering.uiowa.eduCollege of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include std_disclaimer.h Better is not better, 'standard' is better. B{ ___ 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] SA SSL VPN vulnerable to Heartbleed?
Sounds like an advisory is coming today: The Juniper SIRT is fully aware of the vulnerability and Engineering is working on fixes for affected releases of Junos OS and IVE OS. Juniper will be providing an out-of-cycle advisory (JSA) on this issue later today (April 8th, 2014). Junos OS 13.3 and above use OpenSSL 1.0.1 which is affected by this vulnerability, while earlier versions use OpenSSL 0.9.8 and are unaffected by this vulnerability. SA 7.4r1 and UAC 4.4r1 are also confirmed as vulnerable, since they use OpenSSL 1.0.1. PR 981102 has been submitted for Junos to upgrade OpenSSL to 1.0.1g, and PR 981148 has been submitted for IVE OS to disable TLS heartbeat. SSL VPN (IVEOS) 7.3, 7.2, and 7.1 are not vulnerable On Apr 8, 2014, at 3:41 PM, Andy Litzinger andy.litzin...@theplatform.com wrote: I opened a JTAC case for the same issue. JTAC said their security team is aware of the CVE and they are waiting for fix/recommendation. -andy On 4/8/14 2:51 PM, David B Funk dbf...@engineering.uiowa.edu wrote: We have a SA4500 SSL VPN box with the JTAC recommended 7.4R8.0 release. Testing by tools such as https://www.ssllabs.com/ssltest/; shows it to be vulnerable to the Heartbleed attack (http://heartbleed/). Checking software downloads at juniper.net does not even seem to have an alert for this problem, let alone a fix. Does Juniper have a clue about this? Is anybody else worried? -- Dave Funk University of Iowa dbfunk (at) engineering.uiowa.eduCollege of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include std_disclaimer.h Better is not better, 'standard' is better. B{ ___ 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] Least impactful way to migrate from private ASN to public ASN
We have two MX80 routers that currently each have an eBGP neighbor to the same upstream ISP and are iBGP neighbors. We are using the same internal ASN for both iBGP and eBGP. It's the autonomous-system number defined under routing-options. We're adding a second peer and have recently received our public AS from RIPE. Currently we are only receiving default routes from our upstream ISP. The new peer will only be advertising a small section of their space to us. With respect to configuration changes on the MX80s, what is the least impactful way to move from the private ASN to the public? since we're only receiving default routes is it enough to simply change the ASN on one router at a time while coordinating the change with the ISP at the same time? I presume my iBGP session will break until i replicate the same change on the other side, but will that really impact anything in this case? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP neighbor link failure detection
Hi Payam, yes the logs clearly show that the failures start after the link goes down. We have external monitors set up via a 3rd party monitoring ASP that watch our various services. Some, but not all, of them reported connection issues for about 4 minutes. We also run 'rpm' probes from the MX80s toward 4 different destinations. The MX80 that had the peer go down logged all 4 of these probes failing for 2m 48s. The probes are set with a test-interval of 60, probe-count of 10 and a total-loss threshold of 1. Our 2nd MX80 did not have any rpm probes fail. It is an eBGP peer with another provider taking full routes and an iBGP peer with the other MX80. Here is the sequence of events (fictional time starting at 0s) 0m0s - MX80 A logs interface toward neighbor is down - tfeb0 UPDN msg to kernel for ifd:xe-x/x/x, flag:2, speed: 0, duplex:0 0m0s - MX80 A logs BGP neighbor state change - rpd[1344]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x (External AS Y) changed state from Established to Idle (event Stop) 0m2s - First rpm icmp probe logs failure - rmopd[1348]: PING_PROBE_FAILED: pingCtlOwnerIndex = ICMP-Probe, pingCtlTestName = our-probe-name 0m2s - 3m48s - all icmp probes fail 3m48s - First rpm icmp probe succeeds mopd[1348]: PING_TEST_COMPLETED: pingCtlOwnerIndex = ICMP-Probe, pingCtlTestName = our-probe-name 12m12s - MX80 A logs interface toward neighbor is up - tfeb0 UPDN msg to kernel for ifd:xe-x/x/x, flag:1, speed: 0, duplex:0 12m15s - MX80 A logs BGP neighbor state change to Established - rpd[1344]: RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer x.x.x.x (External AS Y) changed state from OpenConfirm to Established (event RecvKeepAlive) -andy On Thu, Mar 13, 2014 at 5:17 PM, Payam Chychi pchy...@gmail.com wrote: Are you sure? Ive never seen an update to remove routes take 3min. Andy, are you sure the 3min outage was after the link hard down and not just prior? Guessing this is easy to find due to time stamps. Ive seen this due to line protocol down and everything blackholes until bgp fails but never a 3mim wait for route withdraw (unless this is a peering router with dozens of peers and full routes on each) Hope you fins root cause -- Payam Chychi Network Engineer / Security Specialist On Thursday, March 13, 2014 at 4:50 PM, Andy Litzinger wrote: Hi Chris, yes, i am taking full routes from this neighbor. is there any way to reduce the time it takes to handle the updates? if i wanted to test this behavior in my lab, what would i want to watch? (logs/traceoptions) i don't think I've seen this behavior during scheduled maintenance- for example during times when i've deactivated the neighbor config. Am I correct in thinking this is because in this scenario even though the RE is taking awhile to remove the routes from the FIB the actual next hop router is still available and thus the routes are still valid? -andy On Thu, Mar 13, 2014 at 3:54 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, Andy Litzinger andy.litzinger.li...@gmail.com said: what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Are you taking full routes from this neighbor? It takes a while for the routing engine to send updates to remove/replace 200k+ prefixes to the forwarding engine. -- Chris Adams c...@cmadams.net ___ 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] eBGP neighbor link failure detection
Hi John, you might be spot on- graceful restart is configured for this peer and it does look like my side is respecting it: show bgp neighbor snip Options: Preference HoldTime AuthKey GracefulRestart LogUpDown PeerAS Refresh I'll let you know what I find out -andy On Thu, Mar 13, 2014 at 7:10 PM, John Neiberger jneiber...@gmail.comwrote: I've only seen something like this once and it was a graceful restart issueerfeature on a Cisco router, so I doubt it's the same problem here. In that situation, the router waited for a graceful restart timer to expire before it would clear out the routes, and it was doing this despite the fact that it had never received a signal that the other side was doing a graceful restart. It seems unlikely that you'd be seeing the same type of problem, but the symptoms sound very similar. John On Thu, Mar 13, 2014 at 3:38 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: One of my providers (and eBGP neighbor) recently had a hardware failure which caused the port that connects our two routers to go down. My router did detect the link failure and BGP pretty much immediately transitioned to an Idle state. my side is a Juniper MX80 running 11.4, their side I believe is a Cisco 6509. what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Is this normal behavior? is the behavior configurable? I thought it might be related to the BGP holdtime, but that appears to be set for 30 seconds. I see that cisco has a feature called 'fast-external-fallover' that bypasses the hold-down timer. Is there an equivalent in JunOS? what is the Juniper best practice to handle link failure between eBGP neighbors? thanks! -andy ___ 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] eBGP neighbor link failure detection
John, do you have any idea how to view the negotiated parameters for Graceful Restart? Or peak into its current state? I tried setting traceoptions: protocols bgp group my-group traceoptions flag graceful-restart detail but that hasn't yielded any log messages. perhaps negotiation only happens at BGP session initiation. is it fair to say that if you are directly connected to your neighbor and that interface goes down that the expected behavior of GR is it should abort and routes from that neighbor should immediately be removed? -andy On Fri, Mar 14, 2014 at 8:52 AM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: Hi John, you might be spot on- graceful restart is configured for this peer and it does look like my side is respecting it: show bgp neighbor snip Options: Preference HoldTime AuthKey GracefulRestart LogUpDown PeerAS Refresh I'll let you know what I find out -andy On Thu, Mar 13, 2014 at 7:10 PM, John Neiberger jneiber...@gmail.comwrote: I've only seen something like this once and it was a graceful restart issueerfeature on a Cisco router, so I doubt it's the same problem here. In that situation, the router waited for a graceful restart timer to expire before it would clear out the routes, and it was doing this despite the fact that it had never received a signal that the other side was doing a graceful restart. It seems unlikely that you'd be seeing the same type of problem, but the symptoms sound very similar. John On Thu, Mar 13, 2014 at 3:38 PM, Andy Litzinger andy.litzinger.li...@gmail.com wrote: One of my providers (and eBGP neighbor) recently had a hardware failure which caused the port that connects our two routers to go down. My router did detect the link failure and BGP pretty much immediately transitioned to an Idle state. my side is a Juniper MX80 running 11.4, their side I believe is a Cisco 6509. what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Is this normal behavior? is the behavior configurable? I thought it might be related to the BGP holdtime, but that appears to be set for 30 seconds. I see that cisco has a feature called 'fast-external-fallover' that bypasses the hold-down timer. Is there an equivalent in JunOS? what is the Juniper best practice to handle link failure between eBGP neighbors? thanks! -andy ___ 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] eBGP neighbor link failure detection
One of my providers (and eBGP neighbor) recently had a hardware failure which caused the port that connects our two routers to go down. My router did detect the link failure and BGP pretty much immediately transitioned to an Idle state. my side is a Juniper MX80 running 11.4, their side I believe is a Cisco 6509. what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Is this normal behavior? is the behavior configurable? I thought it might be related to the BGP holdtime, but that appears to be set for 30 seconds. I see that cisco has a feature called 'fast-external-fallover' that bypasses the hold-down timer. Is there an equivalent in JunOS? what is the Juniper best practice to handle link failure between eBGP neighbors? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] eBGP neighbor link failure detection
Hi Chris, yes, i am taking full routes from this neighbor. is there any way to reduce the time it takes to handle the updates? if i wanted to test this behavior in my lab, what would i want to watch? (logs/traceoptions) i don't think I've seen this behavior during scheduled maintenance- for example during times when i've deactivated the neighbor config. Am I correct in thinking this is because in this scenario even though the RE is taking awhile to remove the routes from the FIB the actual next hop router is still available and thus the routes are still valid? -andy On Thu, Mar 13, 2014 at 3:54 PM, Chris Adams c...@cmadams.net wrote: Once upon a time, Andy Litzinger andy.litzinger.li...@gmail.com said: what surprised me is that it looks like routes toward that provider were not immediately removed from my routing table. Instead i see evidence of blackholing for almost 3 minutes. Are you taking full routes from this neighbor? It takes a while for the routing engine to send updates to remove/replace 200k+ prefixes to the forwarding engine. -- Chris Adams c...@cmadams.net ___ 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] Multicast/Broadcast Packets going to EX CPU
Chris, can you elaborate on why low TTL on multicast frames will cause high CPU? Sebastien, as Chris pointed out anything in the 224.0.0.0/24 will hit the CPU, but so will a few other ranges that fall into the Link-Local block. This is a good guide someone else on the list forwarded me a few months back: http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml#wp1002391 do you have any other multicast sources hitting the 4500? I kind of doubt you've got enough VRRP traffic to peg your CPU. I believe you can put a multicast policier in your lo0 filter, but you need to size it appropriately to allow the multicast required in your network (including things like VRRP). HTH, -andy From: juniper-nsp [juniper-nsp-boun...@puck.nether.net] on behalf of Chris Evans [chrisccnpsp...@gmail.com] Sent: Wednesday, March 05, 2014 6:52 AM To: Juniper NSP Subject: Re: [j-nsp] Multicast/Broadcast Packets going to EX CPU low TTL on the multicast frames will cause this.. Also the multicast destination addresses will do this too if they're in 224.0.0.0/24 On Wed, Mar 5, 2014 at 8:49 AM, Sebastian Wiesinger juniper-...@ml.karotte.org wrote: Hello, I'm currently looking at an EX4500 setup that had a few problems related to multicast/broadcast packets going to the CPU (and sometimes preventing required packets like LACP reaching the CPU) of the switch. I assume this was because the queue between PFE and CPU was full (is there a way to check?). I noticed that multicast and broadcast packets in all VLANs are sent to the CPU. My question is why? IGMP snooping and VSTP is not enabled on the switch and apart from that I don't see an apparent reason why it should do this for tagged frames. Example of packets being sent to the CPU includes VRRP packets from attached routers (DMAC 01:00:5e:00:00:12) and BOOTP/DHCP (DMAC ff:ff:ff:ff:ff:ff) packets. Would an lo0 firewall filter help? Is this applied before or after the packets are sent over the PFE-CPU link? Perhaps you could share your ideas on how this could be prevented and what you're doing to protect the CPU on these EX boxes. Regards Seastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant ___ 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] Procedure to add a NPC to SRX HA cluster
Hi Muhammad, yes, JTAC agrees with you :). We installed the NPCs using the KB procedure today and had no issues. thanks! -andy From: Muhammad Atif Jauhar [mailto:atif.jau...@gmail.com] Sent: Saturday, November 16, 2013 10:54 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Procedure to add a NPC to SRX HA cluster Hi Andy, As per your procedure, Once you boot up node 1 after installing NPC, there will be mismatch in hardware spics of both firewall which will cause cluster issue. Cluster will not comes up if there is mismatch in JUNOS, Hardware even modules are not installed on same slots. Best solution is provided by JTAC. Regards, Muhammad Atif Jauhar On Wed, Nov 13, 2013 at 1:32 AM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: can anyone recommend a procedure to add an NPC card to an SRX HA (active/standby) cluster? In this case it's a pair of SRX3400s, running 12.1X44-D10.4 I've only got two redundancy groups, RG0(control) and RG1(data). Currently the only NPC in each SRX is the integrated NPC-IOC 10GbE card in each chassis Node0 is primary for both RG0 and RG1. I'm not currently running any dynamic routing protocols. There are some Policy based VPNs, ALGs and NATs in place. Can I do something like the following? * power down node 1, install the NPC, boot up and verify status * manually fail RG1 to node1 via request chassis cluster failover * manually fail RG0 to node1 via request chassis cluster failover (is the best way to do this?) * power down node 1, install NPC, boot up and verify status * fail both RG1 and RG0 back to node0 JTAC's first response was to follow this guide: http://kb.juniper.net/InfoCenter/index?page=contentid=KB26674 which seems overly complicated and possibly not applicable. It seems to deal with the case of wanting to move a live SPC from one slot to another. They say it applies to an NPC- but I'm not moving a live NPC, I'm inserting a new one. thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto: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] SRX fab links through EX VC- seeing enumerating MAC addresses
an update- we finally moved our SRX fab links off of the EX switch and the CPU load on the EX did not change. -andy -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Andy Litzinger Sent: Saturday, October 05, 2013 7:51 AM To: Phil Fagan Cc: juniper-nsp Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses I believe it was set vlans vlan name disable-Mac-learning Xe-2 is not the backup RE. 1 3 are the primary and backups respectively. -andy On Oct 4, 2013, at 6:59 PM, Phil Fagan philfa...@gmail.commailto:philfa...@gmail.com wrote: What was the syntax to kill the learning? This is indeed a strange one. I wonder if it would happen on a stand alone switch vs VC. Also is xe-2 your backup for the VC? Wonder if its busy pushing tables to the backup. On Oct 4, 2013 5:50 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: While I was logged in planning to configure the mac address aging you suggested I noticed there is another knob to completely disable mac learning on the vlan. Since there are only two ports on this vlan and they're only sending to each other anyway they should really need to learn any macs. so I disabled it and let it run for 1 minute (via commit confirm 1). The entries dropped out of the mac-learning-log, but it didn't have any noticeable impact on my CPU. the mac enumeration still seems like a weird deal though. I'll report back anything JTAC uncovers. -andy From: Phil Fagan [mailto:philfa...@gmail.commailto:philfa...@gmail.com] Sent: Friday, October 04, 2013 2:52 PM To: Andy Litzinger Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses Very little is said other than indeed using MAC addresses is how the cluster speaks via the FAB http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNote v2.pdf As you noted direct connect FAB is ideal; but a very very interesting find. Its possible there is a correct aging for your SRX VLAN that might help the CPU. https://www.juniper.net/techpubs/en_US/junos/topics/reference/configur ation-statement/mac-table-aging-time-bridging.html On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: Hi, while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC engineer noticed that one pair of ports is making changes to the MAC learning table at an alarming rate. My SRX3400 fab links are connected to the ports in question (I'm waiting on parts to correct this and directly connect the fab ports). If you watch the mac-learning-log it looks like the SRX is sending packets over the fab link that use a private/fake Ethernet address and are quickly enumerating through a list of Ethernet addresses. Has anyone else ever seen this? is there a way to stop it or minimize its potential effect on the switch cpu? Note that it's not yet proven this is the source of the high cpu. show ethernet-switching mac-learning-log snip Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00
[j-nsp] Procedure to add a NPC to SRX HA cluster
can anyone recommend a procedure to add an NPC card to an SRX HA (active/standby) cluster? In this case it's a pair of SRX3400s, running 12.1X44-D10.4 I've only got two redundancy groups, RG0(control) and RG1(data). Currently the only NPC in each SRX is the integrated NPC-IOC 10GbE card in each chassis Node0 is primary for both RG0 and RG1. I'm not currently running any dynamic routing protocols. There are some Policy based VPNs, ALGs and NATs in place. Can I do something like the following? * power down node 1, install the NPC, boot up and verify status * manually fail RG1 to node1 via request chassis cluster failover * manually fail RG0 to node1 via request chassis cluster failover (is the best way to do this?) * power down node 1, install NPC, boot up and verify status * fail both RG1 and RG0 back to node0 JTAC's first response was to follow this guide: http://kb.juniper.net/InfoCenter/index?page=contentid=KB26674 which seems overly complicated and possibly not applicable. It seems to deal with the case of wanting to move a live SPC from one slot to another. They say it applies to an NPC- but I'm not moving a live NPC, I'm inserting a new one. thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX1400 Forward Proxy
If you want your browser to support a self-signed cert you probably need to import it into your OS's trusted certificate store. In some cases you might be able to import it into your browsers trusted CA store, but I think for a self-signed (vs local CA signed) will have to be imported into your OS's trusted certificate store. hth, -andy -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of EZ Joe Sent: Wednesday, October 16, 2013 1:46 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] SRX1400 Forward Proxy Hi, Have anyone tried using SSL Forward proxy on High end SRX? I've tested using self signed openssl cert, but having problem with the browser reporting certificate not trusted. Is there anyway to workaround this? With Regard EZ Joe - Via Aiped ___ 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] SRX fab links through EX VC- seeing enumerating MAC addresses
I believe it was set vlans vlan name disable-Mac-learning Xe-2 is not the backup RE. 1 3 are the primary and backups respectively. -andy On Oct 4, 2013, at 6:59 PM, Phil Fagan philfa...@gmail.commailto:philfa...@gmail.com wrote: What was the syntax to kill the learning? This is indeed a strange one. I wonder if it would happen on a stand alone switch vs VC. Also is xe-2 your backup for the VC? Wonder if its busy pushing tables to the backup. On Oct 4, 2013 5:50 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: While I was logged in planning to configure the mac address aging you suggested I noticed there is another knob to completely disable mac learning on the vlan. Since there are only two ports on this vlan and they’re only sending to each other anyway they should really need to learn any macs. so I disabled it and let it run for 1 minute (via commit confirm 1). The entries dropped out of the mac-learning-log, but it didn’t have any noticeable impact on my CPU. the mac enumeration still seems like a weird deal though. I’ll report back anything JTAC uncovers. -andy From: Phil Fagan [mailto:philfa...@gmail.commailto:philfa...@gmail.com] Sent: Friday, October 04, 2013 2:52 PM To: Andy Litzinger Cc: juniper-nsp@puck.nether.netmailto:juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses Very little is said other than indeed using MAC addresses is how the cluster speaks via the FAB http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNotev2.pdf As you noted direct connect FAB is ideal; but a very very interesting find. Its possible there is a correct aging for your SRX VLAN that might help the CPU. https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/mac-table-aging-time-bridging.html On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: Hi, while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC engineer noticed that one pair of ports is making changes to the MAC learning table at an alarming rate. My SRX3400 fab links are connected to the ports in question (I'm waiting on parts to correct this and directly connect the fab ports). If you watch the mac-learning-log it looks like the SRX is sending packets over the fab link that use a private/fake Ethernet address and are quickly enumerating through a list of Ethernet addresses. Has anyone else ever seen this? is there a way to stop it or minimize its potential effect on the switch cpu? Note that it's not yet proven this is the source of the high cpu. show ethernet-switching mac-learning-log snip Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was learned on xe-2/0/28.0 the EX port config: show configuration interfaces xe-0/0/28 Oct 04 13:00:13 description srx01-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } show configuration
[j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses
Hi, while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC engineer noticed that one pair of ports is making changes to the MAC learning table at an alarming rate. My SRX3400 fab links are connected to the ports in question (I'm waiting on parts to correct this and directly connect the fab ports). If you watch the mac-learning-log it looks like the SRX is sending packets over the fab link that use a private/fake Ethernet address and are quickly enumerating through a list of Ethernet addresses. Has anyone else ever seen this? is there a way to stop it or minimize its potential effect on the switch cpu? Note that it's not yet proven this is the source of the high cpu. show ethernet-switching mac-learning-log snip Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was learned on xe-2/0/28.0 the EX port config: show configuration interfaces xe-0/0/28 Oct 04 13:00:13 description srx01-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } show configuration interfaces xe-2/0/28 Oct 04 13:32:52 description srx02-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } SRX: srx01 show configuration interfaces fab0 fabric-options { member-interfaces { xe-1/0/1; } } srx01 show configuration interfaces fab1 fabric-options { member-interfaces { xe-9/0/1; } } srx01 show configuration interfaces xe-1/0/1 srx01 show configuration interfaces xe-9/0/1 srx01 thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses
While I was logged in planning to configure the mac address aging you suggested I noticed there is another knob to completely disable mac learning on the vlan. Since there are only two ports on this vlan and they’re only sending to each other anyway they should really need to learn any macs. so I disabled it and let it run for 1 minute (via commit confirm 1). The entries dropped out of the mac-learning-log, but it didn’t have any noticeable impact on my CPU. the mac enumeration still seems like a weird deal though. I’ll report back anything JTAC uncovers. -andy From: Phil Fagan [mailto:philfa...@gmail.com] Sent: Friday, October 04, 2013 2:52 PM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX fab links through EX VC- seeing enumerating MAC addresses Very little is said other than indeed using MAC addresses is how the cluster speaks via the FAB http://forums.juniper.net/jnet/attachments/jnet/srx/1659/1/L2HAAppNotev2.pdf As you noted direct connect FAB is ideal; but a very very interesting find. Its possible there is a correct aging for your SRX VLAN that might help the CPU. https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/mac-table-aging-time-bridging.html On Fri, Oct 4, 2013 at 2:45 PM, Andy Litzinger andy.litzin...@theplatform.commailto:andy.litzin...@theplatform.com wrote: Hi, while troubleshooting high CPU on our EX mixed-mode VC (4200 and 4550) our JTAC engineer noticed that one pair of ports is making changes to the MAC learning table at an alarming rate. My SRX3400 fab links are connected to the ports in question (I'm waiting on parts to correct this and directly connect the fab ports). If you watch the mac-learning-log it looks like the SRX is sending packets over the fab link that use a private/fake Ethernet address and are quickly enumerating through a list of Ethernet addresses. Has anyone else ever seen this? is there a way to stop it or minimize its potential effect on the switch cpu? Note that it's not yet proven this is the source of the high cpu. show ethernet-switching mac-learning-log snip Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:32:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a0:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:50:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:61:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:26:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:17:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:e1:a1:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:21 2013 vlan_name srx_fab_temp mac 00:00:dd:44:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a2:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a3:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:48:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:1b:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:2a:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a4:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:e1:a5:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:22 2013 vlan_name srx_fab_temp mac 00:00:dd:51:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a6:00:00 was learned on xe-2/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:60:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:dd:33:00:00 was deleted on xe-0/0/28.0 Fri Oct 4 12:45:23 2013 vlan_name srx_fab_temp mac 00:00:e1:a7:00:00 was learned on xe-2/0/28.0 the EX port config: show configuration interfaces xe-0/0/28 Oct 04 13:00:13 description srx01-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } show configuration interfaces xe-2/0/28 Oct 04 13:32:52 description srx02-xe-1/0/1; mtu 9216; unit 0 { family ethernet-switching { vlan { members 500; } } } SRX: srx01 show configuration interfaces fab0 fabric-options { member-interfaces { xe-1/0/1; } } srx01 show configuration interfaces fab1 fabric-options { member-interfaces { xe-9/0/1; } } srx01 show configuration interfaces xe-1/0/1 srx01 show configuration interfaces xe-9/0/1 srx01 thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.netmailto:juniper-nsp
[j-nsp] expected multicast forwarding behavior with igmp-snooping and local igmp querier
maybe this will simply turn out to be a gap in my understanding about multicast addressing, but my EX4550/4200 VC is not pruning multicast how I would expect. I have vlan defined with an RVI. I have enabled igmp for that vlan interface. I have two hosts that are members of the same vlan (server A and server B, vlan 123). igmp-snooping is on for all vlans (factory default setting). I am using iperf to send/receive test multicast streams from server A to server B. With igmp-snooping and igmp running on the vlan, If I send a stream via iperf from server A, I do not expect that stream to show up on server B until I start the iperf server at the same multicast address. I expect the switch to not flood the traffic to all ports in the vlan (including serverB ) but instead wait until a server explicitly joins the group. This does not appear to always be true. I obviously haven't tested every multicast address, but it seems that pretty much all multicast traffic directed to 224.0.0.0-239.0.0.255 will cause the switch to flood traffic to all ports in the vlan. But addresses from 239.0.1.0 and up seem to work as I expect. If server A sends to 239.0.1.1 and I listen for traffic to that address on server B, I don't see anything. It seems the switch is pruning as I would expect. As soon as I start the multicast iperf listener on server B for 239.0.1.1 then my tcpdump immediately lights up with the multicast traffic- again as I would expect. In fact the opposite behavior seems to occur- with the 239.0.1.1 address, if I don't have igmp configured on the vlan at all (delete protocols igmp interface vlan.123) the switch does NOT flood multicast traffic for that address. I see nothing arrive on server B. this is also unexpected. can anyone set me straight? also- what I'm trying to do is relatively simple but maybe I'm going about it the wrong way. I have groups of servers in the vlan that use multicast packets as a periodic heartbeat to keep track of each other. I'd like to make sure the multicast heartbeat only goes to other servers that subscribe to the same multicast address- not send it to every server in the vlan. does my config seem like a valid way to do this? I don't need to route the multicast across subnets. thanks! -andy here are the relevant config snippets and the iperf and tcpdump commands I'm using: # show vlans 123 vlan-id 123; l3-interface vlan.123; # show interfaces vlan.123 family inet { address x.x.x.x/24; } # show protocols igmp { interface vlan.123; } igmp-snooping { vlan all; } iperf client (sender): iperf -c 239.0.1.1 -u --ttl 2 -t 30 -i 5 iperf server (receiver): iperf -s -u -B 239.10.1.1 -i 5 tcpdump example: tcpdump -nn host 239.0.1.1 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] Framing errors on down interfaces (MX480, 12.3R3.4, MPC4E-3D-32XGE)
Hi, folks, Anyone else seeing interface error count increase on down (unpatched, no optic!) 10GE interfaces using this combination of hardware and software ? - MX480 - 12.3R3.4 (12.3 required for the 32XGE card) - MPC4E 3D 32XGE I reset the stats and saw the following after an hour : andyd@xx show interfaces xe-2/1/1 extensive Physical interface: xe-2/1/1, Enabled, Physical link is Down Link-level type: Ethernet, MTU: 1514, LAN-PHY mode, Speed: 10Gbps, BPDU Error: None, Loopback: None, [...] Input errors: Errors: 11, Drops: 0, Framing errors: 11, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0, Resource errors: 0 Output errors: Carrier transitions: 0, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0 Any explanation ? Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509
I've had some progress while working with JTAC-thought I'd share. JTAC pointed out that one of the interfaces I was trying to LAG was not even coming online. The Cisco side seemed to think it auto-negotiated happily to 1000/Full (but still added it to an independent port-channel); the Juniper side was marking it down with auto-negotiated speed/duplex at 10/Half. Obviously we suspected a cabling issue. Rather than drive to the datacenter (a good engineer never leaves their desk, right?) I decided to try and replicate the config on the other node in the cluster. so I removed the broken interface from LAG1 on the cisco end and made node0 the primary node for RG1. I then configured the LAG on node1 and lo and behold, it came online immediately. so I failed the RG1 back to node1 and traffic flowed with no issues. node0's issue is almost certainly cable related, right? well... So I decided to play around with LAG1 on node0 again for a bit to see if I could get it to work. No dice. While messing with the config I left both ports out of the LAG on the cisco side and forgot to put the working link back into the LAG. I decided to press my luck with my new discovery and configure the 2nd LAG group I needed online. As before I wanted to first set the LAG up on the standby node (node0 at this point) and make sure LACP was happy before putting traffic on it. The 2nd LAG on node0 came up with both interfaces with no issues. I failed RG1 back to node 0, and because I forgot to put my port back into LAG1 on the cisco side I started blackholing traffic. No problem- I failed the RG back to node1 and then went to add the previously working port back to LAG1 on the cisco side. At this point the interface refused to come up on the SRX side. ge-0/0/4, which had been working previously, suddenly was acting just like ge-0/0/6. Now the 'bad-cable' idea was kind of out the window. I spent another hour on the phone with JTAC. They wanted me to go down and swap in new cables which I said I could do tomorrow. In the meantime I made a discovery- If I removed the 'redundant-parent reth0' from both ge-0/0/4 and ge-0/0/6, and commited, the interfaces both immediately came up though not part of the LAG of course. Then if I re-added them to reth0 and re-commited the config- both links stayed up and immediately formed a proper LACP LAG with the 6509. WTH?!! so I failed RG1 over to node0- things ran smoothly. Now I only had one more LAG to configure, LAG2 on node1. I added the second interface on both sides of the config and had the same issue- the 6509 thought the new link was a-ok and 1000/Full, but added it as an independent member of the LAG. The SRX marked the link down with 10/Half. Once again I removed the 'redundant-parent reth1' statement from both interfaces and commited. Once again both interfaces came right up (or stayed up in the case of the already working interface). Next I re-added the statements and re-commited and Voila, a working LAG... I'll be working more with JTAC tomorrow. Although things are working I worry that they are in a fragile state and any failure of a LAG member may cause an LACP disagreement between the 6509 and the SRX or force me to remember the weird workaround to get things back online. Also, although I don't know how reproducible this is for others, it seems like I may have hit a bug somewhere. -andy -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Andy Litzinger Sent: Thursday, August 15, 2013 3:55 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509 Has anyone had any difficulty creating a port channel between an SRX cluster (in this case, SRX 550s) and Cisco switches (in this case 6509s, non-VSS)? When I tried to bring up a second link in the link agg group the cisco side put it in state I which means: standalone. It also logged this message: %EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with aggregators in channel 10 and cannot attach to them (flow control send of Gi8/2 is on, Gi8/1 is off) I did some googling and found a couple articles that seemed to say that the SRX doesn't support flow-control so I tried turning it off on the cisco side.: interface 8/1 flowcontrol send off interface 8/2 flowcontrol send off interface po10 flowconftorl send off This didn't help and when I shut/no shut the port channel on the cisco side the whole thing went offline and wouldn't come back until I rebuilt it. any ideas? SRX-A connects to 6509-A with 2 physical links bundled into reth0 SRX-B connects to 6509-B with 2 physical links bundled into reth0 SRX side config: show configuration interfaces ge-0/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-0/0/6 gigether-options { redundant-parent reth0; } show configuration
Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509
Hi Per, thanks for your suggestion. I've set it up this way because I'm following this kb: https://kb.juniper.net/InfoCenter/index?page=contentid=KB22474 it's not exactly apples to apples since I'm not connecting to an EX and I'm connecting to two switches instead of one, but I don't think those details matter in this case. Also, several people have pointed out that in the config I posted I had a difference with the channel mode (active vs passive) on the cisco side between the two ports I'm trying to aggregate. I apologize- that is just the state I left it in during troubleshooting. you'll note that the second interface, 8/2, is also actually shutdown in the config I posted. I have tried setting both to active and both to passive with no luck. -andy -Original Message- From: Per Westerlund [mailto:p...@westerlund.se] Sent: Friday, August 16, 2013 12:54 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509 The components of the SRX RETH-interfaces are not all active at the same time, this is a fail-over construct. One active link at the time. You should be looking at the AE-interfaces instead, they are proper LACP aggregators. /Per 16 aug 2013 kl. 00:55 skrev Andy Litzinger andy.litzin...@theplatform.com: Has anyone had any difficulty creating a port channel between an SRX cluster (in this case, SRX 550s) and Cisco switches (in this case 6509s, non- VSS)? When I tried to bring up a second link in the link agg group the cisco side put it in state I which means: standalone. It also logged this message: %EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with aggregators in channel 10 and cannot attach to them (flow control send of Gi8/2 is on, Gi8/1 is off) I did some googling and found a couple articles that seemed to say that the SRX doesn't support flow-control so I tried turning it off on the cisco side.: interface 8/1 flowcontrol send off interface 8/2 flowcontrol send off interface po10 flowconftorl send off This didn't help and when I shut/no shut the port channel on the cisco side the whole thing went offline and wouldn't come back until I rebuilt it. any ideas? SRX-A connects to 6509-A with 2 physical links bundled into reth0 SRX-B connects to 6509-B with 2 physical links bundled into reth0 SRX side config: show configuration interfaces ge-0/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-0/0/6 gigether-options { redundant-parent reth0; } show configuration interfaces ge-9/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-9/0/6 gigether-options { redundant-parent reth0; } show configuration interfaces reth0 vlan-tagging; redundant-ether-options { redundancy-group 1; lacp { active; periodic fast; } } unit x { vlan-id x; family inet { address x.x.x.x/zz; } } unit y { vlan-id y; family inet { address x.x.x.x/zz; } } cisco side on 6509-A: interface GigabitEthernet8/1 description srx01-g0/4 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate spanning-tree portfast edge trunk channel-group 10 mode active end interface GigabitEthernet8/2 description srx01-g0/6 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate shutdown spanning-tree portfast edge trunk channel-group 10 mode passive end interface Port-channel10 description srx01-internal switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate spanning-tree portfast edge trunk end the 6509-B config is identical thanks! -andy ___ 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] trouble setting up link agg between clustered SRX 550 and Cisco 6509
12.1R1.9 I'll check out the link, thanks! here's a pretty sparse (only shows the SRX side) config example from the documenation that implies it is possible in 12.1... https://www.juniper.net/techpubs/en_US/junos12.1/topics/example/chassis-cluster-redundant-ethernet-interface-link-aggregation-group-configuring-cli.html -andy -Original Message- From: Per Westerlund [mailto:p...@westerlund.se] Sent: Friday, August 16, 2013 3:07 PM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509 What versions are you running? Apparently L3 support for this type of config was available before the L2 version was ready. Being lazy, and not having access to equipment where I can set this up, I will start with a pointer to someone who did a similar thing a while ago: http://cooperlees.com/blog/?p=401 /Per 16 aug 2013 kl. 17:37 skrev Andy Litzinger andy.litzin...@theplatform.com: Hi Per, thanks for your suggestion. I've set it up this way because I'm following this kb: https://kb.juniper.net/InfoCenter/index?page=contentid=KB22474 it's not exactly apples to apples since I'm not connecting to an EX and I'm connecting to two switches instead of one, but I don't think those details matter in this case. Also, several people have pointed out that in the config I posted I had a difference with the channel mode (active vs passive) on the cisco side between the two ports I'm trying to aggregate. I apologize- that is just the state I left it in during troubleshooting. you'll note that the second interface, 8/2, is also actually shutdown in the config I posted. I have tried setting both to active and both to passive with no luck. -andy -Original Message- From: Per Westerlund [mailto:p...@westerlund.se] Sent: Friday, August 16, 2013 12:54 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509 The components of the SRX RETH-interfaces are not all active at the same time, this is a fail-over construct. One active link at the time. You should be looking at the AE-interfaces instead, they are proper LACP aggregators. /Per 16 aug 2013 kl. 00:55 skrev Andy Litzinger andy.litzin...@theplatform.com: Has anyone had any difficulty creating a port channel between an SRX cluster (in this case, SRX 550s) and Cisco switches (in this case 6509s, non- VSS)? When I tried to bring up a second link in the link agg group the cisco side put it in state I which means: standalone. It also logged this message: %EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with aggregators in channel 10 and cannot attach to them (flow control send of Gi8/2 is on, Gi8/1 is off) I did some googling and found a couple articles that seemed to say that the SRX doesn't support flow-control so I tried turning it off on the cisco side.: interface 8/1 flowcontrol send off interface 8/2 flowcontrol send off interface po10 flowconftorl send off This didn't help and when I shut/no shut the port channel on the cisco side the whole thing went offline and wouldn't come back until I rebuilt it. any ideas? SRX-A connects to 6509-A with 2 physical links bundled into reth0 SRX-B connects to 6509-B with 2 physical links bundled into reth0 SRX side config: show configuration interfaces ge-0/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-0/0/6 gigether-options { redundant-parent reth0; } show configuration interfaces ge-9/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-9/0/6 gigether-options { redundant-parent reth0; } show configuration interfaces reth0 vlan-tagging; redundant-ether-options { redundancy-group 1; lacp { active; periodic fast; } } unit x { vlan-id x; family inet { address x.x.x.x/zz; } } unit y { vlan-id y; family inet { address x.x.x.x/zz; } } cisco side on 6509-A: interface GigabitEthernet8/1 description srx01-g0/4 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate spanning-tree portfast edge trunk channel-group 10 mode active end interface GigabitEthernet8/2 description srx01-g0/6 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate shutdown spanning-tree portfast edge trunk channel-group 10 mode passive end interface Port-channel10 description srx01-internal switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate spanning-tree portfast edge trunk end the 6509
[j-nsp] trouble setting up link agg between clustered SRX 550 and Cisco 6509
Has anyone had any difficulty creating a port channel between an SRX cluster (in this case, SRX 550s) and Cisco switches (in this case 6509s, non-VSS)? When I tried to bring up a second link in the link agg group the cisco side put it in state I which means: standalone. It also logged this message: %EC-SP-5-CANNOT_BUNDLE_LACP: Gi8/2 is not compatible with aggregators in channel 10 and cannot attach to them (flow control send of Gi8/2 is on, Gi8/1 is off) I did some googling and found a couple articles that seemed to say that the SRX doesn't support flow-control so I tried turning it off on the cisco side.: interface 8/1 flowcontrol send off interface 8/2 flowcontrol send off interface po10 flowconftorl send off This didn't help and when I shut/no shut the port channel on the cisco side the whole thing went offline and wouldn't come back until I rebuilt it. any ideas? SRX-A connects to 6509-A with 2 physical links bundled into reth0 SRX-B connects to 6509-B with 2 physical links bundled into reth0 SRX side config: show configuration interfaces ge-0/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-0/0/6 gigether-options { redundant-parent reth0; } show configuration interfaces ge-9/0/4 gigether-options { redundant-parent reth0; } show configuration interfaces ge-9/0/6 gigether-options { redundant-parent reth0; } show configuration interfaces reth0 vlan-tagging; redundant-ether-options { redundancy-group 1; lacp { active; periodic fast; } } unit x { vlan-id x; family inet { address x.x.x.x/zz; } } unit y { vlan-id y; family inet { address x.x.x.x/zz; } } cisco side on 6509-A: interface GigabitEthernet8/1 description srx01-g0/4 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate spanning-tree portfast edge trunk channel-group 10 mode active end interface GigabitEthernet8/2 description srx01-g0/6 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate shutdown spanning-tree portfast edge trunk channel-group 10 mode passive end interface Port-channel10 description srx01-internal switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan x,y switchport mode trunk switchport nonegotiate spanning-tree portfast edge trunk end the 6509-B config is identical thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall filter -EX4500
I think your source ip range netmask should be /0, not /32. I.e: 0.0.0.0/0 On Jul 9, 2013, at 6:19 AM, Brijesh Patel brju.pa...@gmail.com wrote: Hi All, EX4500 firewall filter configuration : Connectivity : F5 Load balancer - Ex4500 -- Internet I want to configure ex firewall filter configuration , requirement as below : 1. Allow from any source/internet to specific *destination address(F5 load balancer) for any* port for the all network address range (i.e. 192.168.246.1/24). Host are specified in *F5Traffic-IP prefi list* My configuration as below : test@lab-EX4500-01# run show configuration firewall family inet filter incoming_traffic term LB-Traffic from { source-address { 0.0.0.0/32; } destination-prefix-list { F5Traffic-IP; } } then accept; test@lab-EX4500-01# run show configuration policy-options prefix-list * F5Traffic-IP* 192.168.246.8/32; 192.168.246.9/32; 192.168.246.225/32; test@lab-EX4500-01 show configuration interfaces vlan.500 family inet { filter { input incoming_traffic; } address 192.168.246.1/24; } Does my configuration will work OR do I need to specify more in destination port ? Pls suggest. Many Thanks , Brijesh Patel ___ 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] Share static routes between routing-instances on EX series
Thanks all for the tips on and off list. I found this KB http://kb.juniper.net/InfoCenter/index?page=contentid=KB23027 which states that it's not possible to leak local direct routes between routing-instances. Apparently it's a limitation of the EX and even the most recent release notes still list it as a limitation. As stated in the KB article the workarounds are FBF and physically connecting the routing-instances. The second method isn't really explained in the KB- I'm not sure I follow how to do that or the related capacity and redundancy implications. Has anyone done it? -andy -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Andy Litzinger Sent: Tuesday, June 18, 2013 4:29 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Share static routes between routing-instances on EX series I have a network that contains two distinct groups of servers. Group1 with subnets A,B Group2 with subnets C,D Both groups use RVIs on a core VC (mix of EX4550s and 4200s) as their default route. There are two different paths out of the network. I'd like Group1 to take path1 and Group2 to take path2. Subnets A,B,C and D should be able to communicate directly, preferably within the VC (not out to another device and back). I can create a routing-instance for each group (or 1 and use the global table for the other). Adding the RVIs and maintaining a separate default route out for each routing-instance is no problem. The trouble is trying to allow the subnets to communicate to each other. I've tried adding a static route under the routing-instance for Group 1 to a subnet outside the routing-instance, e.g. a route to subnet C inside routing- instance for Group1, but the route never shows up in the routing table, presumably because there isn't a live interface in routing-instance C with a connection to subnet C. and it doesn't look like there's an option to make the next-hop an interface instead of an IP. group1-vr { instance-type virtual-router; interface vlan.A; routing-options { static { route C.0/23 next-hop C.1; } } } root@ex# run show route snip group1-vr.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A.0/23 *[Direct/0] 1d 00:52:00 via vlan.A A.1/32 *[Local/0] 1d 00:52:00 Local via vlan.A I will try rib groups next, but I think I read somewhere that EX switches don't support importing static routes via rib groups. I suppose this could also be solved by Filter Based Forwarding, but I'd like to avoid that if possible; it just doesn't seem as clean. thanks in advance! -andy ___ 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] Share static routes between routing-instances on EX series
I have a network that contains two distinct groups of servers. Group1 with subnets A,B Group2 with subnets C,D Both groups use RVIs on a core VC (mix of EX4550s and 4200s) as their default route. There are two different paths out of the network. I'd like Group1 to take path1 and Group2 to take path2. Subnets A,B,C and D should be able to communicate directly, preferably within the VC (not out to another device and back). I can create a routing-instance for each group (or 1 and use the global table for the other). Adding the RVIs and maintaining a separate default route out for each routing-instance is no problem. The trouble is trying to allow the subnets to communicate to each other. I've tried adding a static route under the routing-instance for Group 1 to a subnet outside the routing-instance, e.g. a route to subnet C inside routing-instance for Group1, but the route never shows up in the routing table, presumably because there isn't a live interface in routing-instance C with a connection to subnet C. and it doesn't look like there's an option to make the next-hop an interface instead of an IP. group1-vr { instance-type virtual-router; interface vlan.A; routing-options { static { route C.0/23 next-hop C.1; } } } root@ex# run show route snip group1-vr.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both A.0/23 *[Direct/0] 1d 00:52:00 via vlan.A A.1/32 *[Local/0] 1d 00:52:00 Local via vlan.A I will try rib groups next, but I think I read somewhere that EX switches don't support importing static routes via rib groups. I suppose this could also be solved by Filter Based Forwarding, but I'd like to avoid that if possible; it just doesn't seem as clean. thanks in advance! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] experience using 10G DAC (twinax) cables between EX and multi-vendor
Has anyone used a 10G DAC/Twinax cable between an EX4550 and other vendor gear? Did you use Juniper DAC cables or the other vendor cables? In particular I'm planning on linking a Cisco UCS Fabric Interconnect and also an F5 BigIP 4200v to a VC of EX4550s. would you recommend it or should I fork over the money to use optics? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] QFX vs EX4550 as collapsed core
Hi, we're deploying to a new environment where there will be about 500 virtual servers hosted completely on Cisco UCS. The Core would mostly be hosting uplinks to the UCS Fabric Interconnects (End Host Mode), inter-vlan routing and links to service appliances (FW/LB) and the Internet edge routers. Nearly all of our traffic is North/South from server to LB to internet or server to LB to another server. The core would mostly be routing a few (dozens at most) routes so RIB/FIB size shouldn't be a great concern. Most links will be 10G, but there are a handful of 1G management links. We're considering either the QFX3500 ( x2) or the EX4450 (x2 as a VC) to fill this role (or potentially Cisco Nexus 6001) * are there any L3 benefits of one over the other? I haven't found clear numbers in the datasheets * Has anyone actually used MC-LAG on the QFX3500? Is it working well? any caveats? we've also considered collapsing the edge too, but the cost of say an MX-480 with similar port count is about twice that of an MX-80 + QFX/EX thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX upgrade procedure -ready for enterprise?
We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in various places in our network including the Datacenter Edge. I was reading the upgrade procedure KB: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947 and started to have some heart palpitations. It seems a complicated procedure fraught with peril. Anyone out there have any thoughts (positive/negative) on their experience on upgrading an SRX cluster with minimal downtime? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX upgrade procedure -ready for enterprise?
what pieces of the KB do you think contribute to the possibility of major outages? Not having tested anything it already makes me nervous that failover is initiated solely by shutting down the interfaces on the active node... -Original Message- From: Tim Eberhard [mailto:xmi...@gmail.com] Sent: Friday, March 08, 2013 10:11 AM To: Andy Litzinger Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX upgrade procedure -ready for enterprise? I would never, ever follow that KB. It's just asking for a major outage.. With that said, you have two options. 1) ISSU and 2) Reboot both close to the same time and take the hit. Depending on your hardware it might be 4 minutes, it might be 8-10 minutes. If option one is the path you choose to go keep in mind the limitations and I would suggest you test it in a lab well before you ever do it in production. ISSU on the SRX is still *very* new. Here is a list of limitations: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17946actp=R SS I've seen ISSU fail more than a couple of times when it was supposed to be fully supported. This caused us to take a hit, then have to reboot both devices anyways. So we ended up expecting a hitless upgrade and got 10 minutes of downtime anyways. If you're up for running bleeding edge code then maybe ISSU will work properly, but if availability is that critical you should have a lab to test this in. Good luck, -Tim Eberhard On Fri, Mar 8, 2013 at 9:50 AM, Andy Litzinger andy.litzin...@theplatform.com wrote: We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in various places in our network including the Datacenter Edge. I was reading the upgrade procedure KB: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947 and started to have some heart palpitations. It seems a complicated procedure fraught with peril. Anyone out there have any thoughts (positive/negative) on their experience on upgrading an SRX cluster with minimal downtime? thanks! -andy ___ 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] SRX upgrade procedure -ready for enterprise?
ICU sounds interesting. Any idea why it's not supported on the 550? or is that just documentation lag? -Original Message- From: Clay Haynes [mailto:chay...@centracomm.net] Sent: Friday, March 08, 2013 3:08 PM To: Andy Litzinger; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] SRX upgrade procedure -ready for enterprise? I've had really good luck with the ICU Upgrade for branch series. You upload the software package to the active SRX, run the commands, and it handles copying the package to the backup unit and all reboots. There is still a drop in traffic for up to 30 seconds, but for the most part it's much safer than upgrading/rebooting both units simultaneously and praying they come up properly. Again, ICU is supported on branch-series only, and you have run 11.2r2 or later for it to be available. http://www.juniper.net/techpubs/en_US/junos12.1/topics/task/operationa l/cha ssis-cluster-upgrading-and-aborting-backup-and-primary-device-with- icu.html I haven't had great luck on ISSU, but then again I don't have many datacenter-series boxes to play with (300+ SRX650 and below, about 10 SRX1400 and above). I would follow this URL, and if you're running any of these services in the respective code do not proceed with the ISSU: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17946actp=R SS - Clay On 3/8/13 12:50 PM, Andy Litzinger andy.litzin...@theplatform.com wrote: We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in various places in our network including the Datacenter Edge. I was reading the upgrade procedure KB: http://kb.juniper.net/InfoCenter/index?page=contentid=KB17947 and started to have some heart palpitations. It seems a complicated procedure fraught with peril. Anyone out there have any thoughts (positive/negative) on their experience on upgrading an SRX cluster with minimal downtime? thanks! -andy ___ 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] SRX AV cloud vs on-device
Hi all, we're looking at an SRX 550 and have been posed with the choice between using the cloud based anti-virus or the on-device. Are there any compelling reasons to pick one over the other? thanks! -andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX - DWDM no link
Hi, Firstly DO NOT LOOK INTO OPTICS! SX optics use mostly harmless red led light which is why you can see the light. Other optics operate in the invisible spectrum and use intense laser light which even though you can't see it can cause damage to the eye. You should go and get your eyes checked. As far as I'm aware mx80 doesn't support tuneable optics you have to buy the right dwdm channel. -- Regards Andy Harding Internet Connections Ltd Direct: 020 7531 5656 Mobile: 07813 975459 Reception: 0800 2888 680 Web: www.inetc.co.uk Email: a...@inetc.co.uk Sent from my iPad On 7 Nov 2012, at 07:37, Luca Salvatore l...@ninefold.com wrote: Hi guys, Got some issues connecting two new MX10 routers over a DWDM link. Basically the link just isn't coming. I'm running the XFP-10G-T-DWDM-ZR optics which are plugged into the 2x10Gb MIC. This might seem silly but when I look into the XPF in the router I don't see any red lights coming from inside the XPF. Normally when you look into a XFP or SFP you can see the red laser inside it. I'm not seeing that with the XFP in the MX. Should I be able to see a light? Any suggestions? I have configured the wavelengths on each side and the interface is just configured as a simple inet interface. Thanks. Sent from my iPhone ___ 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] Suppress particular messages from syslog
-Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Robert Hass Sent: Friday, December 30, 2011 7:49 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Suppress particular messages from syslog Hi Is any way to configure something to suppress selected messages from syslog [messages]. You should be able to use something similar to the following and just change the matched string to suit your needs I want to suppress this (running JunOS 10.4): Dec 30 12:11:46 r02 /kernel: tcp_auth_ok: Packet from 62.77.4.5:179 missing MD5 digest set system syslog host x.x.x.x match !(.* Packet from 62.77.4.5:179 missing MD5 digest.*) and Dec 30 15:08:34 r02 tfeb0 MIC(1/1) link 2 SFP receive power low alarm set Dec 30 15:08:55 r02 tfeb0 MIC(1/1) link 2 SFP receive power low alarm cleared set system syslog file messages match !(.* MIC(1/1) link 2 SFP receive power low.*) My current syslog configuration: file messages { any notice; authorization info; } Rob ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Cheers, Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX480 troubles.
Keith, I have operated MX-480 networks installed with DPC's and within the last year have deployed MX-480's with MPC's/MIC's and haven't experienced the hardware issues you have run into. Based on my experiences with Juniper hardware, I would say you've just had unfortunate luck. Cheers, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Keith Sent: Wednesday, April 13, 2011 9:18 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] MX480 troubles. Hi. You folks have been great at answering some of my questions regarding our MX480, but have come across some big problems that me and the person who signed the PO are not very pleased about. A month or so ago I found we had a bad MPC card. Ok so we RMA'd it. This week I came on site to do some work on the MX. Long story short, new MPC card that had been installed and running for 15 days was flaky and possibly even the MIC too after I spent a day troubleshooting with Juniper TAC. So on a non production box, just sitting in the rack, powered up for a little more than 8 weeks, passing no traffic at all, it's on the 3rd MPC and 2nd MIC. I have to say at this point I am really not impressed with Juniper hardware. I'm sure the box is ok when its running properly, but at this point I'm having doubts about Juniper. We were pretty stoked about this box, now...not so much. Is this an anomaly and we got a lemon? Or have any others had to replace this many parts in so short of time? ___ 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] SNMP command: request snmp spoof-trap
I assume if it is in the logs as a trap, that a trap was indeed sent. Since the trap should have originated from the RE, you should be able to see it leave the router with 'monitor traffic interface interface' on the interface that is the best route back to your NMS. Cheers, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Keith Sent: Wednesday, April 06, 2011 11:27 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] SNMP command: request snmp spoof-trap Just going through some SNMP things on the MX, 10.4. When doing a request snmp spoof-trap oid does the box actually send an SNMP trap to any configured targets? SNMP traps are setup for rmon-alarm and chassis alerts. I can see the SNMP trap being generated in the log file on the MX, but using Wireshark, I do not see any traps coming into the host I have setup to receive traps. I just want to be sure before I start digging through the trap host configs and PIX config in front of the NMS to make sure I have them setup correctly. Thanks, Keith. ___ 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] MX80-48T Fan Speed Variation
We have 5x MX80-48T that all do this so I am interested in the answer too... -- Regards Andy Harding Internet Connections Ltd Phone: 020 7531 5655 Mobile: 07813 975 459 Fax: 01538 382596 Web: www.inetc.co.uk Email: a...@inetc.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ifAlias on sub-interfaces
Serge, I saw this same behavior in 10.2R3.10 but didn't open a JTAC case on it. I haven't seen it since I moved to 10.2S6 but that doesn't mean it isn't still present ;-) My workaround for this was to edit the interface a time or two and commit the changes, eventually the ifAlias would be populated. Cheers, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Serge Vautour Sent: Tuesday, March 15, 2011 9:43 AM To: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] ifAlias on sub-interfaces Sorry about missing the details! I'm seeing this on 10.2S6. I've continued to test after sending the first post and found that it is only happening on some interfaces. I can't find anything yet that sets the broken interfaces apart. I'll continue to test and open a case with JTAC if necessary. My guess is this will in fact be some bug. Serge - Original Message From: Keegan Holley keegan.hol...@sungard.com To: Chris Adams cmad...@hiwaay.net; juniper-nsp@puck.nether.net Sent: Tue, March 15, 2011 1:16:24 PM Subject: Re: [j-nsp] ifAlias on sub-interfaces On Tue, Mar 15, 2011 at 11:53 AM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Serge Vautour sergevaut...@yahoo.ca said: I'm not seeing sub-interface descriptions show up in ifAlias. Has anyone seen this before? No, I haven't had that problem. You didn't say what platform, JUNOS version, etc. though. I've had to look through release notes lately and I remember seeing a bunch of bugs related to the interface polling, ifIndex and the like. I agree though they are all JunOS and platform specific. Have you consulted Juniper and/or looked at the release notes for your Junos version? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. ___ 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] BFD timers for OSPF - MX80 - 10.3R2.11
We are using bfd on mx80 with 300ms timers and no problems. Only 2 or 3 sessions per box however. -- Regards Andy Harding Internet Connections Ltd Phone: 0870 803 1868 Mobile: 07813 975459 Fax: 0870 803 1781 Web: www.inetc.co.uk Email: a...@inetc.co.uk On 3 Mar 2011, at 17:53, David Ball davidtb...@gmail.com wrote: Ah, that might help explain it. And shame on me for not checking 'sh pfe statistics traffic protocol bfd', which of course shows none received or absorbed. I'll only have 2 sessions on each MX80, so I think I might leave it enabled, but may toy with the interval. I'm expecting the control plane to be kinda bored on these guys, so we'll see what it can handle. Thanks, Egor. David On 3 March 2011 10:42, Egor Zimin les...@gmail.com wrote: Hello, David It looks like BFD implementation in MX80 is not distributed. At this moment I have a case in JTAC. The case is opened yet, however, it _looks_like_ bfd is not distributed. Probably because of this BFD echomode is not supported. And using 30ms timers for BFD ControlPackets can be not so easy task for RE's CPU. Because of this I don't see much sense to use BFD on MX80 at this moment. 2011/3/3 David Ball davidtb...@gmail.com: MX80s running 10.3R2.11 For those of you using BFD for OSPF, how low have you been able to set your minimum-interval timer? I have a pair of MX80s connected via XFPs and 1m patch cables and with my hellos set to 30ms and multiplier set to 3, I'm seeing failures. I haven't disabled distributed ppm. Moving to 50ms hellos seems to settle things down. The reason I'm wondering why I can't get away with lower timers is because when Juniper proof-of-concepted (yeah, that's a verb) Trio for us (albeit using MX960s), they used 15ms hellos with a multiplier of 3. Mar 3 10:06:06 router bfdd[1129]: BFDD_TRAP_STATE_DOWN: local discriminator: 1, new state: down Mar 3 10:06:06 router rpd[1257]: RPD_OSPF_NBRDOWN: OSPF neighbor 172.16.1.22 (realm ospf-v2 xe-0/0/2.0 area 0.0.0.0) state changed from Full to Down due to InActiveTimer (event reason: BFD session timed out and neighbor was declared dead) me@router show configuration groups bfd-defaults-core-ospf protocols { ospf { area 0.0.0.0 { interface * { bfd-liveness-detection { version automatic; minimum-interval 30; multiplier 3; full-neighbors-only; } } } } } me@router show configuration protocols ospf area 0.0.0.0 interface lo0.0 { passive; } interface xe-0/0/2.0 { apply-groups bfd-defaults-core-ospf; node-link-protection; } interface xe-0/0/3.0 { apply-groups bfd-defaults-core-ospf; node-link-protection; } David ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- Best regards, Egor Zimin ___ 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] Aggregate Routes Revisited
Paul, Assuming you have a static route policy to pick up static routes into BGP, couldn't you just pin that /24 route down to discard, with a high priority of 240 or so, to inject it into BGP, then allow the routing table to use the OSPF route for packets destined to that /24 once received? Cheers, Andy Vance, IP Engineer 360networks 2101 4th Ave., Suite 2000 Seattle, WA 98121 253.307.7546 (c) andy.va...@360networks.com www.360networks.com -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Wednesday, January 12, 2011 8:59 AM To: 'juniper-nsp' Subject: [j-nsp] Aggregate Routes Revisited Hi folks.. Earlier this year I posed a question to the list and never did things working the way I expected - so I'm revisiting the topic. I got several helpful replies from folks but either am thick headed or misunderstood ;) In our Cisco network, we use the network statement in our BGP configurations. I'm looking to do similar on our MX platforms - my saving grace to date is that the Cisco 7600's are still online and contributing the routes. The 7600's are coming out shortly and I need to resolve this ;) Our BGP export is community driven and working fine today (with the contributed routes from the 7600 platform). Our own routes are tagged with 11666:5000 and our transit customers are tagged with 11666:4000 (both have some additional tags but these catch all - ie 5001 5002 etc) Typical upstream connection looks like this: type external; description Level3; advertise-inactive; import inbound-level3-v4; export outbound-level3-v4; neighbor x.xx.xxx.x { authentication-key x; ## SECRET-DATA peer-as 3356; } Typical export policy to an upstream looks like this (in this case Level3 which we are prepending once at the moment): term lvl3-1 { from community our_nets; then { as-path-prepend 11666; accept; } } term lvl3-2 { from community customer_nets; then accept; } term lvl3-3 { then reject; } So now comes my problem and this is where I start to get confused with the aggregate route options. {master}[edit routing-options aggregate] route 192.168.0.0/19 community [ 11666:5000 11666:5001 ]; This works today - we see the entire /19 exported to our upstreams/peers. Now, in our OSPF tables we have 192.168.0.5/24 for example which we also want to advertise upstream. If I add route 192.168.0.0/19 community [ 11666:5000 11666:5001 ] to the aggregate, this won't work as I understand it because there isn't a more specific route to contribute towards it's existence. I opened a JTAC ticket and they suggested a policy similar to: term bgp1 { from { protocol ospf; route-filter 192.168.0.5/24 exact; } then { community add our_nets; accept; } } term bgp99 { then reject; } This doesn't work neither - there is no BGP route for that particular 192.168.0.5/24 for it to export. So how do I inject this /24 into the BGP tables with a community so that it exports? I keep going around in circles on this one ;) Thanks for your patience ;) Paul ___ 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] Aggregate Routes Revisited
If Paul has an export policy picking up static routes, it should. An export policy such as this policy-statement static-bgp { term static-routes { from { protocol static; tag if a tag value is preferred route-filter 192.168.5.0/24 exact; } then { community add community value to add; next-hop self if next-hop self is required accept; } } term next-policy then { next policy; } } and applied as an export policy on the bgp groups, where it is needed, should pick up the static route set to discard and allow it to be exported to the neighbors as it is a valid static route known by protocol static. Agreed it isn't the best route in the routing table, the OSPF route is, and will not be used for forwarding. I don't have a lab available to test quickly, I'm going from memory, I could be wrong... Andy -Original Message- From: Smith W. Stacy [mailto:st...@netfigure.com] Sent: Wednesday, January 12, 2011 10:36 AM To: Andy Vance Cc: Paul Stewart; juniper-nsp Subject: Re: [j-nsp] Aggregate Routes Revisited I don't think this will accomplish what Paul is asking for. The static route /w preference 240 will not become the active route as long as the OSPF route for the same prefix is present, and only active routes are evaluated by the export policy. --Stacy On Jan 12, 2011, at 10:19 AM, Andy Vance wrote: Paul, Assuming you have a static route policy to pick up static routes into BGP, couldn't you just pin that /24 route down to discard, with a high priority of 240 or so, to inject it into BGP, then allow the routing table to use the OSPF route for packets destined to that /24 once received? Cheers, Andy Vance, IP Engineer 360networks 2101 4th Ave., Suite 2000 Seattle, WA 98121 253.307.7546 (c) andy.va...@360networks.com www.360networks.com -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Wednesday, January 12, 2011 8:59 AM To: 'juniper-nsp' Subject: [j-nsp] Aggregate Routes Revisited Hi folks.. Earlier this year I posed a question to the list and never did things working the way I expected - so I'm revisiting the topic. I got several helpful replies from folks but either am thick headed or misunderstood ;) In our Cisco network, we use the network statement in our BGP configurations. I'm looking to do similar on our MX platforms - my saving grace to date is that the Cisco 7600's are still online and contributing the routes. The 7600's are coming out shortly and I need to resolve this ;) Our BGP export is community driven and working fine today (with the contributed routes from the 7600 platform). Our own routes are tagged with 11666:5000 and our transit customers are tagged with 11666:4000 (both have some additional tags but these catch all - ie 5001 5002 etc) Typical upstream connection looks like this: type external; description Level3; advertise-inactive; import inbound-level3-v4; export outbound-level3-v4; neighbor x.xx.xxx.x { authentication-key x; ## SECRET-DATA peer-as 3356; } Typical export policy to an upstream looks like this (in this case Level3 which we are prepending once at the moment): term lvl3-1 { from community our_nets; then { as-path-prepend 11666; accept; } } term lvl3-2 { from community customer_nets; then accept; } term lvl3-3 { then reject; } So now comes my problem and this is where I start to get confused with the aggregate route options. {master}[edit routing-options aggregate] route 192.168.0.0/19 community [ 11666:5000 11666:5001 ]; This works today - we see the entire /19 exported to our upstreams/peers. Now, in our OSPF tables we have 192.168.0.5/24 for example which we also want to advertise upstream. If I add route 192.168.0.0/19 community [ 11666:5000 11666:5001 ] to the aggregate, this won't work as I understand it because there isn't a more specific route to contribute towards it's existence. I opened a JTAC ticket and they suggested a policy similar to: term bgp1 { from { protocol ospf; route-filter 192.168.0.5/24 exact; } then { community add our_nets; accept; } } term bgp99 { then reject; } This doesn't work neither - there is no BGP route for that particular 192.168.0.5/24 for it to export. So how do I inject this /24 into the BGP tables with a community so that it exports? I keep going around in circles on this one ;) Thanks for your patience ;) Paul
Re: [j-nsp] Aggregate Routes Revisited
Is ok to disagree as your captures below prove your point and that you are correct. Apologies for the misinfo Andy -Original Message- From: Smith W. Stacy [mailto:st...@acm.org] Sent: Wednesday, January 12, 2011 12:02 PM To: Andy Vance Cc: Paul Stewart; juniper-nsp Subject: Re: [j-nsp] Aggregate Routes Revisited Sorry, but I still disagree with you. Only the active route in the routing table is evaluated by export policy. I think the captures below illustrate my point. --Stacy u...@host show configuration protocols bgp group foo { export static-bgp; neighbor 192.168.0.2 { peer-as 2; } } u...@host show configuration routing-options static { route 192.168.5.0/24 { discard; preference 240; } } autonomous-system 1; u...@host show configuration policy-options policy-statement static-bgp term static-routes { from { protocol static; route-filter 192.168.5.0/24 exact; } then { community add our_nets; next-hop self; accept; } } term next-policy { then next policy; } u...@host show route 192.168.5.0/24 inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.5.0/24 *[OSPF/150] 00:01:16, metric 0, tag 0 via lt-0/0/0.2 [Static/240] 00:18:09 Discard u...@host show route advertising-protocol bgp 192.168.0.2 u...@host configure Entering configuration mode [edit] u...@host# delete routing-options static route 192.168.5.0/24 preference [edit] u...@host# commit and-quit commit complete Exiting configuration mode u...@host show route 192.168.5.0/24 inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 192.168.5.0/24 *[Static/5] 00:00:10 Discard [OSPF/150] 00:02:06, metric 0, tag 0 via lt-0/0/0.2 u...@host show route advertising-protocol bgp 192.168.0.2 inet.0: 10 destinations, 12 routes (10 active, 0 holddown, 0 hidden) Prefix Nexthop MED LclprefAS path * 192.168.5.0/24 SelfI u...@host On Jan 12, 2011, at 12:19 PM, Andy Vance wrote: If Paul has an export policy picking up static routes, it should. An export policy such as this policy-statement static-bgp { term static-routes { from { protocol static; tag if a tag value is preferred route-filter 192.168.5.0/24 exact; } then { community add community value to add; next-hop self if next-hop self is required accept; } } term next-policy then { next policy; } } and applied as an export policy on the bgp groups, where it is needed, should pick up the static route set to discard and allow it to be exported to the neighbors as it is a valid static route known by protocol static. Agreed it isn't the best route in the routing table, the OSPF route is, and will not be used for forwarding. I don't have a lab available to test quickly, I'm going from memory, I could be wrong... Andy -Original Message- From: Smith W. Stacy [mailto:st...@netfigure.com] Sent: Wednesday, January 12, 2011 10:36 AM To: Andy Vance Cc: Paul Stewart; juniper-nsp Subject: Re: [j-nsp] Aggregate Routes Revisited I don't think this will accomplish what Paul is asking for. The static route /w preference 240 will not become the active route as long as the OSPF route for the same prefix is present, and only active routes are evaluated by the export policy. --Stacy On Jan 12, 2011, at 10:19 AM, Andy Vance wrote: Paul, Assuming you have a static route policy to pick up static routes into BGP, couldn't you just pin that /24 route down to discard, with a high priority of 240 or so, to inject it into BGP, then allow the routing table to use the OSPF route for packets destined to that /24 once received? Cheers, Andy Vance, IP Engineer 360networks 2101 4th Ave., Suite 2000 Seattle, WA 98121 253.307.7546 (c) andy.va...@360networks.com www.360networks.com -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Paul Stewart Sent: Wednesday, January 12, 2011 8:59 AM To: 'juniper-nsp' Subject: [j-nsp] Aggregate Routes Revisited Hi folks.. Earlier this year I posed a question to the list and never did things working the way I expected - so I'm revisiting the topic. I got several helpful replies from folks but either am thick headed or misunderstood ;) In our Cisco network, we use the network statement in our BGP
[j-nsp] (no subject)
___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Flow accounting on an M7i
Thanks for all the input. In the end, I decided to let it sit for an hour or so and the flows started working. I'm not sure if this is normal, but not what I expected. The flow errors cleared and there are no memory issues now. a...@er01 show services accounting flow Service Accounting interface: sp-1/2/0, Local interface index: 142 Service name: (default sampling) Interface state: Accounting Flow information Flow packets: 188567, Flow bytes: 33001278 Flow packets 10-second rate: 2, Flow bytes 10-second rate: 572 Active flows: 120, Total flows: 156524 Flows exported: 156404, Flows packets exported: 8987 Flows inactive timed out: 156404, Flows active timed out: 0 a...@er01 show services accounting errors Service Accounting interface: sp-1/2/0, Local interface index: 142 Service name: (default sampling) Interface state: Accounting Error information Packets dropped (no memory): 0, Packets dropped (not IP): 0 Packets dropped (not IPv4): 0, Packets dropped (header too small): 0 Memory allocation failures: 0, Memory free failures: 0 Memory free list failures: 0 Memory warning: No, Memory overload: No, PPS overload: No, BPS overload: No Thank you to everyone for the assistance. -Andy On Aug 19, 2010, at 12:08 AM, Doan Nguyen wrote: Starting JUNOS a requirement for cflowd to work is to configure NTP as Stefan pointed out a few emails earlier. --- On Wed, 8/18/10, sth...@nethelp.no sth...@nethelp.no wrote: From: sth...@nethelp.no sth...@nethelp.no Subject: Re: [j-nsp] Flow accounting on an M7i To: a...@ctdam.com Cc: juniper-nsp@puck.nether.net Date: Wednesday, August 18, 2010, 2:39 PM I'm trying to enable flow accounting on one of our M7is. JunOS version is 9.1R8. No matter what I do, I can't get a flow to export. I'd appreciate any input to obvious errors, or tips on other things to try. I've also tried removing sampling from the interface and doing it with a firewall rule. Have you tried RE-based sampling? We use input { family inet { rate 1000; run-length 0; max-packets-per-second 1000; } } output { cflowd a.b.c.d { port 2055; version 5; no-local-dump; autonomous-system-type origin; } } and then for the relevant interfaces we have a firewall filter which includes the sample keyword. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ 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 accounting on an M7i
I'm trying to enable flow accounting on one of our M7is. JunOS version is 9.1R8. No matter what I do, I can't get a flow to export. I'd appreciate any input to obvious errors, or tips on other things to try. I've also tried removing sampling from the interface and doing it with a firewall rule. Currently, it's configured as follows: a...@er01 show configuration forwarding-options sampling { input { family inet { rate 1; } } output { cflowd X.X.X.X { port 2100; version 5; no-local-dump; autonomous-system-type origin; } interface sp-1/2/0 { source-address X.X.X.X; # The IP of an interface that can reach the Netflow server } } } a...@er01 show configuration interfaces sp-1/2/0 unit 0 { family inet { address 10.0.1.1/32 { destination 10.0.1.2; } } } a...@er01 show configuration interfaces ge-0/0/0 unit 3 vlan-id 1; family inet { sampling { input; } address X.X.X.X/30 { preferred; } } When I enable it, for a few minutes nothing seems to happen. Then I can see memory usage increase to the point there is no free memory on the ASP, then it begins to give errors. It never tries to export the flow: a...@er01 show services accounting memory Service Accounting interface: sp-1/2/0, Local interface index: 150 Service name: (default sampling) Interface state: Accounting Memory utilization Allocation count: 695912, Free count: 348290, Maximum allocated: 0 Allocations per second: 0, Frees per second: 0 Total memory used (in bytes): 211804592, Total memory free (in bytes): 7400 a...@er01 show services accounting errors Service Accounting interface: sp-1/2/0, Local interface index: 150 Service name: (default sampling) Interface state: Accounting Error information Packets dropped (no memory): 8262, Packets dropped (not IP): 0 Packets dropped (not IPv4): 0, Packets dropped (header too small): 0 Memory allocation failures: 0, Memory free failures: 0 Memory free list failures: 356435 Memory warning: Yes, Memory overload: No, PPS overload: No, BPS overload: No a...@er01 show services accounting flow Service Accounting interface: sp-1/2/0, Local interface index: 150 Service name: (default sampling) Interface state: Accounting Flow information Flow packets: 0, Flow bytes: 0 Flow packets 10-second rate: 0, Flow bytes 10-second rate: 0 Active flows: 0, Total flows: 0 Flows exported: 0, Flows packets exported: 0 Flows inactive timed out: 0, Flows active timed out: 0 Here's the installed PIC details. I've tried bringing it up/down as well, with the same behavior. a...@er01 show chassis pic fpc-slot 1 pic-slot 2 FPC slot 1, PIC slot 2 information: Type ASP - Integrated (Layer-2-3) StateOnline PIC version 1.7 CPU load average 0 percent Interrupt load average 0 percent Total DRAM size 256 MB Memory buffer utilization 0 percent Memory heap utilization 99 percent Uptime 14 hours, 49 seconds ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Flow accounting on an M7i
I do, I meant to include that. a...@er01 show ntp status status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version=ntpd 4.2.0-a Fri Apr 25 07:34:52 UTC 2008 (1), processor=i386, system=JUNOS9.1R1.8, leap=00, stratum=2, precision=-19, rootdelay=46.515, rootdispersion=14.961, peer=43788, refid=204.152.184.72, reftime=d016a4a1.c6f63e1b Wed, Aug 18 2010 13:27:45.777, poll=6, clock=d016a4d5.07841ed1 Wed, Aug 18 2010 13:28:37.029, state=4, offset=-0.073, frequency=62.639, jitter=2.050, stability=0.004 -Andy On Aug 18, 2010, at 2:28 PM, Stefan Fouant wrote: -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Andy M. Sent: Wednesday, August 18, 2010 11:43 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Flow accounting on an M7i I'm trying to enable flow accounting on one of our M7is. JunOS version is 9.1R8. No matter what I do, I can't get a flow to export. I'd appreciate any input to obvious errors, or tips on other things to try. I've also tried removing sampling from the interface and doing it with a firewall rule. When I enable it, for a few minutes nothing seems to happen. Then I can see memory usage increase to the point there is no free memory on the ASP, then it begins to give errors. It never tries to export the flow: Do you have an active NTP time source and is it synchronized? Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Flow accounting on an M7i
I tried both layer-3 and layer-2-3 with no effect. I also manually took the PIC offline and brought it back up. -Andy On Aug 18, 2010, at 2:49 PM, Nathan Sipes wrote: Did you set the services for the card under the chassis section.. fpc 1 { pic 2 { adaptive-services { service-package layer-3; } } On Wed, Aug 18, 2010 at 12:32 PM, Andy M. a...@ctdam.com wrote: I do, I meant to include that. a...@er01 show ntp status status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg, version=ntpd 4.2.0-a Fri Apr 25 07:34:52 UTC 2008 (1), processor=i386, system=JUNOS9.1R1.8, leap=00, stratum=2, precision=-19, rootdelay=46.515, rootdispersion=14.961, peer=43788, refid=204.152.184.72, reftime=d016a4a1.c6f63e1b Wed, Aug 18 2010 13:27:45.777, poll=6, clock=d016a4d5.07841ed1 Wed, Aug 18 2010 13:28:37.029, state=4, offset=-0.073, frequency=62.639, jitter=2.050, stability=0.004 -Andy On Aug 18, 2010, at 2:28 PM, Stefan Fouant wrote: -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Andy M. Sent: Wednesday, August 18, 2010 11:43 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Flow accounting on an M7i I'm trying to enable flow accounting on one of our M7is. JunOS version is 9.1R8. No matter what I do, I can't get a flow to export. I'd appreciate any input to obvious errors, or tips on other things to try. I've also tried removing sampling from the interface and doing it with a firewall rule. When I enable it, for a few minutes nothing seems to happen. Then I can see memory usage increase to the point there is no free memory on the ASP, then it begins to give errors. It never tries to export the flow: Do you have an active NTP time source and is it synchronized? Stefan Fouant, CISSP, JNCIEx2 www.shortestpathfirst.net GPG Key ID: 0xB5E3803D ___ 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] (H-)VPLS over LDP, documentation?
juniper does support LDP for [H-]VPLS, although they don't shout about it. I have done interop testing between juni mx's tellabs 8800's it works fine ~andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- boun...@puck.nether.net] On Behalf Of Felipe Zanchet Grazziotin Sent: 06 August 2010 22:35 To: juniper-...@punk.nether.net Subject: [j-nsp] (H-)VPLS over LDP, documentation? Hello, I've been trying to setup multi-vendor (H-)VPLS, but unfortunately it can only be done over LDP. I'm aware of all problems of scalability, and so on, about VPLS when done over LDP, but the other vendor just cannot do it over BGP now. All Juniper I've found documentation about this subject talks about BGP configuration, am I missing anything? My Juniper-side here is a M7i router, should be able to do this job. Thanks in advance, Felipe ___ 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] J series users bitten by the massive memory use increase with flow mode add, please file jtac cases.
On 20 Jul 2010, at 23:14, Christopher E. Brown wrote: I know alot of us here have been bitten by this, and the fact that disabling flow mode and reverting to packet does not free up any of the ~ 460MB or so being eaten by fwdd/flowd is insane. I am currently having the This is a design feature, the pre-alloc is planned argument with a SE. It's trash, we've found customers are starting to buy lower end cisco for very-small SP environments again. Cisco 2900 is hoovering up lots of the builds that we used to use J4350/6350 for, precisely because of the added complexity and total resource of that this flow-mode presents. I have no issue with flow features being added, looks great for branch office use. This trade wont come back until there is a rebuild of JUNOS sans enhanced services for J. Pretty please with cherry on top ? Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
On 21 Jul 2010, at 23:28, Nilesh Khambal wrote: I am not a J-Series person and don't know much about flowd operation but does the memory utilization come down when you reboot the router after disabling the flow mode? You can't disable it completely, it needs to remain on for packets destined *to* the router, e.g. bgp sessions. Ergo the memory-pit transcends reboots. Best wishes Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] M20 JunOS Recommendation
We currently have all of our M20's on 8.5S4 and have had no issues whatsoever, we upgraded from 7.5-daily. 8.5S4 is an extended release and if you're not chasing features, I'd look into utilizing it. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct 206.971.5144 . Fax 206.728.1500 Email ava...@hq.speakeasy.net . Web www.speakeasy.net Voice . Data . Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jose Madrid Sent: Wednesday, July 21, 2010 7:42 AM To: Juniper List Subject: [j-nsp] M20 JunOS Recommendation I have an M20 that has been working fine for a few years with no real issues running 7.6 R4.3. I have been putting off upgrading this guy long enough and was wondering what you guys thought would be the best version of JunOS to goto now would be. I was thinking something in the 8.5 train, but I know even that is old now. Any recommendations would be much appreciated. Thank you. -- It has to start somewhere, it has to start sometime. What better place than here? What better time than now? ___ 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] MAC Sticky on EX
On 1 Jul 2010, at 14:27, Fahad Khan wrote: Dear Folks, Do we have any option like MAC Sticky in EX series as we have in IOS for in port security??/ I think we can only limit the number of MAC or we can bind static MAC addresses. This is my understanding too, I achieve the mac limit with ethernet-switching-options secure-access-port interface blah mac-limit 1 action shutdown. A mac acl can be used as you describe too. Ideally, I would like this mac-limit feature for trunk ports too. Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE-400 memory upgrade
On 30 Jan 2010, at 15:41, Kevin Wormington wrote: 陈江 wrote: RE400 is a standard PC running on Intel Celeron400 and 82443BX mainboard. Your could check SPEC of Intel 82443BX how much DRAM it supported. And I don't think there is any limitation in JUNOS. I took a quick look at the spec sheet for the 82443BX and it appears to support 1GB max DRAM but using 4 DIMM sockets, so with the 3 DIMM sockets on the RE-400 768MB would be the max. Hi, j-nsp, -- Does this mean that nobody here has ignored the spec sheet and tried alternative configurations ? :-) I would be interested to hear empirical evidence that 2x512GB certainly would work, or certainly would not work. Best wishes, Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] RE-400 memory upgrade
Andy Davidson wrote: On 30 Jan 2010, at 15:41, Kevin Wormington wrote: 陈江 wrote: RE400 is a standard PC running on Intel Celeron400 and 82443BX mainboard. Your could check SPEC of Intel 82443BX how much DRAM it supported. And I don't think there is any limitation in JUNOS. I took a quick look at the spec sheet for the 82443BX and it appears to support 1GB max DRAM but using 4 DIMM sockets, so with the 3 DIMM sockets on the RE-400 768MB would be the max. Hi, j-nsp, -- Does this mean that nobody here has ignored the spec sheet and tried alternative configurations ? :-) I would be interested to hear empirical evidence that 2x512GB certainly would work, or certainly would not work. Just tried booting with 1x 512MB module installed and only 256MB was detected. -- Regards Andy Harding Internet Connections Ltd Phone: 020 7531 5655 Mobile: 07813 975 459 Fax: 01538 382596 Web: www.inetc.co.uk Email: a...@inetc.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] ISSU
On Mon, Mar 29, 2010 at 06:00:35PM +0530, chandrasekaran iyer wrote: hi, how to do iSSU in junos? Can anybody provide me the steps. A unified in-service software upgrade (unified ISSU) enables you to upgrade between two different JUNOS software releases with no disruption on the control plane and with minimal disruption of traffic. Unified ISSU is only supported on dual Routing Engine platforms. In addition, the graceful Routing Engine switchover (GRES) and nonstop active routing (NSR) must be enabled. To do this you need: [edit system] + commit synchronize; [edit chassis] + redundancy { + graceful-switchover; + } [edit routing-options] + nonstop-routing; Then 1. Verify that both routing engines are running the same version of software code. Use the ‘show version invoke-on all-routing-engines’ command. 2. Enable Graceful Routing Engine switchover and non-stop active routing. Verify that the Routing Engines and protocols are synchronized. On the backup Routing Engine (re1) run the ‘show system switchover’ command. 3. To verify non-stop active routing is configured. On the master Routing Engine (re0) run the ‘show task replication’ command. 4. Issue the request system software in-service-upgrade command on the master Routing Engine. Run the ‘request system software in-service-upgrade path-to-image reboot’ command. Make sure you replace the path-to-image with the correct image version to be used in the upgrade. 5. The upgrade will take place for both routing-engines whilst in service. Cheers -- andya...@shady.org --- Never argue with an idiot. They drag you down to their level, then beat you with experience. CCIP, JNCIP #959 --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] local switching l2circuit not passing traffic
David Coulson wrote: I have what I thought was a pretty simple config - Two VLANs on two GigE interfaces, on a MX240 running 9.4R2.9 which are cross-connected within the MX using a l2circuit. If I remove the 'vlan-ccc' encap from the units and assign an IP, we can ping to something on the other end - So at least we know end-to-end works on both interfaces. Once it's reassembled as a l2circuit, there is no connectivity between the two end points. I'm sure it's something pretty elementary, but I can't determine what it is. Is there a way to sniff or capture traffic on the l2circuit to see what is going on? The VLAN numbers at both ends of the l2circuit need to be the same for it to work. This is a very poorly documented limitation of the l2circuit feature. -- Regards Andy Harding Internet Connections Ltd Phone: 020 7531 5655 Mobile: 07813 975 459 Fax: 01538 382596 Web: www.inetc.co.uk Email: a...@inetc.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] local switching l2circuit not passing traffic
David Coulson wrote: Is there an alternative method of doing this without having consistent VLAN IDs? On 3/12/2010 9:44 AM, Andy Harding wrote: The VLAN numbers at both ends of the l2circuit need to be the same for it to work. This is a very poorly documented limitation of the l2circuit feature. I believe if you have the IQ SFP PICs you can use the VLAN rewriting features to accomplish what you need. However, I'm not lucky enough to have any of these PICs and haven't been able to try it out. -- Regards Andy Harding Internet Connections Ltd Phone: 020 7531 5655 Mobile: 07813 975 459 Fax: 01538 382596 Web: www.inetc.co.uk Email: a...@inetc.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] L3VPN advertises the directly connected subnet - why?
Without config snapshots of the VRF, the import policy and the export policy, it is difficult to say why you see this behavior, I have some ideas but I don't want to guess. Can you provide config snapshots? I don't want to assume and head down some road that may not be relevant. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct 206.971.5144 * Fax 206.728.1500 Email ava...@hq.speakeasy.net * Web www.speakeasy.net Voice * Data * Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Jeroen Valcke Sent: Tuesday, January 26, 2010 7:52 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] L3VPN advertises the directly connected subnet - why? Hi, I'm doing some testing with simple plain L3VPNs and ran into some weird behaviour. At least I think it's weird. Perhaps somebody can enlighten me. A CE router is exchanging routes with the PE through BGP. These routes are correctly advertised 'over' the L3VPN towards other CE routers. However the directly connected subnet between the CE and PE is also advertised to the other CE routers. Why is this? It was my understanding that only the routes learned from the BGP advertisement from the CE router would be advertised to the other CE routers. What's the reasoning behind this behaviour? Can I alter this behaviour? And if yes, is it safe to do so? Weirdly enough I've found a Juniper KB [1] which seems to document the exact opposite behaviour of what I'm experiencing. This KB describes a case where the directly connected subnet is not advertised over the L3VPN and how to 'fix' this. Thanks for any clues. Kind regards, -Jeroen- PS: JunOS version on the PE routers is 9.3R2.8 [1] http://kb.juniper.net/index?page=contentid=KB12430cat=BGPactp=LIST -- Jeroen Valcke ___ 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] IPv6
On 23/01/2010 14:22, Muhammad Aamir wrote: We are planning to go with IPv6; currently we have all Junipers in the Core. I just want to know does juniper supports all features related to IPv6. Anybody faced any problem while configuring IPv6 on their Juniper routers. Does JUNOS (version 9.4) have any bug related to IPv6? All comments are really appreciated. When we are approached to do a Juniper rollout for a new network, we try to get customers to dual stack right away - getting them to do this at the start will save them money in the future on later change work. You don't mention which platform. In addition to RAS's comments, if you are unfortunate enough to run JSeries/ES 9.4 rather than straight Junos, then you need to remember to set packet mode for the inet6 family. There again, I'd consider this a huge feature, not a bug. :-) Other than this, you should find it quite a straightforward process - Support on Juniper is more uniformly good than on many other technology families, and for this we should be grateful to Juniper. Best wishes Andy Davidson // www.netsumo.com ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to delete the BGP Route for IPVPN
Which route are you trying to delete, an imported route into this routing instance or an exported route that is advertised out of this routing instance? You should be able to use a route filter in your policy-options policy-statement to keep the route your trying to remove from being advertised or accepted. for example, I use an export filter such as this to not advertise certain routes policy-statement andys-out { term deny-default { from { protocol static; route-filter 0.0.0.0/0 exact; } then reject; } term out { from protocol [ direct static ]; then { community add vpn-andy-router1; accept; } } term reject { then reject; Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct 206.971.5144 • Fax 206.728.1500 Email ava...@hq.speakeasy.net • Web www.speakeasy.net Voice • Data • Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of venkata saranu Sent: Thursday, January 21, 2010 12:19 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] How to delete the BGP Route for IPVPN Hi Experts , Could you please help me in deleting the BGP Route which was configured like below... I want to delete only one route at a time ... please assist me here thanks in advance routing-instances MS-2 { instance-type vrf; interface lo0.1; route-distinguisher 2828:12002; vrf-import IMPORT-VPN-12002-COMMUNITY; vrf-export EXPORT-VPN-12002-COMMUNITY; vrf-target import target:2828:2; vrf-table-label; protocols { bgp { group CE { type external; family inet { any; } family inet6 { unicast; } peer-as 2000; neighbor 132.1.1.2; } } pim { vpn-group-address 120.1.1.99; rp { static { address 114.1.5.2; } } interface lo0.1 { mode sparse; version 2; } } } -- o__ -,/'_ (_) \ (_) - - - - -వెంకట శరణు - - - - ___ 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-jseries-7.4R2.6
Does anyone happen to have the 7.4R2.6 jinstall for the J-series laying around? I need a copy and have yet to find one. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct 206.971.5144 * Fax 206.728.1500 Email ava...@hq.speakeasy.netmailto:ava...@hq.speakeasy.net * Web www.speakeasy.nethttp://www.speakeasy.net/ Voice * Data * Managed Services ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] JUNOS
On 8 Jan 2010, at 09:13, Richard A Steenbergen wrote: for example if you hit ctrl-c in the cli anywhere other than at the prompt it locks up the cli process :P Fantastic. :-) I've been trying to replicate this on 9.6R2.11 and can't do this at the edit prompt or the ---(more)--- pause - does this mean it's fixed in this version ? Andy ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Compatible RAM for RE
Welch, Bryan wrote: We bought ours directly from Crucial for our M7i RE-400's. The specific modules you need are PC133 Unbuffered ECC. Here is what we bought: http://www.buy.com/prod/crucial-256mb-sdram-memory-module-256mb-1-x-256mb-133mhz-pc133-ecc/q/loc/101/203278621.html This is the part we normally buy however Crucial no longer list it on their site and the above link doesn't seem to want to ship to the UK... -- Regards Andy Harding Internet Connections Ltd Phone: 020 7531 5655 Mobile: 07813 975 459 Fax: 01538 382596 Web: www.inetc.co.uk Email: a...@inetc.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Compatible RAM for RE
Jonas Frey wrote: We used: Kingston KVR133X72C2/256 Also have a look at: http://juniper.cluepon.net/index.php/Route_Engine_DRAM_Compatibility#RE-2.0_Generic_DRAM Interesting... The spec sheet as found here:- http://www.valueram.com/datasheets/KVR133X72C2_256.pdf Lists the internal config as 32Mx8bit which is incompatible with the Intel BX440 chipset used in the RE. It's quite likely that only 50% of the RAM would show up or not work at all. I take your's worked fine? Was this a RE-400 (m7i)? -- Regards Andy Harding Internet Connections Ltd Phone: 020 7531 5655 Mobile: 07813 975 459 Fax: 01538 382596 Web: www.inetc.co.uk Email: a...@inetc.co.uk ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Slot zero on the ERX chassis
None that I'm aware of, can you shoot a show hard and a show ver from that chassis with the card in? We have GE cards in slot 0 but I don't recall any card type limitation. Cheers, Andy Vance Sr. Network Engineer Speakeasy Direct 206.971.5144 * Fax 206.728.1500 Email ava...@hq.speakeasy.net * Web www.speakeasy.net Voice * Data * Managed Services -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Scott Weeks Sent: Tuesday, September 01, 2009 1:01 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Slot zero on the ERX chassis Is there an issue where the ERX will not accept a DS3-4P I/O and OC3/OC12/DS3-ATM card set in slot zero? I am having no luck with search engines and our vendor's support folks. There is no problem when I put them in other slots. scott ___ 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] Broken Per-Flow load sharing
Hey Serge, The default behavior is to look at layer-3 info only. The option you configured below add the layer-4 information to the hash. Starting in JUNOS 9.5, for MX routers with layer-2 links and link aggregation, there are more options. In addition to: [edit forwarding options hash key] family inet there is also: [edit forwarding options hash key] family multiservice http://www.juniper.net/techpubs/software/junos/junos95/swconfig-layer-2/id-load-link-sec.html This is used to layer-2 links can also look at the layer-3 and layer-4 information. Cheers, -Andy On Fri, Aug 21, 2009 at 2:53 PM, Serge Vautour sergevaut...@yahoo.cawrote: For anyone curious, Juniper seems to have 3 ways to solve this problem: http://www.juniper.net/techpubs/software/junos/junos93/swconfig-policy/configuring-per-flow-load-balancing-information.html#id-11352490 I can't say I understand all 3 (docs are a bit vague). We implemented the first and it worked perfectly: [edit forwarding-options hash-key] family inet { layer-3; layer-4; } Serge - Original Message From: Serge Vautour sergevaut...@yahoo.ca To: juniper-nsp@puck.nether.net Sent: Thursday, August 20, 2009 11:44:25 AM Subject: [j-nsp] Broken Per-Flow load sharing Hello, We have several M320s T640s in our network running 8.5R4.3. They are all configured for per-flow load sharing: RouterA show configuration routing-options forwarding-table export perDestinationLoadBalance; RouterA show configuration policy-options policy-statement perDestinationLoadBalance /* Policy exported against forwarding-table configuration to ensure per-flow-destination load balance */ then { load-balance per-packet; } The routers have 2x 10GEs via switches to reach Aggregation routers. OSPF sees 2 equal cost paths to the BGP next hops and splits the traffic across the links. This has been working fine for a few years (it worked on 8.2 as well). We recently upgraded to 9.3R2.8 and load sharing is no longer working: RouterA show interfaces xe-1/0/0 detail | match Output packets.*pps Output packets: 61838797 pps Output packets:00 pps Output packets:525426 pps Output packets:192790 pps Output packets: 31340 pps Output packets:00 pps RouterA show interfaces xe-2/0/0 detail | match Output packets.*pps Output packets: 285078265156 228705 pps Output packets:00 pps Output packets: 280511288646 221803 pps Output packets: 4118406919 6075 pps Output packets:442607080 894 pps Output packets:00 pps The first Output line is the 10GE aggregate. The other output lines are the VLANs on the 10GE. Note that the xe-1/0/0 interface has next to 0 pps on output!! We have upgraded two M320s and they are both showing the same problem. My guess is that the per-flow load balancing hash has changed in the newer release. The 9.3 manual talks about setting something like this: [edit forwarding-options hash-key] family inet { layer-3; layer-4; } But it's a bit unclear as to what happens if it isn't set. Can anyone confirm that this will restore per-flow load sharing? Any help would be appreciated. Thanks, Serge __ Looking for the perfect gift? Give the gift of Flickr! http://www.flickr.com/gift/ ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp __ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ ___ 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] DPC-R-40GE-SFP and Transition Media Converter
I've seen this in the past with media converters and was able to work around it using gigether-options { no-auto-negotiation; Hope that helps, Andy -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Ozgur Guler Sent: Thursday, April 09, 2009 7:58 AM To: juniper-nsp@puck.nether.net Subject: [j-nsp] DPC-R-40GE-SFP and Transition Media Converter Hi All, I am having a problem to get the line protocol up between Juniper DPC-R-40GE-SFP and my media converter (Transition multimode SFP). Has anyone seen this previously? Is there a way to solve this ? Thanks Ozgur ___ 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] JUNOSe and ECMP
To enable ECMP load balancing: routing-options { forwarding-table { export load-balancing-policy; } } policy-options { policy-statement load-balancing-policy { then { load-balance per-packet; } } On Jan 28, 2008 8:54 AM, Sven Juergensen (KielNET) [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, warming up the topic once again ;) Scenario: two routers connected using 2x GIGE. Both of them having a loopback interface. Now, either router has two static routes for the loopback interface of the opposite router. I understand that the default hashed mode is distributing the sessions roughly even across both links. Perhaps my way of judging on this lacks something but when I'm pinging the far end loopback across the router with the other loopback from a firewall, the traffic always picks the next hop which is listed first in the routing table, even when using multiple pings from different source adresses. This also happens when announcing the loopback interface via OSPF w/ a maximum-paths of 4. Am I missing something? Is there a switch that enables ECMP globally for static routing or in general? Does the implementation of ECMP consider ICMP as something else? Thanks and best regards, sven03 Mit freundlichen Gruessen i. A. Sven Juergensen - -- Fachbereich Informationstechnologie KielNET GmbH Gesellschaft fuer Kommunikation Preusserstr. 1-9, 24105 Kiel Telefon : 0431 / 2219-053 Telefax : 0431 / 2219-005 E-Mail : [EMAIL PROTECTED] Internet: http://www.kielnet.de AS# 25295 Key fingerprint: 65B6 90FC 010A 39CE DCA5 336D 9C45 3B7A B02D E132 221 2.7.0 Error: I can break rules, too. Goodbye. Geschaeftsfuehrer Eberhard Schmidt HRB 4499 (Amtsgericht Kiel) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHnd6FnEU7erAt4TIRAqKCAJ0ZiqMPmDoI+eEJuR+cat6X1cxMqQCeJx1+ /OK+rUN15FwrToc7F8EsTiE= =3oXi -END PGP SIGNATURE- ___ 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] New to Juniper (re-try)
[edit] show | compare On Dec 27, 2007 2:06 PM, Wayne Lansdowne [EMAIL PROTECTED] wrote: Hello all, I apologize..my first posting attempt did not come through correctly. I'm new to the Juniper routers having previously worked with Riverstone. Within the Riverstone CLI I had the ability to preview all the pending (non-committed) changes via a 'scratchpad' command. Does the Juniper have a similar feature? I'm unable to find anything thus far to display a list of yet to be committed changes. Thus far I'm simply doing a 'commit check' then 'commit' and hoping I had remembered to implement all my changes. I'm basically looking for a way to review all the pending changes before making that commit. I've done some searching and have come up empty. Is there a CLI command I'm missing? Regards, Wayne ___ 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] Measuring Fast Reroute
Imran, The show mpls lsp extensive will give you a history of the 50 most recent state events - this probably will not be enough however. If you have the traceoptions set, you should be able to see additional information. [edit protocols rsvp] set traceoptions file rsvp.log set traceoptions flag packets file show /var/log/rsvp.log Hope this helps. -Andy On Nov 13, 2007 1:49 PM, Imran Moin [EMAIL PROTECTED] wrote: Hello everyone, I have a situation where I need to remove Fast Reroute through the RSVP signalled MPLS backbone. However, before doing that, I would like to know how many times Bypass LSPs have been used for forwarding traffic in the last 30 days or so. Is there a way to find this out on Juniper routers? Thanks for the inputs. Regards, Imran. ___ 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] load balancing between juniper routers for unequal cost path
Hi Hamid, To expand on Chris's explanation, ECMP is Equal Cost Multi-Path, which allows for the use of 2 (or more) equal cost path at the same time; Load balancing the traffic between the different paths. As Chris also mentioned, this load balancing is done per flow and not per packet, so you don't get any reordering of packets. What you will need to do is create 2 different RSVP Signaled LSPs towards the router which you want to add more traffic, then you need to export these 2 LSPs in OSPF (not turn OSPF off!) so that the routing protocol can see and use these 2 new paths. In the end, you will have 2 equals paths going in 1 direction, and a single path in the other. If you need to move more traffic, then simply add a 3rd, 4th, etc LSP. Please let me know if you need further explanation/configuration samples. -Andy On 11/8/07, Hamid Ahmed [EMAIL PROTECTED] wrote: Hi, Its LAyer 3 load balancing. The traffic intended for load-balancing does is on pure IP with OSPF running and having unequal cost paths regards, Salman. GAY Samuel [EMAIL PROTECTED] wrote: Hi, Which kind of load balancing do you want to do ? layer 3 ? layer 4 ? Are you on a MPLS network ? Regards, Samuel Hamid Ahmed a écrit : Hi Everyone, CAn anyone suggest me how to load balancing between juniper routers for unequal cost paths. BR// HA __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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 __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] mlppp
Yes, this is definitely possible. We have done it using SSG-20 with 2xADSL mini-PIMs at the Customer end, and an ERX on the provider end. On 8/1/07, mixalis mixailidis [EMAIL PROTECTED] wrote: hello Can I aggregate two ADSL lines to act as one thus achiving more bandwidth using mlppp? ** ** ___ 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] JunOS Litterature
Hi Jad, There is some free training available on Junipers website - http://www.juniper.net/training/technical_education/#web - that may be of help. -Andy On 6/4/07, Jad KAROUT [EMAIL PROTECTED] wrote: Hi everyone, i am a newcomer to the world of Juniper routers. I've tried to self-train so far using the online documents available on juniper.net however this is not quite what i need i guess. So i was wondering if any one had recommendations for juniper litterature ? I'm aware for instance of O'reilly's Junos cookbook but is there anything else ? Any recommendations ? Thanks in advance, Jad. ___ 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] runaway MAC interrupt count
Hi, Ive seen this a couple of times lately and I cant seem to find any related doc's as to explain what this issue is. Would be grateful if someone could enlighten me as to what this represents. The error is: Message from [EMAIL PROTECTED] cfeb at Apr 25 14:35:13 ... ibis-gw-2 cfeb SGE(1/0): runaway MAC interrupt count (101) This appears on the console. The hardware is M10i, softawre is 8.2R2.4 thanks -- andy[EMAIL PROTECTED] --- Never argue with an idiot. They drag you down to their level, then beat you with experience. --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] iBGP convergence time
-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp -- andy[EMAIL PROTECTED] --- Never argue with an idiot. They drag you down to their level, then beat you with experience. --- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp