[c-nsp] Quick routing question.

Drew Weaver drew.weaver at thenap.com
Thu Sep 9 13:14:43 EDT 2010


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




More information about the cisco-nsp mailing list