[c-nsp] Converting ATM to VLAN

[Bruce Pinsky]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Clayton Zekelman wrote:
|
| I have a situation where I have ATM PVC's coming in (Bridged RFC 1483) and
| need to convert it to a VLAN dot1q trunk.  I'm doing this for a handful of
| paths, as the ATM enabled router is not the router I need the path to end
| up on.  If it were, I'd likely do ATM RBE.
|
| I do the following:
|
| interface ATM0/0/0.48 point-to-point
|   description MNS-191+B VLAN 48 IP Transit
|   bridge-group 48
|   pvc MNS-191+B 1/70
|    ubr 12500
|    encapsulation aal5snap
|   !
| !
| interface FastEthernet0/0/0.48
|   description MNS-191+B  IP Transit
|   encapsulation dot1Q 48
|   bridge-group 48
| !
| bridge 48 protocol ieee
| bridge 48 route ip
|
| For some reason, things don't work properly unless I add:
|
| interface BVI48
|   no ip address
|
| Can anyone shed any light on why I need to add the BVI?  It *appears* to do
| nothing:
|


If you wish to bridge between the ATM and the FE, why do you have "bridge
48 route ip"?  This would imply that you will be passing layer 3 traffic
between other routed interfaces and the "group of interfaces" represented
by the layer 3 virtual interface BVI48.

I suspect that without the "no ip address" and the presence of "bridge 48
route ip", there would be confusion as to the local subnet for the BVI and
hence when a packet arrives, it is unclear whether it needs to be bridged
onto another member interface of the bridge-group or it should be routed
onto another interface for another subnet or next-hop gateway.  Much like
having devices attached downstream to a physical FE interface and never
adding an IP address for the interface and then wondering why traffic was
not being passed at all.

Now frankly, I think it's a fluke that adding "no ip address" would correct
the problem, however, I think the proper solution here would be to have "no
bridge 48 route ip" which would disable routing for IP within that
bridge-group causing all packets to be forwarded only between member
interfaces of that bridge-group.  There are other possible solutions as
well depending on what other activities this router is expected to do, but
given this limited view, this would be my first suggestion.

- --
=========
bep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCOJVBE1XcgMgrtyYRAqfGAJkBvOG3W0o7ugpOtZ959nWj7s/51wCfTGBj
mTOBy6DWw4Xc0Zz8zGDlAgM=
=RScR
-----END PGP SIGNATURE-----