Transparent bridging on router.

[danielr82]

I have a switch stack (and devices attached to that stack) all using VLAN12.
A device provided by an ISP that I cannot see or configure, (the presentation is by ethernet and the device is offsite) the instructions from the ISP (Verizon) is configure your devices using any one of these 8 static IP addresses on a /24 network and .1 is the gateway.

If I plug the ISP presentation directly into a laptop it works, I can get out to the internet.
if the internet line is plugged into an unmanaged switch switch, then multiple devices can be configured without any issues.

If the ISP device is attached to a managed switch with a VLAN configured (which I was to do to segragate the network) then it appears that all traffic is dropped. (as in the ISP equipment appears to just reject any tagged packets.)

What I am trying to do is setup a router using transparent bridging such that the switch stack and it's tagged packets are able to be taken by the router, have the tags removed and forwarded to the ISP, where the packet should then not be dropped.

Everything that's on VLAN 12 at the switch end is configured and contactable from everything else, (there is a firewall with an address configured on this network, that's able to contact the switch, the switch is able to contact workstations etc.

the router is connectted to the ISP and the router is accessible externally, but it seems that the router is dropping traffic on that vlan 12 now.

the devices are connectted and can "see" each other, just the layer 3 connectivity between the office side of the bridge on the router doesn't seem to be working.

My configurations are below. - Can anyone see what I have gotten wrong?

Switch configuration:

vlan 12
name VLAN12-ISP2

interface GigabitEthernet1/0/3
switchport access vlan 12
switchport mode access

interface Vlan12
ip address A.B.C.3 255.255.255.0

On the switch "show IP route"
gives:

S* 0.0.0.0/0 [1/0] via X.Y.Z.174 (ISP 1)
C X.Y.Z.168/29 is directly connected, Vlan11
L X.Y.Z.170/32 is directly connected, Vlan11
C A.B.C.0/24 is directly connected, Vlan12
L A.B.C.3/32 is directly connected, Vlan12

sh cdp neig:
Device ID Local Intrfce Holdtme Capability Platform Port ID
RTR-01 Gig 1/0/3 140 T B S I CISCO2901 Gig 0/1
...

on the router:
Configuration:

hostname RTR-01
no ip routing
bridge irb

interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
bridge-group 1

interface GigabitEthernet0/1
no ip address
no ip route-cache
duplex auto
speed auto

interface GigabitEthernet0/1.12
description office side of router
encapsulation dot1Q 12
bridge-group 1

interface BVI1
ip address A.B.C.2 255.255.255.0

control-plane
!
bridge 1 protocol ieee
bridge 1 route ip

sh ip route
Default gateway is not set

Host Gateway Last Use Total Uses Interface
ICMP redirect cache is empty

RTR-01#sh cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay

Device ID Local Intrfce Holdtme Capability Platform Port ID
STACK01 Gig 0/1 175 R S I WS-C2960X Gig 1/0/3

show bridge

Total of 300 station blocks, 299 free
Codes: P - permanent, S - self

Bridge Group 1:

Address Action Interface Age RX count TX count
0090.1aa2.5ad6 forward Gi0/0 0 95628 25464
RTR-01#

From the router I can get ping response from the ISP (a.b.c.1) and from the router (a.b.c.2) but not from the switch (a.b.c.3) or from another device (asa) (a.b.c.4)

from the switch I can get a ping response from the ASA (a.b.c.4) and from the switch SVI (a.b.c.3) but the router (a.b.c.2) and the ISP gateway (a.b.c.1) are unresponsive.

[Philip D'Ath]

I can not clearly understand what you are saying.  It confuses me.

Why would you not just plug the ISP circuit directly into your firewall?

[danielr82]

There are two firewalls in active/standby configuration, 

attaching the circuit directly to the firewall would mean a loss of connectivity after firewall failover, (or asking end users half way around the works to re-patch connections)

[pwwiddicombe]

Is your internal network also using the 67.67.1.x addressing scheme?  We're having a difficult time here getting a real picture of what constraints/ design is in place.  If you have internal addressing in another network, then IF the addresses are "Internet routable" the ISP could advertise this network; although preferably you NAT the internal network to the address of the firewall.  You only need a single IP address if sessions originate from your internal network; although if you expect sessions to be originated externally coming INTO your network, then those sessions would be easier with a 1:1 NAT scheme.

For 2 firewalls, one cheap and surprisingly effective method is to have the ISP  into a minihub (non-manageable switch, so it can't be hacked), and then the 2 firewalls' outside addresses into that.  On the INSIDE of the firewalls, you can go to another hub in the same manner with a single connection to your internal network (or router), or if the addressing permits then both firewall internal sides to 2 ports on the internal switch.   Since there's really no processing in them anyway, the failure rate on these will be minimal.

[Richard Burts]

I find the explanation of the environment and of the requirements to be very confusing. But I have a couple of comments that I hope may be helpful:

- if you really want the router to be transparent then you do not need IRB. All you need for the router to be transparent and to bridge is the no ip routing (which you have) and the bridge groups on the connected interfaces (which you have).

- but I believe that bridging is a flawed approach. You have vlan 12 which is in some subnet. And you have addresses from the ISP that are in a different subnet. You can not just bridge to connect these subnets. To communicate between subnets you will need some layer 3 routing device.

- the original poster seems to be telling us that they attempted to connect vlan 12 directly to the provider but it did not communicate. He seems to think that the failure to communicate was due to tagged frames. But I believe that it was not tagged frames but was the difference in subnets (which I mention above).

- the solution that would make sense to me (if my understanding of the environment is anywhere close to correct) would be to connect the router interface Gig0/0 to the provider using one of the suggested IP addresses. Connect the router to the switch using interface Gig0/1.12 and give the router an IP in vlan 12. Then configure routing to connect vlan 12 to the provider using the layer 3 routing of the router.

HTH

Rick

[danielr82]

but I believe that bridging is a flawed approach. You have vlan 12 which is in some subnet. And you have addresses from the ISP that are in a different subnet. 

They are not in different subnets. I never mentioned any other subnet, every address in VLAN 12 has always been listed as a.b.c.1/2/3/4 (or more recently 67.67.1.x)

VLAN11 was mentioned to give information that there was a second ISP at the site (comcast) in addition to this Verizon line, in case anyone had experienced similar issues and it turned out that traffic that is connected to an interface and that should be routed via that interface was actually being routed externally via the other ISP.

I'm not sure where the idea came from that I just have an external address and want to NAT that to an internal address. 

that is NOT what I am trying to do.

I have a range of addresses all in the same subnet.

with some ISP gear that drops any tagged packet.

and a necessity to use tagged vlans on the switch as it carries traffic from many different networks.

what I want to do is bridge two networks together.

one network (my side) uses the subnet 67.67.1.0/24 and packets are tagged in VLAN12

the network (ISP) uses the same subnet 67.67.1.0/24 but packets are not tagged.

the router should sit in the middle and bridge the networks.

[Philip D'Ath]

You still don't need a router doing bridging.

On your switch create a new VLAN and put three ports into it, as access ports.  This VLAN is only a layer 2 VLAN and should have no IP addressing on it (on the switch).  Plug the ISP into one, and the outside of the two firewalls into the other two.

[Richard Burts]

One of the aspects of this which puzzles me is that the switch clearly has two vlans configured and active. The discussion has been about connecting vlan 12 so that it has access to these new addresses. But what about vlan 11? Should it also access these new addresses or is vlan 11 to be separated from these addresses?

If vlan 11 is to be separated then my suggestion of using the router to connect vlan 12 to the ISp would be effective. But if both vlans are to access the new addresses then Philip's suggestion of a new vlan on the switch would be effective. And Phillip's suggestion has the added advantage that it would allow the firewall(s) to use the new addresses for address translation.

Clarification from the original poster would be appreciated.

HTH

Rick

[danielr82]

the trouble is I essentially have that.

I've got VLAN12 configured, there are only three ports. it doesn't work. the ISP equipment drops the traffic as soon as any VLAN tag is applied. I've tried both with an without an SVI on the switch. - though fundamentally that should not make a difference, the presence of L3 capabilities on the switch does not remove L2 functions.

unless your suggestion is to use vlan 1 so that packets are native and not tagged, and then configure the native interfaces on the firewall and not use tagged sub interfaces?

[Richard Burts]

Perhaps we can get some clarification about what kind of switch we are talking about here. I started to make a statement about switch behavior and then realize that without knowing what kind of switch we are dealing with that my comment might or might not be valid. So can you clarify for us what kind of switch this is.

It is interesting, if I am understanding your explanation correctly, that vlan 12 is already using the IP addressing that the provider has given you. It would be helpful to know whether vlan 12 is supposed to communicate with vlan 11 or if the two vlans should remain separate. And knowing this would have a direct bearing on find an appropriate solution for your requirements. It would also be important to know whether you need traffic from the devices in vlan 12 to go through the firewall to get to the provider or whether they can communicate directly with the provider.

You continue to suggest that the issue is that the provider drops any frame which it receives that is tagged. There is a simple solution for that (assuming that we are dealing with a typical layer 2 Ethernet switch). Configure an access port on the switch in vlan 12 and connect the provider device into that access port. As an access port the switch will not apply tags to the frames that it sends out that interface. So no tagged input at the provider device.

HTH

Rick 

[pwwiddicombe]

What may be happening is that your "internal addresses" are being sent to the outside world; and when the external hosts try to return a response, the internal addresses aren't known on the internet, and the return pings go nowhere.

Typically this is handled via NAT, and frequently done on the firewall.  So, internally your 10.10.1.1 address is nat'd to another address and appears on the internet as, say, 67.67.1.5, which the "internet hosts" know about (this would be advertised from the ISP).  The firewall or NAT device then gets the return packets successfully, and knows to forward the packet internally back to 10.10.1.1.

[danielr82]

admittedly this would be ideal, if the ISP had said connect your router to get an address by DHCP on a random address from their pool and then the block of static addresses were simply routed to that address and we could just NAT those addresses, but that is not the circumstances that I have to work with.

The ISP has given only the block of addresses so NAT with a small stub network is not possible.

My internal addresses (a.b.c.xxx are not RFC 1918 addresses they are a block of external addresses.

My understanding of bridging is that any device on either side of the bridge will send an arp request and the bridge should relay that arp request to the other side of the bridge.

The router configured as a transparent bridge should be entirely transparent. (e.g my firewall 67.67.1.4 exists on the same network as the ISPs router 67.67.1.1 and my router 67.67.1.2, and they should be able to communicate using the IP protocol as if the ISP connection were connected directly to the switch.

[danielr82]

When I said a.b.c.1 a.b.c.2 the a.b.c part is always the same, it is (as previously described) a non RFC1918 /24 subnet. it is the same on both sides of the router (that is setup as a bridge), indeed if it was not then I'd want to route between two different subnets, not bridge two subnets that are the same!

I tried to simplify the addresses. using a.b.c but 67.67.1 is just as good.

There is an ISP connection 67.67.1.1/24 - I assume it's a router for me it's just a cable that enters the building and has an Ethernet socket.

At first I connected this directly to the switch stack (2960's) in a port configured for access vlan 12. this did not work, the ISP device appears to drop all traffic that is tagged, I cannot confirm this as I do not work for the ISP, I don't have access to their equipment.

Instead I now have the presentation plugged into a router (2901) to port gi0/0,
port gi0/1 of that router has a subinterface configured. 0/1.12

both those interface (gi0/0 and gi0/1.12) are bridged, as bridge group 1, BVI 1 has address 67.67.1.2

port gi0/1 of the router physically conencts to an access port on the switch stack configured for vlan12

on my network I currently have a switch stack with an svi on VLan12 that has an IP address for testing. this is 67.67.1.3 (eventually I will remove this leaving only the management VLAN with an SVI) - the management VLAN is not important here and is not listed in the configuration

and then I have two firewalls, configured as active standby. each has an address on that external 67.67.1.4 and 67.67.1.5
these are connected to the switch stack, using a trunk port. each firewall has a set of interfaces that are grouped to form a port channel, that port channel has sub interfaces for VLAN11 (a connection to comcast signified as x.y.z.2 in the addresses I gave above - this is why VLAN 11 and it's addresses exist in the routing posted) and vlan12 is included in the trunk (and this is in the a.b.c range, or 67.67.1.4) connectted to the verizon equipment.

I understannd that if I was just given a single IP address and wanted to translate to internal addresses that I could just configure NAT, or if I was given a range of addresses 67.67.1.1/29 and told that my next hop was 32.32.1.1 that I could just configure routing between different subnets. I understand that I don't need a block of addresses to get external connectivity, but there will be some externally available services hosted on this site, and those will need an individual address in the external range allocated, (I have 8 external (and usable) addresses.)

What i have is a network as such.
67.67.1.1 is the ISPs gateway.

I am told that I am allowed to use 67.67.1.192 - 199 and 67.67.1.1 is the gateway on the network.

fundamentally I have a /29 network available in terms of address space, but instead of properly giving subnetted networks Verizon have decided that allocating a /24 (e.g saying use mask 255.255.255.0) and telling people that they may use certain addresses in the range is the way to go.

No internal addresses are mentioned at all. I do not want to NAT to an internal range, I don't want to route to an internal range.

What I want to do is bridge to identically numbered subnets that exist on different equipment together.

one network (the ISP network) seems to not understand tagged traffic and drops it.
the other network is the equipment that I'm configuring, I'm configuring it for vlan12.

so the situation is... in its most simple form.

I have two VLans and one address scheme.

ISP router uses address 67.67.1.1

my switch uses 67.67.1.3 (tagged to VLAN 12)

I have put a router in the middle configured exactly as configuration examples on Ciscos website suggests that you should do to setup a bridge (as above), with the bridge virtual adapter given the address 67.67.1.2 and it does not seem to bridge.

[Richard Burts]

I have thought some more about your attempt to use the router to do bridging and have these comments about it:

- I continue to believe that you do not need IRB configured on the router. IRB is appropriate when you want to bridge IP on some interfaces and route IP on other interfaces. As I understand your environment I do not see anything need to route IP on the router. So I suggest that you remove IRB from the configuration.

- with no ip routing, which you have configured, putting bridge groups on the interfaces will get the interfaces to bridge IP traffic.

- the major flaw in your attempt to use the router is that you connected the router to a trunk port (or at least the subinterface configuration would only be valid if it were connected to a trunk port). But when connected to a trunk port the frames for vlan 12 will have tags. And the bridging on the router should pass the tagged frame along without removing the tag, which I believe is why you wanted to use the router. To get frames in vlan 12 to the router without tags the router needs to be connected to an access port in vlan 12 and the router needs to bridge on its physical interface and not on a subinterface.

HTH

Rick

[danielr82]

The major flaw in your attempt to use the router is that you connected the router to a trunk port (or at least the subinterface configuration would only be valid if it were connected to a trunk port). But when connected to a trunk port the frames for vlan 12 will have tags. And the bridging on the router should pass the tagged frame along without removing the tag, which I believe is why you wanted to use the router. To get frames in vlan 12 to the router without tags the router needs to be connected to an access port in vlan 12 and the router needs to bridge on its physical interface and not on a subinterface.

I've changed the switch port to a trunk port and that has an interesting affect.

the router is now "visble" from the internal network.

i.e from my ASA 67.67.1.4 I can sucessfully ping 67.67.1.3 (switch) 67.67.1.2 - (Router) and 67.67.1.1 the ISP gateway.

BUT, my router is no longer accessible externally. (e.g. 67.67.1.2 was accessible externally it did respond to ping from the outside, now it does neither!)

weirder still I added a route on the router (ip route 0.0.0.0 0.0.0.0 67.67.1.1) and added the statement "bridge 1 bridge ip"

and the router can contact everything on both on my network (up to the firewall no natting exists yet!) AND the internet. (though hit still does not respond to anything originating online)

on my switch I've added a route (ip route 8.8.8.8 255.255.255.255 67.67.1.1)

now pings to 8.8.8.8 are not working from that device.

(e.g. ICMP traffic generated from the switch gets replies from the firewalls, gets replies from my router, gets replies from the ISP router 67.67.1.1, but after that no replies.)

if I try to remove the bridge irb configuration it wants to remove the BVI interface. 

(if not bridge IRB then what should be used to adjoin the two networks)

on removing the VLAN tags.

the router SHOULD remove the VLan tags?

if not then how would examples of joining the same IP subnet in two differently numbered VLANS work? (e.g https://paulsuela.wordpress.com/2010/11/28/cisco-bridge-group-transparent-bridging-between-2-different-vlans-2/)

i.e in those examples the vlan 2 tag is removed when the packet comes from the trunked interface. and the vlan 30 tag is added on the way out the other side of the bridge?

router should pass the tagged frame along without removing the tag, which I believe is why you wanted to use the router. To get frames in vlan 12 to the router without tags the router needs to be connected to an access port in vlan 12

yes, that's exactly why I want to use the router, so that traffic that reaches the ISP is accepted by the equipment and not dropped.

the first thing I did was connect the ISP equipment directly to a port on the switch configured as an access port, and all it seemed to do was drop traffic. 

(e.g vlan 12 was configured with SVI 67.67.1.3

port was

switchport mode access

switchport vlan 12)

To all intent and purpose that should have worked but instead the ISP equipment 67.67.1.1 would ignore all packets from the switch device. (no ICMP responses were recieved, no traffic could be routed through the ISP device)

(what is annoying is that nothing is working as it "should")

I "should" be able to just plug the ISP presentation straight into the switch.

I "should" be able to bridge two networks that use the same address scheme but different VLANs (or some and no VLANs) 

but neither of these seemingly simple things are working.