I have a CCR2116-12G-4S+ we use for our BGP peering with our carrier. I want to bridge the WAN interface to the carrier equipment so I can use another of the carrier’s IPs assigned to me for another appliance that needs a public IP. I tested this internally but when I add the interface to the bridge, I lose connectivity to the next hop. Any advice or tips would be great. Since this is a generalize question, I don’t have my configs attached, but I would be happy to share if that would be helpful. Thanks in advance!
Once you make a physical interface a member port of a bridge, the bridge interface becomes the L3 interface, so you have to replace the name of that physical interface by the name of the bridge in all the remaining configuration (IP addresses, firewall rules etc.). Have you done this?
No I haven’t, that absolutely makes sense. Thank you! I’ll have to try this during off peak hours and report back.
So, when I test this during off-peak hours, the BGP session drops and I lose my connection to the carrier, and I switch back the configuration within 10 seconds. Since I have to wait for an outage window, I’m making the assumption that the carrier and my router will need to build a new BGP session when I switch to the bridge interface, and that’s why it’s dropping. Is this behavior something I should expect?
Thinking of it, I can only imagine that the bridge has cloned its MAC address from another member port than the one to which the IP address was attached originally, so the ARP record at the peer side points to a wrong MAC address until it sends another ARP request and so the BGP session gets dropped. So creating the bridge in advance and manually assiging it the MAC address of the Ethernet port before moving the IP address to it and including the port to the bridge might solve it. But if the BGP stack resets the connection solely due to moving the address to another interface, I’m afraid you’ll indeed have to wait for a maintenance window.
Thank you for all the great feedback and info!
you could insert a switch in between to use another device with another public ip from your carrier
until you get your bridge setup figured out correctly.
IF that is an option you could do.
but be aware - if there is a managed switch, the uplink port (to your carrier) and the WAN port(s) of your CCR (and additional device) need to be in the same VLAN (most likely untagged)
So, I’m seeing that if I have the interface attached to the bridge, I cannot ping via the bridge interface to my ISP. However, the WAN appliance connected to ether1 has full connectivity. Here is a partial snippet of my configuration -
/interface bridge
add arp=proxy-arp name=Spectrum_Distro protocol-mode=none
add name=loopback
/interface ethernet
set [ find default-name=ether13 ] name=mgmt
set [ find default-name=sfp-sfpplus1 ] comment=“to Spectrum”
/ip vrf
add comment=“VRF for WAN Edge Activity” interfaces=
sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4,Spectrum_Distro name=bgp
/port
set 0 name=serial0
/routing id
add disabled=no id=10.255.255.253 name=wan_edge select-dynamic-id=“”
/routing ospf instance
add disabled=no name=FTMC originate-default=always out-filter-chain=BGP-in
redistribute=bgp router-id=wan_edge routing-table=bgp vrf=bgp
/routing ospf area
add disabled=no instance=FTMC name=wan_edge
/routing bgp template
set default disabled=no routing-table=bgp vrf=bgp
/snmp community
add addresses=::/0 name=ftmcsnmpro
/interface bridge port
add bpdu-guard=yes bridge=Spectrum_Distro ingress-filtering=no interface=
sfp-sfpplus1 trusted=yes
add bpdu-guard=yes bridge=Spectrum_Distro interface=ether1
/ipv6 settings
set disable-ipv6=yes
/ip address
add address=10.2.10.253 interface=mgmt network=10.2.10.1
add address=10.255.255.253 interface=loopback network=10.255.255.253
add address=my.public.ip interface=Spectrum_Distro network=my.public.gateway
/ip firewall address-list
add address=0.0.0.0/0 list=default_route
/ip firewall filter
add action=accept chain=input comment=“Allow ICMP” in-interface=mgmt protocol=
icmp
add action=accept chain=input comment=“Allow SNMP” dst-port=161 in-interface=
mgmt protocol=udp
add action=accept chain=input comment=“Allow SSH” dst-port=22 in-interface=mgmt
port=“” protocol=tcp
add action=accept chain=input comment=“Allow Winbox” in-interface=mgmt port=
8291 protocol=tcp
add action=accept chain=input comment=“Allow NTP” dst-port=123 in-interface=
mgmt protocol=udp
add action=drop chain=input comment=“Drop Other MGMT Traffic” in-interface=mgmt
add action=accept chain=input in-interface=sfp-sfpplus4 protocol=icmp
add action=accept chain=output out-interface=sfp-sfpplus4 protocol=icmp
add action=accept chain=input comment=“Allow BGP In” in-interface=
Spectrum_Distro
add action=accept chain=output comment=“Allow BGP Out” out-interface=
Spectrum_Distro
add action=accept chain=input comment=“Allow OSPF In” in-interface=sfp-sfpplus4
add action=accept chain=output comment=“Allow OSPF Out” out-interface=
sfp-sfpplus4
add action=drop chain=input comment=“Drop ALL Remaining Traffic”
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.2.10.1 pref-src=“”
routing-table=main scope=30 suppress-hw-offload=no target-scope=10
/ip service
set www disabled=yes
/routing bfd configuration
add disabled=no vrf=bgp
/routing filter rule
add chain=BGP-in disabled=no rule=accept
/routing ospf interface-template
add area=wan_edge disabled=no interfaces=sfp-sfpplus4
/system clock
set time-zone-name=America/Detroit
You don’t use stateful firewall (no “accept established or related” rule in chain input of filter) - nothing wrong with it per se, but for in-interfaces other than MGMT, chain input in filter looks as follows:
action=accept chain=input in-interface=sfp-sfpplus4 protocol=icmp
action=accept chain=input comment=“Allow BGP In” in-interface=Spectrum_Distro
action=drop chain=input comment=“Drop ALL Remaining Traffic”
So the responses from the ISP to your ping requests sent from the Tik itself are dropped in firewall. Not sure what other changes you did when reconfiguring the WAN, i.e. whether it is directly related to those changes or whether it has always been like that and you have only noticed it now after doing those changes.