The MX platform does not have the general concept of a "VLAN" that is present on the whole platform. The MX only "sees" VLAN tags on incoming packets and can then act on these tags. What you want is to bridge packets from two ports that have the same VLAN-ID in the L2 header and then add a L3 interface to that bridge.
On the MX platform you have two ways of ...
Unfortunately, Brocade gear will not send out CDP packets for Cisco gear to understand. Brocade gear only transmits FDP, but it will be able to understand (most of) the information in CDP packets if configured to intercept them. Enabling CDP on a chassis only configures the device to intercept CDP packets.
Your best bet (if all equipment is under your ...
As far as I know, you can only tell Brocade to intercept (i.e. be able to understand) CDP or not (i.e. forward them along). If you have CDP off, then they will be forwarded on and won't show up in a show fdp neighbor output.
If you are mixing vendors, I would recommend that you look at having them all run LLDP if possible.
To name a few things: development, maintenance testing and support of software and hardware and of course: marketing and profit. Also, these vendors use dedicated ASICs so packet forwarding (amongst other things) are done in hardware instead of software. Basically, you buy a box which is optimized for one task: routing, which means all code and hardware has ...
The best solution is to plug a computer running a packet analysis software like Wireshark to an unused port and duplicate the traffic to this port. This is called mirroring and monitoring. Here is how to do this on a Brocade MLX, XMR, CER or CES :
First configure the mirroring port. This is the port you will plug you packet analyzer, ethe 3/1 here.
According to the FastIron config guide:
If the primary interface of a trunk is enabled for monitoring, the entire trunk will be monitored.
You can also enable an individual trunk port for monitoring using the config-trunk-ind command
Trunk in this sense being the FastIron term for an aggregated interface.
If this didn't work you could use a TAP, or ...
You need to add a statement to explicitly allow those prefixes after denying the default-route, so the final prefix-list becomes:
ip prefix-list no-default-route seq 5 deny 0.0.0.0/0
ip prefix-list no-default-route seq 10 permit 0.0.0.0/0 le 32
Always have at least two different ways to get into a core box remotely. Generally this means in-band and out-of-band. The inband would simply allow your management range to SSH into the box via any available port, while the out-of-band would be a different link via console or ethernet into the management card/fxp port/ etc
VRRP-E is Brocade only. From Brocade documentation:
VRRP-E is a Brocade protocol that provides the benefits of VRRP
without the limitations. VRRP-E is unlike VRRP in the following ways:
There is no “Owner” router. You do not need to use an IP address configured on one of the Layer 3 Switches as the virtual router ID
(VRID), which is the ...
It's important to note that PVST/PVST+ is Cisco proprietary.
They do support one instance of STP per VLAN, and it is enabled by default. You can enable/disable STP on the following levels (taken from the NetIron config docs):
Globally - Affects all VLANs
Individual VLAN - Affects all ports within the specified VLAN. When you enable or disable STP within a ...
My first thought would be that OSPF is thinking it's the same LSA instead of simply the same prefix. I don't know much about brocade, but with the LSA outputs from the Cisco box I could probably tell you more.
In general, for Cisco, if the routes are equal in the protocol they will both be presented to the routing table. The routing table, will, by default,...
EDIT: Just checked the literature - doesn't look like static LSP's are supported on MLX/XMR/CES/CER IronWare at least as of 5.2.0. :-/ My Brocade account rep also confirmed that LSP's signaled with RSVP or LDP are the only options and they have no plans to add support back in for static LSP's.
Aside from the above, what you can do with RSVP is define a ...
Removing previous answer as I misunderstood the question, and my previous answer was actually incorrect - MED is exchanged between peer ASN's but is not propagated beyond that (meaning it won't transit an AS to propagate to another AS). However it's still an optional attribute, so it's not required of an implementation to pass on the MED between eBGP/iBGP ...
This is the logical view of what you're trying to achieve:
Configure the router priorities for both VRRP 'a' and VRRP 'b' as follows:
Router 1: 110 (master)
Router 2: 100 (backup)
The configure interface tracking as follows:
Router 1 VRRP a: track interface R1b with a track priority of 90
Router 1 VRRP b: track interface R1a with a track priority of 90
Could someone please tell me the community string indexing for switches other than Cisco?
This is how to poll Q-BRIDGE-MIB for mac-addresses from the only non-Cisco I have, a DLink DGS-3200. I'm not using [community@vlan] for non-Cisco switches. You're correct that this indexing only applies to Ciscos. I expect any non-Cisco switch, which supports ...
The main current issue with the Brocade line is that you can only enable one at a time, per chassis. i.e. If you want to run VRRP-E, you'll never be able to run VRRP with another vendor on another port.
They are not compatible in any way. VRRP-E is proprietary.
I am considering whether ECMP makes sense for anycast. Routing should direct anycast to the logically-nearest destination in which one host would be favored over the other. Even in the case where the anycast hosts are equidistant, I would still expect this to remain true. As for ECMP load-sharing, I would think per-destination is impossible with a /32. ...
BGP graceful-restart is the mechanism that you are looking for.
Graceful-restart maintains forwarding for the routes that have been received from a BGP neighbor while the connection is being restarted. When the neighbor drops, the routes will be marked Stale (S) in the BGP table and will still be available for route selection.
There are two timers that ...
Many types of fiber connections, including 1000base-LH/LX, use two strands of fiber. However the strands are actually used individually as dedicated TX and RX on each and the traffic on each strand is entirely unidirectional.
So when you are connecting two such devices, you need to cross the strands at some point so that TX on one side matches up with RX ...
I can't reproduce this in my lab, using 12.4(24). Same topology, RCore area 0 loopback, R1 with lo0 and interface in area 1, R2 with lo0 and interface in area 2 (both NSSA), redistributed route gets picked up for ECMP on Rcore:
Routing entry for 10.20.0.0/16
Known via "ospf 1", distance 110, metric 20, type NSSA extern 2, forward metric 6477
have you read this? How to setup trunk and access ports in an MX80? - J-Net Community
It explains quickly how to set a bridge domain for your L3 interface, and add ports as either access or trunk. irb.200 would be your ve 200
You are really looking for the Brocade Track Ports and Track Priority features.
With these features configured, when the red connection fails, it will lower the priority of the green connection. This should then allow the blue connection to take over as master in the group.
Personally, I would also add a direct link between the two L3 switches as well.
The way I did it was with a "fabric recovery" tool. But this requires you to have a second switch with a known password. It erases the configuration (and passwords) from the entire fabric. (yes, a rather dangerous tool)
There's also the (nearly undocumented) root and factory accounts. WARNING: root access drops you to an os shell (vxWorks) from which you ...
interface ve 10
ip address x.x.x.140 255.255.255.248
ip dhcp-server pool noc
network 10.10.10.0 255.255.255.0
It doesn't work because ve 10 (the L3 interface) isn't within the noc dhcp pool (10.10.10.0/24) Your updated ve 20 is, but unless you have something upstream of here doing NAT, there won't be any internet access.
One way of doing this kind of thing with pure routing is to have the "service" IP addresses be secondaries on all the servers, and have routes as appropriate.
Consider this straightforward network where the clients AC and BC go through a router to get to the servers A1, A2, B1, B2. Everything has default gateway aimed at their network's .1. RA and RB ...
Same thing, different (older) branding. Normally for 802.1ad there's a C-TAG and an S-TAG. The C-TAG (customer tag) will have almost always have a value of 8100 set in its TPID (tag protocol identifier) field. The S-TAG (service tag - the tag on top) will have a separate set of fields (same as the C-TAG: PCP/DEI/TPID/VID bits) and its TPID should be 0x88a8 ...
Its not so much Brocades 'version' of Q-in-Q as it still uses the standard, think of it more as a difference in vocabulary, it is still compatible with other vendors such as a Cisco device running a normal qinq tunnel interface.
As you mentioned...
ip route 10.1.0.0 255.255.0.0 iface0
Forces the Brocade to proxy-arp for every destination in 10.1.0.0/16 as if it was directly connected to iface0.
I can't respond about Brocade's ARP cache implementation, but I would simply point out the easy solution to your problem... configure your route differently:
ip route 10.1.0.0 ...
If you are unable to stabilize your bgp sessions with longer timeouts or similar, here is a hack I have been forced to use on a few occations:
If there are only a limited number of routes, and you have a stable environment without too many regular changes, you could insert static routes with higher preference/cost than the bgp routes. When the bgp sessions ...