[c-nsp] Quick routing question.

[Heath Jones]

Actually, it could also be an ingress filter on their side (no other packets
will be routed across 10g link except the icmp request when doing locally).

On 9 September 2010 18:32, Heath Jones <hj1980 at gmail.com> wrote:

> I think the problem is an egress filter on level3 side of 10g. It has to
> be..
>
> When pinging from 10g interface local .14<->remote .13, icmp response
> packets will certainly come back over 10g as router on level3 side will be
> using connected route. *not working*
> When pinging from host to remote .13, packets will certainly be returning
> over 1g interface as level3 has no router back to source over the 10g.
> *working*
>
> I can't see any other way for this to be happening..
>
>
>
>
>
>
> On 9 September 2010 18:14, Drew Weaver <drew.weaver at thenap.com> wrote:
>
>> Have they correctly set their end of the link - does the IP address
>> actually match what you think it should be?
>> What does ARP say!!? ARP is the most underutilised tool for stuff like
>> this!
>> --
>> They claim they have, and arp says this:
>>
>> rtr#sh ip arp
>> Protocol  Address          Age (min)  Hardware Addr   Type
>>  Interface
>> Internet  x.x.x.14              -   xxxx.xxxx.a9dc  ARPA
>>  GigabitEthernet2/1/0
>> Internet  x.x.x.13             14   xxxx.xxxx.4d7a  ARPA
>>  GigabitEthernet2/1/0
>> Internet  x.x.x.12              -   xxxx.xxxx.a9dc  ARPA
>>  GigabitEthernet2/1/0
>>
>> (Ignore the 'gigabit' part, on 12000s for some reason they never changed
>> the interface names).
>>
>>
>> I can see a scenario where downstream hosts could ping that IP, if they
>> are taking a different path and the ISP screwed up, and you could not
>> because on that router it will be taking the connected route. Only if there
>> is another path via another router - do a traceroute... Another option is
>> they have an egress filter on the new port that the replies hit, but not on
>> the old one. Are you not bringing up BGP on the new link? Does it just not
>> work, or you haven't configured it yet?
>> --
>> [root at vmz bin]# tracert x.x.x.13
>> traceroute to x.x.x.13 (x.x.x.13), 30 hops max, 40 byte packets
>>  1  gw (gw)  0.486 ms  0.458 ms  0.463 ms
>>  2  core (core)  0.460 ms  0.710 ms  0.709 ms
>>  3  rtr (rtr)  0.427 ms  0.428 ms  0.425 ms
>>  4  x.x.x.Level3.net <http://x.x.x.level3.net/> (x.x.x.13)  3.238 ms
>>  3.238 ms  3.236 ms
>>
>> So you can see here that it does at least appear to be exiting on the
>> correct router.
>>
>> I haven't configured BGP yet because I generally like to see some kind of
>> regular connectivity before I do that.
>>
>> Turn on packet captuing for the new interface, bring the link down and up.
>> You should be able to see the gratuitous ARP packets (if you are not seeing
>> anything useful with show arp).
>> --
>>  I will check this.
>>
>> Thanks,
>> -Drew
>>
>>
>>
>>
>>
>> On 9 September 2010 17:35, Drew Weaver <drew.weaver at thenap.com> wrote:
>> Howdy,
>>
>> I currently have two connections to Level3 because I am upgrading, one
>> (the old one) is a 1Gbps connection in Router-1, the second one is a 10Gbps
>> connection in Router-2.
>>
>> Both connections are up/up, the old connection is getting a full BGP
>> session from Level3.
>>
>> I noticed that no matter what I do, I can't seem to ping Level3's side of
>> our 10Gbps interface on the new connection from either of the 2 routers
>>
>> rtr#ping ip
>> Target IP address: x.x.x.13
>> Repeat count [5]:
>> Datagram size [100]:
>> Timeout in seconds [2]:
>> Extended commands [n]: y
>> Source address or interface: x.x.x.14
>> Type of service [0]:
>> Set DF bit in IP header? [no]:
>> Validate reply data? [no]:
>> Data pattern [0xABCD]:
>> Loose, Strict, Record, Timestamp, Verbose[none]:
>> Sweep range of sizes [n]:
>> Type escape sequence to abort.
>> Sending 5, 100-byte ICMP Echos to x.x.x.13, timeout is 2 seconds:
>> .....
>> Success rate is 0 percent (0/5)
>>
>> I am able to ping their side of the interface from hosts downstream from
>> the routers, just not the routers themselves.
>>
>> [root at vmz ~]# ping x.x.x.13
>> PING x.x.x.13 (x.x.x.13) 56(84) bytes of data.
>> 64 bytes from x.x.x.13: icmp_seq=1 ttl=60 time=3.27 ms
>> 64 bytes from x.x.x.13: icmp_seq=2 ttl=60 time=14.9 ms
>> 64 bytes from x.x.x.13: icmp_seq=3 ttl=60 time=3.01 ms
>> 64 bytes from x.x.x.13: icmp_seq=4 ttl=60 time=3.19 ms
>> 64 bytes from x.x.x.13: icmp_seq=5 ttl=60 time=3.10 ms
>>
>> I can't really think of any reason why I wouldn't be able to ping their
>> end of the Interface from this router, connectivity is obviously good
>> considering I can ping it from a host downstream from the router.
>>
>> Is anyone aware of any sort of gotcha when doing something like this?
>>
>> -Drew
>>
>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>