Re: [j-nsp] MS NLB multicast mode and EX 12.x new behaviour issues
* Tarko Tikan ta...@lanparty.ee [2013-04-28 19:12]: By 'mixed' you surely mean painful. E-s filters do not work for STP, period. STP traffic is captured to RE first, bypassing all ingress filters and is then sent out from RE to be flooded as normal multicast. Hi, I can't confirm this. We have working bpdufilters on EX since at least 11.2 by manually filtering with a firewall filter. I'm pretty sure that it worked in 10.4 but can't find a current example. 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
[j-nsp] Unable to ping all NE when MAC are learned in Bridge group
Hey Guys,
We are migrating some NE to new MX-5 LER. I have started with moving mgmt
to an IRB, IRB is in the bridge domain and in the routing instance. When
cut over about half the NE are no longer accessible.
When the NE are cut back to old default GW (resides on a c7609 within a RI)
and pass through the MX as L2 with in the bridge domain only it all works
fine. Only when cutover to the NE PE does it break on some devices.
All routing appears to be working as some NE with in the subnet
are accessible. not sure why other are not? any idea would be appreciated.
jfortier@routermx5# show
description management irb;
mtu 1600;
unit 101 {
description Management VLAN101;
family inet {
address 10.64.0.1/24;
}
}
jfortier@routermx5# show bridge-domains
101 {
description Management VLAN 101;
domain-type bridge;
vlan-id 101;
interface ge-1/0/1.101;
interface ge-1/0/2.101;
interface ae1.101;
interface ae0.101;
interface ge-1/0/0.101;
routing-interface irb.101;
}
jfortier@routermx5# show routing-instances mgmt_nes
instance-type vrf;
interface irb.101;
interface irb.102;
route-distinguisher 10.92.6.20:3141;
vrf-target target:64512:101;
vrf-table-label;
Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Unable to ping all NE when MAC are learned in Bridge group
gARP is not reliable and Your NE devices' ARP cache still contains old MAC
from old default GW.
You have to revisit them one by one and clear their arp caches, or change
IRB MAC to that of old default GW' MAC.
HTH
Thanks
Alex
- Original Message -
From: Jason Fortier jasoncfort...@gmail.com
To: juniper-nsp@puck.nether.net
Sent: Tuesday, April 30, 2013 6:18 PM
Subject: [j-nsp] Unable to ping all NE when MAC are learned in Bridge group
Hey Guys,
We are migrating some NE to new MX-5 LER. I have started with moving mgmt
to an IRB, IRB is in the bridge domain and in the routing instance. When
cut over about half the NE are no longer accessible.
When the NE are cut back to old default GW (resides on a c7609 within a
RI)
and pass through the MX as L2 with in the bridge domain only it all works
fine. Only when cutover to the NE PE does it break on some devices.
All routing appears to be working as some NE with in the subnet
are accessible. not sure why other are not? any idea would be
appreciated.
jfortier@routermx5# show
description management irb;
mtu 1600;
unit 101 {
description Management VLAN101;
family inet {
address 10.64.0.1/24;
}
}
jfortier@routermx5# show bridge-domains
101 {
description Management VLAN 101;
domain-type bridge;
vlan-id 101;
interface ge-1/0/1.101;
interface ge-1/0/2.101;
interface ae1.101;
interface ae0.101;
interface ge-1/0/0.101;
routing-interface irb.101;
}
jfortier@routermx5# show routing-instances mgmt_nes
instance-type vrf;
interface irb.101;
interface irb.102;
route-distinguisher 10.92.6.20:3141;
vrf-target target:64512:101;
vrf-table-label;
Jason
___
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] Unable to ping all NE when MAC are learned in Bridge group
I have tried clearing arp for most of the devices, I have also moved the
same config to MX480 PE, All NE become reachable. Below is a simple
network layout.
NE-MX5-1--MX5-2MX480C7609--MGMTNETWORK
When MX5-1 becomes a PE some of the NE be come unreachable.
One thing of note it that the MX5-1 mpls interface is on LU 2500 on VLAN
2500. other then that the same FF are plied on the MX480
On Tue, Apr 30, 2013 at 11:18 AM, Jason Fortier jasoncfort...@gmail.comwrote:
Hey Guys,
We are migrating some NE to new MX-5 LER. I have started with moving mgmt
to an IRB, IRB is in the bridge domain and in the routing instance. When
cut over about half the NE are no longer accessible.
When the NE are cut back to old default GW (resides on a c7609 within a
RI) and pass through the MX as L2 with in the bridge domain only it all
works fine. Only when cutover to the NE PE does it break on some devices.
All routing appears to be working as some NE with in the subnet
are accessible. not sure why other are not? any idea would be appreciated.
jfortier@routermx5# show
description management irb;
mtu 1600;
unit 101 {
description Management VLAN101;
family inet {
address 10.64.0.1/24;
}
}
jfortier@routermx5# show bridge-domains
101 {
description Management VLAN 101;
domain-type bridge;
vlan-id 101;
interface ge-1/0/1.101;
interface ge-1/0/2.101;
interface ae1.101;
interface ae0.101;
interface ge-1/0/0.101;
routing-interface irb.101;
}
jfortier@routermx5# show routing-instances mgmt_nes
instance-type vrf;
interface irb.101;
interface irb.102;
route-distinguisher 10.92.6.20:3141;
vrf-target target:64512:101;
vrf-table-label;
Jason
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Fwd: bgp license mx480 MPC-3D-16XGE-SFPP
On Friday, April 26, 2013 06:21:54 PM John pp wrote: i have been told its an honor system however someone i know bought the license and it was just a piece of paper saying they could use it The rumour is that at some point in the future, Juniper will add capability in newer release of code that physically enforces these licenses in software/hardware. So while it could be just a paper/honour license today, it might not be tomorrow, in which case you either don't upgrade Junos or you buy the license. I generally don't like licenses (especially now when both Cisco and Juniper are going stir-crazy with them in recent years), but I really don't like the ones that don't make any sense to me. With all my rumbling with the vendors, licenses appear to be a point of view perpetuated by vendors that are inspired by customers with varying needs and so few boxes to meet them. Oh well... Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Problems with Link Aggregation
On Monday, April 22, 2013 04:54:48 PM Pavel Lunin wrote: For L3 (bridged and routed) EX switches construct hash value from several (6, IIRC) least significant bits of L3 and L4 addresses/ports. MAC addresses (and only MAC addresses) are used for non IP bridged traffic. So, say, (with an exception of EX8200, which can has labels) all MPLS streams between a given pair of routers will follow a single link in spite of labels and payload. And therein lies the issue - well, for us anyway. I need to find out whether the EX4550 have this issue as well. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Problems with Link Aggregation
On Monday, April 22, 2013 10:16:10 AM Ivan Ivanov wrote: http://kb.juniper.net/InfoCenter/index?page=contentid=KB 10926actp=searchviewlocale=en_USsearchid=136661818 Here is written that it uses layer 2,3 and 4 for load balancing hash algorithm. Which doesn't explicitly include MPLS traffic. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Best route reflector platform
On Wednesday, April 24, 2013 02:24:18 PM Richard A Steenbergen wrote: I really can't imagine that the benefit of selling an extra MX240 chassis, even if sold at regular price, is worth the money being lost from everyone else. One would hazard that the twisted thinking of someone at Juniper is that get yet-another-MX chassis into the customer's network, and hope that some bean-counting schmuck will say to the Engineering team, Hey, why do you want me to buy another MX chassis yet you have this big thing which can run both your route reflector function and the Multicast video services the Board is asking us to push by Q4'some year?. Since new products need low capital to get off the ground, Juniper will see an order for new line cards for what was a dedicated route reflector, and perhaps down the line, expect the customer to order another chassis so they can get back there dedicated route reflector once the new product starts making money... ... or something silly like all that. Who knows what Juniper are thinking? I stopped caring. Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Fwd: bgp license mx480 MPC-3D-16XGE-SFPP
In the Release Notes for JUNOS 12 something for EX, there is an example of commit error when you use a protocol without a license and you cannot use it. I am missing the right link now but it stood out as it was the first time I saw it. On Wed, May 1, 2013 at 12:32 AM, Mark Tinka mark.ti...@seacom.mu wrote: On Friday, April 26, 2013 06:21:54 PM John pp wrote: i have been told its an honor system however someone i know bought the license and it was just a piece of paper saying they could use it The rumour is that at some point in the future, Juniper will add capability in newer release of code that physically enforces these licenses in software/hardware. So while it could be just a paper/honour license today, it might not be tomorrow, in which case you either don't upgrade Junos or you buy the license. I generally don't like licenses (especially now when both Cisco and Juniper are going stir-crazy with them in recent years), but I really don't like the ones that don't make any sense to me. With all my rumbling with the vendors, licenses appear to be a point of view perpetuated by vendors that are inspired by customers with varying needs and so few boxes to meet them. Oh well... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] EX4550 MPLS CCC
Hello, Good evening, We bought some JUNIPER EX4550 and put in a simple topology and simple configuration, trying to use MPLS CCC togheter with tagged Vlans (ethernet switching). We come with JUNIPER and they said not to be possible in this case, use two encapsulation types on the same interface (like MX ...). We then made the separation of types of traffic and transportation using physical ports. However, when we set up the interface for support VLANs mode CCC (vlan tagging encapsulation vlan-ccc) ... after the commit it's a warning that will only support vlan-id 1 to 511. Is there any way to not have this limitation? The other way to encapsulamente and ethernet-ccc. Anyone ever used the EX4550 switches to this functionality? Could you help us? The most documents also refers to EX8200. Thank you, Giuliano ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
