Junos OS

We have our first live subscriber who we have issued 3 addresses too. These are assigned to specific web sites.

The three /32 addresses assigned fall within the same aggregated /24 network.

The customer states that he cannot access the sites of 2 addresses but can access the site of the third address.

When we try, we can access 2 of the address sites but not the third.

Our initial MSS size was 1410, but given that my testing found our optimal MTU as 1440 and then we minus 40 for the MSS I changed it to 1400. This made no difference at all.

It is a really weird problem that we cannot seem to get to the bottom of. So, summary of the made up addresses as follows:

All addresses fall within the advertised aggregate route of 192.168.1.0/24, which we have confirmed with the upstream ISP is being accepted and also we see the range in looking-glass under bgp.

Address 1: 192.168.1.3/32 - Customer can access - We cannot access

Address 2: 192.168.1.6/32 - Customer cannot access - We can access

Address 3: 192.168.1.7/32 - Customer cannot access - We can access

This is across our new data network.

If we access from anywhere else it goes straight to all 3 pages.

So, I tried lowering the MSS again, this time to 1380 and it made no difference.

The only difference is that the two we can access are on 1 version of firmware and the one that we cannot access is on a different version of firmware.

Our routing is fine and it does seem to be related to the webpages themselves....

I'm not sure I can give any more information, but if anyone has seen this weird issue before, any help would be greatly appreciated.

This is not an easy one to resolve as the routing is fine. It appears that these addresses cannot be accessed through another tier 1 ISP either. I am pretty certain the issue is not on our network, it's trying to prove it that's the hard part.

I will close as resolved but if anyone can think of something just write it here. Thanks

In these types of situations getting a trace route to compare from the working and not working locations can also help to pin point where in the path the issue is occuring.

Hi Steve,

Thanks for coming back on this.

We have a definate issue with MTU/MSS somewhere, but trying to work out where is the issue.

From a routing perspective, the correct route back is being utilised. I have also completed wireshark traces where certain packet sizes (1434 total packet size) are not showing from one ISP but are from another. Here is the MTU/MSS configuration:

LNS:

set access group-profile l2tp-HEX-group-profile ppp ppp-options mru 1468
set access group-profile l2tp-HEX-group-profile ppp ppp-options mtu 1468

As there is no MTU/MRU set on the dynamic interface then this takes precedence.

If I look at the main SI interface, I see the following MTU size:

run show interfaces si-1/1/0 extensive

MTU: 9192

If I look at the subscriber interface, as follows:

run show interfaces si-1/1/0.3221230823 extensive

Protocol inet, MTU: 1468

Which seems to indicate it is taking the settings from the above mentioned group configuration. However, if I then look at the actual subscriber themselves, I see the following:

run show subscribers user-name <subscriber> extensive

junos-interface-mtu: 1500

Shows a different MTU size.

The configuration of the MSS is ONLY on the Core upstream bgp peer interface as below:

set interfaces xe-1/2/5 unit 0 family inet tcp-mss 1380

This seems to test outbound okay, but this is an inbound connection. So one of my questions is:

The peer interface with the MSS configuration, is this egress only or egress/ingress?

Also, the differences on the LNS  for the MTU, is this likely to be causing a problem please?

Thanks

Okay.

I have resolved the issue, and in doing so have made the connectivity faster.

After discovering that on our MX line cards the tcp-mss is for egress only, it was then a matter of resolving where to set the tcp-mss for ingress. You cannot set that on an aggregated interface, so the only place left was the dynamic-profile. So, configured it there and hey presto, fantastic news, all working. Here is the configuration line for anyone wanting it:

set dynamic-profiles dyn-hex-lns-profile interfaces "$junos-interface-ifd-name" unit "$junos-interface-unit" family inet tcp-mss 1420