From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Sat Aug 27 2005 - 16:04:34 GMT-3
Imal,
With the test you performed, you would not see any difference in the
routing tables, nor in a show of the OSPF database, you have to dig a
little deeper. You have to look at where the forwarding address is
stored.
Perhaps the following example will illustrate this command's use.
R5------R3-------R2
R5 has 100.100.100.0/24, 200.200.200.0/24 and 130.130.130.0/24
redistributed from connected loopbacks in to OSPF. R5 to R3 is the NSSA
and R3 to R2 is the backbone area 0.
The relevant basic config is as follows (R3 to R5 is on the 172.16.136.0
subnet and R2 to R3 is on the 172.16.32.0 subnet):
R5
router ospf 1
log-adjacency-changes
area 35 nssa
redistribute connected subnets route-map loops
network 172.16.136.5 0.0.0.0 area 35
!
ip classless
no ip http server
!
!
access-list 1 permit 100.100.100.0 0.0.0.255
access-list 1 permit 200.200.200.0 0.0.0.255
access-list 1 permit 130.130.130.0 0.0.0.255
!
route-map loops permit 10
match ip address 1
R3
router ospf 1
log-adjacency-changes
area 35 nssa
network 172.16.32.3 0.0.0.0 area 0
network 172.16.136.3 0.0.0.0 area 35
R2
router ospf 1
log-adjacency-changes
network 172.16.32.2 0.0.0.0 area 0
Router2#sho ip ospf data external 100.100.100.0
OSPF Router with ID (192.168.2.2) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 103
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 100.100.100.0 (External Network Number )
Advertising Router: 192.168.3.3
LS Seq Number: 80000001
Checksum: 0xF7C1
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 172.16.136.5
External Route Tag: 0
This shows us the forwarding address for this external route is R5,
which is OK, as we have an inter area route to that prefix on R2.
Router2#ping 100.100.100.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
!!!!!
But supposing we had a big network and wanted to reduce the number of
routes the backbone had to carry from stub areas, so let's stop R3 from
advertizing the 172.16.136 subnet using the following:
R3(config-router)#area 35 range 172.16.0.0 255.255.0.0 not
The routing table on R2 no longer has an entry for 172.16.136.0, and
because of this, the 100.100.100.0 subnet will be present in the link
state database, but will not be present in the routing table. If a
router does not have an inter or intra area route to the forwarding
address of an external route, it will not be inserted in the routing
table. So if I try to ping 100.100.100.100, it fails.
Router2#ping 100.100.100.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Now I enter the following on R3 and look at the database on R2 and
perform the same ping.
R3(config-router)# area 35 nssa translate type7 suppress-fa
Router2#sho ip ospf data external 100.100.100.0
OSPF Router with ID (192.168.2.2) (Process ID 1)
Type-5 AS External Link States
Routing Bit Set on this LSA
LS age: 23
Options: (No TOS-capability, DC)
LS Type: AS External Link
Link State ID: 100.100.100.0 (External Network Number )
Advertising Router: 192.168.3.3
LS Seq Number: 80000003
Checksum: 0x926F
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
Router2#ping 100.100.100.100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.100.100.100, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/36/60 ms
By suppressing the forwarding address, as shown by the value being
0.0.0.0 rather than 172.16.136.5, the route to 100.100.100.0 can now be
inserted in the routing table and traffic to the external route can now
be forwarded. The route on R2 to the 172.16.136.0. subent is still
missing, but it does not need it to reach R5, it just needs to know to
get the packet to R3, and R3 will handle it from there.
Chris
________________________________
From: Imal kalutotage [mailto:imal.kalutotage@gmail.com]
Sent: Saturday, August 27, 2005 11:12 AM
To: Chris Lewis (chrlewis)
Cc: Montiean; ccielab@groupstudy.com
Subject: Re: nssa translate type7 suppress-fa
Hi chris,
As Montiean mentioned, I also experience the same problem..
I went through ur mail 7 also the doc cd.but still I cannot get it
right
My setup is like this
R2--------R3---------R4
area 0 area 34
area 34 is configured as nssa.
i am redistributing a loopback from R4.
Then I removed area nssa command from R3 (ABR for area 34)
& put the following command on R3
Then clear the ospf
area 34 nssa translate type7 suppress-fa
But I cannot see any diffrence in the routing table or the ospf database
on R2
It still shows the forwarding address in it's database..
So effectively I am not seeing any affect on this command..
it it a bug or am I missing something here?
Cheers
imal
On 8/25/05, Chris Lewis (chrlewis) <chrlewis@cisco.com> wrote:
Hi,
I think the first step is to understand what the forwarding
address is,
what it is used for and then look at why suppressing it may be
beneficial.
Starting from the position that NSSA is there to allow the
injection of
external routes from a stub area to the backbone, we know that
the NSSA
area will have type 7 LSAs in it that represent the external
prefixes
being injected. These will be translated at the NSSA ABR to type
5s. The
NSSA ABR has to tell the backbone routers how to reach these
external
prefixes, so there are two choices, either the NSSA ABR
propagates the
actual address of the router injecting these external routes, or
the
NSSA router sends a default in to the backbone and says contact
me to
get to these external routes and I will take it from there. The
address
of the injecting router or the default, is advertized as the
forwarding
address in the external LSA.
So you end up with two choices. If you propagate all the NSSA
routes in
to the backbone, there is no need to suppress the forwarding
address.
However if you do not advertize all the NSSA internal routes in
to the
backbone, you will need to ensure the forwarding address is
suppressed
as the backbone routers will not know how to get to the
injecting
router.
In either case, the suppress fa command has nothing to do with
suppressing the routes from the NSSA in to the backbone, you
have to
figure that out separately J but what it does is alter the value
of the
forwarding address in the external LSA.
It is also worth noting the conditions necessary for a router to
install
an external LSA in to the routing table. Basically a router
needs to see
the ASBR (the one injecting the external route of interest) via
an intra
or inter area route AND the forwarding address must be known via
an
intra or inter area route.
In many cases you will see 0.0.0.0 as the forwarding address
already
with the sho ip ospf database external A.B.C.D command. I
recommend you
try out some configs with your setup to see when you get 0.0.0.0
or the
injecting router IP as the forwarding address and that should
clear
things up.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf Of
Montiean
Sent: Saturday, August 20, 2005 10:29 PM
To: ccielab@groupstudy.com
Subject: nssa translate type7 suppress-fa
Hi,
Someone please explains me about this command "nssa translate
type7
suppress-fa". From cisco
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hi
rp_c/
ch15/hoadsup.htm
Per my understanding, forwarding addresses in type7 will be set
to
0.0.0.0 into Type-5 LSAs. I lab it up but couldn't see any thing
change
rather than under nssa ABR saying below
Perform type-7/type-5 LSA translation, suppress
forwarding
address
I also found CSCec72160 in mainline 12.3 advise to take off area
nssa
command and put it back in with "nssa translate type7 suppress"
But it
didn't work for me.
My lab setup is r6 ----area0 ----- r4 ---- area147(nssa)
-------r1-----rip----- r2.
So I redistributed rip into r1 and use suppress-fa at r4. r6
still
seeing all the addresses advertised from rip.
I just want to understand why we use this command, cisco page
does not
explains clearly for me or I miss understand some thing. I
appreciate
any feedback on this question.
--Montiean
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:20 GMT-3