Directly connected network not detected by router in Packet Tracer

prashanmd91prashanmd91 Member Posts: 5 ■□□□□□□□□□
Hi,
I have a packet tracer exercise file for NAT configuration. The topology looks like:


The problem is that the Office router won't recognize the directly connected 200.100.1.0/30 WAN network. I tried to add the network as a static route using "ip route 200.100.1.0 255.255.255.252". The command apparently works without any errors after checking the routing table I see no static entry for the network.

This supposedly simulates the internet. (i.e. Office router acts like it's connected to the internet). But then I should at least be able to set a default route so that the office PCs can connect to Cisco.com. I tried "ip route 0.0.0.0 0.0.0.0 se2/0" but again the routing table is not updated.

It is very interesting that whoever created this packet tracer file did something to simulate the internet. But the problem is I can't figure out what it is they did or how to set up the default route in Office router before setting up NAT.

This is the packet tracer file (couldn't attach file directly to this post. Invalid file type error)
http://www.filedropper.com/2-nat

Any help would be much appreciated.

Comments

  • negru_tudornegru_tudor Senior Member Member Posts: 473 ■■■□□□□□□□
    You're missing the "clock rate " command under the Serial interface of the OFFICE router (That's the DCE end).

    EDIT:

    Do this on the OFFICE router CLI:

    !
    interface Serial2/0
    ip address 200.100.1.1 255.255.255.252
    clock rate 64000
    !
    2017-2018 goals:
    [X] CIPTV2 300-075
    [ ] SIP School SSCA
    [X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
    [ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    Building configuration...


    Current configuration : 973 bytes
    !
    version 12.2
    no service timestamps log datetime msec
    no service timestamps debug datetime msec
    no service password-encryption
    !
    hostname Router
    !
    !
    !
    !
    !
    !
    !
    !
    ip cef
    no ipv6 cef
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    !
    interface FastEthernet0/0
    ip address 192.168.0.100 255.255.255.0
    ip nat inside
    duplex auto
    speed auto
    !
    interface FastEthernet1/0
    no ip address
    duplex auto
    speed auto
    shutdown
    !
    interface Serial2/0
    ip address 200.100.1.1 255.255.255.252
    ip nat outside
    clock rate 2000000
    !
    interface Serial3/0
    no ip address
    clock rate 2000000
    shutdown
    !
    interface FastEthernet4/0
    no ip address
    shutdown
    !
    interface FastEthernet5/0
    no ip address
    shutdown
    !
    ip nat inside source list 1 interface Serial2/0 overload
    ip classless
    ip route 200.100.1.0 255.255.255.252 Serial2/0
    ip route 0.0.0.0 0.0.0.0 200.100.1.2
    !
    ip flow-export version 9
    !
    !
    access-list 1 permit 192.168.0.0 0.0.255.255
    !
    !
    !
    !
    !
    line con 0
    !
    line aux 0
    !
    line vty 0 4
    login
    !
    !
    !
    end

    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • prashanmd91prashanmd91 Member Posts: 5 ■□□□□□□□□□
    Thank you. Can you tell me when is the clock rate command "necessary". I mean, if I just drag and drop 2 routers together, directly connect them, set up IP addresses and enable the interfaces, the routers detect the directly connected networks just fine, without my using the "clock rate" command.
  • prashanmd91prashanmd91 Member Posts: 5 ■□□□□□□□□□
    @Hondabuff you did the whole thing. Thanks. I didn't even know you could bind the ACL to the outside interface.
  • negru_tudornegru_tudor Senior Member Member Posts: 473 ■■■□□□□□□□
    Thank you. Can you tell me when is the clock rate command "necessary". I mean, if I just drag and drop 2 routers together, directly connect them, set up IP addresses and enable the interfaces, the routers detect the directly connected networks just fine, without my using the "clock rate" command.

    It's necessary because of how serial links (DTE/DCE RS-232) work. In a nutshell, the data is sent sequentially between the 2 ends of the link and rely on a clock (much like a rockband relies on the drummer for timing).

    Whilst it's true that if you drag 2 routers, hook them up via a FastEth cross-over cable, punch in some IP addresses, the routers can see one another, when serial interfaces are concerned it's not sufficient to do this...you also need the clock configured (it also regulates the speed of the link).
    2017-2018 goals:
    [X] CIPTV2 300-075
    [ ] SIP School SSCA
    [X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
    [ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)
  • HondabuffHondabuff Member Posts: 667 ■■■□□□□□□□
    You're missing the "clock rate " command under the Serial interface of the OFFICE router (That's the DCE end).

    EDIT:

    Do this on the OFFICE router CLI:

    !
    interface Serial2/0
    ip address 200.100.1.1 255.255.255.252
    clock rate 64000
    !

    Clock Rate was set already. Obvious solution was no NAT on the router.

    ! interface Serial2/0
    ip address 200.100.1.1 255.255.255.252
    clock rate 2000000
    !
    “The problem with quotes on the Internet is that you can’t always be sure of their authenticity.” ~Abraham Lincoln
  • negru_tudornegru_tudor Senior Member Member Posts: 473 ■■■□□□□□□□
    Staged it in PT 5.3.3 and clock rate was 100% missing on the DCE end. That's why the directly connected network attached to the Serial interface wasn't populating the routing table.
    2017-2018 goals:
    [X] CIPTV2 300-075
    [ ] SIP School SSCA
    [X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
    [ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)
  • prashanmd91prashanmd91 Member Posts: 5 ■□□□□□□□□□
    It's necessary because of how serial links (DTE/DCE RS-232) work. In a nutshell, the data is sent sequentially between the 2 ends of the link and rely on a clock (much like a rockband relies on the drummer for timing).

    Whilst it's true that if you drag 2 routers, hook them up via a FastEth cross-over cable, punch in some IP addresses, the routers can see one another, when serial interfaces are concerned it's not sufficient to do this...you also need the clock configured (it also regulates the speed of the link).

    They work when hooked up via Serial interfaces without setting a clock rate. I couldn't find anything to clear this up by googling. Maybe it's something wrong Packet Tracer? In real devices it may be consistent?
  • negru_tudornegru_tudor Senior Member Member Posts: 473 ■■■□□□□□□□
    not sure...could be a PT bug. What I saw in that file was that they were indeed GREEN but when issuing a "show ip int bri" the serial link was up but the protocol was down; looking at the config, I could see no clock rate was issued on any of the communicating serial ends of the link. So then you usually use the "show controllers serial x/y" to see which is the DTE and which is the DCE side and finally you issue the "clock rate" command on the DCE end which brings the link fully in service. Happens in real equipment; you don't need to set the clock in GNS3 though.
    2017-2018 goals:
    [X] CIPTV2 300-075
    [ ] SIP School SSCA
    [X] CCNP Switch 300-115 [X] CCNP Route 300-101 [X] CCNP Tshoot 300-135
    [ ] LPIC1-101 [ ] LPIC1-102 (wishful thinking)
  • prashanmd91prashanmd91 Member Posts: 5 ■□□□□□□□□□
    Thanks for the help negru_tudor & Hondabuff
Sign In or Register to comment.