[RE: [nsp] gre tunnel using loopback for source]
Streiner, Justin
streiner at stargate.net
Tue Jun 3 14:22:53 EDT 2003
On Tue, Jun 03, 2003 at 03:31:10AM -0400, Streiner, Justin wrote:
> On Mon, 2 Jun 2003, Pete Templin wrote:
>
> > OSPF provides the most specific reachability, and the default route
> > points the same way as well.
> >
> > I'm statically policy routing into the tunnels from a FastE
> > subinterface, and following "normal" destination-based routing from the
> > tunnel to the subinterface at the far end.
>
> I originally tried this, but ran into scalability and administrative problems.
> You may want to check out VRFs as another way to do what you're doing here.
> Cisco's VRF documentation is a bit misleading. Since it's always
> mentioned in the context of implementing an MPLS-based VPN, it's easy to
> assume that you have to be running MPLS and/or a VPN to get any use out of
> VRFs. Not so, as I found from a late-night caffeine-fueled tinkering
> session...
>
> I use it in conjunction with OSPF, GRE tunnels and a few static routes to
> implement some VPN-like services. Replace the GRE tunnels with crypto
> tunnels and it becomes a lot more VPN-like ;-) I can send a sample config
> if you're interested.
Here are the relevant portions of a sample config for all interested
parties. This router is a 7206VXR running 12.2(15)T2. Also ran it on
12.2(10a) with everything but the tunnel keepalives. I used an 802.1q
VLAN trunk in one spot only because I had a limited number of physical
interfaces available. The customer premise router in this case is a 2610
running 12.2(11)T2.
A rough overview of the architecture: Each customer has some type of
connection to our network (T1, DSL, in-building Ethernet, etc). We land
one end of the tunnel on the outside interface of their premise router
(Serial interface for a T1, ethernet for a DSL, etc). The other end of
the tunnel terminates on this router.
All of the traffic from the test VRF gets sent to the INSIDE interface of
our service network, where an appliance lives that does the VPN-like
services. This box speaks OSPF with the OUTSIDE interface so that it can
inject LSAs into the OSPF cloud for customer networks. Note that the
router that terminates the customer's T1 on my side does not have a static
route for their LAN space. At this point the T1 is just a transport for
the tunnel and any management traffic I need to send to the premise
router.
The infrastructure should scale pretty cleanly since no policy routing is
being used. Adding another customer is a matter of provisioning another
tunnel, putting it into the "test" VRF, adding the appropriate routing and
configuring the service appliance accordingly.
jms
--BEGIN---
ip cef
!
ip vrf test
description contains service-specific routes that we don't want to pass
into the global OSPF cloud
rd 65432:99999 ! if you're not using MPLS, it really doesn't matter what
! you set this to.
!
interface Loopback0
ip address 192.168.254.3 255.255.255.255
!
interface Tunnel0
description Tunnel to Customer 1 [GRE]
ip vrf forwarding test
ip address 10.100.0.1 255.255.255.252
no ip proxy-arp
ip mtu 1476
ip route-cache flow
no ip split-horizon
load-interval 30
keepalive 10 2 ! 10 second keepalive intervals, 2 retries before tunnel
! is declared up or down, change to suit your needs
tunnel source Loopback0
tunnel destination 172.31.127.126
tunnel flow egress-records
!
interface FastEthernet0/0
description Service Test network trunk
no ip address
duplex full
!
interface FastEthernet0/0.10
description Service OUTSIDE VLAN
encapsulation dot1Q 10
ip address 192.168.10.9 255.255.255.248
no ip redirects
no ip proxy-arp
ip route-cache flow
ip ospf priority 100
no cdp enable
!
interface FastEthernet0/0.20
description Service INSIDE VLAN
encapsulation dot1Q 20
ip address 192.168.10.17 255.255.255.248
no ip redirects
no ip proxy-arp
ip route-cache flow
ip vrf forwarding test
no cdp enable
!
interface FastEthernet2/0
description Service Test Network upstream interface (to the backbone)
ip address 192.168.3.6 255.255.255.248
ip route-cache flow
duplex full
!
router ospf 10
log-adjacency-changes
redistribute connected
network 192.168.3.6 0.0.0.0 area 400
network 192.168.10.9 0.0.0.0 area 400
network 192.168.10.17 0.0.0.0 area 400
network 192.168.254.3 0.0.0.0 area 400
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.3.1 ! default route for normal IP path
ip route 172.31.127.126 255.255.255.255 192.168.3.1 ! routes for tunnel
! endpoints
ip route vrf test 0.0.0.0 0.0.0.0 192.168.10.18 ! default all outbound
! traffic from tunnels
! into the service
! appliance
ip route vrf test 172.16.200.0 255.255.255.0 10.100.0.2 ! route customer
! LAN space across their
! tunnel
---END---
CUSTOMER PREMISE ROUTER SAMPLE CONFIG
Note that the customer router doesn't need to be VRF-aware, it just needs
to be able to terminate a tunnel.
The customer router is running 12.2(11)T2 to get the "TCP adjust-mss"
and "GRE tunnel keepalive" features... TCP adjust-mss is needed to keep
tunnel MTU-related packet fragmentation from becoming an issue.
interface Serial0/0
description to Service Provider
ip address 172.31.127.126 255.255.255.252
encapsulation ppp
ip route-cache flow
no ip proxy-arp
no ip redirects
no ip unreachables
no cdp enable
!
interface Ethernet0/0
description Customer LAN
ip address 172.16.200.1 255.255.255.0
no ip proxy-arp
no ip redirects
no ip unreachables
no cdp enable
!
interface Tunnel0
description Service Test [GRE]
ip address 10.100.0.2 255.255.255.252
ip mtu 1476
ip route-cache flow
no ip split-horizon
ip tcp adjust-mss 1436
keepalive 10 2
tunnel source Ethernet0/0
tunnel destination 192.168.254.3
!
ip route 0.0.0.0 0.0.0.0 10.100.0.1 ! default all traffic into the tunnel
ip route 192.168.254.3 255.255.255.255 172.31.127.125 ! set a static route
! for the other end
! of the tunnel
! add separate static routes for management networks if you want to be
! able to manage the premise router "pseudo-out-of-band" e.g. management
! traffic doesn't go through the tunnel
More information about the cisco-nsp
mailing list