On Wed, Dec 18, 2019 at 08:28:18PM -0500, Howard Leadmon wrote: > > ??So enter the ASR1000 and I thought great, this is a simple change as I > should just be able to copy most of my 7600 configs across into the ASR > and life will be good.???? The I went to setup a trunked port to bring the > existing equipment into the new ASR.???? Surprise, unlike the old 7600 > there is no turning a port in the ASR into a switchport, or not that I > can find, so it looks very much like it's an L3 device for the most > part.???? Well that sure blows up all the vlan interfaces/trunks that were > in the 7600 that will not transfer into the ASR.
Starting with the "real" (real as in... SR/Router BU) product side of 7600 (that will be ES and ES+ cards; Trident/EZchip NP I believe? mounted on top of typical 6500 DFC architecture) and onward, you now have to use Ethernet service instances to define layer-2 services on a port. So ASR1K follows the same configuration syntax that was introduced with 7600 ES cards, if I recall correctly. As an example, let say you have a Te0/0/1 going to an L2 service provider as an NNI interface. Vlan 10 is layer-3 interface for IP routed connection terminating locally on the router for a customer DIA connection; and Vlan 11 is a layer-2 vlan you're pointing to the customer for a Layer-2 extension that goes out via another port (lets call it GigabitEthernet0/0/3). You would configure the services like this: ! interface Te0/0/1 description NNI to SP mtu 9216 service instance 11 ethernet description (L2) vlan11 for 1Gbps to Customer B layer-2 extension encapsulation dot1q 11 rewrite ingress tag pop 1 symmetric service-policy output shape-1g bridge-domain 11 ! ! interface Te0/0/1.10 description (L3) for 100Mbps DIA to Customer A encapsulation dot1q 10 ip address x.x.x.x 255.255.255.252 ip mtu 1500 service-policy output shape-100m ! interface Gi0/0/3 description (L2) vlan11 UNI for Customer B layer-2 extension mtu 9216 service instance 1 ethernet encapsulation untagged bridge-domain 11 ! !! optional: if you are providing pseudo-wire style service and do not want !! to learn MACs on the layer-2 extension customer (bridge-domain 11): bridge-domain 11 no mac learning ! Note that on newer IOS XE platforms, instead of using bridge-domain w/ MAC learning disabled, you can use proper L2 vpn xconnect contexts, like this, which will naturally stitch two interfaces together as a cross connect: ! l2vpn xconnect context bd11_customer_B interwork vlan member Te0/0/1 service-instance 11 member Gi0/0/3 service-instance 1 ! !! and you'd no longer need to define 'bridge-domain' commands For more information, refer to https://www.cisco.com/c/en/us/td/docs/routers/asr1000/configuration/guide/chassis/ce-xe-3s-asr1000-book/ce-trunk-efp.html https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/cether/configuration/xe-3s/ce-xe-3s-book/ce-ether-vc-infra-xe.html or Google search "ASR 1000 EFP" Hope this helps, James _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
