cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
627
Views
5
Helpful
11
Replies

Best Routing Method

visitor68
Level 4
Level 4

Hi, folks:

Please see attached drawing.

My question is straightorward.

I need to move traffic from site 1 to site 2 and back.

I have 2 separate metroE circuits as shown.

Assume I'll use statics for now.

Should I create 2 /30 subnets to connect R1 to R3 and R2 to R4?

OR is there any value in creating a /29 subnet (vlan 10, for example) and assigning addresses accordingly:

R1 10.10.10.1

R2 10.10.10.2

VIP 10.10.10.3

R3 10.10.10.4

R4 10.10.10.5

VIP 10.10.10.6

And then have the statics on R1 and R2 point to R3 and R4's VIP -- then vise versa....Have R3 and R4 point their statics to R1 and R2's VIP.

I think, since I am using staic routing, I should use the VLAN appraoch because I will just point the static to the VIP, and if one router fails, I wont have to repoint the traffic. Sort of a dynamic failover of sorts....I could achieve the same thing using floating statics I guess...you know...primary static on R2 points to R3 and floating static pointing to R1, incase R3 dies...

Anyway,is there a consideration to be made regarding L2 loop vulnerability since I am creating a vlan? Could the argument be made that a /30 approach would be bette to avoid using SVIs?

Thanks

11 Replies 11

glen.grant
VIP Alumni
VIP Alumni

Just use routed /30 interfaces between the sites. Ever thought of just using EIGRP or OSPF instead of static routing everything?

The client wanted statics, but then re-thought it out and is now considering dynamic routing, wich is what I proposed first.

I came up with a few proposals.

Can you take a look at them and comment, if you can?

The objective is to route subscriber traffic coming from "behind" the 8212's - route bearer traffic to the ASN GW, and OAM traffic to the WSM server.

The ex 4200s do RIP, not OSPF. They dont want to redistribute, for sure.

Thanks

Joe

Any chance you could post this as .jpg rather than a visio.

Personally unless you need L2 adjacency between sites i would look to use L3 routed links and a dynamic routing protocol. Seems like this is going to be your approach anyway.

Jon

OK, Jon....

There are 4 of them.....one that shows xisting, and 3 proposals. I will attach the proposal text, too.

Another post will have the tother 2...

Proposal 2 and 3....

EDIT = Take note that the objective is to havesubscribr traffic hit the ASN GW and the WSM server...the traffic will get split. OAM to WSM and bearer to ASN GW.

Jon:

I went through all the trouble of resending everything in jpeg format just for you....and now you disappeared! :-(

Where hast thou gone? :-)

Joe

Sorry, i've been a bit busy :-)

There's quite a bit of detail in the .jpgs so i'll have a look over the weekend and get back to you if that's okay ?

Jon

Thanks.,...Im just teasing...I appreciae every minute of your time....

Joe

Okay, had a look at the proposals. I'm assuming no L2 adjacency is needed between the 2 sites.

Definitely prefer options 2 & 3 over option 1.

Option 1 uses L2 trunks and you are going to have block on one of the links or add extra configuration to load-balance the vlans over both links. There is also the possibility of a broadcast storm taking affecting both sites.

The only question i would have on 2 & 3 are about the MX960-S devices. Because the links terminate on these devices now all traffic now has to go through these devices not just ASN traffic.

So is there any chance these devices could become a bottleneck between the sites ?

Assmuming there isn't the next point is about OSPF. I prefer 3 in this respect as you are redistributing statics into OSPF on MX960-S devices so less configuration to do on wsr01 and wsr02. And you also don't need static routes on MX devices for BTS subnets.

It's not clear if there is OSPF running anywhere else in the network. Just wondering why you have chosen to use an NSSA instead of just a normal area as by the looks of the diagram you are only actually running OSPF between the 4 routers linking the sites ?

Jon

Hi, Jon:

Traffic considerations have been made so we dont feel that there should be a bottleneck provided at the 960s.

I agree that L3 isolation and either using static routes or, preferably, dynamic routing, is the way to go.

OSPF is running on 4 boxes connected in a square - 2 aggregation routers that are uplinked to 2 internet-facing routers at site 2.

NSSA can be changed to regular area.

Can you give me a deatiled opinion Bout why it is bad to span the vlans across the metro E connections, as is being done presently and in proposal 1? Just want your take....?

Heres the background:

The client keeps repeating the same line over and over again - that the BTS (mobile base stations) send user-voice traffic and OAM (call management) traffic on the same vlan. This is the paradigm used at site 1 (wsr01 and wsr02 site). So, the challenege for the site 2 people is to 'separate" the traffic flows. Bearer traffic must go to the ASN GW, off the 960s, and mgmt traffic must go to the WSM server, off the 4200s.

They keep arguing that the best way to do it is through proposal 1. And I cant for the life of me understand why the traffic flows cannot be separated as shown in poroposal 2 and 3...?!?!?

Remember, the traffic type is generated at the BTS. So it sends bearer traffic AND OAM traffic. The "separate", if you will, is taking place at the beginning by the BTS -- at the application level, if you will.

So, the packets received by the 960 routers will have destination addresses pointing in 2 different directions - one for bearer and one for OAM. Bearer traffic will have a directly connected route to the ASN GW (those are L3 connections) and OAM traffic will use the static route on the 960s to go to the 4200s. Simple. No?

So, whats the problem with using proposal 2 and 3 to do it??

I think the client has coe up with a plan and they are trying to defend it no matter how incoherent it may be.

Thought???

Thanks!

Joe

Firstly option 1 will work and it's not necessarily a bad option. If you needed the same vlan in both sites eg. you have a cluster of servers that need to be on the same vlan but they are split into the 2 different sites, then connecting via L2 trunks is perfectly reasonable.

But in your scenario there is nothing that i can see that requires this adjacency. So assuming you don't need it is what led me to recommend the routed option.

However there is something i overlooked from option 1 ie. wsr01 and wsr02 are interconnected with a L3 routed link. So by adding the second link you do not create a L2 loop between sites. Apologies, should have noticed that before.

So the main reasons for not using L2 ie. STP blocking one of the links and possible broadcast storm are not applicable here.

Having said that option 1 & 2 both extensively use static routing. For example -

on the EX4200 switches for the OAM traffic you have a static route pointing to 10.41.237.164 which is the vlan interface for vlan 14 on wsr01. What happens if wsr01 goes down ?

You could add a second static route pointing to wsr02 ie. 10.41.237.165 as well. In fact with option 1 and 2 you would need to do this or you are creating single points of failure.

Personally i think option 3 is still the way to go altho if possible i would extend OSPF to the EX4200 switches and hence remove the need for static routing altogether between the wsr, mx and ex L3 devices. OSPF would then work out all the redundant paths between the sites which is what it is meant to do.

And removing additional unneeded equipment pretty much always makes things simpler. With option 3 (and 2) you can remove the L2 switches in site 2.

As for the client defending the plan. They make have additional requirements that they haven't made clear. I'm always loathe to criticise other peoples designs because often the design takes into account things that have not been explicitly made clear. It's certainly not an incoherent design but i would still prefer the true routed option.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco