I am gonna start this off by saying that the only way I know to get over my fear of something is to learn to love it. This is how I am learning to conquer layer 2 tunneling. Today was the first day I got an L2 tunneling task to work without using the solution guide. And my solution didn't match but it still worked perfectly!
Here is the topology:
SW3====SW1====SW4
SW3 f0/14-15 connects to SW1 f0/17-18
SW4 f0/14-15 connects to SW1 f0/20-21
SW3 and SW4 need to form an L3 etherchannel. I will start off by explaining my thoughts on how this should work. The only protocol I think we should tunnel is lacp or pagp. Other solutions have dot1q-tunnel and some other stuff but I don't see why those are needed. If I am mistaken...please comment!
So this what I did on SW1:
int range f0/17 - 18, f0/20-21
l2protocol-tunnel point-to-point lacp
Then I configure SW3 and SW4 as such:
int range f0/14-15
shut
no switchport
channel-group 1 mode active
int po 1
no switchport
int range f0/14-15
no shut
The interfaces came up and then came down and this was my message:
%EC-5-L3DONTBNDL2: Fa0/15 suspended: LACP currently not enabled on the remote port.
%EC-5-L3DONTBNDL2: Fa0/14 suspended: LACP currently not enabled on the remote port.
Now I started to think about the tunneling and what could go wrong. I usually always end up with an "l2ptguard error detected" but I was NOT getting that message this time. Instead it just didn't work...
I thought about other labs I did where tunneled packets came back to the same switch over trunks or other ports on the same vlan. This would be bad if SW3 tried to form an etherchannel with itself!
I decided to separate the ports that SW3 and SW4 connected to by vlans. I was allowed to create 1 extra vlan, I knew this was fine because the other set of ports would use native vlan 1.
So I picked one port that connects to SW3 and one that connects to SW4 and put these in vlan 100:
int range f0/17,f0/20
switchport access vlan 100
and waited....
and waited....
Nothing happened. I swear I has this thing in the bag! So I swent to SW3 and SW4 and shut both f0/14-15 down. Then I brought them up again. Then I waited about 15 seconds and what did I see:
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/15, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/14, changed state to up
%LINK-3-UPDOWN: Interface Port-channel1, changed state to up
WOOH OOH! I was at work at the time and you know the looks I got! ;)
SW3#show eth sum | beg Gr
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------
1 Po1(RU) LACP Fa0/14(P) Fa0/15(P)
I know that l2protocol tunneling is still my weakness. And to think how it can affect reachability makes my cringe, but I am gonna learn to love it and hopefully soon I can conquer it.
Wednesday, August 27, 2008
Tuesday, August 26, 2008
IPV6 - OSPFv3, default route, RIPng, redistribution
This is the third of three ipv6 posts today. The others are below. Here we configure OSPFv3 over an nbma cloud, adevrtise a default route, and redistribute with RIPng.
Here is the topology:
|---RIPng---|-------OSPFv3 area 0---------|
[BB2]------[R5]---[FRAME]---[R1]---VLAN1001
Addressing:
R5-BB2 : 2001:192:10:1::/64
R1-R5 : 2001:CC1E:1:1515::/64
VLAN1001: FEC0:CC1E:1:1::/64
BB2 and R5 are doing RIPng (config not shown, it's easy enough!)
R5,R1 are doing OSPFv3, area 0 everywhere else.
Here is how I configured the neighbors over the FR cloud:
R1#show run int s1/0
interface Serial1/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::1/64
ipv6 ospf neighbor FE80::CE01:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 FE80::CE01:9FF:FEE8:0 105 broadcast
frame-relay map ipv6 2001:CC1E:1:1515::5 105 broadcast
R5#show run int s1/0
interface Serial1/0
no ip address
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::5/64
ipv6 ospf neighbor FE80::CE00:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 2001:CC1E:1:1515::1 501 broadcast
frame-relay map ipv6 FE80::CE00:9FF:FEE8:0 501 broadcast
Notice that I use the link-local address as the neighbor address.
R1#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.5.5 1 FULL/DR 00:01:44 5 Serial1/0
R1#
R5 is learning VLAN 1001:
R5#show ipv6 route ospf
O FEC0:CC1E:1:1::/64 [110/65]
via FE80::CE00:9FF:FEE8:0, Serial1/0
R5 is also learning some loopback networks from BB2 via RIP:
R5#show ipv6 route rip
R 2001:205:90:31::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
Task is to advertise default route to R1 via OSPFv3 without "default-information originate always" command. R5 should drop traffic unless it has a longer match. Sounds like a summary route, eh?! WRONG! we can't summarize intra-area, but we are allowed on static route...hmmm....We can point it to null and redistribute!
R5(config)#ipv6 route 0::/0 null0
R5(config-rtr)#redistribute static
Let's check R1:
R1#show ipv6 route ospf
R1#
Nothing!...well. The task says not to use the "default-information originate always" command. What if we leave off the always!
R5(config-rtr)#no redistribute static
R5(config-rtr)#default-information originate
R1#show ipv6 route ospf
OE2 ::/0 [110/1], tag 1
via FE80::CE01:9FF:FEE8:0, Serial1/0
There we go and we didn't need to redistribute static either. If you delete that default route to NULL, then the LSA disappears too!
So now R1 has a default route but BB2 still has no route back to VLAN1001. So we can redistribute into RIPng on R5:
R5(config)#ipv6 router rip RIPNG
R5(config-rtr)#redistribute ospf 1 metric 1
Ping from R1:
R1#ping 2001:205:90:31::1 source FEC0:CC1E:1:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:205:90:31::1, timeo
Packet sent with a source address of FEC0:CC1E:1:1::1
!!!!!
Here is the topology:
|---RIPng---|-------OSPFv3 area 0---------|
[BB2]------[R5]---[FRAME]---[R1]---VLAN1001
Addressing:
R5-BB2 : 2001:192:10:1::/64
R1-R5 : 2001:CC1E:1:1515::/64
VLAN1001: FEC0:CC1E:1:1::/64
BB2 and R5 are doing RIPng (config not shown, it's easy enough!)
R5,R1 are doing OSPFv3, area 0 everywhere else.
Here is how I configured the neighbors over the FR cloud:
R1#show run int s1/0
interface Serial1/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::1/64
ipv6 ospf neighbor FE80::CE01:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 FE80::CE01:9FF:FEE8:0 105 broadcast
frame-relay map ipv6 2001:CC1E:1:1515::5 105 broadcast
R5#show run int s1/0
interface Serial1/0
no ip address
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::5/64
ipv6 ospf neighbor FE80::CE00:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 2001:CC1E:1:1515::1 501 broadcast
frame-relay map ipv6 FE80::CE00:9FF:FEE8:0 501 broadcast
Notice that I use the link-local address as the neighbor address.
R1#show ipv6 ospf neighbor
Neighbor ID Pri State Dead Time Interface ID Interface
150.1.5.5 1 FULL/DR 00:01:44 5 Serial1/0
R1#
R5 is learning VLAN 1001:
R5#show ipv6 route ospf
O FEC0:CC1E:1:1::/64 [110/65]
via FE80::CE00:9FF:FEE8:0, Serial1/0
R5 is also learning some loopback networks from BB2 via RIP:
R5#show ipv6 route rip
R 2001:205:90:31::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
Task is to advertise default route to R1 via OSPFv3 without "default-information originate always" command. R5 should drop traffic unless it has a longer match. Sounds like a summary route, eh?! WRONG! we can't summarize intra-area, but we are allowed on static route...hmmm....We can point it to null and redistribute!
R5(config)#ipv6 route 0::/0 null0
R5(config-rtr)#redistribute static
Let's check R1:
R1#show ipv6 route ospf
R1#
Nothing!...well. The task says not to use the "default-information originate always" command. What if we leave off the always!
R5(config-rtr)#no redistribute static
R5(config-rtr)#default-information originate
R1#show ipv6 route ospf
OE2 ::/0 [110/1], tag 1
via FE80::CE01:9FF:FEE8:0, Serial1/0
There we go and we didn't need to redistribute static either. If you delete that default route to NULL, then the LSA disappears too!
So now R1 has a default route but BB2 still has no route back to VLAN1001. So we can redistribute into RIPng on R5:
R5(config)#ipv6 router rip RIPNG
R5(config-rtr)#redistribute ospf 1 metric 1
Ping from R1:
R1#ping 2001:205:90:31::1 source FEC0:CC1E:1:1::1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:205:90:31::1, timeo
Packet sent with a source address of FEC0:CC1E:1:1::1
!!!!!
Labels:
ipv6,
route redistribution
IPv6 - Policy-based routing
Same topology as before but without the offset:
Three loopbacks on BB2 advertised through RIPng to R3:
2001:205:90:31::1
2001:220:20:3::1
2001:222:22:2::1
Here is a traceroute from VLAN38:
R3#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]: no
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 28 msec 32 msec 32 msec
2 FEC0:CC1E:1:54::4 12 msec
FEC0:CC1E:1:45::4 60 msec
FEC0:CC1E:1:54::4 28 msec
3 2001:205:90:31::1 52 msec 72 msec 24 msec
R3#
Notice at step 2 of the trace we flip-flop between the two hops from R5. Let's use policy based routing to force traffic from VLAN38 to use the serial link to R4. On R5:
ipv6 access-list PBRv6
permit ipv6 FEC0:CC1E:1:38::/64 2001:205:90:31::/64
permit ipv6 FEC0:CC1E:1:38::/64 2001:220:20:3::/64
permit ipv6 FEC0:CC1E:1:38::/64 2001:222:22:2::/64
route-map PBRv6 permit 10
match ipv6 address PBRv6
set ipv6 default next-hop FEC0:CC1E:1:45::4
int s1/0.35
ipv6 policy route-map PBRv6
Do the trace again:
R3#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 20 msec 36 msec 24 msec
2 FEC0:CC1E:1:45::4 4 msec 80 msec 24 msec
3 2001:205:90:31::1 16 msec 40 msec 36 msec
R3#
Sweet. What if the link between R4 and R5 fails?
R5(config-subif)#int s1/1
R5(config-if)#shut
Now back to R3:
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 48 msec 28 msec 44 msec
2 FEC0:CC1E:1:54::4 24 msec 88 msec 20 msec
3 2001:205:90:31::1 8 msec 64 msec 44 msec
R3#
Now we are using the frame relay link.
Three loopbacks on BB2 advertised through RIPng to R3:
2001:205:90:31::1
2001:220:20:3::1
2001:222:22:2::1
Here is a traceroute from VLAN38:
R3#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]: no
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 28 msec 32 msec 32 msec
2 FEC0:CC1E:1:54::4 12 msec
FEC0:CC1E:1:45::4 60 msec
FEC0:CC1E:1:54::4 28 msec
3 2001:205:90:31::1 52 msec 72 msec 24 msec
R3#
Notice at step 2 of the trace we flip-flop between the two hops from R5. Let's use policy based routing to force traffic from VLAN38 to use the serial link to R4. On R5:
ipv6 access-list PBRv6
permit ipv6 FEC0:CC1E:1:38::/64 2001:205:90:31::/64
permit ipv6 FEC0:CC1E:1:38::/64 2001:220:20:3::/64
permit ipv6 FEC0:CC1E:1:38::/64 2001:222:22:2::/64
route-map PBRv6 permit 10
match ipv6 address PBRv6
set ipv6 default next-hop FEC0:CC1E:1:45::4
int s1/0.35
ipv6 policy route-map PBRv6
Do the trace again:
R3#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 20 msec 36 msec 24 msec
2 FEC0:CC1E:1:45::4 4 msec 80 msec 24 msec
3 2001:205:90:31::1 16 msec 40 msec 36 msec
R3#
Sweet. What if the link between R4 and R5 fails?
R5(config-subif)#int s1/1
R5(config-if)#shut
Now back to R3:
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 48 msec 28 msec 44 msec
2 FEC0:CC1E:1:54::4 24 msec 88 msec 20 msec
3 2001:205:90:31::1 8 msec 64 msec 44 msec
R3#
Now we are using the frame relay link.
Labels:
ipv6
IPv6 - RIPng metric offset
Here is the topology, use whatever DLCI's and interfaces you want:
R4 is learning these routes from BB2:
R 2001:205:90:31::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
The task is to force R5 to use the serial link instead of the frame-relay link to reach these networks. Let's look at R5 right now:
R5#show ipv6 route
R 2001:205:90:31::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
R 2001:220:20:3::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
R 2001:222:22:2::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
As you can see it's currently load sharing between the two 3-hop routes. How can we make the serial link more preferred? We can use an offset. It's not like the offset in rip for ipv4, but it works similar:
R5(config)#int s1/0.54
R5(config-subif)#ipv6 rip RIPNG metric-offset 2
Now let's take a look at our routes:
R5#show ipv6 route
R 2001:205:90:31::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
R 2001:220:20:3::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
R 2001:222:22:2::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
Trace from R3:
R3#trace 2001:205:90:31::1
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 24 msec 32 msec 32 msec
2 FEC0:CC1E:1:45::4 8 msec 44 msec 16 msec
3 2001:205:90:31::1 56 msec 16 msec 60 msec
R3#
Easy!
I first started out thinking offset-list but I ran into a couple issues. First you can't make ipv6 standard ACLs, at least I couldn't find a way. Then before attempting to use ipv6 prefix lists I thought I would check out what commands were available under an interface for RIPng:
R5(config-subif)#ipv6 rip RIPNG ?
default-information Configure handling of default route
enable Enable/disable RIP routing
metric-offset Adjust default metric increment
summary-address Configure address summarization
This is where I noticed the metric-offset. In addition there is no offset list under router config mode:
R5(config-subif)#ipv6 router rip RIPNG
R5(config-rtr)#?
default Set a command to its defaults
distance Administrative distance
distribute-list Filter networks in routing updates
exit Exit from IPv6 routing protocol configuration mode
maximum-paths Forward packets over multiple paths
no Negate a command or set its defaults
poison-reverse Poison reverse updates
port Port and multicast address
redistribute Redistribute IPv6 prefixes from another routing protocol
split-horizon Split horizon updates
timers Adjust routing timers
Didn't even need the DocCD!
R4 is learning these routes from BB2:
R 2001:205:90:31::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
The task is to force R5 to use the serial link instead of the frame-relay link to reach these networks. Let's look at R5 right now:
R5#show ipv6 route
R 2001:205:90:31::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
R 2001:220:20:3::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
R 2001:222:22:2::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
As you can see it's currently load sharing between the two 3-hop routes. How can we make the serial link more preferred? We can use an offset. It's not like the offset in rip for ipv4, but it works similar:
R5(config)#int s1/0.54
R5(config-subif)#ipv6 rip RIPNG metric-offset 2
Now let's take a look at our routes:
R5#show ipv6 route
R 2001:205:90:31::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
R 2001:220:20:3::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
R 2001:222:22:2::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
Trace from R3:
R3#trace 2001:205:90:31::1
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1
1 FEC0:CC1E:1:35::5 24 msec 32 msec 32 msec
2 FEC0:CC1E:1:45::4 8 msec 44 msec 16 msec
3 2001:205:90:31::1 56 msec 16 msec 60 msec
R3#
Easy!
I first started out thinking offset-list but I ran into a couple issues. First you can't make ipv6 standard ACLs, at least I couldn't find a way. Then before attempting to use ipv6 prefix lists I thought I would check out what commands were available under an interface for RIPng:
R5(config-subif)#ipv6 rip RIPNG ?
default-information Configure handling of default route
enable Enable/disable RIP routing
metric-offset Adjust default metric increment
summary-address Configure address summarization
This is where I noticed the metric-offset. In addition there is no offset list under router config mode:
R5(config-subif)#ipv6 router rip RIPNG
R5(config-rtr)#?
default Set a command to its defaults
distance Administrative distance
distribute-list Filter networks in routing updates
exit Exit from IPv6 routing protocol configuration mode
maximum-paths Forward packets over multiple paths
no Negate a command or set its defaults
poison-reverse Poison reverse updates
port Port and multicast address
redistribute Redistribute IPv6 prefixes from another routing protocol
split-horizon Split horizon updates
timers Adjust routing timers
Didn't even need the DocCD!
Labels:
ipv6
Monday, August 18, 2008
NAT - Policy NAT with route-maps
Here is the topology. I use this for a lot of NAT scenarios. I have a dynamips file all ready to go for it :) The frame-relay network is 172.12.123.x where x is the router number. You can use whatever internal routing method you want.
Requirements:
When R5 telnets to 172.12.123.1 it should go through R2.
When R5 telnets to 172.12.123.1 port 3001 it should go through R3.
We will look at our NAT translations on R4 to verify.
First set up your outside interfaces (R4 to R2,R3) and inside interface (R4 to R5).
Next create an ACL top match out two types of traffic:
R4(config)#access-list 102 permit tcp host 172.12.45.5 host 172.12.123.1 eq telnet
R4(config)#access-list 103 permit tcp host 172.12.45.5 host 172.12.123.1 eq 3001
Next create your route-maps. F0/0 is connects R4 to R2, F2/0 connects R4 to R3:
route-map gotoR2
match ip address 102
set interface f0/0
route-map gotoR3
match ip address 103
set interface f2/0
Now create your NAT rules:
R4(config)#ip nat inside source route-map gotoR2 interface f0/0
R4(config)#ip nat inside source route-map gotoR3 interface f2/0
Let's head to R5 and do the telnet:
R5#telnet 172.12.123.1
Trying 172.12.123.1 ... Open
User Access Verification
Password:
R1>exit
Now check R4:
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:16208 172.12.45.5:16208 172.12.123.1:23 172.12.123.1:23
Perfect. Now let's head back to R5 and telnet to port 3001 (remember to set up a rotary line on R1's vty)
R5#telnet 172.12.123.1 3001
Trying 172.12.123.1, 3001 ... Open
User Access Verification
Password:
R1>
R4 we now see both translations. Notice the port numbers. Cisco calls these "fully extended" translation entries.
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:16208 172.12.45.5:16208 172.12.123.1:23 172.12.123.1:23
tcp 172.12.34.4:29692 172.12.45.5:29692 172.12.123.1:3001 172.12.123.1:3001
Not too bad, eh? NAT is still pretty initmadating for me. I can get easy scenarios out of the way, but some examples such as this still have the potential to cause me trouble. Hopefully, by practicing and doing these scenarios without any help, I can get it down pat...pun intended :)
Requirements:
When R5 telnets to 172.12.123.1 it should go through R2.
When R5 telnets to 172.12.123.1 port 3001 it should go through R3.
We will look at our NAT translations on R4 to verify.
First set up your outside interfaces (R4 to R2,R3) and inside interface (R4 to R5).
Next create an ACL top match out two types of traffic:
R4(config)#access-list 102 permit tcp host 172.12.45.5 host 172.12.123.1 eq telnet
R4(config)#access-list 103 permit tcp host 172.12.45.5 host 172.12.123.1 eq 3001
Next create your route-maps. F0/0 is connects R4 to R2, F2/0 connects R4 to R3:
route-map gotoR2
match ip address 102
set interface f0/0
route-map gotoR3
match ip address 103
set interface f2/0
Now create your NAT rules:
R4(config)#ip nat inside source route-map gotoR2 interface f0/0
R4(config)#ip nat inside source route-map gotoR3 interface f2/0
Let's head to R5 and do the telnet:
R5#telnet 172.12.123.1
Trying 172.12.123.1 ... Open
User Access Verification
Password:
R1>exit
Now check R4:
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:16208 172.12.45.5:16208 172.12.123.1:23 172.12.123.1:23
Perfect. Now let's head back to R5 and telnet to port 3001 (remember to set up a rotary line on R1's vty)
R5#telnet 172.12.123.1 3001
Trying 172.12.123.1, 3001 ... Open
User Access Verification
Password:
R1>
R4 we now see both translations. Notice the port numbers. Cisco calls these "fully extended" translation entries.
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:16208 172.12.45.5:16208 172.12.123.1:23 172.12.123.1:23
tcp 172.12.34.4:29692 172.12.45.5:29692 172.12.123.1:3001 172.12.123.1:3001
Not too bad, eh? NAT is still pretty initmadating for me. I can get easy scenarios out of the way, but some examples such as this still have the potential to cause me trouble. Hopefully, by practicing and doing these scenarios without any help, I can get it down pat...pun intended :)
Labels:
nat
Sunday, August 17, 2008
NAT - Port forwarding telnet
Here is the topology:
R1---->R3---->R4---->R5
R1 and R3 are on the 172.12.123.0/24 network.
R3 and R4 are on the 172.12.34.0/24 network.
R4 and R5 are on the 172.12.45.0/24 network.
The goal of this scenario is:
R1 uses R4's address and port 23 to telnet to R4
R1 uses R4's address and port 3001 to telnet to R5.
R1 does not have knowledge of R4-R5 network so NAT is necessary.
R5 uses R4 as default route.
When R1 enters "telnet 172.12.34.4" it should enter R4.
When R1 enters "telnet 172.12.34.4 3001" it should enter R5.
First set up R4 and R5 for vty access, remember to use rotary command on R5 to set up port 3001.
R4(config)#line vty 0 4
R4(config-line)#password cisco
R4(config-line)#login
R5(config)#line vty 5
R5(config-line)#rotary 1
R5(config-line)#password cisco
R5(config-line)#login
Also make R4's interface to R3 "ip nat outside", and R4's interface to R5 "ip nat inside."
On R4 we only need one more command now:
R4(config)#ip nat inside source static tcp 172.12.45.5 3001 172.12.34.4 3001
Now Let's try it:
R1#telnet 172.12.34.4
Trying 172.12.34.4 ... Open
User Access Verification
Password:
R4>
Perfect, we are in R4 now. Let's exit and try port 3001:
R1#telnet 172.12.34.4 3001
Trying 172.12.34.4, 3001 ... Open
User Access Verification
Password:
R5>
We are in R5 here. This was a lot easier than I thought :)
R1---->R3---->R4---->R5
R1 and R3 are on the 172.12.123.0/24 network.
R3 and R4 are on the 172.12.34.0/24 network.
R4 and R5 are on the 172.12.45.0/24 network.
The goal of this scenario is:
R1 uses R4's address and port 23 to telnet to R4
R1 uses R4's address and port 3001 to telnet to R5.
R1 does not have knowledge of R4-R5 network so NAT is necessary.
R5 uses R4 as default route.
When R1 enters "telnet 172.12.34.4" it should enter R4.
When R1 enters "telnet 172.12.34.4 3001" it should enter R5.
First set up R4 and R5 for vty access, remember to use rotary command on R5 to set up port 3001.
R4(config)#line vty 0 4
R4(config-line)#password cisco
R4(config-line)#login
R5(config)#line vty 5
R5(config-line)#rotary 1
R5(config-line)#password cisco
R5(config-line)#login
Also make R4's interface to R3 "ip nat outside", and R4's interface to R5 "ip nat inside."
On R4 we only need one more command now:
R4(config)#ip nat inside source static tcp 172.12.45.5 3001 172.12.34.4 3001
Now Let's try it:
R1#telnet 172.12.34.4
Trying 172.12.34.4 ... Open
User Access Verification
Password:
R4>
Perfect, we are in R4 now. Let's exit and try port 3001:
R1#telnet 172.12.34.4 3001
Trying 172.12.34.4, 3001 ... Open
User Access Verification
Password:
R5>
We are in R5 here. This was a lot easier than I thought :)
Labels:
nat
NAT - Redundancy with route-maps
Here is the topology:
R1 has a loopback 100.0.0.1
R4 has a connection R2 via interface f0/0
R4 has a connection R3 via interface f2/0
R5 uses R4 as its default gateway, R1 has no route back to this network, but R1 does have a route to R4. So R4 is where we NAT.
We want R5 to have reachability to R1 when either of the R4 uplinks are down. Here's how. First create an ACL to match the R5 network:
ip access-list standard VLAN45
permit 172.12.45.0 0.0.0.255
Next create 2 route-maps that match the interface that will be used for routing the packet outbound and the ACL:
route-map FE0 permit 10
match ip address VLAN45
match interface FastEthernet0/0
route-map FE2 permit 10
match ip address VLAN45
match interface FastEthernet2/0
Next we create our nat statements:
ip nat inside source route-map FE0 interface FastEthernet0/0 overload
ip nat inside source route-map FE2 interface FastEthernet2/0 overload
Remember to enable nat inside/outside on the proper interface of R4.
Let's try it from R5:
R5#telnet 100.0.0.1
Trying 100.0.0.1 ... Open
User Access Verification
Password:
R1>
Let's check translations on R4. Notice the current address being used for NAT is 172.12.24.4 which is R4's interface towards R2. This is the best route in the route table towards R1.
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:64118 172.12.45.5:64118 100.0.0.1:23 100.0.0.1:23
R4#
Now let's shut the interface to R2 on R4:
R4(config)#int f0/0
R4(config-if)#shut
R4(config-if)#^Z
R4#show ip nat translations
R4#
Telnet again from R5:
R5#telnet 100.0.0.1
Trying 100.0.0.1 ... Open
User Access Verification
Password:
Check translations on R4. Now we are using R4's interface towards R3 for routing and address translation. This is the backup route for R4 towards R1.
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.34.4:13668 172.12.45.5:13668 100.0.0.1:23 100.0.0.1:23
R4#
The key thing to remember with this configuration is that the route-map used in this example is used as the "source" in the NAT statement. As opposed to matching just an address list or a static IP we are matching an address list and the interface out of which the packet will be routed.
Without the "match interface" in the route-map, the router does not perform translation when using the backup interface. I think this is because if you did not have the "match interface", then whatever NAT statement appears first in your running-config would be used. In this case I have the following order of statements:
ip nat inside source route-map FE0 interface FastEthernet0/0 overload
ip nat inside source route-map FE2 interface FastEthernet2/0 overload
If I did not have a "match interface" in my route-maps, than when f0/0 went down, the router would still try to use the first rule for translation! It wouldn't care what interface was used for routing, it would just use the first route-map that matched all conditions, in this case the only condition would be the source address.
R1 has a loopback 100.0.0.1
R4 has a connection R2 via interface f0/0
R4 has a connection R3 via interface f2/0
R5 uses R4 as its default gateway, R1 has no route back to this network, but R1 does have a route to R4. So R4 is where we NAT.
We want R5 to have reachability to R1 when either of the R4 uplinks are down. Here's how. First create an ACL to match the R5 network:
ip access-list standard VLAN45
permit 172.12.45.0 0.0.0.255
Next create 2 route-maps that match the interface that will be used for routing the packet outbound and the ACL:
route-map FE0 permit 10
match ip address VLAN45
match interface FastEthernet0/0
route-map FE2 permit 10
match ip address VLAN45
match interface FastEthernet2/0
Next we create our nat statements:
ip nat inside source route-map FE0 interface FastEthernet0/0 overload
ip nat inside source route-map FE2 interface FastEthernet2/0 overload
Remember to enable nat inside/outside on the proper interface of R4.
Let's try it from R5:
R5#telnet 100.0.0.1
Trying 100.0.0.1 ... Open
User Access Verification
Password:
R1>
Let's check translations on R4. Notice the current address being used for NAT is 172.12.24.4 which is R4's interface towards R2. This is the best route in the route table towards R1.
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:64118 172.12.45.5:64118 100.0.0.1:23 100.0.0.1:23
R4#
Now let's shut the interface to R2 on R4:
R4(config)#int f0/0
R4(config-if)#shut
R4(config-if)#^Z
R4#show ip nat translations
R4#
Telnet again from R5:
R5#telnet 100.0.0.1
Trying 100.0.0.1 ... Open
User Access Verification
Password:
Check translations on R4. Now we are using R4's interface towards R3 for routing and address translation. This is the backup route for R4 towards R1.
R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.34.4:13668 172.12.45.5:13668 100.0.0.1:23 100.0.0.1:23
R4#
The key thing to remember with this configuration is that the route-map used in this example is used as the "source" in the NAT statement. As opposed to matching just an address list or a static IP we are matching an address list and the interface out of which the packet will be routed.
Without the "match interface" in the route-map, the router does not perform translation when using the backup interface. I think this is because if you did not have the "match interface", then whatever NAT statement appears first in your running-config would be used. In this case I have the following order of statements:
ip nat inside source route-map FE0 interface FastEthernet0/0 overload
ip nat inside source route-map FE2 interface FastEthernet2/0 overload
If I did not have a "match interface" in my route-maps, than when f0/0 went down, the router would still try to use the first rule for translation! It wouldn't care what interface was used for routing, it would just use the first route-map that matched all conditions, in this case the only condition would be the source address.
Labels:
nat
Friday, August 15, 2008
BGP - regexp practice part 1
Using regexp with as-path access-list are one of the coolest features of BGP. The show ip bgp regexp command is good way to test your regular expression.
Here is what I have currently on R1's bgp table:
R1#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i
Suppose I want to match routes that contain one AS or two AS but no more. I could do this:
R1#show ip bgp regexp ^[0-9]*$|^[0-9]*_[0-9]*$
Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i
How about paths that only contain at least one 4-digit AS# (why? i have no clue but here's how)
R1#show ip bgp regexp _[0-9][0-9][0-9][0-9]_
Network Next Hop Metric LocPrf Weight Path
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i
R1#
Well that's it for now. I'll come up with some more later.
Here is what I have currently on R1's bgp table:
R1#show ip bgp | be Ne
Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i
Suppose I want to match routes that contain one AS or two AS but no more. I could do this:
R1#show ip bgp regexp ^[0-9]*$|^[0-9]*_[0-9]*$
Network Next Hop Metric LocPrf Weight Path
*> 100.3.0.0/24 172.12.123.3 0 0 300 i
*> 100.3.1.0/24 172.12.123.3 0 0 300 i
*> 100.3.2.0/24 172.12.123.3 0 0 300 i
*> 100.6.0.0/24 172.12.123.3 0 300 600 i
*> 100.6.1.0/24 172.12.123.3 0 300 600 i
*> 100.6.2.0/24 172.12.123.3 0 300 600 i
How about paths that only contain at least one 4-digit AS# (why? i have no clue but here's how)
R1#show ip bgp regexp _[0-9][0-9][0-9][0-9]_
Network Next Hop Metric LocPrf Weight Path
*> 100.6.3.0/24 172.12.123.3 0 300 600 1000 1200 i
*> 100.6.4.0/24 172.12.123.3 0 300 600 1000 1200 i
R1#
Well that's it for now. I'll come up with some more later.
Labels:
bgp,
bgp regexp
some IPv6 notes: frame relay, RIPng, default routes
I was doing an IPv6 lab today. Here are some issues I came across:
Issue #1:
Hub and spoke environment, hubs could ping spoke, spokes couldn't ping hub. Turns out I didn't have "ipv6 unicast-routing" on the hub or the other routers.
Issue #2:
IPv6 router wasn't get routes from the backbone. I didn't have IPv6 rip enabled on the loopbacks.
Issue #3:
Spoke wasn't getting routes from other spoke. I needed to turn of split horizon on the hub. This is turned off under the process as follows:
ipv6 router rip RIP6
no split-horizon
Issue #4:
Default route wasn't getting propogated to downstream router. I need to have a metric for this route. Like this:
interface Serial1/0
ipv6 rip RIP6 default-information only metric 2
Issue #1:
Hub and spoke environment, hubs could ping spoke, spokes couldn't ping hub. Turns out I didn't have "ipv6 unicast-routing" on the hub or the other routers.
Issue #2:
IPv6 router wasn't get routes from the backbone. I didn't have IPv6 rip enabled on the loopbacks.
Issue #3:
Spoke wasn't getting routes from other spoke. I needed to turn of split horizon on the hub. This is turned off under the process as follows:
ipv6 router rip RIP6
no split-horizon
Issue #4:
Default route wasn't getting propogated to downstream router. I need to have a metric for this route. Like this:
interface Serial1/0
ipv6 rip RIP6 default-information only metric 2
Labels:
ipv6
Monday, August 11, 2008
BGP - Neighbor discovery protocol
Ok. The title is misleading, there is no such thing!
But I was doing IPexpert's volume 1 section 11 lab on BGP and I thought this would be a cool topic since I always see some posts about this on groupstudy.
R9 is connected to the same LAN as BB3. We need to peer with BB3 but we don't know the IP or the AS number of BB3.
First, we can ping the broadcast address on the ethernet segment between R9 and BB3. This works best with only 1 other host. Otherwise we would have to resort to trial and error or some other means, maybe debug ip packet.
R9#ping 100.100.250.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.250.255, timeout is 2 seconds:
Reply to request 0 from 100.100.250.250, 4 ms
Reply to request 1 from 100.100.250.250, 1 ms
Reply to request 2 from 100.100.250.250, 1 ms
R9#
Now we know our peer ip, but we need to know the AS number. If you peer to the wrong AS, you can see the BB AS in message debug:
R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as 1
*Aug 12 02:57:05.411: %BGP-3-NOTIFICATION: sent to neighbor 100.100.250.250 2/2 (peer in wrong AS) 2 bytes 0DE9
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0DE9 00B4 6E0F 90C8 1002 0601 0400 0100 0102 0280 0002 0202 00
Here the neighbor is in AS 0DE9 (3561)
R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as
*Aug 12 02:59:12.359: %BGP-5-ADJCHANGE: neighbor 100.100.250.250 Up
Cool, eh?
But I was doing IPexpert's volume 1 section 11 lab on BGP and I thought this would be a cool topic since I always see some posts about this on groupstudy.
R9 is connected to the same LAN as BB3. We need to peer with BB3 but we don't know the IP or the AS number of BB3.
First, we can ping the broadcast address on the ethernet segment between R9 and BB3. This works best with only 1 other host. Otherwise we would have to resort to trial and error or some other means, maybe debug ip packet.
R9#ping 100.100.250.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.250.255, timeout is 2 seconds:
Reply to request 0 from 100.100.250.250, 4 ms
Reply to request 1 from 100.100.250.250, 1 ms
Reply to request 2 from 100.100.250.250, 1 ms
R9#
Now we know our peer ip, but we need to know the AS number. If you peer to the wrong AS, you can see the BB AS in message debug:
R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as 1
*Aug 12 02:57:05.411: %BGP-3-NOTIFICATION: sent to neighbor 100.100.250.250 2/2 (peer in wrong AS) 2 bytes 0DE9
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0DE9 00B4 6E0F 90C8 1002 0601 0400 0100 0102 0280 0002 0202 00
Here the neighbor is in AS 0DE9 (3561)
R9(config)#router bgp 19999
R9(config-router)#neighbor 100.100.250.250 remote-as
*Aug 12 02:59:12.359: %BGP-5-ADJCHANGE: neighbor 100.100.250.250 Up
Cool, eh?
Labels:
bgp
Sunday, August 10, 2008
EIGRP - summarization with leak-map
R7 has three loopbacks:
172.29.17.7/24
172.29.18.7/24
172.29.19.7/24
And it is connected to a few routers including R8. You want R7 to summarize the networks but also advertise a specific route of 172.29.18.0/24 to R8. Here's how:
R7:
access-list 18 permit 172.29.18.0 0.0.0.255
!
route-map LEAK18
match ip address 18
!
int s0/0/0
ip summary-address eigrp 1001 172.29.16.0 255.255.252.0 leak-map LEAK18
Now on R8:
R8#show ip route | in 172
172.29.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.29.16.0/22 [90/20640000] via 150.100.78.7, 00:03:31, Serial0/0/0
D 172.29.18.0/24 [90/20640000] via 150.100.78.7, 00:01:04, Serial0/0/0
Easy, eh?
172.29.17.7/24
172.29.18.7/24
172.29.19.7/24
And it is connected to a few routers including R8. You want R7 to summarize the networks but also advertise a specific route of 172.29.18.0/24 to R8. Here's how:
R7:
access-list 18 permit 172.29.18.0 0.0.0.255
!
route-map LEAK18
match ip address 18
!
int s0/0/0
ip summary-address eigrp 1001 172.29.16.0 255.255.252.0 leak-map LEAK18
Now on R8:
R8#show ip route | in 172
172.29.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.29.16.0/22 [90/20640000] via 150.100.78.7, 00:03:31, Serial0/0/0
D 172.29.18.0/24 [90/20640000] via 150.100.78.7, 00:01:04, Serial0/0/0
Easy, eh?
Labels:
eigrp,
route summarization
Wednesday, August 6, 2008
IPexpert Volume 1 section 5 - L2 protocol tunneling
Not gonna say much here just that this teeny lab kicked my butt. I must say I fell pretty comfortable when it comes time do anything with BGP, OSPF, EIGRP and routing. Even multicast and IPv6 I feel comfortable now. QoS, I am getting there. I thought l2tunneling was cake until I started this lab. That was Sunday. Today is Wednesday and I finally hammered it out. Two online rack sessions and a bunch of researching in between. I didn't just follow the proctor guide on this!
I tried it my own way - didn't work.
Tried to fix it - didn't work.
Saved configs
I copied the final configs to the switches just to make sure the solution worked - it worked.
Recopied my configs over and progressed from their.
Repeat about a dozen times.
Troubleshooting, debugging, I learned a lot along the way.
I even found out a lot about how LACP works, by exchanging your mac and the partner mac - a lot like the OSPF adjacency INIT stage.
Also, the solution doesn't quite follow what you read in the DocCD, another reason it is good to get a taste of more than one vendor, because there are many ways of doing everything.
I swear I know this lab inside-out. It's got me searching for different scenarios. Hopefully come lab time, I am well prepared for anything.
I tried it my own way - didn't work.
Tried to fix it - didn't work.
Saved configs
I copied the final configs to the switches just to make sure the solution worked - it worked.
Recopied my configs over and progressed from their.
Repeat about a dozen times.
Troubleshooting, debugging, I learned a lot along the way.
I even found out a lot about how LACP works, by exchanging your mac and the partner mac - a lot like the OSPF adjacency INIT stage.
Also, the solution doesn't quite follow what you read in the DocCD, another reason it is good to get a taste of more than one vendor, because there are many ways of doing everything.
I swear I know this lab inside-out. It's got me searching for different scenarios. Hopefully come lab time, I am well prepared for anything.
Monday, August 4, 2008
Resolving precedence names to numbers
I had a task to configure WRED for all packets with the precedence of "routine" but doesn't give you the precedence number...so to find it I did this:
Rack1R1(config)#class-map TEST
Rack1R1(config-cmap)#match precedence ?
<0-7> Enter up to 4 precedence values separated by white-spaces
critical Match packets with critical precedence (5)
flash Match packets with flash precedence (3)
flash-override Match packets with flash override precedence (4)
immediate Match packets with immediate precedence (2)
internet Match packets with internetwork control precedence (6)
network Match packets with network control precedence (7)
priority Match packets with priority precedence (1)
routine Match packets with routine precedence (0)
Routine is 0!
Rack1R1(config)#class-map TEST
Rack1R1(config-cmap)#match precedence ?
<0-7> Enter up to 4 precedence values separated by white-spaces
critical Match packets with critical precedence (5)
flash Match packets with flash precedence (3)
flash-override Match packets with flash override precedence (4)
immediate Match packets with immediate precedence (2)
internet Match packets with internetwork control precedence (6)
network Match packets with network control precedence (7)
priority Match packets with priority precedence (1)
routine Match packets with routine precedence (0)
Routine is 0!
Labels:
lab tips
Sunday, August 3, 2008
Task Interpretation (probably part 1 of many)
Recently I had a task that told me a serial link between two routers will only be used if the Ethernet and frame-relay links between these routers went down. Detection of the failed links and convergence should happen within 10 seconds. Immediately I thought of the backup interface command, however:
R4(config)#interface e0/0
R4(config-if)#backup interface s0/1
Serial0/1 is already a backup for Serial0/0
R4(config-if)#
You can only have an interface be a backup for one interface!
What the task was really asking for was to make OSPF detect the failed neighbors within 10 seconds and thus install the direct serial link route. We do this by adjusting the hello-interval on the Ethernet and frame-relay links to 2 seconds (2 x 4 = 8 second dead interval).
Another reason it is important to think a little outside the box and try to understand what the goal of the task is.
R4(config)#interface e0/0
R4(config-if)#backup interface s0/1
Serial0/1 is already a backup for Serial0/0
R4(config-if)#
You can only have an interface be a backup for one interface!
What the task was really asking for was to make OSPF detect the failed neighbors within 10 seconds and thus install the direct serial link route. We do this by adjusting the hello-interval on the Ethernet and frame-relay links to 2 seconds (2 x 4 = 8 second dead interval).
Another reason it is important to think a little outside the box and try to understand what the goal of the task is.
Subscribe to:
Posts (Atom)