Some Tricky Topology

gorebrush

So here is one that will test all of your Routers-On-Stick merchants.

Let's pretend I have 3 sites.

Site A
Site B
Site C

Site A and Site C belong to the same company
Site B belongs to a parent company

Now Site A and Site C and linked through Site B.

So, you have Site A-B-C

In fact, Site B is a massive cloud of Routers (could be say, 3-4)

So, the default gateway out of Site A, let's say is: -

10.0.1.1 /24

Site C is

172.16.3.1 /24

Site B is where the magic happens, and let's say for the purpose of the example, I don't know what the Router addresses are.

There are two problems here: -

Part 1

What I want to be able to do is state that no matter what the configuration of Site B is - I need all clients in Site A to know that to reach a server, say, 172.16.3.10 - they look for 172.16.3.1 and then obviously it can use it's default gateway information to traverse through Site B to get to C.

Additionally, at Site C, I can implement a static route that does the same thing - for 10.0.1.1 it can use a static route that says - for the a server 10.0.1.10, it'll look for 10.0.1.1


However, I am going to add a lot of complexity at this point.

Site C has the following network devices attached to our network from Site B

Router 172.16.3.1
Switch 172.16.3.2

Now, up until the above devices have been installed, Site C has it's own, complete infrastructure, using a 192.168.0.0 network.

So Part 2

What I need to be able to do, is insert a Router-On-A-Stick that is part of both 172.16.3.0 networks, and 192.168.0.0

Is this possible?

Router 172.16.3.1 - I cannot touch the configuration of this router. It does not belong to any company in Site A B C - this router is managed by a 3rd party.

Switch 172.16.3.2 - This is a HP ProCurve switch, that I can remotely manage

Now, for the Router I was going to add: -

RoaS (Router on a Stick)

172.16.3.4
192.168.0.254

Therefore from Site-A. I can add a route which says - to get to 192.168.0.0 network, I look for 172.16.3.4

Then, on the 172.16.3.2 Switch, we configure two VLANS. Now, reading that back, I think this is where I might have my problem.

From my understanding of VLAN's - you can only configure one NATIVE VLAN. A native VLAN dictating what VLAN traffic belongs to, if it arrives untagged.

Given that I cannot alter the configuration of the 172.16.3.1 - I would assume that this must be a native VLAN.

However, let us now say that the equipment on Site-C cannot be added to a VLAN either.

Am I screwed? I.E. I need to be able to run two VLAN's on that site, and I won't be able to?

gorebrush

Looking back at what I have written - I don't think I can pull this off.

If someone can shed light on this, I would be most appreciative.

gorebrush

No replies, huh?

nel

SOunds like your using a hub and spoke topology. So sites A and C can have a default route point to site A and they will be able to reach each over through that depending on routing at site a - this can be a static route or one advertised through a routing protocol.

I would say you really need to find out the big picture - at the moment you are making assumptions about your network about configurations you dont even know about. Get the full picture before you make any changes - especially big changes! otherwise you can screw things up big time. It also makes it a pain when certain devices are externally managed so if you dont have a config for reference then speak to the company about the device or liase with the main network guy(s) at your parent company.

For site C - what are you actually trying to do? are you going to migrate them from the 192.168 range over to the class b range or do you simply want to integrate your 172 range router / switch into there existing class c infrastructure?

How many users are at site C and what kind of devices do you have to work with? i.e. L3 switches etc?

If its a small number of users you can use roas but if its a decent amount of folk then L3 switching maybe best. Either way you could just create a vlan for your 172 range and your clients will go through the L3 switch or roas to reach it. Which method you use depends on the no. of users.

gorebrush

Tell me about it - There are still unknowns which I hope to clear out today.

Basically, Site C is new to our infrastructure, and they use a 192.x.x.x network address.

Site B, the parent company have said that they will basically need to change all their IP addresses to 172.31.x.x to match their infrastructure (hence the 3rd party managed router with 172.31.x.x)

The Router on a Stick that I am adding to each site will act as some translation for us, so we can see the 192.168.x.x network by pointing at 172.31.x.x

Long term we will be changing all the IP addressing instead - but this takes planning and effort and ballache.

There are 25 users in one site, and about 3 in the other - so it'll probably be easier just to re-address the 2nd site.

Think I need more info first.

nel

To be honest if there's only 25 users at site c then i would look to migrate them across now whilst your doing it. It wont be much hassle at all with those small numbers. The infrastructure shouldnt be complex at a small office like that. You'll just have to change a few IP's and the default route to reach your central site.

Make sure you backup everything your going to reconfigure first - just incase

gorebrush

Can do.

But it's not as easy that.

Site C is geographically like 350 miles away (Not far from you in fact)

And there is only 1 IT person on site - he's the IT Manager for the company, and basically looks after everything.. as well as an ERP implementation.

The router on a stick method - while being a pain in the arse to configure - it's also free as I've been donated 2 x 1721 Cisco routers for the job.

So hopefully it can be done this way quickly (i.e. bang the routers in, they at least can see all networks)

nel

Well you'll have to get on the train at some point haha that west coast train from SW england to scotland is a pain in the arse...takes forever!

gorebrush

Bah, I'd drive

Anyway, the guy who is based at those sites is actually here today, had a chat with him: -

There is also a Site D (Imagine C, but carbon copy)

Site C has managed switches (that apparently are capable of VLANs (Hurray))
Site D has 3 computers - and we've been given some HP switches to play with, which I *believe* will do VLAN's...

If not, then we'll re-address the 2nd site in one go, bollocks to it.

nel

Ha!

Aw well good luck with it man.

gorebrush

Well at least at this point it seems feasible.

I have been busy today, but hopefully I should get the topology nailed down onto paper today and I should be rocking.

auos

Hi,
Why you did not support your explanation by figure.

BR,
Auos.

gorebrush

Sorry do you mean produce a diagram?

I will get one up later

gorebrush

Well thought I would post an update on this.

I've been busy the last few weeks, what with my helpdesk being on holiday and now sick.

Anyway, I've got round the entire problem of having to involve ANY internet companies having to do any configuration and any messing about.

BEHOLD



I'm using NAT! Static NAT Translations on the two Routers on a Stick - fixes the problem.

This GNS3 diagram (I think i've finally got it all working ok now and I'm officially in love with GNS3) is the complete working model of the network.

Enjoy!

I should probably point out: -

The two "Some End Devices"

Are actually

R4 = 172.16.0.111
and
R7 = 172.16.1.111

R3 and R8 are the two Routers on a Stick, performing static NAT also.

Respectively.

gorebrush

R5#ping 172.16.0.111

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.111, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/50/104 ms
R5#trace 172.16.0.111

Type escape sequence to abort.
Tracing the route to 172.16.0.111

1 10.0.15.1 16 msec 44 msec 40 msec
2 10.0.12.2 8 msec 16 msec 8 msec
3 172.16.0.254 40 msec * 36 msec


and

R5#ping 172.16.1.111

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.111, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/40/72 ms
R5#trace 172.16.1.111

Type escape sequence to abort.
Tracing the route to 172.16.1.111

1 10.0.15.1 8 msec 4 msec 16 msec
2 10.0.16.6 36 msec 68 msec 40 msec
3 172.16.1.254 8 msec * 16 msec



sweeeeeeeeeeet

ilcram19-2

are you using any routing protocols ? or just ip routes?

gorebrush

Just routes for now.

I don't know what the ISP use between all the "unknown cloud" sites.

However, for example, from Site A - my routers will know how to get to both 172.16.0.x and 172.16.1.x networks.

If I were to ping a computer in either subnet, it would be broadcast in either segment by the router on the entry point to each site (I cannot change any config on any router up until this point)

NAT says "if I receive a packet for 172.16.1.111 then I must send it to 192.168.0.1 instead"

Thus, the system works.

Also works the other way too, (i.e. I can ping from the 192.168.0.1 device, out to 10.0.15.5, for example)

Overall, winner.

ilcram19-2

im thinking that if you want to get communication between those site you'll have to update the routing tables of all the routers involve in here so they will know how to get to each other also to my understanding routing on a stick mean that you will have a router hooked up to a one switch port doing what is call inter-vlan routing, on this case i would recomend that if you want connectivity in all site use a routing protocol en configure it on the routers or add ip routes for each location on each router they all must know how to get to each other it is not that complicated

gorebrush

Yes, they do know all the routes, but they cannot know about 192.168.x.x networks, because those two "outer" routers cannot be configured by ourselves. They are handled by a 3rd party.

The point of the configuration is so we can "get around" having to worry about getting in touch with the 3rd party.

Though over the weekend I fancy making a MEGA network with this same objective

ilcram19-2

ok i see u can use route maps or acls to denied or redirect traffic comming or going to the 3rd party, make sure you apply those close to the source

gorebrush

Very true, would stop any of the 3rd party from seeing the new network.

However, the 3rd party is our parent company and they own both of our companies, so it might be a futile exercise.

I'd certainly put it in though - demonstrates that we can perform network security