Routing new RF ISP with Ethernet handoff

Unanswered Question

Equipment: 7206VXR - IOS 12.0(9)S - NPE300

1 FE port in base card. (FE-0/0)

Module 1 is a 4 x T1 Serial card.


Current ISP is connected via MultilinkPPP via 2 bonded T1 circuits. (S1/0,1)

Current IP space: 1.2.2.128/26



New ISP is RF-based P2P with new antenna installed on roof.

Cable from roof runs into small bridging box which gives us a FastEthernet handoff.

New IP space: 1.4.4.192/26



I want to setup the new ISP, run everything through the VXR and test the new WAN connection before we commit and renumber.


To that end, I've added 2 new 1-port FastEthernet cards into the 7206 with the intention of running the 2 separate WAN links with their own ingress/egress ports as described.


The box the new RF ISP gave us has what is in essence the router address for our subnet: 1.4.4.193 and I have plugged that into one of the new FE ports (FE-2/0). I need to do the following:


1. route traffic that is addressed to IPs on our new public block out through the second new FE interface (FE-3/0)

2. put into place QoS on traffic coming to/from a particular set of IPs on our new public allocation for a new video conferencing system.


There is no NAT occurring here anywhere, just straight routing.


I did try to create a bridge-group between the two new FE (2/0 & 3/0) interfaces along with a configured BVI with address 1.4.4.194.

It was my understanding from some Cisco docs that this would create a sort of virtual switch/bridge between those interfaces. This did not work as planned either because it was not the right way to go or I missed something in the config (bridge irb, BVI, bridge-group 10, etc...)


I've attached a general diagram of what I'm trying to do.

Any suggestions, pointers in the right direction would be much appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Richard Burts Mon, 07/19/2010 - 06:51

Brian


The diagram was helpful and I would like to clarify one thing - it looks like your current provider gave you the 1.2.2.128 address space for your internal use and that the address of the multilink interface is a different subnet. Is that the case?


If that is the case then the basic issue is that your old provider is using 2 subnets while the new provider is using only a single subnet. So one alternative would be to ask the new provider if they could provide a second subnet and your implementation would be quite straightforward. If the new provider will give only the single subnet then I believe that you have a couple of alternatives to consider:

- I have seen situations like this where the solution was to use the provider address subnet as a pool of addresses for Network Address Translation. Some of the translations might be static and some might be dynamic depending on your requirements.

- the other solution would be to try to bridge the new outside interface to an inside interface, which is what you were doing with the BVI. I would think that should have worked. Perhaps you can post some of the configuration detail so that we could see if there were some issue with it?


HTH


Rick

Richard,


Thanks for the reply.


As I said, there is no NAT'ing going on here. These are straight public IP address range allocations from the 2 different ISPs. The "WAN switch" is merely a regular layer 2 switch that we connect devices to that have been given 1 more of public IP addresses from the allocated range(s).


As for the BVI config:


----

bridge irb


bridge 10 protocol ieee
bridge 10 route ip


interface FastEthernet2/0
description InFromNewRFisp
no ip address
bridge-group 10


interface FastEthernet3/0
description InFromNewWANSubnet
no ip address
bridge-group 10


interface BVI10
ip address 1.4.4.194 255.255.255.192



and then I had tried to force routing for that subnet using a route-map:



ip access-list extended rfispipspace
permit ip 1.4.4.192 0.0.0.63 any



route-map rfisp-source-route-hack permit 10
match ip address prefix-list rfispipspace
set interface FastEthernet2/0


and had also tried:


route-map rfisp-source-route-hack permit 10
match ip address prefix-list rfispipspace
set interface BVI10



We were testing basic pings between the RF ISP bridge device (it has a remote console) and the 7206 and also out to the internet to other devices and we could not seem to get much to work as expected.


Obviously, when we drop the old ISP, the routing config will become "simple" again, and assuming most of my config was correct, what would devices on our "WAN" subnet use for gateway? 1.4.4.194 or 1.4.4.194?


Thanks

to clarify a question you asked: the MLPPP interface has an address in a subnet for the ISP: 1.3.3.54/30

Which is working fine for years now and will be dumped once we are happy with the new RF ISP.


Still, no NAT happening here at all. There are no nat inside/outside commands in this device period. These are all publicly routable IP addresses.

Richard Burts Mon, 07/19/2010 - 10:40

Brian


You have made it abundantly clear that there is no NAT in your current environment. And I completely understand that. I am not talking about NAT in your present environment but I am suggesting that you might need NAT in your future environment.


I am not sure that you understand the significance of a subtle change that is taking place as you switch providers. Your original provider supplied 2 subnets (one for your router interface and one for your users) and it easily supports the implementation where the connection to the provider is one interface and the interface to the users is a different interface. But with the new provider they are supplying you with a single subnet and this suggests an assumption that the users are on the same interface as the connection to the provider.


If the users are not on the same interface as the connection to the provider then as I see it you have several options:

- you can ask the provider for a second subnet.

- you can try the bridging/BVI option.

- you can do NAT. (and in my experience the NAT option is chosen more frequently than the bridging/BVI option).


HTH


Rick

Actions

This Discussion