We recently installed a new DS3 circuit, and I am having a monster of a time getting a route-map to work properly. I know I am missing something simple, but I can't find it. I've changed this so many times I have a headache, but nothing.
Setup is as follows:
***T3 controller card installed as serial1/0 interface with outside IP addresses (DS3)
interface Serial1/0 description Connected to DS3 ip address 126.96.36.199 255.255.255.252 ip nbar protocol-discovery ip virtual-reassembly encapsulation ppp ip route-cache policy ip route-cache flow dsu bandwidth 44210
**Physical Interface connecting to VLAN65
interface FastEthernet0/2/1 description Connected to DS3 LAN Block as Gateway switchport access vlan 65 speed 100
**Virtual Interface for inside IP addresses
interface Vlan65 description Local Gateway for DS3 ip address 188.8.131.52 255.255.255.240 ip nbar protocol-discovery ip route-cache policy ip route-cache flow ip policy route-map DS3
** ACL for trafic (picking one address (my test PC) for simplicity)
access-list 10 permit 184.108.40.206
** route map directing all traffic from source address 220.127.116.11 through DS3 circuit
route-map DS3 permit 65 match ip address 10 set interface Serial1/0
From the .23 test PC address, I can ping the serial interface and WAN interface off the serial side, which are all connected routes. Nothing else beyond that.
I have turned on debug packet 10 with detail and all I see is routing to the broadcast domain on VLAN65 via RIB and no counter increments on the sh route-map. I don't see any debug lines come accross for any address I try to ping from the test PC.
If I add a route for any address and point it to the serial1/0 interface, than it works fine, obviously. Without a hardcoded route, nothing. For some reason, the rotue-map match is not being hit, which means my ACL is incorrect? I've changed the ACL several times with extended attribs as well, permit ip, permit ip host, etc...
I expanded the debug to the policies, and I see some interesting results. The packets I am sending out are being rejected by another policy on vlan64, which is another line altogether. Similiar, but not the same subnets. Not sure why it would reject on the other policy. I am reposting the config using (almost) correct addresses for better understanding. BTW, the vlan64 network does route fine.
! interface GigabitEthernet0/1 description Connected to XO MetroE ip address 18.104.22.168 255.255.255.252 ip nbar protocol-discovery ip virtual-reassembly ip route-cache policy ip route-cache flow duplex full speed 10 media-type rj45 negotiation auto crypto map GWVPN ! interface FastEthernet0/2/0 description Connected to XO LAN Block as switchport access vlan 64 speed 100 ! interface FastEthernet0/2/1 description Connected to XO DS3 LAN Block switchport access vlan 65 speed 100 ! interface Serial1/0 description Connected to XO DS3 ip address 22.214.171.124 255.255.255.252 ip nbar protocol-discovery ip virtual-reassembly encapsulation ppp ip route-cache policy ip route-cache flow dsu bandwidth 44210
interface Vlan64 description Local Gateway for XO MetroE ip address 126.96.36.199 255.255.255.224 ip nbar protocol-discovery ip route-cache policy ip route-cache flow ip policy route-map XO ! interface Vlan65 description Local Gateway for XO DS3 ip address 188.8.131.52 255.255.255.240 ip nbar protocol-discovery ip route-cache policy ip route-cache flow ip policy route-map XODS3
access-list 164 permit ip 184.108.40.206 0.0.0.27 any access-list 165 permit ip host 220.127.116.11 any
route-map XO permit 64 match ip address 164 set ip next-hop 18.104.22.168 ! route-map XODS3 permit 65 match ip address 165 set ip next-hop 22.214.171.124 !
router rip version 2 redistribute static network 10.0.0.0 neighbor 10.0.200.2 neighbor 10.0.1.5 no auto-summary ! ip local pool goodwillpool 10.0.111.101 10.0.111.199 ip route 0.0.0.0 0.0.0.0 10.0.200.2 ip route 10.253.24.242 255.255.255.255 10.0.5.1 ip route 126.96.36.199 255.255.255.255 188.8.131.52 ip route 184.108.40.206 255.255.255.248 GigabitEthernet0/1 ip route 172.16.0.0 255.255.0.0 10.0.1.38 ip route 220.127.116.11 255.255.255.255 18.104.22.168 ip route 22.214.171.124 255.255.255.255 GigabitEthernet0/1 !
*** debug *** I actually got one packet to go out, and then it switched to vlan64 and killed them. It does that sometimes, starts out vlan65 and switches to vlan64.
Mar 16 14:57:51.492: IP: s=126.96.36.199 (Vlan65), d=188.8.131.52, len 60, FIB policy match Mar 16 14:57:51.492: IP: s=184.108.40.206 (Vlan65), d=220.127.116.11, g=18.104.22.168, len 60, FIB policy routed Mar 16 14:57:52.492: IP: s=22.214.171.124 (Vlan64), d=126.96.36.199, len 60, FIB policy rejected(no match) - normal forwarding Mar 16 14:57:57.800: IP: s=188.8.131.52 (Vlan64), d=184.108.40.206, len 60, FIB policy rejected(no match) - normal forwarding Mar 16 14:58:02.803: IP: s=220.127.116.11 (Vlan64), d=18.104.22.168, len 60, FIB policy rejected(no match) - normal forwarding
*** SH IP ROUTE ***
22.214.171.124/8 is variably subnetted, 3 subnets, 3 masks C 126.96.36.199/27 is directly connected, Vlan64 S 188.8.131.52/32 [1/0] via 184.108.40.206 C 220.127.116.11/28 is directly connected, Vlan65 18.104.22.168/30 is subnetted, 4 subnets 22.214.171.124/8 is variably subnetted, 5 subnets, 2 masks R 126.96.36.199/30 [120/2] via 10.0.200.2, 00:00:10, GigabitEthernet0/0 C 188.8.131.52/32 is directly connected, Serial1/0 C 184.108.40.206/30 is directly connected, Serial1/0 R 220.127.116.11/30 [120/2] via 10.0.200.2, 00:00:10, GigabitEthernet0/0 C 18.104.22.168/30 is directly connected, GigabitEthernet0/1
I even changed the scheme altogether just in case it was confused on the name, and I created a map DS3 and match 10, but it did not do anything.
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts The ProblemOn traditional
switches whenever we have a trunk interface we use the VLAN tag to
demultiplex the VLANs. The switch needs to determine which MAC ...
The ProblemEnter EVCsHow It Works (Ingress)How It Works
(Egress)Step-by-Step ExampleFinal Thoughts Introduction: Netdr is a tool
available on a RSP720, Sup720 or Sup32 that allows one to capture
packets on the RP or SP inband. The netdr command can be use...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...