09-06-2016 12:54 PM - edited 03-05-2019 04:38 AM
Hi all,
I have an issue where I would like someone else's take on things..
Basically we have a managed MPLS network by a third party so we have no insight into their PE kit config which makes this a little harder to understand, but I will try and give a basic outlay.
We have a remote site with the range of say 192.168.10.0/24 running of a CISCO router on say the Red VRF.
At our central site we have the Red VRF presented to us from the third party; they have the IP of 192.168.100.1 running on a pair of switches running HSRP between them.
They are forwarding all traffic on the Red VRF to 192.168.100.5 on our Nexus (These addresses are all in a VLAN not layer 3 on the interfaces just SVI, so 192.168.100.5 is an IP on our Nexus SVI (VLAN 100))
Basically on the Nexus we have the route for 192.168.10.0/24 heading back to the providers PE kit on the IP of 192.168.100.1 and all other destinations are being sent to another CISCO router doing NAT. This is then passed out behind one of our Public addresses back onto the PE kit on the External VRF.
I have a laptop on another VLAN (30) on the Nexus (192.168.30.1/24) which can ping the remote site and the remote site can ping my laptop with no issues at all, I can also access the internet through the Nexus and the NAT router also with no problems, however when any pings or access is coming from the Remote site through the system it is very intermittent and pings time out a lot to say 8.8.8.8 (Pinging at the same time over to my laptop though dont miss a beat and vice versa)
Bit of a weird one as all tests fine apart from when accessing public addresses from the remote site; I know its a pain also that I cant see whats going on with the third parties kit.
We are trying to move over systems to the Nexus from old kit, so this test is being unplugged from working kit where its all fine and then put onto the Nexus for testing... Part of me is thinking the PE kit is not quite getting things right when updating the new MACS for the traffic etc and its like some sort of Asymmetrical routing going on, but then again I can ping the remote site no problems, its just the problem when the remote site tries to get to anything public.
There is also a ton of NAT Xlates for the remote sites IP's also so its deffo getting to the NAT router also they do get pings now and again from 8.8.8.8 for example.
Anyone got any ideas please?
Thanks..
09-08-2016 12:34 AM
To narrow down the issue scope, I advise that one loopback interface be created on Nexus with IP like 192.168.10.x/32 (not used by any host ). Then ping 8.8.8.8 source loopback on Nexus to see if any packet loss.
09-08-2016 07:06 AM
Hi David..
There is not packet loss when accessing/pinging from the nexus to anywhere. Only when coming from the remote sites.. my packet captures are showing successful pings following the path of:
PSBA kit -> Nexus VLAN
Nexus VLAN -> NAT Device
NAT device -> Nexus VLAN
Nexus VLAN -> PSBA Kit
Failed pings are showing:
PSBA kit -> Nexus VLAN
Nexus does not then show forwarding to the NAT device. This was captured on the VLAN that all these interfaces are part of in the setup.
Hope that makes sense..
09-08-2016 09:38 PM
Thanks for the detailed clarification, I draw the topology according to your description in the attachment.
As I have said, I suspect that there are 2 LSP path in the mpls network.
When ping from remote site to Nexus VLAN, mpls network chose one ECMP LSP per session hash ( source ip / destination ip), and this LSP path show no packet loss.
However, when ping 8.8.8.8 from remote site, mpls network chose another ECMP LSP by session hash, and this LSP path show packet loss caused by intermittent congestion.
09-09-2016 02:46 AM
Hi David,
Thanks for the response and diagram.
Actually tested this OK yesterday by changing the link from the PE to Nexus as IP to IP not using a VLAN and also another IP to IP from Nexus to NAT.
I understand why it was done this way as the dual links from PE are going to a single node running HSRP so they had to use SVI.
Still not really sure why the Nexus was dropping packets like it was but at least it's working now and just need to re jig design now to accommodate the dual link from PE.
Thanks for you assistance!
09-08-2016 04:44 AM
There maybe more than one LSP in the mpls core network, when the remote site access nexus 192.168.30.1 on one LSP path which did no lose packet. And it lost packet on the other LSP path when access public Internet.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide