نمایش نتایج: از شماره 1 تا 2 از مجموع 2

موضوع: OSPF Type-4 LSA & The Forward-Address

  
  1. #1
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

    OSPF Type-4 LSA & The Forward-Address

    کد:
    http://blog.ipexpert.com/2009/11/04/ospf-type-4-lsa-the-forward-address-part-1/

    PART-1


    Welcome back everybody! Today we will be taking a look at some more often misunderstood topics in the world of OSPF. Hopefully, by the end of this two part blog we will have a much clearer view of the dreaded Type-4 LSA. What exactly is it? Who actually generates it and why? Check out the diagram below to get a feel for what we will be working with tonight! In part 1 of this blog, we will take a look at the Type-4 LSA. In part 2 we will dig a bit deeper and look more closely at the forward-address and different situations where it may be altered.



    We have a very basic setup here: OSPF running between three different areas, and mutual redistribution happening on R6, making it the ASBR. All routers in the topology have a loopback0 address of x.x.x.x where x is the router #. Additionally, R6 has the loopback66 interface 66.66.66.66 but that address is NOT being advertised into OSPF. Because 66.66.66.66 is the highest loopback address it is R6’s RID, but NOT a reachable IP address from any of the other routers.

    Let’s talk about the ASBR and the type-4 LSA. This is a topic that seems to confuse many people. Doing a quick Google search will turn up plenty of results claiming that a type-4 LSA is generated by the ASBR. This is simply not true. The type-4 LSA is generated by an ABR. The purpose of it is simply to inform other areas of next-hop information for the ASBR. In other words, it is injected into other areas by the ABR so that routers in other areas know how to get to external routes through the ASBR. Let’s take a look at this on our equipment here. R6 is the ASBR because it is redistributing into OSPF. As you can see below, NO Type-4 LSA is injected into area 56 – there would be no reason for it. Any routers that receive external routes inside of area 56 already know how to get to the ASBR because it is inside of area 56. R5 for instance knows how to get to the ASBR because it already has a Type-1 LSA for R6 within area 56. It knows all about RID 66.66.66.66. On the other hand, a Type-4 LSA is indeed injected into the backbone and into area 12 by their respective ABRs. Why? When routers inside area 0 or area 12 receive an external Type-5 LSA, the advertising router information for that external route is going to point to the RID of the ASBR, R6 (66.66.66.66). A router inside of area 0 or area 1 like R1 has no idea how to get to that RID, so it needs the Type-4 LSA to tell it how.

    R5 has an O E2 route to 7.7.7.7 redistributed in to OSPF from RIP…
    کد:
    R5#sh ip route ospf | i 7.7.7.7
    O E2    7.7.7.7 [110/20] via 56.56.56.6, 00:32:28, FastEthernet0/0
    Notice that there is no asbr-summary LSA (Type-4) in Area 56…only Area 0. Additionally, notice that the advertising router of the Type-4 LSA being injected into area 0 is R5, the ABR and NOT R6 the ASBR.
    کد:
    R5#sh ip ospf database asbr-summary
    
                OSPF Router with ID (5.5.5.5) (Process ID 1)
    
                    Summary ASB Link States (Area 0)
    
      LS age: 1962
      Options: (No TOS-capability, DC, Upward)
      LS Type: Summary Links(AS Boundary Router)
      Link State ID: 66.66.66.66 (AS Boundary Router address)
      Advertising Router: 5.5.5.5
      LS Seq Number: 80000001
      Checksum: 0x717
      Length: 28
      Network Mask: /0
            TOS: 0  Metric: 1
    Now take a look at things from R1’s perspective…
    کد:
    R1#sh ip route ospf | i 7.7.7.7
    O E2    7.7.7.7 [110/20] via 12.12.12.2, 00:47:02, FastEthernet0/0
    
    R1#sh ip ospf data external 7.7.7.7
    
                OSPF Router with ID (1.1.1.1) (Process ID 1)
    
                    Type-5 AS External Link States
    
      Routing Bit Set on this LSA
      LS age: 1627
      Options: (No TOS-capability, DC)
      LS Type: AS External Link
      Link State ID: 7.7.7.7 (External Network Number )
      Advertising Router: 66.66.66.66
      LS Seq Number: 80000002
      Checksum: 0xDE9B
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 0.0.0.0
            External Route Tag: 0
    So the advertising router is R6, the ASBR. Without the Type-4 LSA we would not know how to get to that router…Type-4 LSA to the rescue…
    کد:
    R1#sh ip ospf data asbr-summary
    
                OSPF Router with ID (1.1.1.1) (Process ID 1)
    
                    Summary ASB Link States (Area 12)
    
      Routing Bit Set on this LSA
      LS age: 875
      Options: (No TOS-capability, DC, Upward)
      LS Type: Summary Links(AS Boundary Router)
      Link State ID: 66.66.66.66 (AS Boundary Router address)
      Advertising Router: 12.12.12.2
      LS Seq Number: 80000002
      Checksum: 0xF0D9
      Length: 28
      Network Mask: /0
            TOS: 0  Metric: 65
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 0.0.0.0
            External Route Tag: 0
    The route we wish to get to from R1 (7.7.7.7) is being advertised from the ASBR with RID 66.66.66.66. The Type-4 LSA tells us how to get to that 66.66.66.66 RID. Notice again that the advertising router of the Type-4 LSA is indeed the Area 12 ABR R2. The forward address is set to 0.0.0.0. This may seem a bit concerning but it is normal. The forward address being 0.0.0.0 just means that the next-hop of that LSA is the router that originated it. In this case, the advertising router for the Type-4 LSA is R2 with address 12.12.12.2. We know how to get to 12.12.12.2 so everything is fine!

    The entire idea of the Type-4 LSA brings up another interesting point. Would I have it in a stub area? How about a totally stubby area? What about an NSSA or totally stubby NSSA? Well, let’s think about it. What was the point of the Type-4 LSA? To tell us reachability information for external routes right? Stub areas by definition do not allow Type-5 external LSAs. Therefore, there would be not purpose to have a Type-4 LSA injected into the area. If we can’t receive external routes, why would we need information about how to get to the originator of those external routes? We can see this by modifying the above topology slightly. Let’s make area 12 a stub area and see what happens.
    کد:
    R1(config)#router ospf 1
    R1(config-router)#area 12 stub
    R1(config-router)#
    *Sep 29 20:12:35.695: %OSPF-5-ADJCHG: Process 1, Nbr 12.12.12.2 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
    R1(config-router)#
    *Sep 29 20:12:51.143: %OSPF-5-ADJCHG: Process 1, Nbr 12.12.12.2 on FastEthernet0/0 from LOADING to FULL, Loading Done
    
    R2(config)#router ospf 1
    R2(config-router)#area 12 stub
    R2(config-router)#
    *Sep 29 20:17:34.135: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet1/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset
    R2(config-router)#
    *Sep 29 20:17:37.015: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet1/0 from LOADING to FULL, Loading Done
    
    R1#sh ip route 7.7.7.7
    % Network not in table
    
    R1#sh ip ospf database asbr-summary
    
                OSPF Router with ID (1.1.1.1) (Process ID 1)
    Nada…zilch, nothing, YOU LOSE SIR! YOU GET NOTHING! As we can see above, changing area 12 to a stub area causes both the external route to 7.7.7.7 and the Type-4 LSA to disappear completely. It only makes sense…a stub area does not allow external routes. Because we do not allow any external routes, we have no need for next-hop reachability information for those routes.

    Hopefully this article has helped some people out there better understand the Type-4 LSA. Keep in mind, everything done in this blog post was done without any kind of Not-So-Stubby-Areas configured. When configuring NSSA, things can change due to the Type-7 / Type-5 LSA conversion done on the ABR as well as how exactly the ASBR decides to set its forward-address which depends on certain variables. We will take a look at that in part 2 : ) Until next time…keep studying hard!

    Joe Astorino CCIE #24347 (R&S)
    Sr. Technical Instructor – IPexpert





    موضوعات مشابه:





  2. #2
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://blog.ipexpert.com/2009/11/11/ospf-type-4-lsa-the-forward-address-part-2/

    PART-2



    Welcome back everybody! Today we will be continuing our discussion on some of the internals of OSPF Type-4 LSAs and the forwarding-address. We will also be discussing an interesting feature known as forward-address suppression and see how it can actually dramatically change the flow of our traffic in OSPF. The diagram we will be working on is similar to the one used for part 1 of this blog, but modified to make it a bit more…interesting?





    Notice that area 56 and area 65 are both NSSA. Here is a quick summary of what we are actually doing here with all this routing madness. R7 has a loopback of 7.7.7.7/32 which it only advertises into RIP. This RIP route will get redistributed into OSPF at R6 and injected into both area 56 and area 65 as a Type-7 LSA. R5 being the ABR will then convert the Type-7 LSA to a Type-5 LSA and inject it into the backbone. The fun and magic will come with the specifics and exactly what is happening behind the scenes.


    The first thing we should understand is how things happen and look during normal redistribution into a regular old area – without all the NSSA area madness. To demonstrate this quickly, lets add loopback22 on R2 and redistribute it into OSPF. This should make R2 an ASBR, and we can see exactly how the LSA looks.
    کد:
    R2(config)#int lo22
    R2(config-if)#ip add 22.22.22.22 255.255.255.255
    R2(config-if)#route-map OSPF-Connected 10
    R2(config-route-map)#match int lo22
    R2(config-route-map)#router ospf 1
    R2(config-router)#red conn sub route-map OSPF-Connected
    Excellent…let’s see what that LSA looks like on R1 inside of area 12.
    کد:
    R1#sh ip ospf data ext 22.22.22.22
    
                OSPF Router with ID (1.1.1.1) (Process ID 1)
    
                    Type-5 AS External Link States
    
      Routing Bit Set on this LSA
      LS age: 219
      Options: (No TOS-capability, DC)
      LS Type: AS External Link
      Link State ID: 22.22.22.22 (External Network Number )
      Advertising Router: 2.2.2.2
      LS Seq Number: 80000001
      Checksum: 0xB38C
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 0.0.0.0
            External Route Tag: 0
    OK. So what is going on here? R2 has become an ASBR. We see that R2 is the advertising router for the prefix 22.22.22.22/32 as expected. The thing we want to pay attention to here is the Forward Address. It is set to 0.0.0.0. What this means is that R1 will forward traffic for this prefix to the router that originated it – R2. Simple. Now, we will revert the config and see what happens with redistribution into a NSSA.
    کد:
    R2(config-router)#no redistribute conn
    Now we will head over to R6 and see how things look when we redistribute RIP into the NSSAs.
    کد:
    R6(config-router)#router ospf 1
    R6(config-router)#redistribute rip subnets
    
    R5(config-router)#do sh ip route | i 7.7.7.7
    O N2    7.7.7.7 [110/20] via 56.56.56.6, 00:00:01, FastEthernet0/0.56
    
    R5(config-router)#do sh ip ospf data nssa 7.7.7.7
    
                OSPF Router with ID (5.5.5.5) (Process ID 1)
    
                    Type-7 AS External Link States (Area 56)
    
      Routing Bit Set on this LSA
      LS age: 9
      Options: (No TOS-capability, Type 7/5 translation, DC)
      LS Type: AS External Link
      Link State ID: 7.7.7.7 (External Network Number )
      Advertising Router: 66.66.66.66
      LS Seq Number: 80000002
      Checksum: 0x77E0
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 6.6.6.6
            External Route Tag: 0
    
                    Type-7 AS External Link States (Area 65)
    
      LS age: 91
      Options: (No TOS-capability, Type 7/5 translation, DC)
      LS Type: AS External Link
      Link State ID: 7.7.7.7 (External Network Number )
      Advertising Router: 66.66.66.66
      LS Seq Number: 80000001
      Checksum: 0xCDD9
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 65.65.65.6
            External Route Tag: 0
    There are a few important things to note here. First off, we are receiving TWO NSSA Type-7 LSAs for the 7.7.7.7/32 prefix. This is normal and expected as we have two NSSA (area 56 and area 65). Notice the Type 7/5 translation is set. This means R6 is setting a bit in the LSA that instructs R5 (the ABR) to translate the NSSA Type-7 LSA into an external Type-5 LSA and inject it into the backbone. This is known as the P bit, and is set by default by the ASBR when it redistributes routes into an NSSA. We’ll also notice a significant change from the first example. The forwarding address for both Type-7 LSAs is no longer 0.0.0.0. The forward address is set to R6 in both cases. The rules for what you set the forward address to are outlined in RFC 3103. In summary, first it will choose the highest loopback that is on the ASBR and that is also being advertised into the area. If there is no loopback, it will go with the highest interface that is running OSPF and also advertised into the NSSA. This is why we see 6.6.6.6 for the first LSA and 65.65.65.6 for the second. 6.6.6.6 is a loopback on R6 and it is being advertised into NSSA 56. 65.65.65.6 is the highest available address on R6 that is participating in area 65. The question then becomes if we have two Type-7 LSAs with two different forward address values, which one gets injected into area 0? Let’s check out R2 for the answer.
    کد:
    R2(config-router)#do sh ip ospf data ext 7.7.7.7
    
                OSPF Router with ID (2.2.2.2) (Process ID 1)
    
                    Type-5 AS External Link States
    
      Routing Bit Set on this LSA
      LS age: 875
      Options: (No TOS-capability, DC)
      LS Type: AS External Link
      Link State ID: 7.7.7.7 (External Network Number )
      Advertising Router: 5.5.5.5
      LS Seq Number: 80000010
      Checksum: 0x1D2C
      Length: 36
      Network Mask: /32
            Metric Type: 2 (Larger than any link state path)
            TOS: 0
            Metric: 20
            Forward Address: 6.6.6.6
            External Route Tag: 0
    There we have it. 6.6.6.6 won. Why? The first thing the router will do is check the metrics to those multiple forward addresses. In this case the metric will be 20 to both 6.6.6.6 and 65.65.65.6 because they are O N2 routes. Since the metric is tied, we go with lowest address. Another thing to be aware of here is that R5 is no longer just an ABR between area 0 , area 56 and area 65. It is now an ASBR as well because it is now generating Type-5 LSAs and injecting them (thats what an ASBR does by definition.) Therefore, some interesting things happen regarding our Type-4 LSA. Let’s look at R2.
    کد:
    R2(config-router)#do sh ip ospf data asbr
    
                OSPF Router with ID (2.2.2.2) (Process ID 1)
    
                    Summary ASB Link States (Area 12)
    
      LS age: 1444
      Options: (No TOS-capability, DC, Upward)
      LS Type: Summary Links(AS Boundary Router)
      Link State ID: 5.5.5.5 (AS Boundary Router address)
      Advertising Router: 2.2.2.2
      LS Seq Number: 80000006
      Checksum: 0xD00A
      Length: 28
      Network Mask: /0
            TOS: 0  Metric: 64
    Pay very close attention. The Type-4 LSA is ONLY present in area 12. There are NO Type-4 LSAs being injected into area 0. How then do routers inside of area 0 know how to get to R6 for routes like 7.7.7.7? They will go to R5 since R5 is now acting as an ASBR as well and actually is the one generating the LSAs going into area 0. Everybody in area 0 already knows how to get to R5s RID because R5 is itself part of area 0! In area 12 however, we still will need the Type-4 LSA because routers in area 12 know nothing about R5’s RID as it is in a separate area.


    So far we have seen that the behavior of the forward address parameter is different depending on if you are redistributing into a normal area or a NSSA. Furthermore, we saw a little deeper into how the Type-4 LSA works. Now we will go further down the rabbit hole hehe…Since 6.6.6.6 won the battle on R5 for the right to be sent as the forward address into area 0, we should see 6.6.6.6 set as the forward address of the Type-5 external LSA on R1 and R2. Let’s check R1…
    کد:
    R1#sh ip ospf data ext 7.7.7.7 | i Forward
            Forward Address: 6.6.6.6
    Just as expected. Essentially this is saying “If you want to get to 7.7.7.7 you need to contact the ASBR over at 6.6.6.6.” In order for us to actually install the route in our routing table we need a valid intra or inter-area route for 6.6.6.6. Currently we have 6.6.6.6/32 as an inter-area route so we are golden. That means our ping traffic should go from R1 –> R2 –> R5 –> R6 –> R7
    کد:
    R1#ping 7.7.7.7
    
    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
    !!!!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/8 ms
    
    R1#trace 7.7.7.7
    
    Type escape sequence to abort.
    Tracing the route to 7.7.7.7
    
      1 12.12.12.2 0 msec 0 msec 0 msec
      2 25.25.25.5 0 msec 0 msec 0 msec
      3 56.56.56.6 4 msec 4 msec 4 msec
      4 67.67.67.7 4 msec *  0 msec
    So far so good! NOW…can we influence what the forward address gets set to? The answer is yes we can, and in multiple ways. We have already seen that the Type-7 LSA on R5 with the best metric to the ASBR will win the battle and be injected into the backbone. Take a look:
    کد:
    R5(config-router)#do sh ip ospf int brie
    Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
    Lo0          1     0               5.5.5.5/32         1     LOOP  0/0
    Se0/2/0      1     0               25.25.25.5/24      64    P2P   1/1
    Fa0/0.56     1     56              56.56.56.5/24      1     DR    1/1
    Fa0/0.65     1     65              65.65.65.5/24      10    DR    1/1
    
    R5(config-router)#do sh ip ospf border
    
    OSPF Process 1 internal Routing Table
    
    Codes: i - Intra-area route, I - Inter-area route
    
    i 2.2.2.2 [64] via 25.25.25.2, Serial0/2/0, ABR, Area 0, SPF 17
    i 66.66.66.66 [1] via 56.56.56.6, FastEthernet0/0.56, ASBR, Area 56, SPF 15
    i 66.66.66.66 [10] via 65.65.65.6, FastEthernet0/0.65, ASBR, Area 65, SPF 14
    Did you catch the cost difference? Fa0/0.56 has a cost of 1 while Fa0/0.65 has a cost of 10. Because Fa0/0.56 has the lower metric to get to the ASBR we advertise the forward address as whatever we learned on Fa0/0.56 (6.6.6.6). What if we change things around?
    کد:
    R5(config-router)#int fa0/0.56
    R5(config-subif)#ip ospf cost 10
    R5(config-subif)#int fa0/0.65
    R5(config-subif)#ip ospf cost 1
    
    R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward Address
            Forward Address: 65.65.65.6
    By simply modifying the cost of a link, we have altered where things should be heading! In this case it won’t really affect the routing path, but in certain situations it could. Are there other things we can do? Of course! The second thing we can do is this: If you make the interface on the ASBR (R6) that is facing the outside AS (RIP in this case) part of the OSPF process itself, things will change as well.
    کد:
    R6(config-if)#router ospf 1
    R6(config-router)#pass def
    R6(config-router)#no pass fa0/0.56
    R6(config-router)#no pass fa0/0.65
    R6(config-router)#network 67.67.67.6 0.0.0.0 area 65
    What we should see at this point is that on R5 and thus R1 and R2 the forward address is now set to R6’s interface facing the RIP domain!
    کد:
    R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
            Forward Address: 67.67.67.6
    This makes things veeeeeeerrrrry interesting! Right now, we have a route to 67.67.67.6 via R5, so things would not really be altered. What if we knew about 67.67.67.6 another way though? Let’s advertise the 67.67.67.0/24 network into OSPF on R7. Keep in mind this means that we are advertising the same prefix into two different areas at the same time – On R6 we are injecting it into area 56 and on R7 we are injecting it into area 0. This means that from the perspective of R2 we will prefer the route from R7 over VLAN 27. It is an intra-area route VS an inter-area route from area 56.
    کد:
    R7(config-if)#int fa0/0
    R7(config-if)#ip ospf 1 area 0
    Check things out on R6…
    کد:
    R2(config-router)#do sh ip route | i 67.67.67.0
    O       67.67.67.0 [110/2] via 27.27.27.7, 02:27:31, FastEthernet1/1
    Guess what? The 7.7.7.7/32 still has a forward address of 67.67.67.6. We now know about 67.67.67.6 through another path over VLAN 27. In theory, we just completely altered the path of our packets through the network! Watch this…
    کد:
    R1#sh ip ospf data ext 7.7.7.7 | i Forward
            Forward Address: 67.67.67.6
    
    R1#trace 7.7.7.7
    
    Type escape sequence to abort.
    Tracing the route to 7.7.7.7
    
      1 12.12.12.2 0 msec 4 msec 0 msec
      2 27.27.27.7 4 msec *  0 msec
    WOW! Look at that! We are now taking the path R1 –> R2 –> R7 instead!!! Now here is the REAL kicker. There is a little known feature in OSPF known as forward-address suppression and it is specific for NSSA ABRs. Imagine what would happen if R1 and R2 had no way to reach 67.67.67.0. What would happen is we may have the LSAs in the LSDB but the route would never get put into the RIB. The forward-address suppression feature is a way around this. Essentially what it does is tell the ABR of the NSSA that is injecting the Type-5 LSAs to set the forward-address to 0.0.0.0. When the other routers get the LSA they will then forward to R5 instead of 67.67.67.6. Clearly this can COMPLETELY alter our routing path without changing ANY metrics or anything. Cool huh? Let’s see it in action.
    BEFORE:
    کد:
    R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
            Forward Address: 67.67.67.6
    
    R2(config-router)#do trace 7.7.7.7
    
    Type escape sequence to abort.
    Tracing the route to 7.7.7.7
    
      1 27.27.27.7 4 msec *  0 msec 
    
    R5(config-router)#area 65 nssa translate type7 ?
      suppress-fa  Suppress forwarding address in translated LSAs
    
    R5(config-router)#area 65 nssa translate type7 suppress-fa
    AFTER:
    کد:
    R2(config-router)#do sh ip ospf data ext 7.7.7.7 | i Forward
            Forward Address: 0.0.0.0
    
    R2(config-router)#do trace 7.7.7.7
    
    Type escape sequence to abort.
    Tracing the route to 7.7.7.7
    
      1 25.25.25.5 4 msec 0 msec 0 msec
      2 65.65.65.6 4 msec 4 msec 4 msec
      3 67.67.67.7 4 msec *  0 msec
    That about does it for today guys!!! I really hope you all enjoyed the article and got something out of it! I will be talking to you all soon :P
    Regards,

    Joe Astorino CCIE #24347 (R&S)
    Sr. Technical Instructor – IPexpert





کلمات کلیدی در جستجوها:

mikrotik ospf

mikrotik ospf multiple area

ospf

area nssa totally stub

mikrotik ospf setup example

Neighbor Down: Adjacency forced to reset

forward address ospf highest

one asbr with two forward address

the asbr with highest rid

ospf mikrotik

ospf lsa conversation

why do we need type 4 ospf

f

OSPF Type-4 LSA & The Forward-Address

ospf-type-4-lsa-the-forward-address-part-1

why do we need type 4 LSA

mikrotik ospf change lsa forwarding address

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •