[j-nsp] RA Guard Support on EX Series Switch
Dear List, we are currently evaluating different switch vendors for our network. I am mainly interested in IPv6 Security Features like DHCPv6 Snooping, RA Guard etc. According to this Whitepaper from Juniper: http://www.juniper.net/us/en/local/pdf/whitepapers/2000418-en.pdf RA Guard, DHCPv6 Snooping will be supported in a future release I have looked up the available features on the ex series switches http://www.juniper.net/techpubs/en_US/junos/topics/concept/ex-series-software-features-overview.html but couldn't find any sign of the features mentioned above. Does anyone know when these features will be implemented? Thanks in advance. Cheers, Chris ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] proxy arp C vs J
Did you check what MACs are used in 1st, 2nd and 3rd time? Specifically MAC OUIs. I suspect this is a side effect of having C-J in the same broadcast domain. Basically, when J-interface ARPs for a connected host, _AND_ if C has a specific route to that host/32, the C will answer with own MAC. I have seen this myself many times and I suggest to disable proxy-arp on C to get rid of this behavior. HTH Thanks Alex - Original Message - From: biwa net biwa...@gmail.com To: juniper-nsp@puck.nether.net Sent: Monday, February 06, 2012 7:57 PM Subject: Re: [j-nsp] proxy arp C vs J Forgot to add we are running MX80 on Junos 11.2 On 6 February 2012 19:56, biwa net biwa...@gmail.com wrote: Hi Guys We are experiencing some issues in one of our client sites, Basically we migrate from a Cisco to a Juniper MX80, and since there has been some issues, mainly we are seeing IP addresses being shared by 2-3 mac address, to be precise , mac address being rewritten , ie: one IP is being seen on the Juniper owned by 3 different mac address within one hour ( the 1st mac address is being re-writen by the 2nd one and then 2nd by the 3rd mac). This is causing a lot of users not having any kind of internet connectivity.When we rollback to the Cisco device , this issue does not occur. After investigation we can safely eliminates the DHCP server being the cause of issue (, also proved when Cisco is roll back in the topology), The config of the Cisco is fairly simple and is almost 99.99% than the one being copied over to the Juniper. One thing we notice is that both Cisco and Juniper has proxy-arp configured on some of the interface, and we are planning in our next maintenance to disable it. my question is: is the proxy-arp behavior in Juniper slightly different than the Cisco ? thanks for your inputs ___ 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] proxy arp C vs J
On Tue, Feb 7, 2012 at 2:23 AM, Alex Arseniev alex.arsen...@gmail.com wrote: Did you check what MACs are used in 1st, 2nd and 3rd time? Specifically MAC OUIs. I suspect this is a side effect of having C-J in the same broadcast domain. Basically, when J-interface ARPs for a connected host, _AND_ if C has a specific route to that host/32, the C will answer with own MAC. And potentially, depending on the configuration, the Cisco may try and proxy based on a route learned from the Juniper, creating a loop. The question I would ask: what is proxy arp used for? why? Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] proxy arp C vs J
Proxy ARP can be useful while sorting out a broken (misconfigured) network, but can also cause you a lot of grief. If the network is configured correctly, it's just a hindrance. Most definitely turn it off, then fix any routing issues it was masking. I see someone mentioned turning off gratuitous arps, but I'd only do that if really necessary, as its very useful for forcing a refresh of an entry e.g. E-Series cable customers Cheers, Gordon -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of biwa net Sent: Tuesday, 7 February 2012 5:57 a.m. To: juniper-nsp@puck.nether.net Subject: [j-nsp] proxy arp C vs J Hi Guys We are experiencing some issues in one of our client sites, Basically we migrate from a Cisco to a Juniper MX80, and since there has been some issues, mainly we are seeing IP addresses being shared by 2-3 mac address, to be precise , mac address being rewritten , ie: one IP is being seen on the Juniper owned by 3 different mac address within one hour ( the 1st mac address is being re-writen by the 2nd one and then 2nd by the 3rd mac). This is causing a lot of users not having any kind of internet connectivity.When we rollback to the Cisco device , this issue does not occur. After investigation we can safely eliminates the DHCP server being the cause of issue (, also proved when Cisco is roll back in the topology), The config of the Cisco is fairly simple and is almost 99.99% than the one being copied over to the Juniper. One thing we notice is that both Cisco and Juniper has proxy-arp configured on some of the interface, and we are planning in our next maintenance to disable it. my question is: is the proxy-arp behavior in Juniper slightly different than the Cisco ? thanks for your inputs ___ 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] SCB-E
Anyone running the SCB-E? I've got a stack of them with a set of fresh MX480s ready to roll out. I'm curious what code your running. These will be paired with MPC blades… ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SCB-E
On Wed, Feb 08, 2012 at 01:23:11AM +, OBrien, Will wrote: Anyone running the SCB-E? I've got a stack of them with a set of fresh MX480s ready to roll out. I'm curious what code your running. Given that there is only one public JUNOS release which supports SCB-E, there aren't many options: 11.4R1 - and that one has unusable SNMP due to new PFE statistics request delays introduced (feature, not bug of course!): foo@lab-MX960 show snmp mib walk ifHCOutOctets | count Count: 413 lines $ time snmpbulkwalk -v2c -c removed x.x.x.x ifHCInOctets /dev/null Timeout: No Response from x.x.x.x real0m26.380s user0m1.647s sys 0m0.133s PR/731833 - fix supposed to come in 11.4R3 slated for May. So as far as things stand, SCB-E not deployable before mid 2012 earliest if (and that's a big if when looking at 10.4 experience) 11.4R3 is going to be usable. Ah, and 11.4R1 floods your log with messages like: mcsn[91713]: %DAEMON-6: krt_decode_nexthop: Try freeing: nh-handle: 0x0 nh-index: 1049083 fwdtype: 3 No idea wether that's service affecting - we haven't observed any impact due to that yet. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
