[c-nsp] Quick routing question.

[Heath Jones]

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/
>
>