Switching

I just tried setting up the vme0 port on a large stack of EX4200s.  I assigned vme0.0 an IP address in our "legacy" Cisco network, and the port was reachable, but I presumed that packets from vme0 were getting routed back through the trunks on other interfaces in the stack via the routes found in the routing table, rather than egressing back though the vme0 port. The "legacy" and "new Juniper" networks are connected together at only one point, distant from the stack.

Since I did not see an option to set a default route on the vme0 port independently of the static routes in routing-options, I added a static route for the legacy subnet the vme0 port was on, and the whole stack went offline. (dhcpd died and dumped core as well.) So I rolled back (from the serial console) and all is OK. I am stiil looking through the logs trying to figure out what happened, most likely a spanning tree issue.

I have some general questions:

1) Do I have to consider spanning tree when attaching a vme or me interface to a network, i.e. does it send out BPDUs?

2) Do I have to consider routing issues on vme or me interfaces? I have my OSPF config set to:

export export-edgeroutes;
area 0.0.0.0 {
    interface vlan.0 {

with

vlan {

default {
    l3-interface vlan.0;

I.e. with the vme / me interface uncommitted to a VLAN, will it join the default vlan and start participating in OSPF?

3) Do vme0 and me0 basically behave identically to with respect to the above two questions?

Thanks,

-w

Hi W, I hope that you already know that but just to be sure,

The ME and VME interfaces are Out-of-Band interfaces which means that you cannot route packets from a host conncted on an other interface of the switch or via a "trunk" of this switch.

You can only route packet "going to / comming to" the local routing engine.

I am not sure That this is your main problem but I think it could be.

Just tell me If you knew this point

Regards

I know the me and vme interfaces are out of band, but how do they get their default route? They have to either get it by listening to a dynamic protocol or via a static in the routing-options section, right?

Hi,

Of course you need some route to be able to go to the management site via the ME or VME interfaces.

In a regular config you will use a static route but you can also use a routing protocol.

In case you use a routing protocol you must take care not to interact with your IGP use in your production network.

So the best config would use a stic route without redistributing it in a routing protocol, to be sure not to disturb your production network.

The typical statement would be this kind:

User@Switch# show routing-options 

static {

    route 0.0.0.0/0 {

        next-hop 192.168.0.254;

        no-readvertise;

    }

}

I know where you're going with this (I assume).. What you're looking for is to have your normal routing table default route a long with default route for teh VME/ME interfaces.. Simply put, not possible.

If you code a default route for the VME it will over-ride any dynamically learned from a routing protocol.. I have put in a feature request with Juniper to allow this interface to be put into a VRF to allow for multiple routing tables.. Why this feature has never been thought of is beyond me..

To do this on any other series of platform you have to create a logical-router and put that interface into it.. As EX series don't support logical-routers at this time it's not possible to do so..

We're a Cisco shop reviewing EX devices and require the feature stated above (among many other), unfortunately since the platform doesn't have it we can't deploy EX devices as of now.

That's the answer I was looking for - it does seem odd that the feature is missing. Most other "management ports" attempt to be Out-Of-Band and have their IP settings separate from the rest of the config. Otherwise it's "Out of Band Sort-Of".

I don't have any problem with in-band management in my shop, I only live a 10-minute drive away from all my devices, and I never make mistakes working from home, ha ha ha. But I was very impressed that I could bring down my backbone by misconfiguring the vme interface.

I guess the market for used RS232 terminal servers has to be kept alive somehow.

Haha, totally understand what you are saying.

The company I work for (financial firm) has a huge Cisco presence and Juniper is barking to get in the door. However everytime we review their platforms they just don't seem to have the features needed to replace a Cisco box in our shop. It's not like we're doing anything crazy, it's just that Cisco has had many more years of experience in the enterprise environments so they've created all the tweak features needed. We mostly use Catalyst 6500 platform, while it doesn't do everything the best, it is the industry standard swiss army knife switching platform simply put as it can do about anything you can think of.

Juniper has been in many times asking how they can differentiate themselves from Cisco with their switching platforms.. I keep telling them "BE CISCO FIRST" then you can differentiate. What good to me is a box that can do features X, Y, Z when features A, B, and C are the ones that are mandatorily required (out of band mgmt being one) yet you don't have...

Rather frustrating.. I keep asing for features, but its like barking up a tree at times..

Hi all,

I don't understand what your talking about:

Why do you want to use a default route on the WME port?

Why don't you use a precise Static route to go to the management site ?

In case you were able to achieve this on other JUNIPER platforms with "logical-router" you must know that you can (on EX platform) separate your routing tables with "vitual-router, routing-instance type".

Realy I don't understand where you're stucked !

Here is an example of a routing table with default route received via OSPF and out-of-band management (with a precise route) at the same time working OK:

User@EX3200> show route   

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[OSPF/150] 00:00:12, metric 0, tag 0
                    > to 10.0.0.2 via ge-0/0/0.0
10.0.0.0/30        *[Direct/0] 2d 12:58:02
                    > via ge-0/0/0.0
10.0.0.1/32        *[Local/0] 2d 12:58:02
                      Local via ge-0/0/0.0
10.20.0.0/16       *[Direct/0] 2d 17:20:55
                    > via me0.0
10.20.0.17/32      *[Local/0] 2d 17:20:55
                      Local via me0.0
10.50.0.0/16       *[Static/5] 00:06:40
                    > to 10.20.0.254 via me0.0
224.0.0.5/32       *[OSPF/10] 2d 12:58:03, metric 1
                      MultiRecv

Try putting the VME interface in a VRF.. When you commit it, it will tell you that it is unsupported.. This is what we're speaking of. It is this way among all JUNOS platforms. You can get around this with platforms that support logical routers though.

He just wants to have two routing tables. As the VME shoudl be fully out of band, it should have a seperate routing table for that interface. However it is not possible. The VME and all other interfaces share the same routing-table by default, thus causing the issues.

BuckWeet

Also to further clarify your question.. In our network we have several network management segments. Too many to want to individually static route for, so we just do the supernet route out the VME port. However since these switches participate in our routing-domain they get the more specific subnet routes from the routing protocol.

So what happens is that your request comes in via the VME interface, but return traffic uses in-band interfaces due to the better route being in the table..

Not all of us have a single network management segment.. My company has about 25 subnets spread across the globe. this is where this feature is important.

BuckWeet

OK , I understand your problem !

So that should be easy to leave the VME interface in the main routing table and the real "transient" interfaces in a VR type routing-instance !

I am also surprised that you're not able to have some supernet for your management network !

I understand that you'd like to have Logical-router (logical-system now) on EX switches, so would I, but i am not sure we will have this since a long time.

Alain

You could put all other interfaces into a vrf, but that is an idiotic way to do it in my opinion.. If I were to have an 8216 fully poppulated with modules, it would mean i have to put hundreds of interfaces into it. Let alone that JUNOS has a hack implementation of interface-ranges with 10.x, it's just cumbersome..

I asked my SE to put in a feature request to allow VME/FXP interfaces into a VRF.

BuckWeet

Hi BuckWeet

That's a nice request.

I'm not sure you will see it going out quickly !

Still doesn't understand why you're locked with this static "default" route.

Or your OOB network is completely unstructured !

I was just trying to help but it seems that can't be done

Kind regards

The Idiot guy who wanted to help you!

I to have had many times when a dedicated OOB-RI with it's own Default would have saved me plenty of pain.

On some sites it is a legislated requirement to seperate the managment plane traffic from the rest.

I had this issue with 9.4 and as of my testing on 10.1 there still seems to be a lack of urgency from Juniper about this need.

I would imagine this would not be to hard to add in.

On Extreme XOS devices they have VR-Default and VR-MGMT.  You can cretate your own as you require but the OOBMI are all in the MGMT VLAN which is in the VR-MGMT.

It takes about 3 minutes to set this aspect of the product up.

Juniper should start to take this request on board as a OOBM Network should be standard practice for all networks with more than a half dozen switches.

For me the work around was to go inband and to ensure all managment interfaces are access-limited and encrypted.

Regards

Marc

+1

I need my management routing separate to my main routing table.  On a managed customer fw, there's no way the customer equipment should ever see my management network regardless of any fw rules blocking them from management.

I was just about to add exactly that point about Extreme. 

With extreme the MGMT port is predefined with a separate VR instance. 

Separate routing table for both in fact its not possible to route between the 2 which is exactly what you want. 

I still find it hard to belive JUNOS does not support this, the whole point of the MGMT port is it is a separate interface to the management much like the serial port, only IP.

This is an example config to configure the MGMT on an extreme, job done. 

configure vlan Mgmt ipaddress 172.27.233.43 255.255.255.0
configure iproute add 10.0.0.0 255.255.255.0 172.27.233.254 vr VR-Mgmt

Simon

Please don't say this is still a restriction ?? I've just spent the last half an hour trying to do this (yeah, yeah. I'm a cisco head, that's why it took so long ;))

How would I go about looking to see if it's been scheduled as an enhancement request ?

Stephen - the Juniper party line is that you need to talk to your Juniper Sales Team and get them to submit an enhancement request for you. I don't think you will get any feedback as to where it is in the priority list, or if it is even on the list (unless you have a lot of clout) but the more requests the more Juniper will listen and do the obvious fix.