cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
969
Views
5
Helpful
3
Replies

Dynamic protocols over EoMPLS

mbo.hitc
Level 1
Level 1

I work in a datacenter, where customers connect to our datacenter to get their services and Internet. We work kinda like an ISP for our customers, as they have no local breakout, but are going through our datacenter to get to the Internet.

Some weeks ago we replaced the core in our network, going from a C6509 to a setup with two stacked C9500's and three stacked C9300's. The C9300 switches are connected to our customers with EoMPLS.

We have setup OSPF between the C9300 and CE switches. This used to work just fine in the old core.

 

After switching to the new core, OSPF suddenly flaps which I found out to be hello packets not being delivered at the CE. There is no problem the other way around.

After hours of troubleshooting, we ended up changning the OSPF to a point-to-multipoint non-broadcast, causing hello-packets to be unicast. This made the OSPF work just fine, and we did'nt think much of it.

 

Yesterday I decided to test a setup with EIGRP between the C9300 and a CE. This resulted in the same error as OSPF. The hello packets were again not recieved at the CE. This leads me to think there is a problem with multicast traffic.

I know this problem occured after switching to the new core, Which is why I suspect the 9300 of being the issue.

 

Have anyone heard about this problem before, and maybe found a solution?

 

 

I have tried to turn off mfib forwaring on the interface with no luck.

IP multicast-routing is turned on.

 

What I see is the neighbor being discovered in the C9300, but not on the CE. Debugging shows that hello packets are send on both devices, but only recieved by the C9300.

 

 

Config on our 9300:

 

interface GigabitEthernet1/0/27
description "HITC-Uplink-Core-WS6524G-0/7-GC"
no switchport
no ip address
spanning-tree guard root

 

interface GigabitEthernet1/0/27.852
description "ANNO1884-U-Route-Core-ANNO1884"
encapsulation dot1Q 852
vrf forwarding HITC-ANNO1884-U
ip address 10.156.2.1 255.255.255.0

 

router eigrp 1561
!
address-family ipv4 vrf HITC-ANNO1884-U autonomous-system 1561
network 10.156.2.0 0.0.0.255
exit-address-family

 

 

Config on CE:

 

interface GigabitEthernet1/0/22
description "Uplink til GC..."
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 852,855,857
switchport mode trunk

 

interface Vlan852
description "** ANNO1884 U Route Global Connect **"
ip address 10.156.2.2 255.255.255.0

 

router eigrp 1561
network 10.156.2.0 0.0.0.255

1 Accepted Solution

Accepted Solutions

I decided to setup a lab to test things, and found out the problem only occurs on configurations with subinterfaces. If I change the interface back to layer 2 traffic with SVI's, everything works fine.

View solution in original post

3 Replies 3

Hello,

 

OSPF and EIGRP use standard parameters on the C9000. You don't need ip multicast-routing turned on for the two routing protocols to work. What actually happens when you turn it off ?

 

Which IOS version are you running on the Catalysts ? There are a few bugs out there that might apply...

Hello Georg,

 

I tried turning off multicast-routing. Unfortunately the problem persists. The C9300 is running on IOSXE 16.10.1s.

Below is the debug output from EIGRP hello packets, showing that the customer edge isn't recieving the packets sent from the C9300.

As you stated, this could be a bug.

 

I have tried setting up EIGRP between the C9300 and a locally switch, which worked just fine. So it seems the problem only exists on the EoMPLS links.

I just can't figure out why, as the were no problems before implementing the C9300 and we have three different ISP's for our EoMPLS lines. So the problem just seem to be locally.

 

 

C9300:

Mar 11 13:08:52.661: EIGRP: Sending HELLO on Gi1/0/27.852 - paklen 20
Mar 11 13:08:52.661: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 13:08:53.392: EIGRP: Received HELLO on Gi1/0/27.852 - paklen 20 nbr 10.156.2.2
Mar 11 13:08:53.392: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 11 13:08:56.996: EIGRP: Sending HELLO on Gi1/0/27.852 - paklen 20
Mar 11 13:08:56.996: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 13:08:57.941: EIGRP: Received HELLO on Gi1/0/27.852 - paklen 20 nbr 10.156.2.2
Mar 11 13:08:57.942: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 11 13:09:01.655: EIGRP: Sending HELLO on Gi1/0/27.852 - paklen 20
Mar 11 13:09:01.655: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 13:09:02.689: EIGRP: Received HELLO on Gi1/0/27.852 - paklen 20 nbr 10.156.2.2
Mar 11 13:09:02.690: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
Mar 11 13:09:06.595: EIGRP: Sending HELLO on Gi1/0/27.852 - paklen 20
Mar 11 13:09:06.595: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 13:09:07.226: EIGRP: Received HELLO on Gi1/0/27.852 - paklen 20 nbr 10.156.2.2
Mar 11 13:09:07.226: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

 

 

CE:

Mar 11 12:58:13.143: EIGRP: Sending HELLO on Vlan852
Mar 11 12:58:13.143: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 12:58:17.606: EIGRP: Sending HELLO on Vlan852
Mar 11 12:58:17.606: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 12:58:22.194: EIGRP: Sending HELLO on Vlan852
Mar 11 12:58:22.194: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 12:58:26.682: EIGRP: Sending HELLO on Vlan852
Mar 11 12:58:26.682: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
Mar 11 12:58:31.456: EIGRP: Sending HELLO on Vlan852
Mar 11 12:58:31.456: AS 1561, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0

I decided to setup a lab to test things, and found out the problem only occurs on configurations with subinterfaces. If I change the interface back to layer 2 traffic with SVI's, everything works fine.