[j-nsp] Ex2200
Hi Guys, Just having a look through the ex2200 datasheet and cant see if the switch can do L3 policing. I understand that it does basic L3 functionality like static routing but I would have thought that policing would be a basic L3 function. Can anyone else confirm? Nick -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. Any offers or quotation of service are subject to formal specification. Errors and omissions excepted. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Lumison. Finally, the recipient should check this email and any attachments for the presence of viruses. Lumison accept no liability for any damage caused by any virus transmitted by this email. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Microsoft NLB cluster with EX-series
Hi all, For the record, we ended up putting the server interfaces participating in NLB in dedicated VLANs. We have 4 NLB clusters across 4 physical servers so we ended up with 4 new VLANs each with 2 member switch ports. This seems to be a fairly common workaround to limit the spread of flooded traffic (which, of course, is expected with NLB). There still seems to be a bad NLB/EX-series interaction which could be caused by one of the many multicast bugs fixed in 10.0S10 but I haven't yet had time to confirm. IGMP snooping shouldn't have to be disabled to make this work. Cheers, Dale On Mon, Nov 15, 2010 at 10:33 PM, Dale Shaw dale.s...@gmail.com wrote: Hi all, Has anyone been given the torturous task of supporting Windows servers running NLB? (in multicast mode w/IGMP). Horrible things. Ptooey! It's wreaking havoc at L2, flooding traffic all over the VLAN because I haven't been able to make it work at all with IGMP snooping enabled. I'm doing my best to isolate the badness. I've got the static ARP entries in to support the *unicast* IP to multicast MAC mapping. I couldn't find a way to set a static ethernet-switching table entry using a multicast MAC. With IGMP snooping enabled, show igmp-snooping member creates the right entries but for the multicast group address reverse-derived from the multicast MAC. The problem seems to be forwarding L2 multicast traffic across a dot1q trunk. I've tried 'set protocols igmp-snooping vlan BLAH interface trunk multicast-router-interface' to no avail -- it helps with the IGMP snooping entries on the far side but traffic just doesn't seem to make it. EX4200 running 10.0R4 (same end result as with 10.0S1 but there are known problems with IGMP snooping fixed in 10.0R4 so I upgraded) I've got a case open with the JTAC but it's moving fairly slowly. cheers, Dale ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unable to display ARP table on M10i
On Fri, Nov 12, 2010 at 05:58:33PM +0200, Alexander Shikoff wrote: Hello, I'm unable to display ARP table on my M10i box with JunOS 9.5R1.8. minot...@br1-gdr.ki show arp no-resolve expiration-time ... and silence. The command is just hanging and there is no any output, but I'm still able to break it with Ctrl+C. What may be a reason of such behavior? Thanks in advance. 'clear arp' also hangs. when 'clear arp' or 'show arp' are being executed top shows: last pid: 35703; load averages: 1.02, 0.91, 0.60up 34+17:03:02 14:31:12 62 processes: 2 running, 60 sleeping CPU states: 22.9% user, 0.4% nice, 76.0% system, 0.8% interrupt, 0.0% idle Mem: 472M Active, 96M Inact, 119M Wired, 49M Cache, 69M Buf, 1308K Free Swap: 1536M Total, 4020K Used, 1532M Free PID USERNAME THR PRI NICE SIZERES STATETIME WCPU COMMAND 35700 root1 1220 2560K 1896K RUN 6:56 93.85% arp [...] Did anyone have such issue in the past? -- MINO-RIPE ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] AUTO: Harris Hui is out of the office (returning 11/22/2010)
I am out of the office until 11/22/2010. I will be on Vacation starting on 15/11/2010 and will return on 22/11/2010. For any Network queries or requests, please contact the following Network engineer: 1). Daniel E Chang (US) 2). Keith Sagon (US) 3). Tatsuya Kawasaki (US) 4). Tony CY Tong (HK) 5). Hillson Ng (HK) For any Network change approval, please contact: 1). Kent Ho (HK) 2). Robert Hood (US) 3). Titan Hon (HK) Otherwise I will respond upon my return. Thanks Harris Note: This is an automated response to your message Re: [j-nsp] Unable to display ARP table on M10i sent on 11/17/10 20:33:48. This is the only notification you will receive while this person is away. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] AE Bundle Load Balancing | EX series
Hi Bill From JUNOS Enterprise Switching book (page 629) - Load balancing over AE When sending traffic over multiple member links, the draft specifies that traffic that is part of the same “conversation” should always be on the same link. This is done by creating a hash, based on the conversation and specifying that every packet with that hash takes the same link. The exact details of the conversation are not defined, but in JUNOS the hashing works as follows: • Non-IP traffic hashes on the source and destination MAC addresses (SMAC and DMAC). • IP traffic uses the SMAC and DMAC addresses and the IP address, and, if Layer 4 is present, port numbers. These flows are not user-configurable at this time. The hash is used only for transit traffic over the AE link. CPU control packets are always sent out on the lowest-numbered link. Hope this helps. Regards, Ramesh On Tue, Nov 16, 2010 at 4:15 PM, Bill Blackford bblackf...@nwresd.k12.or.us wrote: How would I determine the load balancing method in use for aggregated Ethernet bundles, what the choices are and how to change? Thanks, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD Logged into reality and abusing my sudo priviledges ___ 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] UDP helpers
I have an unusual request to forward uncommon UDP BCASTs from one VLAN to another. Typically, this is DHCP or netbios traffic and honestly, I've only done this in a vendor C environment. I have to forward a specific M$ SQL port and I'm not sure how to approach this. Is there anyone on the list who is doing this and would care to share? Thanks in advance, -b -- Bill Blackford Senior Network Engineer Technology Systems Group Northwest Regional ESD Logged into reality and abusing my sudo priviledges ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] EX 10.0S10.1
I found it in Bulletin PSN-2010-11-992. I get the email notifications and this was linked in it. -b From: Keegan Holley [mailto:keegan.hol...@sungard.com] Sent: Wednesday, November 17, 2010 1:39 PM To: Bill Blackford Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] EX 10.0S10.1 On Tue, Nov 16, 2010 at 4:44 PM, Bill Blackford bblackf...@nwresd.k12.or.usmailto:bblackf...@nwresd.k12.or.us wrote: So I recently updated almost everything to 10.0R4.7 (I still have some stuff on 10.0S1.1). I'm not experiencing any issues, that I'm aware of. I would like to see the IGMP snooping issues ironed out, but for the most part, I'm content. My question is should I wait 'til the next recommended release, or is there a compelling reason I should update everything again, now? I am a little concerned about the [PR/546674 EX4200 Virtual Chassis problem not passing traffic] issue. Do you have more info on this bug? I searched the PR database but the bug with that ID only lists the following. JUNOS PROBLEM REPORT NUMBER : 546674 JUNOS Problem Report Information NUMBER 546674 SEVERITY critical CATEGORY sw STATE open SYNOPSIS pfem core 0x018f599c in nh_composite_add (nh_params=0x9068ed48, nh=0x906d6bb8) ARRIVAL DATE 2010-08-24 23:29:04 LAST MODIFIED 2010-11-11 18:10:22 CLOSE DATE - RELEASE NOTE The PFE core-dump may happen due to the case of having non-existent l2 unicast-nh. This core dump will not be seen with the fix. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
