Hello all!
I ran into something strange today...
I have several circuits coming into a router that all go to the internet.
Each has its own IP block associated with it and they are not common. I was
terminating all these circuits on different routers and connecting them into
a Cat5500 separate ethernet connections. I recently changed this by
creating VRFs inside a single router (I was tired of wasting 4 routers when
one could do the job) and associating each VLAN subif (trunked to the switch
via an SDE FDDI trunk) with a WAN interface (DS/3 or T1) in a single VRF.
Doing this, I was able to terminate all the circuits into the same router,
and not have to do anything fancy with PBR to get the right networks to
route down the right WAN links. It made the router look like 4 separate
routers... It was pretty cool... Here is a sample:
interface Fddi3/0/0
no ip address
no keepalive
!
interface Fddi3/0/0.100
encapsulation sde 10
ip vrf forwarding fatpipe
ip address aaa.aaa.aaa.aaa 255.255.255.128
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1500
!
interface Fddi3/0/0.200
encapsulation sde 20
ip vrf forwarding fatpipe
ip address bbb.bbb.bbb.bbb 255.255.255.224
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1500
!
interface Fddi3/0/0.300
encapsulation sde 30
ip vrf forwarding talon
ip address ccc.ccc.ccc.ccc 255.255.255.240
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1500
!
interface Fddi3/0/0.400
encapsulation sde 40
ip vrf forwarding wash
ip address ddd.ddd.ddd.ddd 255.255.255.224
no ip redirects
no ip proxy-arp
ip mtu 1500
!
!
interface ATM3/1/0
no ip address
atm scrambling cell-payload
atm framing cbitplcp
no atm sonet auto-configuration
no atm sonet ilmi-keepalive
no atm sonet address-registration
no atm sonet ilmi-enable
no atm auto-configuration
no atm ilmi-keepalive
no atm address-registration
no atm ilmi-enable
!
interface ATM3/1/0.1 point-to-point
description CONNECTION TO RESTON-MS36170-DS3-12/3
bandwidth 25000
ip vrf forwarding fatpipe
ip address xxx.xxx.xxx.xxx 255.255.255.252
ip access-group 2010 in
no ip redirects
no ip unreachables
no ip proxy-arp
ip accounting output-packets
ip accounting access-violations
pvc 0/33
protocol ip xxx.xxx.xxx.xxx broadcast
encapsulation aal5snap
!
interface Serial2/0/0:0
description FRAME CONNECTION TO HAYWARD-CKT#xxxxxx CKT#xxxx 36170-P1-03-3
ip vrf forwarding hayward
ip address yyy.yyy.yyy.yyy 255.255.255.252
ip access-group 2012 in
no ip redirects
no ip proxy-arp
encapsulation frame-relay IETF
no fair-queue
frame-relay map ip yyy.yyy.yyy.yyy 50 broadcast IETF
frame-relay lmi-type ansi
!
interface Serial2/0/1:0
description FRAME CONNECTION TO DC-CKT#xxxxxxx CKT#xxxxxxx 36170-P1-03-2
ip vrf forwarding wash
ip address zzz.zzz.zzz.zzz 255.255.255.252
ip access-group 2011 in
no ip redirects
no ip unreachables
no ip proxy-arp
encapsulation frame-relay IETF
frame-relay map ip zzz.zzz.zzz.zzz 60 broadcast
frame-relay lmi-type ansi
!
interface Serial2/1/0:0
description FRAME CONNECTION TO ATL-CKT#xxxxxxxx CKT#xxxxxxx 36170-P1-04-4
ip vrf forwarding talon
ip address ggg.ggg.ggg.ggg 255.255.255.252
ip access-group 2013 in
no ip redirects
no ip unreachables
no ip proxy-arp
encapsulation frame-relay IETF
frame-relay map ip ggg.ggg.ggg.ggg 60 broadcast IETF
frame-relay lmi-type ansi
!
There are static defaults for each VRF as well... all works great using this
config.
All this was working fine until I switched out the FDDI for a fast-ethernet
dot1q trunk today. I attached this connection to a Foundry Fastiron
workgroup layer-2 switch and all heck broke loose. Either the switch or the
router is now unable to forward any IP packet over about 128 bytes. I can't
tell where the problem is, but there are no dropped packets or errors being
counted on either device. I switched out the Foundry Fastiron and put in an
Extreme Summit 48. Same problem... anything over 128 bytes (or so) gets
dropped (I enabled jumbo frames but I'm not using MPLS here). Here is the
section I replaced the FDDI with:
interface FastEthernet3/0/0
no ip address
full-duplex
no cdp enable
!
interface FastEthernet3/0/0.100
encapsulation dot1Q 100
ip vrf forwarding fatpipe
ip address aaa.aaa.aaa.aaa 255.255.255.128
no ip redirects
no ip unreachables
no ip proxy-arp
no cdp enable
!
interface FastEthernet3/0/0.200
encapsulation dot1Q 200
ip vrf forwarding fatpipe
ip address bbb.bbb.bbb.bbb 255.255.255.224
no ip redirects
no ip unreachables
no ip proxy-arp
no cdp enable
!
interface FastEthernet3/0/0.300
encapsulation dot1Q 300
ip vrf forwarding talon
ip address ccc.ccc.ccc.ccc 255.255.255.240
no ip redirects
no ip unreachables
no ip proxy-arp
no cdp enable
!
interface FastEthernet3/0/0.400
encapsulation dot1Q 400
ip vrf forwarding wash
ip address ddd.ddd.ddd.ddd 255.255.255.224
no ip redirects
no ip proxy-arp
no cdp enable
!
Now, when I take one of the sub-interfaces and its corresponding WAN
interface out of the VRF, everything goes back to normal. This works on
both the Foundry and the Extreme. I am going to try a Catalyst next but I
thought I would ask around and see if anyone knew why I would get this kind
of trouble when I put the interface into a VRF... Is there something
special that a Catalyst does that other switches don't do by default or at
all? If these ethernet subinterfaces were attaching to CE CPE via an
ethernet switch, would this just flat not work? I'm not exporting or
importing or even communicating any info about these VRFs to anyone else...
it just doesn't work.
Any ideas would be helpful...
Scott
-- Scott A. Keoseyan (sak@broadwing.com) Principal Engineer - Lab Services B R O A D W I N G Inc.* 1881 Campus Commons, Suite 210 Reston, Virginia 20191 (703)391-1831 - (FAX)391-1810 http://www.broadwing.com/ccielab http://www.labyrinth.org/homepages/scott/home.html* Company name mentioned for identification purposes only. These ramblings are my own opinions +++The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this document.+++
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:30 EDT