Of course, being the inquisitive network guys that we are, we went on to discuss methods for making OSPF advertise the configured network instead of the single IP.  The guys mentioned two methods – to redistribute the connected interfaces and to manually set the OSPF network type on the loopback.  We were using IPv4 during the session, but I went back and added some IPv6 addresses and processes to compare.

The Basics

The whole lab consisted of R101 and R102 connected via their e0/0 interfaces; R101 also has a loopback interface as the guinea pig.  Here are the interesting lines of config on R101; I think you can figure out the configs on R102.

interface Loopback0
 ip address 172.16.0.1 255.255.255.0
 ipv6 address 2001:DB8:101::1/64
 ipv6 ospf 1 area 0
!
interface Ethernet0/0
 ip address 10.0.0.101 255.255.255.0
 ipv6 enable
 ipv6 ospf 1 area 0
!
router ospf 1
 log-adjacency-changes
 network 10.0.0.0 0.0.0.255 area 0
 network 172.16.0.0 0.0.0.255 area 0
!
ipv6 router ospf 1
 router-id 192.0.2.101
 log-adjacency-changes

So, what would I expect to see in the routing table on R102?  From our discussions, I would guess that 172.16.0.1/32 and 2001:db8:101::1/128 would show up.

R102#sh ip route
[ SNIP ]
172.16.0.0/32 is subnetted, 1 subnets
O        172.16.0.1 [110/11] via 10.0.0.101, 00:00:03, Ethernet0/0
R102#show ipv6 route
[ SNIP ]
O   2001:DB8:101::1/128 [110/10]
     via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0

Hey!  I’m right for once.  Of course, that’s not really “right” (for definitions of the word). What if I have a service module on my router with an unnumbered IP address bound to the loopback interface. I’m thinking of something like a Unity Express (!).  You want to advertise the whole network or else you can’t get to the module. Let’s look at our two options to fix that.

Redistribute Connected

I removed the loopback interface from both OSPFv2 and OSPFv3 processes and redistributed the connected interfaces (don’t forget the subnets option in OSPFv2).  Here’s what the routing tables on R102 look like now.

R102#sh ip route
[ SNIP ]
172.16.0.0/24 is subnetted, 1 subnets
O E2     172.16.0.0 [110/20] via 10.0.0.101, 00:00:06, Ethernet0/0
R102#sh ipv6 route
[ SNIP ]
OE2 2001:DB8:101::/64 [110/20]
     via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0

We can now see the network as an E2 route with a proper mask in both routing protocols.  I don’t like this solution, though, because I have a serious obsessive-compulsive disorder that won’t let me settle with having an internal route show up as external in OSPF.  Let’s try the other solution and see if we have any better luck.

OSPF Network-type

For this part of the experiment, I removed the redistribute commands and added the looback interface back into the routing processes.   When I manually configured the loopback interface as an OSPF point-to-point network, the networks were advertised as the network without being external.  No more nervous ticks caused by my OCD!

! R101 config
interface Loopback0
 ip address 172.16.0.1 255.255.255.0
 ip ospf network point-to-point
 ipv6 address 2001:DB8:101::1/64
 ipv6 ospf network point-to-point
 ipv6 ospf 1 area 0
end

R102#sh ip route
[ SNIP ]
172.16.0.0/24 is subnetted, 1 subnets
O        172.16.0.0 [110/11] via 10.0.0.101, 00:01:04, Ethernet0/0
R102#sh ipv6 route
[ SNIP ]
O   2001:DB8:101::/64 [110/11]
     via FE80::A8BB:CCFF:FE00:6500, Ethernet0/0

Send any type-2002 LSAs questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

OSPF

R102#show run
...
router ospf 1
log-adjacency-changes
redistribute connected subnets route-map SETTAG
network 192.0.2.0 0.0.0.255 area 0
!
route-map SETTAG permit 100
set tag 55555
...

R101#sh ip route 10.0.0.2
Routing entry for 10.0.0.0/24
Known via "ospf 1", distance 110, metric 20
Tag 55555, type extern 2, forward metric 10
Last update from 192.0.2.102 on Ethernet0/0, 00:00:13 ago
Routing Descriptor Blocks:
* 192.0.2.102, from 192.0.2.102, 00:00:13 ago, via Ethernet0/0
Route metric is 20, traffic share count is 1
Route tag 55555

EIGRP

R102#sh run
...
router eigrp 1
network 192.0.2.0
redistribute connected route-map SETTAG
no auto-summary
!
route-map SETTAG permit 100
set tag 55555
...

R101#sh ip route 10.0.0.2
Routing entry for 10.0.0.0/24
  Known via "eigrp 1", distance 170, metric 409600
  Tag 55555, type external
  Redistributing via eigrp 1
  Last update from 192.0.2.102 on Ethernet0/0, 00:00:14 ago
  Routing Descriptor Blocks:
  * 192.0.2.102, from 192.0.2.102, 00:00:14 ago, via Ethernet0/0
      Route metric is 409600, traffic share count is 1
      Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
      Route tag 55555

–
Corrections are encouraged.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

router bgp 123
 no synchronization
 bgp cluster-id 1
 neighbor 6.6.6.6 remote-as 123
 neighbor 6.6.6.6 route-reflector-client

—–
Comment with corrections, please.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

You can configure an EIGRP router to filter routes from being advertised or from being accepted.

Objective:  Filter out the route to 10.0.254.1/32 from being advertised to the rest of the network via EIGRP.

ip prefix-list PRE1 deny 10.0.254.1/32
ip prefix-list PRE1 permit 0.0.0.0/0 le 32
!
router eigrp 1
 distribute-list prefix PRE1 out

-- OR --

ip access-list standard ACL1
 deny 10.0.254.1 0.0.0.255
 permit any
!
router eigrp 1
 distribute-list ACL1 out

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Configuration

There's no new version of BGP for IPv6 here.  It's the standard BGP version 4 that we've all been using for years, but we're going to take advantage of the multiprotocol support (MPBGP, RFC 2858 RFC 4760).  We'll get to the differences in a second, but the first thing to do is to set up the BGP process as normal.  

Just as with the IGPs covered so far, the router ID needs to be set somehow.  Let's just manually set it for now.  We'll be routing on behalf of AS 65001.

Router(config)#router bgp 65001
Router(config-router)#bgp router-id 192.0.2.1

Since we're not using that archaic IPv4 any more, we need to disable IPv4 unicast, which is enabled by default when you configure MPBGP.

Router(config-router)#no bgp default ipv4-unicast

All is good so far?  Now comes the part that's different from your standard BGPv4 deployment with your ISP.  To enable the protocol for IPv6, we need to use the address-family directive.  This tells BGP which of the several protocols that you want to use in MPBGP.  We'll use IPv6, obviously; the others are well beyond our scope.

Router(config-router)#address-family ipv6

This will take your to the address family config mode which is where you can configure your neighbors and network statements just like you did in more traditional configurations of BGP.  A difference here is that you have to activate the neighbor before the address family is enabled for it.  Luckily, that's so easy I won't even explain it; I'm confident you can figure out which command does this.  Heh.  Let's peer with the router at fc00::2 using AS 65002 and advertise fc00:1::/64 to it, shall we?

Router(config-router-af)#neighbor fc00::2 remote-as 65002
Router(config-router-af)#neighbor fc00::2 activate
Router(config-router-af)#network fc00:1::/64

Piece of cake, right?

I've got to note that this is just one way to configure the IPv6 address family under MPBGP; there are other orders of command entry that can be used to get to the same config.  That's actually evident if you look at the config after your'e done.  

router bgp 65001
 bgp router-id 192.0.2.1
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor FC00::2 remote-as 65002
 !
 address-family ipv6
  neighbor FC00::2 activate
  network FC00:1::/64
 exit-address-family

You'll see that config items don't land in the order and place that you configured them.  The end results are the same.

Checking Our Work

First, let's see if we have a neighbor adjacency.  We're all used to running show ip bgp summary, but we're not running IPv4.  The equivalent is show bgp ipv6 unicast summary.  The whole unicast/multicast thing is beyond both the scope of this article and of my comfortable knowledge.  :)

Router#show bgp ipv6 unicast summary
BGP router identifier 192.0.2.1, local AS number 65001
BGP table version is 3, main routing table version 3
2 network entries using 304 bytes of memory
2 path entries using 152 bytes of memory
3/2 BGP path/bestpath attribute entries using 372 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 1) using 32 bytes of memory
BGP using 884 total bytes of memory
BGP activity 2/0 prefixes, 2/0 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
FC00::2         4 65002      15      15        3    0    0 00:10:29        1
Router#

We can see the neighbor is up and that we have a single prefix from that guy.  Let's check out exactly which route that is with the show bgp ipv6 unicast neighbor fc00::2 routes command.  That was a mouthful, eh?

Router#show bgp ipv6 unicast neighbors fc00::2 routes
BGP table version is 3, local router ID is 192.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> FC00:2::/64      FC00::2                  0             0 65002 i

Total number of prefixes 1
Router#

It looks like we have a route to fc00:2::/64 through that neighbor.  That's a good thing since we're trying to exchange routes.  The next question is whether we are sending any routes to the neighbor.  Run show bgp ipv6 unicast neighbor fc00::2 advertised-routes (even more of a mouthful!) to find out.

Router#show bgp ipv6 unicast neighbors fc00::2 advertised-routes
BGP table version is 3, local router ID is 192.0.2.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> FC00:1::/64      ::                       0         32768 i

Total number of prefixes 1
Router#

That looks right.  We're advertising the route to fc00:1::/64 just as we configured in our neighbor statement above.  We're on a roll!

Finally, let's check the routing table to make sure that route from the neighbor landed there.  Run show ipv6 route like we've done with the IGPs, and you should see prefix as a "B" like in the old days of IPv4.

Router#show ipv6 route
IPv6 Routing Table - 6 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
C   FC00::/64 [0/0]
     via ::, FastEthernet0/0
L   FC00::1/128 [0/0]
     via ::, FastEthernet0/0
C   FC00:1::/64 [0/0]
     via ::, FastEthernet0/1
L   FC00:1::1/128 [0/0]
     via ::, FastEthernet0/1
B   FC00:2::/64 [20/0]
     via FE80::C001:1FF:FE18:0, FastEthernet0/0
L   FF00::/8 [0/0]
     via ::, Null0
Router#

Well, there it is.  The only thing you may not have see is the concept of address families, but there's not much to that at all.  

Send any as-path prepends questions to me.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Configuration

As with all IPv6 routing protocols, the first thing we need to do is enable IPv6 unicast routing.

Router(config)#ipv6 unicast-routing

OSPFv3 also has the same router ID problem as EIGRP for IPv6 has, so we have to sort that out.  You can set the router ID either through a loopback interface with an IPv4 address on it or you can set it manually.  I'll just do it manually for now.  Let's use OSPF process ID 100.

Router(config)#ipv6 router ospf 100
Router(config-rtr)#router-id 192.0.2.1

Just like in OSPFv2 and in EIGRP for IPv6, we add interfaces to the routing protocol instead of using network statements; those don't exist in OSPFv3.  Let's assume you already have IPv6 addresses on interface f0/0 and you want that network in area 0.

Router(config)#interface f0/0
Router(config-if)#ipv6 ospf 100 area 0

You can see that it's really easy to add interfaces to different areas as well.

Checking Our Work

Just like we did yesterday, let's check to make sure the right interfaces are participating in the routing protocol.  We can do this with the show ipv6 ospf interface brief command.

Router#show ipv6 ospf interface brief
Interface    PID   Area            Intf ID    Cost  State Nbrs F/C
Fa0/1        100   0               5          10    BDR   1/1
Fa0/0        100   2               4          10    DR    0/0

You can see that we've got two FastEthernet interfaces in two different OSPF areas.  You can even see the state and neighbor count in the output.

That looks good, so let's check to see if we have any neighbors.  Of course, we already saw that we have one off of f0/1 from the output above, but just humor me and run show ipv6 ospf neighbors.

Router#sh ipv6 ospf neighbor

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
192.0.2.2         1   FULL/DR         00:00:31    5               FastEthernet0/1

That looks good to me. The other guy is a DR and is full adjacent with our router. Cool.

One last command shows us the routing table.  Can you guess what that command is without looking at the book?  Very good, class.  It's show ipv6 route.

Router#sh ipv6 route
IPv6 Routing Table - 6 entries
...
C   FC00:1::/64 [0/0]
     via ::, FastEthernet0/1
L   FC00:1::1/128 [0/0]
     via ::, FastEthernet0/1
C   FC00:2::/64 [0/0]
     via ::, FastEthernet0/0
L   FC00:2::1/128 [0/0]
     via ::, FastEthernet0/0
O   FC00:3::/64 [110/20]
     via FE80::C001:1CFF:FED0:1, FastEthernet0/1
OI  FC00:4::/64 [110/30]
     via FE80::C001:1CFF:FED0:1, FastEthernet0/1
L   FF00::/8 [0/0]
     via ::, Null0

Isn't that fancy?  We seem to have both an area router (the O route) and an inter-area route (the OI route).  We are ready for the big time now!

Send any tunnel broker recommendations questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

The config is quite easy and involves my favorite config item in all of Ciscodom – route-maps!  You create a route-map that sets the tag value and apply it to the redistribution.  There are a few ways to skin this cat, but I'll use an outbound distribute-list here.  Here's the config save the basics for getting EIGRP going.

route-map TAGIT permit 100
 set tag 2000
!
router eigrp 1
 redistribute static
 distribute-list route-map TAGIT out
!
ip route 172.16.0.0 255.255.255.0 Null0

If you do a show ip route on one of the other routers, you can see the tag that has been applied.  Check out the last line of the output.

R1#sh ip route 172.16.0.1
Routing entry for 172.16.0.0/24
  Known via "eigrp 1", distance 170, metric 28160
  Tag 2000, type external
  Redistributing via eigrp 1
  Last update from 192.168.0.2 on FastEthernet0/0, 00:00:09 ago
  Routing Descriptor Blocks:
  * 192.168.0.2, from 192.168.0.2, 00:00:09 ago, via FastEthernet0/0
      Route metric is 28160, traffic share count is 1
      Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
      Route tag 2000

Remember that you can only tag routes external to the AS.  That means you can't have a router tag all the internal routes (which may be a cool thing to be able to do).  You can, however, tag any route that is redistributed – including another EIGRP AS. 

Tags are also used in OSPF and BGP.  Our MPLS provider actually tags the routes they distribute to us with their BGP AS number.

Send any infinite-hop routes questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Your first thought is probably to use the old fashioned floating static route where you have a weighted route that takes over if the primary route is withdrawn from the routing table.  That only works if the next-hop of that route is no longer available…like when serial interface goes down and the next-hop isn't directly connected any more.  This is Ethernet, though, so there's no way for the firewall doesn't know or doesn't care if a host on the network isn't there any more.  This config has another problem, too.  What about a scenario where the ISP's router is up, but it's interfaces are down?  How about if there are routing issues farther upstream?  You surely don't want to send traffic to a provider's router is the provider is having issues, right?  

If you've ever tried to do something similar on an IOS router, then you've probably done IP SLA.  An ASA has the same functionality, but it's just called SLA monitoring.  You wind up with a config that is a very similar to IP SLA stuff on IOS routers, actually.  I wrote a terrible blog post about it a few years back, and several other bloggers talk about it as well, but the idea is that you have a process, called an SLA monitor on the ASA, that monitors an IP address by pinging it.  You then create a track object that watches the monitor's status.  This track object is applied to a static route, and, if the SLA monitor fails, the route is removed from the routing table.  We've all done something like this with HSRP tracking, so this shouldn't be totally foreign.

Let's take a look at the test network that I've used to simulate the setup at the customer site.

The test is to have INSIDE1 communicate with TARGET.  Each ISP knows where TARGET is through a huge EIGRP AS, but we want to detect any routing problems on ISP1.  If we find a problem, we want to roll over to ISP2 on the BACKUP interface.  What do we monitor, though?  We can monitor the IP of the ISP's router at the data center, but we'd miss any issues upstream.  Let's monitor the IP of the second router on ISP1, which is 10.0.0.2.  In the real world, we'd fine a host somewhere deep on the Intertubes that we think won't go down very often.  In our test, 10.0.0.2 is the closest thing we can find to that.

Let's create a beautiful symphony of ICMP generation.  First, we create the SLA monitor.

sla monitor 1
 type echo protocol ipIcmpEcho 10.0.0.2 interface OUTSIDE
!
sla monitor schedule 1 life forever start-time now

I think you can see that we are creating an ICMP echo process that will ping 10.0.0.2 on the OUTSIDE interface.  The third line is what controls the start and stop of the process; in this case, we start now and don't ever finish thanks to the word forever.  We can't use the SLA monitor directly on our routes, so let's create a track object.

track 100 rtr 1 reachability

Now we have track object 100 that looks to SLA monitor 1 for reachability.  We apply this to the route just like we do on IOS.  We'll go ahead and add the weighted route as well.

route OUTSIDE 0.0.0.0 0.0.0.0 192.0.2.1 1 track 100
route BACKUP 0.0.0.0 0.0.0.0 192.0.2.129 240

Now the default will go through 192.0.2.1 until 10.0.0.2 is unreachable.  If that happens, the route is removed from the routing table, and the weighted default route will take over.  That's all you need.  Of course, I would create another track object for ISP2 so you can at least get a syslog message or SNMP trap if a problem happens over there, but you can probably get away with just the one.

If you've ever done IP SLA on a router, you would call me on the fact that there's some stuff missing.  If you don't force the ICMP packets to ISP1's router, the state of the SLA monitor will keep flopping; you flip to ISP2, the SLA check is healthy again, you flip back, the SLA check dies again…ad nauseum.  That's not the case for the ASA, actually.  Even though the default route has rolled over to the backup, the monitoring process continues to send requests to the old gateway.

Sometime I like it when my gear knows what I'm trying to do; this is one of those times.

Send any stray ICMP packets questions my way.

Audio Commentary

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

If you remember, I took it over a week ago and had some bad luck on it.  Alright, bad luck is the wrong phrase.  I didn’t study enough and failed it.  This time, though, I had a special weapon on my side – the ROUTE Foundations book.  I haven’t used the Foundations books before, but, I saw some tweets about this one, so I picked it up off of Safari.  In just a couple pages, I realized that I was reading the answers to several questions directly out of the book.  It was amazing.  I only studied my weak points and wound up with 144 more points than I did last time.  I can’t say that was entirely because of the book, but I must say it was a big reason.

The test, like last time, was actually really good.  The questions were well-written and clear for the most part.  There were, of course, some that were confusing, but there weren’t any traps like you usually see in the other tests.  A couple asked you to do contradictory things.  There were a couple that just blasted you with information, but, if you read the question and know the material, the answer just pops right out at you.  Overall, another great test.  That makes 2 I’ve taken…and they’re both the 642-902.  :)

I’m quite excited about finishing up.  I’ve had a lot of failures along the way, but the support from the online community has been tremendous.  Thanks to everyone who kept pushing me and telling me I could do it.  I’m also happy to report that I kept the testing costs below the cost of the CCIE lab (barely) and that I may hold the record for number of P-level tests (8 P-levels tests and 10 overall) and overall Cisco test questions answered (535 questions).  What an honor.  *denotes sarcasm*

So, what’s next?  I think I’m going to take a month or two off from networking to study up for a ham radio license.  We get a lot of hurricanes down here, and having a good radio around will help us and the community out if such a disaster happens.  I’m calling it prep for CCIE-Wireless.  Heh.  When I get done with that, I either plan on hitting up the CCIE-R&S or going down the CCDP track.  I’m not really sure, but we’ll see when we get there.

Don’t worry.  The blog will stay network-related.  With the feedback from the study questions format, I think I’ll start a problem question and answer format.  I’m also thinking of generating scenarios to work through.  Again, we’ll see when we get there.

Send any trips to Delaware questions my way.

Audio Commentary:

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Study Questions

• I’ve got IGRP and EIGRP both configured with the same AS number.  What’s special about this configuration?

If both use the same AS number, then they automatically redistribute their routes into each other without using the redistribute command.

• When redistributing one IGP into another, where’s a good place to filter routes?

There’s no one good place, but at the router(s) that’s doing the redistribution is a good start.  There’s no need to send an IGP a bunch of routes it doesn’t need.

• When redistributing one IGP into another, where’s a good place to summarize routes?

There’s no one good place, but that may be best done at the router just inside the redistributing router.  If the redistributing router only sees the summary route, that’s what it will pass to the other IGP.

• What’s the default metric of RIP?

That’s infinity, so it’s unreachable with an explicit metric.

• I’ve redistributed OSPF into RIP, but I don’t see my subnets there.  What gives?

RIP automatically summarized routes, so look for summaries instead of specific subnets.

• How can you limit the number of routes redistributed into EIGRP or OSPF?

Use the redistribute maximum-prefix X directive under the routing protocol, where X is the maximum number of routes.

• What are the metrics of connected routes when redistributed into EIGRP?

Those routes take the metric of the associated interface instead of using the metric you gave to the redistribution.  [This seems fishy at best.  Can anyone help clarify, please?]

• I have 845734928 interfaces on my router, but I only want to use 3 of them for EIGRP and only want to configure a single network statement.  What’s the easiest way to do that?

Set all the interfaces as passive with the passive-interface default router subcommand.  Next, make all your interesting interfaces non-passive with the no passive-interface X subcommand.  Now you can configure network 0.0.0.0 255.255.255.255 to match all the interfaces, but only the interesting interfaces will participate.

• What is the term for the rank of trustworthiness a routing protocol provides?

Administrative distance

• How can I change the AD of external EIGRP routes to 201 while keeping the default AD for internal EIGRP routes?

Router1(config-router)#distance eigrp 90 201
You have to set both, so you’ll have to remember that EIGRP has an AD of 90 for internal routes by default.

• How can I change the AD of OSPF routes to 192.168.0.0/24 to 202?

Router1(config)#access-list 88 permit 192.168.0.0 0.0.0.255
Router1(config)#router ospf X
Router1(config)#distance 202 0.0.0.0 255.255.255.255 88

• Is it possible to set the AD of different OSPF routes types like intra-area and interarea?

Yes.  You can give it the old distance ospf inter-area X to change the AD.  It also works for intra-area and external routes.

• Is it possible to set the AD of an external OSPF route to 192.168.100.0/24 to 202 without changing the others?

I would have though you could use a route-map for that, but I can’t find a proper set command in a route-map.  [A little help, please.]

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts