2

I am dealing with a really weird problem. Currently we have the following setup:

TransitA --> RouterA
TransitB --> RouterB

iBGP running btw RouterA & RouterB as well as OSPf in Area 0. We have setup a customer in Area 1 as an NSSA area on both RouterA & RouterB with identical OSPF configs like below. (I'm only including the relevant customer ospf config):

router ospf 1
area 0.0.0.1 nssa default-information-originate
redistribute connected metric-type 1 subnets
redistribute statis metric-type 1 subnets
network 1.1.1.1 0.0.0.7 area 0.0.0.1

Now, we are advertising the customer /24's over both transit providers and the problem is that over TransitA provider, we are unable to reach the customer gear. Pings/traceroutes all stop after it hits our interface ip on RouterA while everything works perfectly fine over TransitB provider.

The other piece of information is that from the customer servers, traceroutes, etc work fine when going out over TransitA so it seems the only problem is incoming traffic being dropped over TransitA. The TransitA provider says that nothing is wrong on their end and we can't find anything wrong on our end either.

Any idea where the problem may be? Is it the ospf config, bgp, etc? If you need more info, pls let me know.

Thanks

EDIT***

routerA#sh ip route x.x.x.x
Routing entry for x.x.x.x/32
  Known via "ospf 1", distance 110, metric 0, type extern 2, forward
metric 1
  Last update from x.x.x.x on Vlan8, 7w0d ago
  Routing Descriptor Blocks:
  * f.f.f.f, from y.y.y.y, 7w0d ago, via Vlan8
      Route metric is 0, traffic share count is 1

routerB#sh ip route x.x.x.x
Routing entry for x.x.x.x/32
  Known via "ospf 1", distance 110, metric 0, type NSSA extern 2,
forward metric 2
  Last update from f.f.f.f on Vlan9, 7w0d ago
  Routing Descriptor Blocks:
  * f.f.f.f, from z.z.z.z, 7w0d ago, via Vlan9
      Route metric is 0, traffic share count is 1

EDIT*More info*

RouterA#sh ip route ospf | i x.x.x.x
O E2    x.x.x.0/24 [110/0] via x.x.x.20, 1d00h, Vlan8
RouterA#traceroute x.x.x.c

Type escape sequence to abort.
Tracing the route to x.x.x.c

  1 hostname.here.com (x.x.x.20) 4 msec 0 msec 0 msec
  2 x.x.x.c 0 msec 0 msec 0 msec


RouterB#sh ip route ospf | i x.x.x.x
O N2    x.x.x.0/24 [110/0] via x.x.x.28, 1d00h, Vlan9
RouterB#traceroute x.x.x.c

Type escape sequence to abort.
Tracing the route to x.x.x.c

  1 hostname.here.com (x.x.x.28) 0 msec 0 msec 0 msec
  2 x.x.x.c 0 msec 0 msec 0 msec

So traceroutes work from both routers to the end user ip however from the internet outside, it times out over TransitA.

EDIT-PING

RouterA#ping f.f.f.f source u.u.u.u

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to f.f.f.f, timeout is 2 seconds:
Packet sent with a source address of u.u.u.u
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

u.u.u.u is our interface ip that TransitA assigned to us which we have configured on one of the ports.

TransitA#traceroute x.x.x.c source y.y.y.y

Type Control-c to abort
Sending DNS Query to 8.8.4.4

Type Control-c to abort
Tracing the route to IP node www.domain.com(x.x.x.c) from 1 to 30
hops

  1    <1 ms   <1 ms   <1 ms host.x.com[z.z.z.z]
  2    <1 ms   <1 ms   <1 ms srx.com [f.f.f.f]
  3    <1 ms   <1 ms   <1 ms www.domain.com [x.x.x.c]
  • Can you share your routing table (for customer routes) for A and B? – Ron Trunk Jan 31 '14 at 19:32
  • Here is an example route lookup on one of their ip's that doesn't work when trying to reach via TransitA. See edit above: – Network Samurai Jan 31 '14 at 19:54
  • I should also mention that the customer end device that is also running OSPF is a Juniper SRX. The default route that gets injected into the SRX area 1 has a next hop of RouterA's interface...which doesn't make sense to me either. – Network Samurai Jan 31 '14 at 19:59
  • So I see that each router is learning the customer route from a different source (y.y.y.y and z.z.z.z) Can you ping f.f.f.f from the external (transit) side of router A? – Ron Trunk Jan 31 '14 at 20:07
  • With the way we had to set things up for redundancy purposes with the srx, we had to create 1 vlan on routerA and a different vlan on routerB so both routers learn the routes via ospf over each of the separate vlans. – Network Samurai Jan 31 '14 at 20:16
2

Based on your output. The sh ip route on routerA shows the ospf type as E2 instead of N2 But the router ospf command area 0.0.0.1 nssa default-information-originate Is only going to originate the default route to the NSSA area. Can you verify the default route is getting to the customer & why on routerA its showing as E2??

1

This could be TransitA is not advertising the customer prefix to the internet. Check looking glass of other major transit provider (not TransitA or B), after removing advertisement to the TransitB, and wait up to a hour. The /24 prefix should show in the looking glass. if not, TransitA is problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.