[c-nsp] VRF-Lite Question

Phil Mayers p.mayers at imperial.ac.uk
Thu Feb 15 09:07:36 EST 2007


Ray Burkholder wrote:
>>
>> Lots of per-VRF L3 point-to-points, routing processes and routing 
>> adjacencies is the only working method on non-MPLS capable routers.
>>
>> It's tedious, but then the 3550/3750s are cheap.
>>
> Just to refine the scenario.  You have four buildings.  Cisco standard
> practice recommends layer 3 separation between buildings.  There are four

Yes, and this is why the addition of "distributed layer3" to the cisco 
campus network gravy train was not such a good idea - the smaller and 
thus cheaper routers have weaker capabilities in layer3.

If you can afford 6500s and sup32s in each building then all fine and 
well, but you've got more money than I've got.

> vrf's in each building, with traffic on like vrf's needing to go building to
> building.  And for sake of argument, a mesh of 1 pair fibres between
> buildings.  The switches on either end of each fibre link is a
> 3550/3560/3750.
> 
> The way I've handled this in the past is a routed l3 port on each end of the
> fibre on the switch, and drop that into the global routing table.  Then
> I've done GRE tunnels across that link, with source and destination in the
> global routing table and the tunnel itself in the appropriate vrf.  Four
> vrf's, four tunnels per link.
> 
> Other list members have indicated that GRE tunnels are not supported nor
> recommended.  
> 
> So.... What is the solution for interbuilding links?  Will the 35xx series
> support mpls labelling for one hop links?  Is that a possible mechanism?

No. The 3550/3750s support 802.1q tags and that's it.

One can hypothesise about some kind of auto-provisioned SVIs for 
extending the MPLS cloud, but no such technology exists to my knowledge. 
You have to do it manually.

> Any other suggestions?

To repeat myself: lots of per-VRF L3 point-to-point SVIs and vlan 
tagging, lots of routing adjacencies. That's the only way you'll get 
this done on 3550/3750s. They're limited platforms.

We have a lot as outlying site routers, and I've done extensive 
investigation of how we could least-effort link them into our shiny 6500 
network. The answer is, a lot of typing.

Example, based closely on what we do ($x==1 for buildingA, 2 for buildingB):

ip vrf switchman
ip vrf users
ip vrf other
vlan 4001-4004

int vl4001
   ! not in a vrf
   ip address 10.0.1.$x 255.255.255.252
int vl4002
   ip vrf switchman
   ip address 10.1.1.$x 255.255.255.252
int vl4003
   ip vrf users
   ip address 10.2.1.$x 255.255.255.252
int vl4004
   ip vrf other
   ip address 10.3.1.$x 255.255.255.252

int g0/0
  description faces other building
  switchport
  switchport trunk encap dot1q
  switchport mode trunk
  switchport trunk native vlan 4001
  switchport trunk allowed vlan 4001-4004

router ospf 1
  network 10.0.1.0 0.0.0.3 area 0
  redis connected subnets

router ospf 2 vrf switchman
  network 10.1.1.0 0.0.0.3 area 0
  redis connected subnets

router ospf 3 vrf users
  network 10.2.1.0 0.0.0.3 area 0
  redis connected subnets

router ospf 4 vrf other
  network 10.3.1.0 0.0.0.3 area 0
  redis connected subnets


More information about the cisco-nsp mailing list